This article comes from CoinbaseThis article comes from

To strengthen security and custody assurances for customers trading ERC-20 and other smart contract-based assets, the Coinbase Blockchain Security team investigated the programmatic layer that defines the behavior of these assets: the Ethereum Virtual Machine (EVM). When evaluating projects that modify their own network's EVM, Coinbase's blockchain security team reviews key EVM changes to determine whether the modified EVM can provide the same security and custody guarantees as the original EVM implementation.

secondary title

Forked EVM Status

As of May 2023, the Ethereum Virtual Machine (EVM) has claimed the title of "Big Brother" for the most popular smart contract execution platform. According to DefiLlama, 9 of the top 10 chains by total value locked (TVL) support EVM smart contracts. Therefore, a deep understanding of the EVM is critical to supporting smart contracts across the blockchain ecosystem.

EVM is a virtual machine for decentralized execution of smart contracts on the Ethereum network. Many EVM-compatible blockchains leverage standard implementations of popular Ethereum execution clients in different languages ​​such as go-ethereum (Golang) and besu (Java) directly in their protocol software.That is to say,Forking and modifying the EVM is actually very common in the blockchain ecosystem, even within major protocols

. For example, the Optimism Bedrock Stack, which "powers" Coinbase's Base L2 blockchain, uses a fork of the go-ethereum execution client called op-geth, which runs an EVM identical to the popular ethereum execution client. compatible. However, this does not mean that the EVM on Ethereum behaves exactly the same as the EVM on Optimism: the op-geth EVM behaves slightly differently in some cases (i.e. DIFFICULTY returning random values ​​is determined by the sequencer).Contracts may execute differently on some EVM-compatible chains than they do on Ethereum, and the security assumptions for EVM smart contract behavior may also vary widely between different protocols.

secondary title

Forking the EVM Security Framework

To this end, Coinbase has developed a Web3 security framework for evaluating the security impact in some forked EVM implementations. We call it Coinbase’s forked EVM framework, which is explained in detail below.

• With this forked EVM security framework, Coinbase is able to effectively:

• Understanding the invalidity of the security assumptions of our Ethereum token framework allows us to safely enable new EVM-compatible blockchains to support ERC-20/ERC-721 tokens on our decentralized exchanges;

• Ensuring secure use and execution of EVM smart contracts on Coinbase's Base L2 blockchain.

secondary title

A security standard for EVM-compatible blockchains

We summarize security into two security criteria that represent the minimum requirements for any forked EVM implementation to be eligible for Coinbase support.

secondary title

How do we audit the security risks of an EVM implementation?

Our forked EVM framework focuses on the following audit requirements when assessing compliance with overall security criteria (i.e., contract immutability and a secure execution environment). It should be noted that the following risk components are not the full scope of fork EVM audit.

Modifying the definition and encoding of EVM opcodes can lead to significant differences in how contracts are executed. For example, suppose some forked EVM implementation (EVM') changes the arithmetic ADD opcode to define logic (x 1 + x 2 ) to subtract two values ​​(x 1 - x 2 ).

As a result, the deviating EVM' is not equal and incompatible in execution with the standard EVM. The consequences of modifying opcodes can be beneficial behavior, such as preventing integer overflow and underflow in arithmetic opcodes, or more dangerous behavior, such as self-destruct behavior that causes infinite minting of local assets.

The EVM uses precompiled contracts to define complex functionality (such as cryptographic functions), using a more convenient and performant language such as Golang, rather than using the less accessible EVM bytecode.

Fundamentally, these are programmed functions accessed through predetermined chain addresses represented in the node software. There are 9 precompilers defined in the Ethereum Yellow Paper (as of May 2023), and any changes to these 9 precompilers or introduction of new precompilers are subject to auditing.

Let’s take another concrete example — the BNB Smart Chain vulnerability. The BNB Smart Chain uses a deviating implementation of go-ethereum to run nodes. To this end, two new pre-compiled contracts (tmHeaderValidate, iavlMerkleProofValidate) are introduced, utilizing third-party software (i.e. Cosmos SDK) to perform light client block validation and Merkle proof validation. The problem is that the Cosmos SDK software has an implementation bug in its IAWL tree representation that allows cryptographically invalid proofs to pass verification. In other words, anyone can generate money out of thin air. Attackers were able to exploit this implementation flaw nested in the iavlMerkleProofValidate precompiler to siphon hundreds of millions of dollars from the Binance cross-chain bridge.

This exploit example is meant to demonstrate the need for precompiler security and the potential risks of introducing new precompiled contracts for deviating EVM implementations.

• Potentially fatal risks of introducing additional precompilers include:

• Allowing a party to unilaterally modify the state of any deployed contract;

• This includes all storage modifications (inserts, updates, deletes);

• Use untrusted, unverified or unaudited third-party dependencies;

Provides access to values ​​within an indeterminate node.

Despite treating the compiler and EVM as completely separate entities, it's worth noting that the Solidity compiler does make strict assumptions about the behavior of the first three precompiled contracts (ecrecover, sha 256, and &ripemd), which are passed Native language keyword function representation in the Solidity language. Behind the scenes, the Solidity compiler actually processes these keywords into bytecode, which executes static calls between contracts. The diagram below further illustrates this way of communicating between contracts.

• Security risks introduced by modifying the standard precompiler include:

• Allow centralized counterparties to unilaterally modify the state of any deployed contract;

• This includes all storage modifications (inserts, updates, deletes);

• The Solidity compiler's precompiled location assumptions are inconsistent;

• Provides access to values ​​within indeterminate nodes;

Using untrusted, unverified, or unaudited third-party dependencies.

• Key risks posed by modifying fundamental components of the EVM include:

• does not constrain the interpreter stack to be infinitely large;

• Resizing or changing the memory model may result in non-deterministic execution;

• Using untrusted, unverified, or unaudited third-party dependencies.

secondary title

Why should you care about EVM security?