Bounded Contexts / Business Logic. Is it possible to extract interfaces for application code to use in a way that it doesn't care about the implementation? Hopefully we can get to a point where each of these is a Bounded Context with clear boundaries, obvious and intuitive interfaces into and out of them.
- Consensus
- Proof of Work
- External (or none?): Proof of Stake
- driven by Engine API
- Clique
- IBFT
- QBFT
- P2P
- ETH/66 and prior
- DevP2P
- Execution
- EVM
- Tracing
- Transaction Management
- Tessera integration
- MEV
- public and private transaction support
- Synchronizing
- Full sync
- Fast sync
- Snap sync
- Storage
- World State
- Forrest
- Bonsai
- Verkle
- Blockchain
- Key-Value specific implementations under each. Any of the above could choose to use LevelDB or RocksDB as their storage implementation.
- World State
Cross Cutting Concerns. All of the above may depend on any mix of these. This part is ok to be a web of dependencies.
- Crypto
- Elliptic Curves
- Signatures
- Hashing
- native implementations
- Serialization
- RLP
- JSON
- GraphQL(ish. it's a lot broader than just serialization)
- APIs
- RPC
- HTTP
- Websockets
- GraphQL
- RPC
- Inversion of Control
- Dagger
- Observability
- Logging
- Metrics
- Debugging extras
- Configuration
- PicoCLI
- Genesis state vs. named networks
Proof of Concept:
Introduce Dagger to implement a vertical slice of functionality. We need to find a feature that touches on a few cross-cutting concerns, but just one Bounded Context.
Nominees:
- Jumpdest caching. Only relevant to the EVM, but requires caching, configuration, Observability, and hashing. Plan would be to provide each of these as a dependency.
- PoA consensus mechanisms. Impact TBD.
- Transaction pool. Impact TBD.
- Merge Context. What if the Merge Coordinator and related classes could be a dagger module.
- Protocol Schedule. Impact TBD.