Overview

Within the BridgeHub parachain runtime, our ethereum-beacon-client pallet depends on our fork of the milagro_bls crate for verifying BLS signatures created by the Sync Committee of the Ethereum Beacon Chain.

Specifically:

Every time there is a consensus update that provides a new sync committee, we deserialize the provided public keys into the key format required by Milagro BLS, using APIs provided by the same library.
We verify signatures for every consensus update

Our fork (diff) includes the following changes:

Implements scale-codec Encode and Decode traits on the PublicKey type, so that we can persist them in our runtime storage
A bunch of whitespace-only changes which we should actually revert - not sure how those got merged.

Dependency Tree

BridgeHub parachain runtime

Beacon Light Client pallet

Our Fork: https://github.com/Snowfork/milagro_bls (diff)

Upstream: https://github.com/sigp/milagro_bls

Actual low-level BLS primitives: https://github.com/sigp/incubator-milagro-crypto-rust/tree/057d238936c0cbbe3a59dfae6f2405db1090f474

Audit Coverage

This crate does not appear to be audited. According to the documentation:

WARNING: This library is a work in progress and has not been audited. Do NOT consider the cryptography safe!

Such a disclaimer is relatively common for bleeding-edge cryptographic libraries. Nevertheless, as it stands, there is no audit.

Other public usage of Milagro BLS

Lighthouse, the reference Ethereum client (In Ethereum terminology a client is actually responsible for on-chain consensus) has an optional dependency on milagro.

Its BLS module seems to be a thin wrapper that supports either Milagro or Supranational as the crypto backend. For example in

https://github.com/sigp/lighthouse/blob/441fc1691b69f9edc4bbdc6665f3efab16265c9b/crypto/bls/src/lib.rs#L142

However since only Milagro is marked as optional, we assume that Supranational is the default. Looking at the documentation for the latter, we see that it requires C and assembly, so it is not WASM-compatible.