In-depth Analysis of Ethereum 2.0: The First Step of the Vast Journey - Serenity Phase

This article was published on December 4, 2020, by Mars Finance, and the author is Steven, a partner at Qianfeng Capital.

Since the Ethereum development team announced the launch conditions for ETH2.0 and released the deposit address on October 4, various deep ETH participants have come forward with their 32 or more ETH to support its launch. Finally, on October 24, they exceeded the requirement set by Vitalik Buterin of at least 16,384 deposits of 32 ETH, totaling no less than 524,288 ETH, and the ETH2.0 mainnet went live on December 1 at midnight.

The first phase of the mainnet launch is named "Serenity," and the operating main chain is the Beacon chain, which is the currently running beacon chain (as shown in the figure below, it has now progressed to the 357th Epoch). So, what are the design philosophies and innovations of this PoS chain, and are they sufficient to support ETH's transition to PoS?

1.0 Principles of Serenity's Design Philosophy

Simplicity

Given the inherent complexity of proof of stake and sharding technology in cryptoeconomics, Serenity strives for maximum simplicity in its design to: 1) minimize development costs; 2) reduce the risk of unforeseen security issues; 3) make it easier for future developers to explain the details and legitimacy of the protocol to its users. (Regarding the third point, when the complexity of certain protocols is unavoidable, the priority should be: Layer 2 protocols > client implementations > protocol specifications)

Long-term Stability

The underlying protocol must be sufficiently perfect and predictable, so that no changes are needed for the next 10 years or longer. Any innovations can occur and be built upon these foundations at a higher protocol layer.

Sufficiency

Serenity will fundamentally ensure that as many applications as possible can be built on top of its protocol.

Defense in Depth

The protocol can operate indiscriminately under various possible security assumptions (e.g., network latency, fault counting, and malicious user motivations).

Full Light-Client Verifiability

Under given assumptions (such as network latency, limited attacker budgets, and a minority of honest nodes like 1/n or s/n), a validating client should be able to obtain all valid data of the entire system, even under a 51% attack. (In fact, this is also a subset of defense in depth.)

2.0 The Layer 1 VS Layer 2 Trade-off

In any blockchain protocol, there exists a debate over whether to include more features in Layer 1 or to keep Layer 1 as simple as possible and build more features in Layer 2.

Reasons supporting Layer 2 include:

a. Reduces the complexity of the consensus layer

b. Reduces the need to modify the consensus layer

c. Reduces the risk of consensus layer failure

d. Reduces the governance load and political risks of the protocol

e. Will be more flexible and capable of implementing new ideas over time

The reasons supporting Layer 1 are:

a. Reduces the risk of development stagnation caused by a lack of mechanisms forcing everyone to upgrade to a new protocol (hard fork)

b. May reduce the overall complexity of the system

c. If the first layer is not strong enough, it is impossible to build complex mechanisms on the second layer protocol (just like you can never build Ethereum on the Bitcoin network)

Most of Ethereum 2.0's content is carefully balanced between Layer 1 and Layer 2, and the efforts made on Layer 1 include the following three points:

1) Turing-complete, full state code execution

2) Scalable and computable

3) High-speed block completion time

Specifically:

Without 1), it is impossible to use a complete and trustworthy model to build Layer 2 applications;

Without 2), scalability performance will be limited to certain state channels and some technologies like Plasma, which often face issues of fund locking and large-scale fund exits;

Without 3), it is impossible to meet the requirement for timely transactions without state channels, which also leads to issues of fund locking and large-scale fund exits;

In addition to the above features, ETH2.0 leaves 1) privacy, 2) advanced programming languages, 3) scalable state storage, and 4) signature schemes to Layer 2, as they are all areas of rapid innovation, and many existing solutions have different characteristics, inevitably requiring trade-offs between more and better solutions in the future. For example:

1) Privacy: Ring signatures + confidential values VS Zk snark VS Zk starks; rollup VS ZEXE VS …

2) Advanced Programming Languages: Declarative vs imperative, syntax, formal verification features, type systems, protective features, and native support for privacy functions

3) Scalable State Storage: Accounts VS UTXOs, non-borrowing schemes, raw Merkle branch witnesses VS Snark/Stark compression VS RSA accumulators, sparse Merkle trees VS AVL trees VS usage-based imbalanced trees;

4) Signature Schemes: M/N multi-signature, revocation and recovery of social keys, Schnorr signatures, BLS signatures, Lamport signatures

3.0 Why Casper? Why Choose Casper as the PoS Solution

Currently, there are three mainstream PoS consensus algorithms:

a. Nakamoto-inspired, such as Peercoin, NXT, Ouroboros…

b. PBFT-inspired, such as Tendermint, Casper FFG, Hotstuff

c. CBC Casper

In the latter two schemes, there is a question of whether and how to use security deposits and slashing (the first scheme is incompatible with slashing). All three schemes are superior to proof of work, and we will specifically introduce ETH2.0's approach.

Slashing

The slashing mechanism used by Ethereum 2.0 means that when a validator is found to be acting improperly, their staked tokens acting as validation nodes in the network will be forfeited. In the best case, about 1% of validators will be punished; in the worst case, all staked ETH in the network will face penalties. The significance of this approach is:

1) Increases the cost of attacks

2) Overcomes issues with validators, making the maximum motivation for validators to deviate from honest behavior laziness (signing all transactions without validation). Large penalties for contradictory and incorrect signatures can largely address this issue. A typical case regarding this is: in July 2019, a validator on Cosmos was penalized for signing two conflicting blocks, and the reason for this mistake was that it was running both a main node and a backup node (to ensure that one being offline wouldn't prevent them from earning rewards), and these two nodes were opened outside of the same time, leading to their eventual contradiction.

Choice of Consensus Algorithm

In the event of large-scale malicious behavior by validation nodes (1/3 in PBFT-inspired, 1/4 in CBC), only BFT-inspired and CBC schools' consensus algorithms can achieve good finality; Nakamoto-inspired consensus algorithms cannot achieve finality under such conditions. Confirmation of finality requires a majority of validation nodes to be online, which is also a requirement in the sharding mechanism, as sharding requires 2/3 of random validators to sign during cross-shard communication.

ETH2.0 chooses Casper FFG because it can achieve finality in the protocol's final part using the simplest algorithm, but will gradually shift to CBC Casper in the future.

4.0 Sharding -- Why ETH2.0 Dislikes Supernodes

For Layer 1, the main method of sharding is to use supernodes—requiring each consensus node to have powerful servers to ensure they can handle everything independently. Scaling based on supernodes is convenient because it is simple to implement: it just adds some more parallel operational software engineering work on top of the existing blockchain's way of working.

However, this approach faces the following main issues:

1) Centralization Risk of Staking Pools: The fixed costs of running nodes are very high, so the number of users who can participate is very limited. If the fixed costs of running validation nodes take up most of the returns, larger pools can save smaller fees compared to smaller pools, which will continuously squeeze out smaller pools, exacerbating centralization trends. In contrast, in a sharding system, larger nodes that stake more ETH need to validate more transactions, so their costs are not fixed.

2) AWS Centralization Risk: Under the supernode system, home-based staking forms are almost non-existent, and most staking will occur in cloud computing environments, significantly increasing the risk of single points of failure.

3) Scalability Issues: As transaction throughput increases, the above risks also increase, while the increased load in a sharding system can be handled more easily, reducing the above risks.

These centralization risks are also the reason why ETH2.0 has not chosen to pursue extremely low latency (<1s) excessively; they have set this latency at a relatively conservative figure.

In ETH2.0's sharding system, regardless of how much ETH and computing power you have, you can participate in the ETH validation system. Fixed costs are minimized, and even if you have a very large amount of ETH, the costs you face are still sub-linear.

5.0 Security Model

ETH2.0's defense in depth and sharding approach combines random committee sampling to achieve effectiveness and availability under the honest majority model, while providing custody proofs to prevent lazy actors, and offering fraud proofs and data availability proofs to detect invalid or unavailable chains without downloading and verifying all data; this will allow clients to reject invalid or unavailable chains.

The table below shows the currently expected security attributes:

6.0 How is the Reward Mechanism of Casper Designed?

In each round Epoch, each validator provides their proof, which refers to the validator indicating which is the block header and signing for it. If this proof is packaged, the validator will receive the following rewards:

1) Reward for being included in the proof

2) Reward for specifying the correct Epoch checkpoint

3) Reward for specifying the correct chain head

4) Reward for the proof being quickly packaged on-chain

5) Reward for specifying the correct shard block

In different scenarios, the specific reward calculation method is as follows:

B = base reward, P = proportion of validators making correct judgments

Any validator making a correct judgment will receive a reward of B * P,

The calculation formula for B is:

Where D1…Dn represents the amount of staked ETH, k is a constant.

7.0 Structure of Beacon Chain/Shard Chain

The sharding system consists of 64 logical shards, with the system centered around the beacon chain, coordinating all activities.

The process for a transaction to receive final confirmation in this system is as follows:

1) The transaction is included in a shard block of a group of shards

2) A randomly selected validation committee is assigned to this shard to validate and sign

3) The committee's signatures are packaged into the next beacon block

4) The next beacon chain confirms finality through Casper FFG

Each shard block is connected to the next beacon chain through hashes, allowing shards to quickly identify each other's Merkle roots, enabling mutual verification of receipts:

As shown in the figure above, if shard n is not immediately packaged into n+1 beacon chain, the committee of n+2 beacon chain can attempt to package this shard and the next shard.

8.0 Conclusion -- About the Future of ETH2.0

"Serenity" is just the first step in the vast journey of ETH2.0, but from the trade-offs made in this first step, it is evident that the entire team has deeply considered fairness and efficiency over the past three years, not merely pursuing the so-called million TPS, but rather conducting greater practical experiments on usability and feasibility while ensuring security.

I believe that for a long time to come, ETH will be the cornerstone of the entire blockchain network. This year's DeFi is just a great social practice under immature network conditions. As 2.0 becomes more refined in 2021-2022, it will inevitably unleash greater commercial and social value.