To understand Ethereum 2.0, first understand the core design principles of Ethereum 2.0
The Ethereum Technology Application Conference was held in Beijing today. V God, core members of the Ethereum Foundation, Ethereum DAPP developers and other heavyweight guests gathered. The conference focused on Ethereum 2.0.
The public is also generally concerned about the progress of Ethereum 2.0. V God delivered a speech titled "Ethereum 2.0 Cross-shard Transactions" at the conference.
There are already many articles discussing the roadmap of Ethereum 2.0, research proposals and its development status. However, there are not many articles about the design principles and invariants behind the internal operation of Ethereum 2.0. This article aims to discuss the design principles behind Ethereum 2.0 .
About the author: Raul Jordan, Raul Jordan is the co-founder of Prysmatic Labs and also a partner of zk Capital. He graduated from Harvard and is a blockchain engineer and Ethereum developer. He focuses on the development of Prysmatic Labs sharding technology.
Many articles discuss the roadmap, research proposals, and current status of Ethereum 2.0. However, not much has been written publicly about the design principles and invariants behind its inner workings. Having a clear set of invariants is critical to the success of this coordinated multi-year effort, and it makes implementers think about the Ethereum philosophy.
secondary title
1. History
Since the birth of the Ethereum network, trying to convert Ethereum from PoW to PoS is a major progress. Vitalik Buterin was exploring a viable solution at the time to guard against the flaws of immature PoS and provide greater security than PoW.
In particular, he and the Ethereum research group devised a mechanism called a slasher to punish malicious actors in PoS and slash their entire collateral (Buterin 2014).
Mathematician Vlad Zamfir later joined the project, and much of 2014 focused on solving so-called remote attacks on PoS.
Remote attacks occur when an attacker can create a full chain from scratch that is longer than the current canonical blockchain in order to convince others in the network of the new canonical state.
This is almost impossible to perform in PoW as it requires a lot of compound computing power. However, PoS does not depend on computational power and thus collapses under such attacks (Zamfir 2014).
Both Vitalik and Vlad agree: there is no viable remote attack solution other than "strictly preventing clients from synchronizing chains older than a certain checkpoint" (Buterin 2015).
This means that instead of syncing the chain from the genesis block, new nodes in the network only need to sync up with other finalized nodes in the network from the most recent "checkpoint".
That is, when new nodes join the network, there is an inherent trust in old nodes. This phenomenon was later referred to as the weak subjectivity of PoS.When new nodes join, there is subjective trust among participants in the network that "finalized", "irreversible" blocks exist (Buterin 2018).
During this time, Vitalik and Virgil Griffith from the Ethereum Foundation worked on publishing an initial version of the Casper PoS whitepaper on ArXiV (Buterin and Griffith 2015).
However,
However,secondary title
2. Why choose ETH 2.0?
This article explains the design rationale behind the core question: "Why use Ethereum 2.0?".
Of course, a thorough check of the consensus protocol and data integrity of the existing system cannot be easily accomplished through a hard fork——Wouldn't it be easier to simply create a new system from scratch and ditch Ethereum 1.0 entirely?
One of the challenges we faced when building ETH 2.0 was the need to educate the community about this challenge and clearly understand the great interest and need behind the transition to ETH 2.0.
There has never been a better time to build on ETH 2.0 while understanding the enormous responsibility that comes with this paradigm shift. Like it or not, the crypto industry is still in its infancy and the decisions we make today will have the compounding effect of accelerating growth and adoption over the years.
secondary title
3. Challenge the future
Inexperienced Layer 1 scaling can come at a huge security cost: sharding the blockchain prevents global transaction verification, as the current Bitcoin and Ethereum chains do.
The key question is: how do you achieve scalability without sacrificing decentralization or security? Many competing chains aim to seek the centralized route as a means to solve this problem.
Ethereum chooses a different approach:Divide the network state into 1024 shards that represent a homogenous set of blockchains, each coordinated by a single root chain called a beacon chain. The beacon chain runs on full Casper PoS with no delegation and no centralized voting rights.
In this method,Each node is responsible for only a fraction of the transactions happening across the network, and many blocks can happen in parallel, linearly increasing overall network throughput.
This solution aims to answer the following questions:
How would the security profile of the network change if transactions were not globally validated? How to select validating participants while preventing cartel formation? How can incentives be designed to maximize data availability and encourage active participation?
After years of research, exploration, and understanding of the trade-offs, Ethereum sought PoS as its consensus algorithm. As mentioned earlier, rewards are deterministic,Validating entities have the same treatment in the protocol, the same probability of participating in the committee, and the same reward/punishment.
Global transaction verification becomes indirect verification. Every transaction in each shard chain will first be verified by a validator in that shard, and,secondary title
4. Design invariants
A key pillar of protocol design is understanding under which invariants the protocol will operate.For Ethereum and its developer community, having a list of non-negotiable design decisions is critical to the future of the project.
We can break down the core of ETH 2.0 into the following points:
1. Participation in the network should be permissionless;
2. Layer 1 should be concise, abstract and compact within its scope;
3. The protocol should be as expressive as possible, rather than assuming its future use;
4. The network should tend to be resilient to recover efficiently from any catastrophic scenario;
5. Separate protocol complexity from application development complexity.
1. No permission required
A notable difference between Ethereum 2.0 and other "next generation" blockchains is how participation in consensus is determined. The only requirement of Ethereum 2.0 for validators is to have 32 ETH.
There are no proxies, no voting to select validators, and no centralized constitution to determine who participates. More importantly, validators in Ethereum 2.0 are all treated equally: the hard requirement for each entity to participate is 32 ETH.
However, any individual can have multiple validator identities. This was simply a decision made to simplify the security and compactness of the consensus protocol. From an incentive design perspective, and for formal modeling purposes, it is important to treat all participants equally when validating blocks by voting.
1 validator = 32 ETH staked, no more than that. Other chains aim to address scalability issues by adopting a more centralized approach to verification. However, for Ethereum, this option is not considered.
2. Concise, but most expressive
Ethereum 2.0 strives for simplicity and compactness in its core definition and realization goals. Fundamentally, it is a scalable, permissionless platform for building decentralized applications.
There is no need to introduce application logic in Ethereum 2.0, and for good reason. One can compare the Ethereum 2.0 system to a stripped-down Linux kernel - it's not the operating system that decides what features or hypothetical use cases it includes, but the developers who build applications for the kernel.
The practice of "assuming intent" is limited. The old Ethereum adage that "we don't have any features" applies to Ethereum 2.0 as well.
3. Ensure safety
The PoS model of Ethereum 2.0, also known as Casper the Friendly Finality Gadget, operates under a series of incentives designed to maintain high activity and network participation.
Ethereum 2.0 extends Casper to leverage its properties to secure sharded blockchain networks. That is, Ethereum 2.0 uses the concept of "chain finality threshold" to ensure that 1024 shards in the system share the same security pool as the beacon chain.
The core premise of PoS is that validators are rewarded for doing specified work as expected, lose their stake for being offline, or face severe penalties (forfeited stake) for maliciously violating the protocol.
While the premise is simple, it’s the details that make the difference. The economics of Casper quickly become more complicated once we realize that we have to consider not only the behavior of each validator, but the entire committee of validators.
An open question for PoS chains in general is when behavior should be punished, and how to do so differently depending on the severity of certain validator actions. That is to say,We need to find a penalty that is comprehensive enough to cover all edge cases while remaining concise.
Given that the protocol relies on validator activity and relies on persistent observations of runtime, there may be situations where honest validators cannot participate. Honest validators may go offline due to power outages, network instability, or other factors, but weA clear distinction needs to be made between offline penalties and penalties for malicious conduct.
Part of the design rationale for Ethereum 2.0 is that attackers pay a huge price for any attempt to break the protocol. In other words, the 51% attack that often occurs in other chains should be costly on Ethereum 2.0, and the result may even be counterproductive.
That is, in a protocol with explicit finality, "reversing finality will" make the attacker obvious to honest validators, which allows the community to coordinate a soft fork to remove malicious actors and render their attacks ineffective.
Of course, even if the attack is successful and this community coordination is unsuccessful, the integrity of the system is diminished if the attacker's sole purpose is to disrupt the system and cause great damage.
Another limitation of PoS-based systems is the validator's dilemma, that is, the validators in the system are lazy and simply trust that others in the protocol are doing their work correctly, and therefore do not verify that they should be responsible for validating news.
secondary title
5. Validator Incentives of Ethereum 2.0
The validator incentives for Ethereum 2.0 are as follows:
1. The verifier is offline: Quadratic Leak
Ethereum 2.0 relies on Byzantine fault tolerance thresholds,It must be guaranteed that two-thirds of the verifiers in the network are honest participants.Penalties for validators who do not participate in validating are called "inactivity leaks".
If a chain has not been finalized for more than 4 epochs, the protocol will be as strict as possible on validator rewards. That is, the maximum expected reward becomes 0, so validators need to behave perfectly or face more penalties.
The size of the penalty is proportional to the time since the last time the chain achieved finality to prevent validators from going offline.
This penalty grows exponentially the longer certain validators are offline, and this is known as a “Quadratic Leak”.The reason this penalty is involved is hopefully not to penalize being offline for short periods of time, but given expected real-world behavior, being offline for longer periods of time has a significant downside.
Funds lost to this penalty are destroyed and not redistributed to honest validators.
2. Intentional malicious activities: confiscation
In the early proposals for Ethereum PoS, malicious validators would be punished on a large scale, called slashing, and usually these mechanisms only discuss the punishment of individual malicious validators, and do not discuss the seriousness of validator collusion . If a majority of validators cooperate to maliciously attack the network, the network will be affected.
According to Byzantine Fault Tolerance, the penalty for malicious actors will be 3 times the number of validators acting maliciously within a certain time interval. This helps punish large coordinated attacks, and also prevents malicious validator pools from spawning.
That is, performing an aggregation attack on the network is beneficial to malicious verifiers and disadvantageous to ordinary verifiers.The slashing is carried out through the reporting mechanism, incentivizing verifiers to discover other verifiers' illegal behaviors that can be slashed.
3. Validator rewards
Based on Vitalik's Ethereum Serenity Design Principles, he outlines 4 specific components of a validator's base reward per epoch:
1. 1/4 of the rewards obtained by proving to determine the correct epoch checkpoint;
2. 1/4 of the rewards obtained through proof to determine the correct chain head;
3. 1/4 of the reward obtained by proving that the block can be quickly entered into the chain;
4. 1/4 of the rewards obtained through proof to determine the correct shard block;
secondary title
6. Separate program complexity from protocol complexity
The statement "Ethereum 2.0 roadmap is daunting" is not accurate, because Ethereum 2.0 may be one of the most ambitious and multi-year plans, it can take the best lessons from the industry and create an elegant way. A protocol that solves the scalability trilemma and that will be able to run indefinitely.
There has been a lot of discussion about how sharding can significantly degrade the developer experience. The rationale is that it is very difficult to separate the needs of application developers within the Ethereum 2.0 protocol internal node, because the highly complex sharding system needs to interact with each other (cross-shard transactions).
At first glance, Ethereum 2.0 looks intimidating from the outside, and it is still not clear how smart contracts will be executed in Ethereum 2.0. However, the truth is more nuanced.
Application developers only need to know a small part of the Ethereum 2.0 protocol. The average smart contract developer does not need to understand the internals of validator registries or beacon chain terminal gadgets.
Therefore, phase 0 is completely removed from the application layer. Recently, phase 1 and phase 2 have also put forward very strong proposals, advocating a higher degree of abstraction of the execution environment to make Ethereum 2.0 more powerful and concise.
Worst case, wallet/app developers need to know certain details of cross-shard transactions to show instant transaction settlement through some tricks. Today's computer operating systems and internal devices are far more complex than they were 10 years ago, yet most application developers don't need to understand the hidden internal structures that make up a powerful computer.
secondary title
7. Building a Real World Computer
All in all, Ethereum is Turing-complete, which means it can run any type of code imaginable like today's computers, despite being a slow, single-threaded computer.
Today's Ethereum is similar to the weak processors of the early days. Running applications on Ethereum today is expensive because the protocol has mechanisms in place to prevent the tragedy of the commons that plagues public utilities.
Ethereum's vibrant developer community has never stopped innovating to improve the current network, whether it is at the core layer or at layer 2. However, future planned upgrades can be problematic and painful from a governance perspective.
If a few years after Ethereum 2.0 goes live, we feel constrained and want to build an Ethereum 3.0, it means we have failed at the core design of the former.
Upgradability should be baked into the protocol in a way that does not require risky hard forks. That is, layer 1 innovation should be minimal or close to zero once the system has been in operation for a long time.
We've got a long way to go, but we're careful to remind ourselves why we're building this software, and where we want to see it go in 10 years, to write something more robust and stand the test of time code.
-END-
Disclaimer: This article is the author's independent opinion, and does not represent the position of the Blockchain Institute (public account), nor does it constitute any investment opinion or suggestion.
Disclaimer: This article is the author's independent opinion, and does not represent the position of the Blockchain Institute (public account), nor does it constitute any investment opinion or suggestion.
Source: https://www.tokendaily.co/blog/design-principles-of-ethereum-2-0
