BRIP-0001: Execution Layer Forked Clients

BRIPs
1

Discussion thread for BRIP-0001: Execution Layer Forked Clients BRIPs/meta/BRIP-0001.md at main · berachain/BRIPs · GitHub

Abstract

Berachain benefited from using a vanilla EL to foster a strong developer community and boost developer adoption. After observing 4+ months of network performance, it has become clear that forking the EL to better suit Berachain’s system is required. Predominantly this can be attributed to fundamental differences in network topology (Berachain being significantly more sparse than Ethereum) and block times/finality (Berachain having 2s block times with instant finality as opposed to Ethereum’s 12s block time with ~12m finality).

To ensure efficient maintainability, Berachain Labs will exclusively support Geth and Reth forks. Despite this focused approach, the team remains committed to supporting major EIPs as they are accepted into official Ethereum hard forks.

Motivation

Due to the network differences between Berachain and Ethereum, certain features of the vanilla Ethereum specification are not well-suited for Berachain’s system. From observing real world traffic, network usage and performance, the following issues stand out (among others):

  • Gas prices are too slow to adjust, causing many users to experience stuck transactions. EIP-1559’s dynamic fee market must be adjusted for Berachain.
  • The unmodified EL does not allow for enshrining Berachain’s unique crypto-economic security model (Proof of Liquidity). Fundamental processes to chain health (like distribution of block rewards to block proposers) are not possible without external transactions.
  • A potential increase in demand for block space (or gas throughput) may require re-working features of the EVM implementation itself.

Related work – Gas Fee Modifications BRIPs/meta/BRIP-0002.md at main · berachain/BRIPs · GitHub

2 Likes
2

We fully support this initiative.

1 Like
3

The stuck transaction problem alone would drive people away, regardless of how “standard” the client is. Seems like reason enough.

Polygon, Avalanche C-Chain, BSC - they all forked when they needed to. The trade off, I guess, is keeping up with Ethereum’s roadmap while maintaining forks is going to be added work. Focusing on Geth/Reth makes sense too, but is both required? Keeping one client up to date is work enough. Once the EL engine is “bera-only”, there’s really no need for client choice.

Good call overall.

1 Like
4

P-OPS Team fully support that initiative !