|
| 1 | +--- |
| 2 | +fip: "0105" |
| 3 | +title: BLS12-381 Precompiles for FEVM (EIP-2537) |
| 4 | +author: "Aarav Mehta (@aaravm), Michael Seiler (@snissn)" |
| 5 | +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1135 |
| 6 | +status: Draft |
| 7 | +type: Technical |
| 8 | +category: Core |
| 9 | +created: 2025-04-11 |
| 10 | +--- |
| 11 | + |
| 12 | +# FIP-0105: BLS12-381 Precompiles for FEVM (EIP-2537) |
| 13 | + |
| 14 | +## Simple Summary |
| 15 | +This proposal introduces precompiles in the FEVM for efficient cryptographic operations on the BLS12-381 elliptic curve, as defined in EIP-2537. These enable fast BLS signature verification and aggregation, improve Ethereum compatibility, and unlock advanced cryptographic use cases on Filecoin. |
| 16 | + |
| 17 | +## Abstract |
| 18 | +This FIP proposes the addition of precompiled functions in the FEVM to support BLS12-381 curve operations, matching the functionality defined in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). These precompiles enable point addition, multi-scalar multiplication (MSM), field-to-curve mapping, and pairing checks, facilitating secure and performant BLS signature schemes. This enhancement increases the cryptographic capabilities of FEVM and aligns with Ethereum ecosystem standards. |
| 19 | + |
| 20 | +## Change Motivation |
| 21 | +BLS12-381 precompiles are essential for supporting cryptographic primitives that require high security (≥120-bit) and efficient signature aggregation. These operations are fundamental to threshold signatures, decentralized identities, zk-rollups, and consensus mechanisms. Currently, the FEVM lacks native support for BLS12-381 operations, creating a performance and compatibility gap with Ethereum-based applications and protocols that rely on this curve. This FIP bridges that gap, bringing parity with Ethereum and enabling new cryptographic use cases on Filecoin. |
| 22 | + |
| 23 | +## Specification |
| 24 | +This FIP proposes the addition of precompiled contracts to support elliptic curve operations over BLS12-381, fully aligned with the functionality and encoding rules defined in EIP-2537. The included precompiles enable essential cryptographic primitives—such as point addition, multi-scalar multiplication, field-to-curve mapping, and pairing checks—using the BLS12-381 curve. |
| 25 | + |
| 26 | +The following precompile addresses are proposed: |
| 27 | + |
| 28 | +| Operation | Address | Description | |
| 29 | +|---------------------------|---------|-------------------------------------------------| |
| 30 | +| `BLS12_G1ADD` | `0x0b` | Adds two G1 points (128-byte input, 64-byte each) | |
| 31 | +| `BLS12_G1MSM` | `0x0c` | Multi-scalar multiplication over G1 | |
| 32 | +| `BLS12_G2ADD` | `0x0d` | Adds two G2 points | |
| 33 | +| `BLS12_G2MSM` | `0x0e` | Multi-scalar multiplication over G2 | |
| 34 | +| `BLS12_PAIRING_CHECK` | `0x0f` | Performs a pairing check over (G1, G2) pairs | |
| 35 | +| `BLS12_MAP_FP_TO_G1` | `0x10` | Maps an Fp element to a point in G1 | |
| 36 | +| `BLS12_MAP_FP2_TO_G2` | `0x11` | Maps an Fp2 element to a point in G2 | |
| 37 | + |
| 38 | +Each operation uses the same ABI and data layout as described in EIP-2537, including: |
| 39 | +- **Big-endian byte encoding** of points, scalars, and field elements. |
| 40 | +- **Subgroup checks** where required (e.g. for MSMs and pairings). |
| 41 | +- **Canonical encoding and validation rules** for input field elements. |
| 42 | +- **Deterministic failure modes** on malformed input (e.g. invalid length, non-curve points). |
| 43 | + |
| 44 | +The implementation ensures full compatibility with Ethereum tooling and semantics, enabling cross-chain cryptographic applications and reuse of existing test vectors and infrastructure. |
| 45 | + |
| 46 | +## Design Rationale |
| 47 | +This proposal adopts Ethereum’s EIP-2537 to ensure compatibility with existing tooling and cross-chain applications. By aligning with Ethereum’s design and ABI, developers can reuse BLS-based libraries and workflows without modification. |
| 48 | + |
| 49 | +The inclusion of MSM and field-to-curve mapping operations as precompiles supports important cryptographic use cases such as BLS signature aggregation, zero-knowledge proof systems, L2 subnet consensus, aggregate proofs, and decentralized identity protocols. Exposing these operations as precompiled contracts ensures correctness, consistent validation behavior, and alignment with protocol-layer cryptographic expectations. |
| 50 | + |
| 51 | +## Backwards Compatibility |
| 52 | +This FIP introduces new precompile addresses and does not affect existing contract behavior. Contracts not using these addresses remain unaffected. The precompiles are fully opt-in and backwards-compatible. |
| 53 | + |
| 54 | +## Test Cases |
| 55 | +A comprehensive test suite accompanies this proposal to ensure the correctness, safety, and conformance of the BLS12-381 precompiles with [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). Tests are divided into success, failure, and edge-case categories, each validating specific behaviors under both standard and adversarial inputs. |
| 56 | + |
| 57 | +### **Success Case Coverage** |
| 58 | + |
| 59 | +These verify correctness and adherence to cryptographic properties: |
| 60 | + |
| 61 | +#### **G1ADD / G2ADD** |
| 62 | +- Point addition with valid G1/G2 inputs |
| 63 | +- Addition with identity point (0) |
| 64 | +- Doubling (`P + P`) |
| 65 | +- Subtraction (`P + (-P)` → 0) |
| 66 | +- Commutativity checks |
| 67 | + |
| 68 | +#### **G1MSM / G2MSM** |
| 69 | +- Weighted sums with valid `(point, scalar)` pairs |
| 70 | +- Scalars: `0`, `1`, and random values |
| 71 | +- Mix of valid points, including points at infinity |
| 72 | +- Multiple pairs and varying lengths |
| 73 | + |
| 74 | +#### **MAP_FP_TO_G1 / MAP_FP2_TO_G2** |
| 75 | +- Mapping various valid field elements (from clean byte strings) |
| 76 | +- Verifies resulting points lie on curve and in correct subgroup |
| 77 | + |
| 78 | +#### **PAIRING** |
| 79 | +- Pairing identity: `e(0, 0) = 1`, `e(P, Q) * e(P, -Q) = 1` |
| 80 | +- Bilinearity: `e(aP, bQ) = e(P, Q)^{ab}` |
| 81 | +- Zero contributions: `e(P, 0) = e(0, Q) = 1` |
| 82 | +- Multi-pair checks validating associativity and multiplicative accumulation |
| 83 | +- Mix of G1 and G2 in normal and negated forms |
| 84 | + |
| 85 | +### **Failure Case Coverage** |
| 86 | + |
| 87 | +These verify rejection of malformed, incomplete, or semantically invalid inputs: |
| 88 | + |
| 89 | +#### **General Input Errors (All Opcodes)** |
| 90 | +- Empty input |
| 91 | +- Short input |
| 92 | +- Extra bytes (long input) |
| 93 | +- Invalid top bytes |
| 94 | +- Field elements with illegal encodings |
| 95 | +- Invalid curve points |
| 96 | +- Point not in correct subgroup |
| 97 | +- Mismatched input sizes (e.g., unaligned MSM pairs) |
| 98 | + |
| 99 | +### **Edge Case Behaviors (Covered across modules)** |
| 100 | +- Point at infinity as operand in MSM or pairing |
| 101 | +- Scalar = 0 in MSM (yields zero contribution) |
| 102 | +- Double vs. add equivalence in G1ADD/G2ADD |
| 103 | +- Mixed representations and ordering (commutative symmetry) |
| 104 | +- Subgroup validation logic invoked only *after* full field element validation |
| 105 | + |
| 106 | +This comprehensive suite ensures correct implementation of the BLS12-381 arithmetic under realistic usage and malicious input conditions, supporting conformance with EIP-2537. |
| 107 | + |
| 108 | +### Solidity-Based Tests (Planned) |
| 109 | + |
| 110 | +While Rust-based unit tests validate core functionality, Solidity-based integration tests are planned to ensure end-to-end compatibility within the FEVM execution environment. |
| 111 | + |
| 112 | +## Security Considerations |
| 113 | + |
| 114 | +This FIP introduces a set of precompiled contracts to perform cryptographic operations over the BLS12-381 elliptic curve, consistent with Ethereum’s [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). These include G1/G2 addition, multi-scalar multiplication (MSM), mapping from field elements to curve points, and bilinear pairing checks. The implementation uses the audited `blst` library (Supranational) for cryptographic primitives and mirrors the design and operational constraints of the Ethereum specification. |
| 115 | + |
| 116 | +### Surface and Context |
| 117 | + |
| 118 | +The BLS precompiles expose powerful cryptographic primitives used in aggregate signature verification, threshold cryptography, and zero-knowledge systems. As such, correctness and safety are critical. These operations act on untrusted input and therefore must defend against malformed data, invalid encoding, and subgroup-related attacks. |
| 119 | + |
| 120 | +### Threat Model and Risks |
| 121 | + |
| 122 | +The following threat vectors and risk areas are addressed: |
| 123 | + |
| 124 | +#### 1. **Curve Membership and Subgroup Checks** |
| 125 | +- Operations involving scalar multiplication and pairings **must** perform subgroup checks to prevent cofactor-related attacks and ensure that only points in the prime-order subgroups are used. |
| 126 | +- Our implementation adheres to the subgroup-check requirements laid out in EIP-2537, applying them **after** curve membership and field validity checks to ensure consistency and avoid leaking information about malformed inputs. |
| 127 | + |
| 128 | +#### 2. **Input Validation** |
| 129 | +- All precompiles validate the length and structure of input bytes prior to deserialization. |
| 130 | +- Inputs failing length checks, field modulus checks, or invalid encoding formats are rejected early with clear failure paths. |
| 131 | +- Particular care is taken in mapping precompiles to avoid processing non-canonical field elements or incorrect byte representations. |
| 132 | + |
| 133 | +#### 3. **Point at Infinity Handling** |
| 134 | +- All operations explicitly handle identity elements and correctly return zero points where expected (e.g., scalar multiplication by zero, or adding a point to its negation). |
| 135 | +- Pairings involving points at infinity are treated as identity elements but still undergo validation to ensure that no malformed input is accepted. |
| 136 | + |
| 137 | +#### 4. **Error Handling and Deterministic Fails** |
| 138 | +- The implementation provides deterministic and transparent error behavior for all malformed inputs. |
| 139 | +- Inputs that are malformed in ways that could lead to unpredictable behavior (e.g., truncated input, invalid field elements) result in failure with no side effects. |
| 140 | + |
| 141 | +#### 5. **Compatibility and Cross-Chain Consistency** |
| 142 | +- Matching Ethereum’s EIP-2537 ensures consistency for cross-chain cryptographic applications and tooling. |
| 143 | +- Test vectors and behaviors are aligned with Ethereum’s reference implementation to support shared ecosystem tooling and audits. |
| 144 | + |
| 145 | +### Implementation Safeguards |
| 146 | + |
| 147 | +- The implementation includes extensive unit tests covering edge cases, invalid inputs, and critical functional properties (e.g., bilinearity of pairing, subgroup correctness). |
| 148 | +- All tests are built against known-good vectors and checked for conformance against Ethereum-compatible expectations. |
| 149 | +- The use of precompiles restricts these operations to controlled execution contexts, reducing the attack surface compared to userland implementations. |
| 150 | + |
| 151 | +## Incentive Considerations |
| 152 | +Enabling efficient BLS operations enhances support for use cases like decentralized storage verification, threshold signing, and zk-rollup integration. These use cases directly improve Filecoin’s reliability, performance, and application ecosystem. While no direct protocol incentive changes are introduced, better cryptographic primitives contribute to Filecoin’s long-term network utility. |
| 153 | + |
| 154 | +## Product Considerations |
| 155 | +BLS precompiles improve developer experience by enabling advanced applications (e.g., zk-proof aggregation, BLS-based voting, and signature-based storage proofs). This upgrade positions Filecoin as a capable and attractive platform for cryptographically advanced dApps and aligns with emerging Ethereum tooling standards. |
| 156 | + |
| 157 | +## Implementation |
| 158 | +Reference implementation will be integrated into the `builtin-actors` FEVM runtime. A pull request with a working precompile set and test coverage can be viewed [here](https://github.com/filecoin-project/builtin-actors/pull/1669). |
| 159 | + |
| 160 | +## TODO |
| 161 | +- Implement Solidity-level integration tests in FEVM test suite. |
| 162 | + |
| 163 | +## Copyright |
| 164 | +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
| 165 | + |
| 166 | + |
| 167 | + |
0 commit comments