A brief analysis of Ethereum EIP-3074: Ordinary users can send transactions trustlessly without ETH

Original title: "Introduction | Introduction to EIP-3074"
Written by: lightclients
Translation & Proofreading: Min Min & A Jian

Ethereum wallets may soon be undergoing a major upgrade. Once the upgrade is completed, ordinary accounts (EOA) can send batch transactions, time-limited transactions, unordered transactions, etc.

My two colleagues @SamWilsn and @adietrichs and I are working on how to improve the interactive experience of Ethereum. After many iterations, we proposed EIP 3074: opcodes AUTH and AUTHCALL.

To use these two opcodes, the external account needs to sign a message off-chain and send the message to the relayer, which then sends the signature and call data to an on-chain contract (called the "caller"). The caller contract will first use the opcode AUTH to verify the signature, and then use the opcode AUTHCALL to relay the call from the external account.

There is only one difference between AUTHCALL and a normal call: AUTHCALL sets the caller (e.g., the sender of the message) to an external address that was restored using the opcode AUTH. This allows users to interact with Ethereum without using Ether. In other words, their transactions are "sponsored" by relayers.

You may find this mechanism familiar. In fact, this is similar to how meta-transactions work. However, it should be emphasized here that meta-transactions cannot arbitrarily set the sender of the message. Therefore, the contract must explicitly support meta-transactions. EIP 3074 aims to eliminate meta-transactions and reduce the complexity of contracts.

Before we dive into how this works, let’s first explain what we want to build. We want to build a mechanism that allows regular users to send transactions in a trustless manner without using ether. The key word here is “trustless”, i.e., users do not grant relayers any privileges that could be exploited.

EIP 3074 creates a trustless system by carefully choosing the parameters included in normal account signatures. Users sign keccak (0x03 ++ invoker_address ++ commit_hash).

The "type byte" is a constant byte of EIP 2718 with a value of 0x03. The purpose of this byte is to avoid conflicts with other signature mechanisms, such as the access list transaction of EIP 2930, the fee market transaction of EIP 1559, and the 0x19 signature message of EIP 191.

The caller address binds the user's call to a specific contract. The user's signature is only valid for the caller contract. Therefore, users can choose the caller they trust, just like choosing a smart contract wallet to store assets.

We expect only a small number of callers to exist, as users can be harmed if the caller contract implementation is incorrect (note that callers opt in voluntarily). Developing a secure caller contract is expensive and requires multi-party audits and static proofs.

But this is not much different from today’s practice. Smart contract wallets should also be fully audited and proven before storing large amounts of funds. This is also the case for many large DeFi projects.

The last signature parameter is commit_hash (or just commit). This gives caller designers more flexibility, allowing them to develop many different solutions.

This commit restricts the caller to only certain actions and creates a specific validity requirement to process the call. Users can trust that the caller will follow this process because they can verify the code on-chain. This is the beauty of blockchain.

Let's look at a simple example. A user wants to send a call through a caller. To prevent their call from being relayed infinitely, they need to provide a nonce, along with other immutable values. The user hashes these values ​​into a commit, and includes the commit in a signed message for the contract to verify using the opcode AUTH.

The caller will use the passed-in value to regenerate the commit hash. In this way, if the sponsor changes one of the values, the commit hash calculated by the caller will be completely different from the one signed by the external account, causing AUTH to restore a garbage address, as shown in the following figure:

Hopefully you are now convinced that a caller is just like a smart contract wallet that any normal account can use. Now let’s look at how to use commit to build more interesting scenarios.

Generally speaking, "one signature for one operation" has become a rule of thumb. This is a relatively simple understanding. The signature is created based on the hash value of a transaction, so why don't we merge multiple transactions for hash calculation? It turns out that EIP 3074 can do this.

As long as an account can pass AUTH verification, the caller can make any number of AUTHCALLs as required by the account. This is fine because we believe that the caller will execute the code truthfully. We can design a solution to merge multiple calls and hash them into commit.

In the scheme shown in the figure above, the caller will combine all the values ​​(nonce1, nonce2, etc.) and hash them to generate a commit. The caller will use this commit and the user's signature to call AUTH. AUTH will verify whether the user actually signed these parameters.

The caller then iterates over each call and verifies the nonce and other parameters before sending the authenticated calldata to the permitted address.

We can build on this foundation and build on it. For example, suppose you add a new parameter "expiration date". This parameter will be hashed and committed along with the other parameters. In addition, during the verification process, the caller will verify that expiration < block.number. Now, external accounts can use expiration date transactions!