Untangling IOTA Spam Protection and Rate Control – Series: Part 7

, ,
IOTA spam protection

Don’t you hate getting spam, both the email type and those letters that you wish people would stop sending you?  You might get an email like “Click here to claim your destination getaway!” or “Find out who’s been looking at your profile…”  Or perhaps in the mail, you get endless credit card offers that somehow you’ve qualified for (and have no desire to activate) or mass mailers that basically imply, “Here, you throw these away.”  There’s another issue to imagine (which is much less likely to happen in the physical world than in the electronic one). 

What would happen if you received 10 emails at a time in your inbox?  Probably nothing, to be fair.  What about 100?  Still, you’re probably covered (albeit a bit annoyed).  Ok, how about 1,000?  Or maybe 10,000?  As these numbers go up and up, you’re bound to eventually drown in emails and not be able to actually do anything with the legitimate emails that you actually care about (assuming you care about your email in the first place, that is 😊). For these reasons, we will be discussing the IOTA spam protection plan.

IOTA Spam Protection

These exact concerns threaten the welfare and well-being of the IOTA Tangle post-Coordicide.  Welcome back to our journey as we take a detailed look at what’s happening in IOTA and how the developers plan to prepare for the inevitable Coordicide.  This is not a simple transition, and as we’ve discovered in our previous posts, it’s going to take a several methodical steps to eventually get to a tangle that can self-sustain, protected by honest nodes and firm technological underpinnings. 

In our last post, we took a look at autopeering and saw how it allows nodes to efficiently find new neighbors upon entering the tangle.  We also studied the concept of node discovery and how new neighbors are identified by existing nodes.  This week, we’re moving on to spam protection and rate control as we seek to work our way through the major pillars that are required for a safe and effective exit of the Coordinator.

Iota Rate Control

Let’s start with the basics again before diving into the deep end.  In any network (such as your home network, the network at your workplace, or even the Internet itself), there is always the need to rate control or limit the rate of transactions on the network.  For example, there are rumors that when Twitter was in its infancy, the social media platform had network difficulties every time Ashton Kutcher would tweet because so many people would respond and react to his tweets. 

This is an illustration of when rate control is required – while Ashton’s single tweet was insignificant in terms of network bandwidth, the sheer number of followers who would respond at one time could cripple Twitter’s backbone because the “transaction” rate was too high. 

Common issues of rate control

There are two common issues that go hand-in-hand with the discussion of rate control.

  • Congestion control – When an excessive amount of traffic hits the network at a single time, there has to be a way to effectively pass it all.  Without an effective strategy to mitigate problems either before they happen or while the network is bogged down, the entire network can slow to a crawl while the routers and switches strain to keep up with the load.  It’s a little bit outside the scope of our discussion here to discuss congestion control (as it’s an incredibly deep topic that has been studied extensively), but there’s a great site that can shed some more light if you’re interested.
  • Spam detection – Like we discussed above, spam is a real problem to deal with in networks.  For example, in IOTA messages are disseminated throughout the tangle via a gossip protocol (so dubbed because “neighboring nodes” on the tangle “gossip” about what’s going on).  These messages comprise information that pertains to the relationships among nodes (somewhat comparable in nature to metadata rather than transactional data).  While this can be a very effective way to distribute such knowledge, there’s a catch here:  there’s no way to determine if messages are spam and accordingly limit their dissemination. 

Additive increase multiplicative decrease

Those are the biggest problems that we face requiring rate control on the tangle.  Albeit this area of study has years of compounding knowledge, it’s not quite a “plug-and-play” solution when it comes to IOTA.  Let’s take a quick aside to better understand this problem.  Most networks today use a strategy called “Additive Increase Multiplicative Decrease” (or AIMD) to model packet traversal across a network.  Take a look at Figure 1 for a better understanding:

Figure 1:  An example of AIMD as utilized by TCP.  Image from here.

The basic premise behind AIMD is that as throughput ramps up over time, the amount of traffic that can be sent with each packet additively increases.  For example, if 20kB can be sent this round, then 21kB can be sent the next round, and then 22kB, 23kB… and so forth.  But what happens when the inevitable limit is hit and no more data can be sent in a timely fashion? 

At this point, the throughput decreases multiplicatively (at 60kB, the next throughput value may drop to 30kB, and then increase to 31kB, 32kB, and so forth).  This is the reason why Figure 1 looks like a sawtooth – there is a gradual increase to a certain high value, then a quick drop followed by another gradual increase until the conversation is over and the connection disestablished.  Since this is such an accepted and widespread solution, it makes sense that the IOTA developers plan to adopt this strategy as-is for congestion control.  However, that’s the easy part of their venture; the tricky part comes when dealing with spam. 

Spam prevention in blockchain

            Spam prevention has, thus far in the blockchain world, been a difficult foe with which to grapple.  How does a network make sure that everyone is provided with the same fair usage and protection regardless of their “size” or apparent power on the network?  So far, many systems have used a proof-of-work (PoW) paradigm to effectively stamp out spam on the network.  Because work has to be accomplished to validate transaction on the network, the likelihood that spam can run rampant is very low, effectively creating an implicit rate-limiting mechanism on the network. 

If it’s that easy, you might wonder, then what’s the problem?  Most PoW systems eventually become dominated by the biggest players on the network.  The “little guys” have nowhere near the throughput as the “big guys”, so the network ultimately becomes less and less decentralized.  Some blockchains, such as that of Ethereum, have attempted and been successful in mitigating this problem, but it’s always a game of “cat and mouse” where the malicious actors find a loophole to exploit, the developers patch it, and the cycle repeats.

            The IOTA developers have decided to explore two different approaches for rate-limiting spam:  adaptive PoW and verifiable delay functions (VDFs) (also referred to as non-parallelizable functions).  (Because of the inherent complexity of these schema, we’re only going to discuss the high-level details here; please take a look at the Coordicide white paper if you really want to get into the excruciating details.) 

Adaptive pow

Typical PoW systems eventually drown out smaller processors as the network’s overall work metric increases.  This leads to large players dominating the validation process.  Bitcoin is a prime example of this:  of the vast number of Bitcoin users on the network, most of the hashing power is controlled by 5 or 6 major players.  

Instead, IOTA hopes to roll out an adaptive PoW system that will enable all devices, whether large supercomputers or small IoT devices, to participate effectively in the tangle.  Basically, this system works by adaptively bounding the devices’ effective throughput or ability to solve PoW problems like in Bitcoin.  An individual device’s throughput is normalized to itself such that every device has essentially the same power.  After some “tuning” of the node, there’s no way for a device to spam the network because it is rate-limited by its previous power profile.

Verifiable delay functions

            Another method considered for rate-limiting is the VDF.  Adaptive PoW functions can do a satisfactory job at limiting the throughput on a network, but VDFs can harness more efficient computational algorithms with equivalent efficacy.  Simply put, a VDF is both difficult to evaluate and simultaneously quite simple to verify.  VDFs are typically considered to be not parallelizable, meaning that it is not possible to split up the load and distribute it across many workers at the same time.  It is for this reason that purpose-built rigs (comprised of ASICs, FPGAs, or other similar circuits) would provide no benefit, hence yielding a fair playing field for both slow and fast nodes. 

The IOTA developers intend to employ a custom implementation based on RSA math (used in asymmetric encryption) to patch together a verification scheme.  The math is shown in the white paper, and while very complex, could yield a promising solution for the next generation of the tangle.

            That’s all folks.  Thanks again for reading on IOTA spam protection.  In the next post, we’re going to finish up the major pillars of the Coordicide by discussing consensus and voting among nodes on the tangle.  We look forward to seeing you then!