From Queue to No Queue, Answer to ETH’s Scaling Already Given 5 Years Ago
The text below is an advertorial article that was not written by Cryptonews.com journalists.
A Discussion around ETH Scaling Solutions between Greg and Vitalik in 2016
– Atticbee. New Jersey, USA
Introduction
The reason for writing this article was a request I received one day on Discord from Darryl. He asked me to explain a technical discussion that took place back in ‘2016. In this discussion Greg, Vitalik and Vlad talked about the route to scaling Ethereum. The video can be found at: https://www.youtube.com/watch?v=DXbvUu-_0S0. The Tarot Fool avatar “Lucius” in the video is Greg, the founder of RChain.
Darryl, the music producer of the RChain community, is a very colorful person. Not only does he have a few Grammy nominations, but he is also a quite enthusiastic learner of blockchain technology and is very supportive of the Chinese community’s marketing efforts. So I took his request quite seriously. Of course, there is a more important point, the idea that “Greg proposed RChain’s technology to Vitalik before but got rejected, RChain thus became an independent project” has been in the community for a long time, but I was not familiar with the details. So it was meaningful for me to watch the video of the discussion back then and review the development of the public chain in the past few years. Volunteers also helped to add Chinese subtitles to the video.
After reading it, I realised that Greg actually completely presented RChain’s key ideas in this discussion to the Ethereum community, without any reservation. And Vitalik was indeed hand-cuffed by backward compatibility. Also back in 2016, Vitalik’s understanding of the key role of the computational model to blockchain development was not that deep. What I don’t understand at present is that from 2016 to 2021, five years passed with two rounds of bull and bear cycle, Greg’s insights are already proved, but are still not taken seriously by the industry. On the other hand many projects are still working tirelessly to build various variants of Ethereum, and won’t jump out of the idea of “queue the transactions and run them sequentially”. RChain, which was built according to Greg’s idea and on the Pi Calculus principles, has yet received only very little notice from the public, which is indeed a pity.
With Shixi, we decided to edit this video with Chinese subtitles and post it to the community. On one hand, we want to let people know the history of this project, and on the other hand, we want to give a reference to the general blockchain industry and so that some ideas can be cherry-picked when new blockchains are designed.
The video is divided into two parts, Greg lead the first half of the discussion about the scaling solutions, and the second half is some design details of the Casper protocol, which can be skipped if you are not interested. Greg raised several key points, and the excerpt of the conversation involved is demonstrated as follows:
Vitalik, Vlad and Greg discussion in 2016
Key idea #1 – Concurrent consensus based on contract isolation by namespace + static analysis
Greg:I argue that because we control the namespace, which is essentially the address space, it should be sufficient to do static analysis in order to infer isolation amongst the contracts. With isolation information what you can do is tell if transactions against two different contracts can be continued or not.
Vlad: It is helping convergence because you can converge on two different sets. Although if contract developers were to give it [address range declaration] maybe we could give them like a gas discount.
Vitalik: Yeah in general one thing I’m not gonna compromise on for Ethereum 2.0, is that everything that was possible in 1.0 should continue to be possible.
Key idea #2 – Concurrent execution based on Pi Calculus
Vlad: I mean certainly execution will definitely use sharding. Any scaling solutions is going to have concurrent execution. The question of whether or not the core of the EVM will be on the Pi Calculus is still pending.
Greg: It doesn’t have to be based on the Pi Calculus, Pi Calculus just happens to be the best concurrency calculus for this kind of stuff.
Key idea #3 – VM with built in type systems and formal validation support
Vlad: The other thing about requiring types is that it increases the burden on the contract developers.
Greg: Unless you have some kind of type inferencing.
Vlad:I don’t think that we have consensus on the idea that we will use a VM that’s designed for contracts to be easily formally verifiable in the concurrency setting. To me it seems like a no-brainer that we would have this option. I want mission-critical applications to be deployed to the blockchain, I want it to be secure enough and form verification is like the only way that really does that.
Greg: You don’t ever need typed execution, you can always do untyped versions of typed things. It just ends up being much more costly over time.
Vlad: The question is the following: formal verification obviously comes at a higher cost in terms of understanding and labour. But you know I think that is probably worth it.
As you may be wondering when you see the conversation excerpt, it’s mainly between Greg and Vlad. But Vitalik, the founder of Ethereum, wasn’t involved too much. As you can see from this discussion video, at least in 2016, the speciality of the three people are: Greg – computational theories; Vlad – protocol design; Vitalik – economic incentives design
Greg and Vlad are the main talking heads when it comes to discussing the scaling route, while Vitalik was repeatedly insisting on the importance of backwards compatibility with Ethereum 1.0. Of course, everyone has been learning and growing fast in this brand new sector of computer science so this conclusion may be very out-of-dated.
Discussion
Next I’d like to explain the key ideas above.
Key idea #1 – Concurrent consensus based on contract isolation by namespace + static analysis
This is actually the theoretical basis for RChain’s concurrent execution + sharding. One thing blockchain has to do is achieve consensus for transaction order. The very first question to ask is, do you put the transactions in a queue for consensus, or do you separate them according to some logic for concurrent consensus?
For example, if you buy a kebab on the street in Shanghai and I buy a coffee at Starbucks in New York, these two transactions should obviously not be queued for consensus, but can be executed simultaneously. The consensus for buying a kebab and the consensus for buying a coffee can be done separately, regardless of the consensus protocol used. This design should be reflected in the blockchain behavior as: “concurrent block producing, voting and finalization”.
How to judge if two transactions can be executed concurrently? Greg gave the answer:
First, the transactions have to be isolated according to certain rules, such as name or address space. In the above example, “Shanghai street” and “New York Starbucks” are examples of address spaces.
Furthermore, the two mutually isolated transactions can not only be executed at the same time, but can also be assigned to different consensus groups, i.e., shards.
Second, the transaction should be able to be analyzed statically. By static analysis, I mean that a transaction can be analyzed before it is submitted to the blockchain to find out what resources it accesses, whether there is any conflict between two transactions, and so on. In the above example, before a transaction is submitted, you should be able to know during the compilation period that it will only access resources in the “Shanghai street” and will never run out of this range. This is the only way to know if consensus between transactions can be done simultaneously, without having to order them.
In my table of correspondence between blockchain and traditional computer systems, the consensus layer of blockchain is the IO layer of traditional computers. The key idea 1 is equivalent to the implementation of concurrency at the IO layer, i.e. upgrading from Ethereum’s tape drive into RChain’s SSD.
Key idea #2 – Concurrent execution based on Pi Calculus
Idea #1 is actually “concurrent consensus”, while idea #2 is “concurrent execution”. In order to scale infinitely, the blockchain must have no single-threaded bottlenecks, and the underlying EVM, WASM and other state-based virtual machines are precisely single-threaded bottlenecks. If blocks are produced concurrently, when a validator receives many transactions at the same time, it still needs the ability to execute them concurrently in order to truly achieve the effect of “no queuing”. Otherwise, it is equivalent to “no queue in this first room, but after you enter a second room, you still need to wait in line”.
Back to my blockchain and traditional computer system, with the ability of idea #2, you get concurrency in the computing layer. With ideas #1 and #2, i.e. concurrency in both IO and computing layer, the blockchain computer can really serve billions of people.
Key idea #3 – VM with built in type systems and formal validation support
When #1 and #2 are implemented, the blockchain can now concurrently converge to consensus and execute transactions, is everything fine? Both Greg and Vlad’s have the same answer: No, we also need formal verifications under the concurrence setting. And, the ideal way to do formal verification is to use type inference, instead of letting the user take the responsibility.
Ultimately, the choice is for the VM to support “typed execution”, which is much less expensive in the long run than “untyped execution”. “Typed execution” is the equivalent of a firewall. Only when contracts are executed and interacting with each other under the protection of these firewalls, can security be guaranteed, and only then can many contracts be truly woven into a web of contracts, forming an unparalleled network effect. Various race conditions and deadlock problems will otherwise haunt dApp developers and users over and over again.
Finally, let’s review how much RChain has accomplished on the above 3 key ideas today in 2021.
First, idea #2: Concurrent VMs were achieved long ago when RChain launched the mainnet.
Today (june 2021), block merging is running on the test network. Idea #1: Concurrent consensus is almost ready.
Finally, the OSLF paper has made key theoretical preparations for ideal #3, and when the milestone of external validators is accomplished, it will be time to sail for Venus, and put idea #3 into implementation.
On the other hand, how much progress has been made by Ethereum, which continues to follow the state machine route?
Layer 2 also improved many things, roll ups being one of them. However layer 2 comes down to the following: “go out-door to form new queues, and report back the state changes to the main queue”. There is no real interoperability between queues.
ETH 2.0 is progressing slowly, various sharding projects in the market already foretell the future of ETH 2.0 which is to “form many queues inside closed rooms”. However there is still no real interoperability between queues, two queues will never equal one queue.
No matter which one queuing solution is chosen, it is an incomplete scaling, or even not a scaling solution at all. One needs to understand the foundation of computing theory, without this understanding, pursuing scalability is like chasing a mirage. Even smart folks like Vitalik, still haven’t realized that the way to break the wall of the “impossible triangle” is precisely the three key steps of the “abandon queuing once for all” approach proposed by Greg in this discussion back in 2016.
So I wrote “Five years of Ethereum Scaling Dream, The Wallbreaker Is Originally Within the Team”.
Media contact
Contact: Shixi Lin
Company: RChain Cooperative
Phone: +1 (206) 580-3249
Email: [email protected]
Website: https://rchain.coop/
Address: 12345 Lake City Way NE Suite 2032 Seattle, WA 98125
