Top Related Projects
Go implementation of the Ethereum protocol
A Python implementation of the Ethereum Virtual Machine
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.
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.
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 designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Ethereum Proof-of-Stake Consensus Specifications
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
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 Name | Fork Epoch | Specs |
---|---|---|---|
0 | Phase0 | 0 | |
1 | Altair | 74240 | |
2 | Bellatrix ("The Merge") | 144896 | |
3 | Capella | 194048 | |
4 | Deneb | 269568 |
In-development Specifications
Code Name or Topic | Specs | Notes |
---|---|---|
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/validateO(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)
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
Top Related Projects
Go implementation of the Ethereum protocol
A Python implementation of the Ethereum Virtual Machine
The Ethereum Improvement Proposal repository
Polkadot Node Implementation
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot