EIP-3074 aims to eliminate meta-transactions, reduce the complexity of contracts, and allow ordinary accounts (EOA) to send batch transactions, deadline transactions, disordered transactions, etc.
Original title: “Introduction| Introduction to EIP-3074”
Written by: lightclients
Translation & Proofreading: Min Min & A Jian
The Ethereum wallet may soon usher in a major upgrade. Once the upgrade is completed, the ordinary account (EOA) can send batch transactions, deadline transactions, and out-of-order transactions.
My two colleagues @SamWilsn and @adietrichs are studying how to improve the Ethereum interactive experience. After many 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 the message to the relayer, and then the relayer sends the signature and call data to an on-chain contract (called “call By”). The caller contract will first use the opcode AUTH to verify the signature, and then use the opcode AUTHCALL to relay calls to external accounts.
There is only one difference between AUTHCALL and ordinary calls: AUTHCALL sets the caller (for example, the message sender) to an external address restored using the opcode AUTH. In this way, users can interact with Ethereum without using Ethereum. In other words, their affairs are “sponsored” by the relayer.
You might think this mechanism is familiar. In fact, this is similar to how a meta-transaction works. But it should be emphasized here that the sender of the message cannot be arbitrarily set in the meta transaction. 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 the principles of operation, let’s first introduce what we want to build. We want to build a mechanism that allows ordinary users to send transactions in a trust-free manner without using Ether. The key word here is “trust-free”, that is, the user will not grant the relayer any privileges that may be exploited.
EIP 3074 creates a trust-free system by carefully choosing the parameters included in the signature of a common account. The user signs keccak (0x03 ++ invoker_address ++ commit_hash).
“Type byte” is a constant byte of EIP 2718, with a value of 0x03. The function of this byte is to avoid conflicts with other signature mechanisms, for example, EIP 2930’s access list transaction, EIP 1559’s expense market transaction, EIP 191’s 0x19 signature message, etc.
The caller address binds the user’s call to a specific contract. The user’s signature is only valid for the caller’s contract. Therefore, users can choose the caller they trust, just like choosing a smart contract wallet to store assets.
We expect that there will only be a small number of callers, because if the caller contract is implemented incorrectly, the user may suffer losses (please note that the caller opted in). The cost of developing a secure caller contract is very high, and it needs to go through multiple audits and static proofs.
But this is not much different from today’s practice. Before depositing huge amounts of funds, smart contract wallets should also undergo a comprehensive audit and certification. The same is true for many large DeFi projects.
The last signature parameter is commit_hash (or commit). This brings greater flexibility to caller designers, allowing them to develop many different solutions.
This commit restricts the caller to only perform specific operations and creates specific validation requirements (validity requirements) to process the call. Users can trust the caller to follow this process because they can verify the code on the chain. This is the advantage of blockchain.
Let’s look at a simple case. The user wants to send a call through the caller. In order to prevent their calls from being relayed indefinitely, they need to provide a nonce and other unchangeable values. The user hashes these values ​​to get a commit, and includes the commit in the signed message so that the contract can be verified 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 that signed by the external account, causing AUTH to recover a garbage address, as shown in the following figure:
I hope you now believe that the caller is like a smart contract wallet that can be used by any ordinary account. Now let’s take a look at how to use commit to build a more interesting solution.
Under normal circumstances, “one operation corresponds to one signature” has become a rule of thumb. This is a relatively simple understanding. The signature is created based on the hash value of a transaction. Why don’t we combine multiple transactions for hash calculation? Facts have proved that EIP 3074 can do this.
As long as an account can pass AUTH verification, the caller can do AUTHCALL as many times as required by the account. This is no problem, because we believe that the caller will execute the code faithfully. We can design a scheme that combines multiple calls and hashes them into commit.
In the scheme shown in the figure above, the caller will merge all values ​​(nonce1, nonce2, etc.) into a hash to generate a commit. The caller will use this commit and user signature to call AUTH. AUTH will verify whether the user has actually signed these parameters.
Then, the caller will iterate through each call and verify the nonce and other parameters, and then send the authenticated call data (calldata) to the permitted address.
On this basis, we can also build more solutions. For example, suppose you add a new parameter “shelf life”. This parameter will be hashed together with other parameters to get commit. In addition, during the verification process, the caller will verify that expiration < block.number . Now, the external account can use the time limit transaction!
EIP 3074 will bring a more smooth user experience without introducing additional trust assumptions. If you want to read the full content of EIP 3074, please click this link .
The prototype implementation of go-ethereum is maintained here .
We are working with some teams that are interested in this mechanism. If you find this mechanism useful, please let us know and let us work together! You are welcome to provide feedback on this proposal, thank you very much! Click on the link and leave your feedback.
Finally, if you are interested in our work, our team is actively recruiting. We are committed to making mid- to long-term improvements to the Ethereum core protocol. For more information, please send a private message to me @lightclients.
Source link: twitter.com
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
