You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: EIP_AUTHORS_MANUAL.md
+22-18Lines changed: 22 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,49 +1,53 @@
1
-
##Introduction
1
+
# Introduction
2
2
3
3
This document outlines the process of specifying and testing EIPs for the Ethereum execution layer. It is intended for EIP authors, researchers and implementers. An EIP will typically go through the following stages:
4
4
5
-
1.**Research**: The EIP author concieves and refines an idea for an improvement to Ethereum.
6
-
2.**Plain English Specification**: The EIP author writes a document describing the EIP. This is done in the eips repository. [EIPS](https://github.com/ethereum/EIPs/tree/master/EIPS)
7
-
3.**Executable Specifications**: The EIP is implemented in the `execution-specs`. This is intended to make the EIP executable, identify any immediate and obvious implementation issues with the EIP (For example, the eip may not be compatible with some minor detail of the current Ethereum Virtual Machine).
8
-
4.**Writing Tests**: The EIP author writes test schemes for the EIP in the `execution-spec-tests` repository. Having the reference implementation should help identify the various logical flows to test and thus, feed into more robust testing. Once the test schemes are written, the reference implementation can then be used to fill the tests and generate the test vectors.
9
-
5.**Community Discussion**: The EIP is now ready for discussion with the broader Ethereum community. Although the feedback from the community can be sought at all stages of the EIP lifecycle, we feel that having a reference implementation and tests act as a good bridge between research and client implemtation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.
10
-
6.**Inclusion in a Fork**: Contigent on the community agreeing to the merits of the EIP, it can be included for implementation in a future fork. The test vectors can then be generated using the reference implementation and made available to the client teams.
11
-
7.**Client Implementation**: The EIP is implemented by the various client teams with the test vectors as the guide.
12
-
8.**Mainnet Deployment**: The EIP is deployed on the Ethereum mainnet.
5
+
| Stage | Activities | Outputs |
6
+
| ------------------ | ----------- | ------- |
7
+
|_Pre‑Draft_| Prospective EIP author conceives of an idea for an improvement to Ethereum, and discusses with the community. | <ul><li>Vague Consensus on [Ethereum Magicians][0]</li></ul> |
8
+
|**Draft**| <p>EIP author writes a technical human-language document describing the improvement, initially in broad strokes and becoming more specific over time.</p><p>Concurrently, they develop a Python reference implementation to make the EIP executable and identify any immediate/obvious implementation issues. For example, the EIP may not be compatible with some detail of the current Ethereum Virtual Machine.</p><p>Finally for this stage, the author begins to write test schemes for the EIP. Having the reference implementation should help identify the various logical flows to test and thus feed into more robust testing. Once the test schemes are written, the reference implementation can then be used to fill the tests and generate the test vectors.</p> | <ul><li>Complete (but not final) document in [EIPs Repository][1]</li><li>Reference Implementation in [EELS][2]</li><li>Initial Tests in [EEST][3]</li></ul> |
9
+
| **Review** | <p>The broader Ethereum community discusses and provides input on the proposal.</p><p>Although the feedback from the community can be sought at all lifecycle stages, having a reference implementation and tests act as a good bridge between research and client implemtation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.</p> | <ul><li>Complete & final document in the [EIPs Repository][1]</li><li>Comprehensive tests in [EEST][3]</li></ul>
10
+
|**Last Call**| Usually after being nominated for inclusion in a fork, the EIP author signals that the proposal is effectively done and begins the last period for comments/discussion. | <ul><li>Complete reference implementation in [EELS][2]</li><li>Complete tests in [EEST][3]</li><li>Immutable proposal in [EIPs Repository][1]</li></ul> |
11
+
|**Final**| The proposal is now immutable (cannot be changed) and exists for reference. | <ul><li>Mainnet client implementations</li></ul> |
This document will focus on stages 3 and 4 of the above lifecycle.
15
19
16
20
17
-
###Executable Specifications
21
+
# Executable Specifications
18
22
19
23
This repository contains the executable specifications for the Ethereum execution layer.
20
24
21
25
## Folder Structure
22
26
23
-
# Forks live on mainnet
27
+
###Forks live on mainnet
24
28
25
29
The folder `src/ethereum` contains the specifications for the different execution layer forks. Each fork has its own folder. For example, the folder `src/ethereum/frontier` contains the specifications for the Frontier hardfork. The `state_transition` function which is available in the `src/ethereum/<FORK NAME>/fork.py` is the transition function for each fork.
26
30
27
-
#Forks under development
31
+
### Fork under development
28
32
29
-
At the time of writing, the Prague Fork is still under development and the previous fork is Cancun, which is live on Mainnet.
33
+
At any given time, there is a single fork under development. Any new EIP has to be implemented in the folder that is meant for that fork (`src/ethereum/<FORK_NAME>` folder).
30
34
31
-
So the prague folder under `src/ethereum` is essentially just the Cancun fork with the values of variables updated to reflect Prague and its under-development status. This folder (`src/ethereum/prague`) serves as the baseline for further Prague development and all the EIPs for Prague are to be implemented in this folder.
35
+
For example, at the time of writing, the Prague Fork is still under development and the previous fork is Cancun, which is live on Mainnet. So the prague folder under `src/ethereum` is essentially just the Cancun fork with the values of variables updated to reflect Prague and its under-development status. This folder (`src/ethereum/prague`) serves as the baseline for further development and all new EIPs are to be implemented in this folder.
32
36
33
37
## Branch Structure
34
38
35
-
# Forks live on mainnet
39
+
###Forks live on mainnet
36
40
37
41
The final stable specification for all forks that are currently live on mainnet are in the `master` branch.
38
42
39
-
#Forks under development
43
+
### Fork under development
40
44
41
45
At any given time, there can only be one fork under active development. The branch structure for the fork under development is as follows:
42
46
43
47
-`forks/<FORK_NAME>`: The main branch for the fork under development. For example, `forks/prague` is the branch for the Prague fork. This branch will be merged into `master` after the fork has gone live on mainnet.
44
48
-`eips/<FORK_NAME>/<EIP_NUMBER>`: Branches for each EIP within the fork under development. For example, `eips/prague/eip-7702` is the branch for EIP-7702 for the Prague fork. This branch will be merged into `forks/prague` after the EIP has been confirmed for release in the fork.
45
49
46
-
##Writing New EIPS
50
+
# Writing New EIPS
47
51
48
52
Implementing a new EIP in the `execution-specs` repository involves the following steps:
49
53
@@ -57,7 +61,7 @@ An EIP can only be CFI'd (Considered For Inclusion) if it has a reference `execu
57
61
Please refer the following tutorial for writing new EIP. It takes you through a sample EIP for adding a new opcode to the specs.
In addition to having a reference implementation, it is also very useful for the community and core development if the EIP author concieves and writes test vectors for the EIP. There is a very user friendly framework for writing ethereum tests in the `execution-spec-tests` repository. Please refer to the following guide for writing tests to your EIP.
0 commit comments