Module Logic Isolation

[tac0turtle]

I have been thinking a lot about module logic isolation after speaking with berachain.

What does this mean?

For example, staking is a lot of different things combined, delegator management, valset management, unbonding management and a few other things. The same thing happens with governance. While this has not been an issue in the past, in the current day there is a want to do large amounts of experimentation with different models of staking, governance and other things.

The idea here would be to separate parts of large modules into sub modules that can be composed into a module and used by a chain.

Staking coule become:

• valset manager
• delegator manager
• validator voting
• (possibly one or two more)

This would compose into the default staking module in the sdk, but allow other chains to pull in valset manager, delegator manager and create their own validator voting design or design multi token staking without having to rewrite the entire module.

Secondly, this isolates each part of staking and could make it easier to audit, understand and possibly write in wasm for some chains

Staking was an example here, but other modules could be done in a similar way.

Would love to hear thoughts on this form others

[itsdevbear]

Will add more thoughts when I'm at my computer, but huge supporter of this. x/staking is massively coupled to the core modules and makes doing all of the above a type system and protobuf nightmare.

[alexanderbez]

x/staking is massively coupled to the core modules

Such as? It's entirely natural for modules to depend on other modules -- this is how they're meant to be used. As you've noted, they're "core" modules.

doing all of the above a type system and protobuf nightmare.

Can you describe how it's a nightmare with specific cases?

---

I recall seeing this proposal in Discord I think, probably from @itsdevbear and it personally doesn't make much sense to me. The components laid out in x/staking in the original post by @marbar3778 are all naturally tightly coupled and naturally fit together to make a whole system.

This sort of reminds me of the classic monolithic vs micro-services debates that plagued SaaS. There's tradeoffs and no perfect solution. I can see some benefits of this approach, but they don't seem worth it to me, the primary being modularity of staking experimentation.

In any case, I'm not rejecting this proposal. Instead, what I propose is leave x/staking alone (apart from some general improvements) and instead implement a new staking module that conforms to this proposal. Any chain that truly believes in this vision is free to implement it. There are so many other super high priority items for the small SDK team to focus on. Just my 2 cents.

[aaronc]

instead implement a new staking module that conforms to this proposal.

I agree with this approach. Ideally it should be easy to innovate on SDK modules in a fork.

x/auth is a more obvious example of a module that should be more decoupled as we've discussed many times. But in this case it's not about separating complex logic but just that x/auth is/was trying to do too many things.

With staking, the logic is tightly coupled and functions as a single system more or less. We do have a big module on Regen Ledger which is composed of a few sub-modules. It's not a bad architecture. But I agree with @alexanderbez - maybe best to innovate outside the SDK for now and then present something when it's more fleshed out.