Has there been some work done on how one would go about making a Cosmos SDK based application which can be updated through an on chain transaction?
By upgrade I mean both updating the application state machine and also potentially transforming the on chain state/data. If one uses something like Ethermint/Lotion, the one sort og gets this for free, as there is a VM running on top of Tendermint, but how would one do this in the SDK, or in any other more light weight way.
So here is my point of view.
We are currently focused on making full network upgrades via export and restart as painless as possible. This is important b/c
At this point in the evolution of the network, we think building cultural norms around this kind of full stack upgrade is best for the health of the network.
Our friends and partners are also experimenting with on chain upgrades via governance parameters.
In the Ethermint project, we learning about routing transaction into systems that support on-chain code. What we learn from this should be also relatively easily applied to a WebAssembly VM allowing zone developers to more easily design on chain code into their applications.
One could imagine wrapping the entire Cosmos stack in some kind of higher level orchestration engine that would enable triggering switching the entire software stack based on chain events.
Finally if the approach substrate has taken really proves itself, it wouldn’t be that much work to make substrate based chains compatible with Cosmos.
This might be a naive idea, but what about if the codebase existed on a distributed CVS replicated by IPFS, and then for any given language, the build environment needs to be available to perform an update. This would be quite efficient in the case of Go, which would only recompile changed packages.
The central part of it would be to start with building a github like app on the network I think. So there would be some component that registers new commits and potentially there is also the option of creating quorums and reputation systems to give weight to votes in accordance with these non-transferrable balances for reputation. The complex part of it has to do with defining a clear scope of expertise in order to compartmentalise the influence according to - probably another quorum, that defines the reputation scope that is applicable.
I come from a background of interest in one of Go’s parent languages from a long way back, being Oberon, where, similar in spirit to Smalltalk, state and introspection of code are designed into the applications in the same way as like Cosmos SDK the logger is considered to not just be a developer-side convenience but part of the application proper.