EOF + Verkle

Context & goals

• EOF considered for Prague
• Verkle considered for Osaka
• How can each EIP affect each other?
• Impact for:
  • Ethereum users?
  • VKT spec and implementation?
  • Risks for EOF adoption?

TL;DR verkle trees

• Motivation: viable stateless clients
• Introduce execution witness, which has:
  • Account data
  • SC code
• SC code is now in the state tree

TL;DR verkle trees

• Deploying bigger contracts: more gas (than today)
• More bytecodes required during exec: more gas (new gas cost dimension)

TL;DR EOF

• More structure in SC code (Header/Type sections)
• Execution efficiency gains
• Avoid JUMPDEST analysis
• Easier to add/remove features/instructions.
• Potential effects:
  • Bigger code?
  • Read more bytecodes during execution?

EOF + Verkle (gas risks)

• EOF might increase code size
• EOF could read more bytecodes in contract execution
• VKT makes those actions add more gas costs
• Caveat!:
  • EOF bring new efficiencies that might offset new costs.
  • Compilers can optimize code layout to account for the new code-chunk gas cost dimension and EOF sections.
  • By how much? ->
    Image Not Showing Possible Reasons

    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported

    Learn More →

EOF + Verkle (gas risks - idea)

• Requires a client with both EOF+VKT implemented
• Testnet with VKT + EOF
• Deploy contracts both compiled with legacy and EOF
• Tx executions to compare both
• With EOF-compilers accounting for both EOF and VKT optimizations? (ideally)
• Feedback for both EOF and Verkle specs to adjust!

EOF + Verkle (EOF adoption risk)

• [Depends if EOF vs legacy has a big gas difference!]
• Users might deploy EOF vs. legacy depending on which has a better gas cost for them.
• Hard to stop accepting new legacy SCs?
• Accepting two contract execution modes forever?

EOF + Verkle (VKT complexity risk)

• How does code-chunking for EOF work?
• Eventual double-spec for legacy vs EOF executions?
• EOF introduces ~19 new instructions: new witness gas extra cost for those? (e.g: BALANCE, BLOCKHASH)
• EOF could delay Osaka: state growth make MPT->VKT transition longer?

Final words

• EOF and VKT implementations looks like non-overlapping, but not their effects
• EOF original assumptions didn't expect code to be in the tree
• VKT needs that for stateless clients
• Described (potential) complications emerge!
• Can deploying a minimal-EOF version help?
• Not claiming there's a big problem. Claiming we don't know and need to find out!