The Ropsten test network went live on June 24 with a block height of 10,499,401.
Since deployment, approximately 88,500 test network ethers have been burned, valued at $177.6 million.
Around the same time Eth2 was launched, 100,000 Ether worth $200 million has been deposited into Eth2’s pledge contract.
The highly anticipated Ether improvement proposal EIP-1559 was finally deployed on the Ropsten test network for Ether’s upcoming London upgrade. The release dates for the three Ether test networks for the London hard fork were announced a few days ago. Tim Beiko, a core Ether developer, announced that the block heights of the Ropsten, Goerli and Rinkeby test networks have been determined. 10499401 for Ropsten was launched on June 24. On the other hand, Goerli on June 30 and Rinkeby will be on July 7.
EIP-1559’s burning mechanism may benefit the price of the token
While the London hard fork has five Ether improvement proposals, EIP-1559 has attracted all the attention. The new upgrade is expected to consume transaction fees on the network. According to EIP-1559 tracking site Watch the Burn, about 88,500 test network ethers have been burned since the Ropsten test network was upgraded in London, worth $177.6 million. However, the large number of Ether burned by EIP-1559 has reignited the Eth2 overhaul deflation debate. Due to the burning mechanism, Ether is burning faster than the circulating supply. This could be very beneficial to the price of ETH.
After EIP-1559, the community is concerned about EIP-3074, which aims to address security issues
However, EIP-1559 is not the only EIP that the Ether community is concerned about. eIP-3074 is another proposed improvement that the community is highly anticipating in the upgrade. According to David Mihal and his tweets, one of the main security issues that Etherpad ignores is the approval of ERC20. He added that he has pushed for ERC777 and their only chance to fix this issue is EIP-3074. this ethereum improvement proposal will allow users to approve transfers, perform actions and revoke approvals in a single transaction.
Previously, ethereum developers noted that EIP-1559 was not designed to reduce the cost of gas: but many still believe that the proposal will certainly reduce the cost of gas significantly. It may even reduce miners’ income by 50%, leading to a “miners’ revolt” that ultimately ended in failure. Nonetheless, the London upgrade is expected to boost the bullish trend of ethereum. CryptoQuant, a leading crypto analyst, noted that around the same time Eth2 was launched, $100,000,000 worth of Ether was deposited into Eth2’s pledge contract. Currently, more than 5% of the ETH supply is locked up, worth about $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 transactionapprove is the contract that spends our tokens, and the second is the transferFrom the transaction 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 up authorized based on the contextual variables of the ECDSA signature. The second sends the call as authorized. This essentially delegates control of the EOA to the [a] smart contract.
The AUTH and AUTHCALL EVM instructions (also called opcodes) let the smart contract authorize the EOA based on a signed message and send transactions (“calls”) from that EOA. This opens up a number of possibilities, such as :
Sponsored transactions (also called meta-transactions): pay the gas of a transaction from another account. this will also allow us to send tokens from an address that does not have any Ether.
Batch transactions: Sending multiple transactions in one call. This ensures 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 in a single transaction.
Unlike existing solutions to these problems, EIP-3074 does not require a smart contract wallet. We can simply send the transaction to the so-called caller that executes it. Callers are stateless, trustless smart contracts that do not require us to send the balance to the contract in advance. eip-3074 also does not introduce new transaction types. By introducing only two new EVM instructions, it should be technically easier to implement.
AUTH and AUTHCALL opcodes
EIP-3074 defines two new opcodes that can be called from a smart contract:
AUTH (0xf6) – authorizes externally owned accounts based on signature and submission. It accepts four input parameters: commit and signed yParity, r and s.
AUTHCALL (0xf7) – sends the invocation (transaction) in the context of an authorized EOA. 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. The 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 the smart contract calls AUTHCALL, the caller is set to the authorized address. When the called smart contract calls CALLER (e.g., via Solidity’s msg.sender), this is now the address of the authorized EOA, not the address of the smart contract caller performing the call.
The basic process for sending one or more transactions is shown below:
A basic EIP-3074 process where the caller contract sends multiple transactions.
The EOA signs the authorization information;
The EOA or other gas payer sends the transaction data and authorization information to the caller contract;
The caller contract executes the authorization using AUTH and sends the transactions using AUTHCALL.
It does not matter who sends the transaction to the contract, as long as the EOA’s signature is valid. This allows someone else (or another account) to send the transaction.
Authorization Messages and Submissions
In order to execute an authorization, the EOA must sign the message in a specific format:
(Note: || is used as a byte concatenation operator)
It consists of three parts: a magic byte (0x03), the caller address (the address of the smart contract that will execute the authorization) filled to 32 bytes, and a 32-byte commit.
Authorization message format, including examples of what can be used for a submission
A commit describes the object of an EOA commit and can be calculated based on certain attributes of the call (e.g., address, value). The caller contract can recalculate the commit based on the attributes provided and, if these fields are correct, perform the authorization.
For example, suppose we want to send the following transaction (represented as JSON):
We can hash these fields (e.g., join them together in a deterministic way, or use something like EIP-712) and use them as a commit.
We can provide the signature of the transaction and authorization message to be sent in the smart contract, as shown in this JSON data. The contract function could 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 signer’s address, and if the commit is invalid, the wrong address will be recovered from the signature, which means the transaction will fail.
The caller is fully responsible for ensuring that this commit is secure. We can simply sign the message as a commit with 0x0 and give the smart contract full access to the EOA. Previous versions of EIP-3074 included a stricter commit format, including things like replay protection, but this has since been removed for more flexibility. Therefore, it is important to trust the caller with whom we interact.
Restrictions and security issues
EIP-3074 significantly changes the way EVM works by being able to change the CALLER based on the signature. This can introduce potential vulnerabilities in new and existing contracts. Therefore, EIP-3074 is audited.
Some possible security issues are explained below. For these different reasons, EIP-3074 recommends only interacting with trusted callers.
Weak commit and replay attacks
As mentioned above, EIP-3074 does not define a standardized format for commits. Callers are free to implement this in any way they wish. This means that the caller is entirely responsible for providing sufficient protection against (for example) replay attacks.
If the commit does not contain some random number, the signed message can simply be obtained and sent to the caller again. A malicious caller can gain control of the EOA by not verifying 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 a basic protection against replay attacks. This makes it impossible to replay a caller’s authorization message on another caller.
EIP-3074 explicitly states that the calling program must be non-upgradable. If the calling program is upgradable, then someone can deploy another version of that calling program that does not validate commits, thus giving the contract full control over the EOA.
Currently, smart contracts can use require(tx.origin == msg.sender), which checks if a transaction was sent from the EOA (and not from another contract). This allows simple re-entry prevention, as it prevents contracts from calling functions.
EIP-3074 also allows tx.origin to be the signer of authorized messages. Even if the call is executed by the smart contract AUTHCALL, any s executed by the caller will cause tx.origin == msg.sender to be true, potentially introducing a re-entry attack. eip-3074 mentions: “[…] the authors of this EIP did not find any such form of example of re-entry protection, although the search was not exhaustive.”
EIP-3074 opens up many exciting new possibilities for Ether.AUTH and AUTHCALL allow EOA to delegate control of accounts to smart contract callers, making it possible to send bulk transactions, sponsored transactions, etc. However, it brings some significant changes to the way transactions work on Ether, so more thought needs to be given to security before EIP-3074 can be activated on the mainnet.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/the-ever-advancing-ether-eip-3074-after-eip-1559/
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.