Debunking Claimed Vulnerability in EOSIO Smart Contract System
A story has been circulating that EOSIO is vulnerable to the same kind of bug as the recent “batchOverflow” bug that crippled many ERC-20 tokens on Ethereum. The team at Chengdu LiaAn Technology Co (LianAn Tech) and its research platform VaaS (Verification as a Service) has managed to prove that EOSIO is Turing complete and capable of replicating any logic, including the logic behind the batchOverflow bug.
The problem is not a security vulnerability, as they represent, but the result of poor coding practices. There is nothing a smart contract platform can do to prevent developers for making mistakes. Such mistakes are not security vulnerabilities in the underlying platform.
That said, there is a major difference in the options available to developers smart enough to adopt good conventions. One of those options is the implementation of “smart integer” wrappers that automatically check for these kinds of overflows without adding any extra noise to the code.
For example you could use a checked_int64_t as defined by boost multiprecision. A simple typedef could convert unsafe code into safe code that would fail if any overflow occurred. The combination of c++ templates and operator overloading means that using safe math is as seamless as using unsafe math.
Any platform that forced developers into always using “safe math” also limits developer flexibility and/or performance in situation where overflows are desired.
In fact, there are many cases where simply preventing overflows on standard-sized types is insufficient. What if you want to have a safe int that keeps all values in a defined range? With c++ templates you can created a bounded integer class. There is no easy way to achieve the same, compile-time-checked, code, in simple languages such as Solidity.
If one wants to compare platforms one should consider the safety and readability tools available to developers who choose to adopt them and compare quality based on best practices. On solidity you are forced to use unreadable functions to wrap all math. The loss of readability due to inability to use the built in operators for +/-* is just as bad for security as the lack of bounds checks.
The other factor to consider is runtime performance of various security measures. C++ compilers can often do compile time checks, optimize, and inline many of the math checks down into the minimal assembly necessary. Similar checks in languages like Solidity force the use of function calls and lack ability to inline code due to the immaturity of the developer tools compared to the battle-tested C++ tools available.
Ability to Update Code
In my recent tweet about the “batchOverflow” bug I made the case that developers are not perfect and that code needs to be updated. A good platform will make updates easy by default rather than difficult. Users should be forced to explicitly mark a contract as immutable. Furthermore, even contracts marked as immutable by their creator should be mutable by the community without requiring a hard fork.
The team at LianAn Tech and other bloggers which report on this issue have constructed a strawman argument against EOSIO. The result of their irresponsible reporting is to mislead those who don’t understand the technology. As an industry we need people who can accurately understand the difference between a security vulnerability (platform not behaving as designed), a user error (developers not using the platform properly), and a fundamental platform design flaw (a platform not giving developers tools to protect themselves).
EOSIO is designed to give developers the most robust toolset for writing high-performance, high-quality, low-bug-count contracts and to allow the platform and the contracts to recover gracefully when all else fails.