The EOS community is once again left looking for solutions now that developers have identified a smart contract bug that allows malicious contract authors to effectively consume network resources owned by other users.
Recently, developers discovered that attackers could create malicious smart contracts that exploit the scripting language’s notifications feature, which allows one contract to notify other contracts of specific events (e.g. an incoming token transfer). The malicious contracts use that feature to fill other users’ RAM with “garbage” data, permanently freezing the RAM and preventing victims from using it for valid purposes or selling it back to the network.
The exploit can affect both ordinary users and certain smart contracts, but, importantly, they’re only at risk if they transfer tokens to the malicious contract.
Dan Larimer, CTO of EOS creator Block.one and the cryptocurrency’s chief architect, addressed the matter on Medium, arguing that it should be characterized as an abuse of a valid feature — he called it “vandalism” — rather than a bug.
He said that, because the exploit takes “advantage of a mismatch between the intent of the users and the actual effect of the code,” the network’s block producers have the authority under the EOS constitution to blacklist the malicious contract while affected users hash out the dispute with the contract author through the network’s arbitration process. As he has argued in the past, the “intent of code is law.” He also noted that many EOS wallets warn users when a transaction may consume RAM.
Larimer further proposed a block producer-only protocol upgrade that, if adopted by all active block producers, would prevent the recipient of action notifications from unexpectedly consuming the sender’s RAM.
In the meantime, a development team operating under the name EOSEssentials has created an effective, albeit mildly complicated, workaround for users worried about losing their stockpiled RAM.
As explained on the group’s GitHub, EOS users can send tokens through a proxy account that holds no RAM, preventing malicious contracts from consuming RAM from the user’s actual account. That account, “safetransfer,” is coded to automatically transfer received tokens to whatever account name appears as the first word in the transaction memo line.
For example, if I wanted to send some tokens to Block.one (they only have 100 million EOS on hand, they could probably use some more), I would send them directly to “safetransfer” and then write “b1” (the firm’s account name) as the first word in the memo line. The memo might look something like this:
“b1 Here are some tokens; hope they help!”
This proxy method is also compatible with other token types, though it will require some manual configuration.
Additionally, the developers said that users should not attempt the proxy token method when interacting with dApps, as the applications will act as if they are interacting with the proxy contract — not the actual user. This is unlikely to be much of a problem, though, since almost no one is currently using EOS dApps (or Ethereum dApps, for that matter).
Images from Shutterstock