This article is from Coinbase and was written by Ethen Pociask, Eric Meng, Nadir Akhtar, Gabriela Melendez Quan and Tom Ryan, compiled by Katie Gu from Odaily Planet Daily.
To strengthen the security and custody assurance of customers trading ERC-20 and other smart contract-based assets, Coinbase’s blockchain security team investigated the program layer that defines the behavior of these assets: the Ethereum Virtual Machine (EVM). When evaluating projects that modify the EVM of its own network, Coinbase’s blockchain security team reviews critical EVM changes to determine whether the modified EVM can provide the same security and custody assurance as the original EVM implementation.
Forked EVM status
As of May 2023, the Ethereum Virtual Machine (EVM) is the most popular smart contract execution platform. According to DefiLlama data, 9 of the top 10 chains ranked by total locked value (TVL) support EVM smart contracts. Therefore, understanding EVM is crucial for supporting smart contracts throughout the entire blockchain ecosystem.
- Organizing On-Chain Activity Data for Polygon zkEVM
- Zero-knowledge identity oracle provider zkMe completes $2 million Pre-Seed funding round, with participation from Circle Venture and others.
- Quick view of the current development status of DePIN ecological infrastructure
The EVM is a virtual machine used to execute smart contracts in a decentralized manner on the Ethereum network. Many EVM-compatible blockchains directly utilize popular Ethereum execution clients in different languages, such as go-ethereum (Golang) and besu (Java), in their protocol software.
That is, forking and modifying EVM is actually very common in the blockchain ecosystem, even in major protocols . For example, the Optimism Bedrock Stack that provides “power” for Coinbase’s Base L2 blockchain uses a forked version of the go-ethereum execution client called op-geth, which runs an EVM compatible with the popular Ethereum execution client. However, this does not mean that the EVM on Ethereum behaves exactly the same as the EVM on Optimism: the behavior of the op-geth EVM is slightly different in some cases (i.e., DIFFICULTY returns a random value determined by the sequencer).
Although this sounds scary, for the adoption of EVM, it is generally beneficial. Although the standard EVM implementation is highly optimized for the Ethereum base protocol, forked EVMs often extend themselves for their own new protocols. Thus, the execution of contracts on some EVM-compatible chains may differ from their execution on Ethereum, and there may be significant differences in security assumptions for EVM smart contract behavior between different protocols.
Fork EVM Security Framework
Coinbase has developed a Web3 security framework for assessing the security impact of implementations of some forked EVMs. We refer to it as Coinbase’s fork EVM framework, and below we will explain it in detail.
With this fork EVM security framework, Coinbase is able to:
-
Understand the invalidity of security assumptions of our Ethereum token framework, enabling us to safely enable new EVM compatible blockchains to support ERC-20/ERC-721 tokens on our decentralized exchange;
-
Provide smart contract auditors with analysis about smart contract vulnerabilities in forked EVMs, especially minor differences across networks;
-
Ensure secure use and execution of EVM smart contracts on Coinbase’s Base L2 blockchain.
Security Standards for EVM-Compatible Blockchains
To understand how security risks exist in the Ethereum virtual machine, we first need to know what guarantees the standard EVM implementation provides us. We define standard EVM as the EVM that is consistently used by Ethereum validators and execution clients as described in the Ethereum execution specification. The most commonly used client so far is go ethereum (geth).
We summarize security into two security standards, which represent the minimum requirements for any forked EVM implementation to be eligible for Coinbase support.
How do we audit security risks in EVM implementations?
Our fork EVM framework focuses on the following audit requirements when assessing compliance with overall security standards (i.e., contract immutability and secure execution environment). It should be noted that the following risk factors are not the entire scope of fork EVM audits.
Modifying the definition and encoding of EVM opcodes leads to significant differences in contract execution. For example, suppose some forked EVM implementation (EVM’) changes the logic of the arithmetic ADD opcode (x1 + x2) to subtract two values (x1 – x2).
As a result, the deviant EVM is not equal and not compatible with the standard EVM in execution. The consequences of modifying opcode can be beneficial actions, such as preventing integer overflow and underflow in arithmetic opcodes, or more dangerous actions, such as causing self-destruct behavior that leads to unlimited issuance of local assets.
The EVM uses precompiled contracts to define complex functionality (such as encryption functions) and uses more convenient and powerful languages such as Golang instead of using the less accessible EVM bytecode.
Essentially, these are the programming functions that are accessed through the chain addresses represented in the node software. The Ethereum Yellow Paper (as of May 2023) defines 9 precompilers, and any changes or introductions of new precompilers to these 9 precompilers require audits.
Let’s take another concrete example-BNB smart chain vulnerability. BNB Smart Chain uses a deviating implementation of go-ethereum to run nodes. For this reason, two new precompiled contracts (tmHeaderValidate, iavlMerkleProofValidate) are introduced, using third-party software (i.e. Cosmos SDK) to perform light client block verification and Merkle proof verification. The problem is that the Cosmos SDK software has an implementation error in its IAWL tree representation, allowing invalid proofs to pass verification. In other words, anyone can generate funds out of thin air. Attackers were able to use the implementation vulnerabilities nested in the iavlMerkleProofValidate precompiler to withdraw hundreds of millions of dollars from Binance cross-chain bridges.
This example of exploiting vulnerabilities is to demonstrate the necessity of precompiler security and the potential risks of introducing new precompiled contracts for deviating EVM implementations.
Fatal risks that may be brought by introducing additional precompilers include:
-
Allowing one party to unilaterally modify the state of any deployed contract;
-
This includes all storage modifications (inserts, updates, deletes);
-
Using untrusted, unverified, or unaudited third-party dependencies;
-
Providing access to uncertain node internal values.
Although compilers and the EVM are generally regarded as separate entities, it is worth noting that the Solidity compiler does make strict assumptions about the behavior of the first three precompiled contracts (ecrecover, sha256, and ripemd), which are represented as native language keyword functions in the Solidity language. Behind the scenes, the Solidity compiler actually processes these keywords into bytecode, which executes inter-contract static calls. The following diagram further illustrates this method of communication between contracts:
The security risks associated with modifying standard precompilers include:
- Allowing centralized transaction counterparties to unilaterally modify the state of any deployed contract;
- This includes all storage modifications (insertions, updates, deletions);
- Inconsistent Solidity compiler precompile locations assumed;
- Providing access to values inside uncertain nodes;
- Using untrusted, unverified, or unaudited third-party dependencies.
The key risks associated with modifying the basic components of the EVM include:
- Unbounded interpreter stack, making it infinite;
- Size modifications or changes to the memory model may lead to non-deterministic execution;
- Bypassing access control to allow unilateral access to all chain states;
- Using untrusted, unverified, or unaudited third-party dependencies.
Why is EVM security important?
Our goal is to build an open financial system based on blockchain technology, and to that end, we encourage the development of various EVM implementation solutions. However, in order for EVM-compatible blockchains to receive full support from Coinbase, they must meet the basic requirements of standard EVM implementation. This article hopes to raise awareness of the risks associated with deviating from EVM, and encourages asset issuers to prioritize the development of secure components when deviating from EVM, in order to increase the security awareness of the entire Web3 ecosystem.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
