After EIP-1559, what is the focus of the Ethereum community on EIP-3074?

Original title: "Ethereum on the Attack: EIP-3074 After EIP-1559"

Source: Chinadefi

▪️ Ropsten test network has been online on June 24, block height is 10,499,401.

Forced the ️ & have spent Since its deployment, about 88,500 Ethereum test networks have burned down, valued at $177.6 million.

Forced the ️ & have spent Around the same time that ETH3 started, 100,000 Ethereum worth $200 million had been deposited into ETH3's pledge contracts.

The much-anticipated Ethereum Improvement Proposal EIP-1559 is finally deployed on the Ropsten test network for Ethereum's upcoming London upgrade. A few days ago, the launch dates for the three Ethereum test networks in London were announced for a hard fork. Ethereum core developer Tim Beiko announced that the block heights for Ropsten, Goerli and Rinkeby test networks have been determined. Ropsten stands at 10499401 and was launched on June 24. Goerli, on the other hand, will be on June 30 and Rinkeby will be on July 7.

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

While London Hard Fork has five Ethereum Improvement Proposals, EIP-1559 has garnered 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 networks, worth $177.6 million, have burned down since the Ropsten test network was upgraded in London. However, the massive amount of Ethereum burned by EIP-1559 has reignited talk of a major ETH3 overhaul of deflation. Due to the combustion mechanism, the ether burns faster than the circulating supply. This could be very beneficial to the price of ETH.

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

However, EIP-1559 isn't the only EIP the Ethereum community is watching. EIP-3074 is another improvement proposal highly anticipated by the community in the upgrade. According to David Mihal and his tweets, one of the major security issues that Ethereum ignored was the approval of ERC20. He added that he has pushed ERC777 and that their only chance to fix the issue is EIP-3074. The proposed Ethereum improvements would allow users to approve transfers, perform actions and revoke approvals in a single transaction.

Previously, Ethereum developers noted that the EIP-1559 was not designed to reduce the cost of gas: but many still believe that the proposal will definitely significantly reduce the cost of gas. This could even have cut miners' incomes by as much as 50 per cent, leading to a "miners' uprising" that ultimately failed. Nonetheless, the London upgrade is expected to contribute to the bullish trend for Ethereum. Renowned cryptography analyst Cryptoquant noted that around the same time ETH3 launched, 100,000 Ethereum worth $200 million had been deposited in ETH3's pledge contracts. Currently, more than 5% of the supply of ETH is locked up, valued at about $11.75 billion.

What is EIP-3074?

When we want to send a token to a smart contract, we usually have to do two transactions: the first transaction Approve is the contract to spend our token, and the second transaction TransferFrom is the transaction to send the token to the contract.

EIP-3074 solves the problem by introducing a smart contract approach to send transactions within an externally owned account (EOA, or simply a regular Ethereum address).

This EIP introduces two EVM directives, AUTH and AUTHCALL. The first sets the context variable *authorized* based on 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 directives (also known as opcodes) let the smart contract authorize the 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) : Gas for a transaction paid from another account. This will also allow us to send tokens from an address that does not have any ether.

Bulk transactions: Sending multiple transactions in a single call. This ensures that two or more transactions are executed in the same block and can also reduce transaction costs.

Improved User Experience (UX) : For example, we can call Approve and TransferFrom on a single transaction.

Unlike existing solutions to these problems, the EIP-3074 does not require a smart contract wallet. We can simply send the transaction to the so-called caller who executes the transaction. Callers are stateless, trustless smart contracts that do not require us to send the balance to the contract up front. The EIP-3074 also does not introduce a new type of transaction. It should be technically easier to implement by introducing only two new EVM directives.

The AUTH and AUTHCALL opcodes

EIP-3074 defines two new opcodes that can be invoked from a smart contract:

AUTH (0xF6) - Authorizes externally owned accounts based on signature and submission. It takes four input parameters: YParity, R, and S for Commit and signature.

AuthCall (0xF7) - Sends the call (transaction) in the authorized EOA context. It takes eight input parameters :gas, addr, value, valueExt, argsOffSet, argslLength, retoffSet, retLength. This is similar to the existing CALL opcode.

To authorize an EOA, we need a signed message from that EOA. A smart contract that calls AUTH can recover the signer from the message signature and then set the message signature to   Context variable authorized EVM. Now, whenever an AuthCall is invoked by a smart contract, the caller is set to the authorization address. When the smart contract being called calls the Caller (for example, through Solidity's MSG.Sender), this is now the address of the authorized EOA, not the address of the smart contract CALLER that performed the call.

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

A basic EIP-3074 process in which the caller contract sends multiple transactions.

EOA signature authorization information;

The EOA or other GAS payer sends transaction data and authorization information to the caller contract;

The caller contract uses AUTH to perform authorization and uses AuthCall to send the transaction.

It does not matter who sends the transaction into the contract, as long as the EOA's signature is valid. This allows someone else (or another account) to send the transaction.

Authorize messages and commits

To perform authorization, the EOA must sign the message in a specific format:

  (note: | | as byte serial operator)

It consists of three parts: a magic byte (0x03), the caller's address padded to 32 bytes (the address of the smart contract that will execute the authorization), and a 32-byte commit.

Authorization message format, including examples that can be used for submission

A commit describes the object that the EOA commits and can be evaluated based on certain properties of the call (such as address, value). The caller contract can recalculate the commit based on the properties provided, and if these fields are correct, authorization is performed.

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

We can hash these fields (for example, join them together in a determinative way, or use something like EIP-712) and use them as submissions.

We can provide the signatures of the transaction and authorization messages to be sent in a smart contract, as shown by the JSON data. A contract function could look like this:

The smart contract recalculates the commit transaction and feeds this commit (along with the signature) to the AUTH call. This will attempt to recover the signer's address, and if the submission is invalid, the wrong address will be recovered from the signature, meaning that the transaction will fail.

The caller is entirely responsible for ensuring that this commit is secure. We can simply sign the message as committed with 0x0 and give the smart contract full access to the EOA. Previous versions of EIP-3074 included a stricter submission format that included things like replay protection, but it was later removed for greater flexibility. Therefore, it is important to trust the caller that we interact with.

Restrictions and security issues

The EIP-3074 is able to change the Caller based on the signature, significantly changing the way EVM works. This could introduce potential loopholes in both new and existing contracts. Therefore, EIP-3074 was audited.

Some of the 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 submissions. Callers are free to implement this any way they want. This means that the caller is fully responsible for providing adequate protection against (for example) replay attacks.

If the submission does not contain some kind of random number, you can simply take the signed message and send it back to the caller. A malicious caller can gain control of the EOA by not validating the submission at all. We should always be careful when signing messages.

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

An upgradable caller

EIP-3074 explicitly states that the calling program must be non-upgradeable. If the caller is scaleable, someone can deploy another version of the caller that does not validate the commit, giving the contract full control over the EOA.

Reentrant attack

Currently, smart contracts can use require(TX.Origin == Msg.Sender), which checks if a transaction is sent from the EOA(and not from another contract). This allows for simple reentrant prevention because it prevents the contract from calling the function.

EIP-3074 also allows TX.Origin to be the signer of the authorization message. Even if the call is performed by a smart contract AuthCall, any S performed by the caller will cause TX.Origin == Msg.Sender to be true, potentially introducing a reentrant attack. EIP-3074 states: "[...] The authors of this EIP could not find any examples of this form of reentrant protection, although the search was not exhaustive."

conclusion

EIP-3074 opens up many exciting new possibilities for Ethereum. Auth and AuthCall allow the EOA to delegate control of the account to the smart contract caller, making it possible to send bulk transactions, sponsored transactions, and so on. However, it brings some significant changes to the way transactions work on Ethereum, so a lot more thought needs to be given to security before EIP-3074 can be activated on the mainnet.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia