V God's latest speech: What exactly is Ethereum 2.0?
Editor's Note: This article comes fromCarbon chain valueEditor's Note: This article comes from
Carbon chain value
(ID: cc-value), Author: Vitalik, Compiler: Elisa, Min Min, A Jian, released with authorization.
This article is a translation of Vitalik's speech at Devcon4. The original English text is dictated from the recording, and there may be some uncertainties in the translation, please forgive me.
Congratulations on the 10th anniversary of the Nakamoto Consensus!
The topic of my speech today is Ethereum 2.0, but I hope to present not only the technical points of Ethereum 2.0, but also why we need to promote the upgrade of Ethereum, what upgrades we will make, and what attempts we have made to get to today.
So, what is Ethereum 2.0?
Over the past few years, we have tirelessly discussed and researched some features of the system, and have also invested a lot of energy in App development. Finally, they come together to form a harmonious world. These features include the proof-of-stake algorithm, Casper; scalability, sharding; virtual machine upgrades, EWASM; enhancements on cross-chain contracts; improved protocol economic models, and many improvements that contribute to the decentralization of the logical layer. There are so many important topics.
PoS
secondary title
Research on Proof of Stake (PoS) began in 2014. This blog post I published in January (Slasher: Punitive Proof-of-Stake Algorithm) explained an algorithm called Slasher, which introduced the most basic concept in the proof-of-stake algorithm: if you violate the agreement and are found , (which can be proven), you will be punished; this method can be used to improve security. But at the time, as you can see in the slides, I believe Slasher is a very useful construct to round out the arsenal of proof-of-stake "mining" and give us a more robust Reasons to switch to Proof of Stake. Of course we haven't done that yet.
scalability
Therefore, at that time, it was still unclear whether PoS should be our direction. But over time, it became a lot clearer.
scalability
In 2014, first, we explored a series of interesting and important concepts, such as "Proof of proof of work", which is a proposal to improve scalability; "Hub and spoke chains model (Hub and spoke chains)", Let one chain be the center, and a series of chains be affiliated. This is actually a very early scalability and sharding proposal. It tries to improve the scalability of transactions in the region, but it cannot improve the global transactions (that is, from a chain to another chain); "Hypercubes", where cubes have 12 dimensions instead of 3, so we can achieve greater scalability than the hub-and-spoke model.
Now, those concepts are being abandoned for a number of reasons; however, someone actually did a huge ICO to develop them, so glad someone is willing to try (audience laughs).
So have we made the right progress in 2014?
Progress in 2014
some. We got a concept called "Weak Subjectivity (Weak Subjectivity)", to some extent, this is a semi-formal security model, trying to explore the confiscation conditions of PoS deposit, and under what conditions PoS is safe. At the same time, we are becoming more and more certain that PoS algorithms with stronger security properties exist, so Peercoin and its variants are really possible. We also gradually realized that there are some scalability strategies that can be combined with the proof-of-stake algorithm through random sampling, but we don't know how to do it.
At that time we determined a roadmap, and Vinay Gupta wrote a great blog post in March 2015, listing the 4 main stages of the Ethereum roadmap at that time. Phase 1: Frontier, which is where we started the project; Phase 2: Homestead, from alpha to beta; Phase 3, Metropolis (literally translated as "metropolis"), when the expectation was Mist interacts with the user interface and enhances the user experience. But since then, our attention has shifted to implementing stronger cryptography support, and interface improvements have become a parallel goal. The fourth stage: Serenity, realizing the proof of rights and interests. From now on, I am willing to call it Ethereum 2.0, and of course I will not refuse to use Shasper to refer to it. To avoid confusion, we can also call it "Serenity".
2015-16: The lows
Then, we hit a low point: we had a series of failures to solve some core problems in PoS, scalability, and Vlad quietly suspended all his work in Casper CBC.
One of the most interesting concepts we got was "Consensus by Bet": Participants bet on which block will be finalized next time, and once someone bets, the fact that they bet itself becomes the basis for others to bet. Consideration factors for people to place bets. In this way, in a sense, we have produced a recursive formula. As time goes by, more and more people place bets, and it will become more and more obvious which block will be finalized; after the logarithmic round , everyone will invest all their rights and interests, so that we have achieved de-qualification. We went pretty far along that line of thinking, creating a full proof of concept for it, and you can see (on the slides) the determinization process, and signature functions and all that. I mean, we spent most of our time here, but then the whole idea stalled, mainly because we realized which BFT-inspired consensus algorithm could actually work safely.
storage rental
Rent's idea is this: Instead of charging a one-time high fee for storage space usage, we can charge it incrementally. Therefore, once a certain storage space is full, you need to pay a certain amount of ETH for it on a daily, per block or other basis. It is written here as EIP 103, but it should actually be EIP 35, because 35 is the issue number. This is a preliminary idea, an attempt to form a formal concept. Since then, we've iterated a lot on how we can best utilize the rent.
Scalability paper from 2015
The goal of this paper is to form the concept of quadratic sharding and super quadratic sharding, but it is really too complicated. It will involve some very complex escalation games. The whole idea is inspired by the role of escalation in the legal system (I know Joseph's philosophy is very fond of using this analogy), but I'm trying to take it down to the base layer. It also contains "deep state reversal", that is, if something really goes wrong, a large amount of state can be deeply rolled back in the future. It's really complicated.
In fact, one of the fundamental problems that we cannot fully grasp, but are gradually approaching, is the so-called "Fisherman's Dilemma". This is a very fundamental concept in sharding research, describing the big difference between scaling execution of state, scaling execution of programs, and scaling availability of data. The basic problem is this: If you want to run the program, you can have people commit to what the answer is, and then you can use a challenge game, use binary search to determine at which step who is wrong (Translator's Note: that is, only Run half of the calculation steps and compare the results to find out which step the two parties made a mistake), and after confirming the facts, you can punish those who gave wrong answers. And the problem with data availability is: no matter how the challenge game works, you can cheat, because you can not disclose any data at all until the mechanism checks whether you have disclosed data, and then you only need to disclose the part of the data that the mechanism checks. up.
All in all, The DAO incident and the DoS attack finally delayed the events and energy of many people, even for as long as 6 months. However, we are still moving forward, EWASM is advancing, research on virtual machines is advancing, and we have also made an alternative version EVM1.5. And everyone also has a more in-depth understanding of the shape of a better blockchain algorithm from multiple perspectives.
forge ahead
secondary title
Casper FFG
forge ahead
Then we made a series of major advances very quickly. During this time, we have learned in many different research areas: some around proof of stake, hoping to make our consensus layer more efficient; some around scalability, hoping to make our base layer consensus shardable ; some are trying to improve the efficiency of virtual machines; some are around account abstraction, which allows users to choose which signature scheme to use, which can obtain the security of the post-quantum era and make privacy solutions Simpler; and one that revolves around a protocol layer economic model. Of course all of this is still growing.
The basic concept is as follows: New blocks will be continuously generated on a blockchain, and you can obtain a pipelined version of efficiency through continuous merging and observation: at the beginning of each round, you will add data for this round, and In the next round, people can confirm some of these data; we can get a huge efficiency improvement from it The parent block of the block is finalized).
Fragmentation
At the beginning, there were 6 minimum penalty conditions, and then I reduced it to 4, and a year later, we stopped merging prepare and commit. This is Casper Friendly Finality Gadget (FFG, friendly deterministic gadget).
Casper CBC
Fragmentation
Casper FFG POC
At Devcon last year, I demonstrated this new sharding design, which is to keep the main chain unchanged, and then create a shard as a Layer-2 system in a certain sense and mount it on the existing main chain, confirming that it is enough After it is reliable, it will be upgraded to Layer-1.
Then there's the Casper CBC ~ paper from Vlad.
Shasper
At 23:40 on December 31, 2017, Thailand time, we happened to be in Thailand at that time, and the Casper FFG proof of concept was born. At that time, we really wanted to determine what the technical details of a PoW/PoS hybrid consensus would look like, and this hybrid consensus would use some concepts from Casper FFG, and some traditional Byzantine fault-tolerant consensus. Inspired concept, and loaded on the existing proof-of-work chain. This would be a mechanism that would allow us to move quickly to hybrid consensus with minimal disruption to existing blockchains, and then we would theoretically be able to upgrade to full proof-of-stake.
We have also gone a long way on this road, we also made a Python test client, using different VPS, server and computer communication for testing.
At the same time, we have made a lot of progress on sharding. We continued to improve the technical details of sharding, and finally we organized a group break in Taipei in March 2018. A lot of ideas started to emerge here, and how to implement a sharded blockchain seemed to become clear. Yes, it looks clearer.
Then we realized, why is there a team developing PoS here, and another PoS project over there? Why do we have to do repetitive work? Then we decided to combine the work of both sides. This decision is a death sentence for many previous works, but the significance is profound: we will work together, develop the same technical specification, the same protocol, and we can make Casper PoS and sharding complement each other at the same time.
other
All in all, rather than having one purpose here and another purpose there, and then trying to figure out how to combine the two, we might as well spend a little more time at the starting point and move towards a set of proof-of-stake and sharded blockchains. (applause)
other
At the same time, we spent a lot of time discussing the fork selection rules, and finally we are getting closer and deeper to understand the fork selection rules; although the GHOST algorithm was originally designed for workload proof, because of a For a series of reasons, we re-propose for proof of stake.
We also developed more ideas on how to implement abstractions and rents. For a few reasons, we decided to rename Storage Rent to Storage Maintenance Fee.
In terms of research, we are studying cross-shard transactions, such as csoss-shard-yanking, we are generalizing some concepts in traditional distributed systems and using them in an asynchronous cross-shard environment; there are also papers on resource pricing, including Optimizing the fee market, how to charge storage maintenance fees, and the trade-offs between different designs. Casey also wrote this post discussing cross-shard transactions under the synchronicity assumption. Of course, CBC research has also been extended to the field of sharding. By the way, this is really not called Valding. Vlad hates this word very much. There is also development. The strategy we use in the development of Ethereum 2.0 is to pursue creative multi-client decentralized development. This is not only because we have the pursuit of decentralization, but also a very practical strategy, which is to bet that other teams will not be as good as you; in addition, the Shanghai incident made us realize that if a certain client fails If there is a problem and other clients do not, the entire network can run better; by the way, it also makes the development of the entire ecosystem less dependent on the foundation itself. The client that the foundation actually develops is the Python client, and Python has inherent limitations in performance, which gives people an incentive to run the client created by Prysmatic, Lighthouse, Status and Pegasus and others that have sprung up Client developed by the team.
secondary title
The upcoming Serenity
So coming down, I gotta say, the upcoming one, can't be called Shasper. Serenity is about to set sail!
What is Serenity?
First of all, Serenity is the fourth stage after Frontier, Homestead and Metropolis. Of course Metropolis is divided into two phases, Byzantium and Constantinople, and the Constantinople upgrade is about to start.
Second, it's a culmination of four years of research that we've been doing in all these different areas, including Casper (not just hybrid consensus, but 100% pure Casper), sharding, EWASM, and all these concepts of protocol research.
Then, this is a new kind of blockchain. This is true in terms of data structure, but it will maintain a certain connection with the current proof-of-work blockchain. Then, for example, the PoS chain can perceive the block hash value of the PoW chain, and you can transfer Ether from the PoW chain to the PoS chain. This is a new system and an interconnected system. The long-term goal is: when the new system is stable enough, all existing blockchain applications can be stored on a certain shard in the new system. contract, and then there is an EVM interpreter written in EWASM. This hasn't been finalized yet, but at this point, it's pretty much our roadmap.
Again, Serenity will become a world computer, not like a smartphone in 1999, which can only process 15 transactions per second, barely able to play Snake.
In the end, Serenity will still be decentralized, and we also hope that in some dimensions, it can be more decentralized than existing blockchains. For example, as a validator of the beacon chain, your storage requirements (currently) may be less than 1GB, compared to the 8GB you need today to store state, or store Ethereum as the rumors on the Internet say The blockchain needs 1.8TB, which will be much better.
expected stage
Phase 0: Proof-of-Stake Beacon Chain. From a certain point of view, the PoS beacon chain is a blockchain warehouse that stores all information, but it is silent itself. There will be some validators on the beacon chain, and these validators will run the PoS algorithm; it's like something in between the testnet and the mainnet, it's definitely not a testchain, because you can stake real Ether goes in and gets real Ether rewards, but it’s not the main chain either, because there’s no application on it, so if it crashes, people won’t cry like they did during the Shanghai DoS attack.
Phase 1: Shard chain as a data chain. This is the role that shards will have. This is a simplified version, which means that we do not shard the state, but shard the data; you can put the data on the chain and try to run your own state execution engine. In fact, the easiest thing to shard is data. So if you want to do decentralized applications on the blockchain, now you have scalability, but you don't have the state enforcement capability to develop smart contract applications and all those very complicated things. (Translator's Note: This sentence should be suspicious. In the 23rd minute of the video attached to the original link.)
Phase 2: Support state transition of EWASM. This includes: support for virtual machines, support for accounts, contracts, Ether transfers between shards, and more.
Phase 3 and beyond: Continuous iteration, adding new technologies.
desired characteristics
Pure PoS consensus.
Faster sync confirmation time (8-16 seconds). Note that because of the fork selection rules and signature mechanism of the beacon chain, a confirmation on the beacon chain includes message passing between hundreds of verifiers. From a probabilistic point of view, it is actually equivalent to the existing Ethereum Hundreds of confirmations on a proof-of-work blockchain. Under the assumption of synchronous delivery of messages, it can already be regarded as finalizing a block.
Faster virtual machine execution via EWASM.
Ideally, 1000 times scalability is achieved.
secondary title
Post-Serenity Innovation
Strengthen privacy protection. We've done a lot of work. For example, in the Byzantine phase, we activated the precompilation of elliptic curve operations and elliptic curve matching. Barry White did a great job using Layer-2 to protect privacy in token transfers, voting, and reputation systems. These jobs can all be borrowed.
Cross-shard transactions.
Semi-private chain. The idea is that if you want to develop some applications and keep the data private among some users, you can still put all the data on the public chain, but you put it in encrypted form, or upload hash Hive value and zero-knowledge proof can be decided by yourself.
Innovation in Proof of Stake. This is something we are always concerned about. When Casper CBC is economical enough, it will be added to our roadmap.
A stronger form of cross-shard transactions.
Faster single confirmation. Reduce confirmation time from 8 seconds to lower.
secondary title
mid-term goals
Finally stabilized the function of Layer-1
There is growing consensus on the guarantees and properties that people want the protocol layer to provide
consider governance issues
secondary title
upcoming updateWhat other updates will we make before the final release?
First, finalize the specification of the protocol layer.Those of you who have been following ethereum and the 2.0 main specs, beacon chain specs, etc. on GitHub should know that the protocol layers are evolving very quickly, but we will be stabilizing them soon.
Continue to do development and testing.Eight implementations of the Ethereum 2.0 protocol are currently under development.
Cross-client testnet.
Some people expressed their great desire to see the cross-client testnet running in January next year. Of course, I am also very happy to see that we have seen hope in August this year. Here is a brief review of the development process of Ethereum 1.0. From the concept proposed in the white paper to the official release, there was an interval of 19 months. Part of the reason why it took such a long time is that we tried to build cross-client compatibility before the technical specification was finalized. We agreed to test and release Testnet, wait for protocol changes, agree to launch new testnet, then wait for more protocol changes, back and forth 5 times. We have learned a lesson in this matter, we don't need to fully focus on cross-client compatibility, and we can wait until we are really close to finalizing the technical specification. I don't think we're too far away from publishing a candidate for a technical note, at least in the parts that don't include state enforcement.
Finally, there is a security audit. Who in the audience think security audit is important? (Voice from the audience) Which audience think that security audit is not important? (Silence) Who thinks the world is run by Lizardmen? (Laughter from the audience) Well, the people in the third part laughed for a second, which is awesome.
