v0.50 migration's DOC

[RaulBernal]

First thing first.... SDK v0.50 job is awesome. I'm testing it and I can appreciate the evolution from v0.46 to here.

I think the related migration's doc is good but could be amazing.

To show my point: you want to announce the ABCI v2.0 integration but you don't provide specific examples enabling the Extension Votes (an important element) for running chains.

The doc only says:

For existing chains this can be done in two ways:

 * During an upgrade the value is set in an upgrade handler.
 * A governance proposal that changes the consensus param after a coordinated upgrade has taken place.

Of course I will find my way to do it but... why don't do it from your side if you want a massive adoption of the SDK?
Right, you include a light reference: Once all the code changes required to implement Vote Extensions are in place, they can be enabled by setting the consensus param Abci.VoteExtensionsEnableHeight to a value greater than zero.

And the SIMAPP doesn't show how to "optionally" enable the new feature
https://github.com/cosmos/cosmos-sdk/blob/release/v0.50.x/simapp/upgrades.go#L21

Please take it as a constructive feedback. And I think more feedback is needed for improve the knowledge base.

Peace and love 🙏 to anyone.

[facundomedica]

Hey Raul, we are working on better docs right now you can see the WIP here: #18625 and here cosmos/cosmos-sdk-docs#93 (they are pretty much done so you should get good ideas from there).
Some other things you can also look into in the meantime are:

• https://github.com/fatal-fruit/abci-workshop
• https://github.com/facundomedica/oraclis
• https://github.com/facundomedica/oracle
• https://hackmd.io/@facu/HksRlWfN6

Feedback will be appreciated!

[RaulBernal]

Amazing! I'm going to bookmark those links!
Gracias 🙏

[RaulBernal]

BTW @facundomedica I'm amazed.... My thought was to implement in ABCI v2 our BCNAracle https://github.com/BitCannaGlobal/BCNAracle
Maybe I can do a mix with your work and mine

[RaulBernal]

Sorry, I referenced my last comment to your examples; really is not related with the main thread. You can safety close this discussion.

[RaulBernal]

My two cents are here:
Something similar (need to review the fields) to this should be send as governance proposal:

{
  "title": "Enable VE on v0.50.x",
  "description": "Enable VE on v0.50.x bla bla ",
  "summary" : "Enable VE on v0.50.x bla bla bla",
  "changes": [
    {
      "subspace": "baseapp",
      "key": "abci",
      "value":{"vote_extensions_enable_height":"XXXXXXXXX"} 
    }
  ],
  "deposit": "50000000000ubcna"
}

Doc says XXXXXXXXX should be greater than 1. But also says that a halt for a new consensus is required. So maybe should coincide the XXXXXXXXX value with a height of an upgrade by governance where all validators should stop & go.

[facundomedica]

But also says that a halt for a new consensus is required.

Can you point me to where it says that? I don't think it's correct.

How it would work is that you first modify the binary so it has the vote extension methods ready to go, and where you perform the processing of vote extensions you should check if vote extensions have been enabled yet (by using consensus params' "vote_extensions_enable_height"). That way you are not trying to process vote extensions results before validators started to send them.

[RaulBernal]

Yeah, here: * A governance proposal that changes the consensus param after a coordinated upgrade has taken place
with "a halt for a new consensus" I meant that you need to upgrade the binary (for manage VE) and stop & start.

I meant to the way of set it by governance not by upgrade_handler
(it helps?)