Upgrade to Cosmos-SDK v45 or v46

[faddat]

Hi Pokt!

A user/investor in Pokt contacted me today to see if Pokt could list on Osmosis, even offered to pay me to do the work.

I told the fellow, well, for $0 I'll check it out and let ya know if that's possible. So I read through your code today and it looks to me like with some effort, and likely a new genesis, Pokt could ~~easily~~ be upgraded to support IBC, allowing it to do IBC with and subsequently list on:

• Osmosis
• Junoswap
• Sifchain
• Crescent

Another advantage of this upgrade would be staking derivatives/quicksilver/interfluid staking.

The upgrade process would not be precisely simple, here's what I think we would need to do:

Software development

1. Re-structure Pokt so that it more resembles Gaia, or even better, Osmosis (they have done a lot of work to clean up app.go and it is looking super nice these days)
2. Upgrade the modules that you've got in x
3. Replace any modules that you've forked, or upgrade their forks
4. Verify that the new chain runs (a basic testnet would do fine)
5. Export the state of Pokt
6. Write code to mutate the existing state so that it can be imported to pokt-2

Infra ops We would be doing a new genesis, so:

1. determine a halt height for pokt-1
2. At halt height, validators should use the upgrade code to create the new genesis state, and mutually confirm that the new genesis state, created by exporting the pokt-1 state and running the upgrade code against it, has exactly the same sha256sum / ipfs cid as one another.
3. Validators then re-start the chain from block 0 (or if you'd like you can make the first block of pokt-2 start with halt height +1 -- that's your choice)

Exchange integrations

• existing exchanges for Pokt would need to refer to their integration code for Cosmos Atom. Pokt-2 should easily integrate with that exact code, changing only the chain-id and denom.

My next steps

So, I like this idea and this blue phone fella, so I'm going to tweet this issue, tag you guys and the relevant IBC exchanges, and we can work on it.

Your next steps

Please let us know if you also like this idea!

[Olshansk]

Hey @faddat,

Thanks for taking the time for diving into the codebase to evaluate the feasibility of IBC compatibility. Making Pocket IBC compatible is something I've personally been interested in but haven't had the time to do a deep dive into.

, Pokt could ~~easily~~ be upgraded to support IBC,

As you correctly pointed out in the statement above, easily is the keyword. It makes sense to me at a high level, but I believe the devil is in the details.

Similar to a proposal on the Pocket forum - Optimizing the v0 client to save the network a ton of money - I would estimate that this effort take a small team more than half a year to implement, test, deploy, with testing taking the majority of the time.

4. Verify that the new chain runs (a basic testnet would do fine)

Given that Pocket's version of Tendermint was forked almost two years ago, along with the other changes you outlined, this step is over-simplified IMO. For example, PIP-9 Consensus Rule Change – RC-0.8.0 was implemented in https://github.com/pokt-network/pocket-core/pull/1408, with the majority of the time/work being dedicated towards QA.

For example, in a recent podcast episode with Federico from Evmos, he mentioned that while the implementation & protocol are sound, the tooling for testing & development is one of the key reasons the recent Evmos launch failed, and it is where their focus is now. Though Pocket's tooling for verifying changes of this magnitude are okay, the wishlist is long and validating these changes would be a non-trivial effort.

Note: I'm not trying to single out Evmos or any other project. It's just an example. IMO this is true for most crypto projects, including Pocket v0.

Please let us know if you also like this idea!

I like it, but I'm afraid it would be a distraction to the core protocol team and be a much greater effort than anyone expects.

I'll counter you with another idea that I love: help us research/design what needs to be done to the V1 specs to have IBC compatibility in the next version of the protocol. It might not make it into the v1.0 release, but I would personally advocate for it to be part of v1.1.

I believe the long-term dividends for the protocol, project and community of focusing the IBC compatibility effort on v1 will be much more significant.

Olshansky

[faddat]

Hey I’m glad you like it!

so I’m not too familiar yet, but let me tell you more or less what my team and I do, and tell you where I am certain you are right:

• upgrades are terrorism to devs

There I said it :) and it’s totally not only evmos, we had to pare down scope for dig’s upgrade recently for all the reasons you just described.

Export upgrades with a new genesis are somewhat less terrorism so, since you do like the idea I’ll take a somewhat deeper look under the hood:

I suspect we might be able to cheat (a little) in one of those don’t lose much feature scope but save lots of time ways— but I need to check your consensus changes before I tell you that with any certainty.

Oh, and about me— so, I specifically maintain chains.

We make some chains at Notional but in fact I take a lotta joy in software maintenance specifically— build automation, linting, updating stuff, etc

I’ll check back in once I’ve figured out if my hunch is right or not and thanks for the reply!

[Olshansk]

@faddat

Question: Since IBC is just an interface, do you know of any Golang projects that implemented it outside of Cosmos?

Idea: I was thinking of putting opening up a research item for V1 where we could scope (design, write interface, prepare, implement, test, etc...) out the work necessary for IBC integration.

Reasoning: My understanding (per your original comment) is that the Cosmos SDK has a lot of "duct tape" to be IBC compatible, but after reading the IBC whitepaper (which I did not read in big detail since it was VERY dry), it is ultimately just an interface that we need to comply to.

Next steps: If you think extracting the golang IBC interface, which we would implement over time, we'd be able to so in a cleaner and more modular way independent of the Cosmos SDK.

I glossed over a lot of details, so would be happy to discuss in a public contributor hour call sometime on discord. Let us know!