diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 10a2a3cb..63c39818 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -1,7 +1,7 @@ - [Home](readme.md) - **Study Group** - [EPFsg overview](/eps/intro.md) -- Schedule +- Presentations - [Week 0](/eps/week0.md) - [Week 1](/eps/week1.md) - [Week 2](/eps/week2.md) @@ -22,8 +22,9 @@ - [Contributing](contributing.md) - **Protocol Wiki** - The Protocol - - [Overview](/wiki/protocol/overview.md) - - [History](/wiki/protocol/history.md) + - [Architecture](/wiki/protocol/architecture.md) + - [Design rationale](/wiki/protocol/design-rationale.md) + - [Evolution](/wiki/protocol/history.md) - Execution Layer - [EL Specs](/wiki/EL/el-specs.md) - [Client architecture](/wiki/EL/el-architecture.md) @@ -31,34 +32,32 @@ - [Besu](/wiki/EL/clients/besu.md) - [Reth](/wiki/EL/clients/reth.md) - [EVM](/wiki/EL/evm.md) + - [Precompiled Contracts](/wiki/EL/precompiled-contracts.md) + - [Data Structures](/wiki/EL/data-structures.md) - [Transaction anatomy](/wiki/EL/transaction.md) - [JSON-RPC](/wiki/EL/JSON-RPC.md) - - [Data Structures](/wiki/EL/data-structures.md) - - [DevP2P] - - [Precompiled Contracts](/wiki/EL/precompiled-contracts.md) -- [Consensus Layer](/wiki/CL/overview.md) + - [DevP2P](/wiki/EL/devp2p.md) + - [RLP Serialization](/docs/wiki/EL/RLP.md) +- Consensus Layer + - [Overview](/wiki/CL/overview.md) - [CL Specs](/wiki/CL/cl-specs.md) - - Client architecture + - [Client architecture](/wiki/CL/client-architecture.md) - [CL Clients](/wiki/CL/cl-clients.md) - - [Proof-of-Stake] - - [Beacon API] - - [Networking](/wiki/CL/cl-networking.md) + - [Beacon API](/wiki/CL/beacon-api.md) + - [CL Networking](/wiki/CL/cl-networking.md) - Development - [Core development](/wiki/dev/core-development.md) - - [Coordination](/wiki/protocol/pm.md) - - [CS Resources](/wiki/dev/cs-resources.md) + - [Coordination](/wiki/dev/pm.md) + - [Dev Resources](/wiki/dev/cs-resources.md) - Testing and security - [Testing overview](/wiki/testing/overview.md) - [Incidents](/wiki/testing/incidents.md) - [hive](/wiki/testing/hive.md) - - Formal Verification - Research - [Roadmap overview](/wiki/research/roadmap.md) - [Scaling](/wiki/research/scaling/scaling.md) - [Core Changes](/wiki/research/scaling/core-changes/core-changes.md) - [EIP-4844](/wiki/research/scaling/core-changes/eip-4844.md) - - Statelessness - - Purge - [MEV](/wiki/research/PBS/mev.md) - [MEV-boost](/wiki/research/PBS/mev-boost.md) - [PBS](/wiki/research/PBS/pbs.md) @@ -67,28 +66,15 @@ - [PTC](/wiki/research/PBS/PTC.md) - [PEPC](/wiki/research/PBS/PEPC.md) - [TBHL](/wiki/research/PBS/TBHL.md) - - Proof of Stake - - [Upgrades](/docs/wiki/research/cl-upgrades.md) - - SSF - - SSLE - - [Light Clients](/wiki/research/light-clients.md) - - Privacy - - AA - - ASE - - EOF - - Portal Network - Preconfirmations - [Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md) - [Based Sequencing with Preconfs](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) - [Cryptography](/wiki/Cryptography/intro.md) - - [ECDSA](/wiki/Cryptography/ecdsa.md) + - [ECDSA](/wiki/Cryptography/ecdsa.md) + - [BLS](/wiki/Cryptography/bls.md) - [Keccak256](/wiki/Cryptography/keccak256.md) - - BLS - [Commitments] - - Polynomials - - Commitment schemes - [KZG](/docs/wiki/Cryptography/KZG.md) - - ZK - [Post-Quantum Cryptography](/wiki/Cryptography/post-quantum-cryptography.md) - [Protocol Fellowship](/wiki/epf.md) diff --git a/docs/eps/intro.md b/docs/eps/intro.md index d0d3c100..ec90e06f 100644 --- a/docs/eps/intro.md +++ b/docs/eps/intro.md @@ -1,64 +1,64 @@ # EPF Protocol Studies -Ethereum Protocol Fellowship Study Group (EPFsg) is a learning community formed to gather knowledge and educate itself about the Ethereum protocol. +Ethereum Protocol Fellowship Study Group (EPFsg) is a community formed gathering knowledge, learning and educating about the Ethereum protocol. -The protocol evolves and grows quickly, it's an always-changing infinite garden. To sustain its credible neutrality, this pace should be reflected in the community as well. Various communities using, building or living on Ethereum need to be able to learn and become involved in the core protocol. The complexity of the architecture, codebases and dynamic development with scattered resources can discourage many talented people from participating on the core level. The protocol study group aims to bridge the gap by introducing a curriculum focused on all parts of the Ethereum stack & roadmap and gathering people interested in diving into it. +The protocol evolves and grows quickly, it's an always-changing infinite garden. To sustain its credible neutrality, this pace should be reflected in the community as well. Various communities using, building or living on Ethereum need to be able to learn and become involved in the core protocol. The complexity of the architecture, codebases and dynamic development with scattered resources can discourage many talented people from participating on the core level. The protocol study group aims to bridge the gap by introducing a curriculum focused on all parts of the Ethereum stack, building a wiki and gathering people interested in diving into it. -> Check also the announcement blog post https://blog.ethereum.org/2024/02/07/epf-study-group +> The study group was originally running from February to April 2024 as an open open, 10-week study program. Although these regular presentations are over, all of the content produced is available here and the community is still active. ## Program Structure -The program is an open, 10-week study program divided into 2 phases. +The study group content is structured in 2 stages of weekly presentations. To follow the study group, you can watch presentations and read related resources week by week. The first half is dedicated to general understanding of the internal mechanisms of the protocol, its architecture and basic concepts. The second half offers 2 different tracks - development and research. Presentations in each track offer a deeper dive into specific topics within the R&D domains. -Each online session will be led by core developers and researchers, come with pre-meeting reading material to get you familiar with the topic and terminology as well as a post-meeting activity to strengthen and solidify your understanding. +Each session is led by core developer or researcher, comes wit reading materials to get you familiar with the topic context and some also include exercises to strengthen and practice your understanding. -Weekly topics, their presentations and materials can be all found in this folder. Checkout the study group content in this folder, start with [Week 0](eps/week0.md). +Weekly sessions, their presentations and materials can be all found in this section under Presentations. -### Schedule +### Presentations -The first part of the program consists of 5 weeks with introductions to high level domains of the protocol. +The first part of the program consists of 6 sessions with introductions to high level domains of the protocol. -| Date | Topic | Speaker | -| ----------- | ---------------------------------- | ------------------------------------------------------------------------------------------------ | -| February 19 | Intro to EPS and Ethereum protocol | [Josh Davis](https://github.com/JoshDavisLight), [Mario Havel](https://github.com/taxmeifyoucan) | -| February 26 | Execution Layer | [Lightclient](https://github.com/lightclient) | -| March 4 | Consensus layer | [Alex Stokes](https://github.com/ralexstokes) | -| March 11 | Testing and security | [Mario Vega](https://github.com/marioevz) | -| March 18 | Roadmap and research | [Domothy](https://github.com/domothyb) | - -The second part of the program offers two distinct tracks focused on development and research with deeper dive into each domain. +> Because some speakers did more technical talks than others, the recommended order for newcomers to start is Week 1, Week 3, Week 2, Week 5 Node workshop and then Week 4 and 5. +| Week # | Topic | Speaker | +| ------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------ | +| [Week 1](/eps/week1.md) | Intro to EPS and Ethereum protocol | [Josh Davis](https://github.com/JoshDavisLight), [Mario Havel](https://github.com/taxmeifyoucan) | +| [Week 2](/epf/week2.md) | Execution Layer | [Lightclient](https://github.com/lightclient) | +| [Week 3](/epf/week3.md) | Consensus layer | [Alex Stokes](https://github.com/ralexstokes) | +| [Week 4](/epf/week4.md) | Testing and security | [Mario Vega](https://github.com/marioevz) | +| [Week 5](/epf/week5.md) | Roadmap and research | [Domothy](https://github.com/domothyb) | +| [Week 5](/epf/node_workshop.md) | Node workshop | [Mario](https://github.com/taxmeifyoucan) | -| Date | Topic | Speaker | Track | -| -------- | ----------------------------- | -------------------------------------------------------------------------------------- | ----------- | -| March 25 | Consensus and Execution specs | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) | Development | -| March 27 | Sharding and DAS | [Dankrad Feist](https://github.com/dankrad) | Research | -| April 1 | Execution client architecture | [Dragan Pilipovic](https://github.com/dragan2234) | Development | -| April 3 | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | Research | -| April 8 | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | Development | -| April 10 | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | Research | -| April 15 | Devops and testing | [Parithosh](https://github.com/parithosh) | Development | -| April 17 | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | Research | -| April 22 | EL precompiles | Danno Ferrin | Development | -| April 24 | SSF and PoS Upgrades | [Francesco D’Amato](https://github.com/fradamt) | Research | -| April 29 | Wrap up | | | +The second part of the program offers two distinct tracks focused on development and research with deeper dive into each domain. +| Week #, track | Topic | Speaker | +| ------------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------- | +| [Week 6 Development](/epf/week6-dev.md) | Consensus and Execution specs | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) | +| [Week 6 Research](/epf/week6-research.md) | Sharding and DAS | [Dankrad Feist](https://github.com/dankrad) | +| [Week 7 Developsment](/epf/week7-dev.md) | Execution client architecture | [Dragan Pilipovic](https://github.com/dragan2234) | +| [Week 7 Research](/epf/week7-research.md) | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | +| [Week 8 Development](/epf/week8-dev.md) | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | +| [Week 8 Research](/epf/week8-research.md) | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | +| [Week 9 Development](/epf/week9-dev.md) | Devops and testing | [Parithosh](https://github.com/parithosh) | +| [Week 9 Research](/epf/week9-research.md) | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | +| [Week 10 Development](/epf/week10-dev.md) | EL precompiles | [Danno Ferrin](https://github.com/shemnon) | +| [Week 10 Research](/epf/week10-research.md) | SSF and PoS Upgrades | [Francesco D’Amato](https://github.com/fradamt) | ### Streams and recordings Talks and calls are announced week in advance based on the schedule above. Recordings of all talks can be found on [Youtube](https://www.youtube.com/@ethprotocolfellows) or [StreamEth](https://streameth.org/archive?organization=ethereum_protocol_fellowship) archive. -Apart from weekly lectures, there are less regular, ad-hoc hangout calls for informal chats and calls for wiki contributors working the content. Join the Discord group to get notified about all of these events. +Apart from weekly lectures, there are less regular, ad-hoc hangout calls for informal chats and calls for wiki contributors working the content. Join the Discord group to get notified about all of these events. ## Participate -The first instance of EPF study group is starting in February 2024. It's completely open and permissionless, and it is up to each participant as to how they want to approach it. Whether you want to learn as much as possible, focus only on certain topics or share your knowledge with others, you are welcomed. Although it's opened, [you can register](https://forms.gle/7TqmryC217EPwgqr9) to help us tailor the experience better. +The study group is an open and permissionless, and it is up to each participant as to how they want to approach it. Whether you want to learn as much as possible, focus only on certain topics or share your knowledge with others, you are welcomed. -> Join our community [Discord server](https://discord.gg/addwpQbhpq) +> Join our community in [Discord server](https://discord.gg/addwpQbhpq). We use it for the easiest community engagement but we are aware that Discord is proprietary and doesn't respect user privacy. Consider using alternative FOSS clients like [Dissent](https://github.com/diamondburned/dissent) or [Discordo](https://github.com/ayn2op/discordo). -Study group participants will collaboratively develop a comprehensive wiki, serving as an evolving knowledge base for current and future core developers. This will provide students with practical experience in contributing to open source resources, while gaining invaluable experience in documentation and community-driven development. +Study group participants collaboratively develop the [Protocol wiki](/wiki/wiki-intro.md), serving as an evolving knowledge base for current and future core developers. This can provide students with practical experience in contributing to open source resources, while gaining invaluable experience in documentation and community-driven development. While this program is designed to act as a precursor to the Ethereum Protocol Fellowship, the study group is for anyone that is interested in learning more about the inner workings of the Ethereum Protocol. Those that have some general knowledge or use of Ethereum and/or blockchains as well as those that have some computer science, technical, or developer experience will get the most from this program. @@ -69,6 +69,7 @@ While this program is designed to act as a precursor to the Ethereum Protocol Fe - [Youtube](https://www.youtube.com/@ethprotocolfellows) - [Sessions calendar](https://calendar.google.com/calendar/u/0?cid=ZXBmc3R1ZHlncm91cEBnbWFpbC5jb20) - [EPF mailing list](https://groups.google.com/a/ethereum.org/g/protocol-fellowship-group) +- [EF Blog](https://blog.ethereum.org) ## Calls troubleshooting diff --git a/docs/images/el-architecture/architecture-overview.png b/docs/images/el-architecture/architecture-overview.png index e911f67d..8cc9e8c1 100644 Binary files a/docs/images/el-architecture/architecture-overview.png and b/docs/images/el-architecture/architecture-overview.png differ diff --git a/docs/images/el-architecture/data-serialization.png b/docs/images/el-architecture/data-serialization.png new file mode 100644 index 00000000..f4547f5c Binary files /dev/null and b/docs/images/el-architecture/data-serialization.png differ diff --git a/docs/images/el-architecture/excalidraw/architecture-overview.excalidraw b/docs/images/el-architecture/excalidraw/architecture-overview.excalidraw index 8576889e..61ed9b7b 100644 --- a/docs/images/el-architecture/excalidraw/architecture-overview.excalidraw +++ b/docs/images/el-architecture/excalidraw/architecture-overview.excalidraw @@ -669,8 +669,8 @@ }, { "type": "arrow", - "version": 1391, - "versionNonce": 364804069, + "version": 1549, + "versionNonce": 1969692213, "index": "aJ", "isDeleted": false, "id": "XGVWIZ6pHUIj7ulOBYe4A", @@ -680,12 +680,12 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": 162.90288831365356, - "y": -468.6856527067158, + "x": 146.13773735681042, + "y": -377.16255650365173, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", - "width": 316.20105724273844, - "height": 302.48700480703644, + "width": 332.9662081995817, + "height": 394.01010101010064, "seed": 1103704340, "groupIds": [], "frameId": null, @@ -693,7 +693,7 @@ "type": 2 }, "boundElements": [], - "updated": 1713692542793, + "updated": 1714326038458, "link": null, "locked": false, "startBinding": { @@ -715,12 +715,12 @@ 0 ], [ - 245.98653198653224, - -37.35569167572396 + 262.7516829433754, + -128.87878787878805 ], [ - 316.20105724273844, - -302.48700480703644 + 332.9662081995817, + -394.01010101010064 ] ] }, @@ -1009,8 +1009,8 @@ }, { "type": "ellipse", - "version": 331, - "versionNonce": 229670933, + "version": 441, + "versionNonce": 1291598965, "index": "aQV", "isDeleted": false, "id": "jvMQXbQZG3ErjC616pYO3", @@ -1020,8 +1020,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -186.61226320149854, - "y": -480.5665969076922, + "x": -208.27892986816528, + "y": -337.2332635743587, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 68.68013468013469, @@ -1046,7 +1046,7 @@ "type": "arrow" } ], - "updated": 1713642890971, + "updated": 1714326038457, "link": null, "locked": false }, @@ -1184,8 +1184,8 @@ }, { "type": "arrow", - "version": 273, - "versionNonce": 956746193, + "version": 481, + "versionNonce": 1390284155, "index": "ad", "isDeleted": false, "id": "kofqDTcbmGMFtvTWA-kFY", @@ -1195,8 +1195,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -183.6897042789392, - "y": -480.5665969076923, + "x": -205.35637094560593, + "y": -337.23326357435883, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 105.2121212121212, @@ -1208,10 +1208,14 @@ "type": 2 }, "boundElements": [], - "updated": 1713649560134, + "updated": 1714326039812, "link": null, "locked": false, - "startBinding": null, + "startBinding": { + "elementId": "jvMQXbQZG3ErjC616pYO3", + "focus": 0.33727771334282786, + "gap": 12.343479248160179 + }, "endBinding": null, "lastCommittedPoint": null, "startArrowhead": null, @@ -1229,8 +1233,8 @@ }, { "type": "arrow", - "version": 421, - "versionNonce": 204205937, + "version": 629, + "versionNonce": 5547547, "index": "ae", "isDeleted": false, "id": "yTHLUCYwtFkDM98RX9Tx0", @@ -1240,8 +1244,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -187.83401912683075, - "y": -419.96437705788753, + "x": -209.5006857934975, + "y": -276.63104372455405, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 102.28956228956228, @@ -1253,10 +1257,14 @@ "type": 2 }, "boundElements": [], - "updated": 1713649560134, + "updated": 1714326039812, "link": null, "locked": false, - "startBinding": null, + "startBinding": { + "elementId": "jvMQXbQZG3ErjC616pYO3", + "focus": 0.11838961774399336, + "gap": 9.193005139639233 + }, "endBinding": null, "lastCommittedPoint": null, "startArrowhead": null, @@ -1274,8 +1282,8 @@ }, { "type": "arrow", - "version": 272, - "versionNonce": 1931052849, + "version": 480, + "versionNonce": 1085221563, "index": "af", "isDeleted": false, "id": "dtRi2_WvVx9qE1iqfIBOh", @@ -1285,8 +1293,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -185.15098374021863, - "y": -446.9571692982647, + "x": -206.81765040688538, + "y": -303.62383596493123, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 135.8989898989899, @@ -1298,10 +1306,14 @@ "type": 2 }, "boundElements": [], - "updated": 1713649560134, + "updated": 1714326039813, "link": null, "locked": false, - "startBinding": null, + "startBinding": { + "elementId": "jvMQXbQZG3ErjC616pYO3", + "focus": 0.011419036349284633, + "gap": 1 + }, "endBinding": null, "lastCommittedPoint": null, "startArrowhead": null, @@ -1454,8 +1466,8 @@ }, { "type": "text", - "version": 134, - "versionNonce": 1074350481, + "version": 168, + "versionNonce": 1013480885, "index": "aj", "isDeleted": false, "id": "Q1CZDpTaEEKNTXlFuZNKH", @@ -1465,8 +1477,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -536.0085232545501, - "y": -694.029319370415, + "x": -522.6751899212168, + "y": -830.6959860370816, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 365.6000061035156, @@ -1476,7 +1488,7 @@ "frameId": null, "roundness": null, "boundElements": [], - "updated": 1713649560134, + "updated": 1714325608229, "link": null, "locked": false, "fontSize": 32.95238095238093, @@ -1488,42 +1500,6 @@ "originalText": "Gossips with \nother exceution lauer \nclients over p2p", "lineHeight": 1.25 }, - { - "type": "text", - "version": 143, - "versionNonce": 425859387, - "index": "al", - "isDeleted": false, - "id": "TdgNuphR5Reg09dqFbC-V", - "fillStyle": "hachure", - "strokeWidth": 4, - "strokeStyle": "dashed", - "roughness": 2, - "opacity": 100, - "angle": 0, - "x": -531.722808968836, - "y": -833.3150336561295, - "strokeColor": "#1e1e1e", - "backgroundColor": "transparent", - "width": 304.0333251953125, - "height": 56.42857142857142, - "seed": 851946144, - "groupIds": [], - "frameId": null, - "roundness": null, - "boundElements": [], - "updated": 1713642487815, - "link": null, - "locked": false, - "fontSize": 45.14285714285714, - "fontFamily": 1, - "text": "Network: UDP", - "textAlign": "left", - "verticalAlign": "top", - "containerId": null, - "originalText": "Network: UDP", - "lineHeight": 1.25 - }, { "type": "rectangle", "version": 161, @@ -1929,8 +1905,8 @@ }, { "type": "rectangle", - "version": 498, - "versionNonce": 2125109937, + "version": 557, + "versionNonce": 721928725, "index": "b02", "isDeleted": false, "id": "ZuasuskvUFGU2ZdFZUvPC", @@ -1940,8 +1916,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -149.34963693887175, - "y": -517.8292231703184, + "x": -157.682970272205, + "y": -376.1625565036517, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 311.2525252525253, @@ -1974,14 +1950,14 @@ "type": "arrow" } ], - "updated": 1713650533114, + "updated": 1714326038457, "link": null, "locked": false }, { "type": "text", - "version": 661, - "versionNonce": 691517193, + "version": 720, + "versionNonce": 491829109, "index": "b03", "isDeleted": false, "id": "p_sKc-oXirXqR4NES8oii", @@ -1991,8 +1967,8 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": -42.498375838488016, - "y": -460.83932418041945, + "x": -50.831709171821274, + "y": -319.1726575137527, "strokeColor": "#1e1e1e", "backgroundColor": "#ffffff", "width": 97.55000305175781, @@ -2002,7 +1978,7 @@ "frameId": null, "roundness": null, "boundElements": [], - "updated": 1713645774423, + "updated": 1714326038457, "link": null, "locked": false, "fontSize": 29.22558922558922, @@ -2144,8 +2120,8 @@ }, { "type": "arrow", - "version": 433, - "versionNonce": 35907423, + "version": 591, + "versionNonce": 1856165109, "index": "b0R", "isDeleted": false, "id": "gO_ZMZNq0JV7moXCYXxDJ", @@ -2155,11 +2131,11 @@ "roughness": 2, "opacity": 100, "angle": 0, - "x": 162.90288831365353, - "y": -399.0099355450733, + "x": 154.56955498032028, + "y": -270.5291135781252, "strokeColor": "#1e1e1e", "backgroundColor": "transparent", - "width": 708.6588318811038, + "width": 716.992165214437, "height": 245.33346080458358, "seed": 1375156071, "groupIds": [], @@ -2168,7 +2144,7 @@ "type": 2 }, "boundElements": [], - "updated": 1713650756993, + "updated": 1714326038458, "link": null, "locked": false, "startBinding": { @@ -2190,12 +2166,12 @@ 0 ], [ - 462.2314455746533, - -80.94795525391294 + 470.5647789079866, + -209.42877722086104 ], [ - 708.6588318811038, - 164.38550555067064 + 716.992165214437, + 35.904683583722544 ] ] }, @@ -2651,6 +2627,686 @@ "containerId": null, "originalText": "Payload Validation & Insertion\nPipeline", "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 887, + "versionNonce": 810118805, + "index": "b1EG", + "isDeleted": false, + "id": "kJJXsoaK9sX0k2hPaWZv4", + "fillStyle": "solid", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 2, + "opacity": 100, + "angle": 0, + "x": -52.98895085019234, + "y": -598.9944091704378, + "strokeColor": "#1e1e1e", + "backgroundColor": "#ffffff", + "width": 447.3636363636364, + "height": 567.7340067340069, + "seed": 2051138293, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [ + { + "type": "text", + "id": "Idbz_UHlTbbQ8v6rIwdES" + } + ], + "updated": 1714326693225, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 1057, + "versionNonce": 1453904885, + "index": "b1EV", + "isDeleted": false, + "id": "Idbz_UHlTbbQ8v6rIwdES", + "fillStyle": "solid", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 2, + "opacity": 100, + "angle": 0, + "x": 100.76786427986804, + "y": -337.6274058034344, + "strokeColor": "#1e1e1e", + "backgroundColor": "#ffffff", + "width": 139.85000610351562, + "height": 45, + "seed": 1179892821, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326693225, + "link": null, + "locked": false, + "fontSize": 36, + "fontFamily": 1, + "text": "DevP2P", + "textAlign": "center", + "verticalAlign": "middle", + "containerId": "kJJXsoaK9sX0k2hPaWZv4", + "originalText": "DevP2P", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 332, + "versionNonce": 558698581, + "index": "b1F", + "isDeleted": false, + "id": "cIKoR1G9S613GqXd_iddk", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -43.825128014765426, + "y": -577.0499828094416, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 415.55555555555554, + "height": 228.88888888888877, + "seed": 1503881653, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326126200, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 163, + "versionNonce": 839551867, + "index": "b1J", + "isDeleted": false, + "id": "Xzfwj1pJ_WfU_dJNjm-cb", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -16.60290579254348, + "y": -564.272205031664, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 125.69999694824219, + "height": 27.965599010749017, + "seed": 894855957, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326126200, + "link": null, + "locked": false, + "fontSize": 22.372479208599213, + "fontFamily": 1, + "text": "Transaport", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "Transaport", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 168, + "versionNonce": 844250549, + "index": "b1K", + "isDeleted": false, + "id": "uyMgKnE_vbVXzg2tkWAei", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -11.602905792543368, + "y": -511.494427253886, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 348.888888888889, + "height": 129.99999999999994, + "seed": 434258037, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326126200, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 120, + "versionNonce": 21062683, + "index": "b1L", + "isDeleted": false, + "id": "0aBjUVYof9x5Z-Tl8uyv9", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 12.285983096345603, + "y": -497.6055383649972, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 50, + "height": 25, + "seed": 487352789, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326126200, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "RLPx", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "RLPx", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 168, + "versionNonce": 957005589, + "index": "b1M", + "isDeleted": false, + "id": "U7Qa_ObzWsWuSktEytoR7", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 90.61931642967886, + "y": -470.383316142775, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 98.88888888888893, + "height": 62.222222222222285, + "seed": 2146068277, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326126201, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 111, + "versionNonce": 1096034491, + "index": "b1N", + "isDeleted": false, + "id": "J8AVpiu1S8fHQMwJY1nkx", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 119.50820531856778, + "y": -452.04998280944153, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 42.18333435058594, + "height": 25, + "seed": 1155643541, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326126201, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "TCP", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "TCP", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 162, + "versionNonce": 1273762933, + "index": "b1O", + "isDeleted": false, + "id": "LD692x2fJR-knVy5i5PQ4", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 217.28598309634583, + "y": -473.71664947610816, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 78.8888888888888, + "height": 67.7777777777777, + "seed": 94887413, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [ + { + "type": "text", + "id": "6L4K3NIkPF7-fWXr7jmnd" + } + ], + "updated": 1714326126201, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 107, + "versionNonce": 420684277, + "index": "b1P", + "isDeleted": false, + "id": "6L4K3NIkPF7-fWXr7jmnd", + "fillStyle": "hachure", + "strokeWidth": 4, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 244.67209414387855, + "y": -452.32776058721936, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 24.116666793823242, + "height": 25, + "seed": 155342677, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714325858561, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "IP", + "textAlign": "center", + "verticalAlign": "middle", + "containerId": "LD692x2fJR-knVy5i5PQ4", + "originalText": "IP", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 443, + "versionNonce": 1206212955, + "index": "b1Q", + "isDeleted": false, + "id": "kFUXF3EEaP_EYfePbjPq4", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -38.408461348098854, + "y": -282.8833161427747, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 415.55555555555554, + "height": 228.88888888888877, + "seed": 436642997, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326126201, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 297, + "versionNonce": 1525957621, + "index": "b1R", + "isDeleted": false, + "id": "XYTcO10n00Tn821PEUe0x", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -11.18623912587691, + "y": -270.1055383649971, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 102.1500015258789, + "height": 27.965599010749017, + "seed": 463095317, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326544482, + "link": null, + "locked": false, + "fontSize": 22.372479208599213, + "fontFamily": 1, + "text": "Discovery", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "Discovery", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 493, + "versionNonce": 576760283, + "index": "b1S", + "isDeleted": false, + "id": "wHq0o5OPIYgSCam3Ud3ox", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": -6.186239125876796, + "y": -217.32776058721902, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 348.888888888889, + "height": 129.99999999999994, + "seed": 1626520437, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326667492, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 451, + "versionNonce": 817608021, + "index": "b1T", + "isDeleted": false, + "id": "GHkR-NTc9kCpHyJ4KRGEu", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 17.702649763012232, + "y": -203.43887169833033, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 38.83333206176758, + "height": 25, + "seed": 1112900821, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326667492, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "Wire", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "Wire", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 473, + "versionNonce": 302298747, + "index": "b1U", + "isDeleted": false, + "id": "kJ26GQukJfY9NLrg-Cwxl", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 96.03598309634549, + "y": -176.21664947610816, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 98.88888888888893, + "height": 62.222222222222285, + "seed": 1935155765, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [], + "updated": 1714326667492, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 439, + "versionNonce": 111428277, + "index": "b1V", + "isDeleted": false, + "id": "kJjfJZvH9KuDUgkKFa1dW", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 124.9248719852344, + "y": -157.88331614277456, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 43.099998474121094, + "height": 25, + "seed": 417338261, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326667492, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "UDP", + "textAlign": "left", + "verticalAlign": "top", + "containerId": null, + "originalText": "UDP", + "lineHeight": 1.25 + }, + { + "type": "rectangle", + "version": 485, + "versionNonce": 1455304475, + "index": "b1W", + "isDeleted": false, + "id": "KdhTH7IKq0qbRAlPOTcfO", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 222.70264976301235, + "y": -179.5499828094412, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 78.8888888888888, + "height": 67.7777777777777, + "seed": 522377461, + "groupIds": [], + "frameId": null, + "roundness": { + "type": 3 + }, + "boundElements": [ + { + "type": "text", + "id": "sQ50L5Av6ekng3OZcrKFU" + } + ], + "updated": 1714326667492, + "link": null, + "locked": false + }, + { + "type": "text", + "version": 543, + "versionNonce": 517219349, + "index": "b1X", + "isDeleted": false, + "id": "sQ50L5Av6ekng3OZcrKFU", + "fillStyle": "hachure", + "strokeWidth": 4, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "angle": 0, + "x": 250.08876081054512, + "y": -158.16109392055233, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "width": 24.116666793823242, + "height": 25, + "seed": 1336275541, + "groupIds": [], + "frameId": null, + "roundness": null, + "boundElements": [], + "updated": 1714326667492, + "link": null, + "locked": false, + "fontSize": 20, + "fontFamily": 1, + "text": "IP", + "textAlign": "center", + "verticalAlign": "middle", + "containerId": "KdhTH7IKq0qbRAlPOTcfO", + "originalText": "IP", + "lineHeight": 1.25 + }, + { + "id": "g1ZfPJFDYRULh-a-l4zq8", + "type": "rectangle", + "x": 206.58221759223278, + "y": -272.46228821834586, + "width": 75.47350817609556, + "height": 44.56582689299915, + "angle": 0, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "groupIds": [], + "frameId": null, + "index": "b1b", + "roundness": { + "type": 3 + }, + "seed": 921396315, + "version": 149, + "versionNonce": 728245083, + "isDeleted": false, + "boundElements": [ + { + "type": "text", + "id": "i8arnc2i2DpaUEvL_S7kb" + } + ], + "updated": 1714326722526, + "link": null, + "locked": false + }, + { + "id": "i8arnc2i2DpaUEvL_S7kb", + "type": "text", + "x": 223.9939709173411, + "y": -262.67937477184626, + "width": 40.650001525878906, + "height": 25, + "angle": 0, + "strokeColor": "#1e1e1e", + "backgroundColor": "transparent", + "fillStyle": "hachure", + "strokeWidth": 1, + "strokeStyle": "solid", + "roughness": 0, + "opacity": 100, + "groupIds": [], + "frameId": null, + "index": "b1c", + "roundness": null, + "seed": 682137653, + "version": 110, + "versionNonce": 1323368443, + "isDeleted": false, + "boundElements": null, + "updated": 1714326722526, + "link": null, + "locked": false, + "text": "DNS", + "fontSize": 20, + "fontFamily": 1, + "textAlign": "center", + "verticalAlign": "middle", + "containerId": "g1ZfPJFDYRULh-a-l4zq8", + "originalText": "DNS", + "lineHeight": 1.25 } ], "appState": { diff --git a/docs/images/elliptic-curves/bls-alice.png b/docs/images/elliptic-curves/bls-alice.png new file mode 100644 index 00000000..bfc58c21 Binary files /dev/null and b/docs/images/elliptic-curves/bls-alice.png differ diff --git a/docs/images/elliptic-curves/bls-key.svg b/docs/images/elliptic-curves/bls-key.svg new file mode 100644 index 00000000..d1c71d6b --- /dev/null +++ b/docs/images/elliptic-curves/bls-key.svg @@ -0,0 +1,916 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/elliptic-curves/bls-setup.svg b/docs/images/elliptic-curves/bls-setup.svg new file mode 100644 index 00000000..a719cf02 --- /dev/null +++ b/docs/images/elliptic-curves/bls-setup.svg @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/elliptic-curves/bls-signing.svg b/docs/images/elliptic-curves/bls-signing.svg new file mode 100644 index 00000000..331f5704 --- /dev/null +++ b/docs/images/elliptic-curves/bls-signing.svg @@ -0,0 +1,308 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/elliptic-curves/bls-verifying.svg b/docs/images/elliptic-curves/bls-verifying.svg new file mode 100644 index 00000000..d5b96503 --- /dev/null +++ b/docs/images/elliptic-curves/bls-verifying.svg @@ -0,0 +1,504 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/wiki/CL/beacon-api.md b/docs/wiki/CL/beacon-api.md new file mode 100644 index 00000000..53e59474 --- /dev/null +++ b/docs/wiki/CL/beacon-api.md @@ -0,0 +1,7 @@ +# Beacon API + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Beacon API is the endpoint provided by consensus layer clients. It's the interface for interacting with consensus for users and validators. + +Check the [Beacon API reference](https://ethereum.github.io/beacon-APIs/#/). \ No newline at end of file diff --git a/docs/wiki/CL/cl-clients.md b/docs/wiki/CL/cl-clients.md index f1a2a225..87c9c573 100644 --- a/docs/wiki/CL/cl-clients.md +++ b/docs/wiki/CL/cl-clients.md @@ -2,15 +2,15 @@ This page covers resources on all consensus client implementations, whether in production or development. It provides an overview of unique features of each client, architecture, basic guides and resources. -> Consensus clients originally used to be called _eth2.0 clients_ which is now a deprecated nomenclature but you can still find this reference in their repositories. +> Consensus clients originally used to be called _eth2.0 clients_ which is now a deprecated nomenclature but you can still find this reference in their repositories. -There are multiple Consensus Layer clients developed to participate in the Ethereum Proof-of-Stake (PoS) mechanism. The most popular, FOSS and production ready are [Lighthouse](https://lighthouse-book.sigmaprime.io/), [Lodestar](https://lodestar.chainsafe.io/), [Nimbus](https://nimbus.team/index.html), [Prysm](https://prysmaticlabs.com/) and [Teku](https://consensys.io/teku). These clients are developed in different programming languages, provide have unique features and offer different performance profiles. All clients support Ethereum mainnet out of the bo as well as currently active testnets. Variety of implementations allows the network to benefit from client diversity. If you are choosing a client to use, current client diversity should be one of the main factors. +There are multiple Consensus Layer clients developed to participate in the Ethereum Proof-of-Stake (PoS) mechanism. The most popular, FOSS and production ready are [Lighthouse](https://lighthouse-book.sigmaprime.io/), [Lodestar](https://lodestar.chainsafe.io/), [Nimbus](https://nimbus.team/index.html), [Prysm](https://prysmaticlabs.com/) and [Teku](https://consensys.io/teku). These clients are developed in different programming languages, provide have unique features and offer different performance profiles. All clients support Ethereum mainnet out of the box along with active testnets. Variety of implementations allows the network to benefit from client diversity. If you are choosing a client to use, current client diversity should be one of the main factors. -## Clients in production +## Clients in production ## LightHouse -[Lighthouse](https://lighthouse-book.sigmaprime.io/) is a client developed in the Rust programming language. It is a full-featured Ethereum consensus client that can be used as a beacon node or a validator client. It is developed by [Sigma Prime](https://sigmaprime.io/). +[Lighthouse](https://lighthouse-book.sigmaprime.io/) is a client developed in the Rust programming language. It is a full-featured Ethereum consensus client that can be used as a beacon node or a validator client. It is developed by [Sigma Prime](https://sigmaprime.io/). ### Features @@ -49,7 +49,6 @@ For more frequently asked question about the client, refer to the [FAQ](https:// By ChainSafe in TypeScript - ## Nimbus By Status in Nim @@ -58,7 +57,7 @@ By Status in Nim [Prysm](https://docs.prylabs.network/docs/getting-started) is a client developed in the Go programming language. It is one of the most popular clients and has a large community. Using this client, validators can participate in the Ethereum PoS mechanism. Prysm can be used as a beacon node or a validator client. It can assist execution layer clients in processing transactions and blocks. When an execution client is integrated with Prysm, it first syncs the block headers with it since, as a beacon node, it has a full view of the chain. It gossips the latest block headers to the EL client. Then, the EL client can request the block bodies from its p2p network. This is mostly common in the case of all Consensus Layer clients. -Apart from Ethereum mainnet, Prysm can also be run on testnets such as Goerli, Holesky, and Pyrmont. Prysm can be integrated with different EL clients such as [Geth](https://geth.ethereum.org/), [Nethermind](https://www.nethermind.io/nethermind-client), and [Besu](https://besu.hyperledger.org/), etc. It has a web interface to monitor the beacon chain and validator performance. It also has a RESTful API to interact with the beacon chain and validator client. +Apart from Ethereum mainnet, Prysm can also be run on testnets such as Goerli, Holesky, Pyrmont. Prysm can be integrated with different EL clients such as [Geth](https://geth.ethereum.org/), [Nethermind](https://www.nethermind.io/nethermind-client), and [Besu](https://besu.hyperledger.org/), etc. It has a web interface to monitor the beacon chain and validator performance. It also has a RESTful API to interact with the beacon chain and validator client. ### Installing the client @@ -162,7 +161,7 @@ Teku also provides a slashing protection mechanism, especially in the case where ## Clients in development -### Grandine +### Grandine Originally a proprietary client in Rust, recently became open source @@ -170,6 +169,6 @@ Originally a proprietary client in Rust, recently became open source By LC in Elixir -### Additional reading +### Additional reading [Analysis of CL clients performance, outdated](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc) diff --git a/docs/wiki/CL/cl-specs.md b/docs/wiki/CL/cl-specs.md index e69de29b..9a968621 100644 --- a/docs/wiki/CL/cl-specs.md +++ b/docs/wiki/CL/cl-specs.md @@ -0,0 +1,11 @@ +# Consensus layer specification + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Ethereum network started as a proof-of-work blockchain with the intention of switching to proof-of-stake after its bootstrap. The research produced a consensus mechanism combining Casper and GHOST, released in [Gasper paper](https://arxiv.org/abs/2003.03052). + +Based on its design, a specification was written in python. [Pyspec](https://github.com/ethereum/consensus-specs) is an executable specification that serves as a reference for consensus layer developers. It is also used as reference for client implementations and for creating the test case vectors for clients. + +## Resource + +[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 diff --git a/docs/wiki/CL/client-architecture.md b/docs/wiki/CL/client-architecture.md new file mode 100644 index 00000000..bfad295b --- /dev/null +++ b/docs/wiki/CL/client-architecture.md @@ -0,0 +1,10 @@ +# CL Client architecture + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Beacon Chain clients are implementing various fundamental features: + +- Forkchoice mechanism +- Engine API for communication with the execution client +- Beacon APIs for validators and users +- libp2p protocol for communication with other CL clients \ No newline at end of file diff --git a/docs/wiki/Cryptography/bls.md b/docs/wiki/Cryptography/bls.md new file mode 100644 index 00000000..79443f1a --- /dev/null +++ b/docs/wiki/Cryptography/bls.md @@ -0,0 +1,235 @@ +# Boneh-Lynn-Shacham (BLS) signature + +### TLDR; + +- Proof-of-stake protocols use digital signatures to identify their participants and hold them accountable. + - Validators in Beacon chain (Ethereum) use BLS signatures to participate in Consensus, sign blocks, post attestations etc. +- BLS signatures can be aggregated together, making them efficient to verify at large scale. +- Signature aggregation allows the beacon chain to scale to hundreds of thousands of validators. +- Normal Ethereum transaction signatures on the execution layer remain using ECDSA. However, account abstracted wallets can also utilize BLS. + +BLS is a digital signature scheme with aggregation properties. Given set of signatures (_signature_1_, ..., _signature_n_) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use-cases, specifically when minimal storage space or bandwidth are required. This page will cover the general idea and Math behind BLS signatures, further cover BLS in context of Ethereum. + +## How BLS works? + +At the core of BLS signatures is the concept of bilinear mapping through pairings on elliptic curves. A key component is a pairing function $e$, defined between two groups derived from elliptic curves: + +$$e: G_1 \times G_2 \rightarrow G_T$$ + +This function is efficiently computable and must satisfy bilinear properties: + +- For all $P,Q$ in $G_1$ and $a$ in integers, bilinearity is defined as: + $$e(aP, Q) = e(P, Q)^a$$ + $$e(P, aQ) = e(P, Q)^a$$ + +- Additionally, it must distribute over addition: + $$e(P + Q, R) = e(P, R) \times e(Q, R)$$ + $$e(P, Q + R) = e(P, Q) \times e(P, R)$$ + +These properties enable the cryptographic mechanisms necessary for functions like signature aggregation, which is a pivotal feature in blockchain applications and cryptographic consensus. + +#### Why BLS Over Schnorr and ECDSA for Digital Signatures? + +Traditional ECDSA signatures, as commonly used in Bitcoin or Ethereum transactions, depend heavily on the randomness of nonce generation and necessitate verification of all involved public keys individually, which can be computationally intensive. After its patent expired, Schnorr signatures became an alternative scheme which allows for some aggregation but still lacks the full efficiencies gained from BLS. + +BLS signatures, employing bilinear pairings, offer robust protection against certain cryptographic attacks and produce shorter signatures. Unlike Schnorr, BLS does not rely on random number generation for securing signatures, making it inherently more secure against randomness-related vulnerabilities. + +_Please note: While BLS signatures themselves do not require a random nonce for each signing operation (making them deterministic), the initial step of generating private keys in BLS is still dependent on secure random number generation. Unlike ECDSA, where a nonce is crucial in each signature to maintain security (and the randomness of this nonce is essential to prevent vulnerabilities), BLS avoids the need for this kind of nonce during the signing process. However, the randomness in generating the private key remains critical. This initial randomness ensures that the private key is secure and unpredictable, which is fundamental for the overall security of the cryptographic system._ + +#### Example of BLS Signature Generation and Verification: + +
+ +![Diagram showing key pair generation and verification for BLS](../../images/elliptic-curves/bls-alice.png) + +
+ +_Visual Aid to understand how BLS signatures work_ + +
+
+ +Consider Alice creating a BLS signature. She starts with her private key $a$, and computes her public key $P$ using a generator point $G$ on the elliptic curve: + +$$P = aG$$ + +She hashes her message and maps this hash to a point on the curve, $H(M)$. Her signature $S$ is then: + +$$S = a \times H(M)$$ + +The signature is verified using the pairing function: + +$$e(G, S) = e(P, H(M))$$ + +This can be proven as: +$$e(G,S)=e(G,a×H(m))=e(a×G,H(m))=e(P,H(M))$$ +where $G$ is the generator point on the elliptic curve. + +This equation proves that the signature was indeed created by the holder of the private key corresponding to $P$. + +#### Example + +For BLS signatures using a curve like BLS12-381 example values would look like: + +``` +Message: "Hello" +Secret Key: 26daf744780a51072aa8de191259bf7ff080b8457512cfd0eedfb4f8c71b131d +Public Key: bfdab807246849b76b7bdf5229619b9ccb33713633644a48b7ab3a7e67af7c1ae9d597a1c0fac6f61e63c1278b26c2f527be3d58bce95451b36f0c692ee90e1f +Signature: dee15784b458419b4b8bbdbb13838da13c27dccab6ef50f0dcb4ff7352048c0b +``` + +For ECDSA using a curve like secp256k1, there's an $R$ and an $S$ value, which produces a longer signature whose example values would look like: + +``` +Message: "Hello" +Private Key: 2aabe11b7f965e8b16f525127efa01833f12ccd84daf9748373b66838520cdb7 +Public Key (EC Point): + x: 39516301f4c81c21fbbc97ada61dee8d764c155449967fa6b02655a4664d1562 + y: d9aa170e4ec9da8239bd0c151bf3e23c285ebe5187cee544a3ab0f9650af1aa6 +Signature: + R: 905eceb65a8de60f092ffb6002c829454e8e16f3d83fa7dcd52f8eb21e55332b + S: 8f22e3d95beb05517a1590b1c5af4b2eaabf8e231a799300fffa08208d8f4625 +``` + +### Aggregation in BLS: + +A major advantage of BLS is the ability to aggregate multiple signatures into a single compact signature. This is particularly useful in scenarios involving multiple transactions or signers, greatly reducing the blockchain space and computational power needed for verifications. For example if there are 100 transactions, where signature for each one is represented by $S_i$ and each are associated with a public key of $P_i$ (and a message $M_i$), rather than storing 100 separate signatures, BLS allows combining them into one: + +$$S = S_1 + S_2 + \ldots + S_{100}$$ + +which can then verified with (using a multiply operation): +$$e(G,S)=e(P_1,H(M_1))⋅e(P_2,H(M_2))⋅…⋅e(P_{100},H(M_{100}))$$ + +Verification of this aggregated signature would involve a corresponding aggregation of public keys and message hashes, maintaining the integrity and non-repudiation of all individual signatures. + +## BLS Signatures in Ethereum + +With respect to Blockchain, digital signatures typically leverage elliptic curve groups. Ethereum primarily employs [ECDSA](/wiki/Cryptography/ecdsa.md) signatures using the [secp256k1](https://www.secg.org/sec2-v2.pdf) curve, while the beacon chain protocol adopts BLS signatures based on the [BLS12-381](https://hackmd.io/@benjaminion/bls12-381) curve. Unlike ECDSA, BLS signatures utilize a unique feature of certain elliptic curves known as "[pairing](https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627)." This allows for the aggregation of multiple signatures, enhancing the efficiency of the consensus protocol. While ECDSA signatures are [much quicker](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-1.1) to process, the aggregative capability of BLS signatures offers significant advantages for blockchain scalability and consensus efficiency. + +The process to create and verify a BLS signature is straightforward, involving a series of steps that can be explained through diagrams, descriptions, and mathematical principles, although understanding the mathematical detail is not essential for practical application. + +There are **4** component pieces of data within the BLS digital signature process. + +- **The secret key:** Every participant in the protocol, specifically a validator, possesses a secret key, also referred to as a private key. This key is crucial for signing messages and maintaining the confidentiality of the validator's actions within the network. +- **The public key:** Derived directly from the secret key using cryptographic methods, the public key, while linked to the secret key, cannot be reverse-engineered from it without extreme computational effort. It serves as the public identity of the validator within the protocol and is accessible to all participants. +- **The message:** In Ethereum, messages consist of byte strings whose structure and purpose will be explored in further detail later in the context. Initially, understand these messages as basic data units processed within the blockchain protocol. +- **The signature:** The signature is the result of the cryptographic process where the message is combined with the secret key. This signature uniquely identifies that a message was authored by the holder of the secret key. By verifying the signature with the corresponding public key, one can confirm that the message originated from a specific validator and has not been altered post-signing. + +In Mathematical terms, we use 2 subgroups of BLS12-381 elliptic curve: $G_1$ defined over a base field $F_q$, and $G_2$ defined over the field extension $F_{q^2}$. The order of both the subgroups is $r$, a 77 digit prime number. The (arbitrarily chosen) generator of $G_1$ is $g_1$, and of $G_2$ is $g_2$. + +1. The secret key, $sk$, is a number between $1$ and $r$ (technically the range includes $1$, but not $r$. However, very small values of $sk$ would be hopelessly insecure). +2. The public key, $pk$, is $[sk]g_1$ where the square brackets represent scalar multiplication of the elliptic curve group point. The public key is therefore a member of the $G_1$ group. +3. The message, $m$ is a sequence of bytes. During the signing process this will be mapped to some point $H(m)$ that is a member of the $G_2$ group. +4. The signature, $\sigma$, is also a member of the $G_2$ group, namely $[sk]H(m)$. + +
+ +![Diagram showing how we will depict the various components in the diagrams below.](../../images/elliptic-curves/bls-key.svg) + +
+ +_The key to the keys. This is how we will depict the various components in the diagrams below. Variants of the same object are hatched differently. The secret key is mathematically a scalar; public keys are_ $G_1$ _group members; message roots are mapped to_ $G_2$ _group members; and signatures are $G_2$ group members._ + +
+
+ +### Key pairs + +A key pair is a secret key along with its public key. Together these irrefutably link each validator with its actions. + +Each validator is equipped with atleast 1 primary "signing key" used for routine operations like creating blocks, making attestations etc. Depending on their withdrawal credentials, a validator may also have a secondary "withdrawal key," which is stored offline for added security. + +The secret key should be randomly generated within the range $[1,r)$, adhering to the [EIP-2333](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2333.md) standard, which recommends using the [`KeyGen`](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.3) method from the draft IRTF BLS signature standard. Although compliance with this method is not mandatory, deviating from it is generally discouraged. Most stakers generate their keys using the [`eth2.0-deposit-cli`](https://github.com/ethereum/eth2.0-deposit-cli) tool from the Ethereum Foundation. For security, key pairs are typically stored in password-protected [EIP-2335](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2335.md) keystore files. + +The secret key, $sk$, is a 32-byte unsigned integer. The public key, $pk$, is represented as a point on the $G_1$ curve and serialized in a compressed format as a 48-byte string within the protocol. + + + +
+ +![Diagram of the generation of the public key.](../../images/elliptic-curves/bls-setup.svg) + +
+ +_A validator randomly generates its secret key. Its public key is then derived from that._ + +
+
+ +### Signing in the Beacon Chain + +In Ethereum's beacon chain, the only messages that get signed are the [hash tree roots](https://eth2book.info/capella/part2/building_blocks/merkleization/) of objects. These roots, called "signing roots," are 32-byte strings. The [`compute_signing_root()`](/wiki/CL/functions#compute_signing_root) function integrates the hash tree root with a specific "domain," enhancing the security. + + + +The signing root is mapped onto an elliptic curve point within the $G_2$ group. This mapping, $H(m)$, where $m$ is the signing root, transforms the hash into a format suitable for cryptographic operations. This complex process is outlined in the [Hash-to-Curve draft standard](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/), but typically, developers rely on cryptographic libraries to manage this step efficiently. + +#### Signature Creation: + +The actual signing involves multiplying the $G_2$ point $H(m)$ by the signer's secret key $sk$: + +$$ +\sigma = [sk]H(m) +$$ + +The signature $\sigma$ thus generated is also part of the $G_2$ group and is typically compressed into a 96-byte string for practical use. + +
+ +![Diagram of signing a message.](../../images/elliptic-curves/bls-signing.svg) + +
+ +_A validator uses their secret key to sign a message, producing a unique digital signature_ + +
+ +
+ +### Verifying Signatures + +To validate a signature, the public key of the corresponding validator is necessary. This key is readily available in the beacon state, accessible by the validator's index, ensuring that key retrieval is straightforward and reliable. + +Verification is streamlined: input the message, public key, and signature into the verification process. If the signature is authentic—matching both the public key and the message—it is accepted; otherwise, it’s rejected due to potential corruption, incorrect key usage, or message tampering. + +Formally, this verification utilizes elliptic curve pairings. For the BLS12-381 curve, the pairing takes a point $P$ from $G_1$ and a point $Q$ from $G_2$, resulting in a point from group $G_T$: + +$$ +e: G_1 \times G_2 \rightarrow G_T +$$ + +Pairings are expressed as $e(P, Q)$ and are crucial for validating the correspondence between the signature and the public key: + +$$ +e(g_1, \sigma) = e(pk, H(m)) +$$ + +This checks whether the message signed with the secret key $sk$ matches the observed signature $\sigma$, using the fundamental properties of [pairings](/wiki/Cryptography/bls#how-bls-works). + +
+ +![Diagram of verifying a signature.](../../images/elliptic-curves/bls-verifying.svg) + +
+ +_Verification uses the validator's public key and the original message to confirm the authenticity of the signature._ + +
+ +
+ +**Verification Output**: The process returns `True` if the signature aligns with both the public key and the message, confirming its validity. If not, it returns `False`, indicating issues with the signature’s integrity or origin. + +## Resources and References + +- [BLS and key-pairing](https://asecuritysite.com/encryption/js_bls) +- [BLS signatures and key-pairing concepts](https://www.youtube.com/watch?v=cVgJBdM5E2M) +- [BLS aggregation by Vitalik Buterin and Justin Drake](https://www.youtube.com/watch?v=DpV0Hh9YajU) +- [Pragmatic Signature Aggregation By Justin Drake](https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105?u=benjaminion) +- [Building blocks from Eth2 Handbook](https://eth2book.info/capella/part2/building_blocks/signatures/) +- [formal IETF Draft Standard](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html) +- [Pairing Friendly curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10) +- [Hashing to elliptic curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-09) +- [ERC2333](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2333.md) provides a method for deriving a tree-hierarchy of BLS12-381 keys based on an entropy seed. +- [ERC2334](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2334.md) defines a deterministic account hierarchy for specifying the purpose of keys. +- [ERC2335](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2335.md) specifies a standard keystore format for storage and interchange of BLS12-381 keys. diff --git a/docs/wiki/Cryptography/intro.md b/docs/wiki/Cryptography/intro.md index 561af8be..7e146ddb 100644 --- a/docs/wiki/Cryptography/intro.md +++ b/docs/wiki/Cryptography/intro.md @@ -1,5 +1,7 @@ # Cryptography +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + Cryptography researchers craft the weapons or implements of change that developers use. They use advanced algebra to exploit the hard limits set by the universe on reality and craft cryptographic schemas that obey certain properties. They are in a sense reality-hackers. They hack reality to create systems that obey objective properties due to the underlying mathematics. https://summerofprotocols.com/wp-content/uploads/2023/12/53-BEIKO-001-2023-12-13.pdf \ No newline at end of file diff --git a/docs/wiki/EL/RLP.md b/docs/wiki/EL/RLP.md new file mode 100644 index 00000000..64ff9339 --- /dev/null +++ b/docs/wiki/EL/RLP.md @@ -0,0 +1,189 @@ +# Recursive-Length Prefix (RLP) Serialization + +Recursive Length Prefix (RLP) is a core serialization protocol used within the execution layer for encoding and parsing data. It is designed to serialize data and produce a structure readable by all client software. It is used for everything from transaction data to the entire state of the blockchain. This wiki page explores the internals of RLP, its encoding/decoding rules, tools available and its role in Ethereum's functionality. + +## Data Serialization in Ethereum + +Data serialization is the process of converting data structures or objects into a byte stream for storage, transmission, or later reconstruction. In distributed systems like Ethereum, serialization is crucial for transmitting data across network nodes reliably and efficiently. Clients written in different languages need to be able to process data the same way. Data communicated to other nodes or exported by the client need to have a standard format. While there are common serialization formats like JSON, XML or Protobuf, Ethereum uses its own protocols for its simplicity and effectiveness in encoding nested arrays of bytes. + +> Ethereum actually utilizes 2 formats: RLP and Simple Serialize (SSZ) which is more modern standard used by consensus layer. + +## How RLP Algorithm works + +**RLP encoding algorithm** + +Here is a flow chart describing how RLP encoding algorithm works. + +_Note that in some RLP tools, some clients may add additional conditional cases to the flow. These additional cases are not part of the standard specification but they are useful for the clients for the correct data serialization, e.g. geth client node communicating with a Nethermind client node._ + +```mermaid +flowchart TD + A[Start: Input] --> B{Is Input null, empty string, or false?} + B -->|Yes| C[Encode as Single Byte 0x80] + B -->|No| D{Is it a Single Byte and < 0x80?} + D -->|Yes| E[Directly Encode the Byte] + D -->|No| F{Is it a String or List?} + F -->|String| G{String Length <= 55} + G -->|Yes| H[Encode with Length + 0x80] + G -->|No| I[Encode Length with 0xB7 + Length Bytes] + F -->|List| J{Total Encoded Items Length <= 55} + J -->|Yes| K[Encode with Total Length + 0xC0] + J -->|No| L[Encode Total Length with 0xF7 + Length Bytes] + H --> M[Output Encoded Data] + I --> M + K --> M + L --> M + E --> M + C --> M +``` + +_Figure: RLP Encoding Flow_ + +**RLP decoding algorithm** + +Here is a flow chart describing how RLP decoding algorithm works. + +```mermaid +flowchart TD + A[Start: Encoded Input] --> B{Check First Byte} + B -->|0x00 to 0x7F| C[Direct Byte Output] + B -->|0x80| D[Decode as Empty String/Null/False] + B -->|0x81 to 0xB7| E[Short String] + E --> F[Subtract 0x80 from First Byte to get Length] + F --> G[Output Next 'Length' Bytes as String] + B -->|0xB8 to 0xBF| H[Long String] + H --> I[Subtract 0xB7 from First Byte to get Length Bytes Count] + I --> J[Read Next 'Length Bytes Count' to Determine String Length] + J --> K[Output Next 'String Length' Bytes as String] + B -->|0xC0 to 0xF7| L[Short List] + L --> M[Subtract 0xC0 from First Byte to get Total Encoded Length] + M --> N[Decode Each Element in the Next 'Total Encoded Length' Bytes Recursively] + B -->|0xF8 to 0xFF| O[Long List] + O --> P[Subtract 0xF7 from First Byte to get Length Bytes Count] + P --> Q[Read Next 'Length Bytes Count' to Determine List Total Length] + Q --> R[Decode Each Element in the Next 'List Total Length' Bytes Recursively] + C --> S[Output Decoded Data] + D --> S + G --> S + K --> S + N --> S + R --> S +``` + +_Figure: RLP Decoding Flow_ + + +## RLP Encoding Rules + +Understanding how RLP encoding is derived requires a grasp of the specific rules applied based on the type and size of the data. Let's explore these rules using an example to demonstrate how different types of data are encoded. + +If you are not familiar with converting the strings to hex, you may refer to this [ASCII chart](https://www.asciitable.com/). + +### Detailed Explanation of RLP Encoding Rules with Example + +Recursive Length Prefix (RLP) is a fundamental data serialization technique used in Ethereum to encode structured data into a sequence of bytes. Understanding how RLP encoding is derived requires a grasp of the specific rules applied based on the type and size of the data. Let's explore these rules step-by-step using an example to demonstrate how different types of data are encoded. + +**Single Byte Encoding** + - **Condition**: If the input is a single byte and its value is between `0x00` and `0x7F` (inclusive). + - **Encoding**: The byte is encoded directly, unchanged. + - **Example**: Encoding the byte `0x2a` directly yields `0x2a`. + +**Short String Encoding (1-55 bytes)** + - **Condition**: If the string (or byte array) length is between 1 and 55 bytes. + - **Encoding**: The output is the length of the string plus `0x80`, followed by the string itself. + - **Example**: Encoding the string "dog" (`0x64, 0x6f, 0x67`) results in `0x83, 0x64, 0x6f, 0x67`. Here, `0x83` is `0x80 + 3` (the length of "dog"). + +**Long String Encoding (over 55 bytes)** + - **Condition**: If the string length exceeds 55 bytes. + - **Encoding**: The length of the string is encoded as a byte array in big-endian format, prefixed by `0xb7` plus the length of this length array. + - **Example**: For a string of length 56, the length `0x38` is encoded, preceded by `0xb8` (`0xb7 + 1`). The resulting encoding starts with `0xb8, 0x38`, followed by the string's bytes. + +**Short List Encoding (total payload 1-55 bytes)** + - **Condition**: If the total encoded payload of the list's items is between 1 and 55 bytes. + - **Encoding**: The list is prefixed with `0xc0` plus the total length of the encoded items. + - **Example**: For a list `["cat", "dog"]`, each item is first encoded to `0x83, 0x63, 0x61, 0x74` and `0x83, 0x64, 0x6f, 0x67`. The total length is 8, so the prefix is `0xc8` (`0xc0` + 8 = `0xc8`). The entire encoding is `0xc8, 0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67`. + +**Long List Encoding (total payload over 55 bytes)** + - **Condition**: If the total encoded payload of the list's items exceeds 55 bytes. + - **Encoding**: Similar to long strings, the length of the payload is encoded in big-endian format, prefixed by `0xf7` plus the length of this length array. + - **Example**: For a list `["apple", "bread", ...]` exceeding 55 bytes, suppose the payload length is 57. The length `0x39` is encoded, preceded by `0xf8` (`0xf7 + 1`), followed by the encoded list items. + +**Null, Empty String, Empty List and False** + - Rule for Empty string, Null and False: Encoded as a single byte `0x80`. + - Rule for Empty List: Encoded as `0xc0`. + - Examples: + - Encoding an empty string or a null value or false, (` `, `null`, `false`), result in `0x80`. + - Encoding an empty list, `[]`, results in `0xc0`. + +## RLP Decoding Rules + +The RLP decoding process is based on the structure and specifics of the encoded data: + +**Determine Data Type**: + - The first byte (prefix) of the encoded data determines the type and length of the data that follows. This byte is critical in guiding the decoding process. +**Decoding Single Bytes**: + - If the prefix byte is in the range `0x00` to `0x7F`, the byte itself represents the decoded data. This case is straightforward as the byte is encoded directly. +**Decoding Strings and Lists**: + - The complexity in decoding arises with strings and lists, which have varying lengths and may contain nested structures. +**Short Strings (0x80 to 0xB7)**: + - If the prefix byte is between `0x80` and `0xB7`, it indicates a string whose length can be directly determined by subtracting `0x80` from the prefix. The following bytes equal the length are the string. +**Long Strings (0xB8 to 0xBF)**: + - For longer strings, if the prefix byte is between `0xB8` and `0xBF`, the number of length bytes is determined by subtracting `0xB7` from the prefix. The subsequent bytes represent the length of the string, and the bytes following represent the string itself. +**Short Lists (0xC0 to 0xF7)**: + - Similar to short strings, a prefix between `0xC0` and `0xF7` indicates a list. The length of the list's encoded data can be determined by subtracting `0xC0` from the prefix. The bytes that follow must then be decoded recursively as individual RLP encoded items. +**Long Lists (0xF8 to 0xFF)**: + - For longer lists, a prefix between `0xF8` and `0xFF` indicates that the next few bytes (determined by subtracting `0xF7` from the prefix) will tell the length of the list's encoded data. The data following these length bytes is then recursively decoded into RLP items. + +**Examples of RLP Decoding of `[0xc8, 0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67]`** + +- **Identify the Prefix** + - The sequence starts with the byte `0xc8`. In RLP, a list's length prefix starts at `0xc0`. The difference between `0xc8` and `0xc0` gives us the length of the list content. + - `0xc8 - 0xc0 = 8` + - This tells us that the next 8 bytes are part of the list. +- **Decode the List Content** + - The list content in this example is `[0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67]`. + - We will decode this content byte by byte to extract the individual items. +- **Decode the First Item** + - The first byte of the list content is `0x83`. In RLP, for strings where the length is between 1 and 55 bytes, the length prefix starts at `0x80`. Thus: + - `0x83 - 0x80 = 3` + - This tells us that the first string has a length of `3` bytes. + - The next three bytes are `0x63, 0x61, 0x74`, which correspond to the ASCII values for "cat". + - We have now decoded the first item: "cat". +- **Decode the Second Item** + - After decoding the first item, the next byte in the sequence is another `0x83`. + - Following the same rule as before: + - `0x83 - 0x80 = 3` + - This indicates the next string also has a length of 3 bytes. + - The following three bytes are `0x64, 0x6f, 0x67`, corresponding to "dog". + - We have now decoded the second item: "dog". +- The decoded output is `["cat", "dog"]`. + +## The Need for RLP in Ethereum + +> RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike protobuf, BSON and other existing solutions, RLP does not attempt to define any specific data types such as booleans, floats, doubles or even integers; instead, it simply exists to store structure, in the form of nested arrays, and leaves it up to the protocol to determine the meaning of the arrays. +> -- Ethereum's design rationale + +RLP was created with Ethereum and is tailored to meet its specific needs: +- Minimalistic Design: It focuses purely on storing structure without imposing data type definitions. +- Consistency: It guarantees byte-perfect consistency across different implementations, crucial for the deterministic nature required in blockchain operations. + +## RLP Tools + +There are many libraries available for RLP implementations in Ethereum. Here are few tools: +- [Geth RLP](https://github.com/ethereum/go-ethereum/tree/master/rlp) +- [RLP Dump](https://github.com/ethereum/go-ethereum/tree/master/cmd/rlpdump) +- [RLP for Node.js and the browser.](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/rlp) +- [Python RLP serialization library.](https://github.com/ethereum/pyrlp) +- [RLP for Rust](https://docs.rs/ethereum-rlp/latest/rlp/) +- [Nethermind RLP Serialization](https://github.com/NethermindEth/nethermind/tree/master/src/Nethermind/Nethermind.Serialization.Rlp) + +## Resources +- [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Ethereum RLP documentation](https://ethereum.org/vi/developers/docs/data-structures-and-encoding/rlp/) +- [A Comprehensive Guide to RLP Encoding in Ethereum by Mark Odayan](https://medium.com/@markodayansa/a-comprehensive-guide-to-rlp-encoding-in-ethereum-6bd75c126de0) +- [Ethereum's RLP serialization in Elixir](https://www.badykov.com/elixir/rlp/) +- [Ethereum Under The Hood Part 3 (RLP Decoding)](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Ethereum's Recursive Length Prefix in ACL2](https://arxiv.org/abs/2009.13769) + + + diff --git a/docs/wiki/EL/devp2p.md b/docs/wiki/EL/devp2p.md new file mode 100644 index 00000000..929117f3 --- /dev/null +++ b/docs/wiki/EL/devp2p.md @@ -0,0 +1,7 @@ +# Execution p2p + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +The execution layer implements [devp2p](https://github.com/ethereum/devp2p) as its communication protocol with nodes in the network. It includes various subprotocols and features: eth, snap, les, pip, wit. + +Because libp2p (used by CL) was not ready when Ethereum was created, devp2p was created as Ethereum's own p2p protocol stack. \ No newline at end of file diff --git a/docs/wiki/EL/el-architecture.md b/docs/wiki/EL/el-architecture.md index 3f4c4cc1..77b4a366 100644 --- a/docs/wiki/EL/el-architecture.md +++ b/docs/wiki/EL/el-architecture.md @@ -178,23 +178,21 @@ In Ethereum two primary types of transaction pools are recognized: ### EVM -TODO Link to wiki page +[Wiki - EVM](/wiki/EL/evm.md) ### DevP2P -TODO Link to wiki page +[Wiki - DevP2P](/wiki/EL/devp2p.md) ### Data structures Blockchain and state data processed by execution client need to be stored in the disk. These are necessary to validate new blocks, verify history and to serve peers in the network. Client stores historical data, also called the ancient database, which include previous blocks. Another database of trie structure contains the current state and small number of recent states. In practice, clients keep various databases for different data categories. Each client can implement a different backend to handle this data, e.g. leveldb, pebble, mdbx. -More details in the page on [EL data structures](./data-structures.md). +More details in the page on [EL data structures](/wiki/EL/data-structures.md). -TODO Link to wiki page +#### RLP -### RLP - -TODO Link to wiki page +[Wiki - RLP](/wiki/EL/RLP.md) ### StateDB diff --git a/docs/wiki/EL/el-clients.md b/docs/wiki/EL/el-clients.md index f2e94d97..19e062f2 100644 --- a/docs/wiki/EL/el-clients.md +++ b/docs/wiki/EL/el-clients.md @@ -1,5 +1,7 @@ # Execution Layer Implementations +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + Resources covering all current and historical execution clients. Overview of client unique features of each client, architecture, guides and resources. ## Clients in production diff --git a/docs/wiki/EL/el-specs.md b/docs/wiki/EL/el-specs.md index e69de29b..f5b68320 100644 --- a/docs/wiki/EL/el-specs.md +++ b/docs/wiki/EL/el-specs.md @@ -0,0 +1,7 @@ +# Execution layer specification + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Apart from the yellow paper and changes tracking in EIPs, the main specification of the execution layer is in [EL pyspec](https://github.com/ethereum/execution-specs). + +This is executable specification used for client implementers as a reference and test generation tool. Learn more about it in [week 6](/eps/week6-dev.md) presentation. \ No newline at end of file diff --git a/docs/wiki/dev/core-development.md b/docs/wiki/dev/core-development.md index 99ca277b..733cc6c6 100644 --- a/docs/wiki/dev/core-development.md +++ b/docs/wiki/dev/core-development.md @@ -1,11 +1,27 @@ # Core development -The core Ethereum protocol (Layer 1) is continuously developed by the community through EIPs, which open up the possibility of introducing changes to the base protocol. -Resources for aspiring core developers. -What is it like to work on the core protocol? -What is it like to work in FOSS? +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. -https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04208.html -https://www.youtube.com/watch?v=R-Xr1JRF6bY -https://www.coindesk.com/consensus-magazine/2023/02/22/a-day-in-the-life-of-a-dev-ethereums-justin-florentine/ -https://protocol-guild.readthedocs.io/en/latest/ +The work on core protocol specification, implementation and testing is commonly referred to as core development. Core devs are contributors the client software, its validation and related tooling for building the protocol, all domains covered in this wiki. + +There are many implementation of both [consensus](/wiki/CL/cl-clients.md) and [execution](/wiki/EL/el-clients.md) layer developed by various independent teams. Together with teams working on research, testing and other infrastracture, core developers are maintaining the base technology used by everyone building on Ethereum. + +![Space Core Devs](../../images/space-core-devs.png) + +[Hsiao-Wei Wang](https://github.com/hwwhww) shared the graphic above in her presentation _[A Journey of an Ethereum Core Dev/Researcher”](https://www.youtube.com/watch?v=0lBrd2_fPPU)_ she gave at ETHGlobal Tokyo in April 2023. The graphic symbolizes the connection between a space station and the efforts involved from various teams to bring it to life. + +Teams working on separate clients are distributed across different organizations, companies or non-profits. They implement the same specification in different languages with various features and performance profiles. The [client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity) is a fundamental principle embraced by Ethereum. The range of different clients can ensure stability and security of the network while keeping the core development decentralized and open to everyone. + +Although different teams come from different organization, they all work together and collaborate on improving the whole network. Progress is achieved through discussions in public channels, mainly carried out in weekly meetings. These calls are public and tracked in [project management repo](https://github.com/ethereum/pm), including ACD - Execution and Consensus Layer calls, various "Breakout Room" and working group calls. Outside of calls, discussions are held in the Ethereum R&D Discord channel, Eth Magicians forum and EthResearch forum. + +# Appendix + +[A Day in the Life of a Dev: Ethereum’s Justin Florentine](https://www.coindesk.com/consensus-magazine/2023/02/22/a-day-in-the-life-of-a-dev-ethereums-justin-florentine/) + +[Protocol Guild](https://protocol-guild.readthedocs.io/en/latest/) + +[Protocol Guild: Funding Core Protocol Stewardship | Cheeky Gorilla - Protocol Guild ETHDenver 2024 Presentation](https://www.youtube.com/watch?v=9Tc2g7pu-gc&ab_channel=ETHDenver) + +[Protocol Guild Pledge](https://tim.mirror.xyz/srVdVopOFhD_ZoRDR50x8n5wmW3aRJIrNEAkpyQ4_ng) + +[Capital and enclosure in software commons: Linux & Ethereum](https://trent.mirror.xyz/GDDRqetgglGR5IYK1uTXxLalwIH6pBF9nulmY9zarUw) diff --git a/docs/wiki/dev/cs-resources.md b/docs/wiki/dev/cs-resources.md index 6d9f5797..e8b43d51 100644 --- a/docs/wiki/dev/cs-resources.md +++ b/docs/wiki/dev/cs-resources.md @@ -41,11 +41,14 @@ - 🎥 [Berkeley CS 61A: Structure and Interpretation of Computer Programs](https://cs61a.org/) - 🎥 [Parallel Programming](https://www.coursera.org/learn/scala-parallel-programming) - 🎥 [Compilers](https://www.edx.org/course/compilers) +- [Mastering programming](https://tidyfirst.substack.com/p/mastering-programming) - 📄 [Awesome c++ (or C)](https://github.com/fffaraz/awesome-cpp) - 📄 [Awesome go](https://github.com/avelino/awesome-go) - 📄 [Awesome rust](https://github.com/rust-unofficial/awesome-rust) - 📄 [Awesome javascript](https://github.com/sorrycc/awesome-javascript) - 📄 [Awesome python](https://github.com/vinta/awesome-python) +- 🎥 [George Hotz | Programming | rewriting linearizer (tinygrad) | Day In The Life Of A Software Engineer](https://www.youtube.com/watch?v=R-Xr1JRF6bY) + ## Networking @@ -76,7 +79,8 @@ - 🎥 [The Missing Semester of Your CS Education | MIT](https://missing.csail.mit.edu/) - 🎥 [The Unix Workbench | Johns Hopkins](https://www.coursera.org/learn/unix) - +- 📄 [Git tips and tricks](https://blog.gitbutler.com/git-tips-and-tricks/) +- 📄 [Popular Git config options](https://jvns.ca/blog/2024/02/16/popular-git-config-options/) ## Misc - 📄 [Things Every Programmer Should Know](https://github.com/mtdvio/every-programmer-should-know) diff --git a/docs/wiki/dev/developer-resources.md b/docs/wiki/dev/developer-resources.md deleted file mode 100644 index a3b3d30b..00000000 --- a/docs/wiki/dev/developer-resources.md +++ /dev/null @@ -1,11 +0,0 @@ -# Resources for aspiring devs - -https://tidyfirst.substack.com/p/mastering-programming - -## Git - -Git is an important tool for any developer and contributor to this repository. It's a distributed version control system which helps us to track changes and coordinate our work. Created by Linus Torvalds almost 20 years ago, it's widely used in probably every FOSS project out there. Here are few resources to learn more about using it effectively: - -https://blog.gitbutler.com/git-tips-and-tricks/ - -https://jvns.ca/blog/2024/02/16/popular-git-config-options/ \ No newline at end of file diff --git a/docs/wiki/dev/pm.md b/docs/wiki/dev/pm.md index c0eee431..37e77434 100644 --- a/docs/wiki/dev/pm.md +++ b/docs/wiki/dev/pm.md @@ -1,5 +1,7 @@ # Core development coordination +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + Because of the approach of client diversity and decentralization, Ethereum core development is spread across many teams from various organizations. Roughly estimated, there is around 200+ client developers, researchers, testers and other contributors split across ~20 teams. To effectively maintain and implement various initiatives affecting the Ethereum protocol, all of these people need be able to reach consensus and collaborate in a productive manner. Generally, this is possible thanks to free and open source nature of Ethereum and it's design and development based unix philosophy but still requires lot of coordination work. diff --git a/docs/wiki/dev/upgrades.md b/docs/wiki/dev/upgrades.md deleted file mode 100644 index e69de29b..00000000 diff --git a/docs/wiki/epf.md b/docs/wiki/epf.md index e69de29b..a1008f11 100644 --- a/docs/wiki/epf.md +++ b/docs/wiki/epf.md @@ -0,0 +1,11 @@ +# Ethereum Protocol Fellowship + +EPF is a program for everyone interested in starting to contribute to Ethereum core protocol. Organized by EF Protocol Support, the program is divided into yearly cohorts, each running for 4-5 months. The program was originally started as CDAP by Piper Merriam and grew with each cohort. + +Because the protocol, its development and research is fully public and open, anyone can start contributing. But the understanding of current issues, identifying a project to work on and connecting with other contributors can pose a barrier to start, EPF helps to smooth this process. + +The fellowship is fully open and permissionless, anyone can join the community to start working their area of interest. The cohort opens up with an application process and ends with EPF Day in-person event at Devcon. The most active and skilled contributors might be eligible for stipend at the start of the cohort based on their application or retrospectively. + +> Upcoming EPF cohorts are announced when applications open. Follow the [mailing list, ESP discord and EF blog](/eps/intro.md#important-links) to stay informed. + +All work done within EPF cohorts can be found in [eth-protocol-fellows repositories](https://github.com/orgs/eth-protocol-fellows/repositories). Each cohort repo includes `/projects` directory with all project proposals and `dev-updates.md` document tracking weekly progress of every participant. Use these resources to learn about the protocol, fellows' work and get inspiration for your own projects. \ No newline at end of file diff --git a/docs/wiki/protocol/architecture.md b/docs/wiki/protocol/architecture.md index e69de29b..fa736c45 100644 --- a/docs/wiki/protocol/architecture.md +++ b/docs/wiki/protocol/architecture.md @@ -0,0 +1,13 @@ +# Protocol Architecture Overview + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +The current protocol architecture is a result of years of evolution. The protocol consists of 2 main parts - execution and consensus layer. The execution layer (EL) handles the actual transactions and user interactions, it's where the global computer executes its programs. The consensus layer (CL) provides the proof-of-stake consensus mechanism - a cryptoeconomic security making sure all nodes follow the same tip and drives the canonical chain of execution layer. + +In practice, these layers are implemented in its own clients connected via API. Each have their own p2p network handling different kind of data. + +![](./img/clients-overview.png) + +Looking under the hood of each client, they consists of many fundamental functions: + +![](./img/protocol-overview.png) diff --git a/docs/wiki/protocol/design-rationale.md b/docs/wiki/protocol/design-rationale.md index 9a06a1f4..2690a27d 100644 --- a/docs/wiki/protocol/design-rationale.md +++ b/docs/wiki/protocol/design-rationale.md @@ -1,6 +1,9 @@ # Protocol Design Philosophy -Page covering development philosophy and design rationale of the protocol. +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. -https://vitalik.eth.limo/general/2022/02/28/complexity.html -https://web.archive.org/web/20211121044757/https://ethereumbuilders.gitbooks.io/guide/content/en/design_rationale.html \ No newline at end of file +The Ethereum protocol evolves and changes over time but it always follow certain principles. These principles reflect values of the whole community and are reflected in some of the main design decisions of Ethereum. + +- https://web.archive.org/web/20211121044757/https://ethereumbuilders.gitbooks.io/guide/content/en/design_rationale.html + +- https://vitalik.eth.limo/general/2022/02/28/complexity.html diff --git a/docs/wiki/protocol/history.md b/docs/wiki/protocol/history.md index 6c2d0487..8d25bc35 100644 --- a/docs/wiki/protocol/history.md +++ b/docs/wiki/protocol/history.md @@ -1,4 +1,6 @@ -# History +# Protocol history and evolution + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. This page highlights important technical changes in the history of Ethereum protocol. @@ -8,7 +10,7 @@ Useful links: [Overview from Ethereum.org](https://ethereum.org/en/history) and TODO -## The Merge. +## The Merge On September 15, 2022, Ethereum activated [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) and upgraded the consensus mechanism to proof-of-stake through an event known as The Merge. The Merge has resulted in the deprecation of the proof-of-work consensus, which was previously implemented in the same logic layer as execution. Instead, it has been replaced by a more complex and sophisticated proof-of-stake consensus that eliminates the need for energy-intensive mining. New proof-of-stake consensus has been implemented in its own layer with a separate p2p network and logic, also know as Beacon Chain. The Beacon Chain has been running and achieving consensus since December 1st, 2020. After a prolonged period of consistent performance without any failures, it was deemed ready to become Ethereum's consensus provider. The Merge gets its name from the union of the two networks. diff --git a/docs/wiki/protocol/img/clients-overview.png b/docs/wiki/protocol/img/clients-overview.png new file mode 100644 index 00000000..92cb84fb Binary files /dev/null and b/docs/wiki/protocol/img/clients-overview.png differ diff --git a/docs/wiki/protocol/img/protocol-overview.png b/docs/wiki/protocol/img/protocol-overview.png new file mode 100644 index 00000000..329386f2 Binary files /dev/null and b/docs/wiki/protocol/img/protocol-overview.png differ diff --git a/docs/wiki/research/img/full_roadmap2024_1600x1596.webp b/docs/wiki/research/img/full_roadmap2024_1600x1596.webp new file mode 100644 index 00000000..409cbeb5 Binary files /dev/null and b/docs/wiki/research/img/full_roadmap2024_1600x1596.webp differ diff --git a/docs/wiki/research/roadmap.md b/docs/wiki/research/roadmap.md index 81f39f2d..00abec53 100644 --- a/docs/wiki/research/roadmap.md +++ b/docs/wiki/research/roadmap.md @@ -1,3 +1,136 @@ -# Roadmap +# Ethereum Protocol Roadmap -Overview of the research landscape. Check week 5 presentation. \ No newline at end of file +The development philosophy of Ethereum is open to protocol evolution and certain risk aversion for benefits which are worth the change. As our knowledge and experience of Ethereum grows, researchers and developers are crafting ideas on how to tackle challenges and limitations of the network. There has been [many changes](/wiki/protocol/history.md) to the core protocol over many years of its existence. Most of these changes are part of some common goals we could call a roadmap. + +Even though there is no official roadmap and no authority which could dictate it, there are wide community discussions steering the protocol development in certain ways. By agreeing on some goals and reaching consensus about current state of the development, the community, dev and research teams work together to progress in this abstract roadmap. + +## The Infinite Garden + +> *Ethereum is NOT a zero sum game with a clear finish line, but rather a game that we want to play continuously. For that to be a reality, the Infinite Garden needs to upgrade regularly, on topics like its security, scalability or sustainability, until it reaches ossification. After that point there will probably be, just some trims - here and there.* + +## Core R&D + +The discussion, resources and all research and development on the core protocol is fully open, free and public. Anyone can learn about it (as you are probably doing in this wiki) and further more, anyone can participate. There is no set of individuals which could push core protocol changes, the Ethereum community can raise the voice to help steer the discussion. To learn more about the core R&D shaping the protocol, read the [wiki page about it](/wiki/dev/core-development.md). + +## Roadmap overview + +While there is not a single roadmap that Ethereum development follows, we can track the current R&D efforts to map what changes are happening and might happen in the future. +A popular overview mapping many domains of the current core research and development is Vitalik's chart (December 2023): + +![Ethereum roadmap updated by V.B. Dec2023](/docs/wiki/research/img/full_roadmap2024_1600x1596.webp) + +In this overview, different domains are coupled to related categories forming various 'urges'. Many of these boxes are have their own page on this wiki where you can study more. + +### The Merge + +Upgrades relating to the switch from proof-of-work to proof-of-stake. The Merge was successfully achieved at Thu Sep 15 06:42:42 2022 UTC, reducing the network's annualized electricity consumption by more than 99.988%. However, this category also tracks subsequent upgrades which can be done to improve the consensus mechanism and smooth issues we encounter after The Merge. + +**IMPLEMENTED** +| Upgrade | Description | Effect | State of the art | +| :----------------------------------- | :-------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------- | +| Launch the Beacon Chain | A crucial step in Ethereum's shift to a proof of stake consensus mechanism | Beacon Chain becomes the engine of block production, replacing mining. Validators have the role and responsibility for processing the validity of all transactions and proposing blocks | shipped
EIP-2982[^1] | +| Merge Execution and Consensus Layers | Ethereum's execution layer merged with the Beacon chain (consensus layer) | Proof of work activities ceased and the network's consensus mechanism shifted to proof of stake | shipped | +| Enable Withdrawals | The last of the three-part process of Ethereum's transition to a proof of stake consensus mechanism | Validators can push withdrawals from the Beacon chain to the EVM via a new "system-level" operation type | shipped
EIP-4895[^2] | + +**TODO** +| Upgrade | Description | Expected effect | State of the art | +| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------- | +| Single slot finality (SSF) | Blocks could be proposed and finalized in the same slot | (i) more convenient for apps (transactions finalization time improved by an order of magnitude, i.e. 12 seconds instead of 12 minutes means better UX for all), (ii) much more difficult to attack (multi block MEV re-orgs can be eliminated and the complexity in consensus mechanism, reduced) | in research
(i) VB's SSF notes[^4]
(ii) 8192 signatures post-SSF[^5]
(iii) simple SSF protocol[^6] | +| Single Secret Leader Election (SSLE) | Allow elected block proposers to remain private until block publishing, to prevent DoS attacks | Only the selected validator knows it has been selected to propose a block. | in research
EIP-7441[^7] | +| Enable more Validators | The technical challenge of efficiently coordinating an ever increasing number of validators to achieve SSF with the best trade-offs possible | Greater redundancy, a broader range of proposers, a wider array of attesters, and overall increased resilience | in research
(i) EIP-7514[^8]
(ii) EIP-7251[^9]
(iii) 8192 signatures[^5] | +| Quantum-safe signatures | Proactive research and integration of quantum-resistant cryptographic algorithms | Quantum-safe, aggregation-friendly signatures will enhance protocol security against quantum attacks | in research
(i) lattice-based[^10]
(ii) STARK-based [^11] systems | +### the Surge +Upgrades related to scalability by Roll-ups and Data Sharding. + +**IMPLEMENTED** +| Upgrade | Description | Expected effect | State of the art | +| :----------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------: | :------------------------- | +| Proto-danksharding | We can stop storing Rollup data permanently on Ethereum and move the data into a temporary 'blob' storage that gets deleted from Ethereum once is no longer needed | Reduced transaction costs | shipped
EIP-4844[^12] | + +**TODO** +| Upgrade | Description | Expected effect | State of the art | +| :---------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------- | +| Danksharding | Danksharding is the full realization of the rollup scaling that began with Proto-Danksharding | Massive amounts of space on Ethereum for rollups to dump their compressed transaction data | in research
| +| Data Availability Sampling (DAS) | Data Availability Sampling is a way for the network to check that data is available without putting too much strain on any individual node | (i) ensure rollup operators make their transaction data available after EIP-4844 (ii) ensure block producers are making all their data available to secure light clients (iii) under proposer-builder separation, only the block builder would be required to process an entire block, other validators would verify using data availability sampling | in research
EIP-7594[^13] | +| Removing Rollup Training Wheels | (i) Optimistic Rollup Fault Provers
(ii) ZK-EVMs
(iii) Rollup interoperability | (i) Optimistic rollups having live proof systems will address the L2's censorship risk
(ii) Massive improvements to Ethereum's scalability and privacy without sacrificing the security and decentralization aspects of the chain via zkEVMs (EVM-compatible virtual machines that supports zero-knowledge proof computation)
(iii) L1 Sequencers, or Ethereum L1 proposers with given rollup sequencing rights will bring better credible-neutrality and security, and offer roll-ups L1 compatibility | in research
(i)Arbitrum BoLD[^14]
Optimism Cannon[^15]
(ii) ZK-EVMs [^16] [^17] [^18]
(iii) Based preconfs[^19]
ET[^20] | +| Quantum-safe and Trusted-Setup-Free Commitments | replace KZG commitments with commitments that don't require a trusted setup and are quantum safe | Quantum-safe Commitments | in research
| + +### the Scourge +Upgrades related to censorship resistance, decentralization and mitigating protocol risks from MEV and liquid staking/pooling. + +**IMPLEMENTED** +| Upgrade | Track | Topic | Description | Effect | State of the art | +| :-------- | :-------: | :-------------------------------: | :------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------- | +| MEV-Boost | MEV-Track | Endgame Block Production Pipeline | Extra-protocol MEV markets | Ethereum community successfully commoditized MEV (partially), via an extra-protocol market. The majority of MEV goes now to Validators. | [shipped](/wiki/research/PBS/mev-boost.md)
| + +**TODO** + +| Upgrade | Track | Topic | Description | Expected effect | State of the art | +| :------ | :-------: | :-------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------- | +| ePBS | MEV-Track | Endgame Block Production Pipeline | Enshrinement of block Proposer and block Builder separation at protocol level, because of anti-censorship and MEV risk mitigation reasons | (i) creates opportunities to prevent transaction censorship at the protocol level
(ii) prevents hobbyist validators from being out-competed by institutional players that can better optimize the profitability of their block building
(iii) helps with scaling Ethereum by enabling the Danksharding upgrades | [in research](/wiki/research/PBS/ePBS.md)[^21]
| + +### the Verge +Upgrades related to verifying blocks more easily + +| Upgrade | Track | Topic | Description | Expected effect | State of the art | +| :------ | :---: | :---: | :---------: | :-------------: | :--------------- | +| | | | | | | + +### the Purge +Upgrades related to reducing the computational costs of running nodes and simplifying the protocol + +### the Splurge +Other upgrades that don't fit well into the previous categories. + +## Resources: + +[^1]: EIP-2982: Serenity Phase 0 https://eips.ethereum.org/EIPS/eip-2982, [[archived]](https://web.archive.org/web/20230928204358/https://eips.ethereum.org/EIPS/eip-2982) + +[^2]: EIP-4895: Beacon chain push withdrawals https://eips.ethereum.org/EIPS/eip-4895, [[archived]](https://web.archive.org/web/20240415201815/https://eips.ethereum.org/EIPS/eip-4895) + + +[^4]: VB's SSF notes https://notes.ethereum.org/@vbuterin/single_slot_finality, [[archived]](https://web.archive.org/web/20240330010706/https://notes.ethereum.org/@vbuterin/single_slot_finality) + +[^5]: Sticking to 8192 signatures per slot post-SSF https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989. [[archived]](https://web.archive.org/web/20240105131126/https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989) + +[^6]: A simple Single Slot Finality protocol https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920, [[archived]](https://web.archive.org/web/20231214080806/https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920) + +[^7]: EIP-7441: Upgrade BPE to Whisk https://eips.ethereum.org/EIPS/eip-7441, [[archived]](https://web.archive.org/web/20231001031437/https://eips.ethereum.org/EIPS/eip-7441) + +[^8]: EIP-7514: Add Max Epoch Churn Limit https://eips.ethereum.org/EIPS/eip-7514, [[archived]](https://web.archive.org/web/20240309191714/https://eips.ethereum.org/EIPS/eip-7514) + +[^9]: EIP-7251:Increase the MAX_EFFECTIVE_BALANCE https://eips.ethereum.org/EIPS/eip-7251, [[archived]](https://web.archive.org/web/20240324072459/https://eips.ethereum.org/EIPS/eip-7251) + +[^10]: Medium post on lattice encryption https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175, [[archived]](https://web.archive.org/web/20230623222155/https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) + +[^11]: VB's hackmd post on STARK signature aggregation https://hackmd.io/@vbuterin/stark_aggregation, [[archived]](https://web.archive.org/web/20240313124147/https://hackmd.io/@vbuterin/stark_aggregation) + +[^12]: EIP-4844: Shard Blob Transactions https://eips.ethereum.org/EIPS/eip-4844, [[archived]](https://web.archive.org/web/20240326205709/https://eips.ethereum.org/EIPS/eip-4844) + +[^13]: EIP-7594: PeerDAS https://github.com/ethereum/EIPs/pull/8105 + +[^14]: BoLd: dispute resolution protocol https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf + +[^15]: Fault proofs bring permissionless validation to the OP Sepolia testnet https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/ + +[^16]: Parallel Zero-knowledge Virtual Machine https://eprint.iacr.org/2024/387, [[archived]](https://web.archive.org/web/20240415180222/https://eprint.iacr.org/2024/387) + +[^17]: What is zkEVM https://www.alchemy.com/overviews/zkevm, [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm) + +[^18]: Types of ZK-EVMs https://vitalik.eth.limo/general/2022/08/04/zkevm.html, [[archived]](https://web.archive.org/web/20240329112600/https://vitalik.eth.limo/general/2022/08/04/zkevm.html) + +[^19]: Based preconfirmations https://ethresear.ch/t/based-preconfirmations/17353, [[archived]](https://ethresear.ch/t/based-preconfirmations/17353) + +[^20]: Execution Tickets research page https://ethresear.ch/t/execution-tickets/17944, [[archived]](https://web.archive.org/web/20240401205945/https://ethresear.ch/t/execution-tickets/17944) + +[^21]: Barnabe - More pictures about proposers and builders https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ, [[archived]](https://web.archive.org/web/20240424010902/https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ) + +[^200]: Inclusion lists https://eips.ethereum.org/EIPS/eip-7547, [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547) + +[ethereum/EIPs github repository](https://github.com/ethereum/EIPs/tree/master#ethereum-improvement-proposals-eips) + +[Roadmap on Ethereum.org](https://ethereum.org/en/roadmap/) + +[ethroadmap.com](https://ethroadmap.com/) + +[Herc’s substack article on Ethereum roadmap](https://herccc.substack.com/p/the-ethereum-roadmap#%C2%A7relevant-researchproposals) diff --git a/docs/wiki/testing/hive.md b/docs/wiki/testing/hive.md index eddd3b09..b54dd43a 100644 --- a/docs/wiki/testing/hive.md +++ b/docs/wiki/testing/hive.md @@ -1,3 +1,7 @@ # Hive testing +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Hive is and end-to-end testing harness enabling to spin up various clients in a single network with different testing scenarios (simulations). + https://github.com/ethereum/hive \ No newline at end of file diff --git a/docs/wiki/testing/incidents.md b/docs/wiki/testing/incidents.md index 9685046b..b614168e 100644 --- a/docs/wiki/testing/incidents.md +++ b/docs/wiki/testing/incidents.md @@ -1,4 +1,6 @@ # Notable mainnet incidents +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + - [Post-Mortem Report: Ethereum Mainnet Finality (05/11/2023)](https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2) - [Minority split 2021-08-27 post mortem](https://github.com/ethereum/go-ethereum/blob/master/docs/postmortems/2021-08-22-split-postmortem.md) \ No newline at end of file diff --git a/docs/wiki/wiki-intro.md b/docs/wiki/wiki-intro.md index 9464209b..843308ab 100644 --- a/docs/wiki/wiki-intro.md +++ b/docs/wiki/wiki-intro.md @@ -1,7 +1,14 @@ # Welcome to Protocol Wiki -Protocol Wiki has been created during EPF Study Group as an collaborative learning resource for anyone diving into Ethereum protocol and its development. +Protocol Wiki is a learning resource for anyone diving into Ethereum protocol, its development and research. It has been created during EPF Study Group as collaborative effort to create a contextual documentation of important domains of the protocol. ## Using the wiki -The wiki structure follows the design of Ethereum protocol. \ No newline at end of file +The wiki structure follows the design of Ethereum protocol. It's divided into sections mapping to important areas of the protocol and its development. Each section consists of pages covering its most relevant parts and provides a technical overview. Sections and its topics can be navigated in the left sidebar. + +> Wiki pages provide a context and explanation but also serve as a collection of external resources covering the topic. Use the resource section at the bottom of each page to learn more about the topic. + +To learn about a specific topic, identify what section it belongs to or use the search bar to find occurrences of the relevant term. If there is an important topic currently missing, open an [issue](https://github.com/eth-protocol-fellows/protocol-studies/issues) to let other know. For contributing yourself, check [contribution guidelines](/contributing.md) first. + +The wiki is written by a community of volunteers and continues to grow. Many pages are marked as _stubs_ and don't yet fully cover the topic. + diff --git a/wordlist.txt b/wordlist.txt index 13ddf7c2..30879bae 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -3,6 +3,7 @@ aantop ABI accelerometer ACD +ACL addons Aleth allowfullscreen @@ -52,12 +53,15 @@ blocksize bloXroute bloXroute's BLS +Bogotá Boneh bool +booleans bootup borderless BPE broadcasted +BSON Buterin Buterin's bypassability @@ -67,6 +71,7 @@ canonicalized Carb cartelization Casper +CDAP cdot cdots centralisation @@ -82,6 +87,7 @@ codebase codebases CODECOPY coinbase +commoditized Composability composable config @@ -131,6 +137,7 @@ Devs DEX Diffie DILITHIUM +Discordo discv distro docsify @@ -193,6 +200,7 @@ EVM evmlab EVMONE EVM's +EVMs excalidraw exchangeTransitionConfigurationV Explainer @@ -238,16 +246,18 @@ Goomy Goron Gorondan gpg -Grafana gradle gradlew +Grafana Grandine Guillaume hackmd Hager +Herc’s hoc Holesky homomorphic +Hotz Hsiao HSP Hulsing @@ -301,6 +311,7 @@ libp lifecycle Lightclient Lightclient's +linearizer liveness LLM LLMs @@ -317,9 +328,9 @@ mainnet Mana Mário mathbb -MDS mdbx MDBX +MDS meldsun mem Mempool @@ -331,6 +342,7 @@ Merkleize MEV mevboost Michaël +minimalistic Mitigations mload MMPTs @@ -365,6 +377,7 @@ NOXX NSS n't Occhipinti +Odayan OFAC Offchain offsites @@ -392,6 +405,7 @@ permissionless permissionlessness PGA Pilipovic +PKCS Playdate pmod POC @@ -400,7 +414,6 @@ Potuz's POV PQ PQC -PKCS PQCA pre precompile @@ -424,6 +437,7 @@ privateKey probabilistically programmability proto +protobuf prover Prover's Provers @@ -499,8 +513,8 @@ SNARKify socio solvm SPHINCS -src Sproul +src SSF SSLE SSTORE @@ -515,6 +529,8 @@ stf StreamEth subnets suboptimal +subprotocols +substack Summa systemd Takenobu @@ -526,9 +542,10 @@ testnets Tetris textnormal timeframe +tinygrad tldr -TODO TLS +TODO TPS tracoor Tracoor @@ -590,4 +607,24 @@ zk zkEVMs ZKSNARK ZKSNARKs -Zksync \ No newline at end of file +Schnorr +IETF +IRTF +Shacham +aggregative +atleast +computable +keystore +validator's +verifications +CLRS +Endian +Noam +Pyrmont +Goerli +financials +testnets +Hotz +linearizer +tinygrad +Zksync