- Come on! Ethereum 2.0 beacon chain test network officially launched
- Beacon Chain Contract: A New Way to Deploy Dapps on Ethereum 2.0
- Ethereum 2.0 audit report announced next week, giving green light to multi-client testnet
- Ethereum 2.0 terminology reveals why a beacon chain is needed
- Technical Guide | Ethereum 2.0 Phase 0 V0.8.0 Technical Specifications (1)
- Perspectives | Ethereum 2020: Roadmap and Outlook
This is a remote attack when an attacker easily builds a chain longer than the current specification chain from scratch and causes other participants in the network to recognize the state of the new chain.
This is almost impossible to happen on PoW chains such as Bitcoin or Ethereum, as this requires a lot of computing power. However, since the PoS mechanism does not rely on computing power, it can cause a network crash in the event of such an attack (Zamfir 2014) .
Vitalik Buterin and Vlad Zamfir agree that there is no other viable solution to defend against remote attacks (Buterin 2018), except that the client is strictly prevented from synchronizing a chain that exceeds a checkpoint .
This approach means that new nodes in the network only need to start synchronizing from the latest "checkpoint" that is recognized as "finalized" by other nodes in the network, rather than starting from the initiating block. That is, when a new node joins the network, the new node has an inherent trust in the old node. This phenomenon is known as the weak subjectivity of PoS. When a new node joins the network, there is a subjective trust for blocks that have been "finalized" and not tampered with among all participants in the network .
During that time, Vitalik Buterin and the Ethereum Foundation's Virgil Griffith were working on the original version of the Casper Proof of Stake white paper on the ArXiV (https://arxiv.org/abs/1710.09437) website. For a long time between 2014 and 2017, Ethereum tried to cover a PoS based finality system on the Ethereine backbone that currently runs the PoW mechanism. At the same time, Ethereum developers are also working on state sharding as a way to extend the Ethereum network.
By 2018, both plans had been significantly promoted, and after an iconic research meeting in Taipei in March 2018, the Ethereum research team proposed to merge Casper Proof of Stake and Sharding into one For the development of the Ethereum Serenity (also known as Ethereum 2.0) .
Why launch Ethereum 2.0?
Of course, a comprehensive change to the current Ethereum PoW chain consensus agreement and data integrity is not easily achieved with just one hard fork – a new system is re-started and the current Ethereum 1.0 chain is completely Abandon, isn't it easier?
One of the challenges we encountered when building Ethereum 2.0 was the need to involve the Ethereum community in this challenge and to give community members a clear understanding of the tremendous benefits and needs behind the transition to Ethereum 2.0. After learning about the huge responsibilities that accompany this paradigm shift, it is now a great time to build Ethereum 2.0.
Regardless of whether we are willing to admit, the current blockchain and cryptocurrency are still in the embarrassing phase, and the decisions we make today will drive the accelerated growth and adoption of blockchains and cryptocurrencies in the years to come. We have been waiting for a long enough time to move to the PoS mechanism, as is the Ethereum application. The best time to build Ethereum 2.0 is now available, and the relevant teams are ready.
The key question is: How do we get scalability without sacrificing decentralization and security? Many of Ethereum's competitive blockchain platforms (such as EOS) have chosen a centralized approach to address this issue. Ethereum chose a different way, dividing the state of the network into 1024 parallel-running fragment chains, each of which is unified by a root called a beacon chain. Chain coordination .
The beacon chain runs a full Casper PoS mechanism, and there is no proxy or centralized voting rights like EOS in the whole system. In this way, each node only needs to be responsible for processing a portion of all transactions in the entire network, and many blocks can process transactions in parallel, which linearly increases the throughput of the entire network .
The Ethereum 2.0 specification attempts to answer the following questions:
If there is no global verification of the transaction, what impact will the security of the network have? How should the selected participants be selected to prevent the emergence of a verification monopoly? How should incentives be designed to maximize data availability and enthusiasm for participation?
After years of research, exploration, and understanding of the trade-offs that need to be made, Ethereum explored the choice of PoS as its consensus algorithm. For the reasons discussed in the text, the verifier is guaranteed to be rewarded, while the verification entity (individual or business) is treated equally in the Casper PoS agreement and is equal in participating in the Certifier Board and receiving rewards/penalties. Probability .
The global verification of the transaction turns into indirect verification: each transaction in each segment chain will be first verified by the certifier in the segment, and the certifier of the segment will submit the checkpoints In the beacon chain, the beacon chain plays the role of “coordinator” in each fragment chain in Ethereum 2.0 .
Invariant of Ethereum 2.0 design
For Ethereum and its developer community, there is an unchangeable design decision that is critical to the future of Ethereum 2.0. We can divide the core of Ethereum 2.0 into the following points:
- Participation in the network should be without permission (permissionless);
- The scope of Layer 1 should be concise and compact;
- The agreement should be expressive to the greatest extent possible, regardless of its future use;
- The network should be lively and effectively recover from any catastrophic scenario;
- The complexity of the protocol should be distinguished from the complexity of application development.
01. No permission is required
The significant difference between Ethereum 2.0 and other “next generation” blockchain platforms is how to participate in consensus.
The only requirement in the Ethereum 2.0 to be called a certifier is to hold 32 ETHs. In the Ethereum 2.0 system, there is no proxy, there is no vote to select the verification node, and there is no centralization mechanism that determines who can participate in the verification. More importantly, the hard requirement for each entity to participate is to pledge 32 ETH, which makes the verifiers in Ethereum 2.0 equally treated.
However, any individual may have a certifier identity (that is, a user holding a large number of ETHs pledges across multiple clients and has multiple certifier identities). This is just a decision to simplify the security and simplicity of a consensus agreement. From the perspective of incentive design, it is important to treat all participants equally when voting for blocks, which is also important for formal modeling. 1 verifier = pledge 32 ETH, no more and no less.
Other blockchain platforms often address scalability issues by taking a more central approach to transaction verification; but for Ethereum, this is not an option to consider.
02. Keep it simple, but with the greatest degree of expressiveness
Ethereum 2.0 strives for simplicity and compactness in its core definitions and goals. At the basic level, Ethereum 2.0 is an extensible, license-free platform for building decentralized applications.
03. Guaranteed safety
Ethereum 2.0's PoS model — Casper the Friendly Finality Gadget — operates under a range of incentives designed to maintain a high level of vitality and network engagement. Ethereum 2.0 is extended by Casper and leverages its features to protect the security of the entire slice chain network. That is to say, Ethereum 2.0 guarantees the sharing security of 1024 segmentation chains and beacon chains in the system by using the concept of chain finality threshold.
The premise of PoS is that the verifier can be rewarded after performing the assigned verification work as expected, or because of a small loss of partial deposit due to offline status, or if the verifier is maliciously violating the agreement, it is severely punished (quality deposit) Was fined.)
Although this premise is very succinct, the relevant details are the key to success. Casper's economics quickly became more complex once we realized that we must consider not only the behavior of each verifier but also the behavior of all the verifier committees.
An open question for the PoS chain is usually: when should the malicious act be punished, and how the verifier should be punished accordingly according to the severity of the action (the severity should be different and the penalty should be different). In other words, we need to find a comprehensive punishment that covers all extremes and keeps it simple .
Since the protocol relies on the certifier's activities, the operation of the protocol also depends on a persistent time scale, and there may be cases where an honest certifier cannot participate in the verification. An honest verifier may be offline due to a power outage, network failure, or other reason, but we need to explicitly distinguish between offline penalties and malicious behavior penalties .
Another limitation of the PoS-based system is the verifier's dilemma, that is, the verifier in the system is too lazy (offline), and blindly believe that other verifiers in the protocol will perform block verification in the correct way, so These lazy verifiers are negligent. These verifiers save bandwidth or general computing needs by not performing their verification duties unless they face significant penalties. In this case, this problem can be alleviated by adding very serious penalties and challenge mechanisms for missing or erroneous signature information in the network.
Evidence Incentives for Ethereum 2.0
01. Certifier offline: Quadratic Leak
Ethereum 2.0 relies on the Byzantine fault tolerance threshold, which means that 2/3 of the verifiers in the network are honest verifiers .
The penalty for certifiers who do not participate in the verification is called "invita leaks". If a slice chain is not finalized during more than 4 epochs, the reward for the verifier will be as strict as possible, ie the maximum expected reward will be 0, so the verifier needs to perform the verification correctly. Otherwise, there will be more punishment. The degree of punishment will be proportional to the time since the last chain was finalized (ie, the longer the last time from the last time, the greater the penalty), to organize the verifier offline.
[Note: In the Ethereum 2.0 phase, each time 64 blocks are generated (approximately 6.4 minutes, called an epoch), the beacon chain will re-scramble the certifiers and redistribute them into all the shards. ]
The longer the certifier goes offline, the exponential growth . This punishment is called “ quadratic leak ”. This punishment mechanism is designed to be: short-term offline status will not be punished, but offline for a long time will have a great negative impact on the verifier, which can be very Goodly take into account the expected reality. The funds lost by such punishment will be destroyed, not distributed to other honest verifiers.
02. Intentional malicious behavior: slashing
In the early proposal for the Ethereum PoS, malicious verifiers would be subject to a huge penalty called slashing, which usually only discussed penalties for individual malicious verifiers, without discussing the verifier collusion The seriousness. The network will only be affected if a large percentage of the verifiers work together to maliciously operate the network.
According to Byzantine fault tolerance, the penalty for malicious actors will be three times the number of verifiers who also conduct malicious acts within a certain time interval. This helps to punish a large number of coordinated attacks and also prevents malicious verifiers from coming together. That is to say, for the verifier, it is very disadvantageous to jointly attack the network.
Slashing is achieved through an exposing mechanism , in which the verifier can obtain rewards by discovering other certifiers' punishable aggression behavior, and as compensation can obtain funds that other verifiers are punishable.
03. Verifier reward
According to Vitalik Buterin's Ethereum Serenity design principles (https://notes.ethereum.org/s/rkhCgQteN), he outlines each verifier within each epoch time period (each block is called an epoch) ) 4 clear components of the basic rewards obtained:
- 1/4 of the rewards obtained by proof to determine the correct epoch checkpoint;
- 1/4 of the rewards obtained by proof to determine the correct chain head;
- 1/4 of the rewards obtained by demonstrating that the block can be quickly entered into the chain;
- 1/4 of the rewards obtained by proving to determine the correct fragmentation block;
In addition, there are additional bonuses above this basic reward based on the number of validators participating in the verification. This additional reward is used to motivate the verifier to operate correctly and together to drive honesty in the network. The timetable for awards should be consistent and straightforward. Adding more complexity will make the whole system more error-prone and more difficult to understand from a macroeconomic perspective.
Distinguish the complexity of the protocol from the complexity of the application
There has been a lot of discussion about how shards will effectively increase the developer experience. The basic rationale is that it is very difficult to disregard the needs of application developers in the design of the Ethereum 2.0 protocol, because the highly complex systems of the slice chain require that the slices need to interact with each other (cross-chip communication).
At first glance, this view makes sense, because Ethereum 2.0 is very daunting from the outside, and there is still a lot of uncertainty in the implementation of smart contracts in Ethereum 2.0. But in fact, the facts are subtle.
Therefore, phase 0 (beacon chain phase) is completely removed from the application layer. Recent Phases 1 and 2 also present some very powerful proposals that suggest a higher degree of abstraction of the execution environment, which makes Ethereum 2.0 more powerful and simpler.
In the worst case, the wallet/app developer needs to know some details about the cross-slice transaction in order to show real-time transaction settlement with some tips. Today's computer operating systems and internal structures are much more complex than they were 10 years ago, but most application developers don't need to understand the hidden internal constructs that make the computer architecture powerful. Separating the two is the core of good architectural design, and we can also think of it as a design invariant that needs to be remembered when building Ethereum 2.0.
Build a real world computer
Today's Ethereum is similar to the early weak processors. Currently running applications on Ethereum is expensive because the protocol has built-in mechanisms to stop the tragedy of the commons that plague many public utilities.
Ethereum's vibrant developer community has never stopped innovating on the current network, whether it's its core layer (Layer 1) or Layer 2. From a governance perspective, the upgrade of Ethereum's future plans will not be flat and without setbacks. If the future Ethereum 2.0 goes online for a few years, we feel that we have received constraints and hope to build Ethereum 3.0, which also means our failure in the core design of the former.
Upgradeability should be incorporated into the protocol in a way that does not require a risky hard fork. That is to say, once the system is in operation for a long time, the innovation at the Layer 1 level should be kept to a minimum or even zero state.
We still have a long way to go, but we are cautiously reminding ourselves why we should build this software, and where we want Ethereum to go in the next 10 years, we can also write a more versatile way to withstand the test of time. Great code.
Author | Raul Jordan
Compile | Jhonny