Add host functions to support BLS12-381 #1427
Conversation
init
added motivation, abstract, encoding.
added specification
formatting
supporting docs for bls cap
…tes.md implementation details
added link to fp-c mapping
added link to supporting docs
updated spec
| #### Addition in G1 | ||
|
|
||
| ```rust | ||
| fn bls12_g1add( e: &Host, p0: BLST_G1_POINT, p1: BLST_G1_POINT) -> Result <BLST_G1_POINT, Error>; |
There was a problem hiding this comment.
BLST_G1_POINT is not a type, what is this signature supposed to mean?
While it's probably not important for the discussion, if we want to merge this, we should make it consistent with the host function specifications we have.
https://github.com/stellar/rs-soroban-env/blob/main/soroban-env-common/env.json can be used as a general reference. Some quick notes:
- There is no need to specify the
&Hostargument. - There is no need to declare the return type as
Result, just use the return value - There is no
u8type supported; minimal integer type isU32Val. - Slices can't be passed to the host functions; use
BytesObjectinstead (the length of the bytes object is just a part of the protocol specification, but can't be reflected in the function signature)
There was a problem hiding this comment.
Agree with @dmkozh.
I would suggest following https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-03.md on host function definition format. The host functions are written in WAT (WebAssembly Text) format because that (not Rust, or Json) is what is exposed to the WASM contracts.
There was a problem hiding this comment.
While WAT might be ok for bulk definitions we had in the protocol 20, I would prefer to also have a definition in terms of env-common types (used in env.json) - while these functions are not type-checked on the Wasm side, they are type-checked on the host-side, so it would make sense to specify what should be the signature. It is also easier to understand for the reader, which is important given that hopefully future CAPs will be focused on small sets of functions.
There was a problem hiding this comment.
env.json sounds good, i don't feel strongly either way
| Arguments: | ||
| p_g1: point in G1(96 bytes) | ||
| p_g1: point in G1(192 bytes) | ||
| Returns padded 0x01 if pairing is successful else 0x00. |
There was a problem hiding this comment.
Why not return Bool instead?
| ``` | ||
| Perform addition of two points in G1. | ||
| Inputs should be 96 bytes each. | ||
| An error will be thrown if neither input is in G1, input has invalid length, or encoding rules are violated. |
There was a problem hiding this comment.
We don't return any errors actually - the host functions just trap in case of an error.
| #### Map Base Field Element to G1 | ||
|
|
||
| ```rust | ||
| fn bls12_map_fp_to_g1( e: &Host, fp: &[u64]) -> Result <BLST_G1_POINT, Error>; |
There was a problem hiding this comment.
Why do we have two variants of the same 'map' function that seemingly take the same input? I think we should only need one version, that either takes a U64Val, or BytesObject, depending on which case is more useful.
| ``` | ||
| ### Curve Operations | ||
|
|
||
| #### Addition in G1 |
There was a problem hiding this comment.
It seems like there is a lot of redundancy in this interface. E.g. we could reduce the number of functions by 2 times if we take g1/g2 as an input bool parameter to functions instead of having duplicate functions for every operation.
| This section describes the composition of the working group. | ||
|
|
||
| ## Motivation | ||
| BLS12-381 host functions allow for cryptographic operations in the Soroban execution environment that are otherwise prohibitively expensive. It enables a variety of applications including confidentiality preserving systems, BLS signature schemes, and multiple types of scaling solutions. Pairing-friendly elliptic curves are needed for such systems and BLS12-381 is the state of the art in secure elliptical curves. |
There was a problem hiding this comment.
I would add a note about the motivation of using BLS12-381 as opposed to BN254
|
What are your thoughts on exposing a generic interface for pairing friendly curves? That is, instead of One reference would be the algebraic interfaces defined in arkworks. There is a large family of curves, including 2-chain curves (which have applications to Rollups), that can be exposed via the same interface. |
|
This pull request is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed. |
This CAP proposes adding support for BLS12-381 elliptical curve to enable advanced zero knowledge proof systems including privacy preserving constructions and zkrollups. The Soroban ecosystem has already expressed interest in these type of systems.
Next steps:
Issue: stellar/rs-soroban-env#779
PR (in progress): stellar/rs-soroban-env#1310