docs(adr): ADR-045 Admin module #9708
Conversation
github-actions
bot
added
the
T: ADR
There was a problem hiding this comment.
Thanks for your contribution @Mar-Alex !
So the functionality laid out here is as far as I understand it is covered by #9438, which will allow the gov module to use x/authz to delegate governance operations to other accounts.
One use case which you describe - changing the balance of a test account - sounds useful but isn't actually covered in your proposed design (because proposal handlers currently can't be arbitrary messages). I do think this an important functionality to consider. i.e. should governance be able to execute any message at all such as changing account balances? There might be different ways to deal with it, but what occurs to me is adding some admin privilege handling in x/authz.
As a general matter of process, I suggest opening an issue or discussion first before submitting an ADR because generally we'll want to talk through various solutions. We do currently have a working group on governance overseeing the work in #9438 as well as governance more broadly. I suggest we continue this discussion in #9438 or a separate issue so the working group can make sure our designs cover all the important use cases.
There was a problem hiding this comment.
I think in the context of test or dev networks, this makes a lot of sense. I mostly left linting feedback. But also have two comments:
- We should ensure
InitGenesisfails forx/adminif there exists no admin(s) in genesis. - Are you planning on copying the proposal types from
x/govor just use them directly? I would make note of that.
|
|
||
| ## Context | ||
|
|
||
| The current proposal workflow is based on a concept of validators (token holders) who vote to accept/reject a proposal. The tallying of those votes is based on the voting power (stake-based voting) of validators and their delegators. This stake-based multi-step approach provides a high level of security necessary for mainnets. |
There was a problem hiding this comment.
note, it's not just validators -- any token holder can vote to accept or reject a proposal.
|
|
||
| However, the specifics of testnets - often updates with new features that need to be well tested. | ||
|
|
||
| Almost every feature and every scenario require some proposals to be accepted. For example, changing a test account's balance (thanks to blockchain technology) is not as easy as changing some number in a bank database. Any modification of a blockchain state requires a full proposal workflow with the majority of stakeholders to participate in voting. The situation is even more complicated in testnet - there's no motivation for users to participate in voting/governance. The full governance process is too long, so it slows down testing and the delivery of new features. |
There was a problem hiding this comment.
I think in the context of testnets mainly, this makes a lot of sense.
There was a problem hiding this comment.
exactly, this is really only meant for testnet environments (altho technically a chain may want it on mainnet for things like emergency upgrades)
| ``` | ||
| type MsgService interface { | ||
| // SubmitProposal defines a method to create new proposal with a given content. | ||
| SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSenMsgSubmitProposalResponsedResponse, error) |
There was a problem hiding this comment.
| SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSenMsgSubmitProposalResponsedResponse, error) | |
| SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponsedResponse, error) |
Was that a copy paste error or intended as before?
| Requester string | ||
| } | ||
|
|
||
| type QueryService interface { |
There was a problem hiding this comment.
could be nice to have some convenience queries like isAdmin
| # removing admin | ||
| simd tx admin delete-admin [admin_address] --from <mykey> | ||
| # query list of admins | ||
| simd query admin list |
There was a problem hiding this comment.
maybe a command for adding the admin to the genesis file before launch?
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
|
Since the SDK is already working on more comprehensive solutions to the problems identified in this ADR, my opinion is that this module doesn't belong in the SDK. Maybe there are cases where this module is useful for testnets and devnets, but it can always live in a standalone repo if there is some immediate need for it before the work in #9438 is finished. Adding a new core module to the SDK is a substantial amount of work involving a lot of QA and testing, and if the use cases are already covered elsewhere, it seems hard to justify adding this. So with that in mind, I am going to close this PR as a duplicate. Apologies for any inconvenience and I do appreciate the effort here. As I said before, we're happy to have a more thorough discussion of the use cases motivating this work in either #9438 or another issue or discussion which you're welcome to open. |
Description
This ADR defines an admin module.
Author Checklist
docs/) or specification (x/<module>/spec/)godoccomments.Unreleasedsection inCHANGELOG.mdFiles changedin the Github PR explorerCodecov Reportin the comment section below once CI passes