The Ethernet wallet may soon be due for a major upgrade. Once the upgrade is complete, regular accounts (EOA) will be able to send bulk transactions, deadline transactions, out-of-order transactions, etc.
I’m working with two colleagues @SamWilsn and @adietrichs on how to improve the interactive experience of Ether. After several iterations, we came up with EIP 3074: opcodes AUTH and AUTHCALL.
To use these two opcodes, an external account needs to sign a message off-chain and send that message to a relay, which in turn sends the signature and invocation data to an on-chain contract (called a “caller”). The caller contract verifies the signature first using the opcode AUTH and then uses the opcode AUTHCALL to relay the call to the external account.
AUTHCALL differs from a normal call in only one way: AUTHCALL sets the caller (e.g., the message sender) to an external address that is recovered using the opcode AUTH. In this way, users can interact with Ether without using Ether. In other words, their transactions are “sponsored” by a relay.
You may think this mechanism is familiar. In fact, it works pretty much the same way as a meta-transaction. But it is important to emphasize here that meta-transactions cannot set up message senders at will. EIP 3074 aims to eliminate meta-transactions and reduce the complexity of contracts.
Before we dive into how this works, let’s first describe what we want to build. We want to build a mechanism that allows ordinary users to send transactions trust-free without using ethereum. The key word here is “trust-free”, i.e., the user does not grant any privileges to the relay that could be exploited.
EIP 3074 creates a trust-free system by carefully selecting the parameters included in the ordinary account signature. User signs keccak (0x03 ++ invoker_address ++ commit_hash).
“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, e.g., EIP 2930 for access list transactions, EIP 1559 for cost market transactions, EIP 191 for 0x19 signed messages, etc.
The caller address binds the user’s call to a specific contract. The user’s signature is only valid for the caller contract. Thus, users can choose their trusted callers, just as they choose the smart contract wallet used to store their assets.
We expect that only a small number of callers will exist, because the user could lose money if the implementation of the caller contract is wrong (note that callers are self-selecting). Developing a secure caller contract would be costly, requiring multiple 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 depositing large amounts of money. This is also the case for many large DeFi projects.
The last signature parameter is commit_hash (or commit). This gives the caller designer more flexibility and allows them to develop many different scenarios.
This commit restricts the caller to only perform certain actions and creates a specific validity requirement to process the call. Users can trust the caller to follow this process because they can validate the code on the chain. This is the beauty of blockchain.
Let’s look at a simple case. A user wants to send a call through a caller. To avoid their call being relayed indefinitely, they need to provide a nonce, in addition to other immutable values. The user hashes these values to get a commit, and includes the commit in a signed message so that the contract can verify it using the opcode AUTH.
The caller will use the values passed in to regenerate the commit hash. In this way, if the sponsor changes one of the values, the commit hash computed by the caller will be completely different from the one signed by the external account, resulting in the AUTH recovering a garbage address, as shown in the following figure.
Hopefully you are now convinced that callers are like smart contract wallets that can be used by any regular account. Now let’s see how to use commit to build more interesting scenarios.
Typically, “one operation for one signature” has become a rule of thumb. This is a relatively simple understanding. Signatures are created based on the hash of a transaction, so why don’t we combine multiple transactions for hashing? It turns out that EIP 3074 can do this.
As long as an account can be authenticated by AUTH, the caller can do as many AUTHCALLs as that account requires. this is fine because we trust the caller to execute the code as it should. We can design a scheme that combines multiple calls into a commit.
In the scenario shown above, the caller combines all values (nonce1, nonce2, etc.) for hashing and generates a commit. the caller will use this commit and the user’s signature to invoke AUTH. AUTH verifies that the user has actually signed these parameters.
The caller then iterates through each call and verifies the nonce and other parameters, and then sends the authenticated call data (calldata) to the permitted address.
On top of this, we can build more scenarios. For example, suppose you add a new parameter “shelf life”. This parameter will be hashed with the other parameters to get commit. additionally, during validation, the caller will verify that expiration < block.number. now, external accounts can already use deadline transactions!
EIP 3074 will bring a more fluid user experience without introducing additional trust assumptions. If you want to read the full EIP 3074, please follow this link: https://eips.ethereum.org/EIPS/eip-3074
The prototype implementation of go-ethereum is maintained here:
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/ethernet-wallets-may-soon-be-due-for-a-major-upgrade-read-the-eip-3074/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.