How to assess the security risk of "forked EVM"?

9 of the top 10 TVL chains support EVM smart contracts.

Original title: "How to uate Forked EVMs for Security Risks"

撰文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan

Compiler: Katie Koo

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 assurances as the original EVM implementation.

Fork EVM Status

As of May 2023, the Ethereum Virtual Machine (EVM) has won the title of "Big Brother" of 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 crucial to supporting smart contracts in the entire 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 implementation clients in different languages such as go-ethereum (Golang) and besu (Java) directly in their protocol software.

That said, forking and modifying the EVM is actually quite common in the blockchain ecosystem, even within major protocols. For example, the Optimism Bedrock Stack that "powers" Coinbase's Base L2 blockchain uses a fork of the go-ethereum execution client called op-geth, which runs the same EVM as 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).

While this sounds scary, it is generally beneficial for EVM adoption. While the standard EVM implementation is highly optimized for the base Ethereum protocol, forked EVMs often extend it for new protocols of their own. As a result, contracts may execute differently on some EVM-compatible chains than they do on Ethereum, and the security assumptions of EVM smart contract behavior may also vary widely between different protocols.

Fork the EVM security framework

To this end, Coinbase has developed a Web3 security framework for evaluating the security impact of some forked EVM implementations. We call it Coinbase’s forked EVM framework, which will be 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;
• Provide smart contract auditors with an analysis of the smart contract vulnerability situation of the forked EVM, especially small differences in cross-network;
• Ensure the safe use and execution of EVM smart contracts on Coinbase's Base L2 blockchain.

Security standard for EVM-compatible blockchains

In order to understand how security risks exist in the Ethereum virtual machine, we must first know what guarantees the standard EVM implementation provides us. We define the Standard EVM as the EVM consistently used by Ethereum validator execution clients as described in the Ethereum Implementation Specification. By far the most used client is go ethereum (ie geth).

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

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

Our forked EVM framework focuses on the following audit requirements when evaluating 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 the 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 (x1 + x2) to subtract two values (x1 - x2).

As a result, the deviated EVM' is unequal 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.

EVM uses precompiled contracts to define complex functions (such as encryption functions), using a more convenient and performant language such as Golang, instead of 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 the introduction of new precompilers need to be audited.

Let’s take another concrete example — the BNB Smart Chain vulnerability. The BNB Smart Chain uses a deviated implementation of go-ethereum to run nodes. To this end, two new pre-compiled contracts (tmHeaderValidate, iavlMerkleProofValidate) are introduced to utilize 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 intended 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:

• Allow one party to unilaterally modify the state of any deployed contract;
• This includes all storage modifications (inserts, updates, deletes);
• use of untrusted, unverified or unaudited third-party dependencies;
• Provides access to the value within the indeterminate node.

Despite treating the compiler and the 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, sha256, and &ripemd) that are passed through Solidity The native language keyword function representation in the 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 assumption of the precompilation position of the Solidity compiler is inconsistent;
• Provides access to values within indeterminate nodes;
• Use of 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 lead to non-deterministic execution;
• Bypass access control, allowing any counterparty to unilaterally access all chain states;
• Use of untrusted, unverified, or unaudited third-party dependencies.

Why should we pay attention to EVM security?

Our goal is to build an open financial system based on blockchain technology, and to this end, we encourage the development of various EVM implementations. However, in order for an EVM-compliant blockchain to be fully supported by Coinbase, it must meet the basic requirements of a standard EVM implementation. This paper hopes to raise awareness of the risks associated with deviating from the EVM, and encourage asset issuers to prioritize the development of secure components when deviating from the EVM, raising security awareness across the entire Web3 ecosystem.