specs: Specify derivation of future tx types

[sebastianst]

Description

Clarifies how to deal with 7702 and future transactions.

• batcher tx must be of type 0-3, or 0x7e, but not 4, that is, 7702 txs.
• we allow 7702 txs, and possibly other future txs with similarly encoded logs, for user deposits on L1 and SystemConfig configuration tx

Metadata

Part of ethereum-optimism/optimism#13627

[protolambda]

LGTM.

Maybe consider clarifying "best-effort receipt decoding" as "ignore the tx-type prefix-byte of the RLP payload, and decode the RLP like the receipt-type that is used for for types 0, 1, 2, 3, 4.

Also maybe clarify that TX-type != prefix byte. Legacy transactions, and receipts also (!), have a range of prefix byte values, and not really an actual prefix byte but part of the RLP payload itself, that all effectively map to "legacy", and represented as type 0.

[geoknee]

I think it would be good to reference https://eips.ethereum.org/EIPS/eip-2718.

In implementation work so far I have been making a distinction between:

• explicitly supported EIP 2718 tx (fully parsed)
• not explicitly supported EIP 2718 tx (treated as "opaque" and only the tx type and hash is parsed)
• non-EIP 2718 tx (not parsed at all, causes an error / panics). An example is when the first byte is out of range, e.g. > 0x7f.

[sebastianst]

Thanks @protolambda @geoknee I agree that a specific reference to EIP-2718 is helpful here. I've completely rewritten the spec and came up with a process that feels much more clearly defined. PTAL.