The Ethereum ecosystem continues to witness a flurry of activity as individuals and organizations implement token contracts, add liquidity to pools, and implement smart contracts to support a wide range of business models. While notable, this growth has also been plagued by security vulnerabilities, leaving decentralized finance (DeFi) protocols vulnerable to attacks and scams.
For example, recent findings from crypto intelligence firm Chainalysis show that crypto-related hacks have increased by 58.3% from the beginning of the year to July 2022. The report further notes that $1.9 billion has been lost to hacks during this year. Period of time, a figure that does not include the $190 million Nomad Bridge hack that occurred on August 1, 2022.
While open source code can be beneficial to the blockchain industry, it can unfortunately be easily studied by cybercriminals for exploits. Security audits for smart contracts aim to resolve these challenges, but this procedure lacks industry standards, leading to complexity.
An industry standard to ensure the security of smart contracts
Chris Cordi, chair of the EthTrust Security Levels Working Group at the Enterprise Ethereum Alliance (EEA), told Cointelegraph that as the Ethereum blockchain industry grows so does the need for a mature framework to assess the security of smart contracts.
To address this, Cordi, along with a number of EEA member representatives with audit and security expertise, helped establish the EthTrust Security Levels Working Group in November 2020. Since then, the organization has been working on a document draft of a smart contract specification, or industry. Standard, intended to improve the security behind smart contacts.
More recently, the working group announced the release of the EthTrust Security Levels Specification v1. Chaals Nevile, technical program director at the EEA, told Cointelegraph that this specification outlines smart contract vulnerabilities that a proper security audit requires as a minimum measure of quality:
“It is relevant to all EVM-based smart contract platforms where developers use Solidity as a coding language. In a recent Splunk analysis, this is more than 3/4 of the mainnet contracts. But there are also private networks and projects that are based on the Ethereum technology stack but run a chain of their own. This spec is just as useful to them as it is to core network users in helping them protect their work.”
From a technical perspective, Nevile explained that the new specification outlines three levels of testing that organizations should consider when conducting smart contract security audits.
“Level [S] is designed so that, in most cases where common Solidity features are used following well-known patterns, the tested code can be certified by an automated 'static analysis' tool,” he said.
He added that the Level [M] test requires a more stringent static analysis, noting that this includes requirements where a human auditor is expected to determine whether the use of a feature is necessary or whether a claim about the security properties of the item is warranted. Code.
Nevile further explained that the [Q] test level provides an analysis of the business logic that the tested code implements. "This is to ensure that the code does not exhibit known security vulnerabilities, while also ensuring that it correctly implements what it claims," he said. There is also an optional “best practices” test that can help improve the security behind smart contracts. Neville said:
“Using the latest compiler is one of 'best practice'. It's pretty straightforward in most cases, but there are many reasons why a contract might not have been implemented with the latest version. Other good practices include reporting new vulnerabilities so they can be addressed in a specification update and writing clean, easy-to-read code.”
In general, there are 107 requirements within the entire specification. According to Nevile, about 50 of these are [S] level requirements that arise from bugs in s validity compilers.
