Pectra’s EIP-3074, and its Impact on Deployed Smart Contracts

Introduction

Ethereum’s end-user experience (UX) is about to be significantly enhanced with the introduction of EIP-3074, which will be part of the upcoming Pectra update. This proposal intends to improve wallets’ functionality by directly enabling more complex operations similar to smart contracts within traditional wallet architectures. It improves blockchain user UX and solves problems like transaction bundling and sponsored transactions.

For a study commissioned by the Ethereum Foundation, Dedaub identified the potential impacts of EIP-3074 on all known deployed smart contracts as of the date of the study. The results of our analysis are becoming increasingly relevant as we approach the implementation EIP-3074. You can read the original study here.

According to our research, we have found that EIP-3074 can bypass many access control predicates involving comparisons between the caller (msg.sender) and transaction originator (tx.origin). These have been used in the past to protect against flashloan attacks, and in rare cases, reentrancy. Although the former comparisons were previously considered unsafe, our findings suggest that upgraded security measures against such attacks need to be accelerated. However, it is worth noting that the use of these access control predicates were found to be rare. In addition, since our study in 2021, multiple other mechanisms such as MEV bundling have further rendered comparisons to tx.origin even more unsafe, meaning that modern contracts are less susceptible to negative security impacts.

Dedaub’s EIP-3074 Impact Study: A Look Back

In May 2021, Dedaub conducted a study to assess the impact of Ethereum Improvement Proposal (EIP) 3074 and evaluate its potential effect on Ethereum’s ecosystem. Our researchers built custom static analysis pipelines, reviewed the source code and bytecode of deployed contracts, and obtained insights from developer interviews to understand the proposal’s possible outcomes.

The team was concerned that non-standard checks (e.g., reentrancy checks) used `msg.sender == tx.origin`. Although EIP-3074 could make new attacks easier to execute, it was found that it does not create significant new attack vectors to the existing code already using checks on expressions such as `msg.sender == tx.origin`. Although the issue has the potential to impact several thousand deployed contracts (around 1.85% of the entire smart contract corpus on Ethereum as of May 2021), the developer community is aware of the potential risks and most developers we spoke to are ready to adapt with sufficient warning.

Our study utilized our state-of-the-art decompilation and static program analysis frameworks, which are part of the toolchains available in the Dedaub Security Suite. These techniques were critical in identifying specific contracts and scenarios were EIP-3074 could change the attack surface.

Although it is important to acknowledge that the results are subject to interpretation, we considered the impact of EIP-3074 to be “moderate but manageable” as of May 2021, and even more manageable today.

About EIP-3074 and the Pectra Update

The upcoming Pectra upgrade of Ethereum is set to change the functionality of Ethereum wallets. The proposal will introduce two new advanced opcodes (AUTH and AUTHCALL), allowing traditional wallets such as MetaMask to operate with functionalities similar to those of smart contracts. The proposed enhancement will empower wallets to authorize transactions on behalf of users, thereby streamlining interactions and boosting security.

The upcoming Pectra upgrade, which is planned to be integrated into the Ethereum network later this year, aims to significantly streamline the user experience. EIP-3074 will play a crucial role in this upgrade. EIP-3074 introduces two new Ethereum opcodes, AUTH and AUTHCALL, to improve the control of smart contract transactions and allow more flexible delegation of transaction execution. Here’s a summary of their functionality:

AUTH:

• AUTH is an opcode that takes a single secp256k1 signature as input.
• The purpose of AUTH is to recover the address of an Ethereum account that has signed the input data. It stores this address in the EVM’s context.
• This allows smart contracts to securely authenticate a message signed by a specific account without requiring direct transaction signatures.

Effectively, AUTH authenticates that the transaction is being executed on behalf of the specified account.

AUTHCALL:

• AUTHCALL builds upon AUTH. It is an opcode that works similarly to a normal CALL but leverages the address authenticated by AUTH.
• This opcode allows executing a call from the authenticated address established by AUTH.

Essentially, it lets the contract execute transactions as if it were that authenticated account, thus enabling secure and flexible delegation of transaction execution.

These opcodes can be used to build more complex smart contract architectures where you can delegate transaction signing to another entity or allow relayers to execute transactions on behalf of others securely. This improves flexibility and can facilitate more seamless smart contract interactions, especially in systems requiring more complex transaction flows.

However, it’s crucial to handle these opcodes carefully to maintain the security of the delegation scheme and avoid unintended transaction execution.

Applications Enabled by EIP-3074

A few examples of applications that EIP-3074 will enable or significantly facilitate include:

Meta-Transactions: Users can sign a message off-chain, and relayers can use AUTH to verify the signature and AUTHCALL to execute the transaction securely.

Smart Contract Wallets: Instead of executing calls through multiple layers of contract indirection, smart contracts can act directly as users using AUTHCALL.

Delegated Governance: Users can delegate their voting power by signing off-chain messages, which governance contracts can then verify and act upon using AUTHCALL.

Subscription and Recurring Payments: Recurring transactions can be authenticated off-chain, and service providers can execute authorized payments using AUTHCALL.

Access Control and Delegation: A master account can securely delegate access to sub-accounts via signed messages, with AUTHCALL enforcing the permissions.

Dedaub was commissioned by the Ethereum Foundation to perform a security audit of the bytecode of a smart contract that was introduced to the EIP-4877 in a recent change, enabling the on-chain storing and accessing of the beacon block roots of recent blocks.

In this blog post, titled “EIP-4877 summary,” we highlight key insights from the audit. You can access the complete report here.

The audited contract uses the block’s timestamp as a key for their parent beacon blocks’ roots. To bind the contract’s storage footprint while retaining accurate information, a set of two ring buffers are used (using a HISTORY_BUFFER_LENGTH with a value of 98304):

1. The first one stores the timestamp (i.e. the key) and is used to ensure that the result for the provided timestamp is the one that is currently stored on-chain. Its value will be stored at storage location timestamp % HISTORY_BUFFER_LENGTH.
2. The second one is used to store the beacon root chain value for the timestamp. Ιts value will be stored at storage location HISTORY_BUFFER_LENGTH + timestamp % HISTORY_BUFFER_LENGTH.

The audited contract implements two methods, set() and get(). As the contract does not adhere to the contract ABI specification, the method to be executed is chosen based on the contract’s caller; if called by the special address 0xfffffffffffffffffffffffffffffffffffffffe, the set() function is called, while every other address the calls the get() function. Both methods accept the first 32 bytes of the call’s calldata as their arguments.

The highest severity vulnerability found during this audit is one where calling the get() function. More specifically, if this is called with a value of zero it will not fail and return the zero value back.

// get()
require(msg.data.length == 32);
require(calldata0_32 == STORAGE[calldata0_32 % 0x18000]);
return STORAGE[0x18000 + calldata0_32 % 0x18000];

EIP-4877 Summary | Main body of the get() function

Although this does not affect the contract’s functionality for valid timestamps it can potentially lead to misuse, and funds stolen in projects that rely on this root to exist and valid. Therefore we suggested adding a special case for the zero value, in the get() function or invalidating it by storing a value in the 0th storage slot during the contract’s construction.

You can read the full audit report here.

The Ethereum Foundation commissioned our team to examine the potential impact of Ethereum Improvement Proposals (EIPs) 6404 and 6466. These EIPs propose the modification of Merkle-Patricia Trie (MPT) commitments for transactions and receipts, respectively. Importantly, this entails a change in the serialization algorithm, from Recursive Length Prefix (RLP) format to the Simple Serialize (SSZ) format for the Receipts and Transactions containers. In turn, this changes the Receipts Root and Transactions Root fields in the execution layer headers.

A primary concern is that this transition could disrupt contracts that rely on RLP for proofs on data committed to the Ethereum mainnet. These contracts may include critical parts of decentralized bridges, which generate proofs about some log that was emitted in historical transactions.

EIPs 6404 and 6466 | This research seeks to quantify and qualify the extent of potential disruption caused by these changes. Identifying the specific on-chain patterns that verify commitments in this manner represents a significant challenge, necessitating a semi-automated examination of all smart contracts deployed on the Ethereum network, together with their recent behavior. The study also attempts to identify which projects these contracts are part of, and whether actions can be taken, on-chain (such as upgrading) or off-chain (such as modifying their respective oracles) to limit the impact of these changes.

For the proposed EIPs, we were able to measure the extent of the impact of these changes. The effects are observed on a handful of known projects, all of which are cross-chain bridges.

Notably, many other protocols that do employ RLP functionality are not affected. For instance the Optimism and Polygon bridges use RLP operations for inclusion proofs when bridging from L2 networks back to Ethereum, and, thus, are not affected by the Ethereum encoding of transactions.

Project Name	Website	Estimated Impact
zkBridge	https://zkbridge.com	Moderate
LayerZero	https://layerzero.network/	Moderate
Telepathy	https://docs.telepathy.xyz/	Moderate

Finally, an interesting result of our study is that out of the two proposed EIPs, only EIP-6466 (Receipts Root EIP) was observed to have an impact on the inspected protocols. This makes sense as log-inclusion proofs are probably the most common way to conduct cross-chain message passing.

Read the rest of the study here.

Dedaub was commissioned by the Ethereum Foundation to perform an impact study of Ethereum Improvement Proposals (EIPs) 4758 and 6780 on existing contracts. EIP-4758 proposes to deactivate SELFDESTRUCT by changing it to SENDALL, which recovers all funds (in ETH) to the beneficiary without deleting any code or storage. On the other hand, EIP-6780 modifies SELFDESTRUCT to work only in the same transaction in which the contract was created, while in all other cases it recovers all funds but does not delete any other account data.

The aim of this study is (i) to help the Ethereum community decide whether to implement, based on the impact of these changes to the ecosystem, EIP-4758 or EIP-6780. In either case we also aimed to (ii) find out which projects are affected and by how much. To evaluate the impact of these proposed changes, we performed comprehensive queries over past on-chain behaviors of smart contacts and queries on code and bytecode of deployed contracts; inspected code manually; checked balances, approvals, and contract proxying state; and informally interviewed developers.

The study found that a small number of known projects and many smart contracts, mainly involved in Miner Extractable Value (MEV) bot networks, would be affected. Quantitatively, over 98% of SELFDESTRUCT-CREATE2 pairs in known contracts would remain unaffected if EIP-6780 is implemented, while the impact of EIP-4758 is less certain. Metamorphic contracts used for upgrades were found to be rare. If implemented today, EIP-4758 could affect some functionalities of certain projects, including AxelarNetwork, Pine Finance, Revest, and JPEGd (with high impact), and Sorbet Finance, Celer, Gelato, Ricmoo’s Wisps, Chainhop Protocol (with low impact), and Thousand Ether Homepage (with moderate impact). However, most of these projects could be upgraded in time for a deployment of the proposed EIPs.

Based on this, we judged the impact of EIP-4758 and EIP-6780 to be manageable and could be a net positive due to the simplification of Ethereum Clients’ implementations, especially if EIP-6780 is selected.

The study used dynamic analysis and static program analysis, along with smart contract inspection and transaction debugging.

Read more

Static analysis of smart contracts as-deployed on the Ethereum blockchain has received much recent attention. However, high-precision analyses currently face significant challenges when dealing with the Ethereum VM (EVM) execution model. A major such challenge is the modeling of low-level, transient “memory” (as opposed to persistent, on-blockchain “storage”) that smart contracts employ. We offer an analysis that models EVM memory, recovering high-level concepts (e.g., arrays, buffers, call arguments) via deep modeling of the flow of values. Our analysis opens the door to Ethereum static analyses with drastically increased precision. One such analysis detects the extraction of ERC20 tokens by unauthorized users. For another practical vulnerability (redundant calls, possibly used as an attack vector), our memory modeling yields analysis precision of 89%, compared to 16% for a state-of-the-art tool without precise memory modeling. Additionally, precise memory modeling enables the static computation of a contract’s gas cost. This gas-cost analysis has recently been instrumental in the evaluation of the impact of the EIP-1884 repricing (in terms of gas costs) of EVM operations, leading to a reward and significant publicity from the Ethereum Foundation.

Extract from “Precise Static Modeling of Ethereum Memory” by SIFIS LAGOUVARDOS, University of Athens, Greece NEVILLE GRECH, University of Athens, Greece
ILIAS TSATIRIS, University of Athens, Greece, and YANNIS SMARAGDAKIS, University of Athens, Greece – Read more

Ethereum static analyses | INTRODUCTION

The Ethereum blockchain has enabled the management of digital assets via unsupervised au- tonomous agents called smart contracts. Smart contracts are among the computer programs with the most dire needs of high correctness assurance, due to their managing of high-value assets, as well as their public and immutable nature. Therefore, static analysis for Ethereum smart contracts has captured the attention of the research community in recent years [Albert et al. 2018; Feist et al. 2019; Grech et al. 2018; Mueller 2018; Tsankov et al. 2018]. The first generation of Ethereum

Most static analysis tools for Ethereum operate at the binary level of contracts, as-deployed on the blockchain. This ensures that the analysis operates on all contracts in existence, regardless of whether source code is available. (Source code is not always present but not negligible either: it is available for under 25% of deployed contracts, yet for more than half of the high-value contracts.) Furthermore, operating on low-level binaries offers source-language and language- version independence, completeness in the presence of inline assembly (which is common), and, perhaps most importantly, uniform treatment of complex language features: as analysis authors often argue, innocuous-looking source-level expressions can incur looping behavior or implicit overflow [Grech et al. 2018].

Operating at the binary level necessitates contract decompilation [eth [n. d.]; Brent et al. 2018; Grech et al. 2019; Kolinko 2018] in order to recover high-level information from the very-low-level Ethereum VM (EVM) bytecode format. This decompilation effort is non-trivial: the EVM is a stack machine with no structured information (no types or functions). Control-flow (i.e., calls, returns, conditionals) is implemented as forward jumps over run-time values obtained from the stack, hence even producing a control-flow graph requires a deep static analysis [Grech et al. 2018]. Despite these challenges, sophisticated decompilers mostly succeed in recovering high-level control flow and have been the basis of the most successful Ethereum static analyses.

Despite the relative success of Ethereum decompilers, some low-level aspects of the deployed contract remain unaddressed. The most major such aspect is the precise modeling of transient EVM memory. “Memory” in the context of the EVM (and of this paper) refers to a data store that is transient and transaction-private, used by the runtime primarily to store values whose size is statically unknown—e.g., arrays, strings, or encoded buffers. (Memory is to be contrasted with storage: the on-blockchain persistent value store of an Ethereum smart contract.)

Memory is crucial in the execution of smart contracts. It is used for many cryptographic hash operations (SHA3 is a native instruction, operating over arbitrary-length buffers), for the arguments of external calls (i.e., calls to other contracts), for logging operations, and for returns from a public function. Crucially, any complex mapping data structure (i.e., the most common Ethereum data structures) stores and retrieves information (from storage) after hashing keys in memory buffers.

Modeling EVM memory is unlike other memory management settings. There is no speed premium for locality, yet the compiler attempts to keep memory tightly packed because the contract’s execution cost (in terms of Ethereum gas consumed for memory-related operations) depends on the highest initialized memory address. For the vast majority of smart contracts, written in the Solidity language, the compiler uses a simple strategy: every allocated buffer is written after the end of the last one, updating a “free-memory” pointer. This memory management policy is a low-level aspect, introduced entirely during the compilation process. At the source-code level, memory is implicit: the values that end up stored in memory merely have dynamic-length array or string types.
The goal of a precise modeling of EVM memory is to recover such source-level information (expressed in terms of arrays or strings) from the low-level address manipulation code that the compiler produce”