Author: Don't give the machine crazy
The origin of drafting this article is that one day, I received a request from Darryl on Discord, let me explain to him a technical discussion video that happened in 2016. In that discussion, Greg, the founder of RChain, and the founder of Ethereum Vitalik, the founder, and Vlad, the founder of the Casper protocol, discussed the scaling route of Ethereum.
Darryl, a music producer in the RChain community, is a very colorful person. Not only has he been nominated for several Grammy Awards, but he also maintains a "joyful learning" for blockchain technology. The publicity work in the district is also very supportive. So naturally I will not refuse this request. Of course, there is another more important point. The saying that "Ether does not accept Rho calculus, and RChain claims to be the roost" has been around for a long time in the community, but I am not the person involved after all, so I dug out the discussion video from that year and compared it with this It is still very meaningful to review the development of the public chain in the past few years.
After reading it, I found that Greg has fully presented the main idea of RChain in this discussion, without any reservations about the Ethereum community. V God is indeed bound by backward compatibility, and V God in 2016 does not have a deep understanding of computing theory. But what I don't understand is that from 2016 to 2021, the bull and the bear in the currency circle have alternated two cycles for five years. However, the idea of God G in the public chain circle is still not valued by enough people. Working tirelessly to create various variants of Ethereum, we can't jump out of the vicious circle of various "queuing". It is indeed a pity that RChain, the project built according to G God's ideas, is still in a state of "raised in a deep boudoir and no one knows about it".
So I decided to publish this video with Chinese and English bilingual subtitles. On the one hand, let everyone know the historical origin of the RChain project, on the other hand, it is also a reference for the entire public chain circle, adding new ideas to the design of the new public chain.
The entire video is divided into two parts. G God dominates the discussion on the expansion part in the first half, and the second half is some design details of the Casper protocol. If you are not interested, you can skip it. To summarize, Greg made a few key points, and excerpts from the conversation involved are as follows:
Key point 1. Concurrent consensus based on contract isolation + static analysis
Greg: I think that since we control namespaces - essentially address spaces, those address spaces should be sufficient to use static analysis to infer (resource) isolation between contracts. You can say whether essentially two propositions correspond to two different contracts, and whether transactions calling two different contracts can be executed or not.
Vlad: It basically helps with consensus convergence because you can converge consensus on two different sets.
Vlad: But if the user gives (address limit), maybe we give them a gas fee discount.
Vitalik: In general, there is one thing I will not compromise on Ethereum 2.0. That is everything allowed in Ethereum 1.0, and should continue to be allowed in Ethereum 2.0.
Key point 2. Concurrent virtual machine based on Pi calculus
Vlad: I think the execution will definitely be on the shards, and any scaling solution needs to be executed concurrently. The question is whether the core of the EVM needs to be based on Pi calculus? I think this problem still exists.
Greg: It doesn't have to be based on Pi calculus, and Pi calculus happens to be the best concurrent calculus of this kind.
Key Point 3. Type Systems and Formal Verification
Vlad: I'm sure another downside of requiring contracts to provide types is that it increases the burden on contract developers.
Greg: Unless you have some kind of type inference.
Vlad: I don't think we have reached a consensus that we will use a virtual machine, which is designed to allow easy formal verification of contracts in a concurrent environment. It seems obvious to me that we need to have this option. I want mission-critical applications to be deployed on the blockchain, and I want it to be secure enough. And formal verification seems to be the only way to really do this.
Greg: Yeah, you never need a typed implementation, you can always make an untyped version of something that is typed. It's just that it's much more costly to do so over time.
Vlad: The problem is that formal verification, as you know, is more expensive to understand and labor. But you know I think it's worth it.
You may be curious to see here, it is basically a conversation between Greg and Vlad, but Vitalik, the founder of Ethereum, did not participate too much. Yes. As can be seen from this conference video, at least in 2016, the specialty of these three giants lies in: Greg—computation theory; Vlad—protocol design; Vitalik—economic incentive mechanism.
So when discussing the expansion route, Greg and Vlad are the protagonists of the conversation, and V God is just insisting on the importance of backward compatibility with ETH 1.0. Of course, Shibie should look at it with admiration for three days, not to mention the field of rapid knowledge update such as blockchain, it may be worth talking about it now.
Figure 1. All public chains other than RChain need to queue transactions
Figure 2. The evolution from "need queuing" to RChain's "no queuing" is the key point of public chain expansion
Next, briefly explain the above key points.
Key point 1. Concurrent consensus based on contract isolation + static analysis
This is actually the theoretical basis of RChain concurrency + sharding. What the blockchain does is to make a consensus on the transaction. After all, are you lining up transactions for consensus? Or separate them according to a certain logic for concurrent consensus?
For example, you buy skewers on the streets of Shanghai, and I buy coffee at Starbucks in New York. Obviously, these two transactions should not be queued for consensus, but can be done at the same time. The consensus of buying skewers and the consensus of buying coffee can be carried out at the same time, no matter what consensus protocol is used at the bottom layer. This is reflected in the behavior of the blockchain, which is "concurrently issuing blocks, concurrent voting, and concurrent confirmation".
And how can we judge that two transactions can be done at the same time? God G has already given the answer:
First, transactions should be isolated according to certain rules, such as name/address space. In the above example, "Shanghai Street" and "New York Starbucks" are the address spaces, and your transaction of buying skewers on the streets of Shanghai will not affect Starbucks in New York anyway. This is isolation. Two isolated transactions can not only be done at the same time, but can also be assigned to different shards.
Second, transactions must be able to be analyzed statically. The so-called static analysis means that before a transaction is submitted to the blockchain, it can analyze what resources it accesses, whether there is any conflict between the two transactions, and so on. Corresponding to the above example, before a transaction is submitted, you know at compile time that it will only access resources on the "streets of Shanghai" and will never go out of this range. Only in this way can we know which transactions can be handed over to the blockchain for consensus at the same time, without prioritizing.
In the correspondence table between my blockchain and traditional computer systems, the consensus layer of blockchain = the IO layer of traditional computers. With the capability of key point 1, it is equivalent to achieving concurrency at the IO layer, upgrading from Ethereum’s tape storage to RChain’s SSD.
Key point 2. Concurrent virtual machine based on Pi calculus
Since key point 1 is "concurrent consensus", and key point 2 is "concurrent execution". In order to be able to expand infinitely, the blockchain must have no single-thread bottleneck, and the underlying EVM, WASM and other state machine-based virtual machines are exactly this single-thread bottleneck. A verifier has received many contracts at the same time, and it must have the ability to execute them concurrently in order to truly realize "no queuing". Otherwise, it is equivalent to not queuing outside the door, but queuing when entering the door.
Going back to my topic of blockchain and traditional computer systems, with the ability of key point 2, it is equivalent to achieving concurrency at the computing layer. With the cooperation of 1&2, computing and IO have achieved concurrency, and blockchain computers can truly serve billions of people.
Key Point 3. Type Systems and Formal Verification
When both 1 and 2 are realized, and the blockchain can issue blocks and execute them, is everything going to be fine? G God and Vlad are very consistent on this: no, formal verification under concurrency is essential. Moreover, the most ideal way is to use type inference to do formal verification, rather than push it to the client. Moreover, the final choice is that the virtual machine should support "typed execution", which in the long run is much cheaper than "untyped execution". "Typed execution" is the equivalent of a firewall. Only when the contracts are executed and invoked under the protection of the firewall can the security be guaranteed, and countless contracts can be truly woven into a network of contracts, forming an unparalleled network effect. Otherwise, various race conditions and deadlock problems will force DApps developers and users to lie down again and again.
So, let's review, today in 2021, how much has RChain accomplished on the three key points of the appeal?
First of all, when RChain was launched on the mainnet, key point 2: concurrent virtual machine has already been realized; now, block merging is running on RChain’s test network, and key point 1: concurrent consensus is almost ready; finally, Greg’s OSLF The paper has made key theoretical preparations for key point 3. After waiting for the internal and external nodes to open in the past few months, it is time to set sail for Venus.
On the other hand, how much progress has Ethereum, which continues to take the state machine route, made?
Figure 3. ETH 2.0's multiple queuing methods that cannot be coordinated are by no means a solution
Layer 2 has made great progress, especially Roll up. However, because Layer 2 is just "going out and queuing", there is no interoperability between teams. ETH 2.0 is progressing slowly, but various sharding projects on the market have heralded the future of ETH 2.0, that is, "many queues are lined up inside the gate", and there is no interoperability between teams. No matter which one is incomplete, it can even be said to be a false expansion. Without the basis of computing theory, the five-year dream of capacity expansion turned out to be nothing more than a mirage. Even a hero like God V did not realize that the way to break the "impossible triangle" is exactly the three axes of "no need to line up" proposed by God G in the discussion in 2016.
Oh, it’s just that: the five-year dream of ether expansion, the broken wall was originally the person next to the pillow!
June 17, 2021 in New Jersey