EIP-3074: AUTH and AUTHCALL opcodes

Yes, fixed! More words to satisfy spam bot.

1 Like

I was always too skeptical about this EIP due it is introducing ability to steal all user tokens with 1 transaction, not only ETH as previously.

But today I realized that this EIP is effectively generalizing signature based calls as EIP-2612 (aka Permit) and others.

This EIP is also almost resolving EOA non-programmability.

1 Like

It could even effectively deprecate ERC20 approves/allowances usage especially if AuthContract will be additionally introduced compatible with EIP-1271.

Wish we had unification among EOA and smart contract based authentications (aka signatures)

1 Like

What do you think about introducing transaction format change allowing specifying DELEGATECALL for the top transaction trace?

There are a few proposals that attempt to add bytecode execution to EOAs (eg. EIP-2803.) Not exactly the same, but similar idea.

Found exactly the same: EIP-5806: Delegate transaction
Discussion: EIP-5806 Delegate transaction - #2 by Amxx

I have a question about calculating the dynamic gas portion (dynamic_gas ), and the gas available for execution in the sub call (subcall_gas ) for AUTHCALL.

According to the provided pseudo-codes, if the value is not zero, the cost of gas should add 6700, it is not 9000 because no gas stipend even if the value is not zero. The value added to gas is CallValueTransferGas - CallStipend, which means stipend gas is included in 9000 value transfer gas.

if value > 0:
    dynamic_gas += 6700         # NB: Not 9000, like in `CALL`

But in go-ethereum, the stipend gas is not included in 9000.

When executing the opcode CALL, if value is not 0, firstly add 9000 gas in function gasCall() :

Then value will be checked in function opCall(), if it is not 0, 2300 stipend gas will be added :

Therefore, I think the dynamic_gas should add 9000 not 6700 in provided pseudo-codes.

Itā€™s been a long while and Iā€™m not extremely familiar with geth, but I think the first link (core/vm/gas_table.go) is where the gas is deducted from the parent, and the second link (core/vm/instructions.go) calculates how much is available to the child.

Note that MAGIC would have to be changed to a different value, now that EIP-4844 uses 0x03 as its EIP-2718 transaction type.

1 Like

@SamWilsn hey what is the progress on this eip and how many chances are there of it going through?

There hasnā€™t been much movement on this. Weā€™ve paused pushing for it on ACD for the time being.

1 Like

Is that still the case given the recent growing support in the ecosystem?

1 Like

Talks have opened up again. Still rather early to tell though.

1 Like

There is a breakout call on this subject tentatively scheduled for Feb. 28th: Future EOA/AA Breakout Room Ā· Issue #962 Ā· ethereum/pm Ā· GitHub

2 Likes

An hour wasnā€™t enough to both levelset AND advance too far towards decisioning, it seems, so the topic will be continued on tomorrowā€™s call, at 7am denver time:

Regarding the recent changes in this pull request, how sure are we that the worse case invalidation with 3074 is similar to a proposer invalidating transactions with a block?

Back of the napkin estimate looks like AUTH + AUTHCALL costs about 10,200 and a normal transaction is about 21,000. So this halves the price of a tx pool invalidation attack?

There is something I would like to raise, we still have accounts where pkeys are stolen from (these are now public, so every time you send ETH there it is immediately drained). However, some of these accounts have other assets with more value than just a simple ETH transfer (e.g. ERC20 tokens). I think we can foresee that at the moment we launch this opcode, then we will see a huge influx of people spamming AUTHCALL on accounts which have almost zero eth left, but with significant ETH values (and we cannot determine if these are the original owners or the attackers (likely: the attackers)). Just wanted to raise this point here, not sure if this was raised before.

Stealing ERC20s was practically not possible from these accounts, since you need ETH to fund these accounts to send the txn. Since we pay 21k gas for one tx, and we pay more for an ERC20 transfer, then the gas bidding accounting will always be won by the ETH tx.

Getting ERC20 tokens out of such accounts can already be done via bundled transactions and a private relay. In fact, there is a self-help tool (disclosure: Iā€™m on the team that built it) that allows end-users to do this without needing any knowledge of scripting. I think at this point, any well known tokens in public-private-key accounts that are trapped have already been liquidated.

1 Like

Ah right, good point, I should have been aware of this method of course. Thanks for the reply :slight_smile:

Given the important push for inclusion of this EIP in the next hardfork, I would like to formally express my concerns about the usage of the signerā€™s nonce for invalidation of the AUTH, and the inconsistencies that creates.

Lets says Alice has nonce 10, and signs an Auth with nonce 10. This signature is valid, and Bob can relay it to perform some operation in Aliceā€™s name. After the operation is done, Aliceā€™s nonce does not change, so it is essential that the forwarder (contract that uses the Auth and does AuthCall) includes some replay protection.

However, if Bob doesnā€™t relay the message, and Alice wants to do it herself (Alice might be using a ā€œmulticallā€ forwarder), then the nonce Alice used is invalid, because the transaction that Alice submits increases the nonce BEFORE the Auth is verified.

This means that if Alice plans to relay the Auth herself, she needs to sign something different (nonce 11) than if she plans to have Bob relay it (nonce 10).

Furthermore, after Alice has done the relaying, her nonce is now 11, and the Auth she just used is still valid, so anyone could possibly re-use it if the forwarder doesnā€™t include some replay protection mechanism.

I think this is really messed up, and I would like to propose that if authority is tx.origin, then the nonce that is used should be the one before the current transaction (ie. the current one minus one).

I believe this change would make signing a Auth agnostic of the relayer (which I believe is a good thing).