Partnered With:

The Design Philosophy of Ethereum 2.0

Read this article in 25 Minutes

Take a look at everything behind the "quiet" Ethereum 2.0.

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

Original source: Chain Hill Capital Qianfeng Capital

Since the Ethereum development team released the activation conditions of ETH2.0 and announced the deposit address on November 4th, Various ETH in-depth participants sacrificed their own 32 or more ETH to support its launch, and finally overfulfilled at least 16,384 32-eth validator deposits set by V God on November 24th. According to the launch requirement of 524,000 ETH, the ETH2.0 main network was launched on time in the early hours of December 1st.

After the mainnet goes online, the first stage is named "Serenity", and the running mainchain 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 enough to support the transition from ETH to PoS?

Principles Serenity's design philosophy

Simplicity

Based on the inherent complexity of Proof-of-Stake and Sharding technology in cryptoeconomics, Serenity is designed to be as simple as possible in order to: 1) Minimize development costs; 2) Reduce The risk of unforeseen security issues; 3) Make it easier for subsequent developers to explain the details and legality of the protocol to its users when designing the protocol. (As for the third point, when the complexity of some protocols is unavoidable, the order of priority should be obeyed: Layer2 Protocol > Client Implementation > Protocol Specification)

Long-term stability

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

Sufficiency

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

Defense in depth

A protocol can work indiscriminately under every possible security assumption. (For example, network latency, failure counts, and nefarious motives of users.

Full light- client verifiability Full light-node Verifiable

In a given assumption (such as network delay, attacker's budget constraints, 1/n or s/n a small number of honest nodes), a verification client, even under 51 attacks, should be able to obtain all valid data of the entire system. (In fact, this is also a subset of defense in depth)

The Layer1 VS Layer2 trade-off between Layer 1 protocol and Layer 2 protocol

In any blockchain protocol, there is a need to put more features in Layer1, or to design Layer1 as simple as possible while doing more on Layer2 The debate on feature construction.

Among them, the reasons for supporting Layer2 include:

Reduces the complexity of the consensus layer

Reduces the need to modify the consensus layer

Reduce risk of consensus layer failure

Reduce protocol governance load and political risk

More flexibility and implementation of new ideas over time Ability

The reason for supporting Layer1 is:

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

Possibly reducing overall system complexity Sex

If the first layer is not strong enough, it is impossible to build such a complex and huge mechanism on the second layer protocol (just like you will never have a way to build Ethereum on the Bitcoin network)

Most of the content of Ethereum 2.0 is a careful trade-off between Layer1 and Layer2, and it is done on Layer1 The efforts made include the following three points:

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

2) Scalable and computable

3) High speed Block completion time

Specifically:

If there is no 1), it is impossible to use a complete trusted model to build Layer2 applications program;

If there is no 2), the expansion performance will be limited In some state channels and some technologies like Plasma, these technologies often face the problem of fund locking and large-scale fund withdrawal;

If there is no 3), the requirement of timely transactions without state channels cannot be realized, and this will generally result in capital lock-up and large-scale capital

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

1) Privacy: Ring Signature + Secret Value VS Zk snark VS Zk starks; rollup VS ZEXE VS …

2) Advanced Programming Languages: Declarative vs. Imperative, Syntax, Formal Verification Features, Type Systems, Protection Features, and Native Support for Privacy

3) Extended state storage: account VS UTXOs, impossible lease scheme, raw Markle branch witness VS Snark/Stark compression VS RSA accumulation, spares Markle trees VS AVL trees VS Based on imbalanced trees used;

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

Why Casper Why choose Casper for PoS solution

There are currently three mainstream POS consensus algorithms:

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

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

CBC Casper

There is a problem in the latter two schemes, that is, whether and how to use Security deposits and Slashing (Security deposits and Slashing) (the first scheme and Slashing are Incompatible). 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 the verifier is found to have misbehavior, the tokens pledged to act as verification nodes in the network will be confiscated. In the best case, about 1% Validators will be punished, and in the worst case, all ETH pledged by the entire network will face punishment. The significance of this approach is:

1) Increase the cost of attack

2) To overcome the problems of verifiers, the biggest motivation for verifiers to deviate from honest behavior is laziness (sign all transactions without verification) , large penalties for contradictory and incorrect signatures can largely solve this problem. Regarding this point, there is a very typical case: in July 2019, a verifier on cosmos was fined for signing two conflicting blocks, and the reason for this verifier's mistake is Simply because it runs a master node and a backup node at the same time (to make sure one of them goes offline doesn't prevent them from getting rewarded), and both nodes are turned on outside of the same time, causing them to end up contradicting each other.

The choice of consensus algorithm

When large-scale verification nodes do evil (1/3inBPFT-inspired, 1/4in CBC), only BFT-inspired and CBC school consensus algorithms can have better finality, Nakamoto- The inspired consensus algorithm cannot achieve finality under this premise. The final confirmation requires that most of the verification nodes are online. This requirement also needs to be met in the Sharding sharding mechanism, because sharding requires 2/3 of the random verifiers to sign when communicating across shards.

ETH2.0 chooses Casper FFG because it can use the simplest The algorithm achieves finality in the final part of the protocol, but will gradually turn to CBC Casper in the third stage in the future.

Sharding sharding--why ETH2.0 hates super nodes

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

For this approach, the main problems are as follows:

1) Risk of centralization of mortgage pools: the fixed cost of running a node is very high High, so few users can participate. If the fixed costs of running a validator account for the majority of the rewards, then larger pools will save smaller fees than smaller pools, which will keep smaller pools being squeezed out, exacerbating the centralization trend. In comparison, in a sharding system, larger nodes with more ETH staked need to verify more transactions, so their fees are not fixed.

2) AWS centralization risk: under the super node system , The form of home workshop mortgage is almost non-existent, and most of the mortgage will be in the cloud computing environment, which will greatly increase the risk of single point of failure.

3) Scalability issues: With transaction throughput With the increase of , the above-mentioned risks increase, and the increased load in the sharding system can be handled more easily to reduce the above-mentioned risks.

These centralized distributions are also ETH2.0 and there is no choice to pursue them The reason for ultra-low latency (<1s)< span="">, they set this latency at a relatively conservative data.

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

Security Model

ETH2. The defense-in-depth and sharding approach is to combine random committee sampling , to achieve validity and availability under the honest majority model, while providing proof of custody to prevent lazy actors, and proof of fraud and proof of data availability to detect invalidity or unavailability without downloading and verifying all data chains; this will allow clients to reject invalid or unavailable chains.

The following table is the current expected security attributes:

How is Casper's reward mechanism designed?

In each round of Epoch, each validator will give his own proof, which refers to The validator points out which is the block header and signs it. If this proof is packaged, the verifier will receive the following rewards:

1) Proof of being packaged rewards

2) Rewards for specifying the correct Epoch checkpoint

3) The reward for specifying the correct chain head

4) The reward for proving that it was packaged on the chain quickly

5) Specify the reward for the correct shard block

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

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

Any verifier who makes a correct judgment will be rewarded with B*P,

B is calculated as:

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

Beacon chain/shard chain structure

The sharding system includes 64 logical shards "shards". The system centers on the beacon chain to coordinate all activities.

The final confirmation process of a transaction in this system is as follows:

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

2) Random The selected verification committee is assigned to this shard for verification and signature

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

4) The next beacon chain will be finalized through Casper FFG

Connect each shard block to the next beacon chain through hash, so that shards can quickly identify each other’s Markle root, so that they can mutually verify receipts:

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

At the end---about the future of ETH2.0

"Serenity" is just ETH2.0 The first step of the vast journey, but from the trade-offs they made in the first step, it can be seen that the whole team has thought deeply about fairness and efficiency in the past three years, and did not blindly pursue the so-called million TPS, but to ensure safety A greater practice of practicality and feasibility under the premise of

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