Skip to content

BRIP-0009.md

Latest commit

 

History

History
145 lines (92 loc) · 8.48 KB

BRIP-0009.md

File metadata and controls

145 lines (92 loc) · 8.48 KB
Raw
brip 0009
title Deprecation of Go-ethereum Execution Client
author calbera, fridrik01, grizzlybera
status Final
created 2026-01-11
type Core
requires BRIP-0001, BRIP-0004

Summary

This BRIP proposes the deprecation of bera-geth, Berachain's fork of the Go-ethereum execution client. Following this deprecation, the Berachain core team will exclusively maintain bera-reth, the Rust-based execution client built on the Reth SDK. This consolidation aligns with Berachain's long-term goals of supporting modular, performant execution infrastructure and enables future protocol enhancements that require reth-sdk capabilities, such as the preconfirmation network proposed in BRIP-0007.

Context

As outlined in BRIP-0001, Berachain initially launched with support for unmodified execution clients to foster developer adoption. After observing network performance, Berachain forked execution clients to better suit Berachain's unique system, committing to maintain both Geth and Reth forks.

However, future protocol enhancements—particularly the preconfirmation network described in BRIP-0007 will require deep integration with reth-sdk for block builder and RPC modifications that are more naturally implemented with existing rust libraries. Maintaining two separate execution client forks creates significant maintenance overhead in this process.

Motivation

Resource Efficiency

Maintaining two execution client forks requires:

  • Duplicate implementation of protocol changes across Go and Rust codebases
  • Separate CI/CD pipelines and testing infrastructure
  • Dual upstream merge processes for each Ethereum hard fork
  • Increased code review and audit surface area

Consolidating to a single execution client reduces maintenance burden and allows the team to focus resources on protocol improvements rather than duplicate client maintenance.

Technical Alignment

Reth's SDK-based architecture provides better modularity for custom protocol modifications. The reth-sdk enables clean separation of concerns and easier integration of Berachain-specific features.

Additionally, BRIP-0007 proposes a preconfirmation network that requires modifications to the block builder and RPC layer. These modifications are more naturally implemented using reth-sdk, which provides the necessary hooks and extensibility points for such features. Supporting this functionality in bera-geth would require significant architectural changes that are already available in the Reth ecosystem; compatibility with existing libraries like Flashbot's rbuilder would be much harder to achieve in bera-geth.

Specification

Deprecation Timeline

  1. Announcement Phase: This BRIP serves as the formal announcement of bera-geth deprecation.
  2. Migration Period: A transition period will be provided for validators and infrastructure providers to migrate from bera-geth to bera-reth.
  3. Final Deprecation: After the migration period, bera-geth will no longer receive updates or support from the Berachain core team.

Beacon-Kit Dependency Migration

A critical dependency exists: beacon-kit, Berachain's consensus layer implementation, currently uses bera-geth as a library dependency. This dependency exists solely to support the ParentProposerPubkey field in execution block headers, as required by BRIP-0004 for enshrined Proof of Liquidity reward distribution.

Current State: The ParentProposerPubkey field is defined in bera-geth's core/types/block.go:

type Header struct {
    // ... other fields ...
    ParentProposerPubkey *common.Pubkey `json:"parentProposerPubkey" rlp:"optional"`
}

Beacon-kit uses this field through the geth-primitives package, which wraps bera-geth types.

Required Changes: To fully deprecate bera-geth, beacon-kit must:

  1. Implement ParentProposerPubkey Logic Locally: Beacon-kit must implement the logic to include ParentProposerPubkey in execution headers without relying on bera-geth's type definitions
  2. Remove bera-geth Dependency: Update beacon-kit's go.mod to remove the replace directive that points to bera-geth
  3. Update geth-primitives Package: Modify the geth-primitives package to work with upstream go-ethereum types while maintaining compatibility with the ParentProposerPubkey field requirement

This migration ensures that beacon-kit can continue to function correctly while no longer depending on the bera-geth fork.

Bera-Reth as Primary Client

Following deprecation, bera-reth will serve as the primary and officially supported execution client for Berachain. All protocol changes, hard fork support, and new features will be implemented exclusively in bera-reth.

Rationale

SDK Architecture: Reth's SDK-based design provides better extensibility for protocol-specific modifications. The modular architecture makes it easier to implement custom features like the preconfirmation network without forking the entire client.

Performance: Rust's performance characteristics and Reth's optimized implementation provide better throughput and lower latency, which is important for Berachain's 2-second block times.

Ecosystem Alignment: The Rust ecosystem aligns better with Berachain's long-term technical direction. Future protocol enhancements that require low-level system integration are more naturally implemented in Rust.

Maintenance Efficiency: Maintaining a single client reduces complexity and allows the team to focus on protocol improvements rather than duplicate client maintenance.

Backward Compatibility

Validator Migration

Validators currently running bera-geth will need to migrate to bera-reth. The migration process involves:

  1. Installing bera-reth
  2. Syncing the execution state
  3. Updating configuration to use bera-reth instead of bera-geth
  4. Restarting validator infrastructure

Beacon-Kit Compatibility

The beacon-kit dependency migration must maintain full compatibility with existing functionality. The ParentProposerPubkey field must continue to work identically after removing the bera-geth dependency.

Network Continuity

The deprecation does not require a hard fork. Both clients implement the same protocol, so the network can continue operating normally during the migration period. Validators can migrate at their own pace within the transition window.

Security Considerations

Decreased Execution Client Diversity

Moving to just a single execution client implementation ties Berachain's network to that single implementation. This means if bera-reth has something implemented undesirable it will become the effective protocol rules and no other clients can "disagree" with it.

Migration Security

  • Validators must ensure proper state synchronization when migrating
  • Configuration validation to prevent misconfiguration during migration
  • Monitoring and alerting for migration issues

Beacon-Kit Changes

  • The ParentProposerPubkey implementation must be thoroughly tested to ensure it matches the previous bera-geth behavior
  • RLP encoding/decoding must remain compatible to ensure network consensus
  • All edge cases must be handled correctly

Network Stability

  • Migration should be gradual to avoid network disruption
  • Monitor network health during migration period
  • Have rollback procedures in place if critical issues arise

Testing

  1. Beacon-Kit Functionality: Verify all beacon-kit functionality works correctly after removing bera-geth dependency
  2. ParentProposerPubkey: Test that ParentProposerPubkey is correctly included in execution headers
  3. RLP Compatibility: Verify RLP encoding/decoding remains compatible with network
  4. Validator Migration: Test complete validator migration from bera-geth to bera-reth
  5. Edge Cases: Test edge cases in ParentProposerPubkey handling (nil values, fork boundaries, etc.)

Reference Implementation

  • bera-geth: The deprecated Geth fork
  • bera-reth: The primary Reth-based execution client
  • beacon-kit: Consensus layer implementation requiring dependency migration
  • BRIP-0001: Original decision to fork execution clients
  • BRIP-0004: Enshrined Proof of Liquidity requiring ParentProposerPubkey

Copyright

All copyrights and related rights in this work are waived under CCO 1.0 Universal.