Double spending protection
This fraud method is based on the idea of re-using the same payable asset two or more times. It is a rather popular attack for the common blockchains, and the methods to repel it usually cause the blockchain transactions be executed rather sluggishly, and the data read results be probabilistic. The latter fact means that the recorded transactions, even having a high “confirmation” level, still may be rolled back, and in general practice the transaction rollback is rather common; specifically for financial purposes this could be considered unacceptably common.
Repelling within Universa
Universa network is rather different from traditional blockchain architectures. To understand, why double spending (or double utilization) is impossible in Universa, you need to know about the following features of Universa:
every transaction is rather accepted or rejected by the whole network, using the voting procedure. The approval consensus level is 90%, what is noticeably larger than the rejection consensus (10% + 1 голос). Also, it is noticeably higher than the “50% + 1 vote” consensus common in other blockchains. As a result, every voting always ends up in a concrete result.
while the voting procedure (for some change in some specific smart contract) is in progress, its current state is locked until the voting completion. The lock means that if some other transaction attempts to change the state of the contract, it will be rejected by the node.
during the voting, every node provides its own vote (the node’s opinion whether the transaction is acceptable), but, on the voting completion, the note accepts the consensual decision no matter of its own original vote.
Altogether, these factors repel the double-spending attack rather efficiently. Let’s have a look how it works in practice.
Imagine some fraudster named Chuck, who owns the smart contract for 10 000 UTN (S), and wants to scam his friends named Bob and Alice, sending this contract to both of them in exchange for some goods or service. Thinking he is a coolhacker, her manually created two contract revisions: A and B, in which the ownership is changed to Alice and Bob (their cryptography keys, actually), accordingly. He signs both of these contracts with his own key, and writes a simple Python program to launch the registration of these revisions simultaneously, from the different points of the network (though the actual one will more likely write a Bash script, using the uniclient tool).
Chuck thinks – and he is fully right in his thinking – that both of these revisions are correct at the current moment. But then he would make a wrong conclusion if decide that the network would accepts both of them simultaneously; even if he launches them as much simultaneously as possible, from some different network entries, hoping that the network approves them both, and fails under the “double spending” attack.
Alas, the real life is too much different from the utopian stories in the blockbusters or on 4chan. And Universa is too much different from the Bitcoin ideologic clones.
So, let’s imagine that the two (mutually exclusive) transactions registrations were executed as much simultaneously as possible. Imagine the worst-case scenario, when the nodes are broadcasted with just one of either states, as long as it is possible in the network. All the nodes receiving this state would accept that the according transaction is correct.
In such case, after some time there is a pack of nodes which received just one of the transactions, either A or B, consider them valid. In the worst possible case, the number of these nodes would be 50% of both types,.. what is insufficient for the positive consensus of 90%:
And since this moment every next node, receiving either A or B transaction, will start to reject this state, as its parent state is already locked by another transaction. So since one half of the network (already) considers state A correct, and the other half considers B correct, then, as the transactions are broadcasted over the network, all incoming states will receive only negative votes. The node cannot vote in favor of B it it has just voted for A (and vice versa) – these states share the same parent, which has been locked already and cannot be used in another transaction until unlocked!
After some short time, both A and B would get the negative consensuses (have you wondered if the plural from “consensus” is “consensi”? no, it is “consensuses” in English or just “consensus” in Latin), 10% + 1 votes, so both revisions will be rejected (declined) by the network. And every node will accept this voting outcome regardless of its own voting! Therefore, the attack has failed:
At the diagram you see that the first two nodes receiving both states have issued the negative votes, which (in this particular example) were enough to get the negative consensual decision on both transactions.
But this was the “perfect storm” case, when both revisions do not collide as long as possible. In the more possible case, the collisions (when some node receives both revisions and rejects the last one) would start earlier, so the network will reject the revisions even before they have a chance to spread over the network.
In case if one transaction takes longer to spread over the network, the other one can have enough time to obtain the needed 90%, so it will be approved by the whole network; the other transaction will be rejected almost immediately, as its parent state is already invalid, the transaction (that just got approved) has already changed the parent state to REVOKED, so the second transaction will be receiving only negative votes, and will get rejected promptly.
Fun fact: an attempt to launch more than 2 conflicting transactions at once would just cause the rejection to happen faster, as the collisions will start earlier. Imagine, we’ve launched the same number of conflicting states as the nodes of the network, and each one has been launched from a different node. In this case, each conflicting revision will get just 1 positive vote (from the node where it has been launched), and all the other nodes will reject this transaction (as they’ve just voted in favor for another, conflicting one); so the 10% + 1 votes required for rejection will be collected very soon.
Summarizing, we can see that in case of the “double spending” attack, Universa network can end up in either one of two only possible outcomes:
- either both transactions will be rejected (when launched more or less in parallel);
- one of the transactions would get approved, but the remaining one (or ones) will get rejected.
Both outcomes are quite correct and valid: in the first case, nobody would get the result transfer at all (and the transfer just won’t happen); in the second case, someone of the receivers will get the correct transfer, while the other (or others) will get nothing.
A nice bonus for the abiding network participants (in particular, the network owners) is that the network will take the fee for both of the transactions, no matter of the result – the failed fraud attempts are actually costly for the hacker while bringing profit to the network in the same way as the regular network usage.