They why can’t the 9bad nodes make the data public ?
I’m guessing because they need the 4 honest nodes.
But we need all nodes to be honest.
The way I see it is; encrypt data on end user.
Then decrypt is on end user.
Nodes should just be a vessel of transfer.
Keep Privacy intact.
NNS is the most fundamental part. Really glad that Dfinity is move forward. Then SNS and Bitcoin subnets.
My understanding is that there have been significant gains in chips and algo being able to certify these things. Not an expert on sev here, but I do know that corporates accept a bit of risk in exchange for profit in all that they do and it “seems” that the current version of dev may have passed that threshold for this use case, especially in a scenario where the node providers are kyc’d and doxed.
Agreed. There is no need for Web3 enthusiasts to get fanatical in their marketing message about replacing the entire Web2 IT stack. Just like we would always want to retain strong security over the centralized private data on our non-replicated phone or non-replicated laptop in a pure Web3 world, there is nothing wrong with retaining some Web2 capabilities on the back end too, like centralized, secure databases behind a firewall. Those capabilities are truly needed for certain use cases (e.g., for enterprise B2B applications and private organizational data shared by a large organization).
The same logic can be applied to Web1, which has never been completely replaced either and still thrives for many use cases. Web2 just refers to a new Internet architecture that became dominant over Web1. Likewise, Web3 will likely just dominate - but never completely replace - the still dominant Web2 architecture. Web2 and Web3 just represent successive new layers of an evolving original Internet, not upgrades to an obsolete version of the Internet.
That said, it could still be possible for a community or DAO to go 100% Web3 on the IC if they are absolutely determined and don’t really care that much about their PII, health records, salary, etc. being publicly accessible to some extent without any firewall security as this data is processed. In a future world with far less concentration of power to abuse private data, and where people are not afraid to be authentic and transparent with strangers, I might even be one of those people too.
However, until then, the IC should be able to integrate with secure, Web2 centralized databases when absolutely needed. Enterprise-scale database technology has taken decades to develop and fine tune. So why would the IC community want to reinvent this wheel on its blockchain when the data stored on the IC can’t even be as secure (from unauthorized access) as it currently is in a Web2 hosting environment like AWS?
That logic can work for B2C applications, but not really for B2B applications like ERP, CRM, BI, etc. where unencrypted organizational data must be processed by an enterprise web application (running on those nodes), which would have no firewall protection in a pure Web3 world. Again, this is not a problem specific to just the IC. No blockchain has a solution to this fundamental contradiction between blockchain transparency and private data.
Interesting discussions here on the privacy of data stored in canisters, which I agree isn’t very private at all. IMO, any data stored by a canister should be considered as publicly available from a security point of view.
And I think that’s exactly why the proposal of public subnets makes sense. Currently, we have the worst of both worlds: we can’t rely on a subnet to keep its data private, yet we can’t verify its correct execution either. By making the blockchain public, at least we can do the latter.
To handle private data on the IC, please have a look at the proposed threshold key derivation feature. It can’t address all use cases, in particular not those that require canister-side computation on encrypted data (for that you will need advanced and much less efficient techniques like fully homomorphic encryption), but it does open a wide spectrum of B2B applications that simply route pieces of encrypted data that only get decrypted on the user’s side.
12 Likes
Your issue seems to be that you don’t trust blockchain consensus, and that is the bigger issue.
This is the basic assumption of the blockchain. You don’t have to trust consensus completely, so we need blockchain data to be transparent and everyone can verify it. Because of data transparency, node conspiracy to cheat can be easily detected, and the blockchain asset may go to zero, which is costly. On the balance of interests, nodes usually cannot conspire to cheat, which achieves the effect of “trustworthiness”. This is an effect driven by data transparency and interest, not because I trust them. The same is true for the assumptions of economics.
In short: trustless – balance of interests – produces a trustworthy effect. This all comes from the fact that blockchain data is transparent.
1 Like
Thank you for your clarification, when you say currently, do you think that in the future IC will be able to have the best of both worlds?
1 Like
I would like to point out a few things.
To begin with, I agree that strictly from a security point of view, data stored by a canister should be considered public (because a malicious or hacked node operator can, with some effort, expose it). However, there are a few finer points that I believe should be considered:
- It does not automatically follow from the above that all subnets’ blockchains must be public.
- As Hazel pointed out, for some applications there is value in “pseudo-private” data.
- SEV may provide full privacy. Or just significantly better “pseudo-privacy”.
- Data in a subnet’s state (i.e. in a canister heap/stable memory) may be removed. It may not be removed from a blockchain. Again, some applications may be perfectly happy with that level of privacy.
Second, as long as at least one honest replica is present on a subnet, it is possible to detect even a malicious supermajority. An honest node would diverge from a malicious majority. DFINITY takes state divergence (one node diverging from the rest of the subnet) very seriously (mostly in order to detect non-determinism bugs). To my knowledge, we have investigated all such occurrences since Genesis. There is no reason to believe that, once a more decentralized operations model is set up (where it’s not only DFINITY keeping an eye on replica operation), one cannot continue the same approach. (FWIW, replica divergence is very rare. It only happened a handful of times since Genesis. And it was always determined to be due to bugs, that were then immediately fixed.)
Third, applications that require high tamper resistance would also be deployed on subnets with higher replication. Even if replica divergence was not investigated, you would need to get significantly more than 9 (likely mostly independent) entities to collude in order to turn such a subnet malicious. And they would need to very closely synchronize their attack in order to prevent the subnet from stalling. Not impossible, just more defense in depth.
Fourth, IC blocks are usually small (particularly when not much update traffic is going on), but they can be up to 4 MB (and we are considering ways of making that “up to 4 MB of message hashes; with message payloads on the side”). Per second. Per subnet. Meaning that publicly exposing subnet blockchains is by far not the same as retaining all of them forever (as is e.g. the case with Bitcoin or Ethereum). And one of the reasons why node hardware is standardized is that, at full tilt, you need serious CPU; memory/storage capacity and throughput; and network bandwidth; in order to keep up with a subnet. At which point, what exactly is the difference between having a subnet’s last N blocks and adding one more replica to the subnet? (A replica that doesn’t even need to take part in the consensus algorithm in order to verify correctness. And, obviously, a replica that you trust more than the existing ones.)
Edit: Fifth, what exactly would be the difference between the IC and some distributed storage network (say, IPFS) if all one expects from canisters is to store encrypted data and hand it back to clients on request?
7 Likes
I agree with the previous part of the statement.
You can’t throw away the most valuable things of blockchain just to be “different”.
The biggest difference between WEB2 and WEB3 is that
WEB2: Users must trust the product/service provider to use the product.
WEB3: Users can use the product even if they don’t trust the product/service provider.
1 Like
If I’m reading this correctly, you seem to be saying that for you, IPFS provides all that you expect from Web3. Then why not stick with IPFS?
I’m not referring specifically to IPFS. i’m referring to the most valuable thing about the blockchain.
The choosing of IC was a trade-off, but based on an assumption that IC will have open data subnets later. If IC never opens up the subnet data, we will leave.
1 Like
Ability to compute the data on chain using the same tech stack would be one, but generally speaking if the only difference between IPFS and ICP is the pseudo privacy, then IC value proposition should be reconsidered.
I was not arguing that there is no value in opening up subnet blockchains. I was also (by far) not arguing that pseudo-privacy is the only value proposition of the IC.
I was merely arguing against a few specific points that were raised in this thread. Namely:
- The need for every single subnet to publish their blocks (and the argument that there is no value in subnets whose blockchains are pseudo-private).
- The impossibility of detecting a malicious supermajority in the absence of a public blockchain.
- It being easy to hijack a subnet that is set up to be highly tamper resistant.
- The expectation that simply publishing most subnets’ blockchains is somehow a magic bullet and will automatically give you the same properties that Bitcoin and Ethereum do (hint: there is a good reason why Ethereum transactions and storage are as expensive as they are).
- Dumbing down the IC to the point where all it does is store data encrypted by end users.
There is a lot more to the IC (and Web3) than verifiability by means of a public blockchain that is persisted forever (scalability, cost, efficiency, on-chain governance, including protocol evolution; variety; decentralization; direct integration with Web2 and other blockchains; and so on, and so forth). If all you need is a persisted public blockchain plus scripting, then there are literally tens if not hundreds of Ethereum copycat networks. And there is of course Ethereum.
Again, still not arguing against subnets with public blockchains (and particularly the NNS subnet). Only against claims that blockchains and blockchain networks cannot possibly be useful outside of the very narrow spectrum where virtually all other public blockchains in existence are fighting it out.
9 Likes
Question here, how does Dfinity prove that they are sure about the super majority of the nodes are not cheating without revealing their data? Through Zero Knowledge? I haven’t seen much talking with it. I know Dfinity can monitor it but to just to make sure Dfinity is a main contributor to IC not a corporate and IC is a public blockchain. The due diligence doesn’t convince me
The above is a very good indication that either no nodes are malicious or every single node is malicious.
Since only DFINITY currently has access to the raw metrics (some aggregated metrics are publicly available via the public dashboard API), the above is not exactly a proof. But there is no technical barrier to opening up the metrics. Or to setting up a more decentralized operations model, where not only DFINITY would have access to metrics, logs and debugging. As most everything else, it merely requires a lot of work.
1 Like
So we basically have to fully TRUST Dfinity to ensure that nodes are not malfunctional. Hope that part can be solved soon……
Yes, I too hope that every single feature that the community requests can be “solved soon”.
And expect to be laughed at throughout for attempting to build something more complex than a replicated state machine backed by a public blockchain.
While trying to remember that attempting to bring considered arguments to a flame war merely provides more fuel…
2 Likes