Ethereum Smart Contract Framework Updated to Combat Security Concerns

Disclosure: Crypto is a high-risk asset class. This article is provided for informational purposes and does not constitute investment advice. By using this website, you agree to our terms and conditions. We may utilise affiliate links within our content, and receive commission.

Ethereum is one of the most widely used blockchain networks globally. Recent findings from CoinMarketCap show that Ethereum has the highest number of total developers, accounting for 16% of all developers in the crypto sector.

Source: CoinMarketCap

Unfortunately, the Ethereum network has also become extremely prone to security exploits. Blockchain security firm Beosin found in its “Global Web3 Security Report ” that crypto investors lost $282.96 million to rug pulls during quarter three of this year. The report further noted that phishing schemes generated $66.15 million during the same time period. According to findings from Beosin, the Ethereum blockchain underwent the most losses and incidents overall.

Source: Beosin

Updated framework for reviewing smart contract code

Chaals Neville, technical program director at the Enterprise Ethereum Alliance (EEA) — an organization that aims to drive the use of enterprise ethereum as an open standard — told Cryptonews that there are known problems within Ethereum that are impacting the ecosystem’s security. “The most obvious problem is that the Solidity compiler – which outputs byte code and other artifacts needed for deployment of smart contracts – has bugs. As the compiler evolves, old bugs are fixed, but new ones are also created,” said Neville.

In order to address this and other challenges, the EEA established the “EthTrust Security Levels Working Group in November 2020.” In August 2022, the group released the publication of the “EthTrust Security Levels Specification v1.” This specification has since served as a framework for developers, organizations and customers leveraging and reviewing smart contract code written in Solidity, Ethereum’s main programming language.

Yet as the Ethereum network continues to advance, Neville pointed out that the EthTrust Security Levels Specification required updates to reflect ongoing and new security developments. “For instance, the v1 specification covers bugs up to about the year 2022, yet new bugs were discovered after we released v1,” he said.

This in mind, Neville shared that today the EEA announced the release of Version 2.0 of its EthTrust Security Levels Specification. Neville noted that the EthTrust Security Levels Specification v2 addresses issues such as newly discovered bugs in the Solidity compiler, treatment of rounding errors, more vigorous treatment of read-only reentrancy attacks and more.

Updates are critical, as the Ethereum ecosystem has fallen victim to security exploits in the past due to these specific issues. For instance, Michael Lewellen, head of solutions architecture at OpenZeppelin – a security firm building an open-source framework to secure smart contracts – told Cryptonews that “The DAO” hack occurred due to reentrancy. “The DAO Hack was the original big hack on Ethereum that happened in 2016 and got everyone thinking more about security. This was a classic case of reentrancy,” Lewellen said. The DAO hack resulted in a loss of $3.64 million in ETH.

Neville explained that reentrancy occurs when a developer starts a smart contract and then requests for the program to do something different while it is in the middle of running code. He said:

“Essentially this means that a program is halfway through running code, but then something else is asked of it. As a result, the two requests could get mixed up. A program hacker can then use this mix up as an opportunity to steal people’s money or change the prompt of things.”

Will an industry standard be widely adopted?

Aware of the severity behind such incidents, Lewellen pointed out that OpenZeppelin leverages the EthTrust Security Levels v1 framework to prevent such security vulnerabilities from occurring. “We use this framework as a pre-audit assessment for many of our clients. This allows clients to know that we are checking for certain instances during the audit process.”

This industry standard seems to be helpful, as an anonymous OpenZeppelin client revealed to Cryptonews that EthTrust is what the company had been lacking in the past. The source said:

“We failed our previous security audit because we didn’t have clear guidance on what security requirements we were missing. We feel much more confident going into our next audit after reviewing the EthTrust requirements and implementing them in our codebase.”

Yet Neville commented that while feedback for the EthTrust standard v1 has been positive, it remains challenging getting developers and organizations to know that such an open standard exists. He also noted that the framework is best suited for newer Ethereum projects. He said:

“Projects like Uniswap, Aave and others may look at these specifications and find them to be useful, but for the most part it’s common knowledge for them. Projects that are just now being developed and going to production on Ethereum will likely find these specifications to be valuable.”

Yet the question remains whether or not such an industry standard will help prevent security exploits on Ethereum moving forward. John Wingate, founder and chief executive officer of BankSocial – a financial services company that leverages blockchain technology – told Cryptonews that the changing nature of industry standards is problematic. “Standards are always changing; languages are always depreciating methods, variables, data types, and object types,” he said.

This concern in mind, Neville shared that version 3 of the EthTrust specification is already in the works. “We are roughly 16 months between publications. I think that 12 to 18 months is a frequent enough revision to ensure that we don’t fall out of date.”

Although this may be, Wingate believes that repeatable, automated testing is the only way to make sure decentralized applications are adhering to best practices that may prevent security exploits. He said:

“This means being able to set your platform up to have regular, automated, code testing. When the source code, or compiler is known to have a bug, the automation tool can be updated and then everyone gets the benefit of scanning for the exploits.”

Source