How to Predict the Impact of EVM Upgrades

This document serves as an accompaniment to my talk at ETHTaipei and Web3FC, you can find my slides and some useful resources below. If you have any questions you can message me at https://twitter.com/_trvalentine.

Slides are available here, or click on the image below.

Update

Both talks are now available online in-case you missed them:

• How to predict the impact of EVM upgrades | Tony Valentine, Dedaub | ETHTaipei 2024
• Talk on “How to Predict the Impact of EVM Upgrades” - by Tony Valentine

Self Destruct Removal (EIP-4758, EIP-6780)

• Study on Removal of Self Destruct
  • EIP-4758
  • EIP-6780
• Geth Tracers
• Metamorphic Smart Contracts
  • Tornado Cash Governance Attack
  • https://a16zcrypto.com/posts/article/metamorphic-smart-contract-detector-tool/
  • Add CREATE3 opcode - no init_code hash
    • create3
    • https://github.com/transmissions11/solmate/blob/main/src/utils/CREATE3.sol

Top Re-Initialisers (Number of Unique Bytecodes)

Top Re-Deployers (Total Deployments to Address)

WETH totalSupply vs Actual totalSupply

This is the query I ran against our database (if you’re interested in this kinda stuff you might like our transaction monitoring solution)

select (select sum(value)
        from token_balance
        where token_address = '\xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2') as total_weth,
       (select value
        from token_balance
        where owner_address = '\xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2'
          and token_address = '\xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee') as weth_eth_balance

This information is constantly changing but at the time I ran it:

• Using selfdestruct as a transfer: https://app.dedaub.com/ethereum/tx/0xad9d2450700ad9a380ede1e1a59598b283cbd0f701d884d05d1911c05b93375
  • Decompiled initCode: https://app.dedaub.com/decompile?md5=977d622e1886ea97954a053b33ee0138

Transaction/Receipt Root Serialisation (EIP-6404, EIP-6466)

• Study on MPT Serialization
  • EIP-6404
  • EIP-6466
• Serialization
  • RLP Overview
  • SSZ Overview
    • SSZ in Depth
    • Why we need SSZ (StackExchange)

Finding RLP Decoding in TAC

This is the actual query we ran over our database of decompiled TAC code. If you get something in the right format you can actually use regex.

select md5_bytecode
from decompiled_code
where tac_level similar to
      '%\s+[a-zA-Z0-9_:]* = (G|L)T (([a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?, [a-zA-Z0-9_]*\((0x7f|0x80|0x81)\))\n|([a-zA-Z0-9_]*\((0x7f|0x80|0x81)\)), [a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?)%'
  and tac_level similar to
      '%\s+[a-zA-Z0-9_:]* = (G|L)T (([a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?, [a-zA-Z0-9_]*\((0xb7|0xb8|0xb9)\))\n|([a-zA-Z0-9_]*\((0xb7|0xb8|0xb9)\)), [a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?)%'
  and tac_level similar to
      '%\s+[a-zA-Z0-9_:]* = (G|L)T (([a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?, [a-zA-Z0-9_]*\((0xbf|0xc0|0xc1)\))\n|([a-zA-Z0-9_]*\((0xbf|0xc0|0xc1)\)), [a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?)%'
  and tac_level similar to
      '%\s+[a-zA-Z0-9_:]* = (G|L)T (([a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?, [a-zA-Z0-9_]*\((0xf7|0xf8|0xf9)\))\n|([a-zA-Z0-9_]*\((0xf7|0xf8|0xf9)\)), [a-zA-Z0-9_]*(\([a-zA-Z0-9_]*\))?)%'

To explain whats going on we’re looking for comparison operations. We look for both > and <. You might also notice that we use more constants that just the RLP constants, actually what we look for is each RLP constant ±1 to account for < vs <= and > vs >=. We also check for the symmetry, so x <op> y vs y <op> x.

It can be written out more clearly as:

<variable> = (GT)|(LT) <variable> <variable>(±<constant>)
<variable> = (GT)|(LT) <variable>(±<constant>) <variable>

• Example Contract: MPTValidator (LayerZero)
  • RLP Decoding in TAC: https://app.dedaub.com/ethereum/address/0x462f7ec57c6492b983a8c8322b4369a7f149b859/tac?line=909
  • RLP Constant Comparison in Bytecode: https://app.dedaub.com/ethereum/address/0x462f7ec57c6492b983a8c8322b4369a7f149b859/disassembled?line=2390

The Verge

The verge plays a role in both these studies, the self-destruct one more directly since it is being removed because of it. The roots study is also a result of the verge since the move to SSZ is motivated by its Merkle-ization properties (amongst others) which will help empower light clients.

Roadmap courtesy of Vitalik, check his Twitter for an updated one:

• Verkle Trees
  • Vitalik’s Blog post on Verkle Trees
  • Vitalik’s Older Verkle Gas Metering Blog Post
    • We actually did a study on this: Verkle gas cost changes insights

https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Access-events-for-account-headers