# 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? -> :man-shrugging:
---
## 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!**
{"title":"EOF + Verkle","description":"EOF Verkle slides","slideOptions":"{\"theme\":\"moon\"}","contributors":"[{\"id\":\"46f4f11e-c5fd-4f0b-9417-1132b8336f80\",\"add\":8728,\"del\":6179},{\"id\":\"94149ceb-593b-4989-b5d1-0e0af0737310\",\"add\":7,\"del\":7}]"}