What eth2 needs from eth1 over the next six months
tl; dr: support EIP-2537!
a new frontier
With the mainnet launch of the first phase of eth2.0 (called the “beacon chain”) expected later this year, it is time to ask if there is anything the existing network can do to facilitate a smooth genesis of the new system. We can imagine a number of exciting use cases leveraging interoperability between the two networks (ahead of merging eth1 into eth2) but it turns out that these applications are blocked on modifying the EVM to understand new cryptographic primitives used in eth2. I want to provide a high-level overview of the new cryptography and explain how integrating it into the EVM will lay the groundwork for taking advantage of the new system’s features in eth1 before we migrate the eth1 state to the new ecosystem.
what is missing from eth1?
Given that all data on the Ethereum blockchain is public, cryptographic signatures are required to ensure that a given transaction reflects the desires of the parties involved. The signature scheme used in Ethereum is based on mathematical objects called elliptic curves where the particular curve used is called secp256k1. Points on this curve are used in a particular signature scheme called ECDSA which provides the properties we expect from our cryptographic signatures.
While ECDSA over secp256k1 has been battle-tested over many years of usage, the standards defining them are around 20 and 10 years old, respectively. eth2 uses newer constructions that take advantage of advances in cryptography since. Validators in eth2 (analogous to eth1’s miners) use the BLS signature scheme working over a different elliptic curve known as BLS12-381. (Note that the “BLS” in each name are abbreviations referring to different sets of “B”, “L”, and “S”!) A major reason to use this new stack is that it admits efficient aggregation of many signatures into one signature which directly contributes to the scalability of eth2’s security. See this article by Carl Beekhuizen for more information on the importance of signature aggregation in eth2.
While these advances are great for eth2, we immediately run into an issue as eth1 does not natively support this new cryptography and the computationally demanding nature of the underlying mathematics excludes us from implementing BLS signatures inside the EVM. Luckily, we can sidestep performance limitations of the EVM by adding computations as “precompiles” — hardcoded algorithms which defer to a native implementation outside the EVM interpreter when called in a smart contract.
how can we get it?
Precompiles on Ethereum are scarce resources and so are only reserved for computations deemed important by the community. Moreover they require hard forks for deployment (as they change the EVM semantics) so have a high coordination cost. Luckily, work has been underway for these BLS precompiles seen in the current draft EIP-2537. This EIP includes several precompiles for operations over the BLS12-381 curve and will include another expensive operation known as “map to curve” used in the BLS signature scheme. If you dig into the math of the BLS signature scheme itself, you will find that some machinery is required to get a given message (that you want to sign over) into a representation as a point on the curve which “map to curve” helps with.
what does it get us?
The EIP-2537 precompiles will immediately help with the eth2 launch by enhancing the deposit contract user experience and lays the ground work for the construction of an eth2 light client inside eth1. The BLS12-381 curve itself can be used to construct zk-SNARKs and the use of BLS in other blockchains paves the way to interoperability with those networks.
- Deposit contract UX
The initial way to become a validator of eth2’s beacon chain will be via the deposit of ETH on a smart contract on eth1 known as the “deposit contract”. To save on gas costs and minimize complexity, this smart contract does not do much more than cryptographically commit to a given deposit (in a Merkle tree) which then allows a proof to be consumed on the beacon chain. Importantly, the BLS signature required to validate a deposit is not verified on the eth1 chain. This fact has already resulted in loss of testnet ETH when a series of BLS signatures were incorrectly computed due to a bug. By enabling verification of BLS signatures on the eth1 chain (enabled by EIP-2537), we can write a “forwarding” smart contract that takes the deposit data, verifies the signature and only then sends the deposit data to the deposit contract. This capability is not required for the deposit contract to work in a secure fashion but does add some extra peace-of-mind for developers interfacing with the deposit contract.
- eth2 light client inside the EVM
We also want the ability for eth1 to understand the eth2 cryptography as a prerequisite for building an eth2 light client on the eth1 chain. This capability would make a BTCRelay-style light client possible inside a smart contract. Such a light client is exciting as it forms one leg of the “bridge” that would go between the eth1 and eth2 networks. A two-way bridge like this would unlock the ability to move ETH between the eth1 and eth2 networks and also allow the use of the eth2 shards as a massively scalable data layer powering L2 constructions on eth1 (like optimistic rollups, zk-rollups, etc.).
While exciting, it should be understood that building a light client inside the EVM (as a smart contract) may not be the best way to add eth2-awareness to eth1 (in lieu of implementing the light client at the eth1 client level) and that the latest research on a “two-way bridge” suggests it is not feasible under consideration of other security parameters in each network (and instead, it would make more sense to simply fork the eth1 state into an eth2 shard). That being said, it doesn’t hurt to lay the ground work today and it is possible (if unlikely) that the eth1-eth2 merge strategy could change pending further research.
- zk-SNARKs
The BLS12-381 curve was created to support more efficient zk-SNARKs for use in ZCash (see the link to the curve above for more info) and adding the curve to the EVM would let Ethereum verify such SNARKs allowing zero-knowledge protocols with applications in privacy and scaling.
- Other networks
There are also a number of “next-gen” blockchains (Filecoin, Chia, Cosmos, most of them it seems …) that intend to use the BLS signature scheme in some capacity so having the ability to natively verify these signatures in the EVM unlocks similar interoperability use cases like that between eth1 and eth2.
how urgent is this?
None of the use cases enabled by EIP-2537 are blocking the eth2 launch. However, the deposit contract enhancement would be quite nice and the sooner we can lay the ground work for interoperability the sooner we can start prototyping those types of applications. There does seem to be a push to get this EIP into the next Ethereum hardfork, codenamed Berlin. You can help these efforts yourself by supporting the implementation of the EIP in your favorite client :)
Thanks to Kobi Gurkan and Alex Vlasov for review.
