RollCall Breakout #3: Precompiles and the RIP Process

Happenings
1

As announced on RollCall #2, we are organizing a series of breakout calls each Wednesday. The third breakout call will be on RIP precompiles, using RIP-7212 as a concrete example. The intention is for these breakout calls to be optional additions to the monthly RollCalls, and aimed at bringing together the subset of teams interested in each particular topic.

Meeting Info

Agenda

  • current situation
    • RIP finalization
    • precompile address range
  • RIP-7212: next steps
  • open questions
    • RIP registry / L2 indication of support
    • progressive precompiles & alternatives
  • open discussion

Further discussion

Feel free to add comments here with further items of discussion

4 Likes
2

Taiko supports this RIP (and would love to see it on mainnet, it is critical for improving gas cost of our SGX proofs)

3

Notes

thegaram33 here’s a quick summary:

  • RIP-7212: adopted by Polygon (live on testnet), zkSync (ready, rollout ETA April), Optimism, Kakarot
  • Rollup registry wip: https://github.com/ethereum/RIPs/tree/rips_registry/registry. Chains that support an RIP on mainnet can be added here. Which chains → inclusion by default, we don’t want to define what a rollup is.
  • What if a rollup is not fully compliant with a RIP, e.g. changes gas schedule? Generally it would count as not implementing the RIP. Multi-dimensional fees might address this.
  • How to check if an RIP is implemented correctly? We could set up something similar to execution-spec-tests and reuse some of the testing setup from L1.
  • Devex issues around partial support for precompiles, devs need to ensure support on each L2 they deploy on. We could use progressive precompiles but that proposal is not compatible with the RIP address range. Suggestion by @yoavw: new precompile that would allow checking RIP support on-chain in a standard way

Recording

1 Like
4

Notes by Scroll:

https://x.com/scroll_zkp/status/1756490663246610849