In the current blockchain landscape, the choice of a blockchain framework often involves a trade-off:

• The Cosmos-SDK and CosmWasm, while complex and full of technical debt, provides access to Single-Slot Finality and IBC.
• The Move explores a new way to apporach smart contract design, but the ecosystem offers minimal tooling and a confusing array of different versions.
• The EVM boasts mature tooling, but launching your own L1 or L2 involves working with a peculiar geth fork, which eventually becomes only somewhat "EVM compatible".

Our Learnings from Polaris

After extensive testnet data analysis, we carefully assessed the strengths and weaknesses of Polaris. It seemed as though we were combining the best aspects of both the CometBFT/Cosmos and the EVM ecosystems, but also carrying their respective drawbacks, which ultimately led us back to the drawing board.

CometBFT Mempool Issues

A significant portion of the severe congestion on Artio was due to the well-documented issues with the CometBFT mempool. We observed that these issues hindered transaction inclusion and disrupted the EIP-1559 fee market's proper functioning, making the chain difficult to use at times.

Precompiles are Efficient, but Developer Experience is Lacking

Despite the substantial improvements in execution performance (around 500%) achieved through precompiles, the developer experience suffered significantly. Tools such as foundry did not always function as expected. Running forge script caused problems, as the local revm lacks the logic needed to execute these transactions.

Maintaining a Geth Fork is Harder than you Think

We realized internally that maintaining forked execution clients is not sustainable in the long term. Forks rapidly lag behind the latest release, and when combined with custom logic, often require a significant level of engineering support to maintain.

Throw client diversity into the mix and you are now maintaining multiple forks, across several different programming languages, all while trying to hire senior engineers in an already competitive market. What most alt-L1/L2 EVM chain developers want is the stability and tooling that comes with EVM. Why jump through all the hoops of running a fork to glue in your new shiny consensus algorithm, when you can simply hook-up the last docker pull reth:latest and you're done.

Welcome to BeaconKit

BeaconKit is a modular framework for building EVM consensus clients, enabling developers to launch both layer 1 and 2 EVM blockchains with full EIP compatibility, single-slot finality, and much more. Much like its Golang counterpart Prysm, BeaconKit uses the EngineAPI to facilitate communication between the Consensus and Execution Layers, allowing for a complete decoupling of the EVM execution environment from CometBFT.

Operators can run standard unmodified execution clients and achieve perfect / 100% EVM identicality with the Ethereum mainnet. As of today, we have tested BeaconKit with the following execution clients:

Geth: the Official Go implementation of the Ethereum protocol.
Erigon: a more performant, feature-rich client forked from go-ethereum.
Nethermind: a .NET based client with full support for Ethereum protocols.
Besu: an Enterprise-grade client, Apache 2.0 licensed, written in Java.
Reth: a Rust-based client focusing on performance and reliability.
Ethereumjs: a Javascript based client managed by the Ethereum Foundation.

Immediate Execution & Optimistic Payload Building

By leveraging our custom BeaconBlock on top of the standard CometBFT block, BeaconKit supports immediate execution. This means that BeaconKit chains can enforce that Validators sign over the proposed StateRoot before accepting the block, significantly simplifying the Block verification process and reducing the time from BlockGossip to Inclusion. This allows for abci.FinalizeBlock to be extremely fast and paves the way for Optimistic Payload Building.

"This alone can reduce block times by up to 40%."

Immediate execution enables us to start building the execution payload (EVM block) in advance, as we know the StateRoot of the current block before it is finalized. This alone can reduce block times by up to 40%.

Cosmos Modules? Protobuf Encoding? F*** That.

Despite the Cosmos-SDK's goal of allowing for interoperable modules, we found that the coupling of these modules made implementing things the way we wanted to be extremely difficult. The way the SDK is currently implemented is very opionated and leaves little to no flexibility. That wasn't going to work for us, so we ripped everything out and did it ourselves.

Cosmos Modules? Never Heard of em.

BeaconKit uses zero standard Cosmos modules and allows chain developers to inject custom logic on a case-by-case basis, enabling Custom Block Validity rules, custom Block Processing logic, and more.

"Wait, you need AccountKeeper? BankKeeper?? 🤦‍ Ughh...", is a common complaint among Cosmos developers. Implementing custom staking logic shouldn't have turned into a 6-month research project where we had to remove everything, and we ensured that this wasn't the case for BeaconKit. In the process of designing BeaconKit, we made SSZ (Simple-SerialiZe Encoding) a first-class citizen and completely eliminated the mess that is protobuf. This enabled the implementation of EIP-4788, allowing us to verify and prove consensus layer data on the execution layer without permission.

For example, Proof-of-liquidity requires that the chain relay validator proposal information into the execution environment, and this is encompassed within the BeaconBlockRoot. Beyond our own use-cases, we envision a world where other builders developing their own alt L1s or L2s may want similar access to such information, which is why 4788 was such a crucial milestone.

Blobs? Rollups? Of Course.

EIP-4844 was included specifically to scale the future of BeaconKit-based chains. We've seen the benefits of having a readily available data availability layer on the mainnet, and how that enables L2s. In addition to supporting EIP-4844, chain developers can use BeaconKit with any ABCI 2.0 compatible consensus engine, and thus can easily be integrated with Rollkit to create powerful layer-2 solutions.

Custom Block Validity Rules and Types

When integrating BeaconKit, developers can easily introduce custom block validity rules to allow for certain behavior within both their EVM and Beacon Blocks. For example, a chain developer could choose to implement a custom block validity rule that allows for them to reject any ExecutionPayload (EVM block) that does not conform to a certain transaction ordering, as a trivial example.

Eventually, these "plugin-based" validity rules could be extended to integrate mechanisms such as PEPC, which is useful for re-staking and cross-chain applications.

What's to Come?

BeaconKit is currently source-available under a BUSL 1.1 license, but will switch to MIT in the future. If you are interested in using BeaconKit for your next L1 or L2 project, please get in touch! Link to the repo here: https://github.com/berachain/beacon-kit