expose BLS12-381 precompiles on FVM

[CluEleSsUK]

Abstract

BLS12-381 is a pairing-friendly elliptic curve construction most often used for threshold signature schemes. It is currently underpins the addresses used by the Filecoin network, as well as being the core primitive of the drand network (drand beacons are BLS12-381 signatures).

This discussion is a proposal to include all the necessary BLS12-381 precompiles for use on the FVM.

Motivation

In terms of use cases, this opens up:

• blinded on-chain voting (via timelock decryption)
• wallet recovery
• custom drand networks (through verification of arbitrary BLS signatures within smart contracts)
• threshold decryption oracles
• novel on-chain distributed key generation protocols
  and probably a lot more!

While it is possible to implement BLS12-381 in solidity, operations such as pairing are extremely expensive in terms of gas. Providing precompiles would make their use viable for smart contracts.

As the FVM is EVM-compatible, it already supports the BN256 curve for threshold operations, though BN256 has long been considered to provide insufficient security (~96bits).
In Ethereum-land, there is an EIP for BLS12-381 already, though it is long stagnant. Providing precompiles for it on the FVM could be a key differentiator driving users to build on the FVM rather than other platforms.

Considerations

Two routes to implementation exist:

1. precompiles defined for EVM.
   These are much simpler as they only require updating a single builtin actor.
2. syscalls added to the FVM.
   These require a little more fiddling (and possibly a fully fledged FIP), but would likely be a lot faster than actor code.

The interface is an important consideration. By and large, a copy of the interface for BN256 precompiles for EVM would be sufficient for most usage. Some additional calls for hash_to_curve (see: https://eips.ethereum.org/EIPS/eip-3068 and https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html) could be helpful for use cases such as identity-based encryption (though it's unclear if that's actually useful on a public blockchain).

A possible library for the ref-fvm implementation is ZKCrypto's bls12_381 crate. It doesn't require C bindings so should be appropriate.

[anorth]

Sounds good to me! (As VM syscalls)

[CluEleSsUK]

What are next steps for making this happen? There hasn't been a lot of discussion here, but so far 100% of commenters are in favour :^)
Does it require a formal FIP?

[willscott]

@Stebalien - would you be the right person to think about practicality/timing of an implementation for this?

How close are we to underlying wasm execution? that could partially reduce the need for this, although precompiles will as i understand it still be useful for squeezing out additional performance.

[anorth]

Yes it requires a FIP. The instigators of a proposal (who become FIP authors) are generally responsible for taking action. I suggest drafting a FIP.

[nikkolasg]

Yes, 100 % ! And with support for GT operations, that would enable to verify things like snarkpack :)

[AnomalRoil]

I support this as well. Notice that hash_to_curve now has an official RFC and isn't a draft anymore:
https://datatracker.ietf.org/doc/rfc9380/

In general this would allow for identity-based encryption on-chain in general, which would be cool.

I would recommend implementing generic BLS12-381 functions, which would allow for hash to curve on both G1 and G2, since both have different advantages for implementers.

When it comes to dependencies, Filecoin already depends on it anyway, right? So this would just be about exposing it to the FVM.