BLS Signatures and the Ethereum 2.0 Story
Original title: "Introduction | BLS signature and the story of Eth2.0"
Original source: Ethereum enthusiasts
It has been about 2.5 years since ETH 2.0 adopted BLS signature technology, here are some milestones.
In May 2018, I published an article on ethresear.ch stating that BLS signatures could allow ETH 2.0 achieves a minimum pledge mechanism of 32 ETH and 1024 shards, which can increase the degree of decentralization and scalability by several orders of magnitude.
In October 2018, I wrote to Dan Boneh (cryptography advisor to the Ethereum Foundation) that: "We are considering following the example of Zcash and Chia and using the BLS12-381 curve in ETH 2.0." In response, he replied: "(Based on our current knowledge) the BLS12-381 curve is the correct choice." For context, a 2016 paper dropped 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 calling. 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 for BLS12-381 in this article Curve Hash. 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 (e.g. choosing generators and point serialization) is done by Zcash.
In September 2019, Carl Beekhuizen wrote three EIPs (2333, 2334, 2335) Standardize BLS on aspects other than the standard, such as quantum-safe backups, HD wallets (hierarchical deterministic wallets), keystores, 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 fastest implementation of the Herumi library so far) after being introduced 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.
January 2020, Supranational【The team consists of three ex-Intel Delay function) project, I have weekly conference calls with them] told me that they believe they can create a library that is not only better than the Herumi library in performance, but also more friendly to formal verification. To this end, 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 went live 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).
In September 2020, the BLST library was handed over to the Galois team. At the same time, formal verification has made significant progress. Also in September, Danny (again with ProtocolLabs) wrote an RFP requesting an audit of BLST's binding (which is not formally verified) and compilation (which is not 100% formally verified). The audit was carried out by NCC Corporation and started in October. The NCC is expected to complete the binding audit within a few weeks.
All in all, it was certainly a long and tortuous process involving early research, cryptanalytic security, standardization, performance, formal verification and auditing. Every step we take is an effort to move in the right direction, not to take shortcuts. As I said in this tweet, we are increasing the difficulty of implementing Ethereum 2.0, giving up the shortcuts that could have been taken, and pursuing long-term quality.
I hope the above has given you an idea of the amount of work we have put into moving in the right direction, such as I expected more in 2018. I think everyone who pays attention to ETH 2.0 is committed to promoting ETH 2.0 to be created as scheduled in 2020. Get your collateral ready :)
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
