Convert Figma logo to code with AI

ethereum logoconsensus-specs

Ethereum Proof-of-Stake Consensus Specifications

3,555
968
3,555
245

Top Related Projects

Go implementation of the Ethereum protocol

2,262

A Python implementation of the Ethereum Virtual Machine

12,875

The Ethereum Improvement Proposal repository

Polkadot Node Implementation

Quick Overview

The ethereum/consensus-specs repository contains the formal specification of the Ethereum consensus layer. It defines the rules and protocols for Ethereum's proof-of-stake consensus mechanism, including beacon chain, fork choice, and validator behavior.

Pros

  • Provides a comprehensive and authoritative reference for Ethereum's consensus layer
  • Enables consistent implementation across different client software
  • Facilitates collaboration and discussion among Ethereum developers and researchers
  • Supports ongoing improvements and upgrades to the Ethereum network

Cons

  • Can be complex and challenging for newcomers to understand
  • Requires frequent updates to keep pace with Ethereum's evolving ecosystem
  • May contain highly technical content that is not easily accessible to non-experts
  • Potential for discrepancies between specification and real-world implementations

Competitor Comparisons

Go implementation of the Ethereum protocol

Pros of go-ethereum

  • Full implementation of Ethereum protocol in Go, providing a complete client
  • Actively maintained and widely used in production environments
  • Includes additional tools like Geth console for interacting with the Ethereum network

Cons of go-ethereum

  • Larger codebase, potentially more complex to understand and contribute to
  • Focuses on implementation rather than specification, which may be less suitable for protocol research

Code Comparison

consensus-specs (Python):

def get_attestation_participation_flag_indices(state: BeaconState,
                                               data: AttestationData,
                                               inclusion_delay: uint64) -> Sequence[int]:
    # Function implementation

go-ethereum (Go):

func (c *Chain) GetAttestationParticipationFlagIndices(state *state.BeaconState,
    data *ethpb.AttestationData, inclusionDelay uint64) ([]uint8, error) {
    // Function implementation
}

Summary

consensus-specs focuses on Ethereum 2.0 specifications, providing a reference for protocol design and research. It's written in Python and emphasizes readability and clarity.

go-ethereum is a complete Ethereum implementation in Go, offering a production-ready client. It's more suitable for running nodes and interacting with the Ethereum network directly.

While consensus-specs is ideal for understanding and developing the Ethereum protocol, go-ethereum is better suited for practical applications and network participation.

2,262

A Python implementation of the Ethereum Virtual Machine

Pros of py-evm

  • Provides a full Ethereum implementation in Python, allowing for easier experimentation and testing
  • Includes a comprehensive test suite for validating Ethereum protocol rules
  • Offers a more complete codebase for understanding Ethereum's inner workings

Cons of py-evm

  • May have slower performance compared to consensus-specs due to being written in Python
  • Potentially more complex to understand and contribute to, as it implements the entire Ethereum stack
  • Less focused on consensus layer specifications, covering a broader scope of Ethereum functionality

Code Comparison

py-evm (from eth/vm/forks/berlin/state.py):

def apply_create_message(self, message: Message) -> Tuple[BaseComputation, BaseAccount]:
    snapshot = self.snapshot()
    computation, contract_address, data = self._apply_create_message(message)
    if computation.is_error:
        self.revert(snapshot)
        return computation, None
    return computation, contract_address

consensus-specs (from specs/phase0/beacon-chain.py):

def process_block(state: BeaconState, block: BeaconBlock) -> None:
    process_block_header(state, block)
    process_randao(state, block.body)
    process_eth1_data(state, block.body)
    process_operations(state, block.body)

Both repositories contain Python code, but py-evm focuses on implementing the entire Ethereum protocol, while consensus-specs specifically targets the consensus layer specifications.

Pros of research

  • Broader scope, covering various Ethereum research topics beyond consensus
  • More experimental and forward-looking, exploring potential future improvements
  • Encourages community participation and discussion on cutting-edge ideas

Cons of research

  • Less structured and organized compared to consensus-specs
  • May contain outdated or abandoned research proposals
  • Not directly implementable in production environments

Code comparison

consensus-specs:

def get_attestation_participation_flag_indices(state: BeaconState,
                                               data: AttestationData,
                                               inclusion_delay: uint64) -> Sequence[int]:
    # ...

research:

def compute_shard_from_committee_index(state, epoch, committee_index):
    committees_per_slot = get_committee_count_per_slot(state, epoch)
    # ...

Summary

The research repository serves as a playground for exploring new ideas and concepts in Ethereum development, while consensus-specs focuses on defining and implementing the current consensus protocol. research offers more flexibility and encourages innovation but lacks the structure and immediate applicability of consensus-specs. The code in research tends to be more experimental and diverse, whereas consensus-specs contains more production-ready implementations.

12,875

The Ethereum Improvement Proposal repository

Pros of EIPs

  • Broader scope covering various Ethereum improvement proposals
  • More accessible to a wider audience, including developers and users
  • Serves as a standardization process for Ethereum ecosystem changes

Cons of EIPs

  • Less technical depth in implementation details
  • May contain proposals in various stages, including drafts and rejected ideas
  • Slower to update with latest changes due to the proposal process

Code Comparison

EIPs (example of an ERC-20 interface):

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
}

consensus-specs (example of a beacon state transition function):

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)
    # Process block
    process_block(state, block)

The code examples highlight the different focus areas of the repositories. EIPs often contain interface definitions and standards, while consensus-specs includes more detailed implementation logic for Ethereum's consensus layer.

Polkadot Node Implementation

Pros of Polkadot

  • More flexible and customizable blockchain architecture with parachains
  • Designed for interoperability between different blockchains
  • Faster transaction finality and higher throughput

Cons of Polkadot

  • Smaller developer community compared to Ethereum
  • Less battle-tested in production environments
  • More complex governance model

Code Comparison

Polkadot (Rust):

#[derive(Encode, Decode, Clone, PartialEq, Eq, RuntimeDebug)]
pub struct ParaId(pub u32);

impl From<u32> for ParaId {
    fn from(id: u32) -> Self {
        ParaId(id)
    }
}

Ethereum Consensus Specs (Python):

class Eth1Data(Container):
    deposit_root: Root
    deposit_count: uint64
    block_hash: Hash32

class BeaconBlockBody(Container):
    randao_reveal: BLSSignature
    eth1_data: Eth1Data
    graffiti: Bytes32

The code snippets showcase different programming languages and data structures used in each project. Polkadot uses Rust with a focus on parachain IDs, while Ethereum Consensus Specs use Python with emphasis on Eth1 data and beacon block structures.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Ethereum Proof-of-Stake Consensus Specifications

Join the chat at https://discord.gg/qGpsxSA

To learn more about proof-of-stake and sharding, see the PoS documentation, sharding documentation and the research compendium.

This repository hosts the current Ethereum proof-of-stake specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed-upon changes to the spec can be made through pull requests.

Specs

GitHub release PyPI version

Core specifications for Ethereum proof-of-stake clients can be found in specs. These are divided into features. Features are researched and developed in parallel, and then consolidated into sequential upgrades when ready.

Stable Specifications

Seq.Code NameFork EpochSpecs
0Phase00
1Altair74240
2Bellatrix
("The Merge")
144896
3Capella194048
4Deneb269568

In-development Specifications

Code Name or TopicSpecsNotes
Electra
Sharding (outdated)
Custody Game (outdated)Dependent on sharding
Data Availability Sampling (outdated)

Accompanying documents can be found in specs and include:

Additional specifications for client implementers

Additional specifications and standards outside of requisite client functionality can be found in the following repos:

Design goals

The following are the broad design goals for the Ethereum proof-of-stake consensus specifications:

  • to minimize complexity, even at the cost of some losses in efficiency
  • to remain live through major network partitions and when very large portions of nodes go offline
  • to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when available
  • to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time
  • to allow for a typical consumer laptop with O(C) resources to process/validate O(1) shards (including any system level validation such as the beacon chain)

Useful external resources

For spec contributors

Documentation on the different components used during spec writing can be found here:

Online viewer of the latest release (latest master branch)

Ethereum Consensus Specs

Consensus spec tests

Conformance tests built from the executable python spec are available in the Ethereum Proof-of-Stake Consensus Spec Tests repo. Compressed tarballs are available in releases.

Installation and Usage

The consensus-specs repo can be used by running the tests locally or inside a docker container.

To run the tests locally:

  • Clone the repository with git clone https://github.com/ethereum/consensus-specs.git
  • Switch to the directory cd consensus-specs
  • Install the dependencies with: make install_test && make preinstallation && make pyspec
  • Run the tests with make citest

To run the tests inside a docker container:

  • Switch to the directory with cd scripts
  • Run the script ./build_run_docker_tests.sh
  • Find the results in a folder called ./testResults
  • Find more ways to customize the script with ./build_run_docker_tests.sh --h