Earlier This Year, We launched a Bug Bounty Program focusing on the identification of potential issues in client implementations or beacon chain specifications (Lighthouse, Nimbus, Teku, Prysm, etc.). The results (and vulnerability report) were insightful, and provided valuable lessons for fixing any potential problems.
In This series, we will share some of our lessons learned in our security work and help us move forward.
This first post will focus on submissions that are specifically related to BLS primitives.
Disclaimer: All of these bugs have been resolved.
BLS is Everywhere
It was just a few decades ago that Diego F. Aranha attended the 21st Elliptic Curve Cryptography Workshop with the title: Pairings You Ain’t Gone. How prophetic.
Now, here in 2021, pairings are one of many key players in various cryptographic primitives utilized in the blockchain (and beyond). BLS signatures, ZK SNARKs systems, etc.
Ethereum Foundation researchers have been involved for some time in standardization work related to BLS signatures. This is partially driven by Justin Drake as outlined in a recently published blog post.
The Latest and Greatest
Since then, there have been many updates. BLS12-381 has now been universally accepted as the designated pairing-friendly curve to be used in the basis of our current knowledge.
Currently, three different drafts for the IRTF are being developed:
- Pairing-friendly curves
- BLS signatures
- Hashing to elliptic curves
Also, the beacon chain specification has now been partially deployed and is nearing maturity. As mentioned above, BLS signatures are an integral component of proof-of-stake (PoS), as well as the beacon chain.
Recent Lessons Learned
<
