Introduction | What support does ETH 1.0 need to provide for ETH 2.0?

New territory

The mainnet of ETH 2.0 Phase 0 (also known as "beacon chain") is expected to be launched later this year. Right now, we should think about the question: what can the existing network do to drive the new system to go online smoothly? We can imagine some exciting application scenarios that can (before ETH 1.0 is merged into ETH 2.0) take advantage of the interoperability between the two networks, but the facts show that if the EVM (Ethereum Virtual Machine) cannot be modified to adapt With the new cryptographic components used in the ETH 2.0 system, these applications will be blocked. Here I hope to provide a brief description of these new cryptographic components and explain why integrating them into the EVM will help us to take advantage of the new system's capabilities before Eth1 migrates.

What is missing from ETH 1.0?

All data on the Ethereum blockchain is public, so we must use cryptographic signatures to ensure that specific transactions reflect the demands of interested parties. The signature scheme used by Ethereum is based on an elliptic curve, using a curve named secp256k1. The points on this curve are used in a signature scheme called ECDSA, which gives our cryptographic signature the properties we expect.

-, the property of this elliptic curve improves the security of the ECDSA signature scheme-

Although the ECDSA signature scheme based on secp256k1 has been tested for many years, the definition standards of the two are only about 20 and 10 years old. ETH 2.0 adopts a relatively new structure and takes advantage of new developments in cryptography. Verifiers in the ETH 2.0 system (similar to ETH 1.0 miners) use BLS   The signature scheme is based on another elliptic curve called BLS12-381 . (Please note that "BLS" is an abbreviation, these three letters are from the names of the three authors!) The new technology of ETH 2.0 is mainly because it can efficiently aggregate multiple signatures into one signature , Directly promoting the participation feasibility of ETH 2.0 security. For more information, see Carl Beekhuizen 's article on the importance of signature aggregation in ETH 2.0 (editor's note: see the hyperlink "Eth2 Staking Guide # 2" at the end of the article).

Although BLS signatures have many benefits for Eth2, the problem we encountered is that ETH 1.0 itself does not support this new cryptographic component, and its underlying mathematical logic is very computationally demanding, which prevents us from implementing BLS in EVM. signature. Fortunately, we can add computational logic as a "pre-compiled" part to circumvent the EVM's performance limitations-hard-coded algorithms allow native implementations to be called by smart contracts outside the EVM interpreter.

How to implement pre-compilation?

The pre-compiled part of the Ethereum protocol is a scarce resource, so it is only left to the computing logic that the community considers important. In addition, pre-compilation needs to be deployed through a hard fork (because they change the semantics of the EVM), so coordination costs are high. Fortunately, in the current EIP-2537 draft, we can see that the work related to these BLS precompilations is progressing. EIP-2537 includes pre-compilation of BLS12-381 curve operations, and another high-cost operation called "map to curve" used in the BLS algorithm scheme. If you delve into the mathematical principles of the BLS algorithm scheme, you will find that you need to use a mechanism to convert a message (you want to sign) into a point on the elliptic curve through the "map to curve" operation.

What does pre-compilation bring us?

EIP-2537 pre-compilation will help ETH 2.0 go live by improving the user experience of the margin contract, and lay the foundation for building an ETH 2.0 light client within ETH 1.0. The BLS12-381 curve itself can be used to construct zk-SNARKs, along with the BLS used in other blockchains, paving the way for interoperability between these networks.

  • Margin contract user experience

The initial method to become an ETH 2.0 beacon chain verifier is to deposit ETH into a smart contract on ETH 1.0 ("margin contract"). In order to save Gas fees and minimize complexity, the main function of the margin contract is to provide a cryptographic commitment to a deposit (on the Merkel tree), and then such a commitment can be used as a proof on the beacon chain . Importantly, the BLS signature required to confirm the margin is not verified on the ETH 1.0 chain. The testnet caused a series of BLS signature calculation errors due to vulnerabilities, and lost part of the testnet ETH. In order to verify the BLS signature on the ETH 1.0 chain (which can be implemented through EIP-2537), we can write a "forward" smart contract to obtain the margin data, verify the signature and then only send the margin data to the margin contract. Although this function is not a necessary condition for guaranteeing the security of margin contracts, it does bring psychological comfort to developers who interact with margin contracts.

  • ETH 2.0 light client built within EVM

We believe that before building an ETH 2.0 light client on the ETH 1.0 chain, we must first let ETH 1.0 "understand" the cryptography technology used by ETH 2.0. In this way, it is possible to implement a light client similar to BTCRelay in smart contracts. Once this kind of light client is implemented, it will become the backbone of the "bridge" between the ETH 1.0 and ETH 2.0 networks. It is a little exciting to think about it. Through this two-way bridge, ETH can be transferred between ETH 1.0 and ETH 2.0 networks, and ETH 2.0 sharding can also be used as a highly scalable data layer to support the two-layer architecture on ETH 1.0 (for example, optimistic rollups , Zk-rollups, etc.).

Excited, but it should be noted that building a light client within the EVM as a smart contract (rather than implementing a light client at the ETH 1.0 client level) may not be the best way for ETH 1.0 to understand ETH 2.0. In addition, the latest research on the "two-way bridge" shows that this method is not feasible considering other security parameters of ETH 1.0 and ETH 2.0 networks (it is better to fork the state of ETH 1.0 and then put it on the ETH 2.0 shard). Having said that, there is no harm in laying the foundation now, and as the follow-up research progresses, the merger strategy of ETH 1.0 and ETH 2.0 may change.

  • zk-SNARKs

The purpose of creating the BLS12-381 curve is to enable ZCash to use more efficient zk-SNARKs (if you want to learn more about the BLS12-381 curve, you can check the link above). In addition, adding this curve to the EVM allows Ethereum to verify such SNARKs, and implement a privacy and scalability application through a zero-knowledge proof protocol.

  • Other networks

Some "new generation" blockchains (Filecoin, Chia, Cosmos, etc.) also intend to use the BLS signature scheme; giving the EVM a native function to verify these signatures can unlock more interoperability use cases, just like ETH 1.0 and ETH 2.0 Like that.

Sooner rather than later

All uses proposed in EIP-2537 will not prevent ETH 2.0 from going live. Moreover, the optimization of the margin contract will bring good results; the sooner we lay the foundation for interoperability, the sooner we can start to prototype such applications. This EIP may be put into the next Ethereum Berlin hard fork. If you also want to make a contribution, you can support the implementation of EIP-2537 on your favorite client :).

Thanks to Kobi Gurkan and Alex Vlasov for their review.


Original link: Author: Alex Stokes Translation & proofreading: Min Min & A sword

This article was authorized by the original author to be translated and republished by EthFans.