diff --git a/docs/_navbar.md b/docs/_navbar.md index a828b46f..53376eea 100644 --- a/docs/_navbar.md +++ b/docs/_navbar.md @@ -1,3 +1,4 @@ * [Home](readme.md) * [Study Group](/eps/intro.md) +* [Protocol Wiki](/wiki/wiki-intro.md) * [Contribute](contributing.md) diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 4e5a1dfe..518d02db 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) @@ -70,10 +70,10 @@ - [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] + - Commitments - [KZG](/docs/wiki/Cryptography/KZG.md) - [Post-Quantum Cryptography](/wiki/Cryptography/post-quantum-cryptography.md) - [Protocol Fellowship](/wiki/epf.md) @@ -82,5 +82,5 @@ - [GitHub Repository](https://github.com/eth-protocol-fellows/protocol-studies)
- +
diff --git a/docs/assets/css/custom.css b/docs/assets/css/custom.css index fa004e2f..1daa56f8 100644 --- a/docs/assets/css/custom.css +++ b/docs/assets/css/custom.css @@ -154,4 +154,216 @@ body .markdown-section { line-height: 1.3; font-size: 14px; } -*/ \ No newline at end of file +*/ + +/* + ################################ + || || + || 🎨 EPF.WIKI Theme || + || || + ################################ +*/ + +:root { + --base-background-color: #1c153b; + --sidebar-name-color: #ba9afd; + --sidebar-background: #190c39; + --sidebar-toggle-background: #190c39; + --navbar-root-color--active: #ba9afd; + --search-input-background-color: #2d1763; + --table-row-odd-background: #2d1763; + + /* blockquote*/ + --blockquote-background: #2d1763; + --blockquote-color: #fff; + --blockquote-border-color: #ba9afd; + + /* link */ + --link-color: #ba9afd; +} + +/* sidebar */ +li.file, +li.folder { + transition: all 0.3s ease-in-out; + padding: 8px 15px; + margin-bottom: 4px; +} +li.file p, +li.folder p { + margin: 0; +} + +li.folder.active, +li.folder:hover, +li.folder.open, +li.file.active, +li.file:hover, +li.file.open { + border-radius: 5px; + background: #2d1763; +} + +.app-sub-sidebar li.file, +.app-sub-sidebar li.folder { + padding: 0; + margin: 0; + animation: tabFade 0.5s; +} + +li.folder strong, +li.file strong { + padding: 10px 0; + display: block; + border-bottom: 1px dashed #a278ff; +} + +li.folder > ul > li.file { + padding: 0; +} +.sidebar-nav ul.app-sub-sidebar a { + border: none; + border-left: 4px solid #fff; + padding-left: 8px; +} + +.sidebar-nav ul.app-sub-sidebar li.active > a, +.sidebar-nav ul.app-sub-sidebar li a:hover { + border-color: #ba9afd; + text-decoration: none; + color: #ba9afd; + border-left: 4px solid #ba9afd; +} + +.sidebar .search .input-wrap { + padding: 8px 15px; + margin: 0; + border-radius: 50px; + border: 2px solid #6660b9; +} +.sidebar .search input[type="search"], +.sidebar .search input[type="search"]:focus { + background-color: #2d1763; + outline: none; + box-shadow: none; +} +.sidebar-nav a:hover { + text-decoration: none; +} +@keyframes tabFade { + 0% { + opacity: 0; + } + + to { + opacity: 1; + } +} +/* content */ +.markdown-section img { + border-radius: 8px; +} +.markdown-section h2 a::before, +.markdown-section h3 a::before, +.markdown-section h4 a::before, +.markdown-section h5 a::before, +.markdown-section h6 a::before { + color: #ba9afd; + margin-right: 5px; +} + +.app-nav li a { + color: #fff; + font-weight: bold; +} + +.sidebar-toggle .sidebar-toggle-button { + padding: 20px; + border-radius: 5px; + --sidebar-toggle-icon-height: 8px; + --sidebar-toggle-icon-stroke-width: 2px; + background: #6e52a9; +} + +@media only screen and (min-width: 768px) { + .sidebar-toggle .sidebar-toggle-button { + padding: 20px; + border-radius: 5px; + --sidebar-toggle-icon-height: 8px; + --sidebar-toggle-icon-stroke-width: 5px; + background: #6e52a9; + } + .sidebar-toggle span:nth-child(1) { + transform: rotate(-45deg); + } + + .sidebar-toggle span:nth-child(2) { + display: none; + } + + .sidebar-toggle span:nth-child(3) { + transform: rotate(45deg); + } + + .ready-fix.close .sidebar-toggle span:nth-child(1) { + transform: rotate(45deg); + } + + .ready-fix.close .sidebar-toggle span:nth-child(3) { + transform: rotate(135deg); + } +} + +.sidebar-toggle span { + transition: transform 0.5s ease-in-out; +} + +.btn-primary, +.markdown-section a.btn-primary { + border: none; + outline: none; + cursor: pointer; + text-align: center; + border-radius: 3rem; + background: #ba9afd; + padding: 0.75rem 1.5rem 0.85rem; + font-size: 1.13rem; + font-weight: 500; + line-height: 1; + color: #190c39; + margin: 10px 0; + display: inline-block; + text-decoration: none; +} + +.btn-primary::after { + display: inline-block; + margin-left: 4px; + font-size: 22px; + content: "➡"; +} +body .pagination-item-title, +body .pagination-item-label { + font-weight: bold; + color: #fff; + opacity: 1; +} + +.app-name-link { + display: flex; + align-items: center; /* Vertical align */ + justify-content: center; + font-weight: bold; + font-size: 25px; +} + +.logo { + display: inline; + width: 40px; + margin-right: 5px; +} + +.markdown-section table { + display: table; + width: 100%; +} diff --git a/docs/eps/intro.md b/docs/eps/intro.md index d0d3c100..bca7e631 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](/eps/week2.md) | Execution Layer | [Lightclient](https://github.com/lightclient) | +| [Week 3](/eps/week3.md) | Consensus layer | [Alex Stokes](https://github.com/ralexstokes) | +| [Week 4](/eps/week4.md) | Testing and security | [Mario Vega](https://github.com/marioevz) | +| [Week 5](/eps/week5.md) | Roadmap and research | [Domothy](https://github.com/domothyb) | +| [Week 5](/eps/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](/eps/week6-dev.md) | Consensus and Execution specs | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) | +| [Week 6 Research](/eps/week6-research.md) | Sharding and DAS | [Dankrad Feist](https://github.com/dankrad) | +| [Week 7 Development](/eps/week7-dev.md) | Execution client architecture | [Dragan Pilipovic](https://github.com/dragan2234) | +| [Week 7 Research](/eps/week7-research.md) | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | +| [Week 8 Development](/eps/week8-dev.md) | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | +| [Week 8 Research](/eps/week8-research.md) | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | +| [Week 9 Development](/eps/week9-dev.md) | Devops and testing | [Parithosh](https://github.com/parithosh) | +| [Week 9 Research](/eps/week9-research.md) | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | +| [Week 10 Development](/eps/week10-dev.md) | EL precompiles | [Danno Ferrin](https://github.com/shemnon) | +| [Week 10 Research](/eps/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 @@ -85,7 +86,7 @@ For our weekly meetings, we are using a self-hosted FOSS platform Jitsi. Even th - **Will I learn to develop applications on the Ethereum blockchain?** - No. This program is not focused on Solidity or development of decentralized applications. - **When does it start and is the duration?** - - Program will start in February 2024 and continue for 10 weeks, finishing by end of April. + - The program ran from February 2024 and continued for 10 weeks, concluding by the end of April. - **Am I automatically accepted to EPF after attending EPFsg** - No. The study group is a great way to prepare for EPF, but it doesn't guarantee anything. However, EPF is a permissionless program, so you can always participate. - **Where is the study group located?** 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/index.html b/docs/index.html index df52dab1..791c3f92 100644 --- a/docs/index.html +++ b/docs/index.html @@ -33,7 +33,6 @@ href="https://cdn.jsdelivr.net/npm/docsify-themeable@0/dist/css/theme-simple-dark.css"> - @@ -111,7 +110,7 @@ } - + @@ -177,7 +176,7 @@ window.$docsify = { // GENERAL SETTINGS // ----------------------------------------------------------------- - name: 'Protocol Wiki', + name: ' Protocol Wiki', homepage: 'readme.md', loadSidebar: !(getURLParameterByName(['standalone', 'embedded']) || standalone || false), loadNavbar: !(getURLParameterByName(['standalone', 'embedded']) && !(getURLParameterByName('navbar')) || standalone && !navbar ||false), @@ -333,7 +332,7 @@ } else { url = gitLinkRepoURL + '/blob/main/docs/' + vm.route.file } - var editHtml = '[:memo:' + editThisPageLinkText + '](' + url + ')\n' + var editHtml = ` :memo: ${editThisPageLinkText}` if ((!(getURLParameterByName('hidegitlink'))) && (!!gitLinkRepoURL)) { return html + '
' + '\n\n' + editHtml diff --git a/docs/wiki/CL/cl-clients.md b/docs/wiki/CL/cl-clients.md index f1a2a225..fe27a406 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,11 @@ Teku also provides a slashing protection mechanism, especially in the case where ## Clients in development -### Grandine +### Caplin + +A consensus client embedded in Erigon. + +### Grandine Originally a proprietary client in Rust, recently became open source @@ -170,6 +173,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/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/EL/RLP.md b/docs/wiki/EL/RLP.md index 334a3554..64ff9339 100644 --- a/docs/wiki/EL/RLP.md +++ b/docs/wiki/EL/RLP.md @@ -72,6 +72,7 @@ flowchart TD _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. @@ -87,11 +88,6 @@ Recursive Length Prefix (RLP) is a fundamental data serialization technique used - **Encoding**: The byte is encoded directly, unchanged. - **Example**: Encoding the byte `0x2a` directly yields `0x2a`. -**Single Byte String Encoding** - - **Condition**: If the input is a single byte string. - - **Encoding**: The byte is encoded directly, unchanged. - - **Example**: Encoding the byte `0x74` directly yields `0x74`. - - **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. diff --git a/docs/wiki/EL/el-clients.md b/docs/wiki/EL/el-clients.md index 19e062f2..dcdb9db4 100644 --- a/docs/wiki/EL/el-clients.md +++ b/docs/wiki/EL/el-clients.md @@ -28,9 +28,13 @@ Developed in .NET Developed by Paradigm, recently considered stable +### Nimbus EL + +Execution client developed by Nimbus team as an addition to their Nim CL work. + ### Silkworm -Modular C++ implementation by Erigon team +Modular C++ implementation by Erigon team. Also called Erigon++. ### JS Client diff --git a/docs/wiki/dev/core-development.md b/docs/wiki/dev/core-development.md index a63be586..733cc6c6 100644 --- a/docs/wiki/dev/core-development.md +++ b/docs/wiki/dev/core-development.md @@ -2,13 +2,26 @@ > :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. -The core Ethereum protocol is continuously developed by the community through EIPs, which open up the possibility of introducing changes to the base protocol. +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. -Resources for aspiring core developers. -What is it like to work on the core protocol? -What is it like to work in FOSS? +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. -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/ +![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/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/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/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/notes/Week 10 EPFsg Research Track - Fork Choice.pdf b/notes/Week 10 EPFsg Research Track - Fork Choice.pdf new file mode 100644 index 00000000..8a3441a9 Binary files /dev/null and b/notes/Week 10 EPFsg Research Track - Fork Choice.pdf differ diff --git a/wordlist.txt b/wordlist.txt index 6c4d0335..40206965 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -68,9 +68,11 @@ bypassability bytecode calldata canonicalized +Caplin Carb cartelization Casper +CDAP cdot cdots centralisation @@ -86,6 +88,7 @@ codebase codebases CODECOPY coinbase +commoditized Composability composable config @@ -135,6 +138,7 @@ Devs DEX Diffie DILITHIUM +Discordo discv distro docsify @@ -195,6 +199,7 @@ ethresearch ethroadmap EVM EVM's +EVMs evmlab EVMONE excalidraw @@ -249,9 +254,11 @@ Grandine Guillaume hackmd Hager +Herc’s hoc Holesky homomorphic +Hotz Hsiao HSP Hulsing @@ -305,6 +312,7 @@ libp lifecycle Lightclient Lightclient's +linearizer liveness LLM LLMs @@ -523,6 +531,7 @@ StreamEth subnets suboptimal subprotocols +substack Summa systemd Takenobu @@ -534,6 +543,7 @@ testnets Tetris textnormal timeframe +tinygrad tldr TLS TODO @@ -598,7 +608,27 @@ zk zkEVMs ZKSNARK ZKSNARKs +Schnorr +IETF +IRTF +Shacham +aggregative +atleast +computable +keystore +validator's +verifications +CLRS +Endian +Noam +Pyrmont +Goerli +financials +testnets +Hotz +linearizer +tinygrad Zksync Hotz linearizer -tinygrad \ No newline at end of file +tinygrad