x/staking Improvements / Independence

[ryanchristo]

Epic to track x/staking module improvements and development towards a standalone module.

[alexanderbez]

What is a standalone module in this context?

[tac0turtle]

What is a standalone module in this context?

it would have its own go.mod.

[alexanderbez]

What's the primary motivator for this approach? Do we have an idea of what dependency and release management will look like?

[aaronc]

The motivator is that we don't want you tie staking upgrades to SDK release. @zmanian spoke about this on the Gaia call last week. It could be in a separate repo or just a separate go module as proposed here. Can you share any more context @zmanian ?

The release process would basic be that the working group for staking upgrades would own the full implementation and release cycle for this module. As for dependencies that's still something to work out and it's likely non trivial...

[zmanian]

If Gaia wants to continue to depend on staking / dist / slashing / gov which are tightly intertwined we need the ability to do a new release of the module that depends on a released version of the SDK.

I still believe that adding a go.mod to x/staking won't work without more invasive changes to the repo layout that will have a substantial cost in understanding the history because of limitations of the go module resolver but I could be wrong

[alexanderbez]

@zmanian I think your concerns are totally valid. Ultimately, someone needs to just give this a quick-n-dirty shot before proceeding with an actual proposal and solution.

[aaronc]

I think it can be done with the go module resolver but it may require some other changes in the repo layout. I generally agree with @alexanderbez that someone just needs to do a quick and dirty proof of concept. What we did in regen-ledger shows the concept working in general, but there's lots of other complexities and potential gotchas in the SDK code base. Just because it's complex doesn't mean it shouldn't be done, but yeah we really don't know how much work this actually will be...

[zmanian]

My view is that doing a directory reorg is going to have a very difficult to manage impact on inflight PRs and overall readability of the history of the Cosmos SDK.

we are going to try and build out what a separate repository for the core staking modules would look like here.

https://github.com/iqlusioninc/liquidity-staking-module

[aaronc]

My view is that doing a directory reorg is going to have a very difficult to manage impact on inflight PRs and overall readability of the history of the Cosmos SDK.

We just need to do a proof of concept and see how it looks. But if you want to have a separate repo, then that's a reasonable solution as well.

[zmanian]

So the issue we are looking at right now with separating out x/staking is /x/gov depends on x/staking. x/params depends on x/gov and everything touches x/params.

This creates a situation where all the sdk modules have to released together.

[zmanian]

I think I figured out what needed to be done in the proof of concept alt staking module to decouple it from the rest of the sdk.

[aaronc]

It definitely needs a plan and some restructuring. We have a plan to extricate the dependency on x/params everywhere and x/gov is getting redesigned to be more modular. Let us know what else you find @zmanian

[zmanian]

Right now we have staking, dist and slashing outside of the SDk as a unit that can be independently imported

[zmanian]

This feature in go 1.18 looks relevant

https://utcc.utoronto.ca/~cks/space/blog/programming/GoWorkspacesComing

[tac0turtle]

closing as this is encapsulated in app wiring