Discussion: public subnets

Hi everybody! We are starting this thread to discuss a new idea: public subnets.

Currently, the state of a subnet and all subnet inputs (like ingress or cross-net messages) are not exposed to the public. While it’s not always desirable that an application state can be freely inspected by the public, it provides advantages as well. For example, opening the underlying subnet blockchain and its replicated state would allow anybody to build blockchain explorers similar to Etherscan, providing all the technical information about block contents together with the cryptographic signatures, so that anybody can cryptographically verify all state transitions of such a public subnet.

We could consider introducing a new subnet type (or “predicate”) that says whether the subnet is public or not and leave the choice to canister developers if they want to deploy their canisters to such a public subnet. E.g. DeFi and NFT dapps could benefit from running on public subnets, as it would make their internal ledgers completely transparent and auditable.

This idea is clearly not fully baked yet, but we’d be very happy to discuss this on the forum. Some initial questions that we’d like to discuss:

  1. Do you think introducing the notion of public subnets is a valuable addition to the Internet Computer?
  2. Do you think the NNS subnet (tbd26) should be a public subnet? (This would make the state of all neurons public, including the controller principal and the accrued maturity.)
  3. How would you want this to work? What would you want to do with the state of public subnets?

Looking forward to the discussion! @christian, @bjoern and I will try to participate in the discussion from DFINITY’s side.

30 Likes

Within an era in which the defiance is becoming massive – given what is happening in the crypto ecosystem – such an idea is great : the more people know they can inspect, the better is.

5 Likes

I can see many developers valuing privacy, and explicitly choosing private subnets for that reason.

Similarly, I can see value in being able to view all of the blocks for a subnet. And I think some developers would pick public subnets specifically for this reason: transparency, trust, openness, etc.

No well-thought-out opinion about the NNS subnet. I can see arguments for both ways.

In Toniq products, I could see us allowing users to choose where to deploy their canisters. On the one hand, you can have privacy, passwords, secure data. On the other hand you can have openness, transparency, verifiability (perhaps).

Overall feels interesting.

2 Likes

Why not make all subnet inputs/outputs public? What’s the downside?

They should all be public. I think we’re a ways from that(we need AMD-SEV or other multiparty compute for private data storage), but as long as we have private subnets we’ll keep having the pull and financial incentive to obscure the things that, when visible, demand integrity, fair dealing, and the public good.

Having the option would be amazing. Convincing everyone to pay attention to the choices they are making and where they are allowing their assets to flow is a harder challenge. Maybe something like fiduciary subnets would be good to consider here? If it isn’t public then certain assets can be flagged as not allowed to flow there and not allowed to have access to features like t-ecdsa that require high levels of trust.

6 Likes

Are there known technical tradeoffs like performance?

1 Like

Public subnets would be great as long as some data can be encrypted. File drives for example.

If we’ll have aggregators for the internal DeFi/NFT ledgers, then we’ll also need a standard for those data structures.

Lack of privacy. I think having the flexibility of making everything inspectable or not would be a strength for the internet computer.

Opaque centralized custodial financial institutions like FTX destroyed whatever trust was remaining in the crypto space. Going forward the crypto ecosystem will rightfully place even greater importance on Transparency and Auditability for any on-chain financial services.

It’s highly unlikely DeFi on the IC would flourish without complete auditability and transparency of canisters running DeFi applications on the IC. If public subnets will provide this transparency necessary for application code to be verified publicly than I think it is important for the success of DeFI on the IC.

2 Likes

It’s a no brainer for DeFi and should be a high priority. Would love to keep the capability of doing both public and private subnets. Who knows, maybe in the future we’ll see all kind of subnets such as GPU, storage, AI and so on.

1 Like

I don’t think you have to have public subnets to verify DeFi on the IC. On a private subnet the application itself can expose transactions and proofs.

2 Likes

Appreciate all the feedback so far!

If we would want to enable anybody to recompute and fully validate all computation, then even with AMD SEV we would not get any confidentiality of data. AMD SEV would still help improve the integrity of course.

I see it the same way as @Sormarler: many software applications today don’t want all of the data to be public. If we would want a large fraction of the software of the world to run on the IC, we have to take that into consideration, I think strictly enforcing that everything be public would be limiting the use cases of the IC.

No performance impact. I think the only tradeoff is privacy vs transparency and verifiability.

4 Likes

Yes! This would be great to have!

1 Like

I’m not sure a binary public or private is the best solution. I believe it’s preferable to be able to customize at a granular level which components on an application and its surrounding stack are private and which are public.

For example, a finance application may want some information to be public, for example a decentralized exchange that can prove its solvency. But that same decentralized exchange may want to keep individual balances completely private, but maybe organization balances (like companies, government entities, etc) public.

A course public/private subnet choice I don’t believe to be ideal for every use case, but I can see benefits.

8 Likes

It would be helpful if you could link to the Rust structs in the IC codebase containing the data that would be made public, namely the subnet state. I’d like to take a look at the actual fields that would be made public.

Isn’t the implication that there is private data about of a handwave? A node provider could capture and publish this info at any time. Unless the inputs are encrypted you’d see all the data in the transaction logs.

2 Likes

Why couldn’t we simply encrypt everything on a public subnet to preserve privacy?

2 Likes

True, but there’s value in having that by default. You don’t need yet another level of standardization in the ecosystem to make use of this data. I think it would be a huge benefit if services like Dune and DappRadar would be able to integrate (at least parts of) the IC.

3 Likes

I think having the option is good. Transparency and privacy are both import important.

I can see how public subnets could simplify things for users but it could also create misunderstandings. For example; a canister on a public subnet may encrypt its data, and a canister on a private subnet may not.

If the NNS subnet were to become a public subnet, does that raise any concerns about privacy or change things significantly for people who have already locked up their ICP?

There’s been feedback on other proposed ideas that involve changes being made after people have already committed, confidence for people doing that in the future, etc.