search

stellar / rs-soroban-env

Rust environment for Soroban contracts.
Apache License 2.0
60 stars 41 forks source link

Add host functions to support BLS digital signatures #781

Open tomerweller opened 1 year ago

tomerweller commented 1 year ago

BLS digital signatures are becoming increasingly popular due to their short signatures (relative to the level of security), efficient aggregation property and enabling simple threshold constructions. These are already implemented in some other blockchains such as the ethereum beacon chain and chia.

For Soroban this can enable various advanced authorization schemes for, amongst other things, multisig smart wallets and oracle constructions (as pointed out by chainlink in this blog post).

Most current implementations use the BLS12-381 elliptic curve, which has been proposed in https://github.com/stellar/rs-soroban-env/issues/779.

Questions

  1. Does anyone disagree?
  2. Do we actually need explicit host support for BLS Digital signatures? Depending on the host functions in https://github.com/stellar/rs-soroban-env/issues/779 it might be trivial to implement these on the guest side.
  3. What is the exact set of host functions required? should we introduce anything for threshold constructions or is that left to the contract developer to figure out?
  4. What implementation should we choose?

Note: if you're confused (as I was) about the relationship between BLS digital signatures and the BLS12-381 elliptic curve this is a good starting point.

kwantam commented 1 year ago

As you guessed @tomerweller, if you implement the host functions from #779 (including the full hash-to-curve functionality; see my comment in that thread), it will be more or less trivial to add BLS signatures support on top.

For threshold constructions, the most important thing is the ability to do relatively efficient field and group operations. The host functions in #779 already give the required group operations. What's required here is polynomial interpolation, so you'll need field ops in the scalar field of the curve (for BLS12-381, that's a 255-bit field). Adding anything beyond this as host functions probably isn't needed: it should be fine to implement Lagrange interpolation in a smart contract given efficient scalar and group operations.

I'd stick with blst for the implementation, as I mentioned in #779.