...

1. Resolution of tech debt - to support today's existing use-cases in Besu, we have an unwieldy monolithic approach. This is becoming hard to manage and should be addressed (with the added benefit of the two below goals).
2. Better Distribution - Tailoring the code-base by customizing a set of modules of "Besu" to provide users exactly what they need in context. I.e. I need a private network distribution of Besu, so I need PoA consensus, but not PoW validation rules. These distributions can also have their own CI/release process to adjust testing definition and quality standards. These can also be for individual modules like the EVM. 
3. Better Client Modification - Tailoring the run-time to suit user/developer needs, allowing for deep customization of the client, its rules, and components. Here we have two some approaches:
   1. Plug-ins and the plug-in API - Using the existing plug-in API, developers can inject modifications into the Besu code at start up that replaces the "vanilla" rule-sets and functionality. It also allows for new components to interface with Besu via the API, but does not allow for whole-sale swapping of components.
   2. Modules - Creating boundaries and interfaces in the code-base so Besu's existing components can stand-alone and/or be replaced with like modules. This opens up the client to flexibility of its modules, like replacing the EVM or consensus mechanisms with novel ones (or a new storage/peering stack, etc.). This can help with tech debt, but is a heavy handed approach to customization.
   3. Remote APIs - It is currently possible to drive a blockchain purely over the rpc-apis, using the Engine API developed to facilitate Proof of Stake. This approach could be expanded to allow for other use cases that want to interact with the blockchain.

...

• Isolatable execution engine
  • EVM and state are needed and not the Consensus. Ex: Rollups, Hedera Hashgraph, EVM testing tools
• Transaction pool, transaction validation, and block gossip needed. Mev MEV searchers. 
  • Possibly EVM needed to for gas use analysis.
• Use case specific builds
  • All-in-one mainnet client that provides ethereum proof-of-stake as its only consensus mechanism.
• State Synch Testbed, rapid prototyping for data stores which can be populated with state changes from a moving chain.

Potential First Steps

• Catalog all components 
• Test approach on one or more situation listed above. 
• Extrapolate out rough timeline on MVP scope and modules timing vs the catalog.
• Scope MVP (minimum viable platform)

...