True censorship-resistance by decentralizing neuron removal proposal type

Governance
1

TLDR let’s remove default following on the topic and methods that can remove/stop canisters and ensure the threshold for adoption is 50%. If DFINITY/ICA have less than 50% without default following then we have some real decentralization and censorship-resistance in the Internet Computer Protocol.

I just want to get this idea out there and start a discussion.

It’s been great to see the messy yet bolstering governance of the Internet Computer. In the not-too-distant past I was afraid no one would ever care about the Internet Computer, and it’s clear that we have a growing community of concerned citizens.

But our current direct influence as a community has essentially been over proposals of the governance topic, which when executed have no real effect on the provisioning of the Internet Computer Protocol. When adopted and executed, they simply tie DFINITY to a course of action that we take on their word alone, in addition to the social pressure coming from community consensus.

But the direct provisioning of the Internet Computer Protocol is still directly controlled by DFINITY/ICA based on my observations and understanding of the voting power DFINITY wields.

They have near 100% voting power when it comes to shutting down canisters. This isn’t censorship-resistant at all.

As discussed deeply in a previous incident, even though we are divided as a community to what exactly we should have done and should do in the future as it comes to censorship, I think we all agree that censorship should be more difficult than a unilateral decision from one organization. And it definitely should be more difficult to shut down a canister than it is now. If anyone disagrees with this, make it known.

Thus I propose that we remove default following on the governance topic and methods that allow canisters to be stopped or removed (I’ll need to look up the specific topic and methods). I also propose we increase or keep (not sure what it’s at now) the threshold for adoption on that topic and methods to 50%.

If I’m not mistaken, and I haven’t been paying close attention in the last couple weeks so correct me if I’m wrong, DFINITY has only been wielding ~25% voting power on the governance topic with default following disabled.

This would perhaps be the first thing we can do as a community to truly decentralize a major aspect of ICP governance and a major risk vector for many projects.

It’s a great first step to increase the censorship-resistance of the IC. Any canisters that are to be shut down would need broad community consensus, more than 50% voting power, and I feel we’re at a point now where we have a chance at some real decentralization here.

30 Likes
2

I am definitely onboard with improving censorship resistance. What you are proposing is a discussion worth having. As we move forward I would like to see the foundation having less and less power.

I’m glad we have community members like yourselves to bring up these issues.

3 Likes
3

I agree with your proposal, changing the protocol or shutting down canister should require much more voting power than 3%

8 Likes
4

Thanks for starting this conversation Jordan. I have a few preliminary thoughts…

I think this is a true statement. Basically, if Dfinity were to cast votes on any topic that falls under the All Topics Except Governance “catch all”, then there is an Absolute Majority of votes cast through liquid democracy (actually almost 100%). The only two topics that I know of where this is not true currently are Motion proposals (which have no code change as you mentioned) and Register Known Neuron proposals, both of which fall under Governance topics.

I think what you are trying to say here is that you think the rules of Absolute Majority should apply to proposal topics that enable removal of cannisters. That would require greater than 50% of total voting power in the NNS to vote Yes in order for it to happen. I don’t disagree, but this extremely difficult, if not impossible, based on current voter participation rates. I’ll explain more below.

This is true for governance motion proposals. Dfinity actually owns about 22% of total voting power in the NNS according to @diegop in this forum topic.

The best example we have at this time of decentralization of the IC is the Governance topic. The most votes ever cast on any governance proposal since proposal 34485 was implemented (by way of code changes in proposal 44974) is 46% of total voting power. We have reached a plateau at this level of participation with the current tokenomics incentives. Hence, it is not currently possible for a Governance proposal to result in Absolute Majority because the incentives have not moved us to that level of decentralization yet.

I think it is important to ask how we arrived at the current level of decentralization for governance proposals because it helps foreshadow what types of changes that would be needed to enable this proposal to succeed. It’s not just removal of default following for the specific topic. There are 3 events that are required:

  1. Removal of the topic from the All Topics “catch all” category
  2. Weighting of that type of proposal topic higher than all other forms of routine business
  3. People not following Dfinity on the proposal topic.

The first two events by themselves motivate a large portion of the governing body to re-configure their Followees for that topic. However, if the last event doesn’t happen it defeats the purpose of the first two events in regards to the decentralization objective you are describing.

I can think of only 4 reasons why people would not follow Dfinity on a specific proposal topic:

  1. Dfinity routinely abstains from voting on that topic (which they did on the Governance topic from genesis until late Feb 2022)
  2. Remove Dfinity as a named neuron in the NNS dApp
  3. Disallow other neurons from following Dfinity.
  4. People follow another neuron because they “believe” in decentralization.

Dfinity owns their votes and can use them however they choose. However, all other named neurons have to earn followers, which means there needs to be a reason why people would choose to follow a neuron other than Dfinity. So far reason 4 above has not proven to be a strong enough driver…or at least it’s not as strong as tokenomics incentives. Nevertheless, if people don’t follow neurons other than Dfinity then we won’t achieve decentralization.

I think you are bringing up a great point about what could be the next topic to move us further in the direction of decentralization, but it won’t happen if we don’t use the tokenomics to incentivize participation. Removing default following of this topic by itself won’t produce a measurable change. People need to be incentivized to change their Followee designations in a way that leads us to the highest voter participation possible and the highest degree of decentralization.

Edit: I also want to give credit where credit is due. All 3 events described above that I claim have moved us toward decentralized governance were orchestrated by Dfinity. They have stated since genesis that they want a decentralized governance system and they have pushed us in that direction, sometimes without the community recognizing that it is happening. Perhaps this proposal is a logical next step, but perhaps it is also too early. I just want to make sure we are being fair to Dfinity in the language we use because they have really done a lot to move us in the direction of decentralized governance.

4 Likes
5

I thought that default following on governance was already removed. Or are you proposing that following be removed as an option altogether, requiring manual voting on all governance issues? Sorry if I’m being dense but I just spent most of the day doing my taxes, lol.

6

Here, here. Seconded.

1 Like
7

I agree with the general idea, but I think it’s too early to do this.

DFINITY still relies on its followers to push through important and necessary changes quickly. Examples include upgrading the ICP ledger canister to enable ICP (Nov 2021), upgrading the Internet Identity canister to fix a bug (Jan 2022). Security-critical fixes don’t even get revealed until after they are rolled out. That wouldn’t be possible (provided the bug is in the canister code) without the followers they currently have.

At some point, it makes sense to do this, but right now I think speed of execution is still more important to the IC long-term. Perhaps we could make a carve out for NNS subnet canisters?

5 Likes
8

Hopefully @lastmjs will be able to soon verify what proposal topic this canister takedown concern would fall under. Based in the descriptions available to filter proposals in the dashboard, the most likely topic is System Canister Management. A quick review through all those proposals since genesis show that they are all NNS and Ledger canister proposals (upgrades and replacements) so far. I agree with your concern that those proposals would still need to execute quickly by way of absolute majority and liquid democracy. Perhaps what Jordan is suggesting is that takedown for canisters that are not part of core systems like NNS and Ledger canisters should be a separate proposal topic so it can be treated differently.

2 Likes
9

I think it’s reasonable that system canisters should not be a part of this proposal for now.

10

I’m taking a look through here right now: ic/governance.proto at master · dfinity/ic · GitHub

The function I am seeing that might be relevant: NNS_FUNCTION_UNINSTALL_CODE

An expert on the NNS code could hopefully help us out here. But from what I’m seeing it might be possible for a proposal of any topic to execute NNS functions, NNS_FUNCTION_UNINSTALL_CODE being just one of those functions.

NNS_FUNCTION_UNINSTALL_CODE is the function I am proposing we carefully guard against for now. DFINITY can unilaterally use it to take down any canister.

@jzxchiang notice that there are other functions NNS_FUNCTION_NNS_CANISTER_INSTALL, NNS_FUNCTION_NNS_CANISTER_UPGRADE, and NNS_FUNCTION_NNS_ROOT_UPGRADE that seem to control canisters in the NNS subnet. We can leave those out of this for now.

If someone can check my work that would be great.

2 Likes
11

“Remove the jar” is not the only risk, I think it should be designed like this: Other types of proposals cannot be implemented immediately even if they reach an “absolute majority”, and the motion proposal should have the power to suspend the implementation of other proposals.

12

I think it is brilliant to begin discussing the governing procedures for shutting down canisters. If the previous incident (back in late 2021) showed anything, it’s that censorship is a topic for which the community has a wide range of very strong opinions. It’s possible that censorship could be an existential risk to the Internet Computer governance if a specific instance of it tore the community apart. For that reason, it is wise to establish the rules around shutting down a canister prior to there being a reason to implement those rules. Thanks @lastmjs for starting this conversation.

A couple of considerations:

  • There may be technical or other non-censorship-related reasons to shut down a canister. We should most likely design a system where those use cases are exempt from the governing procedures around censorship-related canister shutdowns.
  • It would probably make sense to have a proposal topic dedicated to censorship-related proposals so that it can follow its own governing logic.
  • We should establish a mechanism for the NNS voters to identify and correct any proposal that the voters felt should have been placed in the censorship topic, but wasn’t. This might be a governance proposal.

Again, as a community, I hope we continue to think through the governing mechanisms and procedures we want in place for these types of proposals and codify them through an NNS governance proposal prior to the next censorship controversy.

3 Likes
13

A careful update to the NNS where, specifically, NNS function 19 - uninstalling canister code - requires more than 3% voting power in the case of a simple majority seems like an easy win to make censorship harder.

My thinking is this: basically any time dfinity votes on a canister takedown proposal, we’re likely in a simple majority situation since dfinity’s votes would most certainly constitute more than 50% of votes cast.

So we have two variables, % of votes cast and % of total voting power. I’d like to know how much of each dfinity commands, respectively? As long as we can make it so the community has a chance to sway the vote, we can classify the change as having moved us towards decentralization. In other words, we could require the % of votes cast and % of total voting power thresholds be slightly higher than dfinity commands in the case of NNS function 19 so the community has a legitimate chance to sway the vote.

We might also consider exposing these as sub-topics for neurons to follow… I would be interested to dedicate my voting power to a set of neurons that will specialize in canister take-downs.

1 Like
14

I think canister takedowns should be a rare occurence and only be used to remove canister with: malicious code that damages the IC, CP and illegal markets(drugs, weapons, etc…), everything else should be filtered by boundary nodes as proposed by Dfinity: Path forward on leveraging boundary nodes for content filtering

Immutability is one of the selling points for decentralized systems, but currently the IC is pretty lacking in this aspect in my opinion, considering there is the potential of lots of value being locked in the IC with upcoming DeFi and direct integrations, we should guarantee canisters can’t be taken down easily.

3 Likes