ACP-204: Precompile for secp256r1 Curve Support#204
ACP-204: Precompile for secp256r1 Curve Support#204avalanche-foundation-admin merged 2 commits intoavalanche-foundation:mainfrom
Conversation
|
|
||
| ## Motivation | ||
|
|
||
| The secp256r1 (P-256) elliptic curve is the standard cryptographic curve used by modern device security systems, including Apple's Secure Enclave, Android Keystore, WebAuthn, and Passkeys. However, Avalanche currently only supports secp256k1 natively, forcing developers to use expensive Solidity-based verification that costs 200k-330k gas per signature verification. |
There was a problem hiding this comment.
Where is the 200k-330k estimate from?
There was a problem hiding this comment.
There are a few smart contract based verifiers implemented, the following posts goes through each of the solutions and display how much each cost.
https://hackmd.io/@1ofB8klpQky-YoR5pmPXFQ/SJ0nuzD1T#Smart-Contract-Based-Verifiers
https://www.alchemy.com/blog/what-is-rip-7212#how-does-rip-7212-compare-to-other-solutions
|
|
||
| ## Specification | ||
|
|
||
| This ACP implements [EIP-7212](https://eips.ethereum.org/EIPS/eip-7212) for secp256r1 signature verification on Avalanche. The specification follows EIP-7212 exactly, with the precompiled contract deployed at address `0x0000000000000000000000000000000000000100`. |
There was a problem hiding this comment.
I think this will need to be a relatively standalone document, not reliant on something that can change in another ecosystem. EIP-7212 has already become RIP-7212 and the contents may change too.
There was a problem hiding this comment.
@ARR4N we should include the full technical specification directly in the ACP ?
There was a problem hiding this comment.
I think so. @meaghanfitzgerald knows best though. How much needs to be included in an ACP vs referenced?
|
|
||
| ### Core Functionality | ||
| - **Input**: 160 bytes (message hash + signature components r,s + public key coordinates x,y) | ||
| - **Output**: 32 bytes (success: `0x...01`, failure: empty) |
There was a problem hiding this comment.
Output: 32 bytes
This will be in the returndata buffer, which would typically be copied to memory and not the stack, so I don't think it's necessary to use an entire word as this increases the memory usage of the caller.
There was a problem hiding this comment.
Yes, I agree, but it breaks compatibility with other chains' EIP-7212 implementations.
Is this something we care about?
I understand that this should be a standalone document, so optimizing for efficiency makes sense.
There was a problem hiding this comment.
Good point. I'm in favour of ecosystem compatibility.
Do you know how many chains have implemented RIP-7212? With EIPs we always wait until they're live on Ethereum mainnet because then we know that it's a stable interface. I'd hate to release something, the rest of the ecosystem does something different, and we don't have shared tooling.
That said, we can always create a later ACP to add alternative interfaces if necessary. Same precompile, multiple ways to interact with it.
EDIT: I see that RIP-7212 is marked as final so we can consider the interface stable.
There was a problem hiding this comment.
Rollups are on their way to have this implemented.
Live
Proposed
Regarding Ethereum, I doubt it will soon be added, the community is very conservative when it comes to precompiles, you can go through the magicians forum, has a great discussion about it.
It does seem that the RIP-7212 is in Final status tho.
| ### Cryptographic Security | ||
| - The secp256r1 curve is standardized by NIST and widely vetted | ||
| - Security properties are comparable to secp256k1 (used by ECRECOVER) | ||
| - Implementation follows NIST FIPS 186-5 specification exactly |
There was a problem hiding this comment.
- Implementation follows NIST FIPS 186-5 specification exactly
Which implementation does? This one?
There was a problem hiding this comment.
Yes, and to be accurate, Go's implementation actually follows FIPS 186-3. But the P-256 curve itself is identical across FIPS 186-3, 186-4, and 186-5. The core mathematical parameters, signature verification algorithms, and implementation approach are the same.
I'm specifying we are using the version FIPS 186-3, as that's what the Go implementation uses.
|
|
||
| ### Implementation Security | ||
| - Signature verification (not recovery) approach maximizes compatibility with existing P-256 ecosystem | ||
| - No malleability check included to match NIST specification, but wrapper libraries should add this |
There was a problem hiding this comment.
Why? If every wrapper library adds it then every single one needs to be correct, instead of the precompile just being correct.
@yacovm please can you give an opinion?
There was a problem hiding this comment.
We most definitely enforce that signatures are in the lower order.
There was a problem hiding this comment.
Ah, the comment was about the ecrecover precompile. I thought we were referring to transaction signatures when discussing secp256k1.
sgtm.
|
|
||
| The implementation will build upon existing work: | ||
|
|
||
| 1. **EIP-7212 Reference**: The [go-ethereum implementation](https://github.com/ethereum/go-ethereum) of EIP-7212 provides the foundation |
There was a problem hiding this comment.
I can't find an implementation anywhere in their repo.
There was a problem hiding this comment.
Thanks. I see it's from an original here: https://github.com/ethereum/go-ethereum/pull/27540/files
Just noting so I don't later forget where it is.
scammi
changed the title
|
This repository requires signed commits. @scammi could you please force-push this branch to only include signed commits? See Signing Commits. |
Co-authored-by: Stephen Buttolph <stephen@avalabs.org>
## Why this should be merged Implementation for [ACP-204](avalanche-foundation/ACPs#204). ## How this works Implements [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md) and an additional `Pack(hash,r,s,key)` function with precompile-compatible output. ## How this was tested Unit tests including fuzzing, test case from the proposed but unmerged geth implementation, and vectors from [Project Wycheproof](https://github.com/C2SP/wycheproof).
6 participants
This ACP proposes implementing a precompiled contract for secp256r1 (P-256) signature verification on Avalanche's C-Chain and L1s/subnets. Modern devices use secp256r1 for secure hardware-based signing (Apple's Secure Enclave, Android Keystore, WebAuthn/Passkeys).
Currently Avalanche only supports secp256k1 natively, forcing expensive on-chain verification. This precompile makes device-native authentication practical for Web3 applications.