Planning for mamaki upgrades

[evan-forbes]

There are several factors that could affect when and how we upgrade mamaki. We should plan and discuss those things here. Ideally we can reach consensus over which features can go in which upgrades.

off the top of my head

• we will need to hardfork when we upgrade the cosmos-sdk/downgrade to tendermint v0.34
• we will need to hardfork when we introduce non-interactive defaults Tracking: Non-interactive defaults #382
• we will need to hardfork when we pay for padding by default Charge gas per message share #431
• we will need to hardfork when we introduce the vesting module feature: add real vesting module  #280
• we will need to hardfork when we introduce the QGB
• we will need to hardfork when we pick different parameters Define genesis params #169
• we will need to hardfork when we re-enable IBC/IBC allowlist Investigate limiting IBC connections #235 Re-enable IBC #412
• we will likely restart the chain when introducing 512 byte shares https://github.com/celestiaorg/celestia-core/issues/724 and using leopard/go-leopard Switch to using klauspost/reedsolomon celestia-core#673

Each of the above upgrades could be combined or kept separate.

Assuming that we can get mamaki to a stable enough point, either with v0.6.0 or with another non-hardfork upgrade, then we have more freedom on when we can upgrade.

[liamsi]

we will need to hardfork when we upgrade the cosmos-sdk/downgrade to tendermint v0.34

I still do feel we should do this as soon as possible and independent of the other changes. I want the testnet to be as stable as possible again and not wait for additional features.

[evan-forbes]

if we upgrade ASAP, then we will have to have at least 3 upgrades, assuming that we don't want to bundle everything else into one upgrade.

[liamsi]

I do not mind 3 upgrades if 2 of those are done via the upgrade module and gov voting. As the coordination would happen on chain.

[liamsi]

@musalbas might disagree here.

[musalbas]

I think this should be discussed with #validators at least in Discord. 3 upgrades might require quite a lot of coordination.

[evan-forbes]

if 2 of those are done via the upgrade module and gov voting.

I'd need to try it out to be sure, but since we can run arbitrary logic in the upgrade handler, we might be able to get away with a chain reset using the normal gov + upgrade modules.

[adlerjohn]

The non-interactive defaults aren't a consensus rule, and shouldn't require a hard fork. Could you clarify why they would require a hard fork, I might be missing something.

[evan-forbes]

sorry that I missed this comment, it will need a hardfork mainly because of wrapped txs. Both because nodes that don't know how to interpret them will ignore otherwise valid txs, and because this changes how message inclusion is determined.

[evan-forbes]

closing because this is out of date. we've since hardspooned to mocha