At present, the CometBFT repo is quite monolithic and the Go API surface area is pretty massive. If anyone wants to, for example, import our ABCI types, or crypto or logging interfaces, they need to add an import for our entire codebase. The larger this surface area, the more restricted we are in terms of being able to roll out changes to various parts of the system for fear of breaking others' code.

We also have test code that forms part of our core codebase, whose dependencies end up being tracked in the core go.mod, which seems unnecessary.

Note that this doesn't necessarily mean creating different repositories for each of the modules. One could simply just set these dependencies up to have their own Go modules within our current repository, possibly leveraging Go workspaces.

We can, of course, only do this for modules where we won't be creating circular dependencies, or where we can safely break those cycles. This list will be updated over time through consultation with users.

• security: Separate modules for non-core code #193
• Split out libs/log as a separate Go module
• Split out libs/json as a separate Go module
• Split out crypto as a separate Go module
• ADR 110: Extract mempool as a separate Go module #1051
• ADR 108: Split out P2P layer as a separate Go module #1054