Popular Science | What does ETH 2.0 need from ETH 1.0, and what is EIP-2537?

Editor’s note: The original title was “What does eth2 need from eth1?”

Foreword: The main purpose of this article is to support EIP-2537. It hopes that before eth1 becomes an eth2 shard, the new cryptographic primitives used on eth2 can be integrated into the EVM, which can allow eth1 to take advantage of the functions of the new system and lay the foundation for interoperability. This article was written by Alex Stokes and translated by "DR" of "Blue Fox Notes".

New Frontier

With the first phase of the eth2.0 mainnet (the "beacon chain") expected to launch later this year, it's time to ask if there's anything the existing network can do to facilitate the smooth generation of the new system. We can imagine some exciting use cases that take advantage of interoperability between the two networks (before eth1 is merged into eth2), but it turns out that these applications will be impossible to implement and require modifying the EVM to understand the new cryptographic primitives used on eth2.

I want to provide a high-level overview of the new cryptography and explain that integrating it into the EVM will lay the foundation for leveraging the new system’s capabilities in eth1 before migrating the eth1 state to the new system.

What is missing from eth1?

Given that all data on the Ethereum blockchain is public, cryptographic signatures are needed to ensure that a particular transaction reflects the intent of the parties involved. The signature scheme used on Ethereum is based on a mathematical object called an "elliptic curve", where the specific curve used is called secp256k1. Points on this curve are used in a specific signature scheme, ECDSA, which provides the cryptographic signature properties we expect.

https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication, This mathematical property improves the security of ECDSA as a signature scheme.

Although secp256k1's ECDSA has been in use for many years, the standards that define them are 20 and 10 years old respectively. eth2 uses a new structure that takes advantage of advances in cryptography since then. Validators on eth2 (similar to eth1's miners) use the BLS signature mechanism, which is based on another elliptic curve called BLS12-381. (Note that the "BLS" in the name is an abbreviation, representing different sets of "B", "L", and "S"!)

The main reason for using this stack is that it allows many signatures to be efficiently aggregated into one signature, which directly helps the scalability of eth2 security. For more information on the importance of signature aggregation in eth2, refer to Carl Beekhuizen's article.

While these advances are great for eth2, we immediately run into issues because eth1 does not natively support this new cryptography, and the computationally demanding nature of the underlying math prevents us from performing BLS signatures in the EVM. Fortunately, we can circumvent the performance limitations of the EVM by adding the computation as a “precompile”, which is a hardcoded algorithm that, when called by a smart contract, defers to a native implementation outside of the EVM interpreter.

How we get it

Precompiles on Ethereum are a scarce resource and are therefore only reserved for computations that the community deems important. Furthermore, they require a hard fork for deployment (since they change the EVM semantics) and are therefore expensive to coordinate. Fortunately, there is a draft of EIP-2537 that has been proposed regarding these BLS precompiles.

This EIP includes several precompiles that operate on the BLS12381 curve, and will include an additional expensive operation called "curve mapping" (for the BLS signature scheme). If you dig into the mathematics of the BLS signature scheme itself, you'll find that some mechanism is needed to convert specific information into a representation of a point on the curve, which helps "map to the curve."

How does it help us?

EIP-2537 precompiles will immediately help eth2 by improving the user experience of storage contracts and laying the foundation for building eth2 light clients in eth1. The BLS12-381 curve itself can be used to build zk-SNARKs, and the use of BLS in other blockchains can pave the way for interoperability between these networks.

• Storage Contract User Experience

The initial way to become a validator of the eth2 beacon chain is by depositing ETH into a smart contract ("deposit contract") on eth1. In order to save gas costs or minimize complexity, this smart contract simply makes a cryptographic commitment (on a Merkle tree) to a specific deposit, which is proof that it can be spent on the beacon chain, and does nothing more.

Importantly, the BLS signatures required to verify deposits are not verified on the eth1 chain. This fact led to the loss of testnet ETH when a series of BLS signatures were not calculated correctly due to a bug. By supporting verification of BLS signatures on the eth1 chain (EIP-2537), we can write "forwarding" smart contracts that receive deposit data, verify the signature, and then send the deposit data to the deposit contract. The deposit contract is not required to work in a secure manner, but it does add some additional peace of mind for developers interfacing with the deposit contract.

• eth2 light client inside EVM

We also hope that eth1 can understand eth2 encryption technology and use it as a prerequisite for building eth2 light clients on the eth1 chain. This capability makes it possible to use light clients in the form of BTC relays in smart contracts. Such a light client is exciting because it forms a "bridge" between the eth1 and eth2 networks. Such a two-way bridge can unlock the ability to transfer ETH between eth1 and eth2, and it also allows eth2 shards to be used as a massively scalable data layer to support the construction of Layer 2 on eth1 (such as Optimistic Rollups, zk-rollups, etc. For Rollup, please refer to the previous article of Blue Fox Notes "Understanding ZK Rollup and Optimistic Rollup in One Article: Important Expansion Direction of Ethereum")

While it’s exciting to note that building a light client inside the EVM (as a smart contract) may not be the best way to add eth2 awareness to eth1 (implementing a light client at the eth1 client level instead), recent research on “two-way bridging” suggests that this is not feasible given the other security parameters of each network. (Instead, simply putting eth1 state into the eth2 shard would make more sense). That being said, it doesn’t hurt to lay the foundation today, and it’s possible that the eth1-eth2 merge strategy will change in the future.

• zk-SNARKs

The BLS12-381 curve was created to support more efficient zk-SNARKs used in Zcash, and adding the curve to the EVM will allow Ethereum to verify this SNARKs, allowing zero-knowledge protocols to be used in privacy applications and achieve scalability.

• Other Networks

There are also many “next generation” blockchains (Filecoin, Chia, Cosmos…) that intend to use the BLS signature mechanism to some extent in order to have the ability to verify these signatures natively in the EVM and unlock similar interoperability use cases between eth1 and eth2.

How urgent is this?

None of the use cases supported by EIP-2537 are a hindrance to the launch of eth2. However, this is a good improvement for the deposit contract, and soon, the sooner we lay the foundation for interoperability, the sooner we can prototype these applications. This does seem to be conducive to pushing this EIP into the next Ethereum hard fork codenamed Berlin. You can advance these efforts by supporting the implementation of this EIP in your favorite client. ------ Risk Warning: All articles in Blue Fox Notes cannot be used as investment advice or recommendations. Investment is risky. Investment should consider personal risk tolerance. It is recommended to conduct in-depth research on the project and make your own investment decisions carefully.

Link to this article: https://www.8btc.com/media/582273
Please indicate the source of the article when reprinting