strangelove-ventures / cns Goto Github PK

I may have misunderstood this but it sounded like the ICA AM on the controller chain is in charge of limiting ICA interactions between the controller and the host so that there is only ever one account registered on the host. If that's correct, then it limits the controller chain from using ICA for any other purpose besides CNS.

There's a similar issue with enforcing proper governance flow using ICA in Interchain Security. The solution there may help here as well. Basically the problem there is that there are gov decisions that should take place on the provider chain but enforced on the consumer chain—things like software upgrades. Basically anything that impacts the block producer's job but may not impact the parameters of the application itself. To accommodate these needs we're using the admin module (https://github.com/cosmos/composer) that mimics the gov module but uses a whitelist of addresses so that if the proposal comes from an address on that list it is executed immediately (a bit of a root account system). Since the provider chain will soon have the ability to register interchain accounts on behalf of the gov module we're putting the account address of the provider chain gov module into the "admin" list of the consumer chain's admin module.

The problem is a chicken or egg problem. How do you know the interchain account address on the consumer chain that will represent the provider chain's gov module? These addresses are specifically non-deterministic to avoid front running the creation of the account. Luckily the host chain (conusmer in this case) ICA module keeps track of the account address on the controller chain that is creating the account. Since the consumer chain is created after the host chain, you can pre-load it with the host chain gov module account address so that when an interchain account is created on the host chain, if it is being created from the pre-defined host chain gov module account address AND the client connection is the same as the one defined in genesis as 1/2 of the initial IBC handshake, you know it's the provider chain gov module (and not some other gov module with the same address from another chain).

To apply this flow to CNS you'd still have a chicken and egg problem. The host chain (hub) needs to know the gov module account address (or any designated ICA authorized address) of the controller chain to give it permission to manage the CNS field. This could be the value add of the host chain itself, it verified the go module account address of any IBC connected chain. It's still a bit tedious but at least this isolates exactly what has to be verified by the host chain before the controller chain can manage itself with its own governance.

Maybe a way for anyone to submit a comment saying something is not accurate in CNS. For example, the API endpoint is not working, wrong fee denom is listed, etc.

Setting a single address as a group admin increases risk of exposure to malicious behavior or disfunction (if the admin leaves) because admins have exclusive power to change members and their weights. The preferred way of using groups is to assign the group policy as the admin, so that member changes have to be voted on through a group proposal.

MsgCreateGroupWithPolicy was designed to set the policy as admin directly upon creation.