Due to the conflict detection features of RChain’s programming language, Rholang, RChain can natively run events concurrently, a unique feature outside of any other layer one blockchain platform. This enables RChain to scale as you add hardware.
Darryl Neudorf 00:00
So I have a couple technical questions.
Greg Meredith 00:03
All right, let’s hear them.
Darryl Neudorf 00:05
So one is really short. And it’s also a tweet that you did recently: “RChain, the only blockchain that when you add hardware, it scales.” And so I was just wondering if you could explain that in a more layperson perspective, from both the angle of how RChain does it and how other blockchain approaches to scaling don’t achieve it.
Greg Meredith 00:29
Yeah, so it’s a combination of technologies in RChain. As I mentioned before, the issue is not just improving the consensus algorithm. Improving the consensus algorithm helps a lot, as we just talked about. But the second issue has to do with whether or not you’re able to take advantage of the hardware as a result of the way you’re processing the transactions.
So let’s assume that you’ve already achieved consensus efficiently, then even if that’s the case, if your mechanism for processing transactions, forces you to process them one at a time, then all of the transactions are going to be piled up end on end. But you know, the the analogy I’ve given over and over again, this is like the multi lane freeway, if you have a multi lane freeway, and there isn’t very much lane crossing, right, so everyone pretty much finds their lane and stays in their lane. If you have “n” lanes, you’re getting roughly “n” times the throughput than a single lane freeway. And what this corresponds to, is the fact that most transactions are isolated from each other.
So you know, just think about all your friends, unless you or your friends are paying each other. Almost certainly most of your transactions in a day are separate from each other. And that’s certainly the case when you start moving outside of jurisdictions, right. So the point is that, Darryl, when you you know, if you bought some coffee this morning at a coffee shop, almost certainly that transaction, and the resources it touches is separate than Steve buying a cup of tea in the in the UK. So as a as a result, each of these transactions could find its own lane. And so they could all go down the freeway together at the same time. But if your means of processing the transactions, forces you to put one transaction after the other, they don’t go down the freeway at the same time, they’re all funnelled down to one lane. So you can imagine what happens if you were to take an 8 lane freeway and funnel all those lanes of traffic down to one lane. That’s the issue.
So what you need to have is, after you’ve solved the efficiency of the consensus algorithm, you need to be able to detect when it’s possible to run all those transactions, you know, side by side, they can all run down the freeway together, so to speak. And RChain does that. Because the way we the way we represent transactions in the rho calculus or in rholang, we can detect the conflicts, ie touching the same resources based upon which channels are utilized in the transactions. And so we don’t have to rerun the transactions to determine if there’s a conflict, we can statically just look at the form of the rholang and see if there’s any kind of conflict.
And we now have proof that even for 20 branches, the conflict detection is still sub second. And then when you merge 20 branches, it’s happening in about six seconds, that’s 20 branches worth of transactions is happening in about six seconds. So what that means is that as you add validators, you’re effectively adding more lanes to the freeway. So you can get more and more transactions flowing side by side instead of end on end. And so that validators corresponds to hardware.
So as your add more hardware, you get more and more throughput through the system. Now, of course, there’s diminishing returns, but right now you can get hundreds of these things side by side, and you will increase at a near linear growth rate. So, but this is exactly the opposite of what happens with ethereum and Bitcoin and other kinds of systems. As you add hardware, they slow down because you get more and more contention for the resources.
“The combination of Casper and Rholang provides decentralized scheduling of which events can run in sequence vs which can run in parallel.” – Greg Meredith
Steve Ross Talbot 04:48
So I just want to try out a little analogy. Right. So imagine Darryl you go to Starbucks, near where you live, and I go to Starbucks near where I live. If it’s just that I’m in the UK, and you’re in Canada, so when I pay for my Starbucks coffee, and you pay for yours, and that’s registered on the till, and goes, therefore, into the digital world to be accounted for the UK accounts for its stuff. And the Canada Starbucks accounts for its stuff, right. And it may be that it gets rolled up in Canada, or it may be that it’s done by region and the same here in the UK. But essentially, if if we have to wait for Starbucks headquarters to validate the transaction, we would be waiting a long time and our coffee would be cold.
And so there’s a natural way of organizing. that’s evident in the real world, Starbucks just being one example as to how we understand concurrency of transactions and, and the benefit of so doing, because without that, we couldn’t scale businesses internationally. possible. And actually, I would say what RChain does over and above that, it, first of all, it recognizes that sort of pattern. But it also makes it possible for those patterns to spring up more dynamically, rather than being engineered by some sort of Enterprise Architect types, helping to set up these multi international businesses.