• Increasing address size from 20 to 32 bytes

    • motivation: state expiry, shard ID, security
    • 20 bytes is 80 bits of collision resistance, in reach of sophisticated attacker

    <aside> 🔊 This possibility of attack means that if someone gives you an address that is not yet on-chain, and claims that the address has some property, they cannot prove that the address actually has that property, because they could have some second way of accessing that account. The properties of addresses become more complicated: you can trust an address if either (i) it is on chain, or (ii) you personally created it; for example, an organization cannot safely receive funds at a multisig unless that multisig has already been published on-chain, because whoever was the last to provide their public key could have chosen their private key in such a way as to make the address also a valid EOA controlled by themselves.

    • Not clear we absolutely want this property of trustlessness towards people sending us new addresses, though it is nice. </aside>

    • challenge: backward compatibility

    • make addresses 32 bytes, reserve first byte for version (≥ 1, address ≥ 2^160), 0 for old-style

    • new CREATE3 opcode for address creation, transaction type where msg.sender is 32 byte addr, new opcode BIGCALLER, returns 32 or 20 bytes address, CALLER always returns a 20 bytes address

    • challenge: interoperate with pre-existing contract

      • solution: compress new addresses sha3(DOMAIN_SEPARATION_KEY + address)[12:] (returned by CALLER)
      • .. then save the mapping from compressed to full in a new special contract
      • .. *CALL and *EXT opcode must now attempt to decompress all old-style addresses

    • list of opcodes interacting with addresses

  • ASE (Address Space Extension) with Translation Map

    • issues with how solidity represents addresses
      • N: seems to me that you just need to update it? old contracts will work with compressed addresses anyway?
    • in EIP-1559 tx type, address field is unbounded! (what about before?)
    • specification effort of the above idea
    • ECRECOVER opcode: should it return short or long address?
      • we don't know when the signature we're checking was generated!
      • should there be two version, or should it take a flag?
    • CREATE3 vs changing the behaviour of CREATE/CREATE2 in non-legacy context
    • how to expose mapping short to long addresses? a contract is a nice answer
    • what about new address compresed form colliding with an old address?
      • could happen if sending funds to the shortened version before the long version has been registered on chain!
      • .. then the funds sent would be lost
      • one solution: merging (they say it's too complex... why?)
    • difference to forum: LONGADDRESS does not seem needed, CREATE3 could be dropped
    • double hashing for compression...
      • if find a long address that compresses to a short address, could use to steal the short address' funds! right?
      • prepopulate the map with existing accounts? would avoid collision, but those are pretty unlikely?
    • Q: so there is not concerne we can find a collision for the compressed version of the long address because having an old-style EOA with the same address as the compressed one does it enable the attacker to withdraw the funds?
    • translate via access list instead?
    • Total accounts (as of 2nd June @ etherscan): 156,000,000
      • might double in next two years, at least 9GB of data

  • ASE Test Cases

  • Issues with ASE (with a translation map)

  • Types of Resurrection Metadata in State Expiry

  • Address Space Extension with bridge contracts

  • Request for Proposals: ASE & State Expiry