Dry goods | Deterministic gadgets: used in Taifang 2.0 for 1.0 additional certainty

Editor's Note: The original title of this article is The Finality Gadget. The literal translation is “deterministic gadget”. The name comes from a Casper algorithm codenamed Friendly Finality Gadget (ie Casper FFG). In the beginning, Casper FFG was intended to be a component that provides final determinism and can be deployed on any PoW chain (hence the name "Friendly").

The main content of this article is to introduce a two-way coupling scheme for the Ethereum 1.0 and 2.0 links, so that the beacon chain provides finality for the 1.0 chain. Readers familiar with FFG can see the deep shadow of FFG.

– Continuous leaping determination of PoW blocks through PoS consensus –

• A16z crypto partner: the charm and challenge of blockchain
• Babbitt Column | How to create a new stable currency that competes with Libra
• Babbitt Column | Discussion on Blockchain Technology as a Model of "Business Secrets" Protection

As the launch time of Ethereum 2.0 gets closer, you may be curious about the fate of the current Ethereum blockchain. Under the concept of "Ethereum 1.x", a large number of proposals have been proposed to achieve the expansion of existing networks in the short term. These efforts are aimed at ensuring the continued smooth operation of the current blockchain, thereby contributing to the sustainability of current ecosystem development.

This article describes a program called "finality gadgets." It leverages the consensus of Ethereum 2.0 in Phase 0 (Phase 0) to enhance the security of the existing Ethereum 1.0 chain. Through this program, Ethereum 2.0 can bring certain benefits to the Ethereum community from the first day of its deployment . Let's take a closer look at the concept of "deterministic gadgets" and then discuss how it works, what benefits it will bring to the community, and what the specific deployment process looks like. Finally, we will think about some of the most prominent risks and open issues.

Introduction

The idea behind “Deterministic Gadgets” takes advantage of the attributes of Casper, the final proof of the equity-based consensus agreement that will be deployed on Ethereum 2.0. The Phase 0 plan of Ethereum 2.0 is to deploy the beacon chain, the core backbone of the Ethereum system after the fragmentation. A verifier participating in the beacon chain consensus can provide final determinism for the generated data after satisfying certain conditions of the Casper algorithm . It is called final certainty because once a certain block is determined, it will always exist on the legal chain; it is proved that in order to change the data on the chain, the ETH total pledge must be burned. More than 1/3. Assuming that 10 million ETHs are pledged in the system, a successful attack would result in approximately 3.3 million ETHs being fined. At the time of this writing, the cost has exceeded $600 million. If you want to know more details, check out another article I wrote about finalism, which is linked as follows: https://medium.com/@ralexstokes/how-secure-is-ethereum-2-0 -consensus-41523a59f270

Deterministic gadgets are designed to use the process in the beacon chain to finalize the blocks of Ethereum 1.0 . If we can provide the block data of Ethereum 1.0 to Casper's “deterministic engine”, then we can use the equity certification protocol to enhance the security of the current workload proof network. With enhanced security, improvements can be implemented, such as reducing mining subsidies (thus reducing circulation) and providing finalized block data to the Ethereum Virtual Machine (EVM) to create a more robust user-level application. The use of Phase 0 deterministic gadgets means that Ethereum 2.0 will be able to derive tangible benefits once it is online, although deployment of Ethereum 2.0 will take more time to complete.

The idea of ​​using the PoS Consensus to finalize the PoW-based blockchain has been brewing in the ecosystem for some time (for example, please refer to EIP-1101 https://eips.ethereum.org/EIPS/eip-1011 or Casper FFG's documentation https://arxiv.org/abs/1710.09437 ), and Alexey Akhunov has a good presentation (at the beginning of this slide: https://drive.google.com/file/d/ 16KLZKAutK79NxMh8L7B6hpNKuoOaAPZT/view ), which is about some developments of deterministic gadgets in the context of Ethereum 2.0.

How does a deterministic gadget work?

Now let's take a look at how the first version of a deterministic gadget works in the current state of Ethereum 2.0. Note that although the final specification of our beacon chain is about to be completed, some details (especially the parameters used by the system) are still under discussion and may change.

Building a deterministic gadget requires two things: (i) a deterministic engine and (ii) a solution that provides Ethereum 1.0 block data to the engine. It turns out that the beacon chain can achieve these two requirements during normal operation. The beacon chain is agreed through the Casper protocol, so any data on the chain can be finalized through normal operations. It is a bit difficult to implement the second requirement, because it means that the beacon chain needs to be a light client of Ethereum 1.0. Fortunately, Ethereum 2.0 will start from the Ethereum main network, and in this guiding process, the block hash of Ethereum 1.0 will eventually be included in the Ethereum 2.0 beacon chain.

Light client that tracks pledge margin

To become a certifier of the new Ethereum 2.0 system, you will need to send your pledge margin and registration data to the smart contract on the current main network, and then generate a log on the main network. This is a one-way pledge, and the pledge deposit can only be retrieved if the certificate of registration is submitted to the beacon chain. Once this pledge event is processed, you can enter the activation queue and eventually become an active certifier in the Ethereum 2.0 network .

– Complete a valid pledge on Ethereum 1.0 and activate the Certifier on Ethereum 2.0 after the end of the waiting period –

In order to verify the validity of these pledge certificates, the beacon chain must record the current state of the smart contract that handles the pledge event at Ethereum 1.0. At the time of this writing, the status to be recorded is (i) the root hash of the Merkel tree for all pledged deposits to date (ii) the total amount of pledged deposits to date (see the Eth1Data structure in the current specification https://github) .com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md ). The pledge certificate is usually generated on the basis of this Merkel root hash, and the total pledge margin is used to ensure that all pledge margins in this Merkel root hash are processed. (If the maximum pledge is not indicated in a block, then this block is invalid). Importantly, for deterministic gadgets, you also need to include a hash of the Ethereum 1.0 block that corresponds to the contract status .

– The beacon chain retains the status of the pledge contract on the Ethereum 1.0 chain to verify the pledge certificate and store the hash of the block corresponding to the recorded status. –

For each block generated on the beacon chain, the verifier must submit their status record for the pledge contract. If most of the records submitted during the specified time period are consistent, then the Ethereum 2.0 agreement can be considered as a consensus on the data of Ethereum 1.0 and recorded in the status of the beacon chain. As the blocks on the beacon chain are finalized, the corresponding state of each block is also determined; once a block data on Ethereum 1.0 is included in the final state, we can say the corresponding ether. The Block 1.0 block was finalized. This is the basic structure of a deterministic gadget.

– The figure above shows the voting process for a particular PoW block. Each block has a unique hash; the colors in the figure are used to mark the hash. Each small square represents the verifier's vote for a particular Ethereum 1.0 block. The scale on the black solid line is used to divide the time period (described in more detail below), and a new vote will be started for each time period. Only the first two time periods on the beacon chain are completed (the final confirmation of the beacon chain block), so only the 1.0 blocks (and their chains) that were finalized in these two phases are finally confirmed. Many thanks to Alexey for the coloring scheme :)-

Deterministic gadget parameters

Timing and frequency are two important parameters in the process of updating the data on Ethereum 1.0 to the beacon chain. They are an integral part of ensuring the quality of deterministic gadgets.

The first parameter is the number of SLOTS_PER_ETH1_VOTING_PERIOD (time slots in each Ethereum 1.0 voting period), that is, the number of slots in the state where the pending votes updated for Ethereum 1.0 data are left in the state (one time slot is A period of time, such as 6 seconds). During this time, each verifier will vote for Ethereum 1.0 data and their votes will be saved in the status. The scroll set of pending votes is cleaned up every time period (ie, slot) that is an integer multiple of SLOTS_PER_ETH1_VOTING_PERIOD. The Ethereum 1.0 data used as proof of pledge can only be updated if most of the verifiers reach a consensus during this time. Otherwise, the pending vote will be cleared and the vote will be re-balled without changing the existing 1.0 data.

– This figure shows some of the parameters related to the timing in Ethereum 2.0. The current parameters are: one slot is 6 seconds and each voting period contains 1024 slots (approximately 1.4 hours). –

The second important parameter is ETH1_FOLLOW_DISTANCE (following the distance of the Ethereum 1.0 chain). This number defines the 1.0 block range that the verifier can use to update the beacon chain state: only blocks that are greater than this value from the 1.0 chain end can become candidate blocks for the verifier. The verifier needs to listen to the candidate data for the new Ethereum 1.0 chain and select the candidate with the most votes. If there is no such candidate data (for example, we have just experienced a consensus slot), then the verifier should jump back to the end of the 1.0 chain and find the block with ETH1_FOLLOW_DISTANCE. For example, if the distance is 1024 and the end of the chain is block # 8,000,000, then we should find the status of the pledge contract in block # 7,998,976 and integrate this state and the hash of this block into us. The beacon chain block.

– The above figure shows the above "distance". There are three voting cycles shown in the figure, and each cycle is located in different time periods (not coincident with each other). The shaded parts shown in the figure are the candidate blocks for each cycle, which are determined based on their distance from the end of the chain. ETH1_FOLLOW_DISTANCE refers to the number of blocks. The distance in the figure is two blocks; currently set in the Ethereum 2.0 specification is 1024 blocks. –

This parameter is not included in the consensus of the beacon chain, but is a code that honest verifiers follow. This constant helps the verifier to form a coordination around the growing Ethereum 1.0 block (continuously updating the pledge mechanism), and at the same time there is a side effect that the Ethereum 1.0 chain can be finalized (at a given point in time). The block is set to a maximum height.

Doesn't this skip a lot of blocks?

It should be noted that, given the nature of the Ethereum 1.0 blockchain, as long as we can finally identify the block at the height N, we can assume that all blocks from the founding block to the block at height N are obtained. Final confirmation . This means that the final confirmed block set on the Ethereum 1.0 chain will suddenly skip a certain number of blocks based on the periodic loop determined by the first two parameters and the final acknowledgement time on the beacon chain. According to the current constant set by the beacon chain, this time period is preferably controlled to about 2 hours. According to the explanation below, this progress may slow down or even stop under adverse conditions.

Repeatedly

As I said before, the current Ethereum 1.0 chain does not need to know anything about the new system. In order to fully implement all the features of deterministic gadgets, we have to go further. This last step is to modify the fork selection rules of Ethereum 1.0 to make it final. Specifically, Ethereum 1.0 will still use the GHOST protocol to find the legal chain, but it will start from the newly confirmed block (confirmed by the beacon chain verifier) ​​instead of starting from the Genesis block as it is today. This step-by-step update to make deterministic gadgets available has the greatest impact on Ethereum 1.0, as the Ethereum 1.0 client must now receive a 2.0 consensus. However, modifying the fork selection rules extends the security of final determinism to the PoW chain, thereby achieving all the benefits of this additional security.

Improve deterministic gadgets with anti-rollback mechanisms

If the deterministic gadget can be successfully deployed according to the above rules, the client can use it to greatly improve the quality. This quality improvement is due to the minimization of the update distance between the 2.0 and 1.0 chains. The closer the final certainty is to the end of the Ethereum 1.0 chain, the more secure it will be, and the higher the quality of the data that will provide the user with final certainty.

Considering that block broadcasts always have a certain delay, the ideal situation is to make the "following distance" only a few blocks. Ethereum 2.0 started with a much larger following range (currently 1024 blocks), in part because deterministic gadgets don't exist yet (already introduced!). Another reason is the pledge mechanism. The pledge needs to be processed in order, once it is known by the chain, it must be submitted to the next available block. If the reorganization of the PoW chain occurs on a block that is considered legal by the beacon chain, then the pledge after the Ethereum 1.0 chain is considered invalid (ie invalidating the 2.0 set of verifiers), and may Breaking the mechanism to ensure that pledges are processed in order, and thus destroying future pledges, may even stop the 2.0 chain (because no certifier can submit valid blocks). If the following distance is large (in the current 1024 blocks), this is unlikely to happen because there are 1024 blocks determined by PoW above the block that reaches the final confirmation on the 1.0 chain. . If the client of 2.0 can trust the client of 1.0 to guarantee final confirmation (avoiding chain reorganization beyond a certain depth), the following distance can be shortened. From an abstract point of view, we can imagine that as the "following distance" is shortened, the "maximum height" of the candidate block can be approached to the end of the 1.0 chain in a "ratchet" manner until one The minimum safety distance . How much the following distance can be shortened is also the subject of future research/discussion.

Why do we want FG?

Reduce circulation

There are many advantages to finalizing the 1.0 chain. One of the big advantages is that mining subsidies can be reduced assuming that deterministic gadgets work well. By sharing the security of the beacon chain with the PoW chain, the PoW chain can achieve the same level of security while reducing dependence on miners' computing power. Since we don't need so much hashing power to ensure chain safety, we can reduce mining subsidies (which will reduce incentives for miners and reduce the total amount of mining activity). One of the most direct side effects is that it reduces the ETH's issuance rate and the corresponding total supply. This goal seems to be widely supported by the community. After successfully deploying deterministic gadgets on the main network and modifying the fork selection rules, you can achieve this benefit by gradually reducing the block rewards with another fork, as described in EIP-1011: http://eips .ethereum.org/EIPS/eip-1011#block-reward .

While the exact plan remains to be discussed, reducing circulatory volume through deterministic gadgets is the first step in moving the Ethereum 1.0 chain to the 2.0 system. We will move smoothly, and this process will begin with a gradual reduction in circulation. As a member of the community, we can now start with supporting this initiative and advance the subsequent migration.

Final determinism of the application

Once the 1.0 client receives the finalized data, the data can be exposed to the smart contract and related applications via the Ethereum virtual machine. Final determinism is a very useful attribute because the highest level of certainty that can be achieved at this stage requires waiting for “sufficient” “confirmation” numbers, and the PoW chain is only “impossible” (but still possible) Reorganization. Imagine that there is such an exchange that the user has to wait a lot of times to make a withdrawal after the withdrawal operation. If the exchange only has to wait until finalization, it can significantly shorten the withdrawal time and give the user a better experience.

Smart contracts can also take advantage of final certainty. Predicting the market is an example. It is useful to wait for a certain height to achieve final certainty before confirming the outcome of an event. Implementing such benefits also seems to be deployed through a fork (which may be done concurrently with reducing the forks of the circulation), that is, adding a set of opcodes to determine a block hash or a certain height for the Ethereum virtual machine. Whether the block has been finalized. An EIP case similar to this (adding a new opcode) is the EIP-145 (bit-by-bit move command) ( https://eips.ethereum.org/EIPS/eip-145 ).

Operation of Ethereum 2.0

Deterministic gadgets mean that Ethereum 2.0's phase 0 will bring some benefits when it starts. Ethereum 2.0 is currently being deployed in phases: Phase 0, Phase 1, and Phase 2. Each phase introduces new complexity into the sharding system, while the 2.0 team is currently working on the phase 0 at the end of 2019, and the rest of the phase is expected to take more time. Since the user-level account system similar to Ethereum 1.0 has to wait until phase 2, it is necessary to let everyone understand that each stage of Ethereum 2.0 can bring us some benefits.

With the launch of Phase 0, we can introduce deterministic gadgets into the 1.0 chain to get all the benefits mentioned in this article. In Phase 1, Ethereum 2.0 can implement a slice chain that can hold arbitrary data. The implementation of deterministic gadgets means that the client of Ethereum 1.0 became the light client of Ethereum 2.0. With the help of the light client function, proofs can be generated for the data in the slice chain through the Ethereum 1.0 smart contract. This feature unlocks many interesting use cases for layer 2 expansion technology, such as the high-performance Plasma chain and the zk-SNARKs application that provides privacy. I recommend Vitali's recent talk on "Extensible Blockchain as a Data Layer", https://www.youtube.com/watch?v=mOm47gBMfg8 .

How to deploy?

The deployment of deterministic gadgets involves many components being developed and may require multiple upgrades to enhance their effectiveness; in short, this is a complex solution that requires a lot of work:)

The first step is to refine the idea of ​​deterministic gadgets in the form of proof-of-concept prototypes and simulations to better understand the impact of coupling the two systems in this way. The ideal situation is to deploy deterministic gadgets on a popular mainframe client. In this way, we can collect real-time data on the running of deterministic gadgets, let us know that deterministic gadgets will follow the consensus reached by existing clients.

In parallel with deterministic gadgets, there are development and on-line beacon chains; we need to finalize the block through the beacon chain before deploying deterministic gadgets, so there is no need to explain.

Once we understand what we need to deploy, we can write an EIP to clarify the deployment process and include it step by step into the next fork plan. I think the more sensible option is to deploy deterministic gadgets before discussing the issue of reducing mining subsidies or introducing new EVM opcodes. This proposal follows the idea of ​​“making only one change at a time” and shows which parts of the deterministic gadget will have an impact at each stage . We don't want to find that deterministic gadgets are not as effective as expected after reducing block rewards, which can lead to a reduction in the security of the primary network.

The risk of deterministic gadgets

In a broad sense, deterministic gadgets represent the bidirectional coupling of the 1.0 chain and the 2.0 beacon chain . The higher the degree of coupling between the two systems, the wider the attack surface, causing greater concern. We will analyze the coupling in all aspects before making some specific design recommendations for deterministic gadgets.

The primary function of deterministic gadgets is to import new 1.0 chain data into the beacon chain. The verifier on the beacon chain must be a light client of Ethereum 1.0; if a 1.0 block hash is not in the specific 1.0 chain verifier view, then the beacon chain block consensus formed by the hash will be considered Invalid. This validity condition ensures that as long as most 2.0 verifiers are honest, no invalid data will be finalized on the 1.0 chain. If more than two-thirds of the verifiers are malicious, they may collude to identify a 1.0 block that may not follow the underlying PoW consensus. By setting a larger initial set of verifiers and adopting a conservative deterministic gadget deployment scenario, we can reduce concerns about this situation. If the beacon chain starts and we know that the verifier is the majority of the perpetrators, then we have a chance to reconsider our plan. The design of Ethereum 2.0 and deterministic gadgets needs to ensure that even if this happens, there will be no changes or impacts on the Ethereum 1.0 blockchain.

Another concern is that, given that the verifier is to propose the next block in a voting cycle, this will not affect the correctness of the deterministic gadget, but it will affect its performance. The current specification suggests that the verifier selects most of the blocks proposed by the previous block initiator, while ensuring that the block is in its own view . In practice, this means that an honest verifier only needs to select the first valid block proposed in each round of voting and eventually reach a consensus. The next block that is finalized will be selected from all proposed blocks. Therefore, if the next block cannot be selected (in the divided SLOTS_PER_ETH1_VOTING_PERIOD time period), it means that the deterministic gadget has no way to determine the 1.0 block as quickly as possible. By further researching better voting strategies to facilitate the finalization of the 1.0 chain, we can reduce this concern.

The last type of risk is the forked selection of the 1.0 chain when the following distance is very short and the 1.0 chain is under attack, in the case of many short forks. This is a trade-off between the quality of the final deterministic (determined by the distance between the finalized GHOST head of the chain and the chain) and the risk of unstable bifurcation choices on the PoW chain. In future research, we will better understand the trade-off between the two through simulation and give the final proposal for deterministic gadgets.

Such attacks can cause the 1.0 chain's finalization mechanism to be delayed or even embarrassing, leading to degraded performance of deterministic gadgets. When we rely on final certainty to ensure the security of the 1.0 chain, there is a great risk.

Unresolved issue

• Assuming that the deterministic gadget is put into operation, how do we adjust the mining subsidy (or not at all)? Should mining subsidies be reduced by hard forks? Should the circulation be a function of the following distance? Can we compare the security of the current main network computing power with the economic security (determined by ETH) brought about by the final certainty?
• How much can the follow distance be reduced? How to adjust? Is it slowly shortening over time, or is it shortened to a minimum after deploying a deterministic gadget?
• Is the Ethereum 1.0 block voting process on the beacon chain sufficient to support the high-performance operation of deterministic gadgets?

in conclusion

I hope you can better understand what a deterministic gadget is, why we need it and how we should plan for subsequent progress. We still have some issues to solve, and we look forward to your help.

If you want to help us, Alexey and I are working on a workforce dedicated to implementing deterministic gadgets. You can click here to participate: Ethereum 1.x Deterministic Gadgets Working Group

I would like to thank Danny Ryan for having had a lot of useful discussions with me to better understand the beacon chain and how to use it to bring finality to Ethereum 1.0, and to Alexey Akhunov for his contribution to the working group. Thanks to Terence Tsao for his feedback on this article.

Original link: https://medium.com/@ralexstokes/the-finality-gadget-2bf608529e50 Author: Alex Stokes Translation & proofreading: Whisker & Min Min

This article was authored by the original author to translate and republish EthFans.

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

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