docs: add consensus layer specification#511
Conversation
taxmeifyoucan
left a comment
taxmeifyoucan
left a comment
There was a problem hiding this comment.
Thank you so much for contributing!
Please watch capitalization and follow content standardization https://ethereum.org/contributing/style-guide/content-standardization/
| ## Overview | ||
|
|
||
| [How to use Executable Consensus Pyspec by Hsiao-Wei Wang | Devcon Bogotá](https://www.youtube.com/watch?v=ZDUfYJkTeYw) No newline at end of file | ||
| Before the Merge, the CL operated as the Beacon Chain which handled validator management, block proposals, attestations and was the first use case of the Gasper mechanism. The Beacon chain ran in parallel with the Proof-of-work chain. After the Merge, the CL took on the additional role of driving execution by incorporating execution payloads into beacon blocks. |
There was a problem hiding this comment.
pre-merge details are maybe not that relevant to spec themselves, I would rather focus on motivation behind the spec and its evolution
|
|
||
| The consensus specifications are a set of rules that the consensus clients must follow when implementing the CL. It references Gasper, a combination of the [Casper FFG](https://arxiv.org/pdf/1710.09437) algorithm and the [LMD-GHOST](https://arxiv.org/pdf/2003.03052) fork choice algorithm which are the very foundations of the CL. | ||
|
|
||
| Characteristics of the Consensus Specifications. |
There was a problem hiding this comment.
the overview paragraph could start here
| ## Overview | ||
|
|
||
| [How to use Executable Consensus Pyspec by Hsiao-Wei Wang | Devcon Bogotá](https://www.youtube.com/watch?v=ZDUfYJkTeYw) No newline at end of file | ||
| Before the Merge, the CL operated as the Beacon Chain which handled validator management, block proposals, attestations and was the first use case of the Gasper mechanism. The Beacon chain ran in parallel with the Proof-of-work chain. After the Merge, the CL took on the additional role of driving execution by incorporating execution payloads into beacon blocks. |
There was a problem hiding this comment.
I dont think explaining specs should start with pre-merge insight. Either way, this is a bit weird angle of explaining it, to be clear - before merge BN was launched to follow Ethereum by reading the deposit contract, processing validator deposits and after it was bootstrapped it ran fork choice + finalization with empty slots without execution payload
There was a problem hiding this comment.
but again, this should talk about specs not Beacon chain history itself. The spec angle would be - first generation of Ethereum python spec, started based on papers and research work 2017-18, evolved a lot since then..
| └── pyproject.toml/ | ||
|
|
||
| ``` | ||
| The block above outlines the consensus-specs repository structure. |
There was a problem hiding this comment.
might be worth doing just partially as an example and explain the structure than pasting whole thing that will be changing in the future
| - [EIP-7732 (ePBS)](https://eips.ethereum.org/EIPS/eip-7732) | ||
| - [EIP-7805 (FOCIL)](https://eips.ethereum.org/EIPS/eip-7805) | ||
| - [Verkle trees info](https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf) | ||
| - [Ben Edgington's annotated spec](https://eth2book.info/) |
There was a problem hiding this comment.
I would highlight Ben's annotated spec above as way to understand the protocol and the actual spec repo more way to use it for implementing, testing..
There was a problem hiding this comment.
I would also add HWW's talk on CL spec from Devcon bogota or from EPF study group
|
|
||
| *In development as of writing, scope subject to change | ||
|
|
||
| ##### Phase0 |
There was a problem hiding this comment.
It's great to map the whole repo! But I think diving into each fork deserves maybe its own page. Either way this is something rather document in meta EIPs and fork history https://ethereum.org/ethereum-forks/
Not sure if it belongs to spec page, should be about how to use, learn and contribute to actual specs
2 participants
Expanded the consensus layer specification stub into a full article covering the CL spec architecture, the executable specification (pyspec), repository structure, core spec documents, fork evolution from Phase0 through Heze, the parameterization system, and testing.