# EOF Polis Experiment [ARCHIVED]

Welcome to all exploring Polis to see if it can provide value to Ethereum.

This HackMD is to try to flesh out an actual Polis conversation that we can experiment on! Please feel free to collaborate directly on this!

## Checklist

This is a mini-checklist of items to get us across the line:

- [x] Finalize seed comments.
- [x] Vibe code a fun little website to embed this into (educational links and such, and OG:image / optimizations for SEO).
- [ ] Comb through comments / final touches / send it out

### Final questions

- Should we enable "No comments shown without moderator approval"? Bit worried about spam. I (dionysuz) think **yes**, we can turn it off later.
- Auth is broken on Pol.is (see: https://github.com/compdemocracy/polis/issues/1839). Should we do staged distribution: core dev teams first, then wider community? Or we can do a gossip (each person share to 2-3 friends). I (dionysuz) think **yes**. Start with R&D discord IMO, capture data, then move on. There's not much we can do about auth, I think trying to implement it is a bit of a waste of time, worst case we see how bad it is, and at least we can moderate comments.

### Social media strategy

- Will post on X and Warpcast

**Thread:**

EOF Polis: An Ethereum Social Experiment

EVM Object Format (EOF) is a proposed change to Ethereum's EVM. This Polis conversation seeks to find common ground.

https://eof-polis.pages.dev/ 1/

---

Polis uses AI to identify patterns of agreement across different viewpoints. Your votes and statements help shape the conversation.

Want to learn more? Check out the official Polis documentation: https://compdemocracy.org/Polis/. 2/

---

This is a v1 experiment created by Ethereum community members. We'll use the results of this experiment to learn how we can promote more productive conversations on Ethereum. 3/

---

If you have any feedback or are interested in helping out, don't hesitate to reach out! 4/

## Topic

Let's talk about EOF!

## Description

EVM Object Format (EOF) is a proposed change to Ethereum's EVM. It is planned for Fusaka, but there is lots of push in both directions.

EOF is a contentious topic. This Polis conversation seeks to find common ground across diverse opinion about EOF to help inform the community how we feel about it.

## Seed comments

> We will target ~30 comments, ~10 against, ~10 for, and ~10 consensus building (+ or - a few is fine).

**For**

1. EOF fixes problems left from the initial EVM.
2. EOF ensures smart contracts cannot jump to unpredictable locations or overflow/underflow their stack.
3. EOF makes smart contracts more deterministic by replacing dynamic opcodes with static ones.
4. If EOF is adopted at the base layer, L2s will adopt it as well.
5. EOF will improve the developer experience for smart contract developers.
6. EOF reduces code complexity.
7. EOF improves the effectiveness of security analysis tools at identifying exploits.
8. EOF should be included in Fusaka.
9. EOF will improve Ethereum’s compatibility with L2s.
10. EVM versioning, introduced by EOF, is useful.
11. The complexity of EOF is no more than other execution layer upgrades.
12. EOF makes a variety of small but useful upgrades to EVM execution.
13. Keeping a rapid pace of Ethereum development is a priority.

**Against**

1. EOF adds to much complexity to Ethereum.
2. EOF introduces too many breaking changes.
3. We don't need EOF to make it easier to add/remove opcodes.
4. "Stack too deep" is a Solidity problem.
5. Solidity problems shouldn't be an overriding motivation for EOF.
6. We don't need EOF to solve "stack too deep" errors.
7. The advantages of EOF are questionable given that EOF code can call non-EOF code.
8. EOF is being rushed.
9. The main benefit of EOF is aiding static analyzers.
10. Many of EOF's proposed benefits can be realized through less disruptive means.
11. EOF does not provide enough benefit compared to other performance improvements, like improving state root efficiency.

**Consensus**

1. I would be fully in support of merging EOF if it was proven to be stable and safe.
2. EOF is only worth it if we eventually migrate over pre-EOF contracts to EOF in a later hard fork.
3. EOF should be feature-complete when it is shipped.
4. Any major EVM change, like EOF, should be thoroughly tested before implementation.
5. EOF should include impact analysis (eg. numbers on gas reductions, code size decreases, speed changes) when it is shipped.
6. There is a lack of a clear and cohesive vision for the EVM.
7. We should host a live public debate on EOF.
8. Improving the developer experience of Ethereum is a priority.
9. Ensuring Ethereum remains a stable and reliable platform for users and developers is a priority.
10. Engaging with L2 projects is essential to ensure that EOF enhances the overall Ethereum ecosystem.