DOCSEARCHbyAlgolia
Submit Docs

Ethereum Consensus Specifications

repository·master·Indexed 26 days ago

https://github.com/ethereum/consensus-specs

Official Ethereum Proof-of-Stake consensus specifications, including technical definitions for sequential network upgrades (forks) such as Phase0, Altair, Bellatrix, Capella, Deneb, Electra, and Fulu. The repository provides YAML network configurations, compile-time presets, reference tests for consensus clients, and detailed specifications for features like EIP-6914 (validator index reuse) and EIP-8025 (stateless validation of execution payloads).

Tokens
213.9K
Snippets
390
Records
705
Agent score
87%

What's inside ethereum-consensus-specs

  1. Overview of Gloas Consensus Upgrade

    master

    Gloas is a consensus-layer upgrade for the Beacon Chain. It introduces several key features via EIPs, including:

    • EIP-7688: Forward compatible consensus data structures.
    • EIP-7732: Enshrined Proposer-Builder Separation (PBS).
    • EIP-7843: SLOTNUM opcode.
    • EIP-8045: Exclusion of slashed validators from proposing.
    • EIP-8061: Increased exit and consolidation churn.
    • EIP-8282: Builder Execution Requests.

    Note: These EIPs are in draft and subject to change.

  2. Overview of Phase 0 Networking Specifications

    master

    The Phase 0 networking specification defines the communication protocols for the Ethereum Proof-of-Stake consensus layer. It is organized into four primary components:

    1. Network Fundamentals: Covers transport, encryption, identification, protocol negotiation, and multiplexing.
    2. Network Interaction Domains:
      • Gossip Domain: Uses gossipsub for propagating blocks, attestations, and other consensus messages.
      • Discovery Domain: Uses discv5 for peer discovery and ENR (Ethereum Node Record) management.
      • Req/Resp Domain: A request/response protocol for retrieving specific data (e.g., blocks, metadata) from peers.
    3. Design Rationale: Provides the reasoning behind specific architectural choices (e.g., why QUIC is the primary transport, why SSZ is used for encoding).
    4. libp2p Implementation Matrix: Analyzes the maturity of required libp2p features across different programming languages.

  3. Overview of Phase 0 -- The Beacon Chain

    master
    The Beacon Chain is the core system chain of Ethereum proof-of-stake. It manages the validator registry. Validators are activated by processing deposit receipts from the Ethereum proof-of-work chain once the activation balance and queuing requirements are met. Exits can be voluntary or forced due to misbehavior. A primary load on the beacon chain comes from 'attestations', which serve as availability votes for shard blocks (in later upgrades) and proof-of-stake votes for beacon blocks in Phase 0.

  4. Overview of Electra Beacon Chain Upgrade

    master

    Electra is a consensus-layer upgrade for the Ethereum Beacon Chain that introduces several key features via EIPs:

    • EIP-6110: Enables supplying validator deposits directly on-chain.
    • EIP-7002: Introduces execution layer triggerable exits.
    • EIP-7251: Increases the MAX_EFFECTIVE_BALANCE.
    • EIP-7549: Moves the committee index outside of the Attestation.
    • EIP-7691: Increases blob throughput.

  7. Understand Phase 0 Networking Transport Requirements

    master

    The consensus-layer P2P network uses a multi-transport approach via libp2p.

    • Primary Transport: QUIC (RFC 9000) is the mandated primary transport due to its native stream multiplexing, built-in TLS 1.3 security, lower latency (including 0-RTT), and superior NAT traversal.
    • Fallback Transport: TCP is mandated as a baseline fallback for environments where QUIC or UDP is unavailable or blocked.
    • Optional Transports: Clients may implement WebSockets or WebRTC to facilitate interaction with browser-based light clients.

    Transports are encoded in multiaddrs, allowing peers to dynamically select the appropriate transport for dialing.

  8. Capella Beacon Chain Overview

    master

    Capella is a consensus-layer upgrade focused on validator withdrawals. Key features include:

    • Automatic withdrawals for withdrawable validators.
    • Partial withdrawals sweep for validators using 0x01 withdrawal credentials with balances exceeding MAX_EFFECTIVE_BALANCE.
    • Credential updates: Operations to change from BLS_WITHDRAWAL_PREFIX to ETH1_ADDRESS_WITHDRAWAL_PREFIX to enable withdrawals.
    • Historical Accumulators: New independent state and block historical accumulators (HistoricalSummary) replace the original singular historical roots, allowing validation of block history using only the state and blocks.

  10. Identify and implement Supernode requirements

    master

    A Supernode is a specialized node that subscribes to all data column sidecar subnets, custodies all data column sidecars, and performs reconstruction and cross-seeding.

    Requirements and Characteristics:

    • Resources: Requires significantly higher bandwidth, storage, and computation compared to standard nodes.
    • Mandatory Supernodes: Any node connected to validators with a combined balance $\ge$ 4096 ETH must be a supernode due to validator custody requirements.
    • Altruistic Supernodes: Any node with sufficient resources may choose to act as a supernode.
    • Network Role: At least one supernode must exist on the network to facilitate the reconstruction of missing data.

  12. Understand the Deneb Light Client Sync Protocol upgrade

    master
    The Deneb upgrade extends the Capella Light Client specifications by updating light client data to accommodate changes in the ExecutionPayload structure. This upgrade is necessary for light clients to correctly process Deneb-specific execution data. For existing Capella-based deployments, refer to the fork document to understand the upgrade path.