Impact of EIP-3074 on Wallets and DApps

Author:Nic @ imToken Labs

Target readers:< /strong>Blockchain developer

Prerequisite knowledge:

• Understand the difference between EOA and contract

• Understand EVM and the execution process of the contract

• Understand the approval and permit design of ERC-20

• < p style="text-align: left;">Details can be found at: https://support.token.im/hc/zh-tw/articles/22181703417241

EIP-3074

▶  Better and safer user experience

EIP-3074 allows EOA to transfer control to the designated contract , thereby obtaining the same rich execution capabilities as the contract.

Before EIP-3074, EOA could only perform one operation each time it sent a transaction, such as going to approve ERC20 or going to Uniswap to exchange; after EIP-3074 , EOA can accomplish multiple operations at once, or even lead to previously unimagined uses.

In short, EIP-3074 greatly improves the user experience, and the currently familiar authorization methods will also be reshaped, while maintaining the same user experience. Improve security.

And through EIP-3074, EOA no longer has to send transactions to the chain itself, so there is no need to worry about raising ETH first to pay for transaction fees. question.

▶ Invoker Contract

The contract that can obtain EOA control is called the Invoker contract. Of course, not any contract can gain control of EOA: EOA must be signed with a private key, and the signature content will clearly specify which Invoker contract it is and the operations that the Invoker is allowed to perform.

△ The EOA signature content will clearly specify which Invoker contract (invoker address) and authorize the operation (commit) of the Invoker contract.

The actual execution process will probably look like this:

• Alice signs with her EOA private key, and then gives the signature content and seal to the Relayer.

• Relayer brings the chain to the Invoker contract for execution.

• Invoker verifies the signature. After passing the verification, you can perform operations as EOA, such as go to approve USDC, and then go to Uniswap Perform asset swaps, and finally use some USDC to give Relayer as handling fees.

Note 1: Relayer is not necessary. Alice can also bring her own signature content and seal to the chain.

△ After the Invoker verifies the signature and starts executing the operation, it is executed as Alice EOA, which is like obtaining (limited) control of the EOA.

However, please note that the nonce value of the EOA will not be increased after execution, so the same signature may be reused (as long as the EOA nonce remains unchanged). Therefore, the Invoker needs to implement its own nonce mechanism to avoid replay.

△  If the Invoker contract is not anti-Replay, the same authorization can be executed all the time.

Learn more

About EIP-3074 Actual For an introduction to the operating mechanism, please refer to: https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

▶ Purpose

Batchcall< /strong>

Allows users to merge the execution of several transactions into one, saving the process of multiple authorized signatures and some Gas costs.

Note: This will require the DApp to also support the Batchcall function, such as EIP-5792, which is currently being pushed by the community. Otherwise, the DApp will treat the user as a normal EOA and will only prompt one transaction for each operation. User signature.

To learn about EIP-5792, please copy the link to your browser to view: https://eips.ethereum.org/EIPS/eip -5792

Session Key

Use The user can also let a third party operate on his behalf under certain conditions. The delegate key in the figure below is the authorized third party; the access policy is the execution restriction, such as restricting the operation of Uniswap and the maximum number of transfers per day. 1 ETH, authorization validity period, etc.

These conditions are designed and checked within the Invoker contract. As long as the check passes, the third party can perform operations as the user's EOA identity.

△ Telegram Bot can be given specific permissions to Perform operations on behalf of user EOA.

Native ETH Permit

As long as the conditions are met (i.e. Permit signature is legal), you can perform ETH transfers as the authorizer EOA, achieving the effect of the native ETH Permit.

Limit Order

The user fills in the limit order conditions, and when the conditions are met, it can be executed as the user EOA , including approve related digital assets to DEX, de-DEX swap and other operations. Compared with the Limit Order provided by DEX itself, users do not need to send transactions to DEX for approval in advance.

△ When Alice completes the order, Approve will be executed incidentally, and no prior approval is required.

If the condition is designed to be more general, it will become like an Intent contract: as long as the conditions specified by the user are met, anyone can use it The EOA identity is used to execute the intent.

△ As long as the Intent condition is met, anyone can initiate execution in the name of the user's EOA.

Social Recovery

Let users lose their EOA private key At this time, all the assets of the EOA can be transferred by using the EIP-3074 authorization signed by Alice and the signatures of her authorized persons (Husband and Trust Agent). In fact, Recover is a (transferable) asset, not account control. Once the EOA private key is lost, the EOA can no longer be used.

△ When the user loses the EOA private key, other authorized persons can sign and authorize the transfer of EOA assets.

Impact of EIP-3074

▶  Improve the way assets are authorized, or even replace approve/permit?

DApp is currently designed on the assumption that users are EOA: users must "approve in advance" and "approve is large enough" "Asset quantity" to the DApp contract, so that users do not need to stay online at all times, wait for DApp execution, and do not need to repeatedly approve, which greatly improves the user experience.

For example, for condition-triggered applications such as limit orders or DCA, users may not necessarily be online when the conditions are met, so they must approve in advance. The amount of assets allows the DApp contract to execute, and it may be executed repeatedly.

△ The user must approve the DApp's large enough asset amount in advance to facilitate the DApp's use of his money to operate.

△ But it is also necessary to trust DApp or avoid giving approval to fake DApp, and to be able to remove approval in real time.

Or the permit mode that appeared later, for example, EIP-2612  or the non-native Permit2 , all to improve the user experience and security of the approve model: users no longer need to approve a large amount of assets to each DApp contract (and each asset must be approved once), but only need to "sign a name". The DApp contract can be authorized to "withdraw a specified amount of assets" within a "specified time", which not only greatly reduces the attack surface, but also greatly improves the user experience.

Learn more

EIP-2612 details, please Copy the link below to the browser to query: https://eips.ethereum.org/EIPS/eip-2612

Permit2 details , please copy the link below to your browser for query:

https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction- 858ae3dddf18

△ Users only need to sign off the chain, and can specify the asset quantity and validity period, providing a better user experience and security than approve.

But in fact, not only approval, but also the permit mode is still used as a means of fraud attacks. Incidents still emerge one after another,: Victims mistakenly signed I thought it was a permit for DApp, but it was actually given to the attacker.

△ When users sign the permit, they can only see who they want to authorize, but they don't know what operations will be performed together with it.

Note: In addition, the current permit design is not compatible with DApps that perform repetitive operations, such as DCA or other recurring payment applications. This is because the permit has an anti-replay mechanism, so you cannot use the same permit again after completing a transfer. This means that the user must sign the permit in advance for every repeated operation in the future.

Learn more

Learn about permit In the event that the pattern is used as a means of fraud attack, please copy the link below and query it in your browser:

https://x.com/realScamSniffer/ status/1783027808723435727

https://x.com/realScamSniffer/status/1784932506174967970

https://x.com/realScamSniffer/status/1786738218962223226

But EIP -3074 brings an opportunity for change: when DApp developers know that EOA can perform various complex operations through Invoker, the design of DApp interaction no longer needs to sacrifice security in order to improve the user experience, such as "User Approve the amount of large amounts of assets in advance" and "the user signs a permit message to authorize the withdrawal."

Instead, users tie DApp operations to approve and perform atomic execution through Invoker: or approve and DApp operations If they are executed successfully together, otherwise they fail together, there is no possibility of approval being successful alone, so the user can be very sure that the approval this time is for this operation.

And the user uses the off-chain signature authorization method, so the user experience is the same as permit! This means that DApps will no longer need permit mode! In the future, wallets can directly block or more strictly review permit signature requests, without having to worry about whether users will be unable to use certain DApps (but will instead be exploited by fraud).

△ Users no longer just authorize an address, but authorize an address and what to do, and can even see the execution results of the simulation.

Note: This does not mean that fraud can be completely prevented! Users may also be deceived into fraudulent websites. Fraudulent websites can also set up approve or transfer operations for users to sign, but at this time the user can at least see what the signature operation is, and the wallet can even display it through simulation. The execution results are presented to the user so that the user can clearly know who will lose how much money and who will get more money. Compared with permit, which has no way of knowing what operation to perform or even the execution result, users have more information to decide whether to authorize or not. Although it is not a perfect prevention and control, it will still be a significant improvement on the current situation.

▶ How the wallet handles EOA nonce

The current EIP-3074 design will include the EOA nonce value in the signature content, so as long as EOA sends a transaction to the chain for execution and changes the nonce value, the original EIP-3074 authorization All will immediately fail.

If the user authorizes others to operate EOA on their behalf, such as the Session Key or Social Recovery method mentioned above, then the nonce of EOA must be avoided. be changed, otherwise all authorizations will have to be re-signed and handed over to the trustee, which will have a considerable impact on the user experience and the robustness of the mechanism.

If the user is authorized to operate by himself, there is no need to specifically prevent the EOA nonce from being changed, because the EIP-3074 signature is still expected to be executed at a certain date just like the transaction. Execute it before the deadline. It’s just that the wallet needs to manage more EIP-3074 transactions of the EOA: if there are EIP-3074 signatures waiting to be uploaded to the chain, then the transactions of the EOA itself will have to wait.

Note: The Invoker contract itself will (and should) maintain a nonce mechanism, so after the signature is used, it must be signed again, regardless of EOA. Whether the nonce changes.

Session Key and Social Recovery will most likely have to wait until EIP-3074 changes the rules to remove the EOA nonce from the signature content before they are likely to be blocked by large models. Adopted regulations. Therefore, the wallet only needs to focus on the use case of "user-authorized operations" and treat the EIP-3074 signature as a transaction. There is no need to worry about avoiding EOA sending transactions or changing the EOA nonce.

However, it should be noted that if the user wants to bring his own EIP-3074 signature content to the chain, there will be two disadvantages:

1. Users need to sign twice: once for the EIP-3074 signature and once for the on-chain transaction.

2. Because the on-chain transaction will first +1 the EOA nonce before the transaction starts to be executed, the user's EIP-3074 signature The EOA nonce must be +1 in advance to be able to match the EOA nonce +1 caused by self-winding.

△ Because the EOA nonce will be +1 first when uploading to the chain, when you start to verify the EIP-3074 signature, it will fail because the EOA nonce does not match.

△ Users can successfully pass the verification by +1 the EOA nonce in the EIP-3074 signature before uploading to the chain.

Summary and key points

• EIP-3074 allows EOA to obtain the same rich execution capabilities as contracts, opening up many new application scenarios.

• This will not only greatly improve the user experience, but will also change the current authorization method, allowing it to maintain the same user experience. becomes safer.

• And EIP-3074 is a simple signature. Users do not have to bring the signature to the chain for execution, so there is no need to worry. You must first collect ETH to pay the handling fee.

• The uses of EIP-3074 include Batch Call, Session Key, Native ETH Permit, Limit Order, and Social Recovery. Many of these are originally impossible to achieve with EOA, and some, such as Limit Order, require pre-authorization and other less secure methods to be used.

• EIP-3074 will also change the current authorization method. approve directly authorizes the specified address to have the right to withdraw digital assets indefinitely, and requires the user EOA to first send a transaction to execute approve, so the user experience and security are not good; permit only requires the user's signature, and each signature will The specified asset quantity and validity period are much better than approve in terms of user experience and security.

• However, permit is still frequently used for fraud. When signing, users can only know which address to authorize, the amount of assets and Validity period, but I don’t know what this authorization is intended to be used for. "What is it used for" will be another signature (or transaction). Normal DApp will ask the user to sign permit and "What is it used for", but they will still be two different signatures, so when a permit signature is requested, Neither the user nor the wallet has any way of knowing "what" this permit will be used for.

• With EIP-3074, users (1) do not need to approve a large amount of assets to DApp in advance, but have Approve only when operating, the effect is the same as permit; (2) Just sign and don’t have to worry about collecting ETH to pay the handling fee, the same as permit; (3) Each approve is bound to the specified operation, signed together, and used The applicant can clearly know "what the approval is used for" this time, which will be safer than the permit!

• We hope that EIP-3074 can successfully replace the current approve and permit modes and provide users with a more secure authorization method.