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.