The Ethereum ecosystem continues to witness a flurry of activity that has individuals and organizations deploying token contracts, adding liquidity to pools and deploying smart contracts to support a wide range of business models. While notable, this growth has also been riddled with security exploits, leaving decentralized finance (DeFi) protocols vulnerable to hacks and scams.
For instance, recent findings from crypto intelligence firm Chainalysis show that crypto-related hacks increased by 58.3% from the beginning of the year through July 2022. The report further notes that $1.9 billion was lost to hacks during this timeframe — a figure that doesn’t include the $190 million Nomad bridge hack that occurred on Aug. 1, 2022.
Although open-source code may be beneficial for the blockchain industryit can unfortunately easily be studied by cybercriminals looking for exploits. Security audits for smart contracts aim to solve these challenges, yet this procedure lacks industry standards, thus creating complexity.
An industry standard to ensure smart contract security
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.
In order to address this, Cordi, along with several EEA member representatives with auditing and security expertise, helped establish the EthTrust Security Levels Working Group in November 2020. The organization has since been working on a draft document of a smart contract specification, or industry standard, aimed at improving the security behind smart contacts.
Most recently, the working group announced the publication of the EthTrust Security Levels Specification v1. Chaals Nevile, technical program director of the EEA, told Cointelegraph that this specification describes 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 analysis by Splunk, this is well over 3/4 of mainnet contracts. But, there are also private networks and projects that are based on the Ethereum technology stack but running one their own chain. This specification is as useful to them as it is for mainnet users in helping to secure their work.”
From a technical perspective, Nevile explained that the new specification outlines three levels of tests that organizations should consider when conducting smart contract security audits.
“Level [S] is designed so that for most cases, where common features of Solidity are used following well-known patterns, tested code can be certified by an automated ‘static analysis’ tool,” he said.
He added that the Level [M] test mandates a stricter 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 code is justified.
Nevile further explained that the Level [Q] test provides an analysis of the business logic the tested code implements. “This is to ensure that the code does not exhibit known security vulnerabilities, while also making sure it correctly implements what it claims,” he said. There is also an optional “recommended good practices” test that can help enhance the security behind smart contracts. Nevile said:
“Using the latest compiler is one of the ‘recommended good practices.’ It’s a pretty straightforward one in most cases, but there are a lot of reasons why a contract might not have been deployed with the latest version. Other good practices include reporting new vulnerabilities so they can be addressed in an update to the spec and writing clean easy-to-read code.”
Overall, there are 107 requirements within the entire specification. According to Nevile, about 50 of these are Level [S] requirements that arise from bugs in solidity compilers.
Will an industry standard help organizations and developers?
Nevile pointed out that the EthTrust Security Levels Specification ultimately aims to help auditors demonstrate to customers that they are operating at an industry-appropriate level. “Auditors can point to this industry standard to establish basic credibility,” he said.
Recent: Web3 games incorporate features to drive female participation
Shedding light on this, Ronghui Gu, CEO and co-founder of blockchain security firm CertiK, told Cointelegraph that having standards like these help ensure expected processes and guidelines. However, he noted that such standards are not by any means a “rubber stamp” to indicate that a smart contract is entirely secure:
“It’s important to understand that not all smart contract auditors are equal. Smart contract auditing starts with understanding and experience of the specific ecosystem that a smart contract is being audited for, and the technology stack and code language being used. Not all code or chains are equal. Experience is important here for coverage and findings.”
Given this, Gu believes that companies wanting to have their smart contracts audited should look beyond the certification an auditor claims to have and take into account the quality, scale and reputation of the auditor. Because these standards are guidelines, Gu remarked that he thinks this specification is a good starting point.
From a developer’s perspective, these specifications may prove to be extremely beneficial. Mark Beylin, co-founder of Myco — an emerging blockchain-based social network — told Cointelegraph that these standards will be incredibly valuable to help smart contract developers better understand what to expect from a security audit. He said:
“Currently, there are many scattered resources for smart contract security, but there isn’t a specific rulebook that auditors will follow when assessing a project’s security. Using this specification, both security auditors and their clients can be on the same page for what kind of security requirements will be checked.”
Michael Lewellen, a developer and contributor to the specification, further told Cointelegraph that these specifications help by providing a checklist of known security issues to check against. “Many Solidity developers have not received recent formal education or training in the security aspects of Solidity development, but security is still expected. Having specs like this makes it easier to figure out how to write code more securely,” he said.
Recent: Ethereum Merge prompts miners and mining pools to make a choice
Lewellen also noted that most of the specification requirements are written in a straightforward manner, making it easy for developers to understand. However, he commented that it’s not always clear why a requirement is included. “Some have links to external documentation of a vulnerability, but some do not. It would be easier for developers to understand if they had clearer examples of what compliant and noncompliant code might look like.”
The evolution of smart contract security standards
All things considered, the security level’s specification is helping to advance the Ethereum ecosystem by establishing guidelines for smart contract audits. Yet, Nevile noted that the most challenging aspect moving forward is anticipating how an exploit could occur. He said:
“This specification doesn’t solve those challenges completely. What the spec does do, though, is identify certain steps, like documenting the architecture and the business logic behind contracts, that are important to enabling a thorough security audit.”
Gu also thinks that different chains will start to develop similar standards as Web3 advances. For instance, some developers within the Ethereum industry are coming up with their own smart contract requirements to help others. For example, Samuel Cardillo, chief technology officer at RTFKT, recently tweeted that he has created a system for developers to publicly rate smart contracts based on good and bad elements in terms of development:
Although all of this is a step in the right direction, Gu pointed out that standards take time to be widely adopted. Moreover, Nevile explained that security is never static. As such, he explained that it’s possible for individuals to send questions to the working group who wrote the specification. “We will take that feedback, as well as look at what the discussions are in the broader public space because we expect to update the specification,” Nevile said. He added that a new version of the specification will be produced within six to 18 months.