In previous documents and discussions, we have established 4 facts which, together, pose a problem for CA.
- CA without vote proving is not Byzantine resistant.
- With vote proving, we can only apply CA to transactions which satisfy objective criterion.
- With snapshots, solidification is a subjective criterion.
- We cannot vote on unsolidified transactions.
Putting these facts together, we find that while proving votes, we cannot implement CA securely.
We now go over the arguments in detail. Suppose that we want to vote on the timestamp of all solidified transactions with CA.
Facts 1 and 4 are fairly intuitive, so let us recap 2. Suppose we vote on transactions satisfying some particular condition, call it X. Suppose then that 20% of the honest nodes believe a particular transaction satisfies X and vote on it (this can happen if X is not objective). Suppose that the attacker controls 30% of nodes. Then if the attacker votes too, they hold 60% of the voting power in the vote, and thus can control the outcome. They can hold the 20% in deadlock, or force them to approve a double spend. The 50% other honest nodes cannot affect this outcome unless they fully participate in the vote (point 1).
Thus if some nodes vote using CA, then all nodes must vote.
Now we explain point 3). To enable snapshotting, and we need a rule dictating what can be snapshotted. An example of such a rule is “snap shot all transactions older than currenttime-T for a parameter T” or “snapshot all transactions which are approved by 5 milestones.” Then any transaction which satisfies these rules maybe deleted by some or all nodes. New honest transactions should not approve these transactions, but currently it is not clear
These rules regarding snapshots are inherently temporal. Indeed, new nonlazy tips are of course candidates for tips selection. But at some point in time these transactions becomes old and can be snapshotted. Thus the rules must be temporal. But because of the network delay, temporal rules cannot be objective.
Suppose we require nodes to vote on all solidified transactions. Suppose an attacker issues a transaction that approves transactions which are “the threshold” i.e. some nodes are deleting it, others are not. Then some will see it as solid, and others not. Some nodes will vote on it, and others not, rendering the vote insecure.
We can not solve this problem with solidification requests without forcing nodes redownload large chunks of the tangle on the whim of attackers.
Hans proposed one solution which might work: in this case described above, the transaction is super lazy and so wont be a candidate for tip selection (depending on how we do the TSA of course) and will get orphaned regardless of the vote. This might work, however, and attacker could use promotions to create chaos.
Recently it has also come to my attention that we have similar issue with the gossip. While gossiping, it is difficult to be sure if a transaction that you have seen will propagate through the network or not. Of course, we may want to vote on any transaction we have seen, but we cannot vote on transactions we have not seen (without opening an easy spam attack). We find ourselves in a similar dilemma: how do we determine which transactions to vote on?
Overall, I think the problem goes back to an issue raised in Serguei’s talk at Warsum. We want to design the protocol such that small changes of perception eventually converge to the same view point. In this sense, the tangle is always a stable equilibrium. However, through the hard rules involved in snapshotting, small misperceptions in time cause diverging tangles.