EIP-2537: ETH 1.0 support for ETH 2.0
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans)
, Author: Alex Stokes, Translator & Proofreader: Min Min & A Jian, reproduced by Odaily with authorization.
first level title
new territory
The mainnet of ETH 2.0 Phase 0, also known as the "beacon chain," is expected to go live later this year. Right now, we should think about this question: what can the existing network do to promote the smooth launch of the new system? We can imagine some exciting use cases where interoperability between the two networks could be exploited (before ETH 1.0 merged into ETH 2.0), but it turns out that if the EVM (Ethereum Virtual Machine) cannot be modified to accommodate These applications will be hindered by the new cryptographic elements used in the ETH 2.0 system. Here I hope to provide an overview of these new cryptographic elements and explain why their integration into the EVM will help us take advantage of the new system's capabilities even before Eth1 migrates.
-https://en.wikipedia.org/What is missing from ETH 1.0?
All data on the Ethereum blockchain is public, so we must use cryptographic signatures to ensure that a particular transaction reflects the intent of the parties involved. The signature scheme used by Ethereum is based on elliptic curves, using a curve called secp256k1. The points on this curve are used in a signature scheme called ECDSA to give our cryptographic signatures the properties we desire.
image description
, 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 in use for many years, the defining standards of the two are only about 20 and 10 years old, respectively. ETH 2.0 uses a relatively novel construction that takes advantage of new advances in cryptography. Validators in the ETH 2.0 system (similar to ETH 1.0 miners) use the BLS signature scheme, based on another elliptic curve called BLS12-381. (Note that "BLS" is an abbreviation, and the three letters come from the names of the three proposers!) ETH 2.0 adopts this new technology mainly because it can efficiently aggregate multiple signatures into a single signature , to directly promote 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 "Eth2 Staking Guide #2" hyperlinked 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 element, and its underlying mathematical logic requires high calculations, which prevents us from implementing BLS in EVM sign. Fortunately, we can add calculation logic as a "precompiled" part to circumvent the performance limitations of EVM - through hard-coded algorithms, the native implementation can be called by smart contracts outside the EVM interpreter.
How to implement precompilation?
The precompiled part of the Ethereum protocol is a scarce resource, so only the calculation logic that the community considers important is left. Furthermore, precompiles need to be deployed via hard forks (as they change the semantics of the EVM), so coordination costs are high. Fortunately, in the current draft of EIP-2537, we can see that work on these BLS precompilations is progressing. EIP-2537 includes a precompilation of the BLS12-381 curve operation, and another expensive operation called "map to curve" used in the BLS algorithm scheme. If you dig into the mathematics of the BLS algorithm scheme, you'll find that you need some mechanism to convert a message (that you want to sign) into a point on an elliptic curve via a "map to curve" operation.
What benefits does precompilation bring us?
EIP-2537 precompilation will help ETH 2.0 go live by improving the margin contract user experience, and lay the foundation for building ETH 2.0 light clients within ETH 1.0. The BLS12-381 curve itself can be used to build zk-SNARKs, which together with BLS used in other blockchains paves the way for interoperability between these networks.
User Experience for Margin Contracts
The initial method of becoming a validator on the ETH 2.0 Beacon Chain is by depositing 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 (on the Merkle tree) for a certain deposit, and then such a commitment can be used as proof on the beacon chain . Importantly, the BLS signatures required to confirm the bond are not verified on the ETH 1.0 chain. A series of BLS signature calculation errors occurred in the test network due to a loophole, and a part of the test network ETH was lost. In order to verify the BLS signature on the ETH 1.0 chain (which can be achieved through EIP-2537), we can write a "forward" smart contract to obtain the bond data, verify the signature and then send only the bond data to the bond contract. Although this feature is not a prerequisite for ensuring the security of margin contracts, it does bring psychological comfort to developers who interact with margin contracts.
zk-SNARKs
We believe that before building an ETH 2.0 light client on the ETH 1.0 chain, it is necessary to 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 the smart contract. Once this kind of light client is realized, it will become the pillar of the "bridge" between 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 fragmentation can also be used as a highly scalable data layer to support the two-tier architecture on ETH 1.0 (for example, optimistic rollups , zk-rollups, etc.).
other networks
Excitement is all excitement, but be aware that building a light client inside 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 to make ETH 1.0 understand ETH 2.0. Furthermore, recent research on "two-way bridges" shows that this approach is not feasible given other security parameters of the ETH 1.0 and ETH 2.0 networks (might as well fork the ETH 1.0 state and put it on an ETH 2.0 shard). Having said that, there is no harm in laying the groundwork now, and as follow-up research progresses, the merger strategy of ETH 1.0 and ETH 2.0 may change.
The purpose of creating the BLS12-381 curve is to enable ZCash to use more efficient zk-SNARKs (if you want to know more about the BLS12-381 curve, you can check the link above). Furthermore, adding this curve to the EVM enables Ethereum to verify such SNARKs, enabling privacy and scalability applications through zero-knowledge proof protocols.
other networks
Some "next generation" blockchains (Filecoin, Chia, Cosmos, etc.) are also planning to use the BLS signature scheme; giving the EVM the ability to verify these signatures natively could unlock more interoperability use cases, just like ETH 1.0 and ETH 2.0 like that.
