Addressing the EOSIO REX Exploit

The EOS network recently experienced an exploit where a small number of accounts purchased a large amount of REX resources for about 300 EOS and used that to extract 30,000 EOS in manufactured winnings from the EOSPlay gambling app. EOSgo has an article that explains this. In short, by buying a very large amount of EOS CPU resources cheaply, the exploiters were able to essentially shut down the EOS network to nearly all transactions but their own and exploit the process that EOSPlay used to generate random numbers, essentially ensuring that their bets would be winners. Because the EOS network became clogged and the cost of CPU resources grew very large, the EOSPlay app was not able to pause its contract to stem its losses.

While this represents a large loss for EOSPlay, this exploit poses a more substantive threat to EOSIO blockchains. If the chain can be made generally unusable for all by a single user or small cabal, then it greatly limits the value of these chains, particularly for enterprise users or IoT devices. EOSIO creator Dan Larimer has commented on Twitter that the EOS network operated correctly, and that similar types of clogging attacks have been seen on Bitcoin and Ethereum networks. While this is factual, it does not alleviate the fact that such exploits severely diminish the value of these networks as vehicles of the future economy. Bitcoin and Ethereum likely have no clear ways to resolve their issues, but EOSIO networks have greater tools at their disposal. Exploits capable of rendering a chain unusable for most users need not be accepted as proper operation. I propose the following avenue of exploration for resolving this issue. The Telos Core Developers will undertake this exploration for addressing this exploit on Telos and will share our findings with other EOSIO chains. We welcome any interested EOSIO developers to join us as we seek workable solutions.

A Proposed Solution for the EOSIO REX Exploit

No doubt, many factors contributed to the exploiters using this attack vector to syphon off funds from EOSPlay. Among them:

• EOSPlay used a method of random number generation with inherent risks
• EOSPlay did not adequately stake resources for its own usage but relied on free “overflow” resources
• EOSPlay did not provide themselves a lightweight or alternative way to pause their contract
• EOS has abandoned dispute resolution, therefore reducing the risk to the exploiter of tokens ever being recovered once taken

Addressing any or all of these factors will alter the risk/reward calculation for any future users of this exploit. Nonetheless, we must accept that as long as this exploit remains viable, it may be used by bad actors whose goal is not solely to steal tokens from an EOSIO chain but to render it unusable to many. Therefore, no amount of reducing these contributing factors alone will adequately eliminate the risk. This exploit must be addressed in order to ensure each chain’s ongoing viability and attractiveness to developers as a platform.

The simplest way to address this exploit would seem to be capping the amount of REX that any single account can buy. For example, limiting any single account to purchase no more than 0.3% of all REX for CPU at any one time would mean that about 300 accounts would need to be coordinated in order to purchase an amount of resources able to clog the network. While this could certainly be automated, the limitation of REX purchase by any one account would have an additional benefit.

In terms of usage, 0.3% of network CPU should allow nearly 1 million transactions per three-day period if the chain is capable of 89 million transactions per 24 hours, which is the current EOS record according to Blocktivity.

If no single account could purchase more than 0.3% of the available CPU through REX, then apps with greater needs would be incentivized to stake system tokens for the portion of their resources needed above this. With an upward limit on CPU resource purchases from REX, large apps would better able to sustain operations during periods of network attack. This may actually be the more powerful component of this solution. Providing rules to help enforce the use of good practices, such as not relying on free network resource, is a bit like a seatbelt law: some people will see it as intrusive, even if it is effective. Ultimately, the community should decide if preserving the right for a single account to capture the bulk of network resources by purchasing cheap REX is an acceptable practice on the network. At this stage, the TCD is only exploring the feasibility of such a solution.

In tandem with this limit, a small resources reserve maintained by the Telos Foundation or a similar entity on other EOSIO chains would enable apps under attack similar to EOSPlay to at least pause their operations to halt an ongoing exploit. The threat of action to reclaim tokens through on-chain dispute resolution may serve as further disincentive to attempt such an exploit in some cases. Some EOSIO chains will more easily be able to implement some of these approaches than others. Because any such changes have the potential to alter some aspects of token value or app operational plans, chains should ensure that their communities support such changes.

REX is an important tool for dapps and users. However, over-reliance on REX exacerbates the potential of this exploit. Telos may have a particular vulnerability because its very high staking reward has caused a greater percentage of available system tokens to be staked to Telos REX than on any other EOSIO chain.

Next Steps

The Telos Core Developers will begin exploring this possible solution to this exploit to determine what benefits and costs it may have. Naturally, the limit amount of 0.3% is only a jumping off point in exploring this possible solution.

The TCD will welcome input and participation from others interested in exploring solutions to this exploit. Upon achieving a better understanding of the feasibility and ramifications of such a change, the TCD will make a recommendation to the Telos block producers and community and will share its findings with the broader EOSIO community. If the TCD ultimately recommends such a change, the block producers and community may decide whether the situation demands immediate action, a governance amendment ballot, or some combination thereof.

###

About the author: Telos architect and whitepaper author Douglas Horn leads the Telos Core Developers. He is the founder of GoodBlock.io.