What parts of eth1 are needed by eth2?

Editor's Note: This article comes fromBlue Fox Notes (ID: lanhubiji), reprinted by Odaily with authorization.

Blue Fox Notes (ID: lanhubiji)

Blue Fox Notes (ID: lanhubiji)

, reprinted by Odaily with authorization.

secondary title

new frontier

I wanted to provide a high level overview of the new cryptography and explain that before migrating the eth1 state to the new system, integrating it into the EVM lays the foundation for exploiting the new system's capabilities in eth1.

https://en.wikipedia.org/,secondary title

What is missing from eth1?

Considering that all data on the Ethereum blockchain is public, cryptographic signatures are required to ensure that a particular transaction reflects the needs of the parties involved. The signature scheme used on Ethereum is based on an "elliptic curve" mathematical object, where the specific curve used is called secp256k1. Points on this curve are for a particular signature scheme, ECDSA, which provides our desired cryptographic signature properties.

This mathematical property increases the security of ECDSA as a signature scheme.

Although ECDSA for secp256k1 has been practiced for many years, the standards that define them are 20 and 10 years old, respectively. eth2 uses a new structure that takes advantage of cryptographic advances made since then. Validators on eth2 (like miners on eth1) use the BLS signature scheme, which is based on another elliptic curve called BLS12-381. (Note that the "BLS" in the name are all abbreviations, denoting different sets of "B", "L", "S"!)

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

secondary title

how do we get it

Precompilation on Ethereum is a scarce resource, so it is reserved only for computations deemed important by the community. Also, they require a hard fork for deployment (since they change the EVM semantics), so coordination is expensive. Fortunately, there is a current EIP-2537 draft for these BLS precompiles.

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

secondary title

How does it help us?

• EIP-2537 precompilation will help eth2 immediately 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 could pave the way for interoperability between these networks.

Storage contract user experienceTo become a validator on the eth2 beacon chain, the initial method is by depositing ETH into a smart contract on eth1 (“storage contract”). In order to save gas costs or minimize complexity, this smart contract is only a cryptographic commitment (on the Merkle tree) to a specific deposit, which is a proof of consumption on the beacon chain, and does not do much else matter.》）

Importantly, the BLS signatures required to verify storage 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 (EIP-2537) on the eth1 chain, we can write "forward" 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 does add some extra peace of mind for developers interfacing with the deposit contract.

• zk-SNARKs

eth2 light client inside the 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 BTC relay mode 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 sharding to be used as a massively scalable data layer to support Layer 2 construction on eth1 (such as Optimistic Rollups, zk -rollups, etc. For Rollup, please refer to the previous article of Blue Fox Notes "

Excitingly, building a light client (as a smart contract) inside the EVM may not be the best way to add eth2 awareness to eth1 (alternative implementation of a light client at the eth1 client level), and the latest on "two-way bridging" Research shows that this is not feasible given the other security parameters of each network. (Instead, it would make more sense to just put the eth1 state into the eth2 shard). Having said that, it doesn't hurt to lay the groundwork today, and the eth1-eth2 merger strategy may change in the future.

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 reliability scalability.

other networks