Execution Layer Meeting 177

[timbeiko]

Meeting Info

• Dec 21, 2023, 14:00-15:30 UTC
• Youtube Stream: https://youtube.com/live/7amkZxKobX4
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Dencun Updates
  • Goerli Shadow Fork
  • Next Steps
• Precompile address ranges
• Next ACD & Testing call times
• Prague/Electra Proposals

[timbeiko]

For easy reference, in the case where we want to consider setting a Goerli date prior to the holidays, here are the decently-timed mid-week slots in January that correspond to accumulator boundaries (thanks, Adrian!):

Epoch	Start Slot	UTC	Moscow	Los Angeles	New York	Brisbane
234496	7503872	2024-01-29 18:54:24	2024-01-29 21:54:24	2024-01-29 10:54:24	2024-01-29 13:54:24	2024-01-30 04:54:24
233472	7471104	2024-01-25 05:40:48	2024-01-25 08:40:48	2024-01-24 21:40:48	2024-01-25 00:40:48	2024-01-25 15:40:48
231680	7413760	2024-01-17 06:32:00	2024-01-17 09:32:00	2024-01-16 22:32:00	2024-01-17 01:32:00	2024-01-17 16:32:00
230400	7372800	2024-01-11 14:00:00	2024-01-11 17:00:00	2024-01-11 06:00:00	2024-01-11 09:00:00	2024-01-11 00:00:00

[adietrichs]

@CarlBeek and I would like to briefly talk about precompile address range(s) in light of the recently started RIP (rollup improvement proposal) process.

In particular, in the future many new EVM precompiles will be introduced on (some or all) L2s first, and for that will go through the RIP standardization process. They then might or might not later also be shipped to L1. It would be highly desirable to come up with a precompile address scheme that ensures that the address for any given RIP precompile

• is reserved on L1, meaning that no other conflicting precompile is ever introduced on that address
• is used for that RIP precompile, if it is ever introduced on L1 in identical form.

This will necessarily lead to a situation where the EVM precompile range will no longer be continuous, i.e. that there will be gaps between precompiles. The two main options we see:

• option A: RIP precompiles use the same general range, using the "next available" address when they are about to be finalized. That means that the EVM will have one precompile range, but with gaps for precompiles that only exist on other chains.
• option B: RIP precompiles have their own separate range. Given that not every L2 is expected to ship every precompile, this range will have gaps on each chain. Once an RIP precompile is later introduced on L1, it will keep its address, so over time L1 will also have precompiles in both ranges, including gaps in the RIP range.

Given that gaps seem unavoidable, we think that option A would be simpler, and would like to discuss this and potential practical ways for coordinating address assignment on the call. Given that we have a first RIP precompile in last call already (RIP-7212), we would very much appreciate at least a decision on the call for this specific case, so that the RIP can move to final and be rolled out by L2s.

[timbeiko]

Added @adietrichs !

[holgerd77]

@adietrichs thats a good initiative, thanks a lot for the write-up 👍, I would also think that solution A (one address space) is the easier solution, given the gap argumentation/situation!

Is there already a (optimally canonical) place to get an overview which L2s are intending to implement which precompile? And at what level of intend would we take the intend serious enough to reserve an address (or - to formulate more neutral: what level of intend would „trigger“ a reservation?)?

Just throwing in the ring, can also be left as open questions/thought food for the call.

[timbeiko]

Closed in favor of #931