In the run up to OPEN 2018, Oliver Sylvester-Bradley from The Open Co-op interviews Claire Tolan, a developer at Resonate, the music streaming co-op, about RChain, a new framework for scalable blockchain applications, which aims to enable ‘glocal’ cooperation.
The technical design of RChain has foundations in ‘rho calculus’ which requires a little mind-power to comprehend in detail but, what becomes clear in this interview is that RChain has amazing potential for the cooperative sector. The tools they are building are all open source and aim to liberate cooperation at scale.
OSB: Hi Claire, thanks for talking to us. Can you explain to our readers, what is RChain?
CT: RChain is basically a blockchain 3.0 infrastructure. If you think of Bitcoin, and other crypto currencies as blockchain 1.0, Ethereum is like blockchain 2.0 – it comes with Ether (the Ethereum network’s crypto currency) but also allows smart contracts. Ethereum enables you to do more complex things like creating a decentralised back end for a web app. The reason we call RChain blockchain 3.0 is because it takes what Ethereum does and spins it on its head – the most fundamental way being that it allows concurrent transactions.
Ethereum blocks come one after another, in a linear fashion – that’s the way its set up – using ‘proof of work’ to mine blocks. With RChain we are using ‘proof of stake’ – a different method of adding blocks to the chain.
OSB: OK, we might need a little background here! How does ‘proof of stake’ work?
CT: We’re currently implementing Casper.
[Aside]: Casper is a security-deposit based economic consensus protocol. This means that nodes, so called bonded validators, have to place a security deposit, an action called bonding, in order to serve the consensus by producing blocks.
In Casper style proof of stake anyone can participate in block production by posting a bond. After posting a bond you have an opportunity to bet on which block will be included next. The incentives are such that you make money by betting with the eventual consensus and lose money by betting against the consensus. Any crypto-graphically provable misbehavior results in the forfeit of the bond.
An analogy can be made to proof of work where each miner is betting with their hash power on which block will be accepted. If they bet wrong then any block they produce will be orphaned, causing them to lose money.
For more information, see this Casper paper.
CT: If I’m running a node and I want it be validated – I offer up a coin (a stake) and say, “Look I’m offering you this money – I promise you can trust me to validate things correctly” then, if the node gets validated I keep my stake and earn a bit more in addition – but if I say something untrue I lose the stake I put up and, in some versions of this I’m also “slashed” – so I am untrusted and can’t offer new pledges of validation for a while. Being “slashed” is like being given a timeout – like being told off in a computational manner.
RChain allows concurrent mining of blocks – so instead of solving puzzles to make new blocks, like in blockchain 1.0 – the proof of stake concept creates a fractal structure of validation.
What ends up happening, if you think of 4 validators – 4 nodes trying to validate transactions – Number 1 gets a block which has been validated by node 2 and says “OK, I see it aligns with the others” – whilst the same process can happen between nodes 3 and 4. This process allows nodes to validate in any order – and then, after a certain number of nodes have agreed, a new block gets added to the chain.
OSB: So does this mean that RChain allows for ‘multiple versions of the truth’, like Holochain does?
CT: Not exactly – The truth spins through different nodes in different orders – but the state ends up catching up so there is one truth.
The other thing that happens is we also have different regions, which have different chains. Certain transactions belong to a certain region so, for example, when I’m buying coffee the transaction validates in a certain region designed to manage coffee purchases – and there’s another one for FinTech. They obviously don’t need to be linked, unless they need to transact with each other.
Both proof of stake and the regions concept link back to the core of RChain – which has its foundations in rho calculus.
OSB: OK, I’m worried I might get out of my depth here but can you explain what is rho calculus?
CT: Rho calculus is the model of computation used to create RChain and Rholang. It was innovated upon the pi calculus to fit well for what the market requires for “blockchain apps”.
Pi calculus provides a mathematical way to understand many different transactions that are happening simultaneously. For example, if I’m driving and texting I’m paying attention to the road and the text – these things are not connected but are linked back to my body.
Rho calculus is an expansion on Pi such that it becomes reflective, meaning that the system is able to check back on itself – so kind of like I can also have a God’s eye view of both of me texting and driving!
What both allow is different mathematical functions to happen in different channels at the same time – and they are happening at the same time and don’t need to talk to each other – but afterwards the channels can come back together and split apart again.
In computing we think a lot about things happening in parallel – and this is like parallel pumped up – independent but able to talk back to each other. The systems interact better than before – they are no longer naive, they link up better.
OSB: Does that also mean it works, and can deliver transactions, faster?
CT: Yes, with Ethereum you can have 20 transactions / sec – But with RChain you will have transactions to the tune of 40,000 /sec. This increase in speed because of concurrent processing means better pricing and faster transactions. So I don’t have to wait to buy my coffee – because more than two things can happen at the same time.
OSB: So is there an RChain currency already?
CT: At the moment we have RHOC, which is an Ethereum token. We will have a coin called REV. We’re currently building the infrastructure which will have a directory of wallet holders. When the Ethereum chain reaches a certain block height, this will be the point where we will take a snapshot of RHOC to flip into REV. Then there will be a period of oversight, where users can check and make sure the correct total is there. This is the most common way projects launch from Ethereum.
Currently, RChain’s RHOC is used as a placeholder for REV. When we switch to RChain, users will also be able to use REV to pay for phlogiston (like Ethereum’s gas) in the way you use ETH to pay for Gas on Ethereum.
OSB: Wow that sounds exciting. So at some point you’re going to flip out of Ethereum and RHOC and to launch ‘for real’ on RChain with REV. That will be a significant moment – what will you call the launch?
CT: RChain will launch a test net in September – we don’t have all the answers yet… when the test net is launched, we can test our contracts… it will probably be December when the Genesis event happens.
OSB: “The Genesis event”. So then RChain will exist independent of Ethereum – and become its own pure p2p network?
CT: Yes, validators will run the full RChain software.
OSB: Is there a mission to get more validators?
CT: Yes, it will be more robust with more nodes – although it would work on a smaller scale. The goal is to have about 1750 validators with an average of 50,000 REV (although the reality will be closer to an elliptic curve) staked per validator. This way about 10% of REV will be staked. Groups of individuals with smaller amounts of REV can form a pool.
Unlike some other PoS consensus systems, all validators will be known and will have a contract with the co-op. Full details of how validation will work will be available in August.
OSB: OK, keep us posted about that. So, to get back to your day job, let’s talk about Resonate quickly. We interviewed Resonate’s founder, Peter Harris, so our readers should have some idea about how the music streaming app works but, is Resonate currently running on Ethereum then?
CT: No, we’re developing some decentralised architecture in the fall – and then we’ll transition onto RChain in the new year. LifeID are doing the same.
OSB: It must be very important to get ID right – as it’s such an intrinsic part of the system?
CT: I’m developing something called the Mycelia passport – It’s an identity system for musicians – the foundations for this is what lifeID is developing: Decentralised identifiers that you bring in to different services via verified claims which mean that, for example, my hospital has my birth certificate, so they can issue me a claim which says Claire is older than 18 …. and then I can show that claim from the hospital – and the third party never needs to see my birth certificate. This allows individuals to be issued claims from authorities, which allows them to function in other services without revealing sensitive details.
We can also use this system to provide artist authority to make claims over data – and connect with other artists – a kind of web of trust – Alice and Bob can issue claims that they know each other – like PGP keys – the system increases in value with more connections – and your “clout” increases.
We’re building an ecosystem of services but, ultimately we’re headed towards one ID system – one app would store all you identifiers – but several different types of identifiers – so your entire ID can’t get compromised – this is what lifeID is building.
OSB: So, if I’m a member of lifeID and a member of Resonate – does that mean that, in the future, as more co-ops and other services come on board, they could potentially share member data (providing the members have given permission to do so) to help co-ops scale up and avoid traditional member acquisition costs?
CT: Yes, that’s part of the plan – to create tools that can be used by co-ops. For example, Mycelia and Resonate are building several tools and part of that will be a social network for musicians.
Other co-ops could abstract the social network to provide other functions, so a co-op could have a web of trust and offer that to other co-ops to allow them to see all of their members’ connections. We’re also developing systems which allow decentralised voting, and content management – this can all be done on RChain and it’s all open source, to its very core.
RChain has a mandate to build tools for co-ops to use… Once you have a ‘Web of Trust’, it can be applied to other co-ops. Maybe you have a site where co-ops’ organisations have established relationships and you could use the web of trust to encourage cooperation between them and their members by extending this to the individual level.
OSB: Getting the ID element of this right seems fundamental, as it then enables so many other things based on trusted relationships between co-ops and their members…
CT: Eventually you will have an app like a creative passport, which stores all your ID details, through which you can give permission to other apps and services to use your data, but you can revoke this at any time. With RChain, you develop modules and other co-ops can use these and build on them in new ways.
OSB: How does RChain aim to help the cooperative sector?
CT: As well as the RChain technology, we’re also working on governance – if RChain can figure out modules for voting, they could be used by other co-ops. If we can solve some of the issues of governance through this tech, we should be able to assist inter-co-op governance.
We can remove questions like “who stores and manages it”? by decentralising that to partners with stakes, both in terms of storage and upkeep of the data. We can use this to connect co-ops globally throughout the regions of the world to enable “Glocal” co-operation.
OSB: That sounds like exactly what we need – more global co-operation with actions taken at the local level. Whilst we’re talking about regions, the regions you mentioned in terms of validation are not geographical regions, right?
CT: No, validation is via “region”, but these are not geographic – you can belong to many – or multiple validation regions.
OSB: Right, so it sounds like RChain is working on the meta-system we have needed for so long, to help co-ops everywhere co-ordinate their activities and actually start co-operating between themselves a bit more. What plans do you have to make that happen?
CT: That’s part of the purpose of RChain Europe, which is being established as a German co-op – it’s part of our mandate. It’s also the ethos of Greg Meredith, the founder of RChain – he wants to help enable co-ops with better tools.
OSB: Excellent. You seem to have some good people behind RChain and the resources to make things happen…
CT: Greg was CTO of Synereo [a project to build a decentralized social network based on the attention economy], but decided in his role he couldn’t do what he wanted politically… So he split to make RChain, and part of the funding comes from tokens from that, plus a private sale. Politically, Greg did what he did for a number of reasons. As the inventor of rho calculus, he saw how concurrent transactions plus proof of stake could be combined and would use less computing power than conventional blockchains. That means a lower energy footprint even though we are processing more transactions…. Also, RChain has positioned itself quite politically, aiming for a different, more democratic future.
OSB: I understand that RChain has a few different divisions – is the RChain Co-op the mothership?
CT: Yes, RChain Co-op stands on its own and has two ecosystem development partners, Pythia and Reflective Ventures, which sit under the co-op. There’s also a development team called Pyrofex to do the bulk of the developing.
OSB: How big is Pyrofex?
CT: They are about 20 people working in collaboration with Greg planning the development. The writing of code is often done by them in Boulder – although there are RChain devs all over the world.
OSB: That sounds promising, everything we have discussed clearly demands lots of geekery, much of which is beyond my understanding!
CT: [Laughs] Yeah – and it’s all open source – you can see it all on Bitbucket via the RChain developer site. I follow the commits and it’s cool to see it taking shape and track the goals and the timeline. If you’re a member of the co-op, you can join the chat too – it’s not just about tech either. There’s a lot about governance and memberships too.
OSB: How can people get involved?
RChain, like Resonate, has open community calls every week – RChain’s [debriefs] are at 11:00 am PST on Weds. and the Resonate debriefs are at 8:30 am PST on Fridays (5:30 pm Berlin time). Anyone can follow on Zoom or on Youtube, which is a good way to learn and follow what’s going on. There’s also the community forum resources and obviously if you join the co-op you can get involved how you like.
OSB: That’s great – I joined the co-op already. Can you explain the RChain Bounty system?
CT: We’d like to implement one of these at Resonate. It’s basically an open list of issues that need to be fixed, both tech and non tech. It’s exciting because it’s a way to get rewarded and not just for code bugs.
OSB: I think the bounty system is really smart – it provides a way for the members of the co-op to not only assist and direct and promote the project but also to get rewarded for their input, creating the perfect incentive system, which is bound to help the community grow.
Thanks for talking to us – we look forward to hearing more at OPEN 2018.
Claire Tolan will be speaking in the session on Open source social networks, protocols and platforms
at OPEN 2018 on July 26, 2018 at 1:35 pm alongside Mayel De Borniol from Social.coop; and Mark Harding from Minds.
We will be asking them:
- How does the governance of social networks affect take up and adoption by the co-op community?
- Should we be looking beyond the platform and instead working towards shared protocols and schemas to help catalyze the collaborative economy?
Join us at OPEN 2018 to learn more…
Pingback: Scaling platform co-ops - lessons from Resonate.is - The Open Co-op