diff --git a/README.md b/README.md index 43724e41..59ab1f75 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,13 @@ -# Ethereum Protocol Fellowship Study Group +# Ethereum Protocol Fellowship Study Group (EPFsg) -This repository is dedicated to coordination and knowledge base for EPFsg. It hosts the Protocol Wiki, a community effort to build a technical knowledge base about the Ethereum core protocol. +This repository is dedicated to coordination and developing a knowledge base for the EPFsg. It hosts the Protocol Wiki, a community effort to build a technical knowledge base about the Ethereum core protocol. -Learn more about the EPFsg in announcement blog post and join the study group: https://blog.ethereum.org/2024/02/07/epf-study-group +[Learn more about the EPF study group](https://epf.wiki/#/eps/intro) and dive into the [wiki content](https://epf.wiki/#/README?id=protocol-wiki) to study the protocol. ## Protocol Studies Wiki -You can visit the wiki at https://epf.wiki or head to `/docs` for the source. +You can visit the wiki at https://epf.wiki or head to `/docs` for the source. -The wiki is mostly build by contributors from the EPF Study Group. Join us to learn about the protocol and start [contributing](/docs/contributing.md). +[Join us](https://discord.com/invite/addwpQbhpq) to learn about the protocol and start [contributing](/docs/contributing.md). ![](/docs/images/epfsg_hero.jpg) diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 074f4a6a..02c0c28e 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -22,6 +22,7 @@ - [Contributing](contributing.md) - **Protocol Wiki** - The Protocol + - [Prehistory](/wiki/protocol/prehistory.md) - [Architecture](/wiki/protocol/architecture.md) - [Design rationale](/wiki/protocol/design-rationale.md) - [Evolution](/wiki/protocol/history.md) @@ -41,11 +42,11 @@ - [RLP Serialization](/wiki/EL/RLP.md) - Consensus Layer - [Overview](/wiki/CL/overview.md) + - [Client architecture](/wiki/CL/cl-architecture.md) + - [CL Networking](/wiki/CL/cl-networking.md) - [CL Specs](/wiki/CL/cl-specs.md) - - [Client architecture](/wiki/CL/client-architecture.md) - - [CL Clients](/wiki/CL/cl-clients.md) - [Beacon API](/wiki/CL/beacon-api.md) - - [CL Networking](/wiki/CL/cl-networking.md) + - [CL Clients](/wiki/CL/cl-clients.md) - [SSZ Serialization](/wiki/CL/SSZ.md) - [Merkleization](/wiki/CL/merkleization.md) - Development diff --git a/docs/contributing.md b/docs/contributing.md index ad1f47f9..a6a0aca8 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -12,7 +12,7 @@ Write contributions based on what you learned about the protocol along the way, Before you start with editing, please read the code of conduct, following guide and make yourself familiar with the overall wiki structure. -The wiki source is hosted in github repository at [github.com/eth-protocol-fellows/protocol-studies](https://github.com/eth-protocol-fellows/protocol-studies). Mirrored at //TODO +The wiki source is hosted in Github repository at [github.com/eth-protocol-fellows/protocol-studies](https://github.com/eth-protocol-fellows/protocol-studies). Github repo is the main coordination and hosting platform but wiki source is also mirrored on [radicle](https://app.radicle.xyz/nodes/seed.radicle.garden/rad:zkV49UANVb2w2g5eE4Le197Wuasz) and [independent centralized host](https://git.ethquokkaops.io/eth-protocol-fellows/protocol-studies). > The wiki is served from `wiki-pages` branch which is regularly updated from `main`. When contributing, open a PR to a branch related to the change or `main` for smaller quick fixes. PRs from other branches are reviewed before merging to `main` and collected updates are then pushed to update the `wiki-pages`. diff --git a/docs/eps/intro.md b/docs/eps/intro.md index 4786a0b3..2b6d910b 100644 --- a/docs/eps/intro.md +++ b/docs/eps/intro.md @@ -4,7 +4,7 @@ Ethereum Protocol Fellowship Study Group (EPFsg) is a community formed gathering 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. -> 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. +> 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. Learn more context in the [original announcement](https://blog.ethereum.org/2024/02/07/epf-study-group). ## Program Structure diff --git a/docs/eps/week1.md b/docs/eps/week1.md index 138c996c..ab17bbbf 100644 --- a/docs/eps/week1.md +++ b/docs/eps/week1.md @@ -25,12 +25,12 @@ To understand Ethereum design, we need to learn about predecessors and the cultu Starting all the way back in the 1960s, UNIX is an operating system and philosophy that redefined the entire paradigm of computation. This is the paradigm we have been using for over 50 years and has never really changed. Its fundamental concept of modularity is important to Ethereum design and open collaborative environment of Bell Labs is similar to Ethereum core development today. -> Check this documentary with Dennis Ritchie and Ken Thompson, which perfectly captures spirit and ideas behind UNIX: https://yewtu.be/watch?v=tc4ROCJYbm0 +> Check this documentary with Dennis Ritchie and Ken Thompson, which perfectly captures spirit and ideas behind UNIX: https://www.youtube.com/watch?v=tc4ROCJYbm0 The Free Software movement is fundamental to Ethereum and all cryptocurrencies. The open, independent and collaborative development culture of Ethereum is strongly rooted in FOSS (Free and Open Source Software). Ethereum needs to be transparently implemented in software that gives full freedom to its users. Using any FOSS can empower every user and developer, but it's necessary for security, neutrality and trustless nature of Ethereum. > To understand its importance, watch this talk by Richard Stallman, the founder of Free Software and GNU project: -> - https://yewtu.be/watch?v=Ag1AKIl_2GM +> - https://www.youtube.com/watch?v=Ag1AKIl_2GM > - More reading: https://www.gnu.org/philosophy/free-sw.html, *The Cathedral and the Bazaar* book: http://www.catb.org/~esr/writings/cathedral-bazaar/ The invention of [asymmetric cryptography](https://www-ee.stanford.edu/~hellman/publications/24.pdf) marks the birth of a new paradigm for cryptography applications. Later, the rise of cryptography in computation for general public enabled everyone to utilize tools for digital privacy, secure communication and fundamentally transformed cybersecurity. While nation states did not have a framework for these new concepts, [Crypto Wars](https://en.wikipedia.org/wiki/Crypto_Wars) resulted in activist movements advocating and building cryptography tools. Ultimately, these were people inventing tools and ideas which became fundamental building blocks of modern cryptocurrencies. diff --git a/docs/images/cl/RANDAO.png b/docs/images/cl/RANDAO.png new file mode 100644 index 00000000..3648ed87 Binary files /dev/null and b/docs/images/cl/RANDAO.png differ diff --git a/docs/images/cl/blobs.png b/docs/images/cl/blobs.png new file mode 100644 index 00000000..cbf1e05c Binary files /dev/null and b/docs/images/cl/blobs.png differ diff --git a/docs/images/cl/blockchain.svg b/docs/images/cl/blockchain.svg new file mode 100644 index 00000000..9c7f7f29 --- /dev/null +++ b/docs/images/cl/blockchain.svg @@ -0,0 +1,491 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/cl/blocktree.svg b/docs/images/cl/blocktree.svg new file mode 100644 index 00000000..fcd5da3e --- /dev/null +++ b/docs/images/cl/blocktree.svg @@ -0,0 +1,657 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/cl/checkpoints.jpg b/docs/images/cl/checkpoints.jpg new file mode 100644 index 00000000..460b995b Binary files /dev/null and b/docs/images/cl/checkpoints.jpg differ diff --git a/docs/images/cl/cl-ideal.png b/docs/images/cl/cl-ideal.png new file mode 100644 index 00000000..ec67a64c Binary files /dev/null and b/docs/images/cl/cl-ideal.png differ diff --git a/docs/images/cl/cl-networking-overview.webp b/docs/images/cl/cl-networking-overview.webp new file mode 100644 index 00000000..1a91621c Binary files /dev/null and b/docs/images/cl/cl-networking-overview.webp differ diff --git a/docs/images/cl/cl-real.png b/docs/images/cl/cl-real.png new file mode 100644 index 00000000..5957b005 Binary files /dev/null and b/docs/images/cl/cl-real.png differ diff --git a/docs/images/cl/cl.png b/docs/images/cl/cl.png new file mode 100644 index 00000000..8d7376b7 Binary files /dev/null and b/docs/images/cl/cl.png differ diff --git a/docs/images/cl/client-architecture.png b/docs/images/cl/client-architecture.png new file mode 100644 index 00000000..30f0122c Binary files /dev/null and b/docs/images/cl/client-architecture.png differ diff --git a/docs/images/cl/committees.png b/docs/images/cl/committees.png new file mode 100644 index 00000000..c3c99e67 Binary files /dev/null and b/docs/images/cl/committees.png differ diff --git a/docs/images/cl/el.png b/docs/images/cl/el.png new file mode 100644 index 00000000..b8940c0d Binary files /dev/null and b/docs/images/cl/el.png differ diff --git a/docs/images/cl/finalization.png b/docs/images/cl/finalization.png new file mode 100644 index 00000000..57e33f0f Binary files /dev/null and b/docs/images/cl/finalization.png differ diff --git a/docs/images/cl/network.png b/docs/images/cl/network.png new file mode 100644 index 00000000..9e79be32 Binary files /dev/null and b/docs/images/cl/network.png differ diff --git a/docs/images/cl/reorg-0.svg b/docs/images/cl/reorg-0.svg new file mode 100644 index 00000000..c8eac812 --- /dev/null +++ b/docs/images/cl/reorg-0.svg @@ -0,0 +1,478 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/cl/reorg-1.svg b/docs/images/cl/reorg-1.svg new file mode 100644 index 00000000..62bb3ae8 --- /dev/null +++ b/docs/images/cl/reorg-1.svg @@ -0,0 +1,518 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/cl/slots-and-epochs.png b/docs/images/cl/slots-and-epochs.png new file mode 100644 index 00000000..ac2e9d71 Binary files /dev/null and b/docs/images/cl/slots-and-epochs.png differ diff --git a/docs/images/cl/validator-lifecycle.png b/docs/images/cl/validator-lifecycle.png new file mode 100644 index 00000000..16a98d85 Binary files /dev/null and b/docs/images/cl/validator-lifecycle.png differ diff --git a/docs/images/cl/validators.png b/docs/images/cl/validators.png new file mode 100644 index 00000000..e63721de Binary files /dev/null and b/docs/images/cl/validators.png differ diff --git a/docs/images/space-core-devs.png b/docs/images/space-core-devs.png index fa271792..d9cdeb19 100644 Binary files a/docs/images/space-core-devs.png and b/docs/images/space-core-devs.png differ diff --git a/docs/wiki/CL/beacon-api.md b/docs/wiki/CL/beacon-api.md index 53e59474..1e9701bb 100644 --- a/docs/wiki/CL/beacon-api.md +++ b/docs/wiki/CL/beacon-api.md @@ -1,7 +1,60 @@ -# Beacon API +# Beacon Chain Spec and APIs -> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. +At the core of Ethereum Proof-of-Stake is a system chain called the "Beacon Chain". The beacon chain stores and manages the registry of validators. In the initial deployment phases of Proof-of-Stake, the only mechanism to become a validator is to make a one-way(withdrawable after Capella) ETH transaction to a deposit contract on the Ethereum proof-of-work chain. Activation as a validator happens when deposit receipts are processed by the Beacon Chain, the activation balance is reached, and a queuing process is completed. Exit is either voluntary or done forcibly as a penalty for misbehavior. The primary source of load on the beacon chain is "attestations". Attestations are simultaneously availability votes for a shard block (in a later upgrade) and proof-of-stake votes for a beacon block (Phase 0). -Beacon API is the endpoint provided by consensus layer clients. It's the interface for interacting with consensus for users and validators. +This section will cover some important parts of Beacon Chain Spec and APIs. Also checkout complete [Beacon Chain Spec](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md) and [Beacon API reference](https://ethereum.github.io/beacon-APIs/#/). -Check the [Beacon API reference](https://ethereum.github.io/beacon-APIs/#/). \ No newline at end of file +Beacon API is the REST endpoint provided by consensus layer clients (beacon nodes). It's the interface to read information about the consensus and used by validator clients. + +## Containers + +`BeaconState` + +```python +class BeaconState(Container): + # Versioning + genesis_time: uint64 + genesis_validators_root: Root + slot: Slot + fork: Fork + # History + latest_block_header: BeaconBlockHeader + block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] + state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] + historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] + # Eth1 + eth1_data: Eth1Data + eth1_deposit_index: uint64 + application_state_root: Bytes32 + # Registry + validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] + balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] + # Randomness + randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] + # Slashings + slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] + # Attestations + previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] + current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] + # Finality + justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] # Bit set for every recent justified epoch + previous_justified_checkpoint: Checkpoint # Previous epoch snapshot + current_justified_checkpoint: Checkpoint + finalized_checkpoint: Checkpoint +``` + +#### `BeaconBlockBody` + +```python +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data # Eth1 data vote + graffiti: Bytes32 # Arbitrary data + # Operations + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + application_payload: ApplicationPayload +``` diff --git a/docs/wiki/CL/cl-architecture.md b/docs/wiki/CL/cl-architecture.md new file mode 100644 index 00000000..ef8b0d9a --- /dev/null +++ b/docs/wiki/CL/cl-architecture.md @@ -0,0 +1,246 @@ +# Consensus Layer (CL) architecture + +> Many blockchain consensus protocols are _forkful_. Forkful chains use a fork choice rule, and sometimes undergo reorganisations. +> +> Ethereum's consensus protocol combines two separate consensus protocols. _LMD GHOST_ essentially provides liveness. _Casper FFG_ provides finality. Together they are known as _Gasper_. +> +> In a _live"_ protocol, something good always happens. In a _safe_ protocol, nothing bad ever happens. No practical protocol can be always safe and always live. + +## Fork-choice Mechanism + +As described in [BFT](/wiki/CL/overview.md?id=byzantine-fault-tolerance-bft-and-byzantine-generals39-problem), for various reasons - like network delays, outages, out-of-order messages, or malicious behavior — nodes in the network can have different views of the network's state. Eventually, we want every honest node to agree on an identical, linear history and a common view of the system's state. The protocol's fork choice rule is what helps achieve this agreement. + +#### Block Tree +Given a block tree and decision criteria based on a node's local view of the network, the fork choice rule is designed to select the branch that is most likely to become the final, linear, canonical chain. It chooses the branch least likely to be pruned out as nodes converge on a common view. + + + +
+ +![Diagram for Block Tree](../../images/cl/blocktree.svg) + +
+ +_The fork choice rule picks a head block from the candidates. The head block identifies a unique linear blockchain back to the Genesis block._ + +
+
+ +#### Fork choice rules + +The fork choice rule implicitly selects a branch by choosing a block at the branch's tip, called the head block. For any correct node, the first rule of any fork choice is that the chosen block must be valid according to protocol rules, and all its ancestors must also be valid. Any invalid block is ignored, and blocks built on an invalid block are also invalid. + +There are several examples of different fork choice rules: + +- **Proof-of-work**: In Ethereum and Bitcoin, the "heaviest chain rule" (sometimes called "longest chain", though not strictly accurate) is used. The head block is the tip of the chain with the most cumulative "work" done. +> Note that contrary to popular belief, Ethereum's Proof-of-work protocol [did not use](https://ethereum.stackexchange.com/questions/38121/why-did-ethereum-abandon-the-ghost-protocol/50693#50693) any form of GHOST in its fork choice. This misconception is very persistent, probably due to the [Ethereum Whitepaper](https://ethereum.org/en/whitepaper/#modified-ghost-implementation). Eventually when Vitalik was asked about it, he confirmed that although GHOST had been planned under PoW it was never implemented due to concerns about some unspecified attacks. The heaviest chain rule was simpler and well tested. It worked fine. +- **Casper FFG (Proof-of-Stake)**: In Ethereum's PoS Casper FFG protocol, the fork-choice rule is to "follow the chain containing the justified checkpoint of the **greatest height**" and never revert a finalized block. +- **LMD GHOST (Proof-of-Stake)**: In Ethereum's PoS LMD GHOST protocol, the fork-choice rule is to take the "Greediest Heaviest Observed SubTree". It involves counting accumulated votes from validators for blocks and their descendent blocks. It also applies the same rule as Casper FFG. + +Each of these fork choice rules assigns a numeric score to a block. The winning block, or head block, has the highest score. The goal is that all correct nodes, when they see a certain block, will agree that it is the head and follow its branch. This way, all correct nodes will eventually agree on a single canonical chain that goes back to Genesis. + +#### Reorgs and Reversion + +As a node receives new votes (and new votes for blocks in Proof-of-stake), it re-evaluates the fork choice rule with this new information. Usually, a new block will be a child of the current head block, and it will become the new head block. + +Sometimes, however, the new block might be a descendant of a different block in the block tree. If the node doesn't have the parent block of the new block, it will ask its peers for it and any other missing blocks. + +Running the fork choice rule on the updated block tree might show that the new head block is on a different branch than the previous head block. When this happens, the node must perform a reorg (reorganisation). This means it will remove (revert) blocks it previously included and adopt the blocks on the new head's branch. + +For example, if a node has blocks $A, B, D, E,$ and $F$ in its chain, and it views $F$ as the head block, it knows about block $$ but it does not appear in its view of the chain; it is on a side branch. + + + +
+ +![Diagram for Reorg-0](../../images/cl/reorg-0.svg) + +
+ +_At this point, the node believes that block $F$ is the best head, therefore its chain is blocks $[A \leftarrow B \leftarrow D \leftarrow E \leftarrow F]$_ + +
+
+ +When the node later receives block $G$, which is built on block $C$, not on its current head block $F$, it must decide if $G$ should be the new head. Just for example, If the fork choice rule says $G$ is the better head block, the node will revert blocks $D, E,$ and $F$. It will remove them from its chain, as if they were never received, and go back to the state after block $B$. + +Then, the node will add blocks $C$ and $G$ to its chain and process them. After this reorg, the node's chain will be $A, B, C,$ and $G$. + + + +
+ +![Diagram for Reorg-1](../../images/cl/reorg-1.svg) + +
+ +_Now the node believes that block $G$ is the best head, therefore its chain must change to the blocks $[A \leftarrow B \leftarrow C \leftarrow G]$_ + +
+
+ +Later, perhaps, a block $H$ might appear, that's built on $F$, and the fork choice rule says $H$ should be the new head, the node will reorg again, reverting to block $B$ and replaying blocks on $H$'s branch. + +Short reorgs of one or two blocks are common due to network delays. Longer reorgs should be rare unless the chain is under attack or there is a bug in the fork choice rule or its implementation. + +### Safety and Liveness + +In consensus mechanisms, two key concepts are safety and liveness. + +**Safety** means "nothing bad ever happens," such as preventing double-spending or finalizing conflicting checkpoints. It ensures consistency, meaning all honest nodes should always agree on the state of the blockchain. + +**Liveness** means "something good eventually happens," ensuring the blockchain can always add new blocks and never gets stuck in a deadlock. + +**CAP Theorem** states that no distributed system can provide consistency, availability, and partition tolerance simultaneously. This means we can't design a system that is both safe and live under all circumstances when communication is unreliable. + +#### Ethereum Prioritizes Liveness + +Ethereum’s consensus protocol aims to offer both safety and liveness in good network conditions. However, it prioritizes liveness during network issues. In a network partition, nodes on each side will continue to produce blocks but won't achieve finality (a safety property). If the partition persists, each side may finalize different histories, leading to two irreconcilable, independent chains. + +Thus, while Ethereum strives for both safety and liveness, it leans towards ensuring the network remains live and continues to process transactions, even at the cost of potential safety issues during severe network disruptions. + +## The Ghosts in the Machine + +Ethereum's Proof-of-Stake consensus protocol combines two separate protocols: [LMD GHOST](/wiki/cl/gasper?id=lmd-ghost.md) and [Casper FFG](/wiki/cl/gasper?id=casper-ffg.md). Together, they form the consensus protocol known as "Gasper". Detailed Information about both protocols and how they work in combination are covered in the next section [Gasper]. + +Gasper aims to combine the strengths of both LMD GHOST and Casper FFG. LMD GHOST provides liveness, ensuring the chain keeps running by producing new blocks regularly. However, it is prone to forks and not formally safe. Casper FFG, on the other hand, provides safety by periodically finalizing the chain, protecting it from long reversions. + +In essence, LMD GHOST keeps the chain moving forward, while Casper FFG ensures stability by finalizing blocks. This combination allows Ethereum to prioritize liveness, meaning the chain continues to grow even if Casper FFG can't finalize blocks. Although this combined mechanism isn't always perfect and has some complexities, it is a practical engineering solution that works well in practice for Ethereum. + +## Architecture + +Ethereum is a decentralized network of nodes that communicate via peer-to-peer connections. These connections are formed by computers running Ethereum's client software. + + + +
+ +![Diagram for Network](../../images/cl/network.png) + +
+ +_Nodes aren't required to run a validator client (green ones) to be a part of the network, however to take part in consensus one needs to stake 32 ETH and run a validator client._ + +
+
+ +### Components of the Consensus Layer + +- **Beacon Node**: Beacon nodes use client software to coordinate Ethereum's proof-of-stake consensus. Examples include Prysm, Teku, Lighthouse, and Nimbus. Beacon nodes communicate with other beacon nodes, a local execution node, and optionally, a local validator. + +- **Validator**: Validator client is the software that allows people to stake 32 ETH in Ethereum's consensus layer. Validators propose blocks in the Proof-of-Stake system, which replaced Proof-of-work miners. Validators communicate only with a local beacon node, which instructs them and broadcasts their work to the network. + +The main Ethereum network hosting real-world applications is called Ethereum Mainnet. Ethereum Mainnet is the live, production instance of Ethereum that mints and manages real Ethereum (ETH) and holds real monetary value. + +There are also test networks that mint and manage test Ethereum for developers, node runners, and validators to test new functionality before using real ETH on Mainnet. Each Ethereum network has two layers: the execution layer (EL) and the consensus layer (CL). Every Ethereum node contains software for both layers: execution-layer client software (like Nethermind, Besu, Geth, and Erigon) and consensus-layer client software (like Prysm, Teku, Lighthouse, Nimbus, and Lodestar). + + + +
+ +![Diagram for CL](../../images/cl/cl.png) + +
+ +**Consensus Layer** is responsible for maintaining consensus chain (beacon chain) and processing the consensus blocks (beacon blocks) and attestations received from other peers. **Consensus clients** participate in a separate [peer-to-peer network](/wiki/cl/cl-networking.md) with a different specification from execution clients. They need to participate in block gossip to receive new blocks from peers and broadcast blocks when it's their turn to propose. + +Both EL and CL clients run in parallel and need to be connected for communication. The consensus client provides instructions to the execution client, and the execution client passes transaction bundles to the consensus client to include in Beacon blocks. Communication is achieved using a local RPC connection via the **Engine-API**. They share an [ENR](/wiki/cl/cl-networking?id=ethereum-enr) with separate keys for each client (eth1 key and eth2 key). + +### Control Flow + +**When the consensus client is not the block producer:** +1. Receives a block via the block gossip protocol. +2. Pre-validates the block. +3. Sends transactions in the block to the execution layer as an execution payload. +4. Execution layer executes transactions and validates the block state. +5. Execution layer sends validation data back to the consensus layer. +6. Consensus layer adds the block to its blockchain and attests to it, broadcasting the attestation over the network. + +**When the consensus client is the block producer:** +1. Receives notice of being the next block producer. +2. Calls the create block method in the execution client. +3. Execution layer accesses the transaction mempool. +4. Execution client bundles transactions into a block, executes them, and generates a block hash. +5. Consensus client adds transactions and block hash to the beacon block. +6. Consensus client broadcasts the block over the block gossip protocol. +7. Other clients validate the block and attest to it. +8. Once attested by sufficient validators, the block is added to the head of the chain, justified, and finalized. + + +### State Transitions + +The state transition function is essential in blockchains. Each node maintains a state that reflects its view of the world. + +Nodes update their state by applying blocks in order using a "state transition function". This function is "pure", meaning its output depends only on the input and has no side effects. Thus, if every node starts with the same state (Genesis state) and applies the same blocks, they all end up with the same state. If they don't, there's a consensus failure. + +If $S$ is a beacon state and $B$ a beacon block, the state transition function $f$ is: + +$$S' \equiv f(S, B)$$ + +Here, $S$ is the pre-state and $S'$ is the post-state. The function $f$ is iterated with each new block to update the state. + +### Beacon Chain State Transitions + +Unlike the block-driven Proof-of-work, the beacon chain is slot-driven. State updates depend on slot progress, regardless of block presence. + +The beacon chain's state transition function includes: + +1. **Per-slot transition**: $S' \equiv f_s(S)$ +2. **Per-block transition**: $S' \equiv f_b(S, B)$ +3. **Per-epoch transition**: $S' \equiv f_e(S)$ + +Each function updates the chain at specific times, as defined in the beacon chain specification. + +### Validity Conditions + +The post-state from a pre-state and a signed block is `state_transition(state, signed_block)`. Transitions causing unhandled exceptions (e.g., failed asserts or out-of-range accesses) or uint64 overflows/underflows are invalid. + +### Beacon chain state transition function + +The post-state corresponding to a pre-state `state` and a signed block `signed_block` is defined as `state_transition(state, signed_block)`. State transitions that trigger an unhandled exception (e.g. a failed `assert` or an out-of-range list access) are considered invalid. State transitions that cause a `uint64` overflow or underflow are also considered invalid. + +```python +def state_transition(state: BeaconState, signed_block: SignedBeaconBlock, validate_result: bool=True) -> None: + block = signed_block.message + # Process slots (including those with no blocks) since block + process_slots(state, block.slot) + # Verify signature + if validate_result: + assert verify_block_signature(state, signed_block) + # Process block + process_block(state, block) + # Verify state root + if validate_result: + assert block.state_root == hash_tree_root(state) +``` + +```python +def verify_block_signature(state: BeaconState, signed_block: SignedBeaconBlock) -> bool: + proposer = state.validators[signed_block.message.proposer_index] + signing_root = compute_signing_root(signed_block.message, get_domain(state, DOMAIN_BEACON_PROPOSER)) + return bls.Verify(proposer.pubkey, signing_root, signed_block.signature) +``` + +```python +def process_slots(state: BeaconState, slot: Slot) -> None: + assert state.slot < slot + while state.slot < slot: + process_slot(state) + # Process epoch on the start slot of the next epoch + if (state.slot + 1) % SLOTS_PER_EPOCH == 0: + process_epoch(state) + state.slot = Slot(state.slot + 1) +``` + + +## Resources + +- Vitalik Buterin, ["Parametrizing Casper: the decentralization/finality time/overhead tradeoff"](https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735) +- [Engine API spec](https://hackmd.io/@n0ble/consensus_api_design_space) +- [Vitalik's Annotated Ethereum 2.0 Spec](https://notes.ethereum.org/@vbuterin/SkeyEI3xv) +- Ethereum, ["Eth2: Annotated Spec"](https://github.com/ethereum/annotated-spec) +- Martin Kleppmann, [Distributed Systems.](https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB) +- Leslie Lamport et al., [The Byzantine Generals Problem.](https://lamport.azurewebsites.net/pubs/byz.pdf) +- Austin Griffith, [Byzantine Generals - ETH.BUILD.](https://www.youtube.com/watch?v=c7yvOlwBPoQ) +- Michael Sproul, ["Inside Ethereum"](https://www.youtube.com/watch?v=LviEOQD9e8c) +- [Eth2 Handbook by Ben Edgington](https://eth2book.info/capella/part2/consensus/) \ No newline at end of file diff --git a/docs/wiki/CL/cl-networking.md b/docs/wiki/CL/cl-networking.md index cb75d7b2..575f4d51 100644 --- a/docs/wiki/CL/cl-networking.md +++ b/docs/wiki/CL/cl-networking.md @@ -1,46 +1,33 @@ # Networking -The Consensus clients use [libp2p][libp2p] as the peer-to-peer protocol, -[discv5][discv5] for peer discovery, [libp2p-noise][libp2p-noise] for -encryption, [SSZ][ssz] for encoding, and, optionally, [Snappy][snappy] for -compression. +The Consensus clients use [libp2p][libp2p] as the peer-to-peer protocol, [discv5][discv5] for peer discovery, [libp2p-noise][libp2p-noise] for encryption, [SSZ][ssz] for encoding, and, optionally, [Snappy][snappy] for compression. + +## ENR (Ethereum Node Records) + +## discv5 + ## Specs -The [Phase 0 -- Networking][consensus-networking] page specifies the network -fundamentals, protocols, and rationale/design choices. +The [Phase 0 -- Networking][consensus-networking] page specifies the network fundamentals, protocols, and rationale/design choices. ## libp2p - P2P protocol -[libp2p][libp2p] is used as the peer-to-peer protocol. -[libp2p and Ethereum][libp2p-and-eth] is a great article for a deep-dive on the -history of libp2p, and its adoption in the Consensus clients. +[libp2p][libp2p] is used as the peer-to-peer protocol. [libp2p and Ethereum][libp2p-and-eth] is a great article for a deep-dive on the history of libp2p, and its adoption in the Consensus clients. ## libp2p-noise - Encryption -The [Noise framework][noise-framework] is not a protocol itself, but a framework -for designing key exchange protocols. The [specification][noise-specification] -is a great place to start. +The [Noise framework][noise-framework] is not a protocol itself, but a framework for designing key exchange protocols. The [specification][noise-specification] is a great place to start. -There are many [patterns][noise-patterns] which describe the key exchange -process. The pattern used in the consensus clients is [`XX`][noise-xx] -(transmit-transmit), meaning that both the initiator, and responder transmit -their public key in the initial stages of the key exchange. +There are many [patterns][noise-patterns] which describe the key exchange process. The pattern used in the consensus clients is [`XX`][noise-xx] (transmit-transmit), meaning that both the initiator, and responder transmit their public key in the initial stages of the key exchange. ## SSZ - Encoding -[Simple serialize (SSZ)][ssz] replaces the [RLP][rlp] serialization used on the -execution layer everywhere across the consensus layer except the peer discovery -protocol. SSZ is designed to be deterministic and also to Merkleize efficiently. -SSZ can be thought of as having two components: a serialization scheme and a -Merkleization scheme that is designed to work efficiently with the serialized -data structure. +[Simple serialize (SSZ)][ssz] replaces the [RLP][rlp] serialization used on the execution layer everywhere across the consensus layer except the peer discovery protocol. SSZ is designed to be deterministic and also to Merkleize efficiently. SSZ can be thought of as having two components: a serialization scheme and a Merkleization scheme that is designed to work efficiently with the serialized data structure. ## Snappy - Compression -[Snappy][snappy] is a compression scheme created by engineers at Google in 2011. -It's main design considerations prioritize compression/decompression speed, -while still having a reasonable compression ratio. +[Snappy][snappy] is a compression scheme created by engineers at Google in 2011. It's main design considerations prioritize compression/decompression speed, while still having a reasonable compression ratio. ## Related R&D @@ -67,3 +54,4 @@ while still having a reasonable compression ratio. [rlp]: https://ethereum.org/developers/docs/data-structures-and-encoding/rlp [snappy]: https://en.wikipedia.org/wiki/Snappy_(compression) [ssz]: https://ethereum.org/developers/docs/data-structures-and-encoding/ssz +[blog]: https://medium.com/coinmonks/dissecting-the-ethereum-networking-stack-node-discovery-4b3f7895f83f diff --git a/docs/wiki/CL/client-architecture.md b/docs/wiki/CL/client-architecture.md deleted file mode 100644 index bfad295b..00000000 --- a/docs/wiki/CL/client-architecture.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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/CL/gasper.md b/docs/wiki/CL/gasper.md new file mode 100644 index 00000000..6292dfbe --- /dev/null +++ b/docs/wiki/CL/gasper.md @@ -0,0 +1,40 @@ +# Gasper + +## LMD GHOST (Latest Message Driven -- Greediest Heaviest Observed SubTree) + + + +## Casper FFG (Friendly Finality Gadget) + + + + +- Hybrid Fork-choice (Refer pos-evolution in ethereum post/book) +Possible attacks +- simple ex-ante reorg +- weighted proposer boost + +Solutions: +- view-merge strategy + + +## Resources + +- [Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052) +- [Yang X Zhang- Combining GHOST and Casper](https://www.youtube.com/watch?v=V0RjGmFE35U) +- [Introduction to Gasper from Ethereum.org](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/) +- [Evolution of Ethereum PoS Consensus Protocol](https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md) +- [Goldfish](https://arxiv.org/pdf/2209.03255) +- [Casper FFG](https://arxiv.org/pdf/1710.09437) +- [LMD Ghost](https://inevitableeth.com/home/ethereum/network/consensus/lmd-ghost) +- [RLMD GHOST with Luca Zanolini](https://www.youtube.com/watch?v=F2olypDSVnA) +- [Comparison of different LMD Ghost Implementations by ProtoLambda](https://github.com/protolambda/lmd-ghost) \ No newline at end of file diff --git a/docs/wiki/CL/overview.md b/docs/wiki/CL/overview.md index 0eba8dd2..dca4c7fa 100644 --- a/docs/wiki/CL/overview.md +++ b/docs/wiki/CL/overview.md @@ -1,20 +1,356 @@ -# Consensus layer +# Consensus Layer Overview -The Ethereum consensus layer defines the mechanism for nodes to agree on the network's state. This layer currently employs Proof-of-Stake (PoS), a crypto-economic system. PoS encourages honest behavior by requiring validators to lock ETH. These validators are responsible for proposing new blocks, validating existing ones, and processing transactions. The protocol enforces rewards and penalties to ensure validator integrity and deter malicious activity. +The main challenge a consensus protocol aims to solve is building a reliable distributed system on top of unreliable infrastructure. Research on consensus protocols dates back to the 1970s, but the scale of what Ethereum is trying to achieve is far more ambitious. -Validator selection, block voting, and fork resolution are governed by [consensus specification](/wiki/CL/cl-specs.md). In case of competing blocks, the "heaviest" chain, determined by validator support weighted by staked ETH, prevails. +In Ethereum's consensus layer, the goal is to ensure that tens of thousands of independent nodes around the world stay reasonably synchronized. Each node keeps a ledger with the state of every account, and all these ledgers must match exactly. There can be no differences; the nodes must agree and do so quickly. This is what we mean by "a reliable distributed system." -Ethereum consensus layer addresses the fundamental challenge of Byzantine fault tolerance in distributed computing. Similar to the Byzantine Generals Problem, geographically dispersed nodes in the blockchain network must agree on transaction validity despite potential communication issues or malicious actors. +These nodes often use [consumer grade hardware](https://stakefromhome.com/) and communicate over internet connections that may be slow, lose data, or disconnect unexpectedly. Node operators might misconfigure their software or fail to update it. Additionally, there could be many bad actors running rogue nodes or tampering with communications for personal gain. This is what we mean by "unreliable infrastructure." -Ethereum uses a consensus mechanism known as Gasper that combines [Casper proof-of-stake](https://arxiv.org/pdf/1710.09437.pdf) with LMD GHOST - an extension of [GHOST fork-choice rule](https://eprint.iacr.org/2013/881.pdf). +### Byzantine Fault Tolerance (BFT) and Byzantine Generals' Problem -## Resources +Byzantine Fault Tolerance (BFT) is a property of distributed systems that allows them to function correctly even when some components fail or act maliciously. BFT is crucial in decentralized networks, where trust among nodes cannot be assumed. In other words, a system exhibiting BFT can tolerate Byzantine faults, which are arbitrary failures that include malicious behavior. For a system to be Byzantine fault-tolerant, it must reach consensus despite these faults. For more on the problem and practical solutions read [this](https://hackmd.io/@kira50/SknuPZMIC). -- Vitalik Buterin et al., [Gasper: Combining GHOST and Casper.](https://arxiv.org/pdf/2003.03052.pdf) -- Alt Explainer, ["Ethereum's Proof of Stake consensus explained."](https://www.youtube.com/watch?v=5gfNUVmX3Es) -- Vitalik Buterin, ["Parametrizing Casper: the decentralization/finality time/overhead tradeoff"](https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735) -- Ethereum, ["Eth2: Annotated Spec"](https://github.com/ethereum/annotated-spec) -- Martin Kleppmann, [Distributed Systems.](https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB) -- Leslie Lamport et al., [The Byzantine Generals Problem.](https://lamport.azurewebsites.net/pubs/byz.pdf) -- Austin Griffith, [Byzantine Generals - ETH.BUILD.](https://www.youtube.com/watch?v=c7yvOlwBPoQ) -- Michael Sproul, ["Inside Ethereum"](https://www.youtube.com/watch?v=LviEOQD9e8c) +## Introduction to Consensus Layer (CL) + +> Consensus is a way to build reliable distributed systems with unreliable components. Blockchain-based distributed systems aim to agree on a single history of transactions. +> +> Proof-of-work and Proof-of-stake are not consensus protocols, but enable consensus protocols. In Ethereum, Nodes and validators are the actors of the consensus system. Slots and epochs regulate consensus time. Blocks and attestations are the currency of consensus. + +The Consensus Layer (CL) is a fundamental component that ensures the network's security, reliability, and efficiency. Originally, Ethereum utilized Proof-of-work (PoW) as its consensus mechanism, similar to Bitcoin. PoW, while effective in maintaining decentralization and security, has significant drawbacks, including high energy consumption and limited scalability. To address these issues, Ethereum has transitioned to Proof-of-Stake (PoS), a more sustainable and scalable consensus mechanism. + +The Ethereum network consists of many individual nodes. Each node operates independently and communicates over the Internet, which is often unreliable and asynchronous. + +Users send transactions to this network of nodes, and the consensus protocol ensures that all honest nodes eventually agree on a single, consistent transaction history. This means they agree on the order of transactions and their outcomes. For example, if I have 1 ETH and tell the network to send it to both Alice and Bob at the same time, the network must eventually agree on whether I sent it to Alice or Bob. It would be a failure if both Alice and Bob received the Ether, or if neither did. A consensus protocol is the process that enables this agreement on transaction order. + +Ethereum's consensus protocol actually _bolts together_ two different consensus protocols. One is called [LMD GHOST](/wiki/CL/gasper.md?lmd-ghost), the other [Casper FFG](/wiki/CL/gasper.md?casper-ffg). The combination has become known as [Gasper](/wiki/CL/gasper.md). In subsequent sections we will be looking at these both separately and in combination. + +## Proof-of-work and Proof-of-stake + +This is a good point to clarify that neither Proof-of-work (PoW) nor Proof-of-Stake (PoS) are consensus protocols by themselves. They are often incorrectly referred to as such, but they are actually mechanisms that enable consensus protocols. Both PoW and PoS primarily serve as Sybil resistance mechanisms, placing a cost on participating in the protocol. This prevents attackers from overwhelming the system cheaply. + +However, both PoW and PoS are closely linked to the consensus mechanisms they support through [fork choice](/wiki/CL/cl-architecture.md?id=fork-choice-rules) rules. They help assign a weight or score to a chain of blocks: in PoW, it's the total computational work done; in PoS, it's the total value staked that supports a particular chain. Beyond these basics, PoW and PoS can support various consensus protocols, each with its own dynamics and trade-offs. + +### Blockchains + +The basic element of a blockchain is the block. A block contains a set of transactions assembled by a leader (block proposer). The contents of a block can vary based on the protocol. + +- The payload of a block on Ethereum's execution chain is a list of user transactions. +- In the pre-Merge PoS Beacon Chain, a block's payload was mostly a set of attestations by validators. +- Post-Merge Beacon Chain blocks also include the execution payload (user transactions). +- After [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)(Deneb upgrade), blocks now also contain commitments to opaque data blobs alongside user transactions. + +Except for the Genesis block, each block builds on and points to a parent block, forming a chain of blocks: a blockchain. The goal is for all nodes on the network to agree on the same canonical blockchain history. + + + +
+ +![Blockchain](../../images/cl/blockchain.svg) + +
+ +_Time moves from left to right and, except for the Genesis block, each block points to the parent block it builds on._ + +
+
+ +The chain grows as nodes add new blocks to its tip. This is done by temporarily selecting a "leader", the node that extends the chain. In PoW, the leader is the miner who first solves the PoW puzzle for its block. In Ethereum's PoS, the proposer(leader) is pseudo-randomly selected from active validator set. + +The leader (block proposer) adds a block to the chain, choosing and ordering its contents. The block must be valid according to protocol rules, or the network will ignore it. Using blocks is an optimization. Adding individual transactions one by one would create a huge consensus overhead. So blocks are batches of transactions, In Ethereum's execution chain, block size is limited by the block gas limit (the amount of work needed to process the transactions). [Beacon block](/wiki/CL/beacon-api.md?id=beaconblockbody) sizes are limited by hard-coded constants. + +## Transition to Proof-of-Stake + +> The engine was changed mid-flight! September 15, 2022 — the day Ethereum switched to Proof-of-Stake. That new engine is the Consensus Layer, formerly known as Ethereum 2.0’s Beacon Chain. + +The Paris hard fork (The merge) in Ethereum was activated based on "terminal total difficulty" (TTD) instead of block height to avoid risks like malicious forks. This ensures the transition to Proof-of-Stake (PoS) occurs only when the cumulative difficulty reaches a critical threshold. The terminal block is the last Proof-of-work (PoW) block where its total difficulty surpasses a predefined threshold, ensuring security. The total difficulty is calculated recursively, reflecting the computational effort in the blockchain. + +This is relevant because testnets, devnets and any Ethereum network running the latest software needs to activate the Merge - not by block height but by Total Terminal Difficulty (TTD). More details on the [transition criteria](https://hackmd.io/@kira50/rJ2y7jImR) and [Total Terminal Difficulty](https://bordel.wtf). + +The merge introduces the following: + +- **Beacon Chain Takes Over**: The Beacon Chain, already running in parallel with the Ethereum mainnet, assumes the responsibility for processing new blocks. Under PoS, blocks are validated by validators who stake their ETH to participate in the consensus mechanism, rather than by miners solving cryptographic puzzles. + +- **Security and Efficiency**: This transition not only aims to enhance the security of the Ethereum network by making it more decentralized but also significantly reduces its energy consumption, addressing one of the major criticisms of traditional PoW systems. + +- **New Consensus Mechanism**: The consensus under PoS is achieved through a combination of staking, attestation by validators, and algorithms that randomly select block proposers and committees to ensure the network remains secure and transactions are processed efficiently. + +### Beacon Chain Introduction +The Beacon Chain plays a crucial role in managing the PoS consensus. It oversees validators who propose and attest to new blocks, ensuring the network’s integrity and security. Validators are selected based on a number of criteria, one of them being the amount of ETH they stake, which also acts as collateral against dishonest behavior. Some high level responsibilities of validators are: + +- **Staking ETH**: Validators must stake a minimum of 32 ETH to participate. +- **Proposing Blocks**: A Validator is randomly selected to propose a new block. They must construct valid blocks and broadcast them to the network +- **Attesting Blocks**: Validators attest to the validity of blocks proposed by others. Attestations are essentially votes on the validity of the blocks, ensuring consensus. +- **Participating in Consensus**: Validators participate in consensus by voting on the state of the blockchain at regular intervals, helping to finalize the blockchain's state. + +The Paris hard fork was a pivotal event in Ethereum's history, setting the stage for more scalable, sustainable, and secure operations. It represents Ethereum's commitment to innovation and its responsiveness to the broader societal concerns about the environmental impact of cryptocurrency mining. + +## Beacon Chain and its Preliminaries + +The Beacon Chain is the backbone of Ethereum’s consensus. It coordinates validators, manages the PoS protocol, and ensures consensus across the network. This section with cover the anatomy of Beacon chain. + +### Validators + +Validators are essentially the participants in the PoS Protocol. They propose and validate new blocks, ensuring the integrity and security of the blockchain. Validators must stake ETH as collateral, aligning their interests with the network’s health. Validators are chosen to propose blocks based on several factors: + +- **Staked Ether**: Each validator can stake a maximum of 32 ETH. Stakers with more ETH can increase their influence by running multiple validator nodes, each staking 32 ETH. This system ensures decentralization and aligns the interests of validators with the network's security and integrity. +- **Randomness**: The selection process incorporates cryptographic randomness to prevent predictability and manipulation. This is achieved through the [RANDAO](https://inevitableeth.com/home/ethereum/network/consensus/randao) and [VDF (Verifiable Delay Function)](https://inevitableeth.com/home/ethereum/upgrades/consensus-updates/vdf) mechanisms. +- **Committees**: Validators are grouped into committees for block proposal and attestation. Each committee is responsible for validating and attesting to blocks, ensuring a decentralized and secure validation process. +- **Staking Requirements**: To become a validator, an individual must deposit a minimum of 32 ETH into the official deposit contract. This ETH acts as collateral to incentivize honest behavior. The validator's ETH is at risk if they fail to perform their duties or engage in malicious activities. + +### Slots and Epochs + +Each slot is 12 seconds and an epoch is 32 slots: 384 seconds or 6.4 minutes. Each slot has a validator assigned to propose a block, while committees of validators attest to the block’s validity. + +A slot is a chance for a block to be added to the Beacon Chain. Every 12 seconds, one block is added. Validators need to be roughly [synchronized with time](https://ethresear.ch/t/network-adjusted-timestamps/4187). A slot is like the block time, but slots can be empty. The Beacon Chain genesis block is at Slot 0. + + + + +
+ +![Diagram for slots and epoch](../../images/cl/slots-and-epochs.png) + +
+ +_The first 32 slots are in Epoch 0. Genesis block is at Slot 0._ + +
+
+ + +### Validators and Attestations + +A block proposer is a validator that has been pseudo-randomly selected to build a block. Validators propose blocks and attest to the blocks proposed by others. Most of the time, validators are attesters that vote on blocks. These votes are recorded in the Beacon Chain and determine the head of the Beacon Chain. + +Attestations are votes on the validity of the blocks, which are aggregated into the Beacon Chain to ensure consensus. + + + +
+ +![Diagram for Validator selection](../../images/cl/validators.png) + +
+ +_A slot can be missed as you can see in this diagram on 28th slot_ + +
+
+ +An **attestation** is a validator’s vote, weighted by the validator’s stake. Attestations are broadcasted by validators in addition to blocks. Validators also police each other and are rewarded for reporting other validators that make conflicting votes, or propose multiple blocks. + +The contents of the Beacon Chain is primarily a registry of validator addresses, the state of each validator, and attestations. Validators are activated by the Beacon Chain and can transition to states + +**IMPORTANT NOTE on Staking Validators Semantics:** *In Ethereum's PoS, users activate validators by staking ETH, similar to buying hardware in PoW. Stakers are associated with the amount staked, while validators have a maximum balance of 32 ETH each. For every 32 ETH staked, one validator is activated. Validators are run by validator clients, which use a beacon node to follow and read the Beacon Chain. A single validator client can manage multiple validators.* + +### Committees + +Committees are groups of at least 128 validators assigned to each slot for added security. An attacker has less than a 1 in a trillion chance of controlling ⅔ of a committee. + +The concept of a randomness beacon that emits random numbers for the public, is how Beacon Chain got it's name. The Beacon Chain enforces consensus on a pseudorandom process called RANDAO. + + +
+ +![Diagram for Validator selection](../../images/cl/RANDAO.png) + +
+ +_At every epoch, a pseudorandom process RANDAO selects proposers for each slot, and shuffles validators to committees._ + +
+
+ +**Validator Selection:** +- As mentioned earlier, Proposers are chosen by RANDAO, weighted by validator balance. +- A validator can be both a proposer and a committee member for the same slot, but this is rare (1/32 probability). + +The sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot. + + + +
+ +![Diagram for Committees](../../images/cl/committees.png) + +
+ +The diagram is a combined depiction of what happened in 3 slots: +- Slot 1: A block is proposed and attested by two validators; one validator is offline. +- Slot 2: A block is proposed, but one validator misses it and attests to the previous block. +- Slot 3: All validators in Committee C attest to the same head, following the LMD GHOST rule. + +Validators attest to their view of the Beacon Chain head using the LMD GHOST rule. +Attestations help finalize blocks by reaching consensus on the blockchain’s state. + +**Committee Size and Security:** +- With more than 8,192 validators, multiple committees per slot are formed. +- Committees must be at least 128 validators for optimal security. +- Security decreases with fewer than 4,096 validators, as committee sizes drop below 128. + +> At every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. All of the validators from that slot attest to the Beacon Chain head. A shuffling algorithm scales up or down the number of committees per slot to get at least 128 validators per committee. More details on shuffling can be found in [proto's repo.](https://github.com/protolambda/eth2-docs#shuffling) + +### Blobs + +[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), also known as proto-danksharding, is part of the Deneb/Cancun hardfork. It introduces a data availability layer to Ethereum, allowing for the temporary storage of arbitrary data on the blockchain. This arbitrary data stored this way are called `blobs`, and each block can have 3 ~ 6 blob sidecars (wrappers for blobs). EIP-4844 marks Ethereum's first step towards sharding and scalability, enabling Layer 2 solutions (L2s) to use this data availability layer to lower gas fees and process more transactions. + +### Design and Implementation + +A key design decision in EIP-4844 is the use of [KZG commitments](/wiki/Cryptography/kzg.md) to verify blobs and support future proposer-builder separation. To use KZG commitments, a Trusted Setup is needed. For the Deneb hardfork, a [KZG Ceremony](https://github.com/ethereum/kzg-ceremony) was conducted to create this Trusted Setup. + + + +
+ +![Diagram for Blobs](../../images/cl/blobs.png) + +
+ +### Storage Requirements + +The most significant impact on node operators is the increased storage requirement. Node runners will need more storage: + +``` +131,928 ssz bytes per blob * 4096 blobs retention period * +32 potential blocks per epoch * 3~6 blob sidecars per block + += 52~104GB +``` + +By default, these blobs will be retained for 4096 epochs, and clients would prune the oldest blobs once the retention period is reached. + +### Checkpoints and Finality + +At the end of each epoch, checkpoints are created. A checkpoint is a block in the first slot of an epoch. If there is no such block, then the checkpoint is the preceding most recent block. There is always one checkpoint block per epoch. A block can be the checkpoint for multiple epochs. + +A block becomes a checkpoint if it receives attestations from a majority of validators. Checkpoints are used to finalize the blockchain's state. A block is considered final when it is included in two-thirds of the most recent checkpoint attestations, ensuring it cannot be reverted. + + +
+ +![Diagram for checkpoints](../../images/cl/checkpoints.jpg) + +
+ +_Checkpoints for a scenario where epoch contain 64 slots_ + +
+
+ +For example, if Slots 65 to 128 are empty, the Epoch 2 checkpoint defaults to the block at Slot 64. Similarly, if Slot 192 is empty, the Epoch 3 checkpoint is the block at Slot 180. **Epoch boundary blocks (EBB)** is a term in some literature (such as the [Gasper](https://arxiv.org/abs/2003.03052) paper, the source of the diagram above and a later one), and they can be considered synonymous with checkpoints. + +Validators cast two types of votes: **LMD GHOST** votes for blocks and **Casper FFG** votes for checkpoints. An **FFG** vote includes a source checkpoint from a previous epoch and a target checkpoint from the current epoch. For example, a validator in Epoch 1 might vote for a source checkpoint at the genesis block and a target checkpoint at Slot 64, repeating the same vote in Epoch 2. Only Validators assigned to a slot cast LMD GHOST votes, while all validators cast FFG votes for epoch checkpoints. + +#### Supermajority and Finality + +A supermajority, defined as ⅔ of the total validator balance, is required for a checkpoint to be justified. For instance, if validators have balances of 8 ETH, 8 ETH, and 32 ETH, a supermajority needs the vote of the 32 ETH validator. Once a checkpoint receives a supermajority, it becomes justified. If the subsequent epoch's checkpoint also achieves justification, the previous checkpoint is finalized, securing all preceding blocks. Typically, this process spans two epochs (12.8 minutes). + +When a user transaction is included in a block, On average it would be somewhere in the middle of an epoch. It takes half an epoch (about 3.2 minutes) to reach the next checkpoint, suggesting transaction finality of 2.5 epochs: 16 minutes. Optimally, more than ⅔ of attestations will have been included by the 22nd (2/3rd of 32) slot of an epoch. Thus, transaction finality is an average of 14 minutes (16+32+22 slots). Block confirmations emerge from a block’s attestations, then move to its justification, to its finality. Use cases can decide whether they need finality or an earlier safety threshold is sufficient. + + +
+ +![Diagram for Finality](../../images/cl/finalization.png) + +
+ +_Example of one checkpoint getting justified (Slot 64) and finalizing a prior checkpoint (Slot 32)._ + +
+
+ +**What happened at the Beacon Chain head:** +At Slot 96, a block is proposed that includes attestations (votes) for the Epoch 2 checkpoint. These attestations reach the required two-thirds supermajority, justifying the Epoch 2 checkpoint. This action finalizes the previously justified Epoch 1 checkpoint. When the Epoch 1 checkpoint is finalized, all preceding blocks (up to Slot 32) also become final. Finality calculations happen at epoch boundaries, but attestations accumulate with each block. + +**What could have happened from genesis to the head:** +- **Scenario 1:** + - Proposers from Slot 1 to Slot 63 propose blocks. + - Each block in Epoch 1 contributes attestations for the checkpoint at Slot 32, eventually reaching 55%. + - The block at Slot 64 includes additional attestations, bringing support for the Slot 32 checkpoint to 70%, causing its justification. + - Throughout Epoch 2, the Slot 64 checkpoint gathers attestations but doesn't reach the two-thirds threshold until Slot 96, where it is justified. + - Justifying the Epoch 2 checkpoint finalizes the Epoch 1 checkpoint and all preceding blocks. + +- **Scenario 2:** + - The checkpoint at Epoch 1 could reach the two-thirds supermajority before the next epoch. + - For example, blocks from Slot 32 to Slot 54 could provide enough attestations to justify the checkpoint at Slot 32. + - In this case, the Slot 32 checkpoint would be justified within its current epoch but would need the next epoch to finalize. + +**Special Cases:** +The justification of a checkpoint can sometimes finalize blocks from two or more epochs ago, especially during periods of high latency, network partitions, or attacks, You can find more such cases, discussed in the Gasper paper. These scenarios are exceptional and not the norm. + + +#### Closer Look on Attestations + +Validators submit one attestation per epoch, containing both an LMD GHOST and an FFG vote. These attestations have 32 chances per epoch for inclusion on-chain, with earlier inclusions receiving higher rewards. This means a validator may have two attestations included on-chain in a single epoch. Validators are rewarded the most when their attestation is included on-chain at their assigned slot; later inclusion has a decayed reward. To give validators time to prepare, they are assigned to committees one epoch in advance. Proposers are only assigned to slots once the epoch starts. Nonetheless, [secret leader election](https://ethresear.ch/t/low-overhead-secret-single-leader-election/5994) research aims to mitigate attacks or bribing of proposers. + +Consider a block proposed at Slot 64 containing attestations for the Epoch 2 checkpoint. This scenario can finalize the checkpoint at Slot 32. The finality of the Slot 32 checkpoint, once achieved, propagates backward, securing all preceding blocks. + +In essence, Committees allow for the technical optimization of combining signatures from each attester into a single aggregate signature. When validators in the same committee make the same LMD GHOST and FFG votes, their signatures can be aggregated. + +### Staking Rewards and Penalties + +Ethereum’s PoS system employs a comprehensive set of rewards and penalties to incentivize validator behavior and maintain network security. This section covers six key aspects of these incentives: + +**1. Attester Rewards:** +Validators earn rewards for making attestations (LMD GHOST and FFG votes) that align with the majority of other validators. Attestations included in finalized blocks are more valuable. + +**2. Attester Penalties:** +Validators are penalized for failing to attest or for attesting to blocks that do not get finalized. These penalties ensure validators remain active and aligned with the network’s consensus. + +**3. Typical Downside Risk for Stakers:** +Stakers can estimate their downside risk by comparing potential earnings and penalties. An honest validator earning 10% in a year could lose up to 7.5% for poor performance. Minor penalties apply for short-term inactivity, while prolonged offline periods incur larger penalties. + +**4. Slashings and Whistleblower Rewards:** +Slashing penalizes validators for serious protocol violations. Penalties range from over 0.5 ETH up to the entire stake. For example, a validator committing a slashable offense loses at least 1/32 of their balance and is deactivated. Additional penalties are proportional to the number of validators slashed simultaneously. A whistleblower who reports a slashable offense receives a reward, which currently goes to the block proposer. + +**5. Proposer Rewards:** +Block proposers receive substantial rewards for proposing blocks that get finalized. Consistently performing validators gain approximately a 1/8 boost to their total rewards. Additionally, proposers receive small rewards for including slashing evidence in their blocks. + +**6. Inactivity Leak Penalty:** +The inactivity leak is a severe penalty designed to ensure the network’s finality. If finality is delayed for more than four epochs, validators suffer increasing penalties until a checkpoint is finalized. This mechanism drains the balances of inactive validators, leading to their forced exit, thus allowing active validators to form a ⅔ majority to resume finality. During an inactivity leak, only proposer and whistleblower rewards are earned, while attester rewards are zero. + + +### **Slashable Offenses:** +There are four conditions under which a validator can be slashed: +- **Double Proposal:** Proposing more than one block for their assigned slot. +- **LMD GHOST Double Vote:** Attesting to different Beacon Chain heads for the same slot. +- **FFG Surround Vote:** Casting an FFG vote that surrounds or is surrounded by a previous FFG vote by the same validator. +- **FFG Double Vote:** Casting two FFG votes for different targets in the same epoch. + +## Beacon Chain Validator Activation and Lifecycle: + +A validator requires 32 ETH to be activated. Validators are deactivated if their balance falls to 16 ETH, with any remaining balance withdrawable. Validators can also voluntarily exit after serving 2,048 epochs (approximately nine days). + +Upon exit, there is a delay of four epochs before withdrawal, during which validators can still be slashed. + +Honest validators can withdraw their balance in about 27 hours, whereas slashed validators face a delay of approximately 36 days (8,192 epochs). + + +
+ +![Diagram for Validator Lifecycle](../../images/cl/validator-lifecycle.png) + +
+ +To prevent rapid changes in the validator set, mechanisms limit how many validators can be activated or exited per epoch. The Beacon Chain also employs effective balances for technical optimization, which change less frequently than actual validator balances. + +#### Overall Effects +At every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. Validators can only be in one slot, and in one committee. Collectively: + +- All validators in an epoch attempt to finalize the same checkpoint: FFG vote +- All validators assigned to a slot attempt to vote on the same Beacon Chain head: LMD GHOST vote +Optimal behavior rewards validators the most. + +The Beacon Chain's introduction on December 1, 2020, began with 21,063 validators. The number of validators can decrease with slashings or voluntary exits, or more stakers can join and be activated. Fast forward to today(15th May, 2024) there are more than 1,000,000 validators that are active on Ethereum Network. The world has never seen a scalable platform for decentralized systems and applications like Ethereum. + + + + +### References + +- [Beacon Chain Explainer from ethos.dev](https://ethos.dev/beacon-chain) +- [Evolution of Ethereum Proof-of-Stake](https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md) +- Alt Explainer, [Ethereum's Proof-of-Stake consensus explained](https://www.youtube.com/watch?v=5gfNUVmX3Es) +- [Eth2 Handbook by Ben Edgington](https://eth2book.info/capella/part2/consensus/) diff --git a/docs/wiki/EL/el-architecture.md b/docs/wiki/EL/el-architecture.md index 487e2c49..e053f0a1 100644 --- a/docs/wiki/EL/el-architecture.md +++ b/docs/wiki/EL/el-architecture.md @@ -184,7 +184,7 @@ The execution layer has its own consensus engine to work with its own copy of th | $H_{difficulty} = 0 $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L327) | | | | | | | $H_{nonce} = 0x0000000000000000 $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L328) | | | | | | | $H_{prevRandao} = PREVRANDAO() $ (this is stale , beacon chain provides this now) | | | | | | | -| $H_{withdrawlsHash} \neq nil $ | | | | | | | +| $H_{withdrawalHash} \neq nil $ | | | | | | | | $H_{blobGasUsed} \neq nil $ | | | | | | | | $H_{blobGasUsed} \leq MaxBlobGasPerBlock_{=786432} $ | | | | | | | | $H_{blobGasUsed} \% GasPerBlob_{=2^{17}} = 0 $ | | | | | | | diff --git a/docs/wiki/EL/el-specs.md b/docs/wiki/EL/el-specs.md index cdfd683b..5fc8ac84 100644 --- a/docs/wiki/EL/el-specs.md +++ b/docs/wiki/EL/el-specs.md @@ -95,7 +95,7 @@ $$H_{difficulty} = 0\qquad (57k)$$ $$\land $$ $$H_{nonce} = 0x0000000000000000 \qquad (57l)$$ $$\land$$ -$$H_{withdrawlsHash} \neq nil \qquad (57n)$$ +$$H_{withdrawalHash} \neq nil \qquad (57n)$$ $$\land$$ $$H_{blobGasUsed} \neq nil \qquad (57o)$$ $$\land$$ diff --git a/docs/wiki/protocol/design-rationale.md b/docs/wiki/protocol/design-rationale.md index 5bc8c129..dce685ba 100644 --- a/docs/wiki/protocol/design-rationale.md +++ b/docs/wiki/protocol/design-rationale.md @@ -96,11 +96,26 @@ The [Casper FFG](https://arxiv.org/abs/1710.09437v4) is an overlay atop a propos Simply put, each validator votes on the checkpoint, and after two rounds of voting, the checkpoint is **finalized**. All finalized checkpoints become part of the canonical chain (part of the blockchain history). While Casper guarantees **finality** through attestations to the latest block addition to the canonical chain, it requires a fork-choice rule where validators attest to blocks to signal support for those blocks. - ***LMD GHOST*** -Latest Message Driven Greediest Heaviest Observed Sub-Tree (LMD-GHOST) is a *fork choice rule* where validators attests to blocks to signal support for those blocks. This similar in some ways to the fork choice rule used in Proof-of-Work network, where the fork with the most work done is selected as the canonical chain. +Latest Message Driven Greediest Heaviest Observed Sub-Tree (LMD-GHOST) is a *fork choice rule* where validators attests to blocks to signal support for those blocks. This similar in some ways to the fork choice rule used in Proof-of-work network, where the fork with the most work done is selected as the canonical chain. ![LMD-GHOST-Algorithm](./img/lmt-ghost.png) -Gasper is full Proof-of-stake protocol that serves as an idealized abstraction of the Ethereum implementation. It combines Casper FFG and LMD-GHOST to drive the consensus mechanism for the Eth2. +Gasper is full Proof-of-stake protocol that serves as an idealized abstraction of the Ethereum implementation. It combines Casper FFG and LMD-GHOST to drive the consensus mechanism for the Eth2. + +### Using a DHT + +![P2P Networks Comparison](./img/p2p-nets-comp.png) + +The main benefit of DHTs is that lookups only generate logarithmic communication overhead in the network. This makes them suitable to find (query) content in a p2p network. But an immediate question arises, why do we need to *find* content in Ethereum if most nodes are interested in the same content, the latest block? The tip of the chain is always the same based on consensus slot which has only one block to be gossiped. A DHT is used in protocols like [bittorrent](https://www.bittorrent.org/beps/bep_0005.html) and IPFS which store a wide range of content and users try to *find* the content they are interested in. DHT is used in Ethereum networking to find to find different peers, not blocks. + +The discovery protocol in the networking layer of Ethereum uses, discv5, a [kademlia based DHT](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) to store [ENR records](https://github.com/ethereum/devp2p/blob/master/enr.md). ENR records contain routing information (of the internet layer) to establish connections between peer. Peers joining the network use *bootstrap* nodes to relay lookup queries for its own `node_id` in the DHT. In the process they discover ENR records of other peers which help them populate their routing table. Routinely, peers also look up random `node_id`s to enumerate the network i.e. find all peers. + +Blocks in Ethereum network are distributed using gossip protocol of the p2p stack. After discovering peers through an underlying DHT, peers use an overlay network ([gossipsub](https://github.com/libp2p/specs/blob/f25d0c22e5ef045c8c050bc91c297468de35f720/pubsub/gossipsub/gossipsub-v1.0.md)) to disseminate the block throughout the network. The overlay network creates its own routing table with routing information to establish connection AND overlay specific information(topics subscribed, fanout etc.) This overlay network is indeed an unstructured network. + +DHT goes the extra step to join an unstructured network over simply connecting to peers ([friends-to-friends model](https://en.wikipedia.org/wiki/Friend-to-friend) or PEX) and directly downloading/gossiping the required content directly. +Why go through an extra step of DHT to later join an unstructured network? From the perspective of bootstrapping, kademlia provides a global view whereas f2f networks, inherently, can only provide a local view of the network. Informally, a DHT provides public and non-localized (arguably, slightly more decentralized too) mechanism for nodes to join a network. This hybrid approach of using a structured network(DHT) to bootstrap into an unstructured network, is observed in bittorrent's [Peer Exchange(PEX)](https://www.bittorrent.org/beps/bep_0011.html) protocol as well. [Unstructured networks](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks) are preferred as overlays because they are robust in high-churn networks. + +Over everything else, the biggest benefit of structured networks like kademlia DHT is their [simplicity](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-rationale.md#why-kademlia) in design. # References diff --git a/docs/wiki/protocol/history.md b/docs/wiki/protocol/history.md index c4b21f4f..bf3d9f3b 100644 --- a/docs/wiki/protocol/history.md +++ b/docs/wiki/protocol/history.md @@ -6,13 +6,23 @@ This page highlights important technical changes in the history of Ethereum prot Useful links: [Overview from Ethereum.org](https://ethereum.org/en/history) and [Meta EIPs from Ethereum.org](https://eips.ethereum.org/meta) +## Frontier + +The Frontier release marked the launch of the Ethereum Protocol. The release was essentially a beta release that allowed developers to learn, experiment, and begin building Ethereum decentralized apps and tools. It was launched on July 30, 2015, at 3:26:13 AM UTC, which is the timestamp of the [Ethereum genesis block](https://etherscan.io/block/0). Frontier launched with a gas limit of 5000. This gas limit was hard coded into the protocol to ensure that miners and users could get up and running by installing clients during the initial launch of the protocol. The gas limit would later be increased to 3 million with the Frontier thawing fork (exactly 3,141,592). The canary contracts were contracts that gave a binary signal of either 0 or 1. These canary contracts were an initial launch mechanism used only during the Frontier release of Ethereum. If clients detected that multiple contracts had switched to a signal of 1, they would stop mining and urge the user to update their client. This prevented prolonged outages by ensuring that miners did not prevent a chain upgrade. + +Learn more about Frontier in the following resources: + +- [Frontier is coming, what to expect and how to prepare](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare) +- [The thawing frontier](https://blog.ethereum.org/2015/08/04/the-thawing-frontier) +- [ethereum.org web archive](https://web.archive.org/web/20150802035735/https://www.ethereum.org/) +- [ethereum-protocol-update-1](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1) + ## Homestead -The first version of Ethereum, called the Frontier release, was essentially a beta release that allowed developers to learn, experiment, and begin building Ethereum decentralized apps and tools. -Homestead was the second major version of the Ethereum platform, officially released on March 14, 2016, marking Ethereum’s transition from a beta phase to a more mature and stable platform. +Homestead was the second major release of the Ethereum protocol, officially released on March 14, 2016, marking Ethereum’s transition from a beta phase to a more mature and stable platform. Here are some of the notable features and changes introduced during the Homestead phase: -- [EIP-2](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md): Homestead Hard-fork Changes +- [EIP-2](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md): EIP-2 contained numerous fixes, such as increasing the gas cost for contract creation via transactions, ensuring that contract creation either succeeded or failed (preventing empty contracts from being created), and modifications to the difficulty adjustment algorithm. 1. **Increased gas cost for contract creation:** The gas cost for creating contracts via a transaction was increased from 21,000 to 53,000. @@ -27,23 +37,24 @@ Here are some of the notable features and changes introduced during the Homestea The difficulty adjustment algorithm was modified to address issues observed in the Frontier phase. The new formula aimed to maintain the targeted block time and prevent excessive deviation by adjusting the difficulty based on the timestamp difference between blocks. -- [EIP-7](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md): `DELEGATECALL` +- [EIP-7](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md): EIP-7 introduced the `DELEGATECALL` opcode. A new opcode, `DELEGATECALL`, was added at `0xf4`. It functions similarly to `CALLCODE`, but propagates the sender and value from the parent scope to the child scope. Propagating the sender and value makes it easier for contracts to store another address as a mutable source of code and "pass through" calls to it. Unlike the `CALL` opcode, there is no additional stipend of gas added, which makes gas management more predictable. -- [EIP-8](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md): devp2p Forward Compatibility Requirements for Homestead +- [EIP-8](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md): EIP-8 ensures that clients on Ethereum support future network upgrades by introducing devp2p forward compatibility requirements. The **devp2p Wire Protocol**, **RLPx Discovery Protocol**, and **RLPx TCP Transport Protocol** specify that implementations should be liberal in accepting packets by ignoring version numbers and additional list elements in hello and ping packets, discarding unknown packet types silently, and accepting new encodings for encrypted key establishment handshake packets. This ensures all client software can cope with future protocol upgrades and will accept handshakes, allowing liberal acceptance of data from others (see [Postel's Law](https://en.wikipedia.org/wiki/Robustness_principle)). +Learn more about Homestead in the following resources: -Additional Resources: - [Ethereum Homestead Documentation](https://readthedocs.org/projects/ethereum-homestead/downloads/pdf/latest/) - [The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945) - +- [Homestead blog release post](https://blog.ethereum.org/2016/02/29/homestead-release) +- [The Homestead release - github](https://github.com/ethereum/homestead-guide/blob/master/source/introduction/the-homestead-release.rst) ## The Merge diff --git a/docs/wiki/protocol/img/overview/alan-turing.jpg b/docs/wiki/protocol/img/overview/alan-turing.jpg new file mode 100644 index 00000000..473ad2cb Binary files /dev/null and b/docs/wiki/protocol/img/overview/alan-turing.jpg differ diff --git a/docs/wiki/protocol/img/overview/crypto-anarchy.jpg b/docs/wiki/protocol/img/overview/crypto-anarchy.jpg new file mode 100644 index 00000000..be0d1eeb Binary files /dev/null and b/docs/wiki/protocol/img/overview/crypto-anarchy.jpg differ diff --git a/docs/wiki/protocol/img/overview/cypherpunks-write-code.jpg b/docs/wiki/protocol/img/overview/cypherpunks-write-code.jpg new file mode 100644 index 00000000..6e2823e7 Binary files /dev/null and b/docs/wiki/protocol/img/overview/cypherpunks-write-code.jpg differ diff --git a/docs/wiki/protocol/img/overview/david-chaum.jpg b/docs/wiki/protocol/img/overview/david-chaum.jpg new file mode 100644 index 00000000..681ad7c2 Binary files /dev/null and b/docs/wiki/protocol/img/overview/david-chaum.jpg differ diff --git a/docs/wiki/protocol/img/overview/digicash.jpg b/docs/wiki/protocol/img/overview/digicash.jpg new file mode 100644 index 00000000..915c8ea7 Binary files /dev/null and b/docs/wiki/protocol/img/overview/digicash.jpg differ diff --git a/docs/wiki/protocol/img/overview/ethereum-launch.jpg b/docs/wiki/protocol/img/overview/ethereum-launch.jpg new file mode 100644 index 00000000..efdc81c7 Binary files /dev/null and b/docs/wiki/protocol/img/overview/ethereum-launch.jpg differ diff --git a/docs/wiki/protocol/img/overview/gnu-announcement.jpg b/docs/wiki/protocol/img/overview/gnu-announcement.jpg new file mode 100644 index 00000000..0f96b465 Binary files /dev/null and b/docs/wiki/protocol/img/overview/gnu-announcement.jpg differ diff --git a/docs/wiki/protocol/img/overview/information-superhighway.gif b/docs/wiki/protocol/img/overview/information-superhighway.gif new file mode 100644 index 00000000..fcae8f2c Binary files /dev/null and b/docs/wiki/protocol/img/overview/information-superhighway.gif differ diff --git a/docs/wiki/protocol/img/overview/inventors-of-modern-cryptography.jpg b/docs/wiki/protocol/img/overview/inventors-of-modern-cryptography.jpg new file mode 100644 index 00000000..9d90c3c8 Binary files /dev/null and b/docs/wiki/protocol/img/overview/inventors-of-modern-cryptography.jpg differ diff --git a/docs/wiki/protocol/img/overview/ken-thompson-dennis-ritchie.jpg b/docs/wiki/protocol/img/overview/ken-thompson-dennis-ritchie.jpg new file mode 100644 index 00000000..de8f7f26 Binary files /dev/null and b/docs/wiki/protocol/img/overview/ken-thompson-dennis-ritchie.jpg differ diff --git a/docs/wiki/protocol/img/overview/linux-announcement.jpg b/docs/wiki/protocol/img/overview/linux-announcement.jpg new file mode 100644 index 00000000..5d4daa84 Binary files /dev/null and b/docs/wiki/protocol/img/overview/linux-announcement.jpg differ diff --git a/docs/wiki/protocol/img/overview/namecoin.png b/docs/wiki/protocol/img/overview/namecoin.png new file mode 100644 index 00000000..53010978 Binary files /dev/null and b/docs/wiki/protocol/img/overview/namecoin.png differ diff --git a/docs/wiki/protocol/img/overview/new-direction-in-cryptography.jpg b/docs/wiki/protocol/img/overview/new-direction-in-cryptography.jpg new file mode 100644 index 00000000..154ee3b3 Binary files /dev/null and b/docs/wiki/protocol/img/overview/new-direction-in-cryptography.jpg differ diff --git a/docs/wiki/protocol/img/overview/nsa-crypto-wars.jpg b/docs/wiki/protocol/img/overview/nsa-crypto-wars.jpg new file mode 100644 index 00000000..bba1298d Binary files /dev/null and b/docs/wiki/protocol/img/overview/nsa-crypto-wars.jpg differ diff --git a/docs/wiki/protocol/img/overview/nsa-cryptology-debate.jpg b/docs/wiki/protocol/img/overview/nsa-cryptology-debate.jpg new file mode 100644 index 00000000..70cce568 Binary files /dev/null and b/docs/wiki/protocol/img/overview/nsa-cryptology-debate.jpg differ diff --git a/docs/wiki/protocol/img/overview/phil-zimmermann.jpg b/docs/wiki/protocol/img/overview/phil-zimmermann.jpg new file mode 100644 index 00000000..33a0c698 Binary files /dev/null and b/docs/wiki/protocol/img/overview/phil-zimmermann.jpg differ diff --git a/docs/wiki/protocol/img/overview/rsa-challenge.jpg b/docs/wiki/protocol/img/overview/rsa-challenge.jpg new file mode 100644 index 00000000..7ea15299 Binary files /dev/null and b/docs/wiki/protocol/img/overview/rsa-challenge.jpg differ diff --git a/docs/wiki/protocol/img/overview/rsa-in-scientific-american.jpg b/docs/wiki/protocol/img/overview/rsa-in-scientific-american.jpg new file mode 100644 index 00000000..493dec73 Binary files /dev/null and b/docs/wiki/protocol/img/overview/rsa-in-scientific-american.jpg differ diff --git a/docs/wiki/protocol/img/overview/satoshi-and-bitcoin.jpg b/docs/wiki/protocol/img/overview/satoshi-and-bitcoin.jpg new file mode 100644 index 00000000..25c2da34 Binary files /dev/null and b/docs/wiki/protocol/img/overview/satoshi-and-bitcoin.jpg differ diff --git a/docs/wiki/protocol/img/overview/type-in-program.jpg b/docs/wiki/protocol/img/overview/type-in-program.jpg new file mode 100644 index 00000000..4095ff33 Binary files /dev/null and b/docs/wiki/protocol/img/overview/type-in-program.jpg differ diff --git a/docs/wiki/protocol/img/overview/wei-dai-nick-szabo.jpg b/docs/wiki/protocol/img/overview/wei-dai-nick-szabo.jpg new file mode 100644 index 00000000..452a4e6b Binary files /dev/null and b/docs/wiki/protocol/img/overview/wei-dai-nick-szabo.jpg differ diff --git a/docs/wiki/protocol/img/overview/wire-tap-surveillance.jpg b/docs/wiki/protocol/img/overview/wire-tap-surveillance.jpg new file mode 100644 index 00000000..c090805d Binary files /dev/null and b/docs/wiki/protocol/img/overview/wire-tap-surveillance.jpg differ diff --git a/docs/wiki/protocol/img/p2p-nets-comp.png b/docs/wiki/protocol/img/p2p-nets-comp.png new file mode 100644 index 00000000..c7b94b47 Binary files /dev/null and b/docs/wiki/protocol/img/p2p-nets-comp.png differ diff --git a/docs/wiki/protocol/overview.md b/docs/wiki/protocol/overview.md deleted file mode 100644 index e69de29b..00000000 diff --git a/docs/wiki/protocol/prehistory.md b/docs/wiki/protocol/prehistory.md new file mode 100644 index 00000000..960dc6d6 --- /dev/null +++ b/docs/wiki/protocol/prehistory.md @@ -0,0 +1,319 @@ +# Prehistory of Ethereum + +> “Heroes are heroes because they are heroic in behavior, not because they won or lost.”\ +> — Nicholas Taleb + +This article explores the lineage of Ethereum, celebrating the heroes who influenced it with their courage, creativity, and sheer rebellion. + +Ethereum has its roots in the early internet's open spirit, with its design philosophy echoing the Unix ideal of 'doing one thing and doing it well'. The rise of the free and open source movement, embodied by GNU/Linux, reaffirmed open standards in software. Meanwhile, breakthroughs in public key cryptography and its advocacy by the cypherpunks laid the groundwork for secure, transparent, and decentralized systems like Bitcoin which ultimately inspired Ethereum's vision of building a platform for a borderless, self-sovereign digital economy. + +> “If you look at the people that were involved in the early stages of the Bitcoin space, their earlier pedigrees, if they had any pedigrees at all, were in open source—Linux, Mozilla, and cypherpunk mailing lists.”\ +> — _Vitalik Buterin, Co-founder of Ethereum._ + +## The information super highway + +From its humble beginnings in 1969 as a Cold War project ([ARPANET](https://en.wikipedia.org/wiki/ARPANET)), the internet has evolved into an unprecedented global phenomenon. + +> "The Internet's pace of adoption eclipses all other technologies that preceded it. Radio was in existence 38 years before 50 million people tuned in; TV took 13 years to reach that benchmark. Sixteen years after the first PC kit came out, 50 million people were using one. Once it was opened to the general public, the Internet crossed that line in four years."\ +> — [The Emerging Digital Economy,(July 1998).](https://www.commerce.gov/sites/default/files/migrated/reports/emergingdig_0.pdf) + +![A map of internet cables from 1989 to 2021.](img/overview/information-superhighway.gif) +**A map of internet cables from 1989 to 2021. [Source: The New York Times.](https://www.nytimes.com/interactive/2019/03/10/technology/internet-cables-oceans.html)** + +What started as a research tool for a handful of institutions now connects billions worldwide, collapsing geographical borders and facilitating human interactions that were once inconceivable. + +> "National borders are just speed bumps on the information superhighway."\ +> — Timothy May, Cypherpunk. + +## Unix & Bell Labs + +Unix originated from the efforts to simplify the complexities of [MULTICS](https://en.wikipedia.org/wiki/Multics), a large and ambitious operating system project of the 1960s. As MULTICS became unwieldy, a small group including [Ken Thompson](https://en.wikipedia.org/wiki/Ken_Thompson) and [Dennis Ritchie](https://en.wikipedia.org/wiki/Dennis_Ritchie) at AT&T Bell Labs sought to create Unix - a more modular, simpler, and composable alternative: + +> "At some point I realized that I was three weeks from an operating system. I'll needed an editor, assembler, and kernel overlay — call it an operating system. One week, one week, one week, and we had Unix."\ +> — [_Ken Thompson in an interview_](https://www.youtube.com/watch?v=EY6q5dv_B-o) + +In 1972, Dennis also wrote the influential [C language](). + +![Ken Thompson and Dennis Ritchie](img/overview/ken-thompson-dennis-ritchie.jpg) +**Ken Thompson and Dennis Ritchie.** + +Bell Labs was an unparalleled incubator of the century's most defining technological building blocks: + +> "You couldn't go to the store and buy a Bell Labs innovation, yet it was deep inside other things; it was platform innovation integral to communications infrastructure."\ +> — Jon G., The Idea Factory + +> 🎦 WATCH: [Jon talk about innovations at Bell Labs.](https://www.youtube.com/watch?v=OJsKgiGGzzs) + +In many ways, [Ethereum functions](https://ethereum.foundation/infinitegarden) like an open Bell Labs. + +Unix introduced concepts like hierarchical file systems, the shell as a command-line interface, single-purpose utilities that could be combined to perform complex tasks. +These foundational principles laid the groundwork for what became known as the UNIX philosophy — favoring simplicity, flexibility, and reusability in software design. + +Today, UNIX and its derivatives continue to underpin much of modern computing, influencing everything from operating systems like Linux and macOS to the principles of timeless software development. + +> 🎦 WATCH: [The Unix documentary.](https://www.youtube.com/watch?v=tc4ROCJYbm0) + +The Unix legacy demonstrates the profound influence a small group of individuals can have on the world through software. + +## Can we keep a secret? + +Since the dawn of civilization, the need to convey messages in secrecy has been a constant human pursuit. From merchants concealing trade secrets to spies and the military transmitting critical information, cryptography has played a vital role. Early methods often used the same key for both encryption and decryption, making secure key distribution a nightmare: + +> "The problem of producing, registering, distributing and canceling the keys, may seem slight to an individual who has not had experience with military communications, but in wartime the volumes of traffic stagger even the signal staffs."\ +> — [David Kahn writes in _the codebreakers_](https://en.wikipedia.org/wiki/The_Codebreakers) + +If a key fell into enemy hands, messages were vulnerable. This was evident in World War II with the cracking of the [Enigma machine](https://en.wikipedia.org/wiki/Enigma_machine), a sophisticated German cipher, by mathematician [Alan Turing](https://en.wikipedia.org/wiki/Alan_Turing) and his team. Their success significantly altered the outcome of the war. + +![A statue of Alan Turing and the Enigma machine.](img/overview/alan-turing.jpg) +**A statue of Alan Turing and the Enigma machine.** + +How do you securely exchange keys over long distances, between people who have never met? Critics believed that cryptography was destined to be dependent on trust: + +> "Few persons can be made to believe that it is not quite an easy thing to invent a method of secret writing which shall baffle investigation. Yet it may be roundly asserted that human ingenuity cannot concoct a cipher which human ingenuity cannot resolve."\ +> — Edgar Allan Poe + +Poe was proven wrong by a series of inventions from 1974-1978. + +In 1974, [Ralph Merkle](https://en.wikipedia.org/wiki/Ralph_Merkle) devised [Merkle's Puzzles](https://en.wikipedia.org/wiki/Merkle%27s_Puzzles) - an initial method that allowed two parties to agree on a shared secret by exchanging messages, even if they have no secrets in common beforehand. + +Two years later, in 1976, Merkle’s work inspired [Whitfield Diffie](https://en.wikipedia.org/wiki/Whitfield_Diffie) and [Martin Hellman](https://en.wikipedia.org/wiki/Martin_Hellman) to publish their historic paper ["New directions in cryptography"](https://ee.stanford.edu/~hellman/publications/24.pdf) that introduced [Diffie–Hellman key exchange algorithm.](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) This approach was significantly more mathematically robust than Merkle's puzzles - giving birth to trustless cryptography. + +![Whitfield and Martin published "New directions in cryptography"](img/overview/new-direction-in-cryptography.jpg) +**Whitfield and Martin published "New directions in cryptography".** + +In the following year, 1977, computer scientists [Ronald Rivest](http://amturing.acm.org/award_winners/rivest_1403005.cfm), [Adi Shamir](http://amturing.acm.org/award_winners/shamir_2327856.cfm), and [Leonard Adleman](http://amturing.acm.org/award_winners/adleman_7308544.cfm) developed the [RSA cryptosystem]() - the first working implementation of public key cryptography in a paper titled ["A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"](https://people.csail.mit.edu/rivest/Rsapaper.pdf). Rivest sent a copy of the paper to mathematician Martin Gardner. Martin was so impressed that he broke his usual rule of planning his column several months in advance, and quickly wrote it up for [publication in the August 1977](https://web.archive.org/web/20230728001717/http://simson.net/ref/1977/Gardner_RSA.pdf) issue of Scientific American: + +![Len, Adi, Ron at CRYPTO '82, and the now-famous article by Martin Gardner](img/overview/rsa-in-scientific-american.jpg) +**Len, Adi, Ron at CRYPTO '82, and [the now-famous article](https://web.archive.org/web/20230728001717/http://simson.net/ref/1977/Gardner_RSA.pdf) by Martin Gardner published in Scientific American.** + +In the article, Gardner included a RSA-129 cipher and offered $100 to the first person who solved it: + +![MIT's RSA Challenge](img/overview/rsa-challenge.jpg) +**MIT's RSA challenge.** + +In 1994, a group of computer scientists and volunteers [cracked the cipher](https://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage) and donated the money to the [Free Software Foundation.](https://www.fsf.org/) This effort highlighted a crucial point: perfect security in cryptography is an illusion. Encryption methods, like RSA, are constantly evolving, especially in anticipation of [quantum computers.](/wiki/Cryptography/post-quantum-cryptography.md) + +Nevertheless, modern RSA encryption (1024 to 4096 bits) created a secure pathway on the information superhighway, enabling banks and credit card companies to protect financial transactions. This fostered trust and facilitated the growth of e-commerce and online banking. + +![Inventors of modern cryptography](img/overview/inventors-of-modern-cryptography.jpg) +**Inventors of modern cryptography: Adi Shamir, Ron Rivest, Len Adleman, Ralph Merkle, Martin Hellman, and Whit Diffie at Crypto 2000 [(courtesy of Eli B.)](https://www.ralphmerkle.com/merkleDir/KobayashiAward.html)** + +In 1997, the British government declassified similar [research](https://cryptocellar.org/cesg/possnse.pdf) from 1970. + +## Free as in freedom + +Amidst a blizzard of advancing hardware and operating systems in the 1950s through 60s, early software was often primitive and required modification and software source code was no secret; in fact sharing source code was the norm. This fostered a hobbyist ["hacking culture"](https://en.wikipedia.org/wiki/Hacker_culture) that promoted exploration and exchange of knowledge. Anyone could inspect, modify, and provide feedback to the source code. Computer magazines would even feature printed [type-in programs](https://en.wikipedia.org/wiki/Type-in_program), that encouraged users to write software by hand: + +![Type-in program from compute magazine](img/overview/type-in-program.jpg) +**A type-in program to backup data, Compute! magazine [Source: commodore.ca.](https://www.commodore.ca/gallery/magazines/compute/Compute-004.pdf)** + +As software sizes grew and the cost of storage declined, software began to be distributed on tapes, often bundled with computer hardware by manufacturers like IBM. This practice came to a halt due to the 1969 [US vs. IBM antitrust lawsuit](https://www.justice.gov/atr/case-document/united-states-memorandum-1969-case), which argued that users were compelled to purchase hardware to use the bundled software. Although the lawsuit was later dropped, it backfired – companies seized the opportunity to start charging separately for software. Software became a commodity. + +Unix was another casualty of this trend. Initially distributed at no cost to government and academic researchers, by the early 1980s, AT&T ceased free distribution and started charging for system patches as Unix became more widespread. Due to the challenges of switching to alternative architectures, many researchers opted to pay for commercial licenses. + +To boost revenues, a general trend emerged where companies ceased distributing source code. Some companies went out of their way to prevent software distribution. In an infamous [open letter](https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists), [Bill Gates](https://en.wikipedia.org/wiki/Bill_Gates) asked hobbyists to stop sharing BASIC source code: + +> "Why is this? As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?"\ +> — Bill Gates, [An Open Letter to Hobbyists.](https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists) + +Amidst the growing debate over software ownership, [Richard Stallman](https://en.wikipedia.org/wiki/Richard_Stallman), a research assistant at MIT's AI laboratory, found himself in a personal battle. He was frustrated by his inability to modify the source code of his newly installed Xerox printers. He believed such restriction to be "a crime against humanity:" + +> "If you cook, you probably exchange recipes and share them with your friends, which they are free to change as they wish. Imagine a world, where you can't change your recipe because somebody went out of their way to set it up so that its impossible to change. And if you try to share the recipe with your friends, they would call you a **pirate** and put you in prison."\ +> — Richard stallman, in a [documentary](https://www.youtube.com/watch?v=XMm0HsmOTFI) + +In a 1983 [email](https://groups.google.com/g/net.unix-wizards/c/8twfRPM79u0), he declared his ambition to work on a free alternative to Unix called [GNU:](https://www.gnu.org/) + +![GNU announcement](img/overview/gnu-announcement.jpg) +**Richard Stallman, and his [email announcement](https://groups.google.com/g/net.unix-wizards/c/8twfRPM79u0) of the GNU project.** + +GNU is an in-your-face take on Unix and [recursively](https://en.wikipedia.org/wiki/Recursion) stands for “GNU's Not Unix". He decided to make the operating system compatible with Unix because the overall design was already proven and portable, and compatibility would make it easy for Unix users to switch from Unix to GNU. + +As Richard explains, free software goes beyond just the cost aspect: + +> "Free software", I should explain, refers to freedom, not price. It's unfortunate that the word "free", in english, is ambiguous - it has a +> number of different meanings. One of them means "zero price", but another meaning is "freedom". +> So think of "free speech", not "free beer". + +> 🎦 WATCH: [Richard Stallman talks about Free Software and it's impact on the society.](https://www.youtube.com/watch?v=Ag1AKIl_2GM) + +GNU started in January 1984. As part of this work, Richard wrote the [GNU General Public License](https://en.wikipedia.org/wiki/GNU_General_Public_License) (GPL). By 1990, GNU had either found or written all the major components for the operating system except one — the kernel. + +Coincidentally, [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds), a computer science student, was developing a kernel called Linux: + +![Linux announcement](img/overview/linux-announcement.jpg) +**Linus Torvalds, and his [email announcement](https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/SwRavCzVE7gJ) of Linux.** + +The first responses arrived within hours, several hundred joined the development over the course of next year. Linux was released under the GPL license, which completed GNU/Linux operating system. + +During this course, Linux practically laid the blueprint for software development based on social consensus: + +> "Very early in 1992, suddenly, I didn't know everybody anymore. It was no longer me and couple of friends. It was me and hundreds of people. That was a big step."\ +> — Linus Torvalds + +These diverse range of contributors, from individual enthusiasts to major corporations, collaborated to improve the kernel, fix bugs, and implement new features. It practically laid the blue print for what would later shape the open-source software movement. + +The open-source movement diverges from the free software movement, focusing more on the practical benefits of accessible source code. This approach offered a balance between community-driven innovation and commercial viability which led to widespread business adoption. Free and open-source software (FOSS) is an inclusive umbrella term for free software and open-source software. + +The GNU/Linux stands as a testament to the idea that software should empower, not restrict, its users. + +> 🎦 WATCH: [Revolution OS: A documentary about GNU/Linux.](https://www.youtube.com/watch?v=k0RYQVkQmWU) + +## Cypherpunks write code + +Since the end of World War II, governments a enjoyed stranglehold on advancements in cryptography, and guarded it accordingly. In the US, +encryption technology was controlled under the [Munitions List](https://en.wikipedia.org/wiki/United_States_Munitions_List). This meant that the [National Security Agency](https://en.wikipedia.org/wiki/National_Security_Agency) had a keen interest in cryptographic advancements. + +When the NSA received a copy the RSA paper from MIT, they attempted to classify the research but eventually allowed publication: + +![NSA cryptology debate](img/overview/nsa-cryptology-debate.jpg) +**NSA's response from a [2009 request under the Freedom of Information Act.](https://cryptome.org/2021/04/Joseph-Meyer-IEEE-1977.pdf)** + +NSA's approach opened itself up for considerable public criticism when a personal letter from Joseph Mayer, an NSA employee, written to IEEE noting cryptology publications required government approval was published. + +This marked the genesis of [Crypto Wars](https://en.wikipedia.org/wiki/Crypto_Wars) between the government and cryptography advocates. + +![NSA cryptology debate](img/overview/nsa-crypto-wars.jpg) +**A Science magazine [publication](https://www.science.org/doi/10.1126/science.197.4311.1345) about the cryptology debate.** + +The government's attempts to undermine cryptography were viewed as a means of surveilling public communications. + +![NSA cryptology debate](img/overview/wire-tap-surveillance.jpg) +**A Science magazine [publication](https://www.science.org/doi/10.1126/science.199.4330.750) about wire tapping, and a related Banksy street art in England.** + +Research on cryptography as a means to secure communication continued to evolve through the 1980s. + +In 1985, cryptographer [David Chaum](https://en.wikipedia.org/wiki/David_Chaum) published his breakthrough paper [“Security without Identification: Transaction Systems to Make Big Brother Obsolete,”](https://dl.acm.org/doi/pdf/10.1145/4372.4373) in which he described schemes for transactions that provide security and privacy. He also presented the radical idea of “a digital pseudonym” for individuals using cryptography. + +![David Chaum](img/overview/david-chaum.jpg) +**David Chaum, and his paper.** + +Crypto adoption for the general public was propelled by [Pretty Good Privacy](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) (PGP), an an encryption program developed by Phil Zimmermann in 1991. PGP allowed individuals to secure their communications and data with strong encryption. + +The Crypto Wars continued in 1993 when Zimmermann became the subject of a criminal investigation by the US Customs Service for allegedly violating export restrictions on cryptographic software. + +In an iconic move, he published the entire source code of PGP in a [hardback book](https://philzimmermann.com/EN/essays/BookPreface.html) arguing that the export of books is protected by the [First Amendment](https://en.wikipedia.org/wiki/First_Amendment_to_the_United_States_Constitution). These books were exported from the USA in accordance with US Export Regulations, and the pages were then scanned and OCR-ed to make the source available in electronic form. In a show of support, some activists printed source code on t-shirts. + +The case was dropped in 1996. + +> "I used to feel like I was a flea on the back of a T-Rex. Now I feel I might be a small yapping poodle on the back of a T-Rex."\ +> — Phil Zimmermann + +![Phil Zimmermann ](img/overview/phil-zimmermann.jpg) +**Phil Zimmermann, a t-shirt sporting the RSA source code, and a European volunteer scanning the PGP book; more than [70 people from all over Europe worked for over 1000 hours to make the PGP release possible outside US.](https://www.pgpi.didisoft.com/pgpi/project/scanning/)** + +In early 1992, the same week was PGP 2.0 released, three Bay Area engineers— [Eric Hughes](), [Timothy C. May](https://en.wikipedia.org/wiki/Timothy_C._May), and [John Gilmore]() — got together to start a mailing list named [Cypherpunk](https://mailing-list-archive.cryptoanarchy.wiki/) (cipher + [cyberpunk](https://en.wikipedia.org/wiki/Cyberpunk)). + +Cypherpunk evolved into a defining movement, with over [700 activists and rebels, including Zimmerman](https://mailing-list-archive.cryptoanarchy.wiki/authors/notable/) ready to fight back with code: + +> "Cypherpunks write code. We know that someone has to write software to defend privacy, and we're going to write it. +> [...] +> Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn +> about it, to teach it, to implement it, and to make more of it. Cypherpunks know that +> cryptographic protocols make social structures. Cypherpunks know how to attack a +> system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems."\ +> — Eric Hughes + +![Phil Zimmermann ](img/overview/cypherpunks-write-code.jpg) +**Tim, Eric, and John (top). Eric's cypherpunk [email](https://mailing-list-archive.cryptoanarchy.wiki/archive/1992/09/fdf9c19e77ec3f1a9bbc6bc19266d565b89d19dbd0ad369f5a2e800af3fc9558/) (bottom). [The Cypherpunk's Manifesto](https://www.activism.net/cypherpunk/manifesto.html) (right).** + +During a 1994 conference, Tim [described](https://web.archive.org/web/20240415133242/http://www.kreps.org/hackers/overheads/11cyphernervs.pdf) Cypherpunks' core beliefs: + +> There is nothing official (not much is), but there is an emergent, coherent set of +> beliefs which most list members seem to hold: +> +> - that the government should not be able to snoop into our affairs +> - that protection of conversations and exchanges is a basic right +> - that these rights may need to be secured through _technology_ rather than +> through law +> - that the power of technology often creates new political realities (hence the list +> mantra: "Cypherpunks write code") + +In his 1988 ["Crypto Anarchist Manifesto,"](https://groups.csail.mit.edu/mac/classes/6.805/articles/crypto/cypherpunks/may-crypto-manifesto.html) Tim introduced the political philosophy of "Crypto anarchism," which opposes all forms of authority and recognizes no laws except those described by cryptography and enforced by code. + +![Crypto Anarchist Manifesto](img/overview/crypto-anarchy.jpg) +**Anarchism, and Tim May's Crypto Anarchist Manifesto.** + +The manifesto envisioned anonymous digital transactions as a cornerstone of individual liberty. + +The missing piece: **A cryptonative-native [digital currency.](https://en.wikipedia.org/wiki/Digital_currency)** + +> 🎦 WATCH: [Tim reflects on 30 years of crypto anarchy.](https://www.youtube.com/watch?v=TdmpAy1hI8g) + +## Search for the missing piece + +Throughout the '90s cryptopunks made several attempts at creating a digital currency. + +In 1990, David Chaum introduced [DigiCash](https://en.wikipedia.org/wiki/DigiCash) providing the first glimpse of an anonymous digital economy. However, it relied on existing financial infrastructure and was largely centralized. Ultimately, DigiCash filed for bankruptcy in 1998. + +![DigiCash Homepage](img/overview/digicash.jpg) +**DigiCash Homepage.** + +E-gold emerged later in 1996 backed by physical gold held in reserve. At its peak, e-gold had [3.5 million registered accounts](https://web.archive.org/web/20061109161419/http://www.e-gold.com/stats.html) and facilitated transactions worth billions of dollars annually. However, in 2009, transfers were suspended due to legal issues. + +Later schemes focused on moving away from collateral such as gold instead scarcity was digitally controlled. In 1998, [Wei Dai](https://en.wikipedia.org/wiki/Wei_Dai) proposed [B-money](https://web.archive.org/web/20220303184029/http://www.weidai.com/bmoney.txt) powered by a cryptographic function to create money. In 2005, [Nick Szabo](https://en.wikipedia.org/wiki/Nick_Szabo) designed [BitGold](https://web.archive.org/web/20240329075756/https://unenumerated.blogspot.com/2005/12/bit-gold.html) but was never implemented. Neither successfully garnered mainstream adoption but their designs influenced what would eventually make digital currency a reality - Bitcoin. + +![Wei Dai and Nick Szabo](img/overview/wei-dai-nick-szabo.jpg) +**Wei Dai and Nick Szabo.** + +## Bitcoin + +The 2008 financial crisis revived interest in digital currency experiments and especially brought BitGold back into the conversation. + +A solution to the open problem of how to achieving consensus without a leader was introduced in a 2008 paper titled ["Bitcoin: A Peer-to-Peer Electronic Cash System"](https://bitcoin.org/bitcoin.pdf) by the pseudonymous author [Satoshi Nakamoto](https://en.wikipedia.org/wiki/Satoshi_Nakamoto). Bitcoin established itself as a distributed ledger system where data is cryptographically linked in chronological blocks. It also became the first decentralized digital currency, operating without underlying collateral, and eliminating the need for trusted third-party intermediaries like banks. + +![A statue dedicated to Satoshi, and Bitcoin announcement post.](img/overview/satoshi-and-bitcoin.jpg) +**A statue dedicated to Satoshi, and Bitcoin announcement post.** + +Bitcoin is also the largest socio-economic experiment the world has ever seen: + +> "When Satoshi Nakamoto first set the Bitcoin blockchain into motion in January 2009, he was +> simultaneously introducing two radical and untested concepts. The first is the 'bitcoin', a decentralized +> peer-to-peer online currency that maintains a value without any backing, intrinsic value or central issuer. So +> far, the 'bitcoin' as a currency unit has taken up the bulk of the public attention. +> +> However, there is also another, equally important, part to Satoshi's grand experiment: the concept of a proof of +> work-based blockchain to allow for public agreement on the order of transactions."\ +> — Vitalik Buterin + +[Several](https://web.archive.org/web/20230404234458/https://www.etoro.com/wp-content/uploads/2022/03/Colored-Coins-white-paper-Digital-Assets.pdf) [attempts](https://en.wikipedia.org/wiki/Namecoin) were made to build applications on top of Bitcoin's network to leverage the newly created digital currency. However, for this purpose Bitcoin's network proved primitive, and the applications were built using complex and not very scalable workarounds. + +Ethereum emerged as a solution to address these challenges. + +## The Ethereum world computer + +In 2012, [Vitalik Buterin](https://en.wikipedia.org/wiki/Vitalik_Buterin) and Mihai Alisie founded [Bitcoin Magazine](https://en.wikipedia.org/wiki/Bitcoin_Magazine) - the first serious publication dedicated to digital currencies. Vitalik soon discovered the limitations of Bitcoin and [proposed a platform](https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html) that would support generalized financial applications. + +In 2014, with the help of [Gavin Wood](https://en.wikipedia.org/wiki/Gavin_Wood), the [design of Ethereum was formalized](https://ethereum.github.io/yellowpaper/paper.pdf). + +![Vitalik, Jeff, and Gavin working on Ethereum.](img/overview/ethereum-launch.jpg) +**Vitalik, Jeff, and Gavin working on Ethereum.** + +On July 30, 2015, Ethereum [went live](https://etherscan.io/block/1) as a platform aimed at building tools for a self-sovereign economy using digital currency. + +As of the time of writing, Ethereum has a market capitalization of **$400 billion.** + +> 📄 READ: [Vitalik's post about the origin of Ethereum.](https://vitalik.eth.limo/general/2017/09/14/prehistory.html) + +> 🎦 WATCH: [Mario Havel talks about the Ethereum philosophy.](https://streameth.org/ethereum_protocol_fellowship/watch?session=65d77e4f437a5c85775fef9d) + +> 📄 READ: [Evolution of Ethereum.](/wiki/protocol/history.md) + +## Resources + +- 📄 Computer History Museum, ["The history of Computer Networking"](https://www.computerhistory.org/timeline/networking-the-web/) +- 📄 Wikipedia, ["ARPANET"](https://en.wikipedia.org/wiki/ARPANET) +- 📘 Brian K., ["Unix: A History and a Memoir"](https://www.amazon.com/dp/1695978552) +- 📄 CryptoCouple, ["A History of The World’s Most Famous Cryptographic Couple"](https://cryptocouple.com/) +- 📄 Steven E., ["The Day Cryptography Changed Forever"](https://medium.com/swlh/the-day-cryptography-changed-forever-1b6aefe8bda7) +- 📄 GNU, ["Overview of the GNU System"](https://www.gnu.org/gnu/gnu-history.en.html) +- 📄 Steven V., ["A look back at 40 Years of GNU and the Free Software Foundation"](https://www.zdnet.com/article/40-years-of-gnu-and-the-free-software-foundation/) +- 📄 David C., [“Security without Identification: Transaction Systems to Make Big Brother Obsolete”](https://dl.acm.org/doi/pdf/10.1145/4372.4373) +- 📄 Steven L., ["Wired: Crypto Rebels"](https://web.archive.org/web/20160310165713/https://archive.wired.com/wired/archive/1.02/crypto.rebels_pr.html) +- 📄 Arvind N., ["What Happened to the Crypto Dream?"](https://www.cs.princeton.edu/~arvindn/publications/crypto-dream-part1.pdf) +- 📄 Satoshi N., ["Bitcoin: A Peer-to-Peer Electronic Cash System"](https://bitcoin.org/bitcoin.pdf) +- 📄 Harry K. et al, ["An empirical study of Namecoin and lessons for decentralized namespace design"](https://www.cs.princeton.edu/~arvindn/publications/namespaces.pdf) +- 📄 Nick S,, ["Formalizing and Securing Relationships on Public Networks"](https://web.archive.org/web/20040228033758/http://www.firstmonday.dk/ISSUES/issue2_9/szabo/index.html) +- 📄 Nick S., ["The Idea of Smart Contracts"](https://web.archive.org/web/20040222163648/https://szabo.best.vwh.net/idea.html) +- 📄 Vitalik B., ["Ethereum Whitepaper"](https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) +- 📄 Vitalik B., ["Ethereum at Bitcoin Miami 2014"](https://www.youtube.com/watch?v=l9dpjN3Mwps) +- 🎥 Gavin Wood, ["Ethereum for Dummies"](https://www.youtube.com/watch?v=U_LK0t_qaPo) diff --git a/docs/wiki/research/roadmap.md b/docs/wiki/research/roadmap.md index 0e24362a..2777c10c 100644 --- a/docs/wiki/research/roadmap.md +++ b/docs/wiki/research/roadmap.md @@ -35,27 +35,27 @@ Upgrades relating to the switch from proof-of-work to proof-of-stake. The Merge **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. Under [full rollup scaling](#the-surge), with real-time SNARK proofs implemented, single slot finality would also mean faster bridging for L2s ), (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 +| 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. Under [full rollup scaling](#the-surge), with real-time SNARK proofs implemented, single slot finality would also mean faster bridging for L2s ), (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[^3]
(ii) 8192 signatures post-SSF[^4]
(iii) simple SSF protocol[^5] | +| 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[^6] | +| 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[^7]
(ii) EIP-7251[^8]
(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[^9]
(ii) STARK-based [^10] systems | +### The Surge Upgrades related to scalability by Roll-ups and Data Sharding. **IMPLEMENTED** | Upgrade | Track | Topic | Description | Effect | State of the art | | :----------------- | :---: | :------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------: | :------------------------- | -| Proto-danksharding | - | Basic rollup scaling | 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] | +| Proto-danksharding | - | Basic rollup scaling | 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[^11] | **TODO** | Upgrade | Track | Topic | Description | Expected effect | State of the art | | :---------------------------------------------- | :---: | :-------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Danksharding | - | Full rollup scaling | 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) | - | Full rollup scaling | 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 | - | Basic & Full rollup scaling | (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) [ET](/wiki/research/PBS/ET.md),
[Based Sequencing with Preconfirmations](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) | +| Data Availability Sampling (DAS) | - | Full rollup scaling | 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[^12] | +| Removing Rollup Training Wheels | - | Basic & Full rollup scaling | (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[^13]
Optimism Cannon[^14]
(ii) ZK-EVMs [^15] [^16] [^17]
(iii) [ET](/wiki/research/PBS/ET.md),
[Based Sequencing with Preconfirmations](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) | | 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 +### The Scourge Upgrades related to censorship resistance, decentralization and mitigating protocol risks from MEV and liquid staking/pooling. **IMPLEMENTED** @@ -67,81 +67,102 @@ Upgrades related to censorship resistance, decentralization and mitigating proto | 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)[^19]
| -| MEV - Burn | MEV-Track | Endgame Block Production Pipeline | A simple enshrined PBS add-on to smooth and redistribute MEV spikes | The extracted ETH would be burned, therefore benefiting all ETH holders, rather than only those running validators. | [in research](/wiki/research/PBS/ePBS.md#mev-burn)[^20] | -| ET | MEV-Track | Endgame Block Production Pipeline | A permissionless market allowing buyers to purchase the right to propose execution payloads. | Attester - Proposer separation: the beacon proposer is unconcerned with execution proposer. Execution proposer is selected from the permissionless execution tickets market and has the option to transfer the execution building right to a third party.
Since ET market will be a protocol gadget, the protocol will have introspection over who comes to market and how much they are willing to pay | [ET](/wiki/research/PBS/ET.md),
APS-Burn[^21] | -| IL | MEV-Track | Endgame Block Production Pipeline | Inclusion lists - a way for the most decentralized set of Ethereum to fight censorship by inputting their preferences onto the construction of the chain | Prevents block builders from censoring blocks. Allow Proposers to retain some authority by providing a mechanism by which transactions can be forcibly included, avoiding the current situation, when without any forced transaction inclusion mechanism, the proposer is faced with the choice of either having to say no, on the transactions that get included, or they build the block locally (having the final say on transactions) and sacrifice some MEV rewards | [in research](/wiki/research/inclusion-lists.md)[^22]
Multiplicity gadgets [^23]
COMIS [^24] | -| Distributed Block Building | MEV-Track | Endgame Block Production Pipeline | Decentralize the block building process, by distributing it | Decentralize different parts of the Builder:
(i) the algorithms for choosing transactions (the block building transaction ordering)
(ii) resources for block construction, especially under full Danksharding (split-up big blocks)
(iii) add extra builder services (e.g.Preconfirmations) | in research
[Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md),
SUAVE[^25] | -| Application Layer MEV Minimization | MEV-Track | - | App layer effort to minimize harmful MEV | The minimization techniques target:
(i) frontrunning, and
(ii) sandwich attacks | Examples[^26] | -| Preconfirmations | MEV-Track | - | Users preconfirmations on transaction execution, for a competitive user experience in Ethereum interactions | Block builders could publicly agree to include transactions with a priority fee over a certain amount, and send users a receipt indicating their intent to include the transaction in a specific block | [in research](/wiki/research/Preconfirmations/Preconfirmations.md)[^27] | - -### the Verge +| 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)[^18]
| +| MEV - Burn | MEV-Track | Endgame Block Production Pipeline | A simple enshrined PBS add-on to smooth and redistribute MEV spikes | The extracted ETH would be burned, therefore benefiting all ETH holders, rather than only those running validators. | [in research](/wiki/research/PBS/ePBS.md#mev-burn)[^19] | +| ET | MEV-Track | Endgame Block Production Pipeline | A permissionless market allowing buyers to purchase the right to propose execution payloads. | Attester - Proposer separation: the beacon proposer is unconcerned with execution proposer. Execution proposer is selected from the permissionless execution tickets market and has the option to transfer the execution building right to a third party.
Since ET market will be a protocol gadget, the protocol will have introspection over who comes to market and how much they are willing to pay | [ET](/wiki/research/PBS/ET.md),
APS-Burn[^20] | +| IL | MEV-Track | Endgame Block Production Pipeline | Inclusion lists - a way for the most decentralized set of Ethereum to fight censorship by inputting their preferences onto the construction of the chain | Prevents block builders from censoring blocks. Allow Proposers to retain some authority by providing a mechanism by which transactions can be forcibly included, avoiding the current situation, when without any forced transaction inclusion mechanism, the proposer is faced with the choice of either having to say no, on the transactions that get included, or they build the block locally (having the final say on transactions) and sacrifice some MEV rewards | [in research](/wiki/research/inclusion-lists.md)[^21]
Multiplicity gadgets [^22]
COMIS [^23] | +| Distributed Block Building | MEV-Track | Endgame Block Production Pipeline | Decentralize the block building process, by distributing it | Decentralize different parts of the Builder:
(i) the algorithms for choosing transactions (the block building transaction ordering)
(ii) resources for block construction, especially under full Danksharding (split-up big blocks)
(iii) add extra builder services (e.g.Preconfirmations) | in research
[Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md),
SUAVE[^24] | +| Application Layer MEV Minimization | MEV-Track | - | App layer effort to minimize harmful MEV | The minimization techniques target:
(i) frontrunning, and
(ii) sandwich attacks | Examples[^25] | +| Preconfirmations | MEV-Track | - | Users preconfirmations on transaction execution, for a competitive user experience in Ethereum interactions | Block builders could publicly agree to include transactions with a priority fee over a certain amount, and send users a receipt indicating their intent to include the transaction in a specific block | [in research](/wiki/research/Preconfirmations/Preconfirmations.md)[^26] | +| Increase MAX_EFFECTIVE_BALANCE | Staking Economics | Raising Validator Cap | Increase the max balance for Ethereum validators from 32 ETH to reduce overhead for large stakers | Consolidates validators, reduces network load, simplifies operations for large stakers | [in research](/wiki/research/eODS.md)[^27], confirmed for Pectra upgrade | +| Cheaper Nodes | Staking Economics | Improve Node Operator Usability| Make nodes cheaper and easier to operate using verkle trees and SNARKs | Lower SSD requirements, faster sync times, easier node operation | Research/Proposal: [in eps node workshop](/docs/eps/nodes_workshop.md)[^28] | +| Capping Validator Set | Staking Economics | Explore Total Stake Capping | Cap the total amount of stake to manage communication overhead between validators | Prevents excessive validator participation, maintains network efficiency | Research/Proposals: [in research](/wiki/research/eODS.md)[^29] | +|Combat LST Centralization | Staking Economics | Explore Solutions to Liquid Staking Centralization | Solutions to reduce centralization in the Liquid Staking Token (LST) market | Prevents large LST providers from gaining too much control over the network | Research/Proposals: [^30], [^31], [^32], [^33],[^34] | + + + +### The Verge Upgrades related to verifying blocks more easily | Upgrade | Track | Topic | Description | Expected effect | State of the art | | :------ | :---: | :---: | :---------: | :-------------: | :--------------- | | | | | | | | -### the Purge +### The Purge Upgrades related to reducing the computational costs of running nodes and simplifying the protocol -### the Splurge +### 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) +[^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) +[^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) +[^3] : [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) -[^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) +[^4] : [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) -[^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) +[^5] : [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) -[^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) +[^6] : [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) -[^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) +[^7] : [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) -[^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) +[^8] : [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) -[^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) +[^9] : [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) -[^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) +[^10] : [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) -[^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) +[^11] : [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) -[^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) +[^12] : [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105) -[^13]: EIP-7594: PeerDAS https://github.com/ethereum/EIPs/pull/8105 +[^13] : [BoLd: dispute resolution protocol](https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf) -[^14]: BoLd: dispute resolution protocol https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf +[^14] : [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/) -[^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/ +[^15] : [Parallel Zero-knowledge Virtual Machine](https://eprint.iacr.org/2024/387), [[archived]](https://web.archive.org/web/20240415180222/https://eprint.iacr.org/2024/387) -[^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) +[^16] : [What is zkEVM](https://www.alchemy.com/overviews/zkevm), [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm) -[^17]: What is zkEVM https://www.alchemy.com/overviews/zkevm, [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm) +[^17] : [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) -[^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) +[^18] : [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) -[^19]: 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) +[^19] : [MEV burn—a simple design](https://ethresear.ch/t/mev-burn-a-simple-design/15590), [[archived]](https://ethresear.ch/t/mev-burn-a-simple-design/15590) -[^20]: MEV burn—a simple design https://ethresear.ch/t/mev-burn-a-simple-design/15590, [[archived]](https://ethresear.ch/t/mev-burn-a-simple-design/15590) +[^20] : [APS-Burn](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ#heading-aps-burn) -[^21]: APS-Burn https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ#heading-aps-burn +[^21] : [Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547), [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547) -[^22]: Inclusion lists https://eips.ethereum.org/EIPS/eip-7547, [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547) +[^22] : [ROP-9: Multiplicity gadgets](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b) -[^23]: ROP-9: Multiplicity gadgets https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b +[^23] : [Committee-enforced inclusion sets (COMIS)](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), [[archived]](https://web.archive.org/web/20240310000045/https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835) -[^24]: Committee-enforced inclusion sets (COMIS) https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835, [[archived]](https://web.archive.org/web/20240310000045/https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835) +[^24] : [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave), [[archived]](https://writings.flashbots.net/the-future-of-mev-is-suave) -[^25]: SUAVE https://writings.flashbots.net/the-future-of-mev-is-suave, [[archived]](https://writings.flashbots.net/the-future-of-mev-is-suave) +[^25] : [Examples of app layer MEV minimization](https://herccc.substack.com/i/142947825/examples-of-the-defensive-side-of-mev) -[^26]: Examples of app layer MEV minimization https://herccc.substack.com/i/142947825/examples-of-the-defensive-side-of-mev +[^26] : [Based preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353), [[archived]](https://ethresear.ch/t/based-preconfirmations/17353) -[^27]: Based preconfirmations https://ethresear.ch/t/based-preconfirmations/17353, [[archived]](https://ethresear.ch/t/based-preconfirmations/17353) +[^27] : [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251) + +[^28] : [Spin Up Your Own Ethereum Node - Ethereum.org](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/) + +[^29] : [Paths to SSF](https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928) + +[^30] : [Enshrining Liquid Staking/Decentralized Liquid Staking](https://notes.ethereum.org/@vbuterin/H1_5auGQd) + +[^31] : [Enshrined LST from Arixon](https://ethresear.ch/t/enshrined-lst-allocating-stake-to-node-operators/11053) + +[^32] : [Unbundling staking: towards rainbow staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/11054) + +[^33] : [Liquid Staking Maximalism design by Dankrad](https://ethresear.ch/t/liquid-staking-maximalism/11050) + +[^34] : [Two-tiered staking from Mike Neuder](https://ethresear.ch/t/two-tiered-staking/11049) [ethereum/EIPs github repository](https://github.com/ethereum/EIPs/tree/master#ethereum-improvement-proposals-eips) diff --git a/notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md b/notes/wiki_contributors_meeting/2024-04-18-meeting-1.md similarity index 96% rename from notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md rename to notes/wiki_contributors_meeting/2024-04-18-meeting-1.md index 6dcec092..af8c2726 100644 --- a/notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md +++ b/notes/wiki_contributors_meeting/2024-04-18-meeting-1.md @@ -71,4 +71,4 @@ ## Meta -For every meeting, create a new file inside `/notes/wiki_contributors_meeting` using the convention `YYYY-MM-DD_description.md`; eg.`2024-04-01_kickoff_call.md`. This helps preserve chronological order when sorting files. +For every meeting, create a new file inside `/notes/wiki_contributors_meeting` using the convention `YYYY-MM-DD-meeting-no.md`; eg.`2024-04-01-meeting-1.md`. This helps preserve chronological order when sorting files. diff --git a/notes/wiki_contributors_meeting/2024-05-02_release_plan.md b/notes/wiki_contributors_meeting/2024-05-02-meeting-2.md similarity index 100% rename from notes/wiki_contributors_meeting/2024-05-02_release_plan.md rename to notes/wiki_contributors_meeting/2024-05-02-meeting-2.md diff --git a/notes/wiki_contributors_meeting/2024-05-16-meeting_3.md b/notes/wiki_contributors_meeting/2024-05-16-meeting-3.md similarity index 100% rename from notes/wiki_contributors_meeting/2024-05-16-meeting_3.md rename to notes/wiki_contributors_meeting/2024-05-16-meeting-3.md diff --git a/notes/wiki_contributors_meeting/2024-06-20-meeting-4.md b/notes/wiki_contributors_meeting/2024-06-20-meeting-4.md new file mode 100644 index 00000000..9794565a --- /dev/null +++ b/notes/wiki_contributors_meeting/2024-06-20-meeting-4.md @@ -0,0 +1,73 @@ +### **Meeting Minutes:** + +**Attendance** +Mario +Rory +DanGoron +Sid +Hopinheimer +Kira +Glory Agatevure (gconnect) +Zarathustra + +Mario - First [milestone](https://github.com/orgs/eth-protocol-fellows/projects/1/views/2?filterQuery=), idea was to finish before last week. We are almost there. I edited project status today again to reflect latest changes. Idea was to finish before cohort. You can see Backlog, In Progress and Done. Great job on Done page! And kudos to Kira for Consensus Layer Wiki page. Rahul's work on protocol review is in progress...Raa to help? Otherwise Rahul will take over. Mario asked Rory about Testing backlog. Been tied up with EPF project/research but will continue adding to Testing page this weekend. My EPF project revolves around Testing so this makes it easier. + +Mario - Do we like the Kanban board, this style and milestone tracking progress? + +Kira - I think this is great and I like reviewing so we have a better view. DanGoron agrees also. + +Mario - Gives me better overview of what issues, PRs are coupled and I tried to keep it the same. Keep PR and Issue coupled. We can change the dates if we want to be precise. + +DanGoron - Regarding dates, we should keep them loosely, we all will contribute but it’s finding the time is more difficult now. Keeping timeline loose seems like the best way. + +Mario - EPF people coming in, let me look into current PRs as well. Some PRs open from other people who are not here. Fuzzing page….Fuzzing could be integrated into Testing? (Rory to take this on). Dan you opened up an issue you wanted to bring up on the call? + +DanGoron - Wanted to find time to finish roadmap. Last three "-urges" that need to be completed and thought I hoped other Fellows would want to contribute, used same structure to fill in. Hopefully I can attract Fellows to join and ask for review, otherwise if I have time I will finish myself. + +Mario - On one hand, I think it’s great if Fellows come and contribute. This content is mostly for them, but also they are focused on working, learning. I was hoping first two weeks people contributing, or EPF focused on fellowship projects, they shouldn’t work on wiki as it may be viewed as less of a priority. First few weeks might be different to keep up with the pace, absolutely no worries if you are focusing on something else. + +DanGoron - I do it out of passion so it’s only matter of finding the time. Very nice project Mario that you started and that we contribute to! + +Mario - I’m pushing for people to use it and somehow people also ignore it. + +Dan - Referring to the wiki in our weekly updates could be good practice. Use it and tell others to use it. + +Mario - My observation, I saw in some updates people looking into wiki articles. Then I see questions from people that are answered on wiki. We were explicit about it, I sent people directly to the wiki. I’m not sure how people see it, let’s ask a poll in the next call or fellowship chat, "do you have any feedback for us?" + +DanGoron - There are Fellows that joined just recently and they do not, might not, spend a lot of time reading about what happened in EPF before they came in. + +Mario - Will post in Protocol chat for people to be aware of it and give us issue if there’s anything wrong with it. + +Sid - It was information overload in the first few weeks too. + +DanGoron - Definitely a learning curve there. I’ve also known what I want to work on since I joined the study group. The meeting with the first office hours made me realize we need to think more holistically. I try to assimilate as much as possible before diving in. V2 something we start advertising or v1? + +Mario - Have our own serenity? We can do this but I would keep this v2 thing for later, maybe next year’s study group. I don’t want to take too much resources but also the difference we can make in the content is not huge. There are gaps we have to fill but I would still have it v1.1. Not much difference to call it v2. I would like to have v2 but let’s see how it goes in the coming months. Let’s keep it like this. Gives me ptsd from serenity. :) + +Mario - When I merge the main to the wiki pages branch, I just name it after the week, the day it was done. 8 June version is just four comments behind. I was waiting for some updates but I can push it now if there is nothing merging soon. Should I call it something else or should i keep it as the date naming? Maybe we can call this 1.0. Going with semVer. Do we want to start with 1.0.0? Still going to add date just for reference, push and wiki pages now updated. You should see latest comment there. Make an archive and release it in the GitHub releases. But right now GitHub deployment is running. Just deployed! Also wait for Rahul’s review or if anyone else wants to post a review there. + +Kira is addressing comments on the CL PR today + +Somebody wanted to create table for CL clients based on diversity site. + +Zarathustra just joined! + +Mario addressing this new [issue](https://github.com/eth-protocol-fellows/protocol-studies/issues/295). Frontend is blocked by YouTube now. I wanted to avoid YouTube ads and now they are blocking it. If you want to create GitHub actions workflow. + +Zarathustra - I can do this (responding to his issue). + +Mario - Reminder not to prioritize EPS wiki work compared to EPF itself. Going to go into hotfix of 0.1.0. + +Mario - Anything I missed from agenda? + +Sid - [Mayowa](https://github.com/MayowaObisesan) messaged me about contributing to EL specs. Very little content in EL specs presentation we have so I brought him in. He might be doing that. His Discord is: blessed07 + +Mario - I could have shilled Contributor meeting. + +Glory Agatevure (gconnect) - Introduction. Newcomer! Where can I contribute? + +Mario - Read through the EPF wiki, as you look into it you see articles that are just stubs, any of these missing gaps, you can write your own page on it. Open a PR and contribute. Also existing pages might miss details so you can contribute to existing pages based on what you read there. Look into issues and look into wiki! + +Mario - Before we finish, for our next call, what do we think about schedule? In two weeks is EthCC, so maybe in three weeks from now? But could also do in person. + +Next contributor meeting will be 11 July! diff --git a/notes/wiki_contributors_meeting/2024-07-25-meeting-5.md b/notes/wiki_contributors_meeting/2024-07-25-meeting-5.md new file mode 100644 index 00000000..ee59be63 --- /dev/null +++ b/notes/wiki_contributors_meeting/2024-07-25-meeting-5.md @@ -0,0 +1,88 @@ +# Wiki Contributors Meeting #5 - Jul 25, 2024 (3 PM UTC) + +## Agenda + +- State of the wiki; items in progress since the last call +- Clarify Purpose and Intent of Source Code Mirror #297 +- EPF contributions + +## Participants + +- Caleb +- Dan +- Glory +- Hopinheimer +- Katya +- Kira +- Mayowa +- Mario +- Rahul +- Sid + +## Notes + +**Mario**: We released wiki [version 1.0.2](https://github.com/eth-protocol-fellows/protocol-studies/commit/ef0b7597261dde7706a2e5f5a34b53b74b530d0d) with the history page, DHT, and information about Grandine. Contributions have slowed down a bit, but that is expected because folks are busy with EPF. There are several pull requests pending. Let's start with Kira's pull request on the consensus layer. + +**Kira**: I have considered most feedback and think the PR is ready for review. + +**Rahul**: It looks good to me. + +**Mario**: I will review it once more and merge it. I think the spell check is broken. + +**Kira**: I fixed it in my PR. + +**Mario**: Great. I think the style guide can be a separate page. + +**Rahul**: Agreed. I will create a new page for it. + +**Dan**: I think the roadmap is still open, but it is a good first issue for new contributors. + +**Mario**: Agreed. We should get new contributors to work on it. + +**Dan**: Maybe we should let EPF fellows know that they could contribute their work to the wiki. + +**Mario**: Yep. I don’t think it’s too much overhead. + +**Katya**: Propose it in the office hours. The first call where it was mentioned had introductions, so it’s possible that folks missed the part about contributing to the wiki. + +**Mario**: Yeah, we need to reiterate the message. + +**Rahul**: At the very least, we could ask folks to create an issue about their project and dump resources, allowing other contributors to work on it. + +**Dan**: Reviewing pull requests is a bottleneck. How can we get more contributors? + +**Mario**: Anybody can review PRs, but I agree we need more reviewers. + +**Rahul**: Contributors need incentives. + +**Mario**: Yes, but we don’t want to promote low-quality contributions. We have aspiring new contributors—Katya and Mayowa. + +**Katya**: I would love to contribute about Kurtosis and Grafana. I have some cheat sheets that I can share, extracted from videos that really save time. + +**Mario**: We would love to have that. Feel free to issue and create a PR. It’s fully permissionless. It overlaps with DevOps, so maybe we should create a separate page. + +**Dan**: Tim recently published [EIP 7723](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7723.md) about activation on an EIP. + +**Mario**: We don’t have the EIP process documented. We should create one based on [Tim’s talk](https://www.youtube.com/watch?v=5L9UUCL7bzI). There is also a [great blog post](https://medium.com/ethereum-magicians/comprehensive-guide-on-writing-and-submitting-an-eip-9474163771f0) that discusses this, though it could be a little outdated. + +**Caleb**: I'm working on EPBs with Kira. I realize that most people don’t know how to start with EIPs. I would like to write an article on how to implement an EIP. + +**Mario**: I think that’s great and even more important than proposing an EIP itself. Please open an issue. + +**Hopinheimer**: Asking core devs for advice on getting started would also be valuable. I would like to gather some feedback and include that in the wiki. + +**Mario**: Yeah, we are doing AMAs as part of EPF office hours; we could include that as part of a wiki page. There is also a great [talk by Danny Ryan](https://streameth.org/devconnect/watch?session=65b8f8cfa5b2d09b88ec114b) that might be useful. + +**Dan**: On that note, we should collaborate with [Ethereum Cat Herders](https://www.ethereumcatherders.com/) and [Pooja](https://twitter.com/poojaranjan19). She is very active. + +**Mario**: Yes, we should have Pooja do an AMA. Also, feel free to suggest guests for upcoming AMAs. + +**Mario**: Glory, do you have any comments on your contribution? + +**Glory**: I will continue working on the assigned issue. + +**Mario**: Regarding mirroring, I could ask EF DevOps to add the wiki to their mirroring workflow. But we should also look into something like [Radicle](https://app.radicle.xyz/nodes/seed.radicle.xyz). + +**Dan**: I could help you with that. + +**Mario**: Sounds great. That’s all for now. Thanks, everyone. diff --git a/wordlist.txt b/wordlist.txt index 2da95abc..649dbaf9 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -16,6 +16,7 @@ aggregative Aleth allowfullscreen amidst +amongst Andreas Antonopoulos API @@ -24,6 +25,8 @@ APIs APS Arbitrum Aritra +Arixon +ARPANET ary ASE Ashish @@ -48,6 +51,7 @@ Barnabe Barnabé Barnabé's BDN +beaconblock Beiko Bertoni Besu @@ -171,12 +175,14 @@ decrementation decrementing DeFi Degatchi +dht DELEGATECALL delegator delegators deliverables Dencun deployer +descendent deserialization Deserialize deserialized @@ -197,6 +203,7 @@ disambiguated Discordo discv distro +DNS docsify dogecoin Domothy @@ -235,6 +242,7 @@ ELs emptyset Encodings Endian +enr env EOA EOAs @@ -263,6 +271,7 @@ ethone's ethresear ethresearch ethroadmap +ETHW EVM evmlab EVMONE @@ -273,6 +282,7 @@ exchangeTransitionConfigurationV Explainer Extractable extraData +fanout farcaster fastssz faytey @@ -324,6 +334,7 @@ Goldwasser Goomy Goron Gorondan +gossipsub Gottfried Gottlob gpg @@ -338,6 +349,7 @@ hackathon hackmd Hager halmos +hardfork HashedStorages Herc’s hevm @@ -379,6 +391,7 @@ interop invariants IOP IPC +ipfs IRTF ISA Jitsi @@ -387,6 +400,7 @@ JSON JUMPDEST JVM JWT +Kademlia Karapetsas Katex KEC @@ -408,6 +422,7 @@ Lamport's lceil ldots Lefteris +leftarrow leq leveldb lfloor @@ -433,12 +448,14 @@ LSP LST Lua LuaVM +Luca Lyubashevsky mainnet Mana Manas Mário mathbb +Maximalism mdbx MDBX MDS @@ -457,6 +474,7 @@ mevboost Michaël middleware minimalistic +misconfigure Mitigations mload MMPTs @@ -477,6 +495,8 @@ MVE mvepbs MVI Nagu +Nakamoto +Namecoin namespace namespaces Nand @@ -528,6 +548,7 @@ pepc's performence permissionless permissionlessness +pex PGA Pigovian Pilipovic @@ -537,6 +558,7 @@ pmod POC POS POSIX +postel's possibile Potuz's POV @@ -567,6 +589,7 @@ privateKey probabilistically programmability proto +proto's protobuf Protolambda prover @@ -577,6 +600,8 @@ Prysm Prysmatic PSE PSE's +pseudorandom +pseudorandomly ptc publically pubsub @@ -599,6 +624,8 @@ README reciept referrerpolicy remerkleable +reorganisation +reorganisations replayable repo responder @@ -613,7 +640,9 @@ Rikard RIPEMD Ritchie rK +RLMD RLP +RLPx roadmap rollup rollup's @@ -624,6 +653,7 @@ RPCs RSA RSA's runtime +Satoshi Satisfiability scalability scalable @@ -667,6 +697,7 @@ solvm SPHINCS Sproul src +ssd SSF SSLE SSTORE @@ -694,10 +725,13 @@ substate Substate subtrees Summa +Supermajority systemd +Szabo Takenobu Tani tbhl +TCP Teku testnet testnets @@ -738,8 +772,11 @@ unaggregated unbundle Unbundling underbrace +underflow +underflows Unformatted unguessable +unhandled unincentivized upstreamed utils @@ -753,6 +790,7 @@ validators Vanstone Varun VB's +VDF VDFs Vec verifications @@ -771,9 +809,11 @@ walkthrough WB webkit WebRTC +Whistleblower Whitepaper WIP -withdrawlsHash +withdrawable +withdrawalHash WSS Xatu xff @@ -782,10 +822,63 @@ XORed xy Yan Yellowpaper +Yoni Yoichi +Zanolini Zaverucha +Zhang +Zipfian zk zkEVMs ZKSNARK ZKSNARKs Zksync +Postel's +RLPx +TCP +Zipfian +Adi +Adleman +Alisie +Arvind +Banksy +Chaum +codebreakers +cryptology +cryptonative +Cypherpunk's +cryptosystems +Dai +DigiCash +GPL +Kahn +Merkle’s +Mihai +reusability +Rivest +Satoshi's +Shamir +surveilling +Taleb +Zimmermann +DHT +ENR +fanout +gossipsub +IPFS +kademlia +PEX +SSD +DHT +Katya +Rahul's +Kira's +Mayowa +Pooja +Radicle +Agatevure +gconnect +hotfix +Kanban +Mayowa +ptsd \ No newline at end of file