I think this makes sense. Though it may get absorbed by something like ADR-017.

Current code expects all blocks with height > 1 to have a valid LastCommit, and we probably want to preserve this property, so we'll likely need to include the commit for the last block in the pre-fork chain, even if it's incompatible with the commit structure/verification in the forked version.

Booked ADR-038 as per #2313

I had a thought here - rather than try to plumb the implicit start height out of Tendermint everywhere, we could implement this purely over ABCI by adding the InitialHeight to any Height fields sent in an ABCI message. This could happen either Tendermint-side or SDK-side.

The upside is that this is super easy. The downside is the confusion it might create when interacting with Tendermint RPC, since the height Tendermint is using will be offset from what the app is using.

In the spirit of ADR-017, we could have the new chainID reflect the start height, and that might help ameliorate the confusion.

It's probably the case that this is the "easy" solution, but the proper "simple" solution would be to use a variable for Tendermint's initial start height. While we should still work towards that, I thought I'd record this idea in the meantime.

Seems the best way forward is to do this Tendermint side. We have to locate every place in the code where we assume the chain starts at 0 and replace it with a variable.

Note we should also keep the state-sync use case (#828) in mind when we do this, since nodes that state synced will be effectively starting their blockchain from a non-zero block height (even though the chain itself may have started from 0, or from some other non-zero block height)

@ebuchman I found that ADR-38 was deleted in https://github.com/tendermint/tendermint/tree/master/docs/architecture. Wouldn't you develop it?

I dont believe it was written yet. This is tying into the work being done for state-sync. you can see the progress in adr-053 & #4427

I see the Pr merge failed. Would you continue to develop it?

Now that #4588 is merged, I would assume this is relatively easy to implement. Just wanted to voice that I would love to see this change in order to be able to implement our own custom state sync outside of the planned Tendermint-driven one due to a few limitations. State sync is a complex piece and the ability to start from arbitrary heights essentially allows the consumer to implement it any way they want.

@mappum I think this issue is somewhat different from what you're describing: I believe this is about doing a hard fork of the entire chain (e.g. when doing a breaking upgrade), and having the new chain start from the same height as the old rather than 0. I added a separate issue for doing out-of-band state sync in #4642.

@erikgrinaker while this issue was motivated by a different use-case, I believe it provides everything needed for out-of-band state sync. If a valid non-zero-height genesis and the required application state for that height is enough for Tendermint to start processing blocks, Tendermint doesn't require a special explicit feature for OOB state syncing.

That may well be @mappum. I believe one difference is that starting genesis from e.g. height 1000 would assume that there is no commit at block 999, while with existing application state there would be a commit at height 999 that would have to be taken into account. I'm not familiar with the details here - that may be fine if it only affects the local node, but not if it's transmitted across the wire as part of the protocol.

In any case, a patch for non-zero genesis was submitted in #4646, and I'm wrapping up state sync with the necessary machinery for out-of-band state sync as well, so we should be able to get something together in the near future.

There's increasing user demand to use this for the Cosmos Hub upgrade to Stargate. I've submitted an initial RFC to discuss the design here: tendermint/spec#119

Wondering what would be the response of http://host:rpcport/block?height when the passed height parameter is less than the initialheight set in genesis.json