|
Getting your Trinity Audio player ready...
|
- Network load is a security variable, not just a performance one: low or falling traffic in a DAG ledger significantly increases the probability of a successful double-spending attack, because honest nodes accumulate confirmatory weight more slowly and attackers need proportionally less computational power to outpace them.
- The sudden transition from high to low load (H2LR) is the worst-case scenario — producing confirmation delays even longer than steady low-traffic conditions, due to the large backlog of unprocessed tips inherited from the busy period.
- Raising the confirmation threshold is an effective defense against double-spending in all load conditions, but it directly increases confirmation delay — a hard trade-off for IoT micropayment use cases that protocol designers must calibrate to their specific deployment environment.
Blockchain promised to make the Internet of Things more secure, decentralized, and efficient. But researchers at Beijing University of Posts and Telecommunications identified a fundamental problem hiding inside one of its most promising alternatives: the same design that makes DAG-based ledgers fast and feeless also makes them dangerously vulnerable the moment network traffic slows down.
Their analysis, focused on IOTA’s Tangle — the leading DAG-based ledger by market capitalization — shows that network load is not just a performance variable. It is a security variable. And in the real-world IoT environments these systems are designed for, load is rarely steady.
About the research: Li et al. built a Markov chain model to mathematically capture DAG consensus behavior across four distinct network load conditions — steady high, steady low, high-to-low transitions, and low-to-high transitions — then validated the model against simulations. They also modeled double-spending attack probabilities under each condition. Parameters: transaction reveal delay 1 second, high arrival rate λ=50 tx/s, low arrival rate λ=0.5 tx/s.
Why DAG was supposed to fix blockchain’s IoT problem
Traditional blockchain designs like Bitcoin and Ethereum process transactions in a linear chain, one block at a time. That bottleneck caps Bitcoin at roughly 7 transactions per second and means waiting up to an hour for a payment to be considered final. For IoT applications — where thousands of low-cost devices are constantly exchanging micropayments and sensor data — those numbers are impractical. The fees alone would exceed the value of many transactions.
DAG-based ledgers sidestep both problems by abandoning the single chain entirely. In IOTA’s Tangle, every new transaction must validate two earlier ones before joining the network. There is no block reward, no mining competition, and no transaction fee. Because multiple transactions can be added simultaneously in a branching structure, throughput scales with the number of participants rather than being capped by block size. The system is designed to get faster as it gets busier.
Also Read: Inside Starfish: The Consensus Protocol Powering IOTA’s Speed, Security, and Scale
That last property turns out to be a double-edged property. The system is also designed — though not intentionally — to get less secure as it gets quieter.
The load problem: what happens when traffic slows
In a DAG ledger, a transaction is considered confirmed once enough subsequent transactions have built on top of it — measured by a metric called cumulative weight. The higher the transaction arrival rate, the faster that weight accumulates and the sooner confirmation happens. This works well under steady, high traffic.
The researchers identified four real-world load conditions and modeled each one. Two are steady — consistently high or consistently low traffic. Two are transitional: a sudden drop from high to low, and a sudden rise from low to high. The transitional states are where things get complicated.
High Load (HR)
Fast confirmation but includes an “adaptation period” where the network’s computational power can be partially exploited by attackers before a transaction is fully covered.
Low Load (LR)
Slow confirmation and significantly higher double-spending vulnerability — an attacker needs far less computational power to outpace honest nodes.
High-to-Low (H2LR)
The worst-case scenario. Confirmation delays can exceed even steady low-load conditions because of the large number of pending unprocessed tips inherited from the high-load period.
Low-to-High (L2HR)
The best-case scenario. Confirmation speeds up dramatically because every incoming transaction covers the observed one directly. Security also strengthens quickly as load rises.
The high-to-low transition produced the most striking finding. When traffic suddenly drops — which is normal in any real IoT network, where devices sleep, disconnect, or go idle — the system doesn’t just slow down. It can perform worse than it would under steady low traffic, because the large backlog of unprocessed tips from the busy period takes time to clear. Confirmation can take substantially longer than expected, and the window of vulnerability to attack widens in the process.
The double-spending threat: quiet networks are dangerous networks
In any distributed ledger, the primary adversarial threat is double-spending: spending the same funds twice by creating a competing transaction history and making that history outweigh the legitimate one. In Bitcoin, pulling this off requires controlling more than half the network’s mining power — a significant barrier. In a DAG ledger, the equivalent barrier is the cumulative weight of the honest network’s transactions. When traffic is high, that barrier rises fast. When traffic is low, it rises slowly.
The researchers found that an attacker using the “parasite chain” strategy — where a fraudulent transaction history is built offline and broadcast after a legitimate payment is confirmed — can succeed with dramatically less computational power during low-load periods. The math is stark: the probability of a successful attack in low-traffic conditions is orders of magnitude higher than in high-traffic ones, even with the same attacker resources.
The adaptation period in high-load consensus — the time before a transaction is covered by all network tips — creates a window where an attacker can effectively borrow the honest network’s computational power. Timing the attack correctly to exploit this window is a viable strategy.
In high-load conditions, there is a subtler risk. Early in a transaction’s life — during what the researchers call the “adaptation period” — it hasn’t yet been covered by all the network’s active tips. An attacker who builds a parasite chain during this window can benefit from the honest network’s computational work rather than competing against it. The paper shows that for transactions confirmed during the adaptation period, the attacker’s task is effectively easier than it would appear, because the confirmation threshold is reached before the network’s full weight is behind the transaction.
The optimal attack strategy, the researchers conclude, is to build the parasite chain at the latest possible moment before the honest transaction is indirectly approved by all tips — and to anchor it to the current tips rather than earlier transactions. This minimizes the computational lead the attacker needs to overcome, maximizing attack success probability.
The confirmation threshold trade-off: no free lunch
The most direct defense against double-spending in a DAG ledger is raising the confirmation threshold — requiring a higher cumulative weight before treating a transaction as final. The researchers confirm this works: a higher threshold makes successful attacks substantially less likely, and the effect is consistent across all four load conditions.
The catch is equally confirmed: a higher threshold means longer waits. For IoT systems processing micropayments between resource-limited devices, that’s not an abstract trade-off. It directly affects whether the technology is practical at all. A smart meter waiting several minutes for a low-value energy transaction to confirm is a design failure, even if it’s a secure one.
The paper doesn’t prescribe a universal threshold — it can’t, because the right value depends on the specific deployment. But it provides the mathematical framework to calculate the trade-off for any given combination of network load, attacker power, and required confirmation speed. That’s a meaningful tool for engineers actually building these systems.
What this means for IoT deployment
The research has concrete implications for anyone designing or evaluating DAG-based infrastructure for real-world IoT applications — which, per IBM’s own forecasts cited in the paper, the industry has been moving toward for years.
First: network load monitoring is not optional. A system that behaves well under load testing may behave very differently when a subset of devices goes offline overnight or during low-activity windows. Security assumptions made at design time need to account for the realistic distribution of traffic, not just peak conditions.
Second: the adaptation period vulnerability in high-load environments is not well-understood in prior literature. The paper is the first to formally model it as an attack surface. Protocol designers should treat it as such.
Third: the high-to-low load transition is the highest-risk scenario for any practical deployment — worse than simply operating under low load. Systems that will experience variable traffic need confirmation thresholds calibrated for their worst-case load state, not their average one.
The researchers acknowledge two important limitations. Their models for unsteady regimes capture abrupt changes rather than gradual shifts, which they note is a simplification of real network behavior. They also restrict the analysis to Tangle specifically — the mathematical approach doesn’t transfer directly to other DAG systems like Byteball or Hashgraph, which have different consensus mechanics. Both are directions they flag for future work.
The open questions
The paper closes a significant gap in the formal analysis of DAG consensus security — but it opens several follow-on questions worth pursuing. How should protocol designers set dynamic confirmation thresholds that adjust in real time based on observed load? What does the attack probability look like under slow, gradual load transitions rather than abrupt ones? And how do the findings translate to Byteball’s “main chain convergence” or Hashgraph’s “famous witness” election mechanisms, which play analogous roles in those systems’ security?
DAG-based ledgers remain among the most credible technical candidates for IoT-scale distributed infrastructure — the throughput and fee arguments are real. But this research makes clear that deploying them without understanding how traffic variability affects security is not a minor oversight. It is a structural risk that needs to be designed around, not assumed away.
Based on: Li et al., “Direct Acyclic Graph-based Ledger for Internet of Things: Performance and Security Analysis” · Beijing University of Posts and Telecommunications ·
Disclaimer: The information in this article is for general purposes only and does not constitute financial advice. The author’s views are personal and may not reflect the views of Chain Affairs. Before making any investment decisions, you should always conduct your own research. Chain Affairs is not responsible for any financial losses.
