How can you confirm the formula of say Pfizer or Moderna does what it is intended; they don’t share the formula. But everyone has come to understand the effectiveness of vaccination to boost hard immunity. Now poor countries would want to have the formula to design vaccine that cater for their distinct populations. But the same companies that advocate for eradication of covid19 won’t share that formula based on their reasons. It is the same with IC, you just have to use the product and join everyone in line in waiting for a stable release of what you are asking for.
You really have to take a step back and observe how the world works/ runs for you to understand the stability of IC.
@JxBrian your analogy does not make sense here. Using your analogy, this is like asking Pfizer or Moderna “does the vaccine work?” And them saying “you can’t ask that trust me bro”.
I don’t want the formulation. I want the PROOF that it’s doing what it says it does.
1 Like
To be fair, @free did not state it is trivial to compromise nodes, he stated that should someone compromise enough nodes on a given subnet, it would be trivial for the attacker to then fool any auditor into believing the subnet was behaving fine.
I think we are once more facing a clash between Dfinity’s engineering and math mindset vs the community’s crypto mindset. It’s quite sad, because DW’s notes, and Free’s inputs are rather beautiful, they fill me with wonder at what Dfinity has accomplished.
But the organisation can’t seem to understand the importance of appearances. If people committed enough to a network to spend hours on dev forums say they feel independent, public verification is important, the response ought not to be the equivalent of, “You are idiots who don’t understand the math”. Because the network’s success will depend on convincing millions of idiots like us, which can only be done by appearing to have a trustless system in place. (And to clarify, nobody at Dfinity has called anyone an idiot or implied anyone is an idiot, it is just my construction for effect). Right now, from the idiot’s perspective, Dfinity seems to be saying, “It is as trustless as it can get, trust us.”
6 Likes
I haven’t read the whole thread, but yes I believe you are correct. I’ve been saying this for a long time, and it’s not just me. It’s not like we magically can throw away the need to verify the computations, we’ve instead taken a trade-off.
I feel to say otherwise is misleading.
On the ZK side, that’s part of why I’m so interested in eventually replacing the IC’s VM with a zkWasm VM. Discussion here if you’re interested (and there is a team already working on zkWasm): Zero Knowledge Internet Computer Virtual Machine
Edit: but then again, if a 2/3 majority is malicious, they could produce erroneous proofs. The proofs would have to be correct, but I believe there are certain attacks that would still be possible, probably double-spending
6 Likes
Maybe you did not understand the point I was bringing across is … it is up to developers Pfizer, Moderna or IC in this case to release their project design at the right time. And you can not tell them what the right time is and here is why…
Say you design a futuristic ship. You are in the ocean and moving at godly speeds through a storm. Your dashboard shows you are moving at 1000 miles an hour. This ship has communication capabilities and you are able to interact with the outside world broadcasting on real time on your achievements.
An outsider comes along and says how can we trust the ship is moving at 1000 miles an hour… “let me in, let me peek at the dashboard, I want to confirm xyz.”
So you tell them that is not possible at the current time, they have to wait till the storm clears up. Maybe when the waves clear up and the water settles you might let them in the ship to look at the dashboard. Mind you, you are still working on the ship…probably taking their consideration to have a feature that would let them have what they are requesting.
But they insist on being let in to verify that the ship is moving at a certain speed. To them, maybe the reason they want to confirm the reading on the dashboard is because Einstein theorem of relativity states that based on a point of observation the speed might be different. But while designing your ship you knew that. Newtonian Physics vs. Special Relativity
How can you let them in while there is a storm and you are moving at godly speeds? Though you would want them to see that your dashboard is working as intended, they have to wait till the storm fades away or the water clears up. That is the only way you can protect the ship, yourself and them.
The vaccine analogy also fails because a vaccine is scientifically and independently tested first on animals and much smaller populations. Also, a vaccine formula is not subject to frequent updates like the IC is, thereby mostly invalidating the efficacy of prior independent testing. Finally, there is no survival imperative to use the IC like there is for vaccines. In other words, there is no survival risk to individuals if they simply walk away from the IC because they have no independent assurance to rely upon it. That will make market traction for the IC unnecessarily difficult.
As for protection of proprietary formulas, that could actually be another purpose of an independent auditor, in addition to obviating the need for private subnet data to become public for the purpose of public blockchain verification. Independent auditors could also protect proprietary blockchain algorithms while auditing them if DFINITY’s patent protections are not considered sufficient to do so. However, my understanding was that all the IC algorithms are open source anyway, with only legal usage restrictions on forking the IC. So that means everyone should be able see exactly how the algorithms work without relying on any NNS-approved auditor for privileged algorithm access.
But at that point, it is arguably no longer just an “attack”, is it? It’s basically a complete hijacking or conquest. That’s analogous to saying, “should someone compromise enough nodes on the bitcoin or ethereum blockchains, it would be trivial for the attacker to then fool any auditor into believing the blockchain is behaving fine.” Well, yeah, the attacker just conquered the entire blockchain consensus, so no more “fooling” is technically even required. The blockchain consensus has been hijacked and will now actively protect only the malicious blockchain version. Everyone understands this theoretically remote risk, but that is not the risk we are focused upon here. In other words, I don’t think it is fair to present this extreme risk (which all blockchains face to some degree) as a reasonable argument against the value of an independent audit.
Edit: but then again, if a 2/3 majority is malicious, they could produce erroneous proofs. The proofs would have to be correct, but I believe there are certain attacks that would still be possible, probably double-spending
Exactly! If you need a 2/3 majority to achieve consensus on the ordering of inputs, then why bother with generating proofs, especially if it is at least 5 orders of magnitude more expensive than just replicating the computation without any proof (which is simply “subnet size” more expensive)? In any case, you’ll need to trust the 2/3 majority for the inputs.
Ignoring the zk proof part of this, I agree that running a node yourself, verifying all the blocks, and rerunning all computation would solve this.
One thought experiment: what if tomorrow suddenly 2/3 of the NNS subnet’s nodes were hijacked and they managed to illegally fudge some transactions, e.g. double spend, mint new ICP, etc? Let’s say after 10 minutes the network got restored. How would anyone be able to detect this? The consensus protocol would be chugging along just fine. Because blocks are not public (and in fact blocks are thrown away after a short period of time), the erroneous state (for which consensus was achieved) would be taken as given, and it would go unnoticed until the end of time…
Or am I missing something?
EDIT: Would the ledger’s “blockchain in a blockchain” fix this? I can’t think of how it would.
3 Likes
ZK and it’s applications within the IC are finally starting to make sense to me, having argued the importance of computational proof in distributed systems.
@lastmjs I would be interested in helping forward a zkWasm VM, although I can probably only contribute distributed systems knowledge and a bit of Rust. My Wasm experience is near nil.
1 Like
I think their argument is “the math” says 2/3 of the NNS subnet’s nodes getting hijacked and illegally fudging transactions without being detected is never going to happen in the first place. Kind of like how we assume SHA256 collisions will never happen even though it’s possible but the math says it basically won’t.
The math only says that if at least 2/3 of the nodes aren’t hijacked, then you can trust the computation without downloading the blocks yourself.
Thanks to the way the protocol math works, if the chain key signature validates, this not only tells you that your interaction has not been tampered with, but also that the subnet blockchain returning the result is running correctly and that neither its state or computations have been tampered with (which could only be achieved by corrupting the subnet blockchain involved, for example by overwhelming the fault bounds of its Byzantine Fault Tolerant protocols).
That is, they use protocol math that guarantees that so long as the proportion of “faulty” nodes (i.e. nodes that can behave arbitrarily, including going offline, corrupting data, subverting the protocol, and colluding with other faulty nodes in any way they choose) stays beneath a defined “fault bound,” then the network will continue running correctly.
^ These are quotes from Dom earlier in the post.
His argument that 2/3 of the nodes won’t be hijacked is based on deterministic decentralization, i.e. it’s difficult to hijack 20+ nodes in different legal jurisdictions and owned by separate node providers in a short period of time.
Quote:
The nodes involved are selected by the NNS using a system of deterministic decentralization. This means that they are owned and operated by independent node providers, and installed in different data centers in different geographies and jurisdictions. This is very different to randomly selecting anonymous nodes in a typical Proof-of-Stake network, within which an adversary might be running a large number of nodes – such that if the random selection of a group is unlucky, nearly all the nodes might belong to the adversary.
My concern from above is… OK let’s say that we unfortunately do have a situation where 2/3 of the nodes get hijacked. How can we recover from that? How can we detect that?
1 Like
I think the point made was that as long as there was one honest node, there would be a divergence between nodes, which would be detected.
1 Like
I’m not so sure downloading and verifying all blocks yourself is much better than the ZK proof, I would guess it’s worse. In that case, you still have to download the blocks from the potentially malicious nodes. If 2/3 or malicious, wouldn’t you be in the same boat as with the ZK proofs?
This all breaks down if the bounds on the number of Byzantines are broken.
But, I would guess ZK proofs would be more favorable than downloading and manually verifying all state, given that some protection is given you. If at least one node is honest you could at least detect issues (I believe this is the case both with downloading and verifying and with ZK).
But he’s saying here that the math of deterministic decentralization and network security/monitoring says a situation where 2/3 of the nodes get hijacked without being detected won’t ever happen so we don’t have to worry about it.
Imho Dfinity relies to much on Deterministic Decentralization, a.k.a the assumption that:
- It’s possible to identify individuals in a decentralized manner with a high degree of certainty.
- Being doxed is enough to prevent attacks against the network.
I have serious doubt about both, it’s just a matter of time until the network starts securing enough value and they’ll be put to the test.
3 Likes
Let me take a step back and try to summarize my understanding of how things fit together. Even though it may not look that way, this is not intended as a categorical argument against public subnets. All I’m saying is that public subnets are nowhere near a silver bullet. That being said, please let me know if I’ve missed or misrepresented anything. Which is entirely possible.
AFAICT there are 2 failure modes that public subnet blockchains and independent third party validators are intended to protect against:
- A malicious supermajority (two thirds plus one) of a subnet’s replicas fully taking over a subnet.
- Bugs in the protocol or its implementation allowing a malicious party to take over a subnet without having control of a supermajority.
The underlying assumptions (again, as I understand them) are that:
- an independent validator would be able to detect if a subnet is not behaving correctly (e.g. minting ICP out of thin air; or issuing transactions not authorized by users);
- (partially) that there is no other way of gaining an equivalent level of trust in a subnet; and
- (partially) that tampering with the state of a subnet would be the main vector of attack.
1. Malicious supermajority
Parenthesis: I never claimed that taking control of a two thirds plus one supermajority of subnet replicas would be trivial. I was merely starting from it as an assumption that others had made in this and the earlier thread, as a clear cut example of what independent validation might protect against.
Second parenthesis: I did (incorrectly) claim that “it would be virtually impossible to hijack a subnet without being detected”, even in the absence of independent validators. But Dom then described a smarter attack: if one can just stall the handful of honest replicas for long enough; and then have them sync up to the malicious supermajority after the state has already been tampered with; the honest replicas would be none the wiser about it. A public subnet blockchain and independent validators would indeed be able to detect this specific malicious behavior In this specific situation.
The issue with starting from the assumption of a malicious, colluding supermajority is that it causes pretty much everything else to break down, because no consensus algorithm can possibly deal with it. Yes, an independent validator may be able to detect a subnet going rogue if it does so in the most egregious way possible (e.g. tampering with the state by creating transactions out of thin air). But if that has happened, then the harm is already done (e.g. up to and including draining all Bitcoin held by canisters; on the Bitcoin network, not merely on the IC).
And (my other earlier point) if a majority of a subnet’s replicas are maliciously colluding, there are myriad other ways to cause chaos without even tampering with the subnet’s blockchain/state: the attacker now has the subnet’s secret key, so they can simply sign fake responses to ingress messages; or send fake canister requests to other subnets. There is literally no way to prevent the former, since it’s just an interaction between a user and a boundary node. It is in no way reflected in the subnet’s blockchain or state. As for the latter (malicious subnet firing off arbitrary, legitimate-looking requests to other subnets), unless you have independent validators for every single subnet; and they cross-reference every single canister message received by any subnet as having been sent by the other subnet; again, there is no way to detect it. The fake request from subnet A to subnet B would look like a totally legitimate request to subnet B’s validators; and, according to its blockchain and state, subnet A never produced the fake request, so a subnet A validator would also not detect anything fishy.
It is only if you have a full clone of the IC running on the side that you would be able to detect a malicious supermajority on one subnet. But, since not everyone (or anyone) will be able to afford their own private IC clone, how is that materially different from simply adding one more replica to each subnet?
And even with a fully independent IC clone in place, the attacker may (very likely, I’m not 100% sure on this point) cause mischief simply by taking control of the subnet’s consensus algorithm. That way, without directly messing with the state of the subnet (so again, impossible to detect for an independent third party validator), you can simply pick and choose which transactions make it into blocks and which don’t. And again, with knowledge of the subnet’s secret key, the attacker may prevent your ingress messages from getting included into blocks while still making it look to you as if they did get included. And were successfully processed.
My conclusion from the above is that while independent validators may be able to detect egregiously misbehaving malicious subnets, detection is not prevention; and an intelligent attacker can reach their goals without tampering with the state of the subnet at all. In other words, once someone gains control of a subnet, all bets are off, regardless.
2. Bugs in the protocol
I don’t have much here, except that if a handful of malicious replicas can fool the majority, why wouldn’t they be able to use the exact same mechanism to fool independent validators? They are running the exact same code as the fooled replicas, after all.
In other words, if a handful of malicious replicas can make the subnet behave as if there was a supermajority of malicious replicas, then see above.
Wrap-up
It may appear from the above that I’ve thoroughly discredited the IC’s security model. And that it is hopeless to even try and fix it.
On the contrary, all it shows is that (as already pointed out by others) security is not a binary property; not even a gradient; but a complex interaction between many moving parts. And thus, there is no one size fits all solution. Including public subnets and independent validators. They would increase security by some amount, against some brute force and not particularly subtle attacks. But that increase in security must be weighed against the cost (in cycles; development time; privacy; chilling effect on NNS/SNS voting; etc.). And against the opportunity cost of not implementing other security measures instead.
Including simple stuff, such as bumping the number of NNS replicas. Or designating specific high-replication fiduciary subnets and limiting access to the ICP ledger and Bitcoin canister to canisters running on such subnets. And so on, and so forth.
Of course, there is the intangible aspect of
by making (some) subnets public, pointing to them and saying: “Here, we’re just as secure as every other blockchain because we take the exact same approach to security as them”. And other ways of engendering user trust by taking measures that appear to increase security while in fact providing very little measurable benefit (what may unkindly be labeled as “security theater”). I don’t have anything on that. As an engineer, I would very much not be swayed by it, but then I guess I’m by no means representative of the general population.
5 Likes
This is correct, but having an independent audit will do nothing to prevent such attacks, will it? By definition an audit is a mechanism to detect mishandling of accounts not a defence against mishandling. It does have a deterrent effect with its assurance of detecting mishandling, but cost-benefit considerations always apply.
The question is: what is the value of such an after-the-fact measure on the IC given it would be very expensive and in some cases, described in the two public subnets threads, unable to detect fraud (any fraud would of course become visible through incidents such as the draining of funds)?
I am struggling to find a good answer for why what @free called “security theater” is required, but am also convinced it is. I’m racking my brain for real world examples of similar measures which might convince engineers of their necessity. Will post if I think of one.
2 Likes
Do you see this as a conclusion unique to the IC or do you think it applies to Bitcoin/Ethereum as well?
It’s not just about node divergence from 100% consistency. It’s also about verifying the blockchain calculations, i.e., that they are working exactly as intended, especially after the frequent upgrades across all nodes.
But what about option #3 of bugs in the protocol causing incorrect blockchain calculations in 100% of all nodes? These bugs could have been missed in NNS review or maliciously inserted via a developer backdoor or some other means. Without any independent audit over the internal controls to prevent such a scenario, how would anyone get assurance this cannot realistically happen – or worse, has already happened long ago? Given how frequently updates occur to node machines and the protocol, I don’t think it is unrealistic to think this is a scenario to be concerned about.
Again, you are entirely missing the point here by conflating “security” with “assurance”. Security is a real-time control against attacks, and I actually have a lot of confidence in the IC there. By contrast, assurance is a longer-term control to engender confidence in the protocol and to prevent unnecessary multiplication of losses. If I have no way of independently verifying my assets on the IC blockchain, or even to verify the blockchain calculations that are protecting them at a recent point in time, then I basically know that I can never get the assurance I need. So why would I even begin to invest in the IC (as a new investor or developer) or to invest even more (as an existing investor or developer)?
To explain it another way, “security” mainly relates to how existing assets on the IC blockchain are protected, whereas “assurance” relates more to how future assets on the IC would be protected and current assets are verified. Note that “verified” also comes with a multitude of personal benefits like using ICP for financial leverage, increased emotional comfort, decreased anxiety over risk, etc., which you are obviously ignoring. However, even this distinction is not entirely accurate, since “assurance” can also indirectly protect existing assets too, which is a more substantive argument. To explain, let’s take the BTC blockchain as a more extreme example so that we temporarily get off the hot button of focusing on the IC.
Right now, there are a huge number of large-scale BTC miners on the brink of bankruptcy. So how difficult would it really be for a billionaire to quietly buy up a majority of the nodes at a deep discount to conquer the entire blockchain consensus? He could then edit the state to give himself enough BTC to make this evil venture profitable, assuming no one could validate the blockchain calculations to show that malicious edits have been made to the blockchain state. He could then simply sell those stolen BTC for a tidy profit and still own the entire BTC blockchain. Eventually, of course, trust in the blockchain would slowly collapse after anecdotal stories of stolen BTC become too loud, but he would have made even more profit by then.
However, this horrible scenario obviously assumed (per my italics) that no one could verify the incorrect BTC blockchain calculations after the fact, when in fact anyone can verify those calculations almost instantly. This is why no billionaire would even bother to try this ruse, since it would either be shut down immediately somehow or the entire value of all BTC would drop to zero before he could have any chance of profiting from his conquest of the blockchain. So, in this case, it would not be any blockchain “security” that stops the would-be attacker from a successful exploit, but rather the post-facto audit assurance that would make his potential exploit essentially worthless.
This extra level of independent assurance beyond blockchain security is actually what makes the BTC blockchain both unstoppable and unhackable. It is this one critical off-chain attribute that is missing from the IC blockchain. I can’t see independent verification assurance as ever being optional to the mainstream success of the IC. It will eventually become a requirement, if it is not already for most individuals.
I guess it’s more obvious in the case of the IC, since you have blockchains with on the order of 10 to 50 validators. Which makes it more obvious that all you need is control of two thirds of replicas. And hacking into 10 servers; or paying off 10 node operators; or some combination thereof; appears within the realm of the possible.
In reality, Bitcoin and Ethereum suffer from the exact same problem. It may be more difficult to tamper with them without being detected, but it’s not really more difficult (or easier) to tamper with them
. And they (and their users) pay a huge price for that privilege, And the mechanics of PoW and PoS networks strongly encourage economies of scale, so it may well be that you don’t even need 9 parties to collude in order to take control of a PoW or PoS network (whereas in the case of the NNS you would definitely need more than 9).
Incorrect behavior on 100% of nodes would mean an (accidental or intentional) bug in the code. But you would be using the exact same code to do validation. Meaning that your local validator would also have the same bug and thus see the behavior as correct.
You could, of course, have multiple independent replica implementations. But even just the deterministic state machine that is part of the replica is (likely, because I don’t have any direct experience with Ethereum of Bitcoin code) orders of magnitude more complex than other blockchains. It includes a scheduler, messaging queues, prioritization, instruction and memory limits and so on and so forth. Plus, as pointed out by JaMarco above, it changes weekly. So while not exactly impossible to maintain multiple independent implementations, it would definitely require mind-boggling effort.
I’m not qualified to comment on the security of Bitcoin (because, as said, I am only familiar with the protocol at a very high level) but IMHO what makes BTC unstoppable and unhackable (and I believe the same applies to Ethereum) is the fact that it is one single blockchain, with very, very limited throughput and thousands upon thousands of validators. If the IC becomes amazingly successful one day, it is conceivable that one may expect the same for the NNS and maybe a couple of other very important subnets (assuming their blockchains are published).
But it is entirely unrealistic to expect this across every single subnet. Or even across all “important” subnets. A subnet is virtually equivalent to one (slightly underpowered, when compared to an AWS instance) server. Imagine for a moment how many subnets you would need to put together to build something like a decentralized banking app for millions of people (to stay within the realm of reality). Now imagine how likely it will be for each such subnet to be validated by a healthy number of independent auditors. With each machine required to validate such a subnet costing tens of thousands of dollars (my desktop machine is literally more than an order of magnitude away from the 512 GB of RAM required). All this for one single large-ish app.
Finally, it may be entirely possible to raise hell about someone taking over the Bitcoin network; walk back a few blocks (at one block every 10 minutes); fork the network; and give everyone back what they lost (modulo any valid transactions that happened within those rolled back blocks). It is definitely not possible to notice an IC divergence; raise the issue; analyze it; and still hope to roll back or fork anything meaningful at that point. Even if you do have a full block history. A malicious subnet will have sent messages to many other subnets (or outside the IC) and those subnets and outside systems will have long since acted on those messages.
Which is why I’m inclined to believe that detecting IC subnet divergence is not particularly useful beyond proving that it didn’t happen. And independent validators is exactly what node providers are supposed to be.
1 Like