Ethereum makes progress on smart contract security auditing standards
Chris Cordi, chair of the Ethereum Alliance (EEA) EthTrust Security Levels Working Group, an industry standard for securing smart contracts
, told Cointelegraph that as the Ethereum blockchain industry grows, so does the need for mature frameworks for assessing the smart contract audit services.
To address this issue, Cordi helped establish the EthTrust Security Level Working Group in November 2020 with several EEA member representatives with audit and security expertise. Since then, the group has been working on a draft standard for smart contract specifications, or industry documents, aimed at improving the security behind smart contacts.
Recently, the working group announced the release of the EthTrust Security Level Specification v1. Chaals Nevile, director of technical programs at the EEA, told Cointelegraph that the specification describes smart contract vulnerabilities that require proper security auditing as a minimum quality measure:
“It is relevant to all EVM-based smart contract platforms where developers use Solidity as the coding language. In Splunk In a recent analysis, this is far more than 3/4 of the mainnet contracts. However, there are also private networks and projects that are based on the Ethereum technology stack but run their own chains. The specification helps protect them and mainnet users They work just as well.”
From a technical standpoint, Nevile explained that the new specification outlines three levels of testing that organizations should consider when conducting smart contract security audits.
In the majority of situations, Level[S] is made to employ Solidity’s standard features in well-established patterns, and test code may be verified by automated “static analysis” techniques, he added.
Level [M] tests require more rigorous static analysis, he added, noting that this includes requiring human reviewers to determine whether a feature needs to be used, or whether claims about the security properties of the code are reasonable.
Nevile further explained that Level [Q] testing provides an analysis of the business logic implemented by the test code. “This is to make sure the code doesn’t have known security holes, while also making sure it does exactly what it claims to be,” he said. There is also an optional “recommended good practice” test that can help enhance the security behind smart contracts.
“Using the latest compiler is one of the ‘recommended good practices’. In most cases this is a very simple approach, but there are many reasons why a contract might not be deployed with the latest version. Other good practices This includes reporting new vulnerabilities so they can be addressed in updated specifications, and writing clean and readable code.”
Overall, there are 107 requirements across the specification. According to Nevile, smart contract audit about 50 of them are level[S] requirements caused by bugs in the solidity compiler.
Will industry standards help organizations and developers?
Nevile pointed out that the EthTrust security level specification’s main goal is to make it easier for auditors to prove to customers that they are working at a standard that is acceptable to the industry. “Auditors can point to this industry standard to establish basic credibility,” he said.
More recently: Web3 games incorporate features that drive female participation
Ronghui Gu, CEO and co-founder of blockchain security firm CertiK, made this point, telling Cointelegraph that having such standards helps ensure expected processes and guidelines . However, he points out that these standards are by no means a “rubber stamp” that a smart contract is completely secure:
“It is important to understand that not all smart contract auditors are created equal. Smart contract auditing starts with an understanding of the specific ecosystem in which the smart contract is being audited. The understanding and experience of the system, as well as the technology stack and code language used. Not all codes or chains are created equal. Here, experience is important for reporting and discovery.”
Given this, Gu believes that he would like to have a better understanding of his smart contracts. Firms audited should go beyond the accreditation the auditor claims to have and consider the quality, size and reputation of the auditor. Because the standards are guidelines, Gu said he thinks the norm is a good place to start.
From a developer’s perspective, these specifications may prove to be very beneficial. Mark Beylin, co-founder of emerging blockchain-based social network Myco, told Cointelegraph that the standards will be invaluable in helping smart contract developers better understand security audit expectations. He said:
“Auditors do not have a precise rulebook for analysing project security because there are now a lot of decentralised resources for smart contract security. Using this specification, security auditors and their clients can check what to do on the same page Such security requirements.”
Michael Lewellen, a developer and contributor to the specifications, further told Cointelegraph that the specifications help with checking by providing a list of known security issues. “Many Solidity developers have not recently received formal education or training in the security aspects of Solidity development, but security is still something to look forward to. Having a specification like this makes it easier to figure out how to write code more securely,” he said.
Recently: Ethereum Merger Prompts Miners and Pools to Make Choices
Lewellen also noted that most of the specification requirements are written in a straightforward manner that is easy for developers to understand. However, he commented that it was not always clear why the requirement was included. “Some have links to external documentation for vulnerabilities, but some don’t. It would be easier for developers to understand if they had clearer examples of what compliant and non-compliant code should look like.”
Considering the evolution of smart contract security standards
, The Ethereum ecosystem is advanced by the defining of security levels by creating standards for smart contract auditing. Neville pointed out that forecasting how a breach would happen is the most difficult part of going forward. He said that “this specification doesn’t adequately address these difficulties.”
However, the definition identifies certain tasks, such as describing the architecture and business logic of a contract, which are crucial to completing a full security audit.
Gu also believes that, As Web3 develops, different chains will start developing similar standards. For example, some developers in the Ethereum industry are making their own bsc smart contract audit requirements to help others. For example, RTFKT’s CTO Samuel Cardillo recently tweeted that he created a system for developers to publicly evaluate smart contracts based on what’s good or bad in terms of development:
despite all of this Both are steps in the right direction, but Gu points out that it will take time for the standard to be widely adopted. Furthermore, Neville explained that safety is never set in stone. So, he explained, individuals can send questions to the working group that writes the specification. “We’ll take that feedback and look at what’s being discussed in the wider public space as we look to update the norm,” Neville said. He added that the new version of the specification will be produced within 6 to 18 months.
About the author
Get your smart contracts audited and certified by leading smart contract security experts. Our smart contract audit services cover functionality, vulnerabilities, and gas efficiency. Talk to a consultant now to get started.