Shuffling is good under the assumption of adaptive adversaries, i.e. that a hacker can take a certain amount of time to break into and corrupt a node.
With non-adaptive adversaries, I believe not shuffling is safer. However, perhaps the adaptive adversary is a more realistic threat model.
2 Likes
But the tECDSA subnet has essentially half of the fault tolerance.
Itās the tECDSA protocol that has half the fault tolerance of Chainlink and regular subnets, essentially. Only 1/3 of participants are needed to sign.
Ah, yes that I think is one of the key considerations and something Iām not sure ICC even addresses.
The Liquid side chain holds large value secured by a 11-out-of-15 signing threshold. The 15 entities are well-known (such as exchanges). The significant risk is that 5 loose their keys.
Safety-wise it is equivalent to a 31 node subnet (11 need to collude). But a 31 node subnet can tolerate up to 20 lost keys.
3 Likes
Ah manā¦I may have misunderstood again.
Subnets only need 1/3 + 1 to collude? I was always under the 2/3 assumption.
I thought that 1/3 faults could be tolerated, and 1/3 + 1 would make it so that the subnet could not come to consensus and would thus halt, but 2/3 could collude and continue consensus without being detected as easily.
Can you help me to understand?
I just counted up the number of independent node operators in the tECDSA subnet, and there are only 19 independent node operators out of 28 total nodes.
I would guess that shrinks the tolerance down to 6 out of 19, so 7 independent node operators can collude to sign whatever they want.
7 colluding or hacked node operators.
2 Likes
Perhaps we should start thinking of the IC not as a blockchain like others but as something between the cryptosphere on the one hand and Web 2 / real world on the other. Seen in this light, ckBTC security is underpinned by two factors. There is the replication that makes stealing funds difficult, but as @lastmjs points out, the replication factor is pretty low. However, node providers, though relatively few, are fully doxxed, and will face immediate real world consequences if they collude to steal funds. This is not the case with traditional chains. The two factors together provide better security than any other BTC defi initiative.
Thinking in pure crypto terms, we discount the second factor and want everything to be secured in a trustless, permissionless manner. But I am gradually giving up on the idea that the IC will ever be a truly decentralised, transparent and permissionless chain. It just doesnāt seem to be on the Foundationās roadmap or list of priorities judging by many discussions on this forum. The Foundation only takes baby steps and considers those favours done to the community.
Anyway, maybe this middle ground between crypto and Web2 / real world holds promise, we shall see.
4 Likes
Iām not so sure about this, node providers simply have to convince the NNS they are legit and there are many ways bad actors could exploit that, if banks can be fooled so can the NNS.
Even assuming an ideal system that canāt be cheated are providers actually legally liable? They donāt sign any binding document and reside in different jurisdictions so starting legal action and proving they willingly stole the funds wonāt be easy, after all itās in the realm of possibility that a skilled group could hack 7 independent entities to steal possibly millions of dollars.
3 Likes
Yes and if we open up the floodgates fo independent node operators, unless our verification process is excellent, then the risk of Byzantines increases. So far the node operators have been a relatively small and vetted group. Itās of extreme importance to figure out how to continue vetting them
2 Likes
Even with more independent providers the risk still remains, I very much doubt the vetting process will ever become good enough to filter out competent bad actors, so the only real safety provided by more providers will be the increased amount of money they need to invest in node hardware to take over at least 1 subnet.
I was hoping the ādeclaration of good intentā could at least make it harder to fool the NNS cause at least figure heads would be legally liable and therefore itād be less appealing to be part of a coordinated attack, but that isnāt the case as the declaration is just a piece of paper with no real legal weight nor there is a defined course of action in case it were to be violated.
To be fair Iām not a huge fan of using the law to guarantee safety of what is supposed to be a decentralized protocol, but all things considered it might be best to acknowledge ICPās hybrid nature as @Denis said and take a page out of centralized cloudās book.
2 Likes
I am not sure where the idea that the IC withstands 2/3 corruptions even comes from. Let me say this once and for all: The Internet Computer Protocol withstands 1/3 corruptions and no more ā that is the way it is and the way it always has been. If 1/3+1 nodes are corrupt, then the safety property of the consensus protocol may be broken, which means a subnet can permanently fork into two inconsistent states.
This is not an accident ā achieving liveness and safety in consensus with greater than 1/3 corruption in an asynchronous network is theoretically impossible.
While it is true that the protocol (and a million other consensus protocols) uses a 2/3+1 threshold for various quorum sizes, these thresholds are designed to withstand 1/3 corrupt parties, not 2/3. I think the fact that these thresholds are 2/3+1 has led to the misconception that the protocol withstands 2/3 corruptions, but that is just a fallacy.
What is also true is this: if 2/3+1 parties are corrupt, then it is trivial to break the protocol, but if 1/3+1 are corrupt, it can still be broken, even though it is a bit more challenging (but still feasible enough that nobody would seriously consider the protocol to be secure in that setting).
See The Internet Computer for Geeks for more details.
This was one reason why tECDSA protocol was designed with withstand 1/3 corruptions: this is exactly the same corruption level as the IC consensus protocol. Also note that our tECDSA protocol relies on consensus for its security: in fact, if you break the safety property for consensus, you can steal the ECDSA signing key (this is true of almost any threshold ECDSA protocol, due to the inherent fragility of ECDSA signatures themselves). While it is true that if you corrupt 1/3+1 nodes you can steal the ECDSA signing keys by stealing the key shares, we have implemented various mitigations, such as proactive resharing of the secret key. But even if we took other mitigations, it would still be possible to steal the secret key with 1/3+1 corruptions via other means (e.g., the above-mentioned attack via breaking consensus).
See Design and analysis of a distributed ECDSA signing service for more details.
We are currently exploring some options of trading off liveness vs security, so that we boost somewhat the threshold for breaking security, at the cost of lowering the threshold for breaking liveness (and possibly losing the secret key completely). This same tradeoff would also have to be applied to consensus (at least for ECDSA enabled subnets). This would bring us to a security threshold closer to 1/2. This is a WIP.
8 Likes
Fwiw, @victorshoup helped me grok this over a conversation once. An ELI5 from that convo is:
Forget about quorum sizes and thresholds. Here is the main thing: IC assumes less than 1/3 of actors are bad. If that assumption is broken, all bets are off.
Every chain has a security assumption of how many malicious actors it can function well with (ranging from 1/2 to 1/3, or even less). If that assumption is broken, so is the rest of any protocol.
I found myself often forgetting this simple fact until Victor once helped me focus and not get too distracted by the other numbers floating around (which I was).
3 Likes
Thanks for the detailed explanation. I knew the fault tolerance was 1/3, but assumed that after 1/3 it would simply become unclear which group of participants had the consensus state. So essentially a subnet would fork at that point, and confusion would ensue as to which state to trust. All forks could continue executing state transitions, but none would be trusted as the consensus state machine.
The only way for state changes to be trusted as consensus would be for 2/3 of participants to say so. Thus to truly pull off a catastrophic attack where state could be changed without competing forks you would need 2/3 dishonest parties.
Thus it seems to me that any number of corrupt parties under 2/3 is desirable to 2/3 dishonest parties, because then consensus could be reached possibly without detection or forking.
Is this a correct understanding or should I just assume 1/3 + 1 and itās all over?
1 Like
<= 1/3 corrupt parties = consensus is reached, honest state machine is consensus
> 1/3 corrupt parties = consensus is not reached, forks ensue, unclear which state machine is consensus
>= 2/3 corrupt parties = consensus is reached, dishonest state machine is consensus
Is the description above materially flawed?
4 Likes
This is one more reason the in the future we will likely have to move to a staking/slashing model for node providers. My understanding is that currently the āinvestmentā in hardware is considered enough skin in the game to keep providers honest, but I doubt that is sufficient for the long run.
Perhaps there is a stake reveal game that can be added to tecdsa that would make it more profitable to pretend to collude but backstab the colluders at the time of signing so that the cheaters suffer financially. Getting a bit out of my depth here, but skin in the game can help with these security guarantees. The entire NNS is predicated on the concept.
If 1/3+1 parties are corrupt, then there could be two different states, each certified with 2/3+1 participants saying so (because corrupt parties can vote both ways). That seems pretty catastrophic to me. I agree that if 2/3+1 parties are actually corrupt, the situation is much worse ā so an even bigger catastrophe. So the difference between 1/3+1 corruptions and 2/3+1 corruptions is catastrophe vs an even bigger catastrophe. Maybe in the first instance, through heroic and probably very centralized and ad hoc methods, one could somehow reset the Internet Computer back to some reasonable and consistent stateā¦maybeā¦but I would not want to contemplate that situation
3 Likes
I donāt understand this scenario.
13 node subnet can handle 1/3 corrupt parties = 4 corrupt parties. So a minimum of 9 parties must agree to certify a state.
If 1/3 + 1 parties are corrupt = 5 corrupt parties and 8 honest parties. How could 5 corrupt parties ever sign two states that have at least 9 parties agreeing? The 5 could add at least 1 agreement to the 8 to get the correct honest state, but the 8 would never agree to anything the 5 proposed dishonestly and thus the dishonest state could never get 9 votes.
Iām not seeing how 1/3 + 1 can do this attack. Iām only seeing that you need at least 2/3 corrupt parties, 9 in this case, to certify a state. Otherwise the honest parties would never vote on a dishonest state and thus there would simply be many uncertified states.
I would really like to understand.
1 Like
Hmmmā¦maybe it depends on the nature of the state changes. The dishonest participants could propose valid state changes that for example double-spend, and depending on the order of messages received, network conditions, honest participants wouldnāt be able to tell. Is it along those lines?
DFINITY already engages often in this kind of activity with subnets. They essentially have write access because of follower relationships, and they use it.
I assume itās mostly done with proposals, but couldnāt the same mechanism be used to restore a subnet? and if Iām not mistaken subnets have already ceased finalization in the past and have had to be reset.
1 Like
I hope node providers do have some legal liability, but legal liability is not the only disincentive to acting badly in the real world 
Do you think that Sam Bankman-Fried will be taking walks in the park, even if fully acquitted?
I am not condoning retributive violence, just pointing out that if people steal a lot of money, some of the victims will find the thieves and make them regret it. The threat of retributive violence IRL is as distant as you can get from cryptographic security but is pretty effective as a deterrent. It will certainly be in the minds of the ICās node providers. If node providers were anonymous, I would never put money in a 34 node subnet, no matter how rigorous the maths underpinning it.