The way celestia-app supports multiple app versions in a single binary is error-prone. Currently it relies on conditionals littered throughout the code-base.
Proposal
Refactor how celestia-app supports multiple app versions by introducing an ABCI multiplexer that communicates with CometBFT and delegates to the appropriate version of celestia-app.
Next steps
[x] Create a diagram of multiplexer communication with CometBFT.
[x] Investigate Cosmos SDK v0.50.x to see how they structure state machine modules
Update: most Cosmos SDK modules were not spun out into modules in v0.50.x. See here. So I'm investigating v0.52.x instead. x/mint was spun out in this PR.
Question: why is "cosmossdk.io" the new import name? Go claims it doesn't have a valid go.mod: https://pkg.go.dev/cosmossdk.io
[ ] Explore if any other chains have a solution to one binary supporting many major versions.
[ ] Question: can we refactor celestia-app past versions from release branches into directories on main so that it's easier to modify v1, v2, v3 while working on multiplexed app? Go modules supports this because each new major version has a unique Go module name.
[ ] Question: how long do other chains take to perform stop + start upgrades?
Possible next steps
See Remaining tasks section of prototype
Based on a discussion w/ @cmwaters, on a fork:
Before proceeding, create a diagram with desired Go module dependencies
v2.x
Modify all state machine modules to not import app or appconsts
Extract a Go module for all state machine module
Modify app to import the go.mod state machine modules
Commit and push
main
Cherry-pick the commit to modify all state machine modules to not import app or appconsts
cherry-pick the previous commit exception for x/blob
create x/blob v2 Go module
Modify app to import the go.mod state machine modules
Context
See prototype in https://github.com/celestiaorg/celestia-app/pull/3729
Problem
The way celestia-app supports multiple app versions in a single binary is error-prone. Currently it relies on conditionals littered throughout the code-base.
Proposal
Refactor how celestia-app supports multiple app versions by introducing an ABCI multiplexer that communicates with CometBFT and delegates to the appropriate version of celestia-app.
Next steps
[x] Create a diagram of multiplexer communication with CometBFT.
[x] Investigate Cosmos SDK v0.50.x to see how they structure state machine modules
Question: why is "cosmossdk.io" the new import name? Go claims it doesn't have a valid go.mod: https://pkg.go.dev/cosmossdk.io
[ ] Explore if any other chains have a solution to one binary supporting many major versions.
[ ] Question: can we refactor celestia-app past versions from release branches into directories on
mainso that it's easier to modify v1, v2, v3 while working on multiplexed app? Go modules supports this because each new major version has a unique Go module name.[ ] Question: how long do other chains take to perform stop + start upgrades?
Possible next steps