Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tendermint 0.34 compatibility #305

Closed
liamsi opened this issue Jun 8, 2020 · 3 comments
Closed

Tendermint 0.34 compatibility #305

liamsi opened this issue Jun 8, 2020 · 3 comments
Assignees
Labels
go Compatibility with Go code serialization structure High level repo-wide structural concerns
Milestone

Comments

@liamsi
Copy link
Member

liamsi commented Jun 8, 2020

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).

@liamsi liamsi added go Compatibility with Go code serialization structure High level repo-wide structural concerns labels Jun 8, 2020
@ebuchman
Copy link
Member

ebuchman commented Jun 27, 2020

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
Copy link
Member

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
Copy link
Member

ebuchman commented Sep 16, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go Compatibility with Go code serialization structure High level repo-wide structural concerns
Projects
None yet
Development

No branches or pull requests

3 participants