Really like this one, especially if higher-order curves can be supported.
We actually used double scalar multiplication (Strauss-Shamir method) with 6 bits of precompute to implement on-chain verification of ECDSA signatures over 384-bit curves. Check out the Solidity code here (fuzz-tested and fully covered).
P.S.
Many national passport issuers use higher-order curves to sign off passports. I see this ZK research area benefiting a lot from a DSM precompile.
RIP7696 was wrote with 256 bits size in mind, but it is feasible to integrate a generic lib such as
GitHub - ANSSI-FR/libecc: Library for elliptic curves cryptography in nodes to handle any curve.
This implementation is already quite optimized, but handling 384 bit size as an overhead far superior to the theoreticall x4 factor (because infact double precision requires to handle 128 bits to enable double word on 256).
Take a look at the second operator of the RIP, enabling 4MSM would decrease the cost by 50% (which still let us with a 5 MB gas cost), 8 MSM by 75% (but requires 24kb of precomputed tables stored as contract).
Hi, really excited to see this kind of “framework” and “progressive” precompile for general usage.
having a small question when reading the spec, in mentioned the precompile takes 160k gas in RIPs/RIPS/rip-7696.md at 6261b59fed20e792ffe6e122c759944f2a2cc136 · ethereum/RIPs · GitHub.
Does the 160k gas result come from a self-implemented one instead of a precompile (with recommended ECMULMULADD_B4_COST of 2000 gas)?
also, the RIP mentions “Apple’s secure enclave uses ed25519”, while in the latest developer doc of Apple, it mentions secure enclave “works only with NIST P-256 elliptic curve keys”, this info in the RIP might be outdated.
Another question would be in this spec it mentioned “MSM would be superior, but the variable length and complexity of possible tradeoffs seems to reduce the probability of acceptance.” While I think it’s also worth opening the discussion for MSM (e.g. in another RIP), to be hands-on and see the difficulties, brainstorm and collect some usage cases, etc. any considerations about this?
@mralj and I spent some more time exploring the implementation approach for rollup-geth (GitHub - NethermindEth/rollup-geth: Fork of go-ethereum tailored for L2 Rollups) project. One of the issues we have faced with the implementation is that the majority of Go crypto libraries do not support generic curve implementation (Go std library, Gnark from Consensys, Circl from Cloudfare). For example, the standard Go library has completely deprecated the generic curve API (https://cs.opensource.google/go/go/+/refs/tags/go1.23.6:src/crypto/elliptic/params.go;l=12).
As as per my understanding there are two issues with supporting generic curves: a) Using a non-standard curve which has not been tested could lead to security risks b) Most operations on the standard curves have specific optimized implementations, which have also been well-tested. Thus all the standard crypto libraries in the Go ecosystem focus on providing APIs for specific elliptic curves. Moreover, if we do not use a battle-tested/audited crypto library within any precompile, it could leave potential security loopholes in the L1.
@rdubois-crypto Please let me know what do you think about these challenges, since currently the RIP focuses on generic curve implementation while it might be possible to provide support for specific curves safely.
a) The use of a non standard curve is like misusing ecrecover with a fixed nonce: not a problem of the precompile but of its use.
b) It is possible to use a custom curve in OpenSSL. I saw that some go implementation are instead using some mappings from C to go, would it be an acceptable way to do so ?
OpenSSL is a reference for crypto implementations. There is also libECC from the ANSSI which is a remarkable library that can be used with custom curves.