Within the past few weeks, EOS blockchain protocol users have been experiencing periodic problems with network access. A recent article written by pseudonymous smart-contract developer and security engineer Dexaran described the apparent root of the problem: an inexpensive technique that allows hackers to “congest” the network — or put it into a low-efficiency mode — with just a few dollar’s worth of EOS.
Seemingly, that exploit allowed a hacker to steal more than $110,000 in cryptocurrency from an EOS gambling application, EOSPlay, earlier in September. However, executives of EOS’s parent firm, Block.one, are not fazed, arguing that the network is operating “correctly.”
EOS basics: Governance, staking and congestion mode
EOS.io is a blockchain-powered smart-contract protocol for the development and hosting of decentralized applications (DApps). It employs a consensus model called delegated proof-of-stake (DPoS) and is governed in accordance with the EOS User Agreement (EUA).
Per the agreement, changes to the network can be made when there is a consensus between at least 15 out of 21 Block Producers — i.e., independent entities that are responsible for processing blocks on the EOS blockchain.
The protocol is supported by its eponymous native cryptocurrency, currently the seventh-largest asset by total market capitalization. Those tokens are at the core of the in-built resource staking mechanism, one of EOS’s distinctive features. Whenever a transaction is submitted to the EOS network, Block Producers have to process it.
The length of time (measured in microseconds) that a Block Producer requires to validate the transaction is called CPU. Put simply, EOS users and developers can get access to chainwide CPU and bandwidth resources by staking their tokens. Blocks are produced every 500 milliseconds. Each Block Producer has 200 milliseconds to validate the block. The remaining 300 milliseconds are left for distribution across the network.
Notably, within the cap of 200 milliseconds, there is also a percentage threshold at which rate limiting begins across the network. In other words, when a block reaches the limit of 10% of the total 200 milliseconds CPU allowed per block, it triggers the CPU allocation algorithm to go into “congestion” mode.
“Before this limit is reached, all users can freely transact on the network as it is not in ‘congestion mode,’” the article’s author explained. “Once this limit is passed, users are throttled back to their pro-rata share of the total CPU-per-staked-EOS allotment.”
As per another article penned by EOS Canada, a major Block Producer in the EOS blockchain network, if there were 1,000 tokens being staked for CPU at a given moment, and a single account had 20 tokens staked, then that account would be guaranteed 2% of the total CPU capacity of the network.
However, if the network hasn’t reached the threshold at which rate limiting is activated (not in “congestion” mode), it allows that account to push transactions through above its guaranteed amount of 2%. Once that threshold is passed, the account cannot exceed the allotment. Moreover, during the “congestion” phase, the amount of CPU of each user starts decreasing until every congesting party runs out of CPU and stops taking CPU-consuming actions.
Daniel Larimer, co-founder of EOS and chief technology officer at Block.one, refers to this mechanism as a “free benefit” of the network:
“Owning and staking #eos gives users a prorata share of available bandwidth. When people don’t use their share it is redirected to others on a prorata basis. During heavy use users no longer receive this free benefit.”
Problem: Congestion mode is too easy to trigger
The problem, Dexaran argued, is that the congestion mode is too easy to trigger. After analysis, the smart-contract developer noticed major CPU usage spikes at the beginning of each hour, allegedly caused by a betting DApp called EOSBetDice. Dexaran then decided to evaluate how much CPU is needed to push the network into congestion.
For the experiment, the developer staked 7,156 EOS for CPU. That amount of EOS can be borrowed from resource exchanges at the low cost of two EOS per month (less than $6), Dexaran stressed. To see how the test would affect average EOS network users, the security engineer preselected three random user accounts who were online playing the EOSKnights DApp right before the session started.
The developer then executed a contract that spawned lots of deferred transactions with a delay of one second, with each transaction consuming “25 to 27 ms of CPU.” After monopolizing the CPU utilization for an entire minute, the contract pushed the EOS network into congestion mode. As a result, all three sample accounts were out of CPU and therefore “frozen completely” — basically meaning that all casual EOS users were unable to engage with any DApps on the network at the time.
Two minutes later, the aforementioned EOSBetDice DApp — which caused regular CPU spikes every hour, independent of the experiment — started operating as per the schedule. By consuming even more CPU from the network at the time it was already overloaded, it involuntarily contributed to the congestion initiated by Dexaran. “The more CPU you consume in a row, the ‘deeper’ a congestion mode will be, and the longer it will take for the network to recover to its normal mode,” the developer noted.
As a result, the EOS network went into even “deeper” congestion, and CPU availability reportedly shrunk by 35 times for all EOS users. “No matter how much EOS you staked for CPU — if you have used more than 3% then you would be frozen,” Dexaran observed.
After Dexaran’s contract and EOSBetDice stressed the network for a total of five minutes, the network ostensibly stayed paralyzed for the next 10 minutes. After six more minutes passed, it had largely recovered, but the lending price of EOS at resource exchanges was still about three times higher than normal, indicating that the network required high amounts of tokens allocated in CPU at the time due to the stress test.
The network completely restored only 30 minutes after the last “malicious” action. That gives users “a window of 25 minutes until the next congestion session,” Dexaran noted, since the attack can be performed every hour, according to the developer’s estimations. “7000 EOS is enough to push EOS network into a congestion mode for a decent amount of time,” the researcher concluded, adding:
“The described congestion session will only cause problems for (1) users who spent a certain share of their CPU bandwidth, (2) users with very low CPU bandwidth staked. The described congestion session has no impact on (1) DApps that have a lot of CPU available, (2) users who do not engage in any activity and have their CPU fully available (assuming that these users have enough CPU to make a single tx).”
In addition, Dexaran stressed that while some EOS users could call him or her a “hacker” due to intentionally overloading the network, “I’m doing exactly the opposite: I’m protecting my investments and yours.”
Notably, a couple of days prior to Dexaran’s entry on EOS congestion being published, developer Christoph Michel wrote a blog post linking the recent EOSPlay casino hack to network congestion, hence showcasing how the network problem might be exploited for profit.
According to Michel, the attacker rented EOS tokens from REX, a CPU and NET resource rental market, and then stacked them to increase both his and EOSPlay’s CPU to ensure the casino stayed functional — therefore remain able to pay out his bets. The hacker then spammed the network with transactions similarly to Dexaran, and played several dice games on EOSPlay, betting on a 50/50 outcome. Given that EOSPlay looks at the block hash of the result block and takes the first two characters — starting from the right and between zero and nine — as the dice roll, one has to predict the block hash of the result block to win the game.
“The only unknowns in the prediction are the transactions included in the blocks,” Michel explained. “But what if one could just spam and congest the network so nobody else can send transactions?”
According to the developer, that is exactly why the attacker borrowed EOS to spam the network: to have control over the network and therefore be able to predict the block hashes and win most of his or her bets. In case of a wrong prediction, the attacker could send another random transaction to the block and hence have an extra “coin flip,” greatly improving the odds.
Ultimately, the hacker used just 300 EOS, worth a little over $1,000, which he or she could have rented for a couple of dollars. In return, the fixed winning galore brought in over 30,000 EOS, or around $110,000.
EOS developers ensure that the network is “operating correctly,” not all agree
Dexaran’s congestion experiments haven’t gone unnoticed, as a number of users have reported having “CPU problems” on Twitter and Reddit. Denis Bredikhin, CEO of Graphene Lab, a team of smart contracts developers, confirmed to CryptoX that users of its poker-based EOS betting DApp has also experienced problems over the past weeks, although the application itself was not compromised. Bredikhin said:
“At the peak of spam, players even with 8-10 thousand EOS allocated to CPU, could not do any operation.”
According to him, starting from Oct. 1, the players have to allocate “up to 10,000 EOS” in CPU so that the game would not stop for them during spam sessions. Meanwhile, Block.one’s Larimer has taken to Twitter to reassure the community that EOS is “operating correctly.” He wrote:
“This is no different than when attackers flood eth or bitcoin with high fee transaction spam. The network didn’t freeze for token holders, there was just no extra bandwidth available for free use.”
Some community members beg to differ, however. “The difference between this attack on EOS and a high fee spam on BTC or ETH is you can still pay more to send a transaction on BTC or ETH,” argued Rob Finch, CEO of U.S.-based EOS Block Producer CypherGlass. He added:
“Many EOS users did not have enough CPU to rent more CPU so it did freeze for them. Operating correctly’ is not the best response IMO.”
Another EOS user, blockchain entrepreneur Jared Moore, confirmed that the network was unusable for DApps or his wallet. He also wondered whether Block.one would “help the EOS community out and publish guidelines for how to prevent REX-attacks.”
CryptoX has reached out to Block.one for further comment and will update the article once more information is obtained.
