Following the RIP merge, the address range for the RIP precompiles has been set to 0x100+ (ACDE#177 as reference) and as the first precompile as RIP, P256VERIFY will have 0x100 address (indicates 0x00...00100).
Last Call deadline is 2 weeks from now, until the 4th of January. Then, the proposal will be moved to the Final status and be ready for any implementations by rollups.
Wow. Two months after I wrote this, the Ledger wallet JS got hacked in the exact way that this would have prevented
As a web developer for over a decade I definitely can say that having sandboxed iframes with postMessage, and subresource integrity, mitigates most of the XSS attacks inside those iframes. So if you as a web developer place such an iframe on your webpage, with SRI, then any code that loads inside it (cached or not) can be trusted, as long as some third parties have vetted that SRI hash. That is currently the only way to ensure reliable security on the open web.
@ulerdogan what about layer 1 blockchains like Ethereum Mainnet, Polygon, Binance Smart Chain, etc. ? This is only for rollups and Layer2s?
It’s dependent on the governance mechanisms for every L1 or L2 chain.
Hello everyone! I’d like to express massive support for this EIP!
Wanted to share that some months back I also wrote an implementation of a P256 verifier in Huff Language. I implemented it from Daimo’s implementation and made some optimisations to it to bring down its costs to the range of 228k - 250k gas. This implementation has the same interface as Daimo’s too and passes all their tests too. It is currently deployed on Ethereum’s and Base’s Goerli and Sepolia testnets at 0x00000083Ea3aBb243c4acfDB095DB5aD5A606fc5.
For anyone interested, you can check out the code and tests here:
The PR which applies the last changes and announces Last Call deadline has been merged. The new Last Call deadline is January 10.
There is a push towards multi-proofs in rollups, SGX in particular is a prime candidate:
Having this precompile would solve a big gas cost headache and enable SGX verification without relying on Intel chain of trust.
I wasn’t aware of this use case that EIP-7212 could enable and yes, it is obvious that multi prover rollups could use this precompile. Thanks for the contribution!
As of this PR, RIP-7212 has reached to the Final status and became the first finalized RIP. Now, it’s guaranteed that there will be no changes in the specs and the proposal is ready to be implemented by any chain.
Please check my reference implementation for go-ethereum:
RIP-7212 is live on Polygon Testnet.
You can try it yourself:
Hi everyone,
I was wondering if there are any implementation tricks that can programmatically check if RIP-7212 is live within a specific L2. I believe some longer-term ideas were discussed in the RollCall #2.3 meeting that would address this (e.g. progressive precompiles, or a precompile that itself returns information about which precompiles are active on a chain). However, I believe RIP-7212 will be live before some of these.
The best solution I can think of is to hardcode a call to the precompile with a signature that’s already known to be correct, and then the precompile is live iff bytes32(1) is returned. Does this seem like the best implementation that’s currently possible? Preferably it’d be possible to tell if the precompile is live regardless if a signature is valid or not. However, I believe a call to the RIP-7212 precompile with an invalid signature will return no data, which is equivalent to calling an address with no code/precompile, so it’s difficult to distinguish whether the precompile exists or not in this case.
Hello Riley! Yes, there is no progress on the onchain registry idea. Also, I agree with you that it looks like the most ideal way to understand if precompile exists.
I understand RIP-7212 is not yet live on the Ethereum Mainnet? Do we expect this to happen soon? Or is there any rough estimate as to when it will be?
As an RIP, the proposal has not been planned for the Ethereum mainnet yet. It can be considered in the future.
With the Napoli Hard Fork in the Polygon PoS Chain, RIP-7212 is active on the mainnet. Congrats to the team for being the first to implement an RIP on the mainnet.
Do you guys have a code snippet on how to implement it onchain in Solidity? Thank you
Fastest implementation is here
Actually i’m still working on it and will push a version around 160K in April which will go to an audit.
You can easily adapt this script to bench extra libraries ONCHAIN (this one demonstrate benching of daimo and FCL). (it is easy to forgot to configure toml effectively, or cancel stack optimization).
Thanks for sharing additional resources @rdubois-crypto!
Also, sharing basic wrapper contract to call the precompile contract.
/**
* @notice Calls the verifier function with given params
* @param verifier address - Address of the verifier contract
* @param hash bytes32 - Signed data hash
* @param rs bytes32[2] - Signature array for the r and s values
* @param pubKey bytes32[2] - Public key coordinates array for the x and y values
* @return - bool - Return the success of the verification
*/
function callVerifier(
address verifier,
bytes32 hash,
bytes32[2] memory rs,
bytes32[2] memory pubKey
) internal view returns (bool) {
/**
* Prepare the input format
* input[ 0: 32] = signed data hash
* input[ 32: 64] = signature r
* input[ 64: 96] = signature s
* input[ 96:128] = public key x
* input[128:160] = public key y
*/
bytes memory input = abi.encodePacked(hash, rs[0], rs[1], pubKey[0], pubKey[1]);
// Make a call to verify the signature
(bool success, bytes memory data) = verifier.staticcall(input);
uint256 returnValue;
// Return true if the call was successful and the return value is 1
if (success && data.length > 0) {
assembly {
returnValue := mload(add(data, 0x20))
}
return returnValue == 1;
}
// Otherwise return false for the unsucessful calls and invalid signatures
return false;
}
Check out the interesting conversation with @ulerdogan on the present Signature scheme, special Elliptic Curves & a deep dive inside EOA while providing the overview of RIP7212 on PEEPanEIP
