Stealth’s Network Clock in Feeless Transactions and Spam Resistance
Recently, the Nano (XNO) cryptocurrency recovered, at least temporarily, from a nearly six week long denial of service (DoS) attack. According to a Nano Foundation blog post, the attack exploited five different attack vectors. Although varied, these attack vectors have the net effect of exhausting resources on Nano validator nodes. …
While the Nano developers issued a patch that helped clear backlogged transactions, much of the recovery from this recent attack can be attributed to a reprieve from the attack itself. Indeed, as of writing this post, a new attack on Nano is underway, temporarily crippling the Nano network.
In today’s blog post, I describe differences between the Stealth and Nano protocols, and how these differences result in Stealth’s having far better DoS resistance than Nano. These differences distill to the prohibitive difficulty of exhausting Stealth’s resources by spamming the blockchain. In this description, I underscore that one key to Stealth’s superior DoS resistance is Stealth’s novel network timekeeping mechanism.
— — — — — — —
Nano
Nano is arguably the leading cryptocurrency for feeless transactions. A feeless transaction does not require the sender or recipient to provide any extra money as transaction fees. Instead of a fee, a user includes a digital attachment with each transaction. This attachment of only a few bytes cryptographically proves that the user did a small amount of computational work specific to the transaction. This “work proof”, allows the transaction to be executed without any additional monetary fee. In other words, if a user sends 1 XNO, then the recipient receives exactly 1 XNO and the sender’s account is exactly 1 XNO smaller.
The Nano protocol has many unique features. Most notably, Nano has a block lattice wherein each account has its own blockchain. Each blockchain records all incoming and outgoing transfers for that account. The lattice structure arises from so-called receiving transactions, where the recipient makes a separate record keeping transaction that references the incoming transaction. The receiving transaction is a prerequisite for spending funds.
Importantly, only the account holder can modify the account’s balance. With spending transactions, the account holder specifies how much to reduce the account balance. With receiving transactions, the account holder specifies how much to increase the account balance.
Although the two-part transaction may seem unnecessary to those unfamiliar with Nano’s design, it is critical for Nano’s high throughput because it allows validators to approve transactions asynchronously. The reason is that validators are never required to consider the ordering of transactions when determining whether an account balance can be spent. The account holder specifies the ordering of credits and debits, making it straightforward for validators to calculate an account balance prior to approving any transaction.
The following figure shows a small block lattice as might be found within Nano’s distributed ledger. Pictured are three chains for three accounts: A, B, and C. Each chain has four transactions (diamonds), numbered 1 through 4. Transaction 1 in chain A is called “A-1”, and so on. Each transaction references up to two other transactions. The first reference points to the immediately preceding transaction in the account’s chain. These types of references are represented by solid arrows. The second type of reference connects a receiving transaction to a spending transaction. These latter types of references are represented by dashed arrows.
The flow of money can be inferred from the dashed arrows. For example, account C sent account B money in transaction C-4. The transfer amount of transaction C-4 was credited to account B’s balance in transaction B-3, so an arrow connects B-3 to C-4.
Note that all arrows point backwards in time. In this latter example, transaction C-4 preceded transaction B-3 in time. This elaborate cross-linking of account blockchains results in a multidimensional lattice, giving the Nano ledger its name.
While time relationships between explicitly linked transactions may be inferred from these references, a full ordering of Nano transactions can not be guaranteed. For example, it is impossible to know whether transactions B-3 and B-4 preceded any transaction in chain A because no path of arrows (moving from tail to head) connect B-3 and B-4 with any transaction of chain A.
A profound consequence of the structure of Nano’s ledger is that Nano has no mechanism for timekeeping. For example, transactions B-3 and B-4 could be separated by one millisecond, or they could be separated by one million years. We can only know, in some cases, a relative ordering by following references, as described above for transactions C-4 and B-3. That Nano transactions don’t have timestamps underscores this absence of timekeeping.
Because Nano has no mechanism for timekeeping, the ages of Nano transactions are impossible to determine with certainty. For transactions that have been approved by validators, the lack of timestamps amounts to little more than an accounting inconvenience. However, for transactions that have yet to be approved, the lack of timekeeping can pose serious problems because validators and other network participants have no temporal information with which to expire transactions.
At first thought, the ability to expire transactions might not seem important. However, the crippling DoS attacks suffered periodically by Nano could be rendered orders of magnitude more difficult if “backlogged” transactions expired and were completely cleared from the Nano network.
Consider the following backlog estimate, generated recently within the Nano Discord chat.
This output shows that over one million Nano transactions are backlogged. A result of the ongoing spam attack, the vast majority of these transactions are generated by the attacker. As transactions build up, the strain on computing resources makes it increasingly difficult for validators to approve (clear) new transactions, creating a vicious cycle of resource depletion.
— — — — — — —
Stealth
Imagine if unapproved Nano transactions expired after only two minutes. To maintain a crippling backlog of one million transactions, the Nano attacker would be required to create 500,000 transactions per minute, or 8,333 transactions per second (tps). Imagine further that Nano were redesigned such that it required a backlog of not one million transactions to cripple Nano, but around ten million.
Now, imagine further that Nano used a hashing algorithm wherein each transaction requires, on average, one second on one 3 GHZ CPU. Now imagine that when saturated with feeless transactions, the Nano network required on average about nine times the work for a single transaction. Translated to GPU computing power, about $7000 of GPU hardware could average about 9 tps. So it would require $63,000,000 of GPU hardware running at full capacity to saturate the Nano network with 5 million transactions per minute and create an ongoing backlog of ten million transactions, given this unimaginably effective design.
Not only would the attacker need $63,000,000 of hardware dedicated to this task, he’d have to pay the exorbitant electricity bills to keep it running all the time. Worse yet, if this nefarious mining setup ever went down, the entire backlog would expire after just two minutes. Even the “stuck” transactions of legitimate users would expire after two minutes, meaning Nano users would never experience the frustration of waiting hours or days for a transaction to process.
All that hardware and all those electricity bills would produce nothing but a temporary inconvenience for Nano users, completely remedied after two minutes of cessation. Clearly it would be foolish to attempt to attack Nano with spam, all because transactions can expire.
Even if an attacker mustered the bankroll to execute an effective attack, the notoriety of the expense itself would likely bring more positive attention to Nano, more than offsetting the potential negative attention that inspired the attack in the first place. Imagine the headlines: “Who is spending $400,000 per day to spam the Nano network?”
In case you are thinking that such a system is too good to be true
– I just described Stealth’s approach to fighting spam.
— — — — — — —
Stealth’s Distributed Network Clock
At the core of Stealth’s spam fighting technology is a novel and unique distributed network clock. I have discussed Stealth’s timekeeping elsewhere, but in short, it obviates the need for network-wide time averaging, depicted in the following image.
In the above image illustrating network time averaging, the network time is 00:00:02 while the real time is 00:00:00, as reported by an official timekeeper like NIST (National Institute of Standards and Technology). Each computer that joins the network queries the network time from its peers, then applies an offset to its own internal clock. For example, computer A has an offset of +1, while computer B has an offset of -1. If a block is produced (right), it carries a timestamp reflecting the network time.
Note that in this type of network timekeeping, no computer has any incentive to keep the correct time. In fact, keeping network time relies purely on altruism.
As a result, this type of network clock is highly fragile and can therefore result in fragile networks. The main reason is that this type of network clock is subject to clock drift. In the above example, the hypothetical network has drifted two seconds from the real time. In practice, cryptocurrency network clocks can drift by many minutes. For example, Solana’s network clock is currently 30 minutes behind real time. Barring a hard fork intervention, this clock drift will likely never be fixed.
Another problem with time averaged network clocks is that malicious computers can join the network and report the wrong time, starting a chain reaction of unsynchronized offsets. For cryptocurrencies, this has resulted in forks that arise because some subset of computers invalidate blocks with inappropriate timestamps. An example is a block that may have a timestamp in the future relative to the network time of some subset of the network.
Instead of a time averaged network clock, Stealth uses a distributed network clock. In Stealth’s clock, computers never query the network time. Instead, they get network time from block timestamps. Blocks carry timestamps given to them by the computer that produced the block. Blocks are rejected or accepted independently by every computer on the network, based on comparison not to the computer’s internal clock, but to other blocks known to the computer.
In this system, block producers are incentivized to correctly guess the internal times of all other block producers without ever asking. If block producers guess incorrectly, they run the risk of having their blocks rejected.
This system distills to focal point game theory, where the best guess for the internal clocks of other computers is a known standard, like NIST time. In other words, no block producer is required to keep good time, but keeping good time maximizes their opportunity for block rewards. The bottom line is that the network doesn’t have clock synchronization, but it still has an emergent accurate and distributed network clock. This network clock is embodied by the chain of blocks produced by the network.
A critical feature of Stealth’s network clock is a robustness that arises from the fact that clock ticks are concrete events — namely blocks themselves. This design means that no amount of poor timekeeping by individual nodes, or spikes in network latency, ever influences network time. Moreover, the Stealth network never experiences drift because there is an ongoing incentive for block producers to keep good time, making best effort internal adjustments as needed. In practice, the absence of an offset, and the influence of game theory, means that block times will never deviate from real time by more than the network latency.
This robustness gives a dependable standard for the expiration of transactions. In Stealth’s feeless protocol, feeless transactions must reference a specific block, and therefore a specific time. This reference is one input for the work required to create the feeless transaction. A computer on the network will invalidate all transactions older than two minutes, by comparing the network time to the block timestamp referenced by the transaction. Invalidation means that the transaction is erased from memory and no longer communicated to any new peers.
A consequence of expiration is that the work required to create the transaction is also expired. To create a new transaction, a sender must create new work. This overwhelming burden of work results in considerable ongoing expense to aspiring attackers.
— — — — — — —
Stealth User Experience Under DoS
One question is whether users would be inconvenienced if an attacker attempted to spam the Stealth network. The answer is slightly.
First, users would be required to compete with the spammer for blockchain space. Users can do this in two ways. One way is simply by increasing the difficulty of their work calculations, waiting on average about ten seconds for the work calculation instead of one second. Another way is by paying a fee to ensure a spot in the blockchain. Currently the fee is equivalent to about 0.0001 USD.
While a fee seems to forego the advantages of feeless transactions, this inexpensive work-around removes practically any reason to spam the Stealth network in the first place. In this way, the fee is a nuclear deterrent. It renders conventional warfare (spam DoS) obsolete, impotent, and certainly not worth the expense.
Second, users that do not produce enough work to compete with the sender will have transactions “stuck” in the mempool. Again, this inconvenience is mild and temporary. After two minutes, these stuck transactions will expire, even during an ongoing spam attack. Once expired, the user will be able to resubmit a transaction, either with more work or with the aforementioned small fee.
In summary, an attacker could attempt a DoS spam attack on Stealth. It would cost a fortune in equipment (millions of dollars) and another fortune in energy costs (tens or hundreds of thousands of dollars a day). It would likely bring much positive press to Stealth as well. A successful attack would mean that users would have to wait two minutes for stuck transactions, and likely need to pay a $0.0001 fee to create a successful transaction after their transactions became unstuck via expiration. Once an attacker gave up, the network would require no more than two minutes to completely recover from the attack.
— — — — — — — — —
Dr. James Stroud, PhD
— — — — — — — — —
