Discussion: public subnets

[Tbd]

@paulyoung

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.

Lol a bigger problem is if they think any of it is private

[paulyoung]

We could call them “public” and “not public”

[JaMarco]

@paulyoung

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.

Why is this a big deal? Where is it stated that IC protocol configurations will never change? Everyone that staked ICP knew that IC is governed by a DAO that regularly updates the protocol.

[paulyoung]

That’s how I see it, but not everyone feels that way.

[LucidSamuel]

I believe that giving users the choice of deciding whether sections or components of their dApps should be private or public is a great idea.

[Astrapolis-peasant]

All subnets should be public. Privacy should be ensured by the contracts nor the node providers

[bjoern]

Just to make sure I understand correctly: You have concerns about potentially changing the state of the NNS to be public, not about the core proposal which is creating new subnets that have public state, right?

[Manu]

@lastmjs

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.

The really cool thing about public subnets is the complete verifiability for anybody. This is very difficult to achieve when keeping some data hidden, so I don’t see a practical way to get both the complete verifiability AND have the option to keep some data private. I don’t think some ZKP approach is feasible for how much the IC can process.

@jzxchiang

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.

I don’t have a complete set of links, and I’m actually hoping to do some refactoring in the consensus types, but things like ic/rs/types/types/src/consensus.rs at master · dfinity/ic · GitHub and ic/rs/replicated_state/src/replicated_state.rs at master · dfinity/ic · GitHub. As I said, we don’t have a super concrete plan yet, so happy to hear what you think and if you think you could do something useful with this data.

@skilesare

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.

You’re right, but the question is more about verifiability. If we want the user to fully verify the blockchain and resulting replicated state, then the user needs to have access to this state. We could perhaps think of some way that if a user wants to verify the state it can only do so using an AMD SEV machine in an attempt to keep the state private, but I feel like that’s a pretty big sacrifice to verifiability.

@Mr_Burkes

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

How would that work exactly? Encrypt under which key? And if we give users only encrypted data that they can’t decrypt, they can’t actually verify the computation anymore right?

[paulyoung]

@bjoern

Just to make sure I understand correctly: You have concerns about potentially changing the state of the NNS to be public, not about the core proposal which is creating new subnets that have public state, right?

I wouldn’t say I personally have concerns about it but yes, this was in response to @Manu‘s question about potentially changing the NNS from private to public.

I imagine the average NNS user would want to understand what a change like that means for their privacy.

[bjoern]

Ok makes sense. But anyway I think it makes sense to discuss these things in two steps. I sense a lot of positive sentiment for having (at least some) public subnets. So that’s already good. And the NNS question probably has to be discussed in a broader context and with more explanation of the implications.

[Ang]

You can send a message to support@dfinity.org to help troubleshoot your issue.

[christian]

Hey everyone, quick update on that topic.

We discussed this initiative internally again and decided to not make it a priority for now given that the discussion didn’t reveal any immediate demand or interest for that feature from the side of the community.

We definitely stay open wrt. to this topic and will be ready to revisit it again once there’s more interest.

[Astrapolis-peasant]

There is a high demand from the community. Please help to make subnet blocks open

[Astrapolis-peasant]

Blocks are fundamental for blockchain. And developers should be able to choose private subnets and public subnets freely

[cymqqqq]

Agree with Astrapolis-peasant
There is a high demand from the community. Please help to make subnet blocks open.
We developers should be able to choose private subnets and public subnets freely.

[Manu]

@Astrapolis-peasant

There is a high demand from the community. Please help to make subnet blocks open

To be clear, @christian @bjoern and I started this topic because we actually think it would be a cool feature. Since there are many different things to work on, we try to listen to the community and pick the features that are most requested. Given the mixed feedback in this topic we had the impression that this is not a feature that the entire community is eagerly waiting for, and should therefore not get the top priority.

If you think there are many people actually requesting this, please let them voice it here on the forum, or you can consider submitting a motion proposal. I personally think it would be cool to make at least the NNS subnet a public blockchain that everybody can verify, so I would vote in favor.

[Astrapolis-peasant]

I personally think this is crucial, especially for DEFI applications. Otherwise, it would be hard to for the public to trust. For social applications, it’s not a big deal. But for the DEFI applications, we can then build the blockchain explorer to index the data. All statistic would be hard to implement without public subnets

[Zane]

@Manu

If you think there are many people actually requesting this, please let them voice it here on the forum, or you can consider submitting a motion proposal.

My anecdotal experience based on skimming through the forums and private chats makes me believe public subnets have widespread approval, a related motion proposal would almost certainly be approved, main point of contention would be whether to make NNS public or not and how the feature would be exactly implemented.

What we need to know to decide whether it should be a priority or not is having more details on how long it would take to implement and what would be pushed over as a result.

[bitbruce]

This is an important topic, and it was one of the factors in Dapps’ decision to choose ic blockchain.

The ICLighthouse team chose the IC blockchain on the premise that the node data of the IC subnet would be open in one form or another at a later date.
If this is our error in judgment and IC will never open the subnet data, we end up having to abandon the project at a tragic cost. Because we have a most fundamental value: the project has to be built on a blockchain, not on another Amazon.

Here are my views.

1. The basic essentials of blockchain are cryptography-based and publicly verifiable, because the prerequisite assumption condition here is that we are in an untrustworthy environment and we need trustless mechanisms. “Publicly verifiable” requires blockchain data to be public in a certain dimension, so that anyone can easily verify it.

2. Privacy protection and data openness do not absolutely conflict, and this cannot be a reason for not disclosing data. I acknowledge that there are some specific subnets that do have a need for non-disclosure of data (e.g. the subnet where II canister is located).

3. there is no logical technical barrier. If there is, there are many ways to solve it, such as edge nodes establishing layer 2 protocols.

4. Dfinity’s decision on this topic, and prioritization, can reflect the positioning and philosophy of the IC project. It is about where the ecology will eventually go.

@christian

[JaMarco]

@bitbruce

The basic essentials of blockchain are cryptography-based and publicly verifiable, because the prerequisite assumption condition here is that we are in an untrustworthy environment and we need trustless mechanisms. “Publicly verifiable” requires blockchain data to be public in a certain dimension, so that anyone can easily verify it.

But is it necessary for a dapp (including a dex) to be on a public subnet for it to be “publicly verifiable”?