前言

这几天由于一个跟AA相关的EIP3074被确认排入下一次Pectra硬分叉，因此引起了社群广泛的讨论。Twitter和一些内存块链媒体上都有许多关于EIP3074的介绍，但是由于EIP3074实际改动有点复杂，也有容易让人误解的地方，因此今天希望用这篇文章厘清大家对于这个EIP的疑虑。

EIP3074的主要目的，可z 2 F } 6 M A K以用一句话概括：让EOA（externallyJ + b w K 4 Q owned account）在不需要部署合约钱包（smart contract waly $ ; s v Ilet）的情( ^ n况下，拥有合约钱包的功能。这表n r !示一般钱包用户能直接「升级」自己的EOA，就像安装扩充功能一样，不需要部署新合约或变更现有\ : –的地址。那究竟是怎么做到的呢？

EIP3074前的交易流程

大部分的合约在开发时，都仰赖msg.sender; ~ r . –这个B y K 9变数C G 9 5 1 $ J # ~来判断来者何人，即「呼叫此合约的帐户」。如果有一连串的合约连续呼叫，则每次对外进行呼叫（CALL），接收方收到的msg.sender都会更新。

每一个call，都会开启一个新的call frame，有新的msg.sender

由于合约都仰赖msg.sender来判断呼叫者的身份，因此n _ ! x E + h )常常会不知不觉中限制了呼叫者的UX。如果Alice用了一个EOA（alice.eth）收取了ERC20代币，那么她必须要从自己的EOA花eth发出交易，才能制造出呼叫者msg.s= v S \ : 0 _ V 0ender = alice.e+ 8 R [ / w #tb B k 2 ^ R f Q Oh这样的条件，去呼叫合约进行转账。

同样的原因，加上需要先对代币合约进行approve，才能给其他Dapp使用，也O 7 ( n M 8 8造成许多交易都必须用EOA发起两笔交易才能完成。

需要两笔交易进行一个swap

这就最为人诟病的UX问题；9 D b j |也是所有AA文章都会介绍的两点：必须要亲自用eO o 2 @th付手续费、且不能使用批次交易& x . A。

在没有EIP3074之前，我们必须仰赖合约钱包来解决这些问题，因为合约钱包能自动帮你打包多笔交易，并且让别人代付手续费。但这样的升级不是无痛的，你必须要把所有的资产转移到你新的合约帐户中，并且以这个新的合约钱包作为你去收钱、以及做合约互动的主体：

使用传统「合约帐户」如何解决手续费代付，! 9 L E Y . z H C以及批次交易问题

如上图中，尽管透过一个合约能送多笔交易了，但实际对应用程序合约发送Call呼叫的主体从EOA变成了紫色的合约钱包，我\ + Q们被记录在Dapp中的地址也R N :从原本的alicN + t }e.eth变成smartalice.eth，是被当作不同的两个实体。

这样的解决方法其实? C Z { c很有效，但是对于很多既有的EOA用户来说，迁移EOA成本很高，不但要找出所有存在不同协| C & o # $ N A a议里的仓位，哪天发现有忘记的钱或是有空投可以领又要大费周章$ r 5 0 e l \转eth回来付gas。这或许是到今天为止合约ㄑㄧㄢ包都不普遍的原因之一，毕竟大家刚开始接触内存块链可能不会使用这么fancy的钱包，也不会想要这些比较进阶的功能，n A W ! N ; :但使用久了又. q g } a懒得换了。

EIP3074的解决方法

如果退一步想，我们使用msg.sender是为了验证U _ P [ $发起交易者的身份，那么其实只要确保msg.sender有正当的授权，我们并不一定要强制他一定要是B v b z呼叫本合约的「前一个地址」。

对于; E 5 4 L bEIP3074很好的解释方法，就是通过新的OP code，和一个新的钱包外挂：invoker（调用+ B 3 v 0 e者）合约，打破既有的msg.sendeB y x ] r ! g 1 dr必须来自前一个呼叫地址的限制。一旦我们打破{ a Y ; ` N ~ *这个限制，我们可以允许客制化的「代6 2 9 m理逻辑」写在invoker合约中，创造非常多= f ? D =的g . * p % p r l )变化。

A motivating use case of this E} b _ ? 6 0 q LIP is that it allowsG _ W 7 q j H any EOA to act like a smart contract wallet without deploying a contract.

EIP3074新的交易流程图如下：

经由Invoker验证后发出的呼叫，会使用N F ( _ #新的AUTHCALL，而非CALL。对被呼叫的合约而M L # s ! q j – [言msg.sender变成了最初授权签章的EOA。

新的OP Code

这个EIP透过两个新的OP code来做到这个效果：AUTH与AUTHCALL。AUTH就是授权的步骤，会确认EOA的持有者有签过名，授权invoker做出代理0 q A \ q w ~ o呼叫，接着合约如果使用AUTHCALL取代CALL，则对外呼叫时msg.sen[ = . V ~der即可以被复写为EOA签名者。

注：这个EIP刚提出时，其实只有l q ~ r z一个OP code，就是AUTHCALL，并且直接对着要对外呼叫的内容（calldata）进行签章，相当于每个对外的授权呼叫就要签名一次。但后考虑到invoker一个很大的使用情境是来帮大家做批次交易，如果每次对做AUTHCALL都要验一次签章，将会代表用户如果要批次做多笔交易，就要签名多次，体验不是很好。因此后来转向给予invoker最大的灵活度，把一个OPCode分成两F v _ B | V 5个阶段，只要在同一个call frame中Av [ ^ N [UTH过一次，就可以做多次的AUTHCALL。

一样是一笔交易（1 tx），使用两次对外AUTHCALL来做到batching的效果

执得注意的EIP细节

InvoP – I n w s Uker的角色

这个EIP在第一眼看到时，看起来非常的可怕，毕竟「允许合约代表我的EOA」听起来是一f Q V [个潘多拉的盒子，将引Q o 1 s O \ s s来无尽灾祸。但我认为这是因为我们平时在理解合约的时候，会时常联想到一些DeFi Protocol，他们通常可升级、有一些信任假设，并且常常被hacked。这些都让我们不信任智能合约。因此很多人对于这个EIP的质疑，来自合约的安全性。

但我自己认3 f \ U v为一个比较好理解方式，是把invoker当作钱包的一部分，而非是一个传统的合约` H ( e `。换句话说，上述这两个Opco, d o s t Zde不应~ # F B N L该* / f X z a 4被任何DeFi protocolg B 3 y C )使用，相反的，他们只应该被新的钱m L 6 e包外挂使用。

未来钱包跟invoker将会有一层信任关系~ M [ K D u ; m：钱包方会自己开发y { Q t U g * xinvoker、或使用开源并经过审计的invoker，并且仅允许用户使用他们审核过、并且相信的invoker。我们未来对钱包商的信任基础，也会包含这些invoker，有点像是选用合约钱包时一) M _ 7 Q s p 9样，把它归为整体钱包的一部分。

签章内容

前面有提到，原本这个提案是主张一个AUTHCALL签一次名，不过在决定分成两个阶段后的一个重要精神，就是把大部分可以由invoker做到的工作都交给invoker，因此用户所须签的信息只包含了以下几点：

1. type byte（0x04）b U N：X _ n 9 M [ k K *为了确保不同种类的签名结果不被别人乱用，以太/ M { C坊上的签章系统都! @ ) G _ s会有一个特有的前缀。例如一般交易、signed meR b F h $ – nssage，EIP1559都有不同的前缀。
2. chain id：目前的链id
3. nonce:EOA目前交易的计数（同一般交易所需要附带的nonce）
4. invoker：将会使用AUTHCALL的合约地址
5. commit:32 bytes，通常拿H 4 ? u ]来放invoker客制化逻辑中，需要确认使用者有签名确认的信息hash结果。I U _ ? = = s s例如有个invoker的验证逻辑是确保用户有对AUTHCALL的calldata签章，这个invoker就需要在合约的验证流程中，自己把呼叫者丢进来的calldata都hash起来，看这样能不能验过签章。

这个签章内容其实还没有盖棺定论：其中比较有争议的是chainId以及nonce。其实一开始作者们是期望把所有东西都拿掉，y D O $ n G只剩下type，invoker，以及commit，这样就把所有的实作空间都留给不同的invoker合约。但这样的提案被core devs回馈有风险太多：

（1）.关于chJ M AainID l G m P S r pd

没有chainId可能允– 0 b – & # z 4 `许跨链的重送攻击：如果有两条EVI b P 6 f 3 4 m VM chain同时支持EIP3074，那么可Z Z Y能有用户在第一条链上授权一个invoker，该签名却被拿到另一条链上，被使用在一个同地址，却不同实做的合约中，那么用户在3 C u f E m M F第二条链上的资产就会有危险` f k z l A c A。

补充：理论上用CREATE2 deployer来部署C t h 2 1 R , a #invoker可以解决这个问题，因为这个问题的主要风险) e m x ` D o是来自在不同链上，同个地址可以存在不同合约。例如我用一D | 3 e D A个简单的私钥部署一个看似正当b = } , R V且去中心化的invoker到主网上，地址为0xaaabbb，我等大家签了E2 ` zIP3074授权之k Z ` q i X } =后，再到Arbitrum上面在一样的| l 40xaaabbb地址部署一个可以对外做任何呼叫且没有验证E v y + S 7 f 6的invoker7 5 M o r i ;，那我这个坏人就可以偷走你在Arbitrum链上的EOA控制权。

要如何用CREATE2 deployer解决这个@ y % F 0 r问题呢？因为CREATE2这个Op code会强制一定要部署一样的合约代码及一样的salt（随机数），才有f R b 7 C G d 0 d办法部署出一样的地址。因此透过通用的CREATE2 Deployer部署出来的合约，你可以相信这个地址要嘛在其他链上不存在` O 7 D t合约，如果存在，则合约内容一定跟主网一样。B Z v k 0 I _ N

这里列几个常见的CREATE2 Deployer，连接0 F 8 }到他们的repo或是etK r .herscan:

• Seaport keyless CREATE2
• Deterministic-deployment-proxy
• Safe-singleton-factory

（2）.关于nonce

没有nonce则是可能允许invoker拿到无法撤消的授权：假如今天{ 6 @ , O一个in: & . u A 5 –voker忘了实作签章不能被重复} _ T d C使用的逻辑（replay protectt $ } M U H D kion），有+ n . e 4 T H Y P可A e R L能造成坏人能无限制s x 8的使用一个用户同个签名发起多次AUTHCALL。如果保留这个nonce的验证，用户在任何时候只要发起一笔普通交易，就可以让] Q y r所有现在在外面的签章无A f e B q m y 3 o效化，过程大概是：

假设一个EOA现在nonce是10 =>他的主人可以做一笔简单的以太坊交易，例如转账给自己=>以太坊纪录的EOA nonce会增加1变成11 =>之后验* | ~ e G , 8证AUTHCALL都会使用nonce = 11来验章，造成之前签的签章无效化。

这里牵扯到的问题是，到底这个EIP要给invoker多大的自由与弹性：没有了chainId的限制，invoke) = y h Z s k ar可以透过多链部署，让用户享有「一个签章、全部EVM chain都升级」的功能；而没有nonce的限制的话，能够让钱包设计invoker跟EOA能同步做交易，做到更多自动化。

目k 3 R ` F 4 ^前这些细节都2 { ~ ? d y 2 W U还在讨论中，以提案的现有状况来说，作者（SamWilsn）其实也是偏好开放最大自由度的，但core dev的立场比较偏好不要一次加入太多的attacl t c i V N w w |k vector，因此nonce跟chainId目前还是暂时被加回了需要签章的信息中。

这个讨论还在持续中，大家可以加入forum来发表意见

重送攻击的预防实作

尽管上面有说，EOA交易的nonce必须涵盖} V E 6 Z A在签章中，但这只是为了确保「使用者100%可以让EIP3074签章无效化」，并不限制7 ~ f H一个签章能被用几次。

这是因为当AUTH被使用的时候，他会R K z 7 5 b检查这个\ P b M R C {nonce是否等于使用者目前EOA交易的nonce，只要相同就会给过，但并不会更改Z n 7 7 d gEOA的nonce，因\ ? ` k M 6 A此一个签名是可{ ^ K 4 $以被Ap ! = ] % K q NUTH验b ~ % W证数次的。

Invoker有义务要自行实作一些重送攻击的预防逻辑，但是可以有很多变化，另如自己做一个像是Uniswap Per+ g n X * `mit2的nonce系统，不要用递增的方式来确保可以平行送出多笔交易、也可以批次取消等等。

风险与常见误解

以下列出对于这个EIP常见O ; k Q ? | Y的误解：

1. EIP3074让钓鱼诈骗变得更简单了？

有了这个EIP之后，智能合约确实有了透过一个签章得到EOA控制权的能力。但如前面所说的，invoker应该要跟钱包是一个绑定的关系，钱包应该要拒绝所有不认识的EIP3074签章请求。

由于每种不同的签章有不同的前缀，目前所有市面上的钱包都会默认拒绝EIP3074的代理签章，因j j \此不用担心你的钱包不支持让你被骗。（也没有任何钱包支持用private key盲签未知交易格式。）

除了钱包方8 1 o S ` h ^ 3 (需要主动的去开启这个功能，大家也并不预期钱包方会接受一个网站「要求签署EIP3074」签章，因为像上面说的，q _ j w _这并不是一个正N f # F e k 1常的DAPP会要求钱包做的事情，因此我们可以– 5 T w D 2预期钱包只会允许启用他4 w C 3 &们自己认证过的Invokers。

这跟钓鱼网站不同] U 5 \ v h N的点是：钱包本来就会期待来自网站（Dapp端）的交易请求R v = \ r = %，因此钓鱼网站透过骗你点击按钮，传送「恶意交易请求」给钱包端J a U y g M，如果钱包端没有好的预防，你可能就会点下签署交易。而EIP 3074的签章是h V x –完全不同的形式，钱包也没有理由要允许来自网站的「代管私钥需求」，因此不用担心你的钱包会侦测不到。

这里补上作者之一lightclient对此问题的响应。

虽然理论上钱包不该开启客制invoker的功能，但还是有可能有些钱包为了给用户最大自由度，而提供这个进阶选项。如果真的有这样的钱包，那就可能会出现类似钓鱼网站的攻击了：例如他们做一个很酷的网站告诉你加入invoker后能有什么功能，骗用户忽略钱包的一些警告而签章。

2.无法夺* 0 D L 4 ` f回的钱包控制权

有人在介绍EIP3074– ~ f t Y / x f时写到，这可能造成用户一个无法驳回的单次授权，造成所有的控制权丧失。这也是不对的，在V U ? b目前的EIP中，因为签名内容保有nonce，任何用户都可以发交易来让签出5 B v Z g Z去的签] E = s 6 x章9 ; 5 k c ( X , i无效化。

若是nonce没有被加入必要签章格式中，这样的+ @ [ T ? n Q G ;情境仍然建立在「合约有漏洞」的情况下。在一般合约实作中，让nonce无效化是很简单的一个步骤功能，也有无数经过验证的实作方法，除非遇到恶意的invoker（恶意钱包），否则这方面要出错的机率很低。

我认为讨论这个风险（或是类似的多链重送攻击）就好像讨论「合约钱包可能让你永久失去控制权」一样，就是~ B G – @ y在讨论合约存在bug的风险，考虑到这个问题的复杂度，要防范不会太困难。

潜在的风险s 1 – k v

上面说的两个点：恶意invoker钓鱼网站，还有bug造成的永久丧失控制权，我都觉得不是可行的攻击。但这个EIP确实还是有带来风J f v d险，我认为比较大的风险会在攻击硬件钱包这块。

软件钱包一直都有很大的风险：假如下载了一个假的软件钱包，把私钥存进去，那么你的钱就会直接不见了，因此大家对于软件钱包App已经有比较n A d高的资安意识。但硬件钱包在以前是比较安全的，只要你的硬w $ \ & .件不要掉，基本上不可能有人可以从中读走你的私钥。

但如果有开源的硬件钱包支持了EIP3074签章，不能排除有人做一些新的App，同样去接硬件钱包，并推广给用户（例如做一个手机App可以跟Ledger一起使用）。这些恶意的钱包App就可以接着骗你签一个签名来获得私钥控制权。当然，这个前提也是要先让你相信这个新的钱包App是真的E D f ; e C G，不过假如他们打着「跟老牌硬件钱包合作」的口号，可能很多用户会忽略这个风险。或是未来有更多诈骗会尝试攻击钱包App DNS、骗你下载假的Ledger App等等，都能用来偷取既有硬件钱包用户私钥控制权。

总体来说，大家只要继续谨记谨慎k p ~ (选钱包（无论软硬体），就不会有上述问题。遇到钱包推出新的invoker功能时，记得以「审视合l * 6 G @ m约钱包」的安全指标来^ ~ * v审视invoker，也能有效的避免一些bug造成的问题。

革新应用

这里提几个我觉得很有趣，非常值得期待的[ | . # &应用：

（1）老地址空投领取器：

现在如果\ l V Q有旧地址收到空投，都需要转一些eth回去当gas，领了空投后再转` 3 e ( I l | c U出来，如果有了EIP3074，就可以用领到的空投代付手续费，直接一个签名领取空投、付费并且转到新地址中。或是以前老旧钱包6 W h e g B里的一些残留3 \ k W , c ) J *ERC20也可以拿来付交易手续费。

（2）签署对ENS的交易：

以前EOA交易格式都是签署转账到一个地址，未来可以让用户签署「要转c | : 6 b g给哪个ENS」，透过invoker解析出地址再进行转账，大大增加转账的UX。

（3）签署有到期日的交易：

以前的交易内容没有到期日这样的参数，如果你签出去之后一直没被confirm，后面悔改了要手动w ? H Y R j Q i A取消，否{ R 4 Z T则他就会一直处在pending状态。有了invoker之后X u r 8 X N i S A我们可以很轻松的加入「超过时间便无效」这种限制，简单的制造出有到期日的交易格式。

（4）更多元的钱包代理：

我们= u q可以有更多「代理钱包」的玩法，甚至增加钱包的安全性：使用冷钱包授权不同的地址，指定各个地址只能做特定交易、有不同的到期时间，例如：每一个月用冷钱包授权一次我的metamask地址可以为我发起最多10笔Uniswap交易。这P 0 T H R样对于「私钥」的安全等级我们可以有更多的弹性，也将不再受到「不同私钥不能管同笔资产」的限制。

EIP3074未来可期！F 5 z 1 [

可能带来的改变

我自己觉得比较宏观来r : {说E v 3 & Q * r =，可能对整个市场带来的改变有几个：

1.钱包差异化更t x % f i j大，用户黏着度更高

以前做钱包的时候，最常想的就是如何留住用户：毕竟大} } J , ?家私钥自己存好、随时想换别的钱包，只要下载安装导入私钥，马上就搬家了。因为大家能做到的事情大同小异，就是发送交易。% 9 m . B 2 b ~

未来有了EIP3[ v O 3 : \ N I c074之后，各家EVM钱包UX可能会差的越来越多：有的可能单纯支持ERC20付手续费、进阶一点的就会有前述的代理、订阅制的手) R 2 {续费、批p M W R – –次帮所有用户一起交易等等。这些都会造成好的钱包跟一l s O E般钱包之间的差距放大，也会增加用户黏稠度。

2.钱包方可能拥有更大权力（交易排序权）

未来钱包可能在为用户安排orderflow这块会出现更大的竞争。o ` u p /我们可以越期越来越的用户会习惯把真正「送出交易」的步骤代理给钱包方，钱包方也可以透过invoker做出「只有我能代理上链」的交易，相较于传统交易在曝光到mempoo! k rl后大家（MEV searcher）都可i g \ ; { \ x以任意排序，钱包方可能也有动机去限制这些交易的顺序，从中获利。

3.一般合约可以回归更基础的设计流程

以前为了提升UX，合约设计中会考虑permit、multicall，meta-transaction，wrap ETH等等。我一直很希望AA时代快点到来，就是因为觉得这些东西如果不需要在( r 4 = & Mprotocol层考虑，可以减少很多安全疑虑，例如完全让钱包端处理Wrap ETH可以确保一个protoK ! J N H b |col完^ p r 8全不需要考虑eth的转账以及重入风险。这个EIPu f Z c K j \ q N我觉得可以期望看x z \ _ { C @ =到现有的钱包商如Metamsk，& v 2Rabby都马上投入invoker的开发，大大增加了普及批次交易的机会，如果未来批次交易普及，就# \ I n ( F p } 2能省去很多这方面的合约优化。（不用每个人的合约都继承MultiCall也是帮整个网络省空间吧！）

4.对合约使用msgC : o p f T.sender与tx.origin的影响

最后一个讲的比较细节，跟合约开发者4 h n } A t P相关的议题。

合约常常会使用msg.sender == tx2 m I e |.origin来做不同的限制。在EIP3074之后，使用者可以使用特别的EIP3074交易绕过这个检查：最初发出交易的人（tx.or& B J * % Oigin）可以透过一个中继合约来做AUTHCALL，同时附上K / ~ & )自己的S 9 n \ K P签名，因此可以做到从中继@ Q w r合约打出去的AUTHCALL，然后仍然符合msg.seE x X d ( O d Inder == tc 2 ! I Q D Ix.origin的条件。

大部分合约使用msg.sender ==s L _ 8 u tx.origin的检查是为了保证msg.sender为EOA_ z 1 Q J l q，免得送ETH回去的时候X * { x / @触发重入攻击等。这个特性依然没有改变，因为tx.origin必定是一个EOA，msg.sender也会指向最一开始的发起3 ] M Q者，不用担心不小心跟中R ( m x 3继合约互动，造成意想不到的后果。

不过这个EIP还是会影响到一些usecase，例如用tx.q ! R 6 O K : a corigin == msg.sender来防止「合约依照一笔交易的状态来控制! ] k / H , t f后续交易的行为」。T E . b e v ;例如有人用合约mint NFT，只要没有成功mint出e I H H 7 P 3希有的NFT，就把整笔交易revert掉。但这个usecase其实已经可以透5 C Y k r ( C过& { \ – ) o # bMEV等等手法透过跟builder合作来破$ S _ 5解了，所以算已经是无效的防护，影响并不大。

另一个会被影响的usecase，是用同样的条件来防止flashloan。以前如果有合约不想被用户透过flashloan使用，可以透过tx.origin == msg.sender确定来的人没有透过flashloan借钱。现在发起者可以在flashloan借到钱后，透过中继合约呼叫AUTHCALL，对协议方来说，看起来就会是msg.sender真的带着大笔的钞票来使用这个合P I X x w { ? K b约。

理论上，好的合约/ n \ } # D B不应该使用tx.origin做任何判断，因为这会破坏AA钱包或met] U } h } U \a-G s _ w B , z T Itransaction等体验，使用tx.origin也已经被大量推广为bad practice。因此尽管这个EIP打破了某些使用情境，对整体影响并不大。

结语

我自己十分期待下次升级的到来，毕竟AA说了这么久了，真的看到做出抽象帐户的钱包屈指可数，也一直没有等来说好的大量从EOA到, t M 8 y ) k ] h合约钱包的升级。

我认为EIP3074给予了所v R Y 4有钱包开发商非常大的升级空间，因为大家可以几乎无痛（不需迁移）的为用户带来体感上的大升级。真的很期待真的上线时，各_ W 4 9个钱包v r m V \ & L ? c商能变出什么新玩法，这里也小小许愿，最后EIP可以以不限制nonce跟chainId的自由之姿进入硬分叉，这样就有更多跨链钱包等等功能可以期待了。