The design philosophy of Ethereum 2.0

Original title: "Chain Hill Capital: <ETH2.0 Serenity--"Tranquility">"

Original source: Chain Hill Capital

Since the Ethereum development team released the launch conditions for ETH2.0 and announced the deposit address on November 4, various ETH deep participants have contributed their own 32 or more ETH to support its launch. Finally, on November 24, the launch requirement set by Vitalik Buterin of at least 16,384 32-eth validator deposits totaling no less than 524,000 ETH was exceeded. The ETH2.0 mainnet was launched on time at the early morning of December 1.

The first phase after the mainnet is launched is named “Serenity”, and the main chain is the Beacon chain, which is the beacon chain currently running (as shown in the figure below, it has reached 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?

Principles Serenity’s design philosophy

Simplicity

Based on the inherent complexity of proof of stake and Sharding technology in cryptoeconomics, Serenity strives for maximum simplicity in design in order 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 their users when designing the protocol. (Regarding the third point, when the complexity of some protocols is unavoidable, the priority should be: Layer2 protocol > client implementation > protocol specification)

Long-term stability

The construction of the underlying protocols must be perfect and predictable enough so that no changes will be required in the next 10 years or more, and any innovation can occur and be built on higher protocol layers based on these underlying layers.

Sufficiency

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

Defense in depth

The protocol works indifferently under a variety of possible security assumptions (e.g., network latency, failure counts, and nefarious motivations of users).

Full light-client verifiability

Under given assumptions (such as network latency, attacker budget constraints, 1/n or s/n number of honest nodes), 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 deep defense)

The Layer1 vs. Layer2 trade-offs

In any blockchain protocol, there is a debate about whether to put more features in Layer 1 or to keep Layer 1 as simple as possible and build more features on Layer 2.

Among them, the reasons for supporting Layer2 include:

Reduced the complexity of the consensus layer

Reduces the need to modify the consensus layer

Reduce the risk of consensus layer failure

Reduce the load and political risk of protocol governance

More flexibility and ability to implement new ideas over time

The reasons for supporting Layer1 are:

Reduce the risk of development stalling due to a lack of a mechanism to force everyone to upgrade to a new protocol (hard fork)

Potentially reduces overall system complexity

If the first layer is not strong enough, it is impossible to build complex and large mechanisms on the second layer protocol (just like you will never be able to build Ethereum on the Bitcoin network)

Most of the content of Ethereum 2.0 is a careful balance between Layer 1 and Layer 2. The efforts made on Layer 1 include the following three points:

1) Quasi-Turing complete, full-state code execution

2) Scalable and computable

3) High-speed block completion time

Specifically:

Without 1), you cannot use a complete trust model to build Layer 2 applications;

Without 2), scalability will be limited to certain state channels and certain technologies like Plasma, which often face the problems of capital lock-up and large-scale capital withdrawal;

Without 3), the requirement of timely transactions without state channels cannot be achieved, which will also lead to problems of capital lock-up and large-scale capital withdrawal;

In addition to the above features, ETH2.0 leaves 1) privacy, 2) high-level programming language, 3) scalable state storage, and 4) signature schemes to Layer2, because they are all areas of rapid innovation, and many existing schemes have different characteristics. In the future, it is inevitable to make trade-offs between more and better schemes. For example:

1) Privacy: Ring signature + confidential value VS Zk snark VS Zk starks; rollup VS ZEXE VS …

2) High-level programming languages: declarative vs. imperative, syntax, formal verification features, type systems, protection features, and native support for privacy features

3) Expanded state storage: accounts vs UTXOs, irreversible leasing schemes, raw Markle branch witnesses vs Snark/Stark compression vs RSA accumulation, spares Markle trees vs AVL trees vs usage-based imbalanced trees;

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

Why Casper Why choose Casper as the PoS solution

There are currently three mainstream POS consensus algorithms:

Nakamoto-inspired, like Peercoin, NXT, Ouroboros…

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

CBC Casper

There is a question in the latter two schemes, that is, whether and how to use security deposits and slashing (the first scheme is incompatible with slashing). All three schemes are better than proof of work, and we will introduce the ETH2.0 approach in detail.

Slashing

The Slashing mechanism used by Ethereum 2.0 means that when a validator is found to have misconduct, the tokens staked by the validator as a validator in the network will be confiscated. In the best case, about 1% of the validators will be punished, and in the worst case, all the ETH staked in the entire network will face punishment. The significance of this approach is:

1) Increase the cost of attack

2) Overcoming the problems of validators. The biggest motivation for validators to deviate from honest behavior is laziness (signing all transactions without verification). Large penalties for contradictory and incorrect signatures can largely solve this problem. Regarding this, there is a very typical case: in July 2019, a validator on Cosmos was fined for signing two conflicting blocks. The reason for this error of the validator was that it ran a master node and a backup node at the same time (to ensure that one of them being offline would not prevent them from getting rewards), and these two nodes were opened outside the same time, causing them to eventually contradict each other.

Choice of consensus algorithm

In the case of large-scale malicious verification nodes (1/3 in BPFT-inspired, 1/4 in CBC), only the BFT-inspired and CBC consensus algorithms can achieve good finality, and the Nakamoto-inspired consensus algorithm cannot achieve finality under this premise. Finality confirmation requires that most verification nodes are online, and this requirement must also be met in the Sharding mechanism, because sharding requires that 2/3 of random validators must sign when communicating across shards.

ETH2.0 chose Casper FFG because it can use the simplest algorithm to achieve finality in the final part of the protocol, but in the future it will gradually shift to CBC Casper in the third phase.

Sharding--Why ETH2.0 hates super nodes

For Layer1, the main method of sharding is to use super nodes - by requiring each consensus node to have a super-powerful server to ensure that they can handle each transaction individually. The expansion based on super nodes is very convenient because it is simple to implement: it just adds some more parallel software engineering work to the existing blockchain working method.

The main problems faced by this approach are as follows:

1) Risk of centralization of collateral pools: The fixed cost of running a node is high, so few users can participate. If the fixed cost of running a validating node accounts for a large part of the return, then larger pools can save less money than small pools, which will cause small pools to be squeezed out, thereby exacerbating the trend of centralization. In comparison, in a sharding system, larger nodes with more ETH collateral need to verify more transactions, so their fees are not fixed.

2) AWS centralization risk: Under the super node system, cottage industry-style mortgages are almost non-existent, and most mortgages will be in a cloud computing environment, which will greatly increase the risk of single point failures.

3) Scalability issues: As transaction throughput increases, the above risks increase, while in a sharded system the increased load can be handled more easily and reduce the above risks.

These centralized risks are also the reason why ETH2.0 did not choose to pursue ultra-low latency (<1s)< span="">, and they set this latency at a relatively conservative data.

In the ETH2.0 sharding system, no matter how much ETH and computing power you have, you can participate in the ETH verification system. Fixed costs are minimized, and even if you have a very large amount of ETH, the fees you face are still sublinear.

Security Model

ETH2.’s defense-in-depth approach with sharding is to combine random committee sampling to achieve validity and availability under an honest majority model, while providing proof of custody to protect against lazy actors, and 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 following table lists the currently expected security properties:

How is Casper’s reward mechanism designed?

In each Epoch, each validator will give his own proof, which means that the validator points out which is the block header and signs it. If this proof is packaged, the validator will receive the following rewards:

1) Proof of the rewards packaged in

2) Rewards for specifying the correct Epoch checkpoint

3) Rewards for specifying the correct chain head

4) Rewards for proving that the tokens were quickly packaged and uploaded to the chain

5) Rewards for specifying the correct shard block

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

B = basic reward, P = the proportion of validators who make correct judgments

Any validator who makes the correct judgment will receive a B*P reward.

The calculation formula for B is:

Among them, D1…Dn represents the size of the pledge, k is a constant,

Beacon chain/shard chain structure

The sharding system consists of 64 logical shards, which are centered around the beacon chain and coordinate all activities.

The process for a transaction to be finally confirmed in this system is as follows:

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

2) A randomly selected verification committee is assigned to this shard and performs verification and signing

3) The committee’s signature is packaged into the next beacon block

4) The next beacon chain is finalized through Casper FFG

Connecting each shard block to the next beacon chain via hash enables shards to quickly identify each other’s Markle roots, thus enabling them to mutually verify receipts:

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

Tail---About the future of ETH2.0

"Tranquility" is just the first step in the vast journey of ETH2.0, but from the choices they made in the first step, we can see that the entire team has been thinking deeply about fairness and efficiency over the past three years. They did not blindly pursue the so-called million TPS, but instead carried out greater practice on practicality and feasibility while ensuring safety.

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