- Approach #1 - “Besu as Debian” - create distribution artifacts from modules
- Approach #2 - “Execution Engine Shell” - create an execution engine project leveraging hyperledger/besu modules
Table of Contents outline true type flat
Considerations for this work:
...
Create a new project for the execution engine, leveraging the hyperledger/besu modules. Rewrite, override or extend the portions of besu necessary to deliver a lean execution client without introducing any of the ethereum PoS merge code into besu. This would be a step in the direction of treating hyperledger/besu as more of a general purpose reference implementation of its libraries, rather than an “ethereum mainnet ready client”.
- Pros Greater simplicity
- Less need to coordinate with other concerns: enterprise, other public mainnets
- Submodules and functionality that is unrelated to ethereum mainnet are just unimported
- Onboarding of new PE may be faster - no need to understand the whole codebase, just the specific rules of the execution client.
- Performance
- Lower cyclomatic complexity would inevitably lead to better performance
- Integration to new services
- A standalone execution engine could be leveraged in rollup implementations
- Greater simplicity
- Performance
- Integration to new services
- Cons
- Inevitable drift from re-implemented portions of besu, causing duplication of work for bugfixes and shared features
- Likely no resources or support from besu-contributors and/or hyperledger org
- Work on the execution engine would be split across multiple repositories Hyperledger/Besu and Consensys/besu-engine (for example)
...