EVM Precompiles: Reserve a range for EIP-based precompiles

[Stebalien]

Reported by @wadealexc.

We should reserve a precompile range for "blessed' precompiles. Personally, I'd start defining our own precompiles at, e.g., 128, leaving < 128 for ones with EIPs.

[wadealexc]

Maybe 256? Might be easier to reason about an entire byte.

In Solidity, this would be address(0x0100) vs address(0x80)

[wadealexc]

It would be kinda cute to have these use an F though -- address(0x0F00), address(0x0F01), ...?

[Stebalien]

My understanding is that precompiles are defined to be 0-256, so that might cause some issues. On the other hand... it would guarantee that we won't have any issues.

[wadealexc]

Oh, interesting. I'm unaware of any special rules that apply to those addresses... will ask around.

[Stebalien]

Ah, I thought there was... but I may have been mistaken. See https://eips.ethereum.org/EIPS/eip-1352.

[wadealexc]

After asking a few ETH Layer 2's, the consensus is that there's nothing special you need to do, just give enough space for future ETH precompiles.

Optimism in particular has chosen to place precompiles at addresses starting with 0x42.

I think there are two options here:

1. Prepend FIL precompiles with something, like 0xFE (since 0xFF is taken by ID addresses converted to Eth addrs)
2. Give native EVM precompiles a gap, and then place FIL precompiles after the gap. Can use EIP 1352 to inform the size of the gap.

Personally, I like #2 better, since contracts will already want to bake in special cases for non-evm native actors calling in (0xFF addrs). And I think that treating the FIL precompiles more like native EVM precompiles makes more sense - so they should just sit at low addresses like addr(0x000...F0001).

I think this approach is sane as long as we're providing the guarantee that these precompiles won't ever call into EVM contracts.

[wadealexc]

I think this approach is sane as long as we're providing the guarantee that these precompiles won't ever call into EVM contracts.

Meant to say only ever call in "as themselves." From our convo today, the current impl has the call precompile spoof the caller address, so this shouldn't apply.

[Stebalien]

Concrete proposal:

Use be(chain_id) followed by two bytes for our precompiles. In our case, that's 4 bytes.

[Stebalien]

I.e. [0x1, 0x3a, XX, XX]

[mriise]

I'm a bit more of a fan of 0xFE prefix since it's a bit more human readable (although this is some nice bikesheding)
0x00FE0001
0x013A0001

I agree with reserving 2 bytes for the address and some prefix for our native precompiles.

[Stebalien]

So, @wadealexc commented that some other "layer 2s". Just prefix the entire address, the same thing we do for ID addresses.

In terms of the actual bytes..., yeah, 0xFE is probably the way to go. That way we have a clear 0xFF and a clear 0xFE (and can add more later).

[Stebalien]

@mriise can you handle this?

[mriise]

fix was merged.

[mriise]

For reference:

Precompile address now must start with either 0x00 or 0xfe followed by exactly 18 bytes of zeroes, then one byte indicating the index of the precompile.

Prefix 0x00 is reserved for EVM precompiles, 0xfe is reserved for FEVM (or "native") precompiles.

examples:

• 0xfe00000000000000000000000000000000000001
• 0x0000000000000000000000000000000000000004

Note: Eth null address is a reserved address that is nonassignable by the EAM. This also holds true for the zero index of precompile prefixes, it is a reserved address that is nonassignable by the EAM but also isn't a precompile address.