There is a lot of activity in the Ethereum ecosystem. Individuals and businesses are deploying token contracts, liquidity pools are being added to and smart contracts are being deployed to support various business models. This growth is notable but also has been plagued by security vulnerabilities, making Decentralized Finance (DeFi) protocols susceptible to hacks and scams.
Chainalysis, a crypto intelligence company, recently found that hacks related to crypto have increased by 58.3% between the beginning of the year and July 2022. This report also notes that hacks have cost $1.9 billion over this period, which doesn’t include $190 million hack of the Nomad bridge on August 1, 2022.
Open source code can be useful for the blockchain industry but it can also be easily accessed by cybercriminals searching for exploits. These challenges can be solved by security audits of smart contracts. However, there are no industry standards for this process, which creates complexity.
Smart contract security is guaranteed by a industry standard
Chris Cordi, the chair of the EthTrust Security Levels Working Group of the Enterprise Ethereum Alliance (EEA), stated to Cointelegraph that the Ethereum blockchain industry is growing, and so does the need of a mature framework for assessing the security of smart contract.
Cordi and other EEA members with security expertise and auditing skills helped to create the EthTrust Security Levels Working Group. It was established in November 2020. Since then, the organization has been working on a draft document for a smart contract specification (or industry standard) that will improve security behind smart contacts.
The EthTrust Security Levels Specification (v.1) was published by the group. Chaals Nevile is the technical program director at the EEA. He explained to Cointelegraph that this specification describes smart contracts vulnerabilities, which a security audit requires in order to ensure a minimum level of quality.
It applies to all EVM-based smart contract platforms that use Solidity as a programming language. Splunk recently found that this makes up over 3/4 of all mainnet contracts. There are private networks and projects, however, that use the Ethereum technology stack while running their own chains. They can use this specification to help secure their work, just as mainnet users.
Nevile explained, technical standpoint, that the new specification lists three levels of tests organizations should use when performing smart contract security audits.
He stated that Level [S] was designed to allow for the certification of tested code by an automated “static analysis” tool in most cases where common features are used according to well-known patterns.
He said that the Level [M] requirement requires a stricter stat analysis. This includes requirements where a human auditor must determine whether a feature is needed or whether a claim regarding the security properties code is valid.
Nevile explained that the Level [Q] testing provides an analysis of how the code implements business logic. He explained that this test is used to verify that the code doesn’t have known security flaws and also ensures it implements correctly what it claims. An optional “recommended best practices” test can be used to enhance security for smart contracts. Nevile stated:
“Using the most recent compiler is one of the “recommended good practices.” However, there are many reasons why a contract may not have been deployed using the latest version. Reporting new vulnerabilities to ensure they are addressed in the latest spec is a good practice. Also, writing simple and easy-to-read codes is another good practice.
The entire specification contains 107 requirements. Nevile estimates that about 50 of these requirements are Level [S] requirements arising from bugs in solidity compilers.
What industry standards will help developers and organizations?
Nevile pointed to the fact that EthTrust Security Levels Specification is designed to assist auditors in proving to customers that their operations are at industry-appropriate levels. He said that auditors can refer to the industry standard to establish basic credibility.
Recent: Web3 games include features that encourage female participation
Ronghui Gu (CEO and cofounder of CertiK blockchain security company) explained that such standards help to ensure processes and guidelines are followed. He pointed out that these standards are not a “rubber stamp”, to prove that smart contracts are secure.
It is important to realize that not all smart contract auditors will be the same. Smart contract auditing begins with an understanding of the ecosystem for which a smart contract is being audited, as well as the technology stack and language used. Different code and chains may not be the same. For coverage and finding the right code, it is important to have experience.
Gu says that smart contract audits should not only focus on the certification claimed by the auditor, but also consider the reputation, quality and scale of the auditor. Gu stated that these standards are guidelines and that this is a good starting place.
These specifications could prove to be very beneficial for developers. Cointelegraph spoke with Mark Beylin who is co-founder of Myco, a new blockchain-based social network. He said that these specifications will prove to be extremely valuable in helping smart contract developers understand the expectations from security audits. He stated:
There are many resources available for smart contract security. However, there is no standard that auditors follow in assessing the security of a project. This specification allows security auditors to communicate with their clients about the security requirements that will be met.
Cointelegraph was also told by Michael Lewellen (a developer and contributor), that the specifications provide a checklist of security issues that can be checked against. Although many Solidity developers don’t have formal training or education in security, security is still expected. He said that having specs like these makes it easier to understand how to write code more securely.
Recent: Ethereum Merge forces miners and mining pool to make a decision
Lewellen noted that the majority of specification requirements are written in a simple manner which makes it easier for developers to understand. He did however point out that not all requirements are clear. Some have external documentation about a vulnerability. Others do not. Developers would find it easier to understand compliant and non-compliant code if there were clear examples.
Smart contract security standards evolving
All things considered, the specification of security level is helping to advance Ethereum ecosystem by establishing guidelines and auditing smart contracts. Nevile said that anticipating an exploit’s outcome is the most difficult aspect of moving forward. He stated:
These challenges are not fully solved by this specification. The spec, however, does identify steps such as documenting the architecture or the business logic behind contracts that are essential to enable a thorough security audit.
Gu believes that other chains will develop the same standards as Web3 advancements. Some developers in the Ethereum industry have created their own requirements for smart contracts to assist others. Samuel Cardillo (chief technology officer at RTFKT), recently tweeted that he had created a system to allow developers to rate smart contracts on the basis of good and poor elements.
A few days ago, I created a Google Sheet to rate public smart contracts. It will also include do and don’ts for contract development. https://t.co/2ixBpkNeoc
— SamuelCardillo.eth RTFKT (@CardilloSamuel August 15, 2021
Gu said that although all this is a good step in the right direction it takes time for standards to become widely accepted. Nevile also explained that security is not static. He explained that individuals can ask questions to the specification’s working group. Nevile stated that they will consider the feedback and also look at the public discussions as we plan to update the specification. Nevile stated that a new specification would be available within six to eighteen month.