Reth Integration

[HariSeldon23]

Hey everyone,

I'm exploring ways to use the Simplex consensus engine with Reth (the Rust Ethereum execution client). I've identified two potential approaches for creating the necessary translation layer between Reth's Engine API and Simplex's consensus engine, and I'd appreciate your thoughts on the best path forward.

The core challenge is bridging between:

1. Reth's Engine API interface (engine_new_payload_v2, engine_fork_choice_updated_v2, etc.)
2. The Simplex Engine implementation in commonware-consensus

I've considered two main approaches:

Approach 1: Extend the Commonware Library

Add a Reth adapter module to commonware-consensus that implements Reth's Engine API interface. This would keep all consensus-related code within the Commonware ecosystem and make it easier for others to adopt. The adapter would handle the translation between Reth's execution payloads and Simplex's consensus mechanisms.

Approach 2: Fork Reth

Alternatively, we could fork Reth and add the translation layer there, implementing the connection to Simplex within Reth's codebase. This might offer more direct access to Reth's internal state and potentially better performance, but at the cost of maintaining a separate fork.

Given Commonware's architectural philosophy and future plans, which approach would you recommend? I'm particularly interested in how you envision Simplex being used with different execution clients.

Thank you for any guidance you can provide!

[patrick-ogrady]

Thanks for the question (and writing out some options)! Seeing Reth running on Commonware is very much on my bucket list 👀 .

Given Commonware's architectural philosophy and future plans, which approach would you recommend? I'm particularly interested in how you envision Simplex being used with different execution clients.

I don't think its a good idea to merge any "execution environment specific code" into commonware-consensus (IMO it should only ever operate over "opaque hashes"). I would recommend creating some layer (what you called an "adapter") that sits above consensus (and maybe also p2p) that implements its consensus dependencies. Given past experience, I would strongly recommend not maintaining a fork of EVM execution code.

As mentioned in here, if this adapter/primitive becomes popular we would consider maintaining it but feel it is best kicked off outside of the repo.

Reth's Engine API interface (engine_new_payload_v2, engine_fork_choice_updated_v2, etc.)

I'm not intimately familiar with their API but know Berachain took a similar approach with Cosmos-SDK (so at least their is some prior art): https://github.com/berachain/beacon-kit

Hopefully it doesn't really require much ETH2 specific info (and anything it does want can be coherently stubbed).

[HariSeldon23]

Super helpful as always. Much appreciated :)

Didn't know about beacon-kit that will definitely save a lot of time and provide valuable lessons.

I agree that maintaining a fork of Reth is definitely suboptimal. I've got a basic node working with Simplex consensus, so I'm now working on the leader election. Leader election is based on geographic decentralization so nodes will need to submit a ZK proof of their physical region and hardware. Once I have that up and running and blocks getting produced with leaders, then I'll move onto plugging in Reth via an Adapter.

[HariSeldon23]

Also with Simplex not having forks, the Beacon-kit adaptor for Commonware should theoretically be a lot simpler

[patrick-ogrady]

Didn't know about beacon-kit that will definitely save a lot of time and provide valuable lessons.

I only learned about it recently myself. Very cool approach that I think will become the standard going forward for people running an EVM.

I've got a basic node working with Simplex consensus

Nice!

Also with Simplex not having forks, the Beacon-kit adaptor for Commonware should theoretically be a lot simpler

To clarify, prior to finalization being called on some hash it can be dropped (reorged). It is true that there can't be more than 1 block at a "view" but it is possible for the block from a "view" to be dropped. You can read more about how this works here: https://simplex.blog/