Skip to content

Latest commit

 

History

History
119 lines (84 loc) · 5.53 KB

0030-update-threshold-cryptography.md

File metadata and controls

119 lines (84 loc) · 5.53 KB
Raw

HIP-30: Switch to BLS12-381 for Threshold Cryptography

  • Author(s): @vihu, @Vagabond, Helium Systems, Inc. team
  • Start Date: 2021-04-19
  • Category: Technical
  • Original HIP PR: #155
  • Tracking Issue: #158

Summary

Helium Distributed Key Generation and Honeybadger Consensus Protocol both rely on curve SS512 for pairing-based cryptography. Curve SS512 is considered a very old curve and is not commonly used. In addition, the library we use for pairing-based cryptography, Ben Lynn's pbc library, has not seen major maintenance since 2013.

This HIP proposes switching to an industry standard curve BLS12-381 for doing threshold cryptography. The underlying implementation for BLS12-381 is security-audited, faster, and more secure than curve SS512.

We have been testing a new threshold cryptography library that has been in use on the Validator Testnet for several weeks and believe it is ready for Mainnet.

Motivation

There are several good reasons to switch to curve BLS12-381 from the existing curve SS512:

  • BLS12-381 targets 128 bits of security, however actual security level of the curve is estimated between 117-120 bits. This is still significantly higher than the 80 bits that SS512 provides.
  • BLS12-381 is notably faster than SS512 at polynomial multiplication.
  • BLS12-381 provides primitives for exotic cryptography functions such as digital threshold signatures and aggregate signatures.
  • Implementing BLS12-381 creates a potential to increase the number of Consensus Group and DKG members.
  • Several existing protocols like Zcash, Ethereum 2.0, Skale, Algorand, Dfinity, Chia, etc use BLS12-381 to perform digital signatures and threshold cryptography.

Stakeholders

This change should not affect any current Hotspot owners or HNT holders as it is a purely backend change to the network.

Detailed Explanation

The explanation of curve BLS12-381 itself is beyond the scope of this HIP. However, Ben Edgington provides an excellent explanation of how the curve works.

An outline of the changes required to make BLS12-381 work with the Helium network looks like the following:

  • Add support for understanding BLS12-381 curve in Erlang

    The team has been building a compatibility layer erlang-tc to use in Erlang for poanetwork/threshold_crypto which provides bindings to BLS12-381 curve functions. The Rust code has been security audited.

  • Add support for BLS12-381 based threshold cryptography to DKG

    In parallel, the team has been working on adding BLS12-381 compatibility to erlang-dkg. This work has been done in erlang-dkg#36.

  • Add support for BLS12-381 based threshold cryptography to HBBFT

    The team has also been working on adding BLS12-381 compatibility to erlang-hbbft. The progress of this work is available in hbbft#66.

  • Update miner to use new HBBFT and DKG

    In order to make the switch to BLS12-381, the team has implemented a miner compatibility layer, the progress of which can be followed in miner#733.

Drawbacks

We don't believe there are any drawbacks to this approach. In fact, we believe that this work is absolutely critical to ensure that the Helium network follows the latest industry security standards to remain competitive.

Rationale and Alternatives

We were unable to expand the Testnet Consensus Group past 40 nodes as elections would begin to fail around that group size. We found that the existing DKG with curve SS512 is the primary culprit here. This becomes a greater risk to network security as the network grows to 100s of thousands of nodes and more users expect network stability and security.

On the Testnet, with these changes, we were able to exceed a group size of 60 and are able to run stably with a group size in the mid 50s. Since these protocols do not scale linearly (it's more like cubic scaling), this is a significant improvement.

We don't believe that the alternative of doing nothing makes sense either. We also would like to avoid creating a new library ourselves and haven't been successful in finding an an acceptable alternative that meets all of our criteria.

We believe this library and this implementation is the best choice for the Helium network as it has already been written and has passed a security audit.

Unresolved Questions

None

Deployment Impact

We've written a compatibility layer that allows HBBFT to handle either kind of key. The network will continue to use the current SS512 key during an upgrade to BLS12-381. Once all nodes are updated with the new DKG, elections will start producing BLS12-381 keys and HBBFT will seamlessly switch over to using them instead.

Thus, we do not expect any deployment impact beyond a potentially long election epoch as the network upgrades.

Success Metrics

The upgrade will be considered successful if it continues to support the number of Hotspots coming online in the coming months and years. It will also be successful if we are able to increase the Mainnet Consensus Group size and improve network security.