Table of Contents
- Approach #1 - “Besu as Debian” - create distribution artifacts from modules
- Approach #2 - “Execution Engine Shell” - create an execution engine project leveraging hyperledger/besu modules
Considerations for this work:
...
Lastly, we are working on incorporating MEV strategies into besu. MEV so far seems to be only a consideration for ethereum mainnet and the notion of splitting the block producer role into two roles blockBuilder/blockProposer likely would not make sense outside of the context of ethereum mainnet and MEV auctions.
Considerations common to both approaches
- Pros
- The effort to modularize is underway already for the evm
- This dovetails nicely with the need to have pluggable MEV strategies
- Risks
- Finding the right ‘bounded context’ for libraries is non-trivial
- The effort of refactoring Besu into modules becomes critical-path for having a besu-based execution client
- Changes the value proposition of the project - no longer is besu “an ethereum mainnet ready client”. This is going to be the case post-merge anyway, but it is worth pro-actively redefining the message.
- Adds devops considerations for publishing modules
- Mitigation
- We can initially rely on the existing submodules for library bounds
- We can continue to pursue a branch based approach for an execution client in parallel until we have clarity and modularization
Approach #1 “Hyperledger/Besu as Debian”
- Split up the current monolithic besu artifact into a group of reusable libraries which are published individually
- Rather than a monolithic artifact generate distribution-specific artifacts within the project. An example of a distribution artifact might be “ethereum execution engine”, “ETC mainnet ready client”, “Optimistic Besu”, etc.
- External projects that wish to leverage besu artifacts and/or build a 3rd party Besu distribution are able to leverage the published besu artifacts
...
- Pros
- Teku can directly integrate/implement besu for its default execution engine
- Enables different “distributions” of Besu, with artifacts custom tailored for individual chains, rollups, and/or applications
- Risks
- Might present some political challenges, we would have to solicit buy-in from Hyperledger TSC and contributors for example
- Would have to do distribution-specific acceptance tests for each artifact. This would require additional devops and CI plumbing
- Timeline
- ? (incremental approach)
Approach #2 “An Execution Engine Shell Project”
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)
...