For confidence thresholds of 99% (resp 99.9%, 99.99%, 99.999%), the smallest ratio of attackers for which we observed bad consensus (1 in 100,000) was 1.238% (respectively 1.811%, 5.376%, 11.513%).

Number of consensuses won by the attackers during our simulations

While having an erroneous result achieving consensus is technically not impossible (and cannot be guaranteed not to happen), it is extremely unlikely. In the meantime, attackers would lose a lot of money from their commitment funds being redistributed to honest workers. Figures in the previous section show that in order to notlose money (red curve above 0), an attacker would have to control over ⅓ of the workers in a pool. Even if they ever did, they could win much more by using all those agents (and staked funds) to do actual work for the platform.

While increasing the confidence threshold can provide protection against large attacks, it also has a price. In our simulations, requiring a confidence score of 99.999% to achieve consensus doubles the number of workers required to achieve consensus (on a platform without any attacker) compared to a targeted score of 99%. This means that, in order for the worker to get the same reward, the users would have to pay twice as much for the extra confidence.

In addition to security, changing the confidence threshold also impacts the execution pattern. Using a confidence threshold of 90% or less would probably allow a worker to achieve consensus alone, thus returning a result with minimum delay. This would provide a QoS (quality of service) similar to usual cloud providers. On the other hand, using a confidence threshold above 99.99% would prevent any worker to achieve consensus alone, and would lead to systematic replication, increasing confidence in the result as well as the cost of running the application and the delay before consensus is achieved and the result can be sent back to the user.

What about erroneous ÐApps executions (bugs)?

In the previous section, all bad contributions were originating from attackers, and honest workers were all providing the same result. However, the complexity of application software, their runtime and the hardware they are executed on can lead to bugs or data corruption which do not cause the program to crash but could affect the results produced.

We will designate these potential events as “erroneous executions” of the application. In the worst case, where these erroneous executions were to systematically produce the same (bad) results, we would be facing something similar to the coordinated attack described previously. We showed that if bad results are provided less than 1% of the time, then we can be confident the consensus mechanism will perform correctly.

From an economic point of view, erroneous executions will only marginally redistribute some funds between lucky and unlucky workers. On average, workers will still be rewarded the same amount. Yet, while these erroneous executions do not affect the long-term profitability of running a worker, neither should they have a negative effect on reputation. They should not prevent an honest worker from growing on the platform. Therefore, rather than resetting the credibility to 0 when a bad answer is submitted, we should consider losing only part of the history, either through a ratio (e.g. losing 50% of your bonus) or through a flat rate (e.g. losing 50 points). Providing they still have enough stake, workers would be able to rapidly regain the lost reputation. For old workers, who already gathered RLC through their work, such events would be virtually invisible. The only circumstances where an erroneous execution would have a real impact on the worker would be if it was to strike a young worker, with a low initial stake, before it got time to grow and gather enough momentum (funds and reputation).

Still, efforts are expected from ÐApp developers to write robust code. Worker pools could also use a whitelist/blacklist mechanism to restrict which ÐApps are executed by their workers. While it is not realistic to audit the code of each application, it is possible to use replication to verify the application correctness. More details on that below.

What about attacker-ÐApp coordination?

A more sophisticated attack scheme, discussed by u/mreima on Slack and Reddit, that could be deployed by attackers is to use a specific application to try stealing the stakes of other workers. The idea is that, if the application can manage to detect whether it is running on one of the attacker workers or not, it could leverage this knowledge to perform an attack. If it is being executed on one of the attacker workers, the application would provide the correct result all the time, but if it is running on another worker, it could fail to provide the correct result with some probability.

While we should prevent the applications from accessing information identifying the workers, it might be possible for the attacker workers to intentionally leak information to the applications. Nevertheless, if the application runtime is the same during the application validation and later, during the execution on an honest worker, the application should not be able to evade the validation process and we should be able to detect a high probability of erroneous executions (signalling that the application is not behaving correctly).

But is such an attack more sophisticated than the scenario described before?

We discussed that bugs in applications cause variation in the profit of workers, but the mean profit stays very similar and should not discourage workers. However, this is only true if all workers are identical. If some workers (those owned by the attacker) are guaranteed to never be on the losing side, they will get an “unfair advantage”, and steal money for the other workers.

However, such an application, designed to perform an attack, would require users to pay for its execution. Simulations show that if the attacker has to pay for it, the cost of doing so will far outweigh the benefit from the attack for the commitment funds discussed earlier (x0.2~x0.5). In the end, the honest workers would benefit from the cost paid by the attacker to execute the fraudulent app more then the attacker would steal stakes using the fraudulent app.

That attack is therefore not viable if the application is designed specifically for the attack. It could be viable in the context of a useful application used by many users. However such an application already gets part of the reward, and its reputation among user of the platform would be ruined if such a behaviour was to be proven. Open source applications would be a plus for preventing such types of attacks. Once again, it would be the scheduler’s choice to decide which application can run on the working pool it manages.