

Denial of Service Attacks

Users of decentralised blockchains are not required to provide digital or physical identifiers. This can be beneficial to users who lack identity or are being persecuted because of it. However, systems that do not require identification render themselves vulnerable to Sybil attacks, where a malicious actor produces numerous false identities (in Loki’s case, numerous public-private key pairs) and uses these identities to spam the network with requests.

Many cryptocurrencies have struggled with this problem, and are forced to implement either a fee-for-service model or a proof-of-work model. In fee-for-service models such as Siacoin, users pay for the services that they use. In Siacoins case, the cost is determined per TB of storage per month. Fee-for-service models are effective at reducing Sybil attacks, however, they drive many users away from the system especially when similar services are available for free (such as Google Drive and Onedrive in the case of Siacoin). Proof-of-work systems such as those used in Hashcash and Nano require users to calculate a small proof-of-work before sending a message or transaction. These small proof-of-work systems are arguably more egalitarian than the fee-for-service model but can fall prey to attackers who possess large amounts of computing power.

Loki proposes a modified proof-of-work scheme to address the two largest Sybil attack surfaces in the Loki system; offline messages and path creation. Offline messages present a potential target because each message must be stored by a swarm of nine nodes. Potential abuse could arise where a malicious user overloads a particular swarm with a high volume of 15 messages that it would have to store. In path creation attacks, the attacker seeks to engage in the path creation process with as many nodes as possible, taking up bandwidth resources and denying service to users who create paths through the network for legitimate purposes.

To prevent both attacks, the Loki network requires that a short proof-of-work be attached when both messages and paths are created. For messages, this proof-of-work is calculated as a Blake2b hash of the message. For path creation, the proof-of-work is sent along with the request for a node to be included in the path building process. To ensure scalability and accessibility for mobile users, the proof-of-work difficulty requirement is fixed based on the Time-to-live (TTL) of the message or the path, and not based on global network activity.