BTC
ETH
HTX
SOL
BNB
View Market
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Ethereum on the Rise: EIP-3074 after EIP-1559

ChinaDeFi
特邀专栏作者
This article is about 3568 words, reading the full article takes about 6 minutes
Ropsten has a height of 10499401 and was launched on June 24. Goerli, on the other hand, is on June 30 and Rinkeby will be on July 7.
AI Summary
Expand
Ropsten has a height of 10499401 and was launched on June 24. Goerli, on the other hand, is on June 30 and Rinkeby will be on July 7.
  • The Ropsten testnet was launched on June 24 with a block height of 10,499,401.

  • Some 88,500 testnet ether worth $177.6 million have been burned since deployment.

  • Around the same time Eth2 launched, 100,000 ETH worth $200 million had been deposited into Eth2’s staking contract.

  • The highly anticipated Ethereum Improvement Proposal EIP-1559 has finally been deployed on the Ropsten testnet for Ethereum’s upcoming London upgrade. A few days ago, the three Ethereum testnet launch dates for the London hard fork were announced. Ethereum core developer Tim Beiko announced that the block heights of the Ropsten, Goerli and Rinkeby testnets have been determined. Ropsten has a height of 10499401 and was launched on June 24. Goerli, on the other hand, is on June 30 and Rinkeby will be on July 7.

    The burning mechanism of EIP-1559 may benefit the price of the token

    While the London hard fork has 5 Ethereum improvement proposals, EIP-1559 has grabbed all the attention. The new upgrade is expected to consume transaction fees on the network. According to EIP-1559 tracking site Watch the Burn, since the Ropsten testnet was upgraded in London, about 88,500 testnet ethers have been burned, worth $177.6 million. However, the large amount of Ethereum burned by EIP-1559 has reignited the discussion of Eth2 overhaul deflation. Ether burns faster than the circulating supply due to the burning mechanism. This could be very beneficial for the price of ETH.

    After EIP-1559, the community focused on EIP-3074, which aims to address security issues

    However, EIP-1559 is not the only EIP that the Ethereum community is paying attention to. EIP-3074 is another improvement proposal highly anticipated by the community in the upgrade. According to David Mihal and his tweets, one major security issue that Ethereum has overlooked is ERC20 approval. He added that he has pushed for ERC777 and their only chance to fix this is EIP-3074. The ethereum improvement proposal would allow users to approve transfers, execute actions and revoke approvals in a single transaction.

    Previously, ethereum developers noted that EIP-1559 was not designed to reduce gas costs: but many still believe that the proposal will definitely reduce gas costs significantly. This could even reduce miners' income by 50%, leading to a "miner's uprising", which ultimately failed. Nonetheless, the upgrade in London is expected to boost the bullish trend for Ethereum. Well-known encryption analyst CryptoQuant pointed out that around the same time Eth2 was launched, 100,000 Ethereum worth $200 million had been deposited into Eth2's pledge contract. Currently, more than 5% of the ETH supply is locked, worth approximately $11.75 billion.

    What is EIP-3074?

    When we want to send tokens to a smart contract, we usually have to do two transactions: the first transaction approve is the contract that spends our tokens, and the second transaction is transferFrom that sends the tokens to the contract.

    EIP-3074 solves the problem by introducing a way for smart contracts to send transactions in an externally owned account (EOA, or simply a regular Ethereum address).

    This EIP introduces two EVM instructions AUTH and AUTHCALL. The first sets the *authorized* context variable for ECDSA-based signatures. The second sends the call as *authorized*. This essentially delegates control of the EOA to [a] smart contract.

    The AUTH and AUTHCALL EVM instructions (also known as opcodes) let the smart contract authorize an EOA based on a signed message, and send a transaction (“call”) from that EOA. This opens up many possibilities, such as:

  • Sponsored transactions (also known as meta transactions): Paying the gas for a transaction from another account. This will also allow us to send tokens from an address that doesn't have any ether.

  • Batch transactions: send multiple transactions in one call. This guarantees that two or more transactions are executed in the same block and also reduces transaction fees.

  • Improved User Experience (UX): For example, we can call approve and transferFrom within a single transaction.

  • secondary title

    AUTH and AUTHCALL opcodes

    EIP-3074 defines two new opcodes that can be called from smart contracts:

  • AUTH (0xf6) - Authorize externally owned accounts based on signature and commit. It accepts four input parameters: commit and signature yParity, r and s.

  • AUTHCALL (0xf7) - Send call (transaction) in authorized EOA context. It accepts 8 input parameters: gas, addr, value, valueExt, argsOffset, argsLength, retOffset, retLength. This is similar to the existing CALL opcode.

  • In order to authorize an EOA, we need a signed message from that EOA. A smart contract calling AUTH can recover the signer from the message signature and then set the message signature to the authorized EVM context variable. Now, whenever a smart contract calls AUTHCALL, the caller is set to the authorized address. When the called smart contract invokes CALLER (for example, via Solidity's msg.sender ), this is now the address that authorizes the EOA, not the address of the caller of the smart contract that performed the call.

    The basic flow for sending one or more transactions is as follows:

    A basic EIP-3074 flow where the caller contract sends multiple transactions.

  • EOA signing authorization information;

  • EOA or other gas payers send transaction data and authorization information to the caller contract;

  • The caller contract performs authorization using AUTH and sends transactions using AUTHCALL.

  • secondary title

    Authorization messages and commits

    image description

    (Note: || is used as byte concatenation operator)

    image description

    Authorization message format, including examples available for submission

    A commit describes the object that the EOA commits to, and can be computed based on certain attributes (eg address, value) of the call. The caller contract can recompute the submission based on the provided properties, and if those fields are correct, authorization is performed.

    For example, suppose we want to send the following transaction (represented as JSON):

    We can hash these fields (e.g. concatenate them together in a deterministic way, or use something like EIP-712) and use that as a commit.

    We can provide signatures of transactions and authorization messages to be sent in smart contracts, as shown in this JSON data. A contract function can look like this:

    The smart contract recomputes the commit transaction and provides this commit (along with the signature) to the AUTH call. This will attempt to recover the address of the signer, and if the commit is invalid, the wrong address will be recovered from the signature, meaning the transaction will fail.

    text

    Limitations and Security Issues

    EIP-3074 is able to change the CALLER based on the signature, which significantly changes the way the EVM works. This could introduce potential vulnerabilities in new and existing contracts. Therefore, EIP-3074 is audited.

    text

    Weak commit and replay attack

    As mentioned above, EIP-3074 does not define a standardized format for submissions. Callers are free to implement this in any way they want. This means that the caller is solely responsible for providing adequate protection against (for example) replay attacks.

    If the commit doesn't contain some kind of nonce, you can simply get the signed message and send it to the caller again. A malicious caller can gain control of the EOA by not validating the commit at all. We should always be careful when signing messages.

    By including the address of the caller in the authorization message, EIP-3074 has basic protection against replay attacks. This makes it impossible to replay one caller's authorization message on another caller.

    upgradable caller

    reentrancy attack

    reentrancy attack

    Currently, smart contracts can use require(tx.origin == msg.sender), which checks whether a transaction is sent from EOA (and not another contract). This allows for easy reentrancy prevention as it prevents contracts from calling functions.

    in conclusion

    in conclusion

    EIP-3074 brings many exciting new possibilities to Ethereum. AUTH and AUTHCALL allow EOA to delegate the control of the account to the smart contract caller, making it possible to send batch transactions, sponsor transactions, etc. However, it brings some significant changes to the way transactions work on Ethereum, so more thought needs to be given to security before EIP-3074 is activated on mainnet.


ETH
Developer
Welcome to Join Odaily Official Community