It is indicating very clearly that there is NO technical barrier to open those metrics. If you consider that it is your priority, get to work on it. Dfinity as the largest contributor to the world computer has a lot of work to do on many fronts, but it gets where it can. I only see your the desire to put fud on your part and that doesn’t help
1 Like
What you are doing is going to set precedents in the history of technology. Do not listen to the non-constructive Fud. keep up the vision and the huge good work you do
1 Like
I feel like at one point it was proposed that independents might be able to run read only replicas to speed up query time for the off-chain parts of their applications…is that still on the agenda at some point?
It is definitely not out of question. I don’t know whether it is in anyone’s actual future plans.
Such replicas would be useful both as independent validators and as additional query handlers, to take load off of replicas that participate in consensus. So they would clearly be useful to have.
I think your points are awesome and I pretty much agree with @bitbruce’s position.
I think even @bitbruce is ok that we’re on the path to somewhere awesome, but we’ve all got to agree on the general vector of where we are going and I don’t think anyone here is arguing that we should never have public subnets. I assume that having some public subnets would meet @bitbruce’s criteria and that he might be inclined to have the apps that he support not trust private subnets as a security assumption. I would consider that to be a cogent approach depending on your risk profile.
At one point we had a fairly functioning plug in that would give you a red, yellow, green signal if the canister you were interacting with was 1. Open Sourced, 2. Verifable by Cover(A psycadelic thing that I guess is going away now). I could see something like that for if your sub net was public or not.
4 Likes
I guess they’d also make this debate a bit outdated as anyone would be able to set up a read-only replica and they’d be able to see all the ingress and state…so those would be defacto public.
3 Likes
I might be nitpicking but the 2 seems to contradict each other.
This is what I mainly disagree with, I don’t think all subnets being public would in any way dumb down the IC, quite the opposite in fact. Some might see pseudo-privacy as a feature but imo it’s a bad practice to rely on it.
I doubt any serious enterprise would be fine with it, especially considering it’s hard if not impossible to track down the leaker and even if it were, legal consequences are dubious and as a user I wouldn’t provide sensitive data to a service whose security guarantees are based on the hope a bad provider never gets into their subnet.
Plus as @skilesare said permissionless boundary nodes are on Dfinity roadmap as part of the decentralization process, especially in relation to canister censorship and that would get rid of the current psuedo privacy anyway.
Some folks in this discussion seem to think of privacy as a binary property: you either have it or don’t. From a practical perspective, that’s a totally bogus world view.
In reality, privacy, like security, is a spectrum. You can only increase or decrease the probability and cost of successful attacks. It all comes down to a tradeoff and a game of economics: you want to make attacks costly enough. There is no 100% protection.
Neither does reality enable such a thing as trustless computing. You have to trust your own hardware, its vendor, and the entire supply chain, much of which is coming from countries with questionable laws. Contemporary hardware has plenty of back doors, and the amount of phoning home that it can do (and does) before it even starts booting the OS is mind-boggling. The times where we were in full control of our own machines have passed at least 20 years ago. And obviously, blockchains don’t work with air gaps.
So some of the absolutist arguments in this thread just sound silly to me, especially when they argue against trusting node hardware vendors but completely ignore the hardware problem right in front of them.
15 Likes
Well said, @rossberg. This is definitely a good thought to keep in mind. The technical term for such an absolutist position would be a “false dichotomy fallacy”. I still don’t think the IC is anywhere near being ready for enterprise B2B applications in terms of privacy and database capabilities, but it doesn’t necessarily have to be in order to still be very successful.
I don’t think we were quite in a “flame war” yet on this thread, but I could see it looking that way from your perspective. At any rate, I sincerely want to thank you and @gregory for stepping into this discussion to cool down some of those flames. I definitely don’t think the flames are increasing, as you may have feared.
Yes, it’s an economic concept. The effect of any protection comes from the fact that the cost of his attack is greater than the benefit.
There are two aspects of security.
(1) data privacy security. One path is that it relies on cryptographic encryption and does not rely on any hardware or node provider. The benefit of this approach is that it is secure enough, the drawback is that it limits the development of Dapp, which must be massively refactored. The other path is that it relies on hardware and node provider security measures, like AWS. the benefit of this approach is that it protects low-value data (because the cost of attack is higher than the benefit), but in the face of high-value data, hardware and node providers still have many paths to steal data because the benefit is much greater than the cost of attack. btc and ETH have chosen the former, and IC is choosing the latter, depending on which application scenarios take precedence.
(2) Consensus layer security. Security relies on cryptographic verification and consensus mechanisms, which rely heavily on the inability of nodes to form a conspiracy to cheat, a logic that also stems from the assumption that the costs of attack outweigh the benefits, not that we really trust them. However, this assumption may break down in the face of high-value events, and nodes may conspire to cheat in the face of benefits. So many blockchains have some practices that increase the cost of cheating: a) Allowing anyone to be able to create nodes, which comes at the expense of efficiency. IC has shrunk this practice for the sake of efficiency. b) Blockchain data is made public so that everyone can verify it, complicity in cheating can be detected quickly, and all users can take steps to protect themselves and make cheaters pay, which inadvertently raises the cost of attack significantly. This inadvertently increases the cost of attack significantly and creates a deterrent for potential cheaters. If blockchain data is not publicly available, cheaters are likely to go undetected, or be detected when it is too late. The vast majority of blockchains have adopted this measure, and IC is currently hesitant to do so for the sake of pseudo-privacy, although there are plans to open it up.
Again, to make my point.
- I think most of the subnet data being open is a priority.
- I don’t object to a small portion of the subnets still taking the current non-open measures, because there are indeed some applications that have this need, such as putting some unimportant files. I don’t think this direction will be mainstream. But please make good open guidelines, to let the developer know what he is doing, he can’t treat canister as his own server.
7 Likes
Not sure what you meant by “choosing the latter, depending on which application scenarios take precedence”, but it could be exactly what I was arguing for (and the IC is aiming for): instead of enforcing one extreme, the IC allows for a wide spectrum, not merely the binary choice you present:
- you can publish and persist blocks forever, as will likely be the case with the NNS;
- you can publish and persist the last N blocks, allowing anyone to run independent replicas that verify correctness; and
- you can keep blocks and replica state more or less private (up to and including allowing someone to run a subnet exclusively on their own nodes; or on nodes with specific hardware features).
And everything in-between. On the IC, as opposed to BTC and ETH, there is zero need to go full-on religious fundamentalist on this particular choice.
This very dynamic applies to traditional blockchains. How exactly is it more difficult for a couple of mining pools to agree to cheat than it would be for 9 or more (mostly independent) parties? Why do you keep assuming that simply because some network has thousands of validator nodes, this must mean thousands of independent parties? The very nature of such networks makes economies of scale the way to go: node operator overhead is huge if one can only afford to run a couple of validators; it is negligible if you are adding N more validators to an already running pool of thousands of servers you own.
Again, I’m not sure what you mean by “IC has shrunk this practice”, but the truth is that the only reason why you cannot run your own replica on the side, as a validator, is that it requires work to implement and that work has not been done yet. This very thread discusses what priority should be assigned to that work. And AFAICT not a single comment has argued for keeping all subnets’ blockchains private. Yet, there is a vocal minority that acts as if this were so and as if no one but them understands the benefits of a public blockchain.
Honest question: what draws you to the IC when, as you point out, ETH (and the vast majority of other networks) do exactly what you see as necessary? If it is perchance the scalability and the very low costs of operating a canister? If so, that directly contradicts verifiability via publishing and persisting the blockchain forever, exactly because the latter is so insanely expensive.
Have you read my comments above regarding replica divergence? How exactly is that less likely to detect cheating? Or “too late” as opposed to some random third party replica detecting a divergence? (Whether on the IC or e.g. on Ethereum.)
You keep going back to this strawman. No, it is not “for the sake of pseudo-privacy”, it’s (i) for the sake of scalability and cost (in the case of persisting blocks forever); and (ii) because no one has had the time to build this in (in the case of independent nodes). With the minute increase in privacy as a side-effect. And instead of finally agreeing that publishing blocks in some form or other is a high priority feature and moving forward with an implementation, here we are waging holy war over how it constitutes the only reasonable way of using a blockchain and trying to enforce it onto “most subnets”.
Again, why “most”? Why “small portion”? Why “unimportant”? Why not let canister developers decide what is important to them? Provide clear guidelines on the various options, sure. But what is the benefit of imposing your (or anyone’s) particular view on “most”?
9 Likes
It could be that I’m reading too much into this and you are just referring to the use of homomorphic encryption as a way to provide data privacy on a public network while allowing a dapp to do more than serve as glorified storage. If so, I highly doubt that this is currently used much, if at all, on any network. And there is absolutely nothing preventing you from using it on the IC, if you so choose. It is (to the extent that you can do cryptography on-chain) not a binary choice that the network enforces on you.
Another way of reading this (based on “btc and ETH have chosen the former, and IC is choosing the latter”) is that you believe (or make yet another strawman argument) that the actual IC protocol “relies on hardware and node provider security measures” as opposed to strong cryptography for its correctness.
Regardless, whether referring to homomorphic encryption; or relying on individual node providers for protocol correctness and safety; there are no two paths here. BTC and ETH have not chosen homomorphic encryption. And the IC protocol does not rely on node providers for its correctness.
It is simply a case of the IC as currently deployed (due to choices related to efficiency and scalability; and not yet implemented features; not technical or political limitations) offering by default a modicum of privacy to canisters, in that e.g. some random person without significant technical or financial backing cannot just go ahead and read a message that you posted to some private DSCVR group.
This thread discusses giving up that modicum of privacy on specific subnets for the possibility (not guarantee) of significantly stronger correctness checks.
Edit: “significantly stronger correctness checks” from the point of view of any one entity, not necessarily from the point of view of the protocol / community at large. There is zero improvement to me if you run an independent node that validates one subnet’s blockchain vs. the NNS deciding to add one more replica to said subnet.
2 Likes
I express my opinion and you can stick to yours. You will also read other people’s opinions.
I am not emphasizing binary choices, but talking about having to make trade-offs when some options face conflicts.
Regarding blockchains like BTC, ETH, IPFS, IC, they are all great projects and all unique in their own way. It is important to know that the ecology of BTC and ETH still leads the crypto world, and the new generation of projects still faces challenges and struggles, which is the reason why people have the opportunity to chat in this forum.
The reason why some people are expressing their views here is to make IC better, not to linguistically praise how good it is.
Many of IC’s innovations have come at a partial cost, which needs to be weighed against the trade-offs. For example, IC gave up atomicity and reduced security to get higher performance and efficiency, as well as scalability. But some changes will send IC down a different path, and I’m worried it’s losing too many blockchain features to cater to what would otherwise be web2 needs. I think more than one person has said something similar.
I’m not here to deny it, I’m here to push it. Otherwise, I wouldn’t be here talking.
7 Likes
I’m very much not saying you should not be expressing your opinions. Or that everything that you are proposing is wrong or worthless. Just that taking absolutist approaches to anything just because that’s how everyone else has done it; and ignoring alternate approaches and different needs; will not lead to strictly better security or privacy.
In particular and as an example, as long as I personally am not running an independent node that verifies a subnet’s blockchain in real time; or even if I do but there are parts of the replica stack that I’m not intimately familiar with; I get fewer benefits from you (claiming to) run an independent node as opposed to the NNS adding one more node to the subnet (and my having access to said node’s metrics). You running an independent node is better for you, not necessarily better for me.
As you say, there are trade-offs to be made. So you should be free to run your own validator node, if that gives you stronger confidence in (but not a guarantee of) a subnet’s honesty. And there’s no good reason for me to prevent that. But if I don’t intend to run a node validating every subnet that I interact with; and instead value more my boss not being able on a whim to read my ranting behind his back; you should also not be forcing your constraints (“most of the subnet data being open”) on me.
That being said, I do take issue with blanket statements such as “IC […] reduced security to get higher performance and efficiency”; “If blockchain data is not publicly available, cheaters are likely to go undetected”; “Dapp should not store any private data on the IC” (while claiming that you understand that privacy is a continuum, not a binary state); or the false dichotomy between BTC and ETH’s (vague) “choice” on the one hand and the IC’s on the other. None of the above adds anything useful to your argument.
3 Likes
This is what you think so. I said the reasons are based on logical analysis, technical background, and economic principles. And many of your points, just to emphasize that you are right, do not have arguments.
The object of my narrative has always been IC. and the object of your narrative is not on how IC can do better, but on arbitrarily expressing that I am wrong and also looking at other blockchain projects with contempt, perhaps you want to express that the path IC is on now is the best option. Then fine, please stick to it!
1 Like
If you said so, then it must be so. No argumentation required.
Would you mind pointing out one such point, not backed by arguments? Honest request. I would be happy to provide the arguments I have.
I am not looking at other blockchain projects with contempt. They made their choices (either for technical reasons; or simply because they exist from long before the IC was even conceived and that was the state of the art at the time) and they have their trade-offs. Usually, favoring huge replication as a way to achieve tamper resistance over cost or scalability. Hence, they are very useful for some applications, but not so much for others.
What I do have a strong opposition to is the claim that following closely in their footsteps is the only way in which the IC could be useful as anything more than an AWS clone.
6 Likes
My question for partial public subnets would be. How to handle cross-subnet verification. This is similar to cross chain transaction,which needs to be verified on both sides
It sounds like the end users need to run their validator nodes FULLY trust IC as a blockchain.
I think there is a misunderstanding here. @free is making really brilliant balanced arguments.
1 Like
You think the security of a 9 node IC subnet is about the same as a blockchain with thousands of nodes, you also think the security of non-public blockchain data is comparable to the security of public data, and think IC has the ability to protect private data for most applications. That’s the funniest joke I’ve ever heard.
If this foundational argument of yours holds true, then all of your points above are true.
Do you remember the BTC-BCH fork? Several large mining pools could really do whatever they wanted if there were no public nodes, but numerous public nodes prevented this from happening and BTC went on to become mainstream. This proves the value of public nodes, even if they don’t participate in consensus.
Yes, a lot of people are stupid, including me, and don’t understand the great things you guys do. Some even claim that IC is not a blockchain, that many mature application scenarios don’t want to come in, that some IC developers are leaving, and that it’s these people who are too stale to see the great things IC is doing.
The people who chat here are those who have hope in IC, those who don’t recognize IC won’t come here at all. So don’t feel good about yourself.
5 Likes
I agree with you. All I’m saying here is I hope IC will have a better future. Hopefully there will be a change in the authorities.
1 Like