Tendermint 0.34 compatibility

[liamsi]

Tendermint 0.34 is around the corner and will contain has a bunch of nice improvements and quite some will be breaking changes (e.g. #300): https://github.com/tendermint/tendermint/milestone/27

If we plan to migrate to 0.34, we should start thinking about how to wiggle that into our workflow and planning (if that didn't happen already). I don't know when the SDK or even the hub plans to update.

My suggestion is to do a 0.33-compatible release first (asap). When the time is right start working on 0.34 directly on master (instead of a a separate branch like we did for 0.33). Ideally, in a bunch small efficiently reviewable PRs.
An alternative approach could be to start working in 0.34 branch like we did with 0.33 compatibility but differently from there, we do the actual changes in small reviewable PRs (and don't push commits directly to the 0.34 branch). So we can review changes only once.

Also related: #120 (comment) (this is kinda independent of 0.33 -> 0.34 but relevant each time a breaking docker image is published).

[ebuchman]

v0.33 compatible version has been released with v0.14. The next release will be for the light client and still target v0.33, but then we should start working on v0.34 compatibility.

Likely alot of things will break. Here is a high level summary of changes:

• All amino encoding is now protobuf encoding - see the new proto dir, especially types and abci
• JSON formatting may have changed (not exactly clear if so or how)
• Validators are now sorted by voting power instead of by address

Some more info can be found in the Tendermint changelog and the UPGRADING.md, though they could both use a lot of work on clarifying.

I don't have an exact idea of how we're going to integrate the protobuf stuff, but basically anywhere we have amino encoding we probably want to move to protobuf encoding. We should ultimately be looking to drop the dependence on amino_rs completely. Since amino was already pretty close to proto, it's possible we don't need to make any changes for some data structures, but it's not entirely clear, especially because a number of data structures were also modified after being moved to proto, for instance:

• many int types were changed to int32
• PubKey field was removed from evidence::DuplicateVote
• SignedMsgType is now a protobuf enum
• possibly more?

So I think we'll have to do some kind of comb through our integration tests so we can go one at a time to figure out what's breaking. But we also probably need to establish a plan to potentially iteratively replace the amino_types with something generated from the new tendermint proto files.

This is something we should try to do sooner than later as we'll need all this to prepare for / participate in the Stargate testnets and upgrade.

[greg-szabo]

Added this issue to the Tendermint 0.34 milestone. We can use this issue for coordination.

I'm going with the

When the time is right start working on 0.34 directly on master (instead of a a separate branch like we did for 0.33). Ideally, in a bunch small efficiently reviewable PRs.

approach proposed by Ismail. I'm planning to open issues tackling small portions of the upgrade and linking them to the 0.34 milestone.

[ebuchman]

Let's close this for now since basically everything mentioned in this issue has been addressed (mostly in #527) or has a dedicated or followup issues: #502, #536, #567