EIP-7587 Reserving precompile addresses for RIPs (Reserve Precompile Address Range for RIPs)
Final · EVM & execution · EIP status Final · created 2023-12-21
Reserves a precompile address range (0x0100 to 0x01ff) in advance for use by Rollup Improvement Proposals (RIPs) on L2s, so that it does not overlap with addresses assigned by EIPs.
Why it is needed
Ethereum has special contracts called precompiles. These embed frequently used, complex operations at fixed addresses so they can be processed quickly and cheaply. Until now, precompile addresses have only been determined through the EIP process, the improvement proposal process for Ethereum's base layer (L1). However, layer 2 networks (L2s) running on top of Ethereum have begun deploying their own precompiles through a separate process called Rollup Improvement Proposals (RIPs). If the two processes assign the same address to different functions, a conflict arises. This created a need to reserve an address range for RIPs in advance to eliminate the possibility of such conflicts.
What changes
Today
- Precompile addresses are determined only through the EIP process, with no range set aside for RIPs
- If an L2 adds a precompile via an RIP, there is a risk that an EIP will later assign the same address to a different function
- It is undefined who manages the list of RIP precompiles
After EIP-7587
- The address range from 0x0100 to 0x01ff is reserved exclusively for the RIP process
- The RIP process manages its own list of precompiles within this range
- The EIP process continues to use its own set of 255 addresses without worrying about conflicts
Who is affected
- L2 (rollup) teams: They can assign RIP precompile addresses within the reserved range without worrying about conflicts with changes on the L1 side.
- EIP authors and client teams: They simply avoid using the 0x0100 to 0x01ff range for new EIP precompiles, and bear no burden of managing the list of RIP precompiles.
- Wallet & app developers: It avoids situations where the same address means different things on L1 and L2, simplifying code that supports multiple chains.
- Ordinary users: There is no change users will notice directly, but it is a safeguard that preempts incidents that could arise from address conflicts.
In depth
Specification of the reserved range
Reserves the range from address `0x0000000000000000000000000000000000000100` to `0x00000000000000000000000000000000000001ff` for the RIP process. This range covers 256 addresses. It is the contiguous range immediately above the existing low address range used by L1 precompiles (starting after 0x01), with no overlap. The specification itself is just this one statement and does not define the behavior of any specific precompile.
Background: L2s begin deploying RIPs
As L2s began actually deploying RIPs, a need arose to guarantee that there would be no conflict between precompile addresses used by RIPs and those used by EIPs. The purpose of this EIP is to reserve an address range for the RIP process to use in order to provide that guarantee.
Design intent: separating the registries
Reserving the range allows the RIP process to maintain its own precompile registry. The precompiles in this registry are not necessarily all deployed on L1 mainnet. Meanwhile, the EIP process is freed from the obligation to manage the RIP precompile registry while still retaining its own 255 addresses for its own use. In other words, this creates a structure in which neither process needs to look up or coordinate the other's address assignments.
Meta EIP, compatibility, and security
This proposal is an EIP of type Meta, establishing a procedural agreement about address assignment rather than changing protocol code. No backward compatibility issues were found, and Security Considerations are listed as Nil. The status is Final, meaning the content is settled and will not change further.