BeaconKit Roadmap / Ideas Board

What is Beacon Kit?

BeaconKit is a Cosmos-SDK based framework that allows for creating EVM blockchains. It accomplishes this by communicating with a standard Ethereum Execution Client over the EngineAPI, in a very similar fashion to how Ethereum 2.0 works today.

BeaconKit Goals / Engineering Ethos

1. No Forking Shit

An absolutely requirement, I will die on this hill no matter what. BeaconKit must not have to maintain any (long term) forks of any execution client, nor CometBFT nor Cosmos of any kind. If anyone ever questions this topic please share https://github.com/maticnetwork/heimdall with them, here is their current go.mod:

This is why we have brought on experts like @tac0turtle and @melekes to help ensure that we have all the tools we need to get this done. Any fork that is made to achieve a feature must have a short to at most medium term solution to being back on main (cometbft, cosmos, go-ethereum) whatever it may be.

2. EIP Compatibility

In BeaconKit I believe that it is critical to perfectly (or at least in a way that doesn't destroy the usefulness of the EIP / make it hard to integrate) all EIPs that affect the execution layer. If it works on ChainID: 1, it should work on an execution client that is being powered by BeaconKit.
Currently we are having the BeaconKit repo follow a hardfork schedule identical to that of the Eth 2.0 BeaconChain in the future this may not make sense and instead of having Electra / Prague for instance, we may have / Prague. We will for sure, maintain the naming scheme for the execution Layer (Prague in this example)

3. Minimize data we store in the IAVL "AppHash" + Single Binary Full Replay from Genesis

In standard Cosmos-SDK chains the normal heuristic is to enforce that basically all state required for the chain to operate is stored within the IAVL tree. For many use cases this makes sense, for BeaconKit a lot of the time it isn't needed, since the Execution Client will enforce this.
We want to leverage Store/Server V2 to help us safely manage data that is important for the chain to operate but shouldn't be included in the "StateRoot" of the Cosmos Chain.
By reducing the IAVL footprint, it allows for BeaconKit chains to be more nimble, iterate faster and move to an upgrade path that looks a lot more like Ethereum hardforks that go seamlessly. We want to make it possible for the latest version of a BeaconKit change to be able to run from Genesis without any "binary" swaps along the way. A very notable annoyance that is common in the Cosmos ecosystem.

4. Decouple Execution Layer Blocks from CometBFT/Beacon Blocks

We believe that the liveliness of the Beacon Chain should not be affected by the Finalization of Execution Blocks. The Beacon Chain is "an AppChain whose goal is to finalize Execution Blocks", and thus in the even that an ExecutionBlock cannot be finalized, this SHOULD NOT halt the Beacon Chain / Force it to go into voting rounds. We should be "able to come to consensus on the fact that we did not come to consensus" is the phrase I've been using. This being said, there should be some Slashing / Penalty system to if you propose a "bad beacon block" / "miss your slot" which is an Eth 2.0 term"

5. Run a large validator set (but actually leverage it to increase decentralization)

Because BeaconKit has offloaded the computation and data heavy aspects of the EVM to the execution client layer. The Cosmos-SDK chain that is running is relatively light from a performance perspective.
I hope that utilizing standard Cosmos-SDK semantics, we can achieve stability with validator set of 256 Validators, and that is my goal.
We have also been researching other ways to increase the validator sets, via committees and other things, many of which align with this post by Vitalik regarding a potential future in which ethereum sees SSF: https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989

V0 Launch Requirements

EIP Compatibility CheckList

The following lists all of the ongoing development. Completion of these features are P0 for releasing BeaconKit to the public / testnet. I think it is important we release a product that has FULL EIP Compatibility and isn't a half baked solution.

Paris / Bellatrix Feature List:

[x] #313

Shanghai + Capella Feature List:

[x] EIP-3651: Warm COINBASE (fully handled by EL)
[x] EIP-3855: PUSH0 instruction (fully handled by EL)
[x] EIP-3860: Limit and meter initcode (fully handled by EL)
[x] EIP-4895: Beacon chain push withdrawals as operations (ref: #298)
[x] EIP-6049: Deprecate SELFDESTRUCT (fully handled by EL)

Cancun / Deneb Feature List:

[x] EIP-1153: Transient storage opcodes (fully handled by EL)
[x] #288
[x] #476
[x] EIP-5656: MCOPY - Memory copying instruction (fully handled by EL)
[x] EIP-6780: SELFDESTRUCT only in same transaction (fully handled by EL)
[x] EIP-7516: BLOBBASEFEE opcode (fully handled by EL)

Cosmos-SDK/ CometBFT Related Things

BLS Signatures in the SDK / CometBFT

BLS signatures forced us to fork the SDK and Comet, we need to work towards an unfork path.

https://github.com/berachain/beacon-kit/issues/393
Comet v1.0.0

Store / Server V2
BeaconKit chains are not like normal Cosmos chains, they have a lot of asynchronous components and need to communicate over JSON-RPC to a whole other client! We want to leverage Server/Store V2 to help manage a lot of these components and ensure that we aren't introducing any potential footguns.

berachain / beacon-kit

Dev's BeaconKit Engineering Roadmap / Vision [WIP] #474