EIP-3074: AUTH and AUTHCALL opcodes

EIPs Core EIPs
, ,
248

The fragmentation I’ve outlined primarily relates to dapps rather than wallets. What I mean by “initiate fragmentation” is that 3074 will set in motion a parallel track of smart wallet development that does not seamlessly align with the roadmap for full account abstraction.

I acknowledge the importance of additional functionalities to EOAs. Infinite approval scams have hunted the ecosystem for too long, and batch transactions is the solution. Gas sponsorship is crucial for usability beyond today’s users. I do agree that upgrading EOAs isn’t a trivial task, as you’ve rightly pointed out. It poses risks because someone will inevitably honor the key.

Although 3074 seems straightforward to implement, its implications on wallet ecosystem development are profound if integrated into L1. It further encourages EOA development. It slows down users and developers from transitioning to to a better model where it protects users with key rotation and different signature schemes.

EOAs will eventually be deprecated, not by choice, but due to quantum advancement. Further enshrinement encourages not only its continued spread and adoption, but also it’s gets us away further from the end goal of full native AA.

249

Not to sound too much like a broken record, but EIP-3074 was designed to allow changing the signature format/algorithm. Whatever approach is adopted by EOA and ecrecover signatures, EIP-3074 can adopt too.

1 Like
250

A post by @yoavw: Implications of EIP-3074 inclusion - HackMD

My reply: Sam's Reply to Implications of EIP-3074 inclusion - HackMD

1 Like
251

My reply to Sam’s reply: Yoav's Reply to Sam’s Reply to Implications of EIP-3074 inclusion - HackMD

252

Can we check both codesize at that address and tx.origin vs. msg.sender to determine if msg.sender is an EOA?

For example,

uint256 codeSize;
assembly {
    codeSize := extcodesize(msg.sender)
}
require(msg.sender == tx.origin && codeSize == 0, "not an EOA")

I believe EIP-3074 can possibly bypass the first check msg.sender == tx.origin, contracts have zero codesize can bypass the second check codeSize == 0, but they can never be bypassed together? You have to authorize an existing contract to AUTHCALL, right?

Correct me if I made a mistake, thanks.

253

Just FYI, EIP-3074 has mostly been replaced by EIP-7702.

To answer your question directly:

msg.sender will be the EOA, so codeSize will be zero.

2 Likes