# Execution Specifications: What is "Done"? These things need to be implemented before the core spec code can be frozen: - Issues in https://github.com/ethereum/execution-specs/milestone/14 - [x] London - [ ] The Merge - [x] Opcode Refac - [ ] Documentation Rendering - [ ] https://github.com/ethereum/execution-specs/issues/590 - [x] https://github.com/ethereum/execution-specs/issues/591 - [ ] https://github.com/ethereum/execution-specs/issues/519 - [ ] Pass **all** `ethereum/tests` test (that are correct/possible.) - [x] Contributing documentation (`CONTRIBUTING.rst`.) - [ ] Code Style documentation (`STYLE.rst` maybe?) - eg. only call `charge_gas` once per opcode These things *might* need to be implemented before EELS is "done": - [ ] Branching bot - some kind of tool to enforce the rules in [Executable EIPs](https://notes.ethereum.org/@timbeiko/executable-eips). - [ ] Being able to fill tests. - Test cases: https://github.com/ethereum/go-ethereum/tree/master/cmd/evm/testdata - [ ] Run the previous fork's tests for DAO and glacier forks. - [ ] Formalize cadence for code freezes: 1. Fork `F-1` happens. 2. EELS maintainers apply refactoring (30 days?) 3. Fork `F` opens for EIP authors (30 days?) 4. Fork `F` freezes for implementation. 5. Goto 1. - [ ] Documenting requirements for "EELS Proposals": - Needs a test that fails before your change that passes after. - Has to pass all the CI checks. - Needs to meet the relevant checks from `eipw` - [ ] Join in the fuzzing - https://github.com/holiman/goevmlab/tree/master/evms
Last changed by  
 
SamWilsn
414

Read more

Ethereum Improvement Proposals: Working Groups

This proposal sketches out how Working Groups might work within the Ethereum Improvement Proposal ecosystem.

2/21/2024
The Big List of EIP Peer Reviewers

This is a list of people/groups that have volunteered to be pinged on EIP discussion threads for specific topics. Forum Post There are four placeholders in the following template: As part of our process to encourage peer review, we assign a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @<!-- TODO -->! Please note that this review **is NOT required** to move your EIP through the process. When you&mdash;the authors&mdash;feel ready, just open a pull request. If any of this EIP's authors would like to participate in the volunteer peer review process, [shoot Sam a message](https://ethereum-magicians.org/new-message?username=SamWilsn&title=Peer+Review+Volunteer)! ---

4/27/2023
Executable Spec instead of Core EIPs

Discussion link https://ethereum-magicians.org/t/core-eips-in-an-executable-spec-world/8640 Contents [toc] Context Today, Core EIPs are used to specify changes affecting the execution layer (EL) which need to be activated through coordinated network upgrades (a.k.a. soft/hard forks). Core EIPs currently serve two purposes: explaining the motivation/rationale/security implications of the change and formally specifying it. While the former is very useful, and helps the Ethereum community understand and debate changes, the latter isn't ideal for a few reasons:

3/23/2022
🅰️🅰️ Account Abstraction Beyond EIP-2938 🧵🎉

This is the second of two posts describing account abstraction. You can find the first post here. Special thanks to @adietrichs and the rest of the Quilt team for review, content, and editing! More Account Abstraction? If you haven't yet, read EIP-2938 Account Abstraction Explained for some background on account abstraction (AA) and how EIP-2938 implements it. To quickly summarize it here, EIP-2938 implements just enough AA to support single-tenant applications, with minimal consensus changes and some new transaction propagation rules. While the EIP lays the groundwork for AA and does provide a compelling solution for single-tenant use cases, like smart contract wallets, several use cases are not satisfied and require new features to be fully realized. Features Beyond EIP-2938

10/26/2020
Read more from SamWilsn
Published on HackMD