The IOTA network concludes that a transaction is permanent when enough other transactions are directly or indirectly confirming it. Every transaction must confirm two older transactions, therefore the network benefits from a higher transaction rate, which is why dedicated users have decided to help the network by spamming transactions. In this blog, I will introduce an hypothesis about why the current spam might reduce the confirmation rate of other transactions and how you can overcome this when you build an application on top of IOTA and how the community could try and improve the confirmation rate.

Getting a transaction confirmed

In a previous blog, I explained how a transaction must confirm two older transactions and why the number of direct or indirect confirmations of a transaction increase the probability that a transaction is confirmed. If you are unfamiliar with that system, I recommend reading that blog first to understand my reasoning in this blog. In short, all the confirmations between transactions creates a graph of transactions, which the tip selection algorithm walks through searching for two end-points, called tips. The tips are then used for the next transaction as anchor points into the Tangle. The tip selection algorithm prefers to follow the path of the longest chain of transactions, therefore you want your own transactions to become part of the longest chain. Once your transaction is in a deep part of the longest chain, it will be considered confirmed and immutable.

This process can take only a few minutes and might eventually be reduced to seconds once the IOTA network is used more frequently. The usage of the network can be expressed in transaction per second (TPS) and the quality can be expressed as confirmation rate (CR) in percentage. The time till confirmation can be reduced significantly by spamming the network. Some users of the IOTA network try to help the network by creating 0-value transaction purely to increase the TPS of the Tangle and therefore reduce the confirmation time for the other transaction. However, we observe a reduced CR during times of higher TPS. Even more curious, the CR of the spam transactions are significantly higher (at time of writing: 60%) then the other transactions (35%).

The problem

When a transaction is sent to the IOTA network, it needs to select two transactions (tips) that it will confirm, and the user’s device must perform a Proof-of-Work (PoW). The tip selection algorithm is performed and will take a few seconds, based on how far back into the history it starts. The further back in history it starts, the higher the chance that the tips are part of the longest chain. After the transaction tips are chosen, the PoW calculation is performed, taking up to a minute on your average cell phone. In total, we have a delay of around 1 minute between choosing tips and broadcasting the transaction. During this minute, our transaction has not yet been broadcasted, therefore it can’t be chosen as a tip for other transactions.

Meanwhile, spammers use a tip selection algorithm that doesn’t go far back into history to save time. In addition, they often use a very fast device, solving the PoW puzzle in a matter of seconds. They do not have the same latency between tip selection and broadcasting as our transaction and their next transaction will calculate a new tip based on their previous contributions. This increases the probability that transactions they have broadcasted with a reduced latency become confirmed by themselves, while our transactions have a reduced probability to be picked because the tips will be considered old by the time we broadcast our transaction.

I will illustrate this by the walking through Figure 1. In the following scenario, a milestone has recently been broadcasted and 5 new transactions reference it (A-E). At this point, we started our tip selection for the red transaction and we select transaction D & E to confirm. While we perform our PoW, the spammers create transactions F-N. Now the scenario is as is depicted in Figure 1. If a new transaction needs to find tips and starts from the milestone he will still find transactions A-E with different weights. The probability that transactions D or E are chosen is low due to the low weight, decreasing our odds of being selected as the tip. The worst part is, that this example is mild. In reality, a transaction that takes 1 minute, will be overshadowed by 180 transactions instead of 9, assuming the spammer’s spam with 3 TPS.

Figure 1: A part of the IOTA Tangle. The blocks represent transactions with the lines indicating which transactions they confirmed. The red transaction is the transaction performed by a slow device. The numbers on the upper left are the weight of the transactions. The milestone transaction is given by the coordinator and is often referenced by the first transactions after it has been broadcasted.

The solution

The problem boils down to the fact that the spammers have a shorter latency between tip selection and broadcasting the transaction. The goal of any solution to this problem would be to reduce the absolute difference between spammers with a high hash rate versus genuine transaction using everyday devices. Unfortunately, this problem will remain when the TPS increases, as slower devices will always have a lower CR. Luckily the gap might be significantly reduced if the IoT devices get the long-awaited dedicated JINN processor. However, until that time, here are a few solutions that might help and can be done by different groups.

Solution 1: Spammers could pre-calculate tip selection

Spammers could perform tip selections for future transactions, while not actually starting that transaction for a small window of time. This maintains the same TPS, however, the Tangle will increase in width, rather than depth, giving slower devices a chance to catch up. A similar result would be achieved if spammers calculate x transactions at the same time in parallel, increasing the delay between tip selection and broadcasting.

Solution 2: Enforce tip selection in the nodes

At the moment, the tip selection algorithm is developed by the IOTA Foundation but is not enforced for broadcasting a transaction. All you need to do is confirm two other transactions and it doesn’t matter how you found them. However, the community could come to a consensus to enforce the tip selection algorithm before the nodes accept a transaction. This could be done by asking for the specific path that the algorithm has taken. There are obvious cheats around this, but at least enforces spammers to walk through the Tangle from a specific depth to the chosen tips.

Solution 3: The IOTA Foundation could reduce the PoW difficulty

If the IOTA Foundation would decide to lower the PoW difficulty it will reduce the PoW calculation time for slow devices by a lot, while fast devices will see a less beneficial increase. This might reduce the latency gap, which could reduce the advantage of spammer transaction to get confirmed. Besides the uncertainty of this improvement, it could come with side effects that the IOTA Foundation have probably anticipated. But it is an interesting thing to consider none-the-less.

Solution 4: Offloading the PoW

The last solution is the most practical for users of the Trinity wallet or for businesses that want to build an IOTA application from multiple slow devices. The IOTA Foundation has released a piece of software called the PoWbox, which allows you to offload your PoW to a server. For any business application, this means you could run all the PoW calculation on a single machine, reducing the need for powerful hardware on multiple locations. In addition, this will speed up the transaction and therefore increased the CR. Other users could use this to offload Trinity transaction to your desktop, or even pay another entity to do your PoW (Oh no, I just introduced optional fees to IOTA).

Important architectural decisions like this show that it is difficult to develop on the IOTA platform. IOTA is however a very useful platform to consider for your business application as it brings all the benefits of blockchain, for free and without scaling issues and has a lot of future potential.

If you want to learn more about developing with Blockchain or IOTA:

Check out our blog: IOTA Deepdive: Consensus on the Tangle.

Contact me for consultancy or development for your projects via jmillenaar@vxcompany.com.

Meer informatie