chore(data-review): miscellaneous questions about current data

[mds1]

Mainnet

• Should type 0 transactions be marked as deprecated: true? They are strictly worse than type 2 transactions because type 2 transactions provide a refund, so here it seems we should consider them deprecated.

Optimism

• Should type 0 transactions be marked as deprecated: true? (Though, arguably type 0 is better for users since it has less calldata—expand the block below for more info on the cost difference)

Type 0 vs Type 2 cost analysis

Type 0 results in a bit less calldata to post on L1 since there's one less gas param and no prefix byte, so it should be cheaper. The refund for a type 2 transaction is priced in L2 gas, and the reduced calldata is priced in L1 gas which is ~10,000x more expensive. Therefore the reduced calldata of a type 0 tx should always outweigh the L2 refund, and maybe on L2 type 0 transactions are preferred? Perhaps something about the transaction serialization or compression makes this not true.

• Tested this by serializing two transactions and pasting the results into the getL1Fee of the optimism gas oracle.
• Tx 0: tx0 = utils.serializeTransaction({to: constants.AddressZero, gasPrice: 1, gasLimit: 21000, chainId: 10, type: 0}) = 0xdf800182520894000000000000000000000000000000000000000080800a8080
• Tx 2: tx2 = utils.serializeTransaction({to: constants.AddressZero, maxPriorityFeePerGas: 1, maxFeePerGas: 1, gasLimit: 21000, chainId: 10, type: 2}) = 0x02df0a8001018252089400000000000000000000000000000000000000008080c0
• Resulting fee in wei is 31753508714978 for tx0 and 34678476442615 for tx2, which meas tx 2 has an L1 fee that's 2.924967727637e-6 ETH more expensive
• Conclusion: that difference is small enough that this is probably not relevant, especially after EIP-4844

• The docs say the COINBASE opcode is undefined (sounds like that means it'd cause a revert), but by calling getCurrentBlockCoinbase (block.coinbase) on the Multicall3 contract it seems the actual value returned is 0x4200000000000000000000000000000000000011 (the sequencer fee vault)
• Verify that prefix byte 0x03 is considered reserved and will not be used.

Arbitrum

1. It seems there used to be a transaction type 0x67 (103) that was removed called ArbitrumWrappedTxType. This is worth documenting as deprecated: true. I searched their issues/PRs/codebase for that name and number but didn't find it
2. The docs (1, 2) say "Accessing block numbers within an Arbitrum smart contract (i.e., block.number in Solidity) will return a value close to (but not necessarily exactly) the L1 block number at which the Sequencer received the transaction." — are there any guarantees on the bounds of the returned number? Can it be greater than the most recent L1 block number? Is there a maximum bound on how much lower it is? In general this description is vague, how is the estimated block number derived?
3. The docs say the COINBASE opcode returns zero, but by calling getCurrentBlockCoinbase (block.coinbase) on the Multicall3 contract it seems the actual value returned is 0xA4b000000000000000000073657175656e636572.
   1. That address is the L1 batch poster, will the batch poster always be that address
4. The docs say the DIFFICULTY (PREVRANDAO) opcode returns 2500000000000000, but by calling getCurrentBlockDifficulty (block.difficulty) on the Multicall3 contract it seems the actual value returned is 1
5. The docs don't mention the CALLER opcode, but pretty sure it also has address aliasing and behaves the same as it does on optimism
6. Verify that prefix byte 0x03 is considered reserved and will not be used.

[TucksonDev]

Hey @mds1, Tuckson here, from OffchainLabs. I'll try to clarify your points about Arbitrum:

1. ArbitrumWrappedTx was used in the Arbitrum Classic stack, but has never been deployed as part of the Nitro stack as it was removed before Nitro was live.
2. L1 block number is updated in the Sequencer to the latest block on L1, here. So it can’t be greater than the most recent L1 block number. There are also some examples of how it works here, although you have probably seen those already.
3. My colleague already addressed this point in our PR.
4. Also handled in the same PR.
5. CALLER is always treated as in Ethereum except when using L1-to-L2 messages as explained here.

Hope that helps.

Feel free to tag me for further questions, or open an issue in our repo.
Thanks!

[mds1]

This is great, thanks so much @TucksonDev!

[mds1]

Closing this issue as part of the move to automated data collection in #62