Introducing the first "fiduciary" subnet

We are happy to announce that users will soon be able to create canisters on the larger subnet that was created a couple weeks ago. The subnet will be assigned to the “fiduciary” subnet type which users can choose in dfx when they’re creating their canisters, see the docs for more details. Canisters running on this larger subnet will pay more cycles compared to canisters running on the existing 13-node subnets but in return they will get more security due to the bigger subnet size. The costs scale linearly to the number of nodes, for more details please see here.

There are going to be two proposals submitted today that will enable access to this new “fiduciary” subnet. We will provide updates on the progress in the thread.

19 Likes

Is it possible to “move” to this subnet and maintain the canister ID? We would like better security for the OGY token canister and would consider moving once we have a better idea of the costs.

3 Likes

Not at the moment. What you’re asking for is essentially canister migration which is not widely available yet – we did a very special one-off migration of II if you recall and the team is working on generalizing that but we’re not there yet.

If you don’t want to wait, your best bet would be to create a new canister on this subnet and then do an overhaul of your data manually and redirect traffic to the new canister.

2 Likes

After proposals 98206 and 98227, the first fiduciary subnet is now open to the public!

4 Likes

Glad to see the fiduciary subnet going live.

A couple of things I don’t understand:

Why was it decided to do 28 nodes instead of capping it at roughly the number of independent node providers of the subnet, 19?

Alternatively, since there appear to be more than 19 independent node providers in the IC, why is the fiduciary subnet not administered by 28 independent providers (I think there are more than 28 in total in the IC?) so as to maximise the security improvement?

Hey @blabagastered, I’m not sure where exactly you saw that the fiduciary subnet has 36 nodes but if you look at the internet computer dashboard link that I included in the original post, the number of nodes for this subnet is 28.

The number of nodes providers on the IC is indeed limited at the moment and that limits our ability to create an even larger fiduciary subnet at this point (or at least one that would actually be more secure than the current 28-node subnet). There’s ongoing work in further decentralizing the IC and specifically adding more independent node providers, for more details this thread would be useful. With more independent node providers, I believe we could create even bigger fiduciary subnets in the future with even stronger security guarantees.

2 Likes

Not sure where I read 36 either.

In that case the questions are the same but with 28 instead of 36 in them (now edited).

Why not use 28 independent providers, or alternatively why not use as many nodes as there are independent providers in the subnet (19 on dashboard)?

I seem to have gotten 36 from the docs linked above here (actually 34, and only an example):

https://internetcomputer.org/docs/current/developer-docs/deploy/computation-and-storage-costs/

1 Like

Using more nodes from even the same providers can provide some better resistance against certain types of attacks. For example, certain node providers have nodes in different physical locations. In this sense, we’re still better off than having fewer nodes as one would need to gain access to a larger number of physical nodes to compromise the subnet.

Of course, if you’re worried about other types of attacks, like node providers colluding to take over the subnet, then indeed the number of independent node providers is more important. As I mentioned in my previous reply, the team is working on onboarding more providers and as we get more of them, we can always update the membership of nodes for this subnet to make it more decentralized and even more robust.

Hopefully 28 independent providers jump in soon. When people look at the IC to establish whether it can secure e.g. a billion in bitcoin, they will ask themselves how many people need to collude to take the billion, and the number is now 19 x 2/3 = ~13.

With 28 independent providers it would be ~19.

Anything that increases the (credibility of the) security of IC’s Defi is probably of strategic importance in coming months.

Rooting for security improvements, past and future.

2 Likes

I’m surprised a project like OGY hasn’t blackholed the canister

We are working on V2 of our governance canister that will have call_raw and the ability for the DAO to upgrade canisters. At that point, we won’t be ‘blackholed’ but will be controlled by the DAO canister only(similar to the NNS).

When the current version was rolled out call_raw wasn’t in the motoko cdk yet so we didn’t have much choice in the matter if we wanted to be able to upgrade.

Interesting take. I understand your not so much concerned with token price action but don’t you think OGY should have some sort of preventative measures to keep token mints from occurring? There are meme tokens on the ic that are able to do this with a natural community. See:

Candid: DFINITY Canister Candid UI

ICScan: ICSCAN

ICLighthouse: ICHouse - Dfinity ICP & Tokens Explorer

OGY mah directly financially benefit the foundation but I’m not certain what it’s purpose is in even maintaining. The new goal is what? Validating luxury used products as legitimate?

es3he-kyaaa-aaaah-abzna-cai

standard: DIP20

Here’s the canister I’m referencing.

I feel like the foundation is very concerned with DAO projects when there are much more interesting things that could be done, see Accept a web2 third party auth + web2 payment - #10 by PablosOne type things. I know the canister I referenced is Crass but they managed to burn tokens and lock their canister. In turn people are active in there community. What Purpose does OGY token serve?

OGY is our utility token. It will be used for minting certificates on the network and for staking in our ecosystem. Currently, it gives you governance rights over the platform as well.

Is there a way to deploy to a fiduciary subnet ?

answered over here

2 Likes

Why was the fiduciary subnet created? I would like to know the background. Frankly, I do not know how many nodes there should be. I think that I need a trust to governance.
Are most people of the opinion that 13 is not enough? Also, is there a plan to transfer from 13 to 28 ? Cost is also a very important concern.

Why was the fiduciary subnet created? I would like to know the background

The fiduciary subnet was created to enable safer deployment of DeFi applications which need even stronger guarantees than the ones that someone gets from the regular 13-node subnets. Increasing the number of nodes is generally adding extra security since more nodes need to be malicious in order to take over the subnet. Now, there’s also an aspect of geographic location or if the nodes belong to the same (or a small set of a few) node providers. At the moment, not all 28 nodes come from different node providers because we still don’t have that many. We’re working on adding more independent node providers and then we can replace some of the existing nodes on the fiduciary subnet to get even more decentralization.

Frankly, I do not know how many nodes there should be

Yeah, this is a tough question. As I alluded above, number itself is also not a silver bullet. For example, having 28 nodes from 3 providers is clearly less decentralized from having 13 nodes from 13 providers. The idea is to increase the decentralization of the fiduciary subnet even more (either by adding more independent node providers or adding more nodes or combination thereof). Also, in general, we would like to get to bigger subnets in the future but for that we also need to have some protocol enhancements to be able to sustain a good finalization rate even with a lot more nodes distributed across the globe.

Also, is there a plan to transfer from 13 to 28 ? Cost is also a very important concern.

Good question. I think, for backwards compatibility, we would have to keep the existing 13 node subnets to avoid breaking dapps that expect certain costs. If you want to utilize the extra security of larger subnets, you’d have to explicitly migrate your dapps over to such subnets.

1 Like