Compatibility between interop chain ID and batch inbox convention

[mds1]

Currently the interop spec allows 256 bit chain IDs. The current convention (not requirement) for the batch inbox address is 0xFF00...{chainId}. These are not compatible, as the batch inbox address only can fit chain IDs up to 19 bytes because addresses are 20 bytes.

This is currently not a big problem, and this issue is low priority, because:

1. The batch inbox address is only a convention, so chains with chain IDs larger than 19 bytes can choose an arbitrary batch inbox address. But we don't yet spec out what requirements (if any) that address should have.
2. From my research, no chain IDs are currently large enough for this to be a problem. However, some OP Stack chains do not follow the batch inbox convention anyway.

So one consideration here is: should we enforce a batch inbox convention? Doing so would be a nice property, and we may want to spec out the required work to make this convention into a requirement.

Regardless, possible solutions to the existing incompatbility are discussed below:

Shrink max allowable chain ID

EIP-2294 proposed a max chain ID of floor(MAX_UINT64 / 2) - 36. This value was chosen to prevent overflow of a uint64 when calculating the v-component of a signature as {0,1} + CHAIN_ID * 2 + 35 per EIP-155. Many popular tools, like MetaMask, only support chain IDs that are within the javascript Number.MAX_SAFE_INTEGER based on the same v-component calculation (resulting in ~4e15, below this proposed max).

This is my preferred solution because (1) it fixes the issue with minimal work, (2) mitigates the risk of OP Stack chains not supporting popular tools, and (3) can be expanded to a larger value in the future when needed.

A factor in this proposal becoming stagnant was because it prevents an easy way for chains to pick a unique chain ID through a process like keccak256("myUniqueChainName"). This is a good point, but we already do not do this, and we can expand allowable chain ID and change the convention in the future if this becomes necessary/desirable.

Change Batch Inbox Convention

Since we only have 20 bytes to work with, the new batch inbox address convention have to be something like keccak256(schemeVersion, chainId)[:20]. This would require changes to op-node so it can read from two batch inbox addresses: the legacy address, and a new address. It also makes it harder to look at a batch inbox address and back out the chain it's for, but this can is solved by the superchain-registry anyway

Do Nothing

Because this is just a convention, and not enforced, the status quo is ok—for chains that cannot meet the convention, they just choose a different, arbitrary batch inbox address. This should still be documented in the spec somewhere, e.g. in this case does the address still need to start with 0xFF?