This is basically how governance has moved forward throughout time. Sometimes the governors get it right and sometimes wrong. We can try to make a good decision and then move forward.
Culture exists to overcome the mere survival of the fittest. We can be better than raw nature at helping people live full lives. Maybe we need some more mantras:
Not your code, Not your canister
Social Recovery or Recovery Misery
Public utility funding builds trust, VC funding leads to secrecy and lust.
Seed protection, data’s lifeline connection.
Upgrade success? Backup first!
$ICP is the governance token that controls the NNS
$CHAT is the governance token that controls the OpenChat SNS
What happens if the OC SNS gets stuck and there’s millions locked in the dapp?! Game over?! No, you ask the NNS DAO for help!
This is by design and the whole purpose of the NNS/ICP.
The NNS can vote to delete any canister and make updates to any canister. We’re debating whether it should or shouldn’t and completely agree there needs to be strict governance on how or when. I’m just saying by design it can and as a DAO built wholly on the NNS we are asking for it to intervene on our behalf. That is all. The NNS can help…will it?
If not now, is there a time when it will? If not, then why bother to decentralize or build on it?
I would imagine over time, scale will give the lower hierarchy tokens a lot of power in practice. When there are millions of dapps on IC, the NNS won’t be able to mediate all of them. Probably like how the US Federal Court system has 94 district courts, 13 circuit courts, and a supreme court. Supreme court only hears very few cases that have successfully appealed district and circuit courts.
I would be comfortable with this one-off recovery only if:
The NNS should first pass a governance proposal, declaring that it would never assign itself as a controller of another canister, unless a) there is a security incident, b) the last owner prior to the security incident provably submits a proposal asking the NNS for help, and c) the community agrees via NNS voting.
The proposal from Taggr should clearly state its purpose: it wants to fork the IC network after a security incident, and not disguise it as “social recovery”. The NNS would be voting on whether to adopt the new fork as mainnet.
After the incident is resolved, the NNS shall immediately revoke its power to add itself as a controller to other canisters by performing a code upgrade (if applicable).
This is a very dangerous feature. The NNS would need to deliberately increase the barrier in order to use such a feature, and make it apparent to the entire community what it’s actually doing (i.e. forking the network), so that people can properly weigh the pros & cons.
I feel very uncomfortable with voting yes on this proposal, and I am leaning towards voting no.
This will set a precedent that may be extremely difficult to deal with in the future.
There is the ability to recover the application apparently because of backups. There is an issue with IIs, but perhaps that is the price to be paid. Or, I would love to see a solution that allows greater portability/recovery of IIs.
I would also like to call out the difference between an application controlled by a DAO and an immutable/autonomous application. Taggr was apparently not immutable nor autonomous, as a group of people had the ability to upgrade it. This group of people used that power and unfortunately made a mistake that affected all users without their consent. They had no guarantees that this would not happen, guarantees they might have enjoyed with a truly immutable canister.
I think we should consider the power of immutable applications that can’t have their binaries updated. That doesn’t mean the application can’t be updated, just that the binary is deployed and fixed to a canister. An upgrade process would require a new set of canisters to be created, and data and accounts to be ported over. Ideally each individual would have the choice to port themselves over to the new app, ensuring maximum decentralization.
I think the idea of completely mutable binaries is very dangerous and potentially antithetical to the idea of decentralization and autonomy. Of course it’s convenient, but it trades off security and decentralization because the binary can be changed at any time, meaning literally anything about the application can be changed.
I rambled a bit there. In the end, I lean towards not supporting a bailout at the replica level. We should look into allowing IIs to port easily instead, which would help us to embrace truly immutable canisters. Mutable binaries are dangerous. They have a place but they are dangerous.
Appreciate the feedback Jordan… we never claimed to have an immutable canister although maybe it qualifies now!
But a DAO that can have code changes submitted by a person and voted on by DAO members…doesn’t this define the NNS?!
There are weekly code changes to the ICP voted on by the NNS DAO.
Also, there are many additional II related challenges that prevented us from just migrating to a new canister this is a protocol problem and and akin to platform risk…we have the backup and this was our first choice which was discussed and ruled out.
Bottomline we are asking the NNS DAO to help with updating our canister…similar process if it was a SNS.
We accept the results of the NNS DAO but it opens the discussion about whether decentralising an app on the IC makes sense because this problem is almost guaranteed to happen again.
If the IC is going to succeed we need to start with the right presuppositions. Any canister on the IC can be updated by the NNS via a replica upgrade. Full stop. Unless you want to get rid of the NNS completely, I don’t see a way around this. If the mob can vote to kill/update/usurp any canister on the network via code upgrade then your only choice is a governance engineering exercise that sets up boundaries, checks and balances and other institutions that reduce the likelihood of mob rule.
The ICDevs dev board seems pretty split and I’m getting convinced that we shouldn’t accept this current proposal, should regroup, and offer a more comprehensive proposal that meets the governance goals and ethos goals that seem to be present.
No one wants the NNS to be a vote away from coercing someone’s canister.
The NNS in all constructions that allow replica upgrades will be one vote away from coercing any canister on the network.
Give the mob a viable, easier path canister recovery that works well when we want it to and becomes very hard to corrupt. We may need to use some game theory here.
A modest proposal:
Create an SNS DAO called Social Recovery.
Let people put in ICP and get tokens.
Do our best to anti-bot it.
Collect a treasury.
The Social Recovery DAO only has these functions:
SRDAO elects 21(other number?) Doxed Community delegates to sign for the DAO.
A person wanting social recovery must submit a proposal that has a non-insignificant fee. This fee is split between paying the delegates for review and making determinations and paying out to Token holders. Delegates also get paid from the treasury per proposal via a treasury proposal. Token holders can veto this if they feel the delegates did a bad job.
Delegates can accept the proposal to update the canister controllers which sends a controller update to the NNS.
The NNS can veto it. If it is vetoed, fees go into the treasury.
Delegates are incentivized to only let items through that will pass the NNS.
Token holders are incentivized to elect competent delegates.
Maybe spam proposals are hiding in here somewhere. More thought is certainly needed.
Exactly, this is how the NNS works. And I think the NNS has some major drawbacks because of this. It also has major benefits because of this. But its decentralization and autonomy is questionable because it can be upgraded at any time. I would like to see the NNS’s scope reduced to the minimum possible. I think canisters should seek to reduce their upgradability to the minimum possible as well.
We don’t have to go down this path here, but I absolutely agree that we need more checks and balances. Right now there are a few monolithic powers in the system with few checks on that power.
Voters aren’t split up into groups that can balance and check each other, such as with the electoral college in the USA and researchers, client teams, and validators on Ethereum.
If a proposal goes up and passes the vote, that’s it. It’s a simple democracy which can lead to mob rule (that’s what it is now).
Imagine, just as one hypothetical example, that node operators had the ability or duty to also approve all replica updates, or perhaps the power to veto.
Again I don’t want to derail the thread, but I agree that we need more diverse groups with different incentives and viewpoints to create appropriate checks and balances within the system.
The NNS right now is just a simple majority-takes-all democracy, and I don’t think it’s sophisticated enough to achieve our vision of a secure and stable world computer.
@lastmjs my understanding is that the NNS can only work from a code perspective with simple majority rule.
Are you suggesting building off chain voting norms and structures to supplement the on chain voting or are you suggesting somehow adjusting the way the NNS actually approves proposals from a technical standpoint?
There is a fundamental difference here. One is about how we operate as people and another is how the code governs the IC. Hope that distinction is clear.
I can’t really know for sure unless I was put under the same stress, but I hope I would advocate in exactly the same way I’m advocating now.
Boot up the project again, port all of the IIs, learn from the mistakes and never do it again. If the IIs can’t be ported, perhaps seek a remedy at the II level since that’s at the application layer controlled by the NNS, and I find that less harmful/less precedent-setting than a replica change.
I would seek every way to stop this from happening again, and I think portable IIs or other auth systems that allow users to port to another version of the app would be the way to go.
I don’t think so. The NNS could be programmed to enforce that a proposal can never be passed by one neuron, regardless of the voting power. I don’t see why it couldn’t enforce a minimum neuron count with a minimum percentage of voting power per neuron to pass a proposal. Add ZK identities in the future and perhaps we get to a better one-person-one-vote combined with quadratic/logarithmic voting situation.
For example, for any proposal to pass, no fewer than 5 neurons must cast a vote and no individual neuron can contribute more than 1% of the voting power. Just a simple example.
We talk so much about deterministic decentralization at the subnet level, but don’t apply it to voting at all!
I believe the II could be changed such that if the derivation origin is the old taggr canister Id that it hits a hardcoded list of ii-alternative-origins and all II accounts for taggr are recoverable.
If true, seems a much better solution without a dangerous precedent. Even if II canisters must be changed, seems a better choice.
But perhaps we can generalize the solution so that all apps can have this capability.
Imagine the II canisters are changed to allow applications to setup alternate domains for these types of situations with legacy apps, and it takes a proposals or something to add them in.
