BRIP-0009: Deprecation of Geth Execution Client

BRIPs
1

Abstract

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.

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.

Bera-Reth as the 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.

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.

More details can be found in BRIPs/meta/BRIP-0009.md at main · berachain/BRIPs · GitHub

2

No concerns and mentioned this back when the fork was first proposed.

3

1XP supports BRIP-0009 and the deprecation of bera-geth in favor of a single bera-reth execution client. From an operator’s perspective, converging on a single execution client reduces long-term operational complexity, simplifies maintenance and upgrades.

4

P-OPS fully supports this decision. Additionally, Reth is well-known in the industry for its superior storage efficiency compared to Geth. We have already been migrating from Geth to Reth across multiple networks for this reason.

5

We support the overall direction of BRIP-0009. Consolidating execution client development around a higher-performance client like bera-reth is beneficial for both the Foundation and validators from a maintenance and operational perspective.

From an operational standpoint, this consolidation can simplify node operations such as migration, snapshot management, and node configuration.

Additionally, focusing execution layer development on a single client allows the Foundation to concentrate its engineering efforts more effectively, which should contribute to the long-term stability and evolution of the network.