Modularity of Consensus Mechanisms

[non-fungible-nelson]

Description

Besu is primarily used in a PoS and PoA context. However, the bulk of development of the client impacts the codebase with the assumption of PoS consensus only. This can cause unintended side-effects for PoA and other networks like ETC using PoW.

This epic outlines a set of work to modularize the components used in consensus to remove/avoid downstream impacts of PoS code on other network types. This can allow for the speed of Mainnet related development to keep pace and will allow other users to develop PoA/PoW features without confusing / entangled code.

Goals

• Determine viability of engine API for directing consensus across Besu's many algorithms
• Determine modularity necessary to compartmentalize consensus mechanisms as individual libraries
• Determine potential performance impacts and scope of regression testing
• Determine responsibility of maintenance for consensus packages

Outcomes

• Cleaner codebase focused on the PoS consensus mechanism
• Easier feature development for PoS and non-PoS consensus mechanisms by limiting surface area for changes to any consensus type and having predictable boundaries for changes.
• Easier for networks to take the latest updates to Besu, even in private network types, to get the latest security and performance benefits.
• Cleaner plumbing / reduction of tech debt accumulated around the support of 3 main consensus types.
• Easier to add new consensus types over time as they become relevant (L2 consensus, new PoA types, more).

Approach

• [x] Set up preliminary meetings to discuss approach and next steps
• [ ] Decide upon architectural approach among contributors and document
• [ ] Determine scope of work for initial POC
• [ ] Determine scope of work for production-ready code

[NickSneo]

Hey @non-fungible-nelson , Me and @gtebrean also wants to get involved in this. Can you invite us too for the discussion meetings? Would love to contribute in this

[non-fungible-nelson]

Hi all - tagging @matthew1001 as well. @NickSneo @gtebrean I think we should start a working group for this. We can begin on the next AMER/EUR contributor call. I just rescheduled it as it was previously on the 4th of July in the US, now on the 11th of July.

I will come prepared with some materials we can discuss on how to get started. I think this will be a long-running piece of work. We can start in several places and extend out.

Ideally we lean on the plug-ins heavily and create the easiest plug-in (likely proof of work) and template it from there to the more complicated constructs.

@diega if you are able to attend this call, your knowledge will be greatly helpful!