Anti-spam on the Kin Blockchain (Part 1 of 2)

Anti-spam is an important topic in the cryptocurrency industry. Over the past decade, we have witnessed numerous spam attacks on multiple popular blockchain networks. Extensive brainstorming and research are invested worldwide on how to implement transaction and account creation rate-limiting. The results have been effective to some degree, but the battle against spam and denial of service attacks continues.

Kin is aiming to be the cryptocurrency for consumer apps. Companies in the digital world are integrating Kin into the center of their user engagement strategy, and use it to solve real customer problems.

Our goal is to onboard applications and digital services with user bases ranking in the millions or more. Soon after the Kin project was launched at the end of 2017, it became clear that if we want to achieve that goal, we have to tackle the potential issue of transaction spam. We understood that it was necessary to invest the resources to ensure our blockchain will be capable of handling the load that comes with these large user bases, while providing a sufficient anti-spam implementation.

Here, we’ll discuss the research efforts done prior to designing and implementing our anti-spam system for the Kin Blockchain.

Impacts of Spam

We started our design process by breaking down the primary negative impacts of transaction spam on our blockchain, focusing on our product vision and use cases. We also took into account the impact of the most popular solution that exists today to mitigate spam: transaction fees. We converged on three high-level topics:

1. Operational impact
2. User experience impact
3. Financial impact

Operational Impact

First and foremost, spam can degrade the performance of a network, rendering it partially or completely unusable for extensive periods of time. It also negatively reflects on the public image of the blockchain, potentially damaging its growth and mass adoption potential.

Impact on User Experience

Transactions fees are commonly used as a, somewhat, effective way for mitigating spam. However, they have the negative impact where an entity willing to use the network (e.g. a user sending a payment), has to pay something extra just to process its transaction.

In the case of Kin, we onboard companies along with their entire user base. These users originate from industries outside of the cryptocurrency space, and have different expectations about both the cost of using applications and digital services. Specifically, in regard to fees, they do not expect to pay anything at all for using a digital product. Asking them to pay such a fee will have a negative impact on these users, and it might cause them to stray away from using the product completely.

Financial Impact

The above reasons force a situation where digital services need to subsidize user fees themselves. When a digital service has millions of users, the aggregated sum of fees imposes a large financial burden on that company, and it is most certainly a big hindrance when one considers joining the Kin Ecosystem.

Attack Vectors

“Have you got anything without spam in it?”

While researching the impacts above, we came to the conclusion that we needed to find an alternative to transaction fees that mitigates the aforementioned attack vectors. Here is a definition of the attacks we want to prevent:

Denial-of-Service / Transaction Spam

An attacker can spam the network with “garbage” transactions, up to the point where legitimate transactions cannot be processed for a sustained period of time. This can also be called a denial-of-service (DoS) attack. This practically means applications and digital services cannot operate over the network until the attack is over. “Low-value” means transactions that don’t contribute to the businesses and brands operating on the network.

Sybil Attacks

An attacker can create multiple redundant accounts operated by a single entity. This can result in various negative consequences:

1. Pocket subsidies: An attacker can pocket subsidies funded by a digital service when opening a new user account. This is done by the attacker opening multiple accounts in the service, and then transferring the funds to another wallet it controls, which aggregates the funds from all accounts that were opened.
2. Bypass rate-limiting: If we apply some sort of transaction rate-limiting on every account, limiting each to one transaction/second. For example, if the block can hold 525 transaction at maximum, an attacker can still create 525 accounts, generating a single transaction from each one, and still spam the network with 525 transactions/second.
3. Infrastructure encumbrance: Spam transactions unnecessarily create an encumbrance on infrastructure costs, namely storage, memory, network, and CPU. This is while they don’t provide any business value and/or make any valuable transactions.

After understanding what exactly we are trying to mitigate, it became clear that we need to find a solution that mitigates both transaction spam and Sybil attacks together.

Business Goals

We looked at the list of business goals we are aiming for when selecting an anti-spam implementation.

It’s important to note that these goals are directly affected by our product vision and market, which is different from other popular blockchain networks. Specifically, we do not use a completely permissionless blockchain, but primarily aim to align brands and companies. To explain a little bit more, here is an elaboration on the difference in product visions between permissioned and permissionless blockchain products in a The Stellar Blockchain and The Story of the Federated Consensus from part of our Blockchain Academy meetups.

These are the primary business goals we care about in regards to spam mitigation:

Anti-Spam Effectiveness

Obviously, the implementation has to mitigate the attack vectors mentioned above: Denial-of-service and Sybil attacks.

Financial Encumbrance

When a digital service has to pay transaction fees for its large user base, the aggregated sum can become quite large. These could be subsidized by the digital service itself, or granted by the Kin Foundation to the digital service.

However, in the long run it is not sustainable for the Kin Foundation to grant subsidies in order to incentivize digital services to join the ecosystem. In addition, digital services will prefer to avoid having to put down cash and subsidize its users transacting on the network. Avoiding this would lower costs of “infrastructure”.

User Experience

User experience related to anti-spam can be described as follows:

1. Account: How much is a user’s balance affected due to anti-spam measures? Does the user have to pay for transaction fees?
2. Device: How much is a user’s device (i.e., mobile or desktop) affected by operating on the network? How much energy does it consume from the device? Does it heat or slow down the device? What are the network costs (airtime)?
3. Accounts with high transaction rate: Some accounts (ex., exchanges or large digital services) can have legitimate high transaction rates. We should avoid impacting their operations in a negative way.

Store Compliance

Google Play and the App Store might not approve every anti-spam method that we find effective. For example, Google might not allow Android apps to apply proof-of-work.

Implementation Difficulty

How difficult it is to implement a specific anti-spam system, specifically for the Kin Foundation, and all digital services.

Current Solutions

As we moved forward with the development process on the issue of spam prevention, we understood that there is not a one-size-fits-all solution that is 100 percent effective. Like everything else in life, every solution has its pros and cons, and always compromises something to gain an advantage in something else.

For example, fees are a catch-all solution that is indeed effective to some degree. However, it has the negative impacts mentioned earlier. In addition, it does not differentiate between various use-cases in the network. For example, users of a messenger app might generate a very different transaction load than, for example, a music sharing app. Thus, the messenger app may potentially end up paying more fees.

Another example would be Nano’s or IOTA’s proof-of-work. Here, no fees are paid and thus there’s no immediate financial impact. However other things are being compromised instead. For example, applying proof-of-work before submitting a transaction can take time, slow down and heat the device, and also drain battery. This would be unacceptable in today’s application development standards.

These all are a few sample implementations that were considered among many others. No matter which solutions exist today, each blockchain has to choose one and make compromises. Most importantly, these considerations need to be made based on the product vision for which the blockchain serves as an infrastructure.

Part 2

Part two of this article will dive into the anti-spam design and implementation of the Kin Blockchain, following the research efforts discussed here.

Stay tuned!