Exploring Ethereum 2.0: Evolution of Blockchain Incentive System

This paper introduces the evolution of the blockchain incentive system.

A number of articles have recently discussed the roadmap, research recommendations and current status of Ethereum 2.0. But there is nothing publicly disclosed about the design ideas and invariants behind 2.0. Defining invariants is very helpful in coordinating work, and it also ensures that developers are consistent in philosophical logic. This article will explain some of the design, background, and impact on future protocols in 2.0.

History development

• The DeFi Déjà Vu: A long text analysis of the current DeFi dilemma
• Babbitt column | Yang Haipo: Bitcoin forks past events
• When I bought Bitcoin for $18,000, the female billionaire regretted investing and called Bitcoin to deceive herself.

After the birth of Ethereum, technicians are trying to convert PoW to PoS. Vitalik Buterin was exploring a viable solution to prevent PoS vulnerabilities and greater security than PoW. He and the Ethereum research team designed a slasher mechanism to punish PoS as a wicked to cut their deposits.

Later, mathematician Vlad Zamfir joined the slasher project and spent most of 2014 focusing on solving PoS long-range attacks. When attacking remotely, an attacker can create a complete chain longer than the current specification chain from scratch, which causes the remaining nodes of the network to trust the new canonical state. This is almost impossible in PoW, because launching an attack requires a lot of computing power, and PoS does not rely on computing power, so launching a remote attack will cause the blockchain to collapse.

Vitalik and Vlad agree that for remote attacks, the client can only be strictly prohibited from synchronizing chains that exceed a checkpoint. Therefore, the new node does not need to synchronize from the creation block, and only needs to synchronize from the nearest "checkpoint" that other nodes in the network agree on, that is, when the new node joins the network, the old node can be trusted. This phenomenon was later called the subjective weakening of PoS. When new nodes are added, they subjectively trust the "final" and "irreversible" blocks.

While studying Slasher, Vitalik and the Ethereum Foundation Virgil Giffith were busy writing the initial version of ArXiV's Casper Proof of Stake white paper. From 2014 to 2017, Ethereum has been trying to change from PoW to PoS. At the same time, Ethereum is also striving to achieve fragmentation technology and expand the blockchain. Time came to March 2018. After a major Taipei seminar, the Ethereum research team proposed to merge Casper Proof of Stake and sharding technology into Ethereum Slasher, Ethereum 2.0.

Why is it merged into 2.0?

This article aims to explain the design philosophy behind the central issue: “Why use Ethereum 2.0?” It is not easy to check the consensus agreement and data integrity of existing systems through hard forks. Abandon Ethereum 1.0 to build from scratch. Isn't a new system simpler? The biggest challenge we face is the need for community involvement in Building 2.0, and the clear transition to Ethereum 2.0 has huge benefits and needs.

Although the conversion paradigm has a huge responsibility, this is the best opportunity. Whether you like it or not, encryption is still in its infancy, and today's decision will have a profound impact on the adoption of encryption technology in the next few years. PoS switching and Ethereum application expansion are well prepared and the team is well prepared.

challenge

Pure Layer 1 expansion may sacrifice security to a large extent, and fragmented blockchains prevent global transaction verification (such as Bitcoin and Ethereum are in use). The key question is: how to expand without sacrificing decentralization or security? Many competitors use a centralized approach. Ethereum chose a different approach to divide the network state into 1024 fragments, which appear as a set of homogeneous blockchains, each of which is coordinated by a root chain called a beacon chain. The beacon chain runs the Casper Proof of Stake agreement, which has no fiduciary or centralized voting rights. Each node is only responsible for packaging some of the transactions in the network, and can generate multiple blocks in parallel, so that the overall network throughput increases linearly. The immature specification for this solution answers the following questions:

If there is no global verification transaction, how will the security files in the network change? How to prevent monopoly situations when screening verification nodes? How to design an incentive system to maximize data usage and increase participation?

After years of research, exploration and coordination, Ethereum will choose the PoS consensus algorithm. The global transaction is verified indirectly, and each fragment transaction is first checked by the fragmentation verifier and then submitted to the checkpoint on the beacon chain. The latter serves as a "coordinator" for coordinating fragmentation information.

Invariant design

The key point of the protocol design is to understand which invariants the protocol will run under. For Ethereum and its developer community, having a list of design decisions that are not negotiable is critical.

We can break down the core of Eth2 into the following points:

·Network participation without permission

· The scope of the first layer should be simple, abstract and compact

· Maximize the agreement, not assuming its future use—that is, in line with the Ethereum motto "We have no future"

· The network should be active in order to recover efficiently from disaster situations.

• Separate protocol complexity from application development complexity.

No license required

A significant difference between Eth2 and other "new generation" blockchains is how to determine consensus engagement. The only requirement for Eth2 is to hold 32 ETH to become a verifier. There are no trustees, no voting screening verification nodes, and no central law to decide who can participate. More importantly, Eth2 treats all certifiers equally – hardtop 32 ETH. However, any individual can have multiple instances of the validator. Simplified security and consensus protocols. From the perspective of incentive design and formal modeling, it is important to stipulate that all participants have the same stake when voting for a block. One verification = 32ETH as a stake, and other blockchains are all expanded by a centralized solution, but will never be used for Ethereum.

Concise, but can maximize expression

Eth2's goal is to make the core definition simple and compact. At a basic level, Ethereum is a scalable, license-free platform for creating decentralized applications.

No need to introduce application logic, the Ethereum analogy to a Linux kernel – it does not depend on the operating system's features and application scenarios, but depends on the developer who builds the application in the kernel.

Safety

Eth2's PoS model, called Casper the Friendly Finality Gadget, runs under a series of incentives that ensure a high degree of activity and network involvement. Eth2 extends Casper to protect fragmented blockchain network security. That is, the concept of chain termination thresholds ensures that the 1024 shards of Eth2 share the same security pool as the beacon chain.

The core premise of PoS is that the verifier completes the task specified by the expected character to receive the reward, if it is lazy, it loses the reward, and if it violates the agreement, it will be severely slashed. Although the premise is brief, the key points are reflected in the details. The Casper economy becomes more complicated if we consider the various verifier behaviors and the entire certifier's committee behavior.

In general, an open question in the PoS chain is when to punish and how to punish according to the severity of the behavior? That is to say, we have to find a comprehensive punishment to cover all extreme cases at the same time. Given that the operation of the protocol depends on the certifier's behavior and the strong runtime, there may be situations where an honest certifier cannot perform. For example, power outages, network instability, etc., lead to honest verifiers offline, so we must clearly distinguish between lazy punishment and evil behavior punishment.

Part of Eth2's design philosophy is to make the attack damage agreement a huge price. Just like the 51% attack on other chains requires a high price. The attacker reverses the final part of the agreement and will obviously expose it to everyone. The community can coordinate the soft forks, remove the perpetrators, and invalidate the attacks. Of course, if the attack is successful and the coordination fails, if the single purpose of the attacker is to break the system and cause huge losses, the integrity of the system will be destroyed.

Another major limitation of the PoS system is the verifier's dilemma, which is named after the phenomenon. The certifier in the system is lazy and simply believes that the other people in the agreement have done the work seriously and therefore do not verify what they are responsible for. Unless severely penalized, the verifier can perform its duties without saving bandwidth and computing power. This behavior can be reduced by adding significant penalties and challenge mechanisms to lost data or error signatures in the network.

The certifiers of Ethereum 2.0 are motivated as follows:

The verifier is not active: secondary leakage

ETH2 relies on the Byzantine fault tolerance threshold of 2/3 honest participants in the network. Penalties for inactivity are also called inactive leaks. If the chain does not confirm the finality for more than 4 periods, the agreement will strictly control the verifier. In other words, if the final confirmation from the chain has been a long time, the maximum reward will drop to zero. At this point the verifier needs to perform well, otherwise face punishment. The penalty is proportional to the time since the end of the chain, preventing the verifier from going offline. The longer the verifier is lazy, the heavier the punishment. This "second leak" punishment does not have much impact on short-term laziness, but it is heavier for long-term lazy, the fine will be destroyed and will not be redistributed to honest verifiers.

Deliberately doing evil behavior: slashing

The original Ethereum PoS proposal wrote that the verifier of the evil would be severely punished, that is, the slashing penalty, usually against a single verifier, rather than a conspiracy verifier. If most of the verifiers work together, it will destroy the network. According to the guarantee of Byzantine fault tolerance, the punishment for the perpetrators = 3 × the number of evildoers in the same period of time. This helps to punish large-scale cooperative behavior and can also inhibit the development of the pool of vicious verifiers. In other words, launching a joint attack in the network will damage the collective interests of the perpetrators. Advocate the prosecution mechanism, encourage the verifier to discover other illegal attacks, and use the slashed funds as a reward.

Certifier reward

According to Vitalik's Ethereum slasher design principles, he outlines four specific components of the Certifier's basic rewards in each period (64 blocks):

1. Check the specified epoch checkpoint and reward 1/4

2. Prove the specified blockchain, reward 1/4

3. Proof is quickly packaged into the chain, reward 1/4

4. Prove that the correct segmentation block is specified, reward 1/4

There are additional rewards for this basic reward based on the number of valid participants. This extra bonus is used to motivate the verifier to do the right thing and promote collective honesty. The reward release plan should be consistent and intuitive, adding more complexity will only make the system error-prone and more difficult to understand from a macroeconomic perspective.

Separating protocol complexity from application complexity

It is a conservative statement to say that the Eth2 road map is daunting. It may be the most ambitious, and long-term plan to absorb industry lessons and elegantly create a sustainable agreement to solve the expansion problem. There has been a lot of discussion about sharding to reduce the developer experience. The reason for this is that it is extremely difficult to strip Eth2 developers inside. We have a complex sharding system that needs to interact with each other. On the surface, Eth2 is daunting, and it is not clear how to execute the contract clearly in the project. But the facts are very subtle.

Application developers only need to understand a small portion of the Eth2 protocol. Ordinary smart contract developers do not need to know the internal structure of the verifier registry or beacon chain terminal gadget. Therefore, phase 0 is completely removed from the application layer. Phases 1 and 2 have also recently come up with powerful proposals that advocate a higher level of abstract execution environment, making Eth2 more powerful and concise. In the worst case, wallets and app developers need to understand the details of cross-slicing transactions to get some tips for showing real-time transaction settlement. Computer operating systems and internal components have been much more complicated than they were 10 years ago, however, most application developers don't need to understand hidden internals that make them a powerful computer architecture. This separation of concerns is at the heart of good architectural design, and one can say that we should keep in mind the invariant design when building Eth2.

Building a real-world computer

In short, Ethereum is relatively beautiful, which means it can run any type of imaginable code, just like today's computers, even though it is a very limited, slow, single-threaded computer. Today's Ethereum is similar to the early weak processors. Running applications in Ethereum today is also expensive because the protocol has built-in mechanisms to prevent tragedies in public scenes that plague public goods. Ethereum's dynamic developers will always improve the current network, both at the core and at the second. But at the governance level, scheduled upgrades can be difficult and the process is difficult. Once Eth2 is activated a few years later, we can feel that it has certain restrictions, and hope to establish Eth3, then it means that the core design of Eth2 has failed. The protocol should be upgraded in a way that does not require a hard fork, ie, once the system is put into use, Layer 1 is designed to be the least innovative or close to zero. We still have a long journey to go, always reminding ourselves why we built this software, and whether it still exists after 10 years? This way we will write more powerful code that will stand the test of time.

Author | Sadie Williamson

Translation|First Class Warehouse Annie

Compile|First Class Alonso Chen

The copyright of the article belongs to the original author, the translation is provided by the first class warehouse, please keep the preface information for any reprint.

Original: https://www.tokendaily.co/blog/design-principles-of-ethereum-2-0

Source (translation): https://first.vip/shareNews?id=1751&uid=1

We will continue to update Blocking; if you have any questions or suggestions, please contact us!