Introduction: BLS signatures and the story of ETH2.0

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, Author: Justin Drake, translation & proofreading: Min Min & A Jian, reprinted by Odaily with authorization.

It has been about 2.5 years since ETH 2.0 adopted BLS signature technology, here are some milestone events.

In May 2018, I published an article on ethresear.ch, pointing out that BLS signatures can allow ETH 2.0 to achieve a minimum pledge mechanism of 32 ETH, and 1024 shards, which can increase the degree of decentralization and scalability by several order of magnitude.

In October 2018, I wrote to Dan Boneh (cryptography advisor to the Ethereum Foundation) that "we are considering using the BLS12-381 curve in ETH 2.0, following the example of Zcash and Chia." To which he replied: "(Based on our current knowledge) the BLS12-381 curve is the right choice." The background was that a 2016 paper reduced the security level of BN254 from about 128 bits to 110 bits. Given that blockchain infrastructure is designed to last for decades, we adopt cryptographic conservatism, and the ETH 2.0 research team is really not happy with the status quo of BN254. (Another reason to use BLS signatures is that using curve pairings in a cryptographic production system is inherently aggressive.)

In March and April 2019, we did some call-outs. I reached out to a number of blockchain projects (Chia, Filecoin, Dfinity, Cosmos, Ledger, etc.) with the goal of getting all of them to use the same cryptographic primitives for interoperability, library reuse, shared security auditing, etc. Specifically, our goal is to get people involved in the IETF BLS standardization work. This work was started independently and was still in its infancy at the time. Dozens of people are involved in the effort, creating Telegram groups and holding regular conference calls.

Also in April 2019, Riad Wahby proposed constant-time curve hashing for BLS12-381 in this paper. Constant-time hashing is very useful. It can simplify the arithmetic of SNARKs, simplify the gas metering of blockchain opcodes, and solve timing and DoS attack problems for specific applications. It has naturally become a part of the IETF standard. In fact, much of the remaining normalization work (eg, choosing generators and point serialization) is done by Zcash.

In September 2019, Carl Beekhuizen wrote three EIPs (2333, 2334, 2335) to standardize BLS from aspects other than the IEFT standard, e.g., quantum-safe backups, HD wallets (hierarchical deterministic wallets) and keys library etc.

In November 2019, we are working on the best performing BLS12-381 implementation. I started learning more complex BLS optimizations myself, and met Shigeo Mitsunari (the author of the current fastest implementation of the Herumi library) through an introduction by Raul from Prysm. A few weeks later, the Ethereum Foundation gave Shigeo a grant to follow up on the draft of the IETF standard, write some bindings for the ETH 2.0 client, and improve the performance of the Herumi library. Although the performance of the Herumi library is the best, the library is very complex and difficult to formally verify.

In January 2020, Supranational [a team of three ex-Intel veterans responsible for all hardware work on the VDF (Verifiable Delay Function) project, with whom I have weekly conference calls] told me they believed they could create A library that not only outperforms the Herumi library in performance, but also is more friendly to formal verification. For this reason, they also specially recruited Andy Polyakov. Andy Polyakov is an engineer specializing in high-performance cryptography with experience in formal verification.

In April 2020, the Ethereum Foundation and ProtocolLabs gave Supranational a grant to build a production-grade library and have the assembly implementation formally verified by the Galois team. In June 2020, the first version of BLST was launched with amazing performance. Over the next few months, ETH 2.0 clients integrated BLST as bonds were created and support for the integration gained. The ETH 2.0 client has been greatly improved in performance (see here and here for specific examples).

In 2020, one of the complicating factors we have to deal with is the revision of the draft IEFT standard. These modifications are largely out of our control. While these modifications are technically minor, they are operationally difficult because they require coordination among multiple parties. These changes created a lot of friction, sometimes requiring hours of discussion on the nuts and bolts (the details make the difference).