If IC never claim node’s state data is private, why keep the data in secret but not allow the community to sync it?
1 Like
Well, Dfinity started this forum post to ask whether we (users) want that some subnets expose the block data. So, I don’t think is a secret but a non implemented feature and they want to know how important is this feature for us (users) so they can assign a development priority
1 Like
Hey everybody! Let’s please try to keep this thread on topic: do you want public subnets or not, should the NNS subnet be public, and please share if you have any ideas about how concretely you’d want this to work.
We are drafting a motion proposal to make the the NNS blockchain public that we hope to share here tomorrow, and then we can also get a better sense of what the voters really want.
4 Likes
I have a question about NNS subnet being public: would past NNS transaction data be available or just future NNS transaction data after the hypothetical approval/implementation/deployment of this functionality?
1 Like
Isn’t that already kind of planned? “Publish NNS blocks” is on Dfinity’s roadmap.
It is… I think @Manu is asking for feedback to make sure team is not on the wrong path (healthy as things evolve IMO). They are also trying to assess the urgency relative to other projects so feedback like this is helpful.
2 Likes
The topic of the thread is discussing “public subnets”, not just the NNS one. However, I will quickly deal with the NNS subnet first, per your request.
I think there is already widespread agreement to make the NNS subnet public. Without this, there can be no public verifiability of core blockchain activity, such as ICP transfers, neuron balances, BTC/ETH transfers on the IC, etc. Moreover, DEFI on the IC cannot reasonably become mainstream without this transparency. To be more concrete, I would want to see blockchain-tracking websites like https://bitquery.io/ have an easy way to include ICP in their database of blockchain activity. That way, anyone could see what is happening to ICP on the public NNS subnet without any programming skills.
As for other subnets, I think DFINITY really needs to acknowledge a couple of major contradictions that cannot ever be resolved, which I was not previously aware of until this thread:
- That there is a fundamental contradiction between private data and blockchain transparency/verifiability, and
- That it is generally not viable for the IC to run any B2B (or “enterprise”) software applications without exposing private individual or organizational data to an unacceptable extent, at least from the perspective of most companies today.
For the latter, cybersecurity measures like firewalls and VPN tunnels in a Web2 world serve to keep decrypted data secure as it is processed behind a web server. With any Web3 solution (not just from the IC) that discards these Web2 cybersecurity measures, data is no longer safe when it is processed in decrypted format on an IC node. That means all sensitive data like regulated Personally Identifiable Information (“PII”) must be decrypted only on a client device (e.g., phone or laptop), never on a Web3 server. To help you understand this logic, just keep in mind that this is why both hardware and software wallet private keys must only be accessible via authorized client-controlled devices, never via a public server.
As a result of this fundamental restriction imposed by all blockchain technology, this makes all server-based applications on the IC nonviable if they contain any sensitive data. This would explain why we see no ERP applications, CRM applications, healthcare applications, etc. as projects being built on the IC. We see only B2C applications (e.g., personal banking on a client device) or server-based applications containing nonsensitive data (e.g., social media, gaming, etc.). Please correct me if I’m mistaken here, since this is quite a stunning point if true.
All of these limitations on public vs. private subnets get at the heart of the entire “World Computer” marketing message by DFINITY and how their Web3 vision can replace all cybersecurity costs in our Web2 world. As @bitbruce and @Astrapolis-peasant convinced me, I think this radically open internet vision is basically a fantasy, at least under the premise of a world where we still care so fanatically about our “private data”.
Perhaps in a future world where there is dramatically less concentration of corporate and political power to abuse this private data, we might not be so (justifiably) fanatical about what must remain “private”. Unfortunately, that future world is not coming anytime soon, even though I still plan to do my part to help make that world happen. All of this is of course much bigger than just a criticism of the IC. It is a criticism of the entire Web3 vision being based entirely on a decentralization of infrastructure. A true Web3 vision needs to be far broader to include a radical decentralization of organizational and social power as well, which is what I am personally focused upon.
3 Likes
The thing that attracted me to the IC at first was the privacy aspect. While I do see the benefit public subnets could bring for transparency; an audited DApp with an event stream (like the ledger) gives the same level of confidence. Personally, I wouldn’t want this prioritized, and if all subnets went public it would be a dealbreaker.
3 Likes
I guess it’s not the exact same level of confidence because in that scenario you wouldn’t be able to tell if the subnet itself was malfunctioning.
But that has never been there in the first place, has it?
We are trading the fake guarantee of privacy that’s based on the assumption node providers will never read/share subnet data for dApp and subnet verifiability.
On top of it the apparent privacy offered by the protocol disappears and it becomes more evident it’s up to the devs to guarantee safery for their dApps data, which is something they should do regardless. I see this as an absolute win.
1 Like
To me there is a huge difference between everything being publicly available all the time vs. data maybe being snooped on by node providers / boundary nodes. Yes, if you need absolute true privacy data will need to be encrypted. But, I think for many applications the current configuration offers a decent-enough level of pseudo-privacy.
To be clear. I do think adding public subnets would be a useful thing. But, I think only having public subnets would be a bad decremental to the ecosystem.
2 Likes
Yes. Such a thing has never existed from the beginning, and there will never be secure protection of unencrypted private data on IC. It’s not a technical problem, it’s a basic logic problem.
Everyone must understand that all data in Canister is public, just like it is placed on the square.
But I now wonder if the product managers on the Dfinity team think so?
The underlying logic of blockchain technology dictates that Web2 applications cannot simply be built on top of IC. Of course, Web2 can be transformed into a decentralized implementation of Web3 before it can be built on IC. This has a lot of work to do, and it’s not that easy.
I think the dfinity team needs to show professionalism and encryption in their outreach and needs to correct those misconceptions.
NNS subnet data disclosure is just the beginning, we need IC subnet data to be public by default.
I would say it’s more than just “not that easy” - it’s seemingly impossible on any blockchain without actually integrating Web2 firewalls and secure networks around each Web3 node. This, in turn, may imply that each Web3 node would have to be dedicated to a single enterprise to keep the private data secure as it is being processed in an unavoidably decrypted manner behind a Web3 boundary node. A model of “one Web3 node per enterprise” would of course defeat the purpose of a shared blockchain on every IC node. Kubernetes or some other solution might get around this issue of sharing the same node securely by independent enterprises, but that is more Web2 tech to distribute computing power.
Moreover, integrating Web2 firewalls into Web3 likely would create huge cybersecurity inefficiencies vs. Web2. Instead of one firewalled network per enterprise, there would be many replicated networks, across different locations and geographical regions too. Cybersecurity costs for B2B Web3 applications could thus be significantly higher than the already outrageous cybersecurity costs under Web2.
I definitely agree that the DFINITY team needs to correct these misconceptions, or to correct us if we are somehow wrong. The reality for enterprise applications is extremely different from the “World Computer” marketing message of replacing the entire Web2 IT stack.
1 Like
Why doesn’t SEV solve this? Compute a secure key share in your node enclaves, distribute the share, Get a key from the enclave, encrypt your data before you send it to the ic with that key, let the enclaves decrypt and process over the data and return secure results. My understanding was this was on the road map and I anticipaite being the key to enterprise adoption.
I think not exposing sub net blocks leads to gate keeping and a lot of the defensive positions we see on the IC where groups hand wave open and decentralized but don’t ever actual expose their code. Not your code, not your tokens. If we could see the wasms of everything being shipped to the ic in the blocks we could have all kinds of reverse compiler and such that would be a forcing mechanism on people opening up more. Like on ethereum you’d be able to just grab a wasm and deploy even if you didn’t know exactly wat it was doing.
SEV does not solve the privacy and security problem on the blockchain. This is because it has a presupposition that AMD is trusted and that the node providers who install and configure SEV are trusted. But their trustworthiness is based on self-certification, and you can’t do public verification.
Let me ask you, can you be sure that the chip used by the node is AMD’s published chip? Can you be sure that the firmware the SEV is running has not been modified? Can you be sure that SEV is really installed on the node or not, and if they give you a certified result (e.g. a signature), can you be sure that it must be true?
They’re addressing the trustless mechanism with a scheme that requires trust. This is ridiculous. The manager who introduced that scheme should be replaced.
Of course, this may be needed in some scenarios where pseudo-privacy is needed, as SEV raises the cost of leakage and can provide some level of protection for data that has little value.
Without opening up the subnet data, wasm is also public, just a little less public. All nodes in the subnet are aware of this wasm. There are no secrets on IC.
Nodes have the potential to be bad guys. Public users have the potential to be bad guys.
Why do you just trust the nodes and not the public users? Conversely, you can’t trust the nodes if you don’t trust the public users.
1 Like
So, may I ask the Dfinity team, do you want IC to be a blockchain, or to be another Amazon?
Logically, the two are in conflict. Probably you will choose part of the subnet to be a blockchain and part of the subnet to be another Amazon. This may bring new issues, for example in terms of cross-subnet calls.
3 Likes
Node = Bad guys => Penalty paid
That’s a risk that would always exist; but there are solutions to that.
Bad guys always run out of ammo 
At the consensus level.
If there are 9 colluding bad guys out of 13 nodes, they don’t have to pay a penalty, and the other 4 honest nodes need to pay a penalty.
If the data is not public, we can’t verify it, we can’t detect these bad guys, and they have only benefits and no costs.
Solution: Make the subnet data publicly verifiable.
At the data level.
If you send non-encrypted private data to a node, any node can leak it, he doesn’t violate the rules, and he doesn’t have to pay a penalty. You can’t even prove who leaked the data.
Solution: Dapp should not store any private data on the IC (if you want to do so, you need to encrypt it before sending).
5 Likes