Deep dive into the easiest comprehensive security audit for Ethereum with Amberdata.io
Quick note: This is part 1 of 2 posts. Part 1 will cover how you can view network security, part 2 will help you develop & see security for your smart contracts!
We ran security audits against the last 90 days of new contracts & 2,000+ popular contracts. Here’s what we’ve found:
As of 10/28/18 — 8,007,824 contracts and 39,192,745 EOAs have been created on Ethereum, meaning 16.97% of all new addresses are contracts. More than ~9k new contracts are added every day. We ran security audits on the popular contracts and tokens, and found ~22.4% of them exhibited potential security vulnerabilities or warnings.
This process takes quite a while, which is why we have a small portion of the total contracts in Ethereum audited in this snapshot. We are running audits around the clock to continue analyzing the full blockchain. While the above numbers are large, let’s break them down a bit:
Now this begs the question, how do we categorize warning & information type issues?
A few examples here:
Many contracts use modular code, forcing them to deploy other contracts and connecting via DELEGATECALL. An example can be seen with Icon with their contract upgrade pattern. Be careful, as this is a potential for changes to contracts in the future!
In most cases this means assert() was called when it could be require() . See Solidity Exception Docs for more information.
We’ve added a new security audit available for many contracts, giving you visibility into your favorite dApps! Currently, we are running audits against smart contract source code and bytecode.
This panel allows us to see the full context of a smart contract audit. The grade is based on a few parameters — Errors, Warnings & Information, each weighted to allow for a more flexible average. It is meant as a starting point to alert developers of potential risks to mitigate. The area below the sum totals gives direct insight into the output of the audit.
This Integer Underflow warning shows direct code within the smart contract responsible for the issue. Many tokens adhere to the ERC20 spec, however in the actual implementation may not be using best practices. In the case of the above, the contract should have used Open Zeppelin’s SafeMath Library. Most recent tokens take advantage of this resource, however older (~pragma 0.4.11 tokens) did not have this available.
Exception state is triggered when a type errors, division by zero, out-of-bounds arrays, or assert violations occur. In most cases, this is an edge case which is easily remedied. In more recent versions of Truffle, exceptions are reported to the developer allowing them to fix before deployment.
. . .
After seeing so many audits, a pattern has been forming. Over time, many developers are learning and improving. Here’s what we’ve noticed:
In many cases, a lot of the warnings regarding Message CALL to External Contract were a proxy function designed to transact to other contracts. The best implementation of this pattern can be seen with the Colony Contracts. They use a contract acting as a resolver to the many other contracts controlling specific pieces of logic, quite modular!
It’s easy to see that older (~pragma 0.4.11–0.4.16) versions of contracts & tokens had a majority of the integer issues. With the help of libraries and many posts, more recent (~pragma 0.4.18+) contracts use SafeMath or similar helper functions to control math.
While the stats provided above are far from a large picture of the whole Ethereum blockchain, we see this as our first glimpse into the state of security. We will continue to update our findings upon another milestone of contract audits.
We’ve covered a lot of ground today, but we’re not done yet! Soon we will post on how you can automate your own security audits! 🎉👩💻👨💻🎉
Until then, stay awesome ♥️