Jura, like all other decentralized cryptocurrencies, is prone to attacks by malicious parties for financial gain. From the historical evidence, we know a few possible attack scenarios that Jura might have to face. In this article, we present the consequences of these attacks and how Jura prevents them.
1. Monopoly Problem
This problem is common due to the nature of decentralized networks. In this attack, a single entity (monopolist) takes control of the majority of staking resources. The monopolist uses these resources to impose limitations on the network that can hamper its functioning. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying services. As a result of such malicious strategies and the monopolist’s control over the network, purchasing power drops and confidence in the system shatters. Even if the monopolist acts in good faith, it is a sign of centralization that is unacceptable.
To counter this, our Proof of Utility (PoU) consensus mechanism makes acquiring high stakes expensive and takes away the economic benefit from a maliciously acting node. In addition to the traditional methods, our PoU system also hides the way of obtaining 50% of the stake in the network.
In our system, the voting power of every single entity is a result of many factors in a game-theoretic approach in the population, and the non-linear transformation via CDF from the stake size to the marginal utility eliminates the possibility of dominating in any sort. We are aware that an outlier can change the mean by a large amount, but cannot change the median value no matter how far it is.
2. Block gap synchronization
An improperly broadcasted transaction can cause the network to ignore subsequent blocks. There are two ways a node can react after observing a block without any reference to the previous block:
1. Ignore the block as it might be a malicious garbage block
2. Request a resync with another node
In the case of a resync, a TCP connection must be formed with the node to facilitate the increased amount of traffic. However, if the block was malicious, then the increased traffic and resync were completely unnecessary. This is a Network Amplification Attack and results in denial of service.
To avoid unnecessary resyncing, nodes will wait for votes to reach a certain threshold in favor of the block before initiating any connection with the bootstrap node. Otherwise, the block will be considered junk data.
3. Double Spending
Double spending can happen in two main ways:
1. Users send the same balance to two recipients.
In this case, a double spending attack is impossible given the design of FUSUS. In Fusus, once a user sends a certain amount to another address, the exact same piece of the amount cannot be sent to another address at the same time unless the first balance does not go through, or the balance increases with receiving blocks such that there is enough balance.
2. Wrong programming and poor network environment can also cause double spending.
Since the voting power is hidden to everyone and changes dynamically with respect to the population and participation, no single party will have enough confidence and motivation to vote otherwise. Besides, nodes get no financial gain for gaming the system instead are penalized for dishonest voting.
4. Sybil Attacks
To carry out a Sybil attack, a user creates many accounts with the intention of gaming the system and get more voting power. However, users are required to have a non-zero balance at all time in our system. This makes this action relatively expensive. Moreover, PoU consensus mechanism discounts the new stakes with the CST, AIST and LIST metrics, therefore, increasing the economic cost and discouraging such behavior in the first place.
5. Penny-spend Attacks
The Nano and IOTA networks have all suffered from a large amount of zero-value spam attacks. In Jura, this becomes impossible because of our VRF mechanism approach as opposed to the PoW anti-spam. Even if the attacks were to happen, the Fusus has a large capacity to absorb and consume a large amount of sending block thus resulting in zero or very little congestion.
To be specific, the PoVRT required to issue a sending block is designed to make it exponentially harder to issue an unreasonable amount of transactions, i.e., the first sending action since the last sending action or a threshold has zero time elapsing environment, however, the immediate sending actions will be forced to be separated by the VRFs. Again, the basic mechanism of sending blocks and PoVRT prevent this type of attacks.
So after reading this, we can proudly say that the Jura network is robust in the face of crisis and prepared to prevent any malicious attack that may hamper the performance of the network.
Did we miss anything? Let us know and we’ll be happy to answer.
