Seamless upgrade to preserve transaction data?

Archived Cosmos-SDK
1

Hi, I’m now working on a chain, and one of the features is proof of existence of data.

In my opinion, for proof of existence, the data on the transaction itself (e.g. block number with timestamp) is as important as the application state.

However, it seems that currently chains using Cosmos SDK (e.g. Cosmos Hub) are doing upgrades by exporting application state, importing into a new genesis file and starting a new chain.

In this way, the transaction data are not preserved, and it is difficult for an external verifier (e.g. court?) to verify that the old chain is valid from the data of the new chain.

I think seamless upgrade is possible if there is no breaking on the Tendermint part. However, since Tendermint is still in alpha stage, it is expected that it will eventually introduce breaking changes.

I think it is a common issue, so there must be some discussions on it. Could someone please provide some references to discussions on this issue, or briefly describe the current conclusion on this topic?

2

It depends what you mean by ‘seamless’ but you can always retain the data regardless of upgrades/forks etc. It might take you a few hours to update stuff depending on what the ‘breaking’ changes are but this is standard practice when updating libraries through version changes.

3

There’s a module implementation for this already, which most probably will be part of next cosmos-sdk release. You can look at the module in current master.

4

For example, the upcoming Tendermint upgrade (v0.32.9 or maybe v0.33?) is going to change the block header structure, which changes the block hash and hence the signatures on commits for previous blocks will be invalid in the point of view of newer Tendermint software.

In this case, a new full node with the newest Tendermint software will not be able to verify the genesis block and the blocks before the upgrade, unless there is a compatibility mode in Tendermint, which specifies that use old block structure before block 12345 and new structure afterwards for block verification.

Otherwise, it seems the only possible way is to abandon the whole old chain and have a new one on the new Tendermint (and Cosmos SDK) version with exported application data.

Cosmos SDK modules will not help in this case, since it is about Tendermint level.

5

I know this is an old conversation, but did you solve this issue? If you did, would you mind sharing your solution?

We’re bumping against a similar issue upgrading from TM 0.33.x as the key encoding switched from from Amino to protobuf…