Open
Description
High-level, multi-quarter tracking issue for specific work aiming to make the codebase more malleable, while maintaining high standards in terms of QA. This issue will be expanded over time.
The ecosystem benefits from changes to Tendermint Core/CometBFT relatively slowly. This is partially due to the sheer complexity and entanglement of various parts of the codebase as it has evolved somewhat organically over the years.
- Having clear specifications will allow us to modularize the system better, which we believe will allow us to make changes more easily:
- Split parts of the system out as independent Go modules #394
- Improving our QA will give us greater confidence when making changes
- QA runner improvements #51
- Improve QA infra to test upgrades on e2e/testnets #56
- Expand the QA to include a performance benchmark #834
- Add CI workflows to give better assurances with every pull request
- Automatically flag Go API-breaking changes on release branches
- proto: use a breaking change checker in CI workflow of release branches tendermint/tendermint#8003
- ci: add Go vulnerability checker to proactively flag vulnerable code tendermint/tendermint#9872
- Better testing for user-facing parts of the system
- Ensure that all breaking RPC changes are deliberate
- Automation and streamlining of upgrade processes
- Soft upgrades and version numbers [Tracking Issue] #122
- Add automated upgrade tests to our QA for new major releases
- Versioning certain API surfaces will allow us to more easily roll out breaking changes
- Separating logging from tracing #607
- cometbft/tools-infra#1
Paying off technical debt
Paying off technical debt will enable us to move faster.
### RPC
- [ ] cometbft/cometbft#447
### Consensus internal refactoring
- [ ] #2663
- [ ] #2659
### Persona: Consensus engine developers
- [ ] Ideal Go API boundaries for consensus engine developers
- [ ] https://github.com/cometbft/cometbft/issues/342
- [ ] https://github.com/cometbft/cometbft/issues/2424
- [ ] https://github.com/cometbft/cometbft/issues/3383
These used to be tracked by #43. Consolidated those issues here:
Related:
- Offloading non-critical data will allow us to simplify the node architecture
Originally tendermint/tendermint#9882