More than 1.2 million ethereum applications have used a little-known security tool to help them avoid the costly errors arising from self-executing lines of code known as smart contracts.
Launched by ethereum technology startup Amberdata back in October, the free tool is available for anyone in the general public to interpret the security of active applications on the ethereum blockchain. Smart contracts with bugs that have been exploited have led to huge losses, even to the tune of hundreds of millions.
The feature is one of the many tools encouraging best practice and increased transparency between dapp developers and end-users in the ethereum ecosystem.
What's more, it's a feature that has been around in the broader web space for quite some time. Privacy-minded browser DuckDuckGo recently launched a Chrome browser extension used to rate websites (not dapps) with a letter grade, giving users an easy insight into how well or poorly service administrators protect user privacy.
Similarly, the vision behind Amberdata's security grading tool, as highlighted by Amberdata CEO Shawn Douglass in a press release, is to provide "greater access and enhanced visibility into smart contracts."
But how exactly are these applications on ethereum rated on Amberdata?
Pointing to 13 types of vulnerabilities scanned for automatically by the program, Amberdata CTO Joanes Espanol likened each of these to “engine lights on [a car] dashboard.”
"It just means that I need to check what's going on with the car. Any of these can result in security error," explained Espanol to CoinDesk.
And the more security errors that are detected by Amberdata's security scan, the lower the alphabet letter grade a dapp will receive. These ratings range from an A+ all the way to an F.
But they don't strictly depend on the number of security errors. Each of the 13 vulnerabilities have varying degrees of severity, Espanol explains, that will impact a dapp's final grade. Two common low severity vulnerabilities marked by Espanol include “delegate call to a user-supplied address” and “message call to external contract.”
The latter may pose a potential security risk if a dapp, rather than being self-contained in one smart contract, calls additional contracts possessing buggy code.
Similarly, a delegate call is another operation that is normally used to split smart contract code into multiple sub-contracts, so that any necessary upgrades to the software can be made piecemeal without terminating the whole application.
“That’s the good part of those delegate calls. But the bad part is that now as an owner of the contract, I could start doing bad things. So, I could start replacing contracts that change the behavior of the original [application,]” explained Espanol.
As such, on both counts, Espanol described the security audit as sending out “warnings,” rather than pointing out immediate code errors.
Indeed, one such dapp currently leveraging message call and formerly having deployed a smart contract upgrade using delegate call back in January is TrueUSD. Created by blockchain startup TrustToken, the USD-backed stablecoin on ethereum is currently ranked with a C letter grade.
While that doesn't sound good, looking at the vulnerabilities flagged for TrueUSD, TrustToken security engineer William Morriss told CoinDesk in a former interview all identified concerns were actually not “critical.”
“The vulnerabilities that are being reported are not ways in which we can be attacked … We are aware of them and when people bring vulnerabilities to us we treat them very seriously,” said Morriss.
Elaborating on the matter of message calls specifically, Morriss added that for TrueUSD, all external contracts are owned and operated by the companies themselves as opposed to third parties with potentially lower security standards.
How to get an A+
Errors of "high" severity will hit the application's security rating harder because they indicate a greater potential for code error and exploit.
One of the most common of these, “integer overflow,” indicates operations carried out within a smart contract could generate values exceeding code limitations, leading to wacky, unpredictable behavior that, in the worse case, could lead to loss of funds.
The flipside is “integer underflow,” another vulnerability of "high" severity, by which the exact reverse may happen and a value below the defined range similarly causes erroneous output.
There are also some features in Solidity that dapp developers should just avoid, according to Amberdata's grading system, including “suicide()” and “tx.origin.” The latter is described by Espanol as “deprecated code” that may be removed from the Solidity language altogether at a future date, while the former poses risk of being hijacked by outside parties to freeze user funds - that they can never get back.
Adding that “passive resources” such as written documentation and video tutorials on dapp development are not enough to build secure applications on ethereum, Soriani told CoinDesk:
'It's a new set of problems'
Indeed, when it comes to building dapps, the importance of airtight, impenetrable code cannot be understated. The core reasoning for this is two-fold.
First, unlike traditional applications, dapps are generally open-source computer programs and as Morriss explains, "a heightened level of caution" is required when running code that is "public."
"If there's any bug in a traditional application you might be able to get away with it for several years ... but if you have a bug in your smart contract people are going to find it rather quickly and take advantage of it either to your destruction or to their benefit," said Morriss.
Secondly, dapps on ethereum run exclusively on smart contracts. Specially coded in programming language Solidity and executed in the blockchain's nerve center called the Ethereum Virtual Machine (EVM), a key strength of dapps is that they can't be changed.
The downside to this is obvious. Programmers are not easily able to correct errors or bugs in the software once deployed on the blockchain.
Calling it a "grievous error" to skip a third-party security audit or scan for these reasons, Morriss told CoinDesk it was important for developers not to become victims of their own "hubris" and ensure that "tests are covering every branch of your code."
“With ethereum, it’s a new set of problems that people aren’t aware of when coding in Solidity,” stressed Espanol to CoinDesk.