Censorship resistance in IC

General
1

I’m trying to understand the censorship resistance capability in IC. Let me know, whether my understanding is correct as presented below.

Boundary Nodes based Censorship:

Boundary Nodes are the nodes a request to IC reaches first. Boundary Nodes forward the request to the corresponding replica which processes the message. The code for running the boundary nodes is opensource and anybody can spin up their own boundary node using this code. Is this understanding correct?

So, if a takedown notice is given to a boundary node, it could filter/block the requests to the canister and follow the takedown notice. But, another entity could spin up their own boundary node allowing access to the canister again. This would be similar to what happens in the torrent world, where when one torrent listing domain goes down, something comes up few days later. In this way, we can say, IC is kind of censorship resistant.

Governance Based Censorship:

A governance proposal can be submitted proposing to takedown a canister and if the community agrees, then the canister will be taken down. This way, censorship is governed by the community.

So, if there is a takedown notice for a canister, 2 things can happen:

  • Community votes to takedown the canister and it gets taken out of the subnet
  • Community votes to keep the canister. So, the boundary node is forced to block the requests to the canister. But, another boundary can come up allowing access again, until they get the takedown notice and this can go on…
6 Likes
2

You are mostly correct, but for the time being it isn’t possible to run boundary nodes in a permissionless way.

2 Likes
3

Bigger problem is the takedown notice affects the replica nodes, and they can be forced (by law enforcement) to shut down their servers. They will lose alot of initial investment with no recourse if the community vote to remove a canister fails.