Anti-spam in the Kin Blockchain (Part 2 of 2)
This post is the second of a two-part article discussing anti-spam in the Kin Blockchain. Here we will dive into the anti-spam design and implementation, following the research effort discussed in part 1.
Kin Anti-Spam System
The initial version of the implementation can be roughly described as follows:
- We prioritize transactions for digital services and their users first, and then give room for other users. By digital services we mean any online service that integrates Kin.
- Transactions related to digital services are free from fees.
- We give each digital service the flexibility and responsibility to implement anti-spam for its users how it sees fit.
Anti-Spam Implementation
After all the work above was done, we converged on a solution. It is based on the idea that if our network is aimed to align and join digital services, brands, and consumer app developers, it would make most sense to design an anti-spam system focused and centered around them — giving them the power and legitimacy to affect the ones using the network. Which is, in turn, their users.
Deep dive
Now that we’ve talked about the concept of what we’re doing, let’s dive into the topic and understand how this exactly works:
- We will create a “priority whitelist” that includes all digital services, brands, and app developers. We initially assign a portion (ex., 95 percent of every block) for prioritized transactions. Digital services listed in the whitelist will be able to prioritize transactions for their users according to how they see fit. These transactions will be feeless.
- Initially, priority will be split equally between prioritized digital services. The Kin Foundation will monitor this behavior and make changes as the ecosystem grows.
- The remaining portion (ex., five percent) will be left for de-prioritized transactions. Think of these as “normal” transactions that you’re already familiar with — they cost a fee, and transactions are sorted and processed in a block based on the one with the highest fee. De-prioritized transactions compete for a place in a block using fee auction (i.e., the transaction with the highest fee gets priority if there is not enough space in the block).
- Managing which digital services are added to the whitelist, along with the ratio between prioritized and de-prioritized transactions will be done by a federated group.
Let’s summarize the prioritized and de-prioritized “transaction flows” in a diagram:
Let’s also dive into what we are gaining and compromising on by using this design:
Benefits
Business goals
It achieves the business goals we set for ourselves above. In addition, it also prioritizes digital services first and their users above all others.
Anti-spam responsibility on digital services
Instead of relying on a generic, one-size-fits-all system like transaction fees, we are delegating and giving digital services the flexibility and responsibility to design and implement anti-spam in their services on their own. They can choose who to rate limit and who to prioritize according to their product use cases. Catch-all solutions will never be as effective as ones implemented by a digital service itself on its own user base, tailored to its specific use case.
Be forgiving to digital services
If a digital service is under a spam attack which results in it being removed from the whitelist and thus de-prioritized temporarily, it doesn’t incur a financial penalty — unlike in the case of transaction fees, where it has to subsidize fees. The digital service doesn’t have to pay anything. In the worst case, its users can still operate on the network, spending the transaction fees from their own account.
Flexible
This solution gives us flexibility in solving future unexpected problems. For example, consider a case where a digital service uses an internal ineffective anti-spam system, and an attacker uses that to spam the network. This will result in the digital services to be removed from the priority whitelist, being unable to prioritize transactions for its users, who will experience higher response time and degraded performance. In this case, the business as a whole would be negatively affected. We want to ensure mistakes made by digital services will not be heavily penalized in such cases. Most importantly, they will not incur any financial punishment, since this can negatively affect their willingness to join and experiment with the ecosystem. In addition, their transactions should still have higher priority than all other users in the network which do not relate to any digital service. Specifically, their users must still be able to operate on the network with some level of priority in order to not suffer any performance issues. This is one issue we have already recognized, and our design lets us solve this in a future version, where we could create multiple “priority tiers.” All digital services start at the top tier and share the same priority. If a digital service suffers a spam attack, it can be “demoted” to a lower priority tier, which is still above the prioritized tier. Thus, its users will still enjoy some level of priority. Later when the spam issue related to that digital service is resolved, it can be “promoted” back to the top priority tier along with all other digital services.
Compromises
Unequal
This design puts users not belonging to any digital service in second place in the blockchain. As a product-focused company seeking to align brands along with it, this is a practical compromise we are willing to make in order to get things moving. We will tackle this issue, but first we have to make sure we have a thriving ecosystem of apps that other digital services are willing to jump into and experiment with. Also, note that we still leave some room for de-prioritized transactions in every block.
Novel Design
This design is quite novel, and thus needs to prove itself to be stable, like everything that is new. This will require us to monitor and maintain this implementation over time.
Release
We have already finished developing and testing the initial version, and will deploy it along with the new Kin Blockchain. The development effort can be followed on our Core repository.
Looking Forward
It is important to emphasize that this is an ongoing project, starting with this initial version. As the ecosystem evolves, new challenges will appear that require us to make changes. We prefer to iterate over time according to the changing environment, rather than committing to a single, static, inflexible solution.
During the development of the anti-spam project, we spent many hours considering many angles of the topic. Our work is open for review and we welcome any constructive comments. Feel free to comment on this post or open an issue in our Core repository. Until next time!
Go back to part 1 of this article.
