feat(meta): structure and content of execution-level differences

[mds1]

This is a tracking issue, and will link out to specific issues below

Overview

The overall scope of the diff should be "things a smart contract developer or app developer needs to care about". For the most part, this means the diff is primarily an execution layer diff, as contract/app devs don't usually need to worry about consensus layer details. There are exceptions here, e.g. it's easier to manipulate TWAPs in PoS compared to PoW because an attacker knows when they'll be the block proposer for consecutive blocks. Things like this should be included.

Additionally, data should be focused on the current hard fork for a given chain. Including historical data when possible is great, but for now the plan it to keep it simple and focus on doing one thing—diff current EVM specs—really well.

Data Sections

The current plan for sections is below.

In terms of implementation, always start by implementing Ethereum mainnet's spec first, and other chains' specs can import/modify that. Alternatively, another chain may import a non-mainnet chain as it's template. However, mainnet is always the chain that should be independently defined.

Adding data for any of these sections should include references. Lean towards including too many vs. too few, so things are easy to validate.

• Metadata: Chain name, ID, native token name, symbol, and decimals, block explorers, etc. This is pulled from the metadata in @wagmi/chains.
• Opcodes: This is ready to be implemented and is tracked in feat: add Opcode diffs (bounty: 300 OP 🔴) #6
• Precompiles and Predeploys: This is partially implemented and needs to be finished. It's being tracked in feat: finish populating existing precompiles and predeploys (bounty: 75 OP 🔴) #3
• Transaction Types: feat: signature (transaction) types #15
• Account Types: feat(data): Account Types #28
• Data structures and computation: feat(data): Data Structures and Computations #29
• Languages and Compilers: feat(data): Languages and Compilers #30
• Gas: feat: gas costs #31
• JSON-RPC: feat(data): JSON-RPC methods #32
• Nodes: feat(data): Nodes #33
• Mempools: feat(data): Mempools / Nonstandard RPCs #34
• Block production: feat(data): Block Production #35
• Contracts: feat(data): Contracts #36
• EIPs: feat(data): EIPs #37
• EVM version: feat: show latest evmVersion supported by each chain in each section and overall #27

References

• https://community.optimism.io/docs/developers/bedrock/how-is-bedrock-different/
• https://developer.arbitrum.io/arbitrum-ethereum-differences
• Others linked above

[pcaversaccio]

Some further thoughts:

• I love the playground feature from https://www.evm.codes/playground: it would be a nice feature to be able to simulate the differences at opcode or Solidity level, for example. Let me make a simple example: you have a contract compiled with solc version 0.8.20 and default EVM version shanghai. You copy-paste the contract into the playground, select "Optimism<>Ethereum diff" and press run. It will deploy on Ethereum but not on Optimism yet due to PUSH0. Diffs are very powerful on a documentation level, but many times you also want to understand the engineering implications. Thus, we should also think about how to integrate this best into the UI.
• Another important diff to understand is account types (e.g. EOA vs native account abstraction (such as zkSync has)).
• Also, I feel like there must be a section on the trust assumptions and differences across the different implementations. E.g. Optimism or Arbitrum are running centralised sequencers while on Ethereum anyone can participate in block producing as long as you stake 32 eth.

[mds1]

Thanks! I created #5 to track the first bullet. For the second, I added a new "Account Types" section above. And for the third, I added that to the "Block Production" section

[protolambda]

Looking forward to evmdiff, this is a great start for some em-standardization! Even if only research, but maybe also like https://caniuse.com/ that lists all browser differences.

And +1 on showing transaction types and precompiles. It always surprises me how many extra tx types and precompiles some EVM chains, even L2s have.

And fwiw: Optimism has no custom precompiles, and only 1 extra tx type that is equivalent to EIP-1559 but without signature, for deposits from L1. And happy to answer any questions about the Optimism diff / link any useful specs.

[mds1]

Thanks @protolambda, appreciate all that! 🙌

And good call on the similarities with caniuse, haven't used it in a while so will check it out for any good ideas

[ajhodges]

Some references for 1559 parameters:

OP Mainnet + Base + Zora (+ any other bedrock chain): https://community.optimism.io/docs/developers/bedrock/differences/#eip-1559
Elasticity Multiplier: 6
Denominator: 50
Block time: 2s

Polygon PoS Chain:
https://polygon.technology/blog/riding-the-roller-coaster-gas-fee-spikes-demystified
Elasticity Multiplier: 2
Denominator: 16
Block time: ~2s

Gnosis:
Ethereum defaults according to discord and this file: https://github.com/gnosischain/configs/blob/main/mainnet/genesis.json#L70-L71
Elasticity Multiplier: 2
Denominator: 8
Block time: ~5s

Avalanche C-Chain:
Custom 'moderato' implementation, described here:
https://medium.com/avalancheavax/apricot-phase-three-c-chain-dynamic-fees-432d32d67b60
https://medium.com/avalancheavax/apricot-phase-five-p-c-atomic-transfers-atomic-transaction-batching-and-c-chain-fee-algorithm-912507489ecd
This is not a 1559 implementation, but it behaves pretty similar. (Source code for impl) We can probably approximate its behavior (for the purposes of gas price estimation, etc) using these 1559 parameters:
Block time: ~2s
Target Gas Used in 10s: 15M (source)
Target Gas/Block: 7500000
Block gas limit: 15000000 (source)
Effective elasticity multiplier: 5
Denominator: 36 (source)

[protolambda]

Some small requests:

• Separate predeploys and precompiles. The nice thing about predeploys is that external EVM tools can easily import the bytecode and support them, whereas precompiles require deeper modifications.
• Show full predeploy/precompile address on hover, or expand it on clicking, it would be handy to copy.
• compute the similarity between the two sides of text. If the text is > 80% the same, maybe highlight the differences. It's hard to find subtle changes currently.

[mds1]

Closing this issue as part of the move to automated data collection in #62. All new data to fetch will be tracked in separate issues instead of relying on keeping this meta issue up to date.

Additionally:

if only research, but maybe also like https://caniuse.com/ that lists all browser differences.

This will exist once the refactor is merged, on the https://www.evmdiff.com/features page

And +1 on showing transaction types and precompiles. It always surprises me how many extra tx types and precompiles some EVM chains, even L2s have.

Transaction types are tracked in #68. Precompiles are currently supported based on a fixed set of precompiles to test for.

Some references for 1559 parameters:

1559 data is tracked as part of #31, unsure yet if its feasible to detect parameter values automatically. Other block production data is tracked in #69