作者：shew
概述在Pectra升级中，出现了最为复杂的治理争端问题。当EIP3074被纳入Pectra升级后，造成了巨大的争论，特别是来自ERC4337的团队反对。
EIP3074陷入了困境，治理流程无法继续进行。直到Vitalik提出EIP7702结束了ERC4337团队对于EIP3074的质疑。
GCCResearch发现对于Pectra升级中EIP3074和ERC7702的治理问题在中文世界少有讨论。但该治理问题也反映了以太坊治理的深层问题，即在codeislaw的前提下，谁可以控制code的具体内容。EIP3074和ERC7702的治理问题可以带给我们一个很好的视角去观察以太坊内部的真实治理流程。
本文的最终结论是转述自ZeroDev发表的评论文章，该文章指出以太坊治理系统是VVRC模型，任何一个提案的纳入都需要首先符合以太坊价值观(Value)，然后该提案应该反映在Vitalik设计的愿景(Vision)中，最后提案应该反映到路线图(Roadmap)中，最后核心开发者讨论后将其纳入客户端(Client)实现中。
GCCResearch在上一篇文章中介绍的EIP2537只是在Client层级出现了实现问题导致最终延迟加入硬分叉，而EIP3074则是因为Vision和Roadmap问题导致最终没有被纳入硬分叉，而以太坊核心开发者直接选择了Vitalik编写的EIP7702作为最终的账户抽象提案。
提案内容概述在介绍具体的治理流程前，我们首先需要简单介绍一下本文涉及到EIP3074、EIP7702和ERC4337的具体内容。
EIP3074是一个执行层提案，执行该提案需要节点软件升级。EIP3074的核心目的是实现gassponsoring和批量交易的功能。所谓的gassponsoring是指用户可以使用任意代币缴纳gas费用，或者用户可以在线下缴纳gas费用。但需要注意的，相比于其他账户抽象提案允许更改签名校验算法，EIP3074并不允许用户使用secp256k1以外的任何签名算法。换言之，EIP3074并不是一个满足所有账户抽象功能的提案。这也是EIP3074备受诟病的一点。
为了实现预期目标，EIP3074引入了两个操作码，分别是AUTH和AUTHCALL。其中AUTH操作码可以通过校验签名，当签名校验通过后，该操作码就会配置当前EVM上下文中的authorized为签名人的地址。当配置上下文中的authorized后，AUTHCALL可以使用authorized的地址作为调用交易的msg.sender发起交易。从某种程度上来说，用户可以通过签名将自己的账户在一笔交易中委托给一个智能合约使用。我们一般称这个被用户委托的智能合约为invoker合约。
那用户的具体签名内容是什么？用户需要签名如下内容:
上述内容中的invokeraddress是指用户希望委托的invoker合约地址，EVM会校验用户签名内容与真正校验签名的合约是否一致，避免用户的AUTH签名内容被其他合约使用。
而nonce是一个防止交易重放的标识。但是需要注意的时，AUTH操作码会校验签名中的nonce与当前签名的EOA的nonce是否一致，理论上只要用户不使用EOA账户发起交易增加nonce数值，那么用户发出的AUTH签名可以一直被invoker合约使用。这是一个巨大的安全漏洞，意味着使用EIP3074的用户必须信任获得签名的中继服务商。假如获得用户签名的中继服务商是恶意的，该服务商可能在某一个时刻重放用户的AUTH签名盗取用户资产。
另一个具有安全问题的是commit字段。commit字段用于保证某些操作，用户可以在commit内精细化控制自己的签名权限，比如在commit内写入一些内容避免自己的签名内容被用于ETH转账。在EIP3074文档内，提案人给出了一系列的利用commit字段的例子。但是问题是commit的作用完全依靠智能合约定义，本质是一个可选内容。不同的智能合约对commit中内容的解析可能完全不一致，甚至可能某些合约完全不读取commit中的内容。假如用户希望安全使用EIP3074必须自己简单审查智能合约。
最后，我们介绍一个EIP3074对目前以太坊交易内存池的影响。引入EIP3074后可能会出现一种对于内存池的攻击方法，黑客可以使用大量的账户发起交易，然后在交易即将被打包时，使用EIP3074交易一次性抽空这些账户内的ETH，这会导致之前发起的交易全部失败。这种攻击方式会对执行层节点造成相当大的影响，本质上就是一种DoS攻击。但需要注意的，用于替代EIP3074的EIP7702也出现了这种问题，但EIP7702引入了一些限制避免此问题出现，我们会在后文讨论。
除了上文介绍的EIP3074本身存在问题，所以ERC4337的作者Yova在ImplicationsofEIP-3074inclusion一文中介绍了更多的反对意见。简单来说，这些意见主要包括:
中心化风险。由于AUTH签名的特殊属性，用户必须完全信任EIP3074的中继服务商和底层基础设施。同时目前ERC4337等账户抽象协议构建的基础设施完全不兼容EIP3074用户的安全性。正如上文所述，EIP3074没有统一设计的权限控制方法，而且签名nonce设计也存在安全隐患，很有可能导致严重安全问题的出现不完整的账户抽象功能。相比于其他账户抽象提案，EIP3074并不完整，无法实现比如更换用户签名算法等功能用户体验存在问题。当用户需要将自己的账户委托给智能合约时，用户需要进行一次AUTH签名，然后将包含AUTH签名的调用发布到链上。用户需要进行两次签名。EIP7702是由Vitalik提出的一个用于替换EIP3074的提案。该提案没有引入新的EVM操作码，而是引入了一个新的交易类型，该交易类型被称为SET_CODE_TX_TYPE。一旦用户发起EIP7702类型的交易，用户可以将自己的EOA在保留EOA基础功能的前提下增加智能合约的功能。简单来说，用户既可以继续使用MetaMask等钱包发起交易，也可以由其他用户以智能合约的形式调用EOA地址。
我们以一个简单的批量交易的例子介绍EIP7702的功能。用户可以使用EIP7702将自己的EOA地址委托给某一个可以执行批量调用的智能合约，然后用户可以直接以智能合约的方式调用自己的EOA地址发起批量交易。
从技术实现上来讲，EIP7702引入的交易类型的相比于传统的交易增加了authorization_list列表，该列表内具体内容为[[chain_id,address,nonce,y_parity,r,s],...]。其中address是用户希望委托的智能合约地址，而nonce是用户当前的nonce数值。剩下的y_parity、r和s都是用户的签名结果。在具体执行过程中，我们会首先遍历authorization_list内的每一项进行处理，处理的方法是通过y_parity等签名参数恢复出EOA地址，然后将EOA地址指向地址为address的智能合约。之后EOA地址就可以接受调用发挥合约的功能。
EIP7702的优点非常明显，其中最核心的优点是EIP7702本质上就是允许EOA拥有智能合约的功能。这与ERC4337等账户抽象的基本规则是一致的，这意味着EIP7702可以利用目前账户抽象领域内的所有探索和复用已有基础设施，比如EIP7702可以直接使用ERC4337的基础设施。目前ERC4337已经推出了支持EIP7702调用的EntryPointv0.8。从复用已有的基础设施角度来看，EIP7702与ERC4337具有同等的去中戏化程度。
当然，EIP7702实际上也没有完全修复EIP3074中出现的问题。大部分EIP3074中存在的问题依旧存在。EIP7702要求账户合约拥有安全实现，而协议自身不对任何安全进行保证。在EIP7702提出的早期，存在某些开发者提出将签名nonce标准化以避免可能的重放攻击，但是EIP7702最后也没有接受这些建议。所以假如用户希望安全使用EIP7702，那么用户就需要自己审查合约安全性。
同时EIP7702也会为执行层带来一系列问题。在上文我们介绍过一种可能的利用EIP3074对执行层内存池进行DoS攻击的一种方法。这种方法在EIP7702也是有效的。所以EIP7702建议所有使用EIP7702的EOA地址只可以在内存池内存在一笔待处理交易，避免大规模DoS攻击出现。
综上所述，EIP3074最大的问题是EIP3074没有实现完整的账户抽象功能，而EIP7702实现了完整的账户抽象的功能。而定义“完整的账户抽象”包含哪些内容的正是ERC4337的作者。读到这里，读者应该就可以理解为什么EIP3074被ERC4337团队反对，最后被EIP7702替代。我们会在后文介绍整体治理和讨论的全部流程。
EIP3074和EIP7702的治理流程EIP3074在以太坊核心开发者会议内提及的非常早。在2021年4月2日的Meeting#109内，以太坊核心开发者就对EIP3074进行了简单的讨论。讨论结果非常简单:
Alexey提出EIP3074签名内容存在安全风险，可能对用户造成严重的安全损失，建议EIP3074进一步规范化AUTH签名的具体内容，该提议得到了Martin的支持James提出EIP3074可能带来潜在的执行层漏洞，比如DoS攻击等，建议EIP3074给出书面的威胁分析Alexey和Martin抱怨EIP3074文档质量一般，花费了大量时间阅读和理解Martin认为EIP3074的核心是与应用，特别是钱包开发者的合作和实现，EIP3074的作者表示已经和应用开发者进行了一系列交流比较有趣的是，Vitalik在这次会议中认为无论如何，以太坊需要一种为EOA设计的一笔交易产生多次调用的技术方案。虽然EIP3074存在可能的安全问题，但EIP3074给出了一种可能的技术方案，开发者需要在EIP3074的基础上前进。
显然，由于EIP3074存在安全问题，这次会议并没有将EIP3074纳入London升级。
在2021年6月11日的Meeting#115内，EIP3074开发者提交了安全审计方面的报告，会议主要讨论了EIP3074的安全问题。一个简单的结论是EIP3074invoker合约在系统内是十分重要的，所以是否需要对invoker合约进行管理是一个问题。EIP3074开发者希望对invoker合约进行形式化证明，以此增加安全性。
当然，还有部分讨论关于有一些合约使用msg.sender==tx.origin进行了调用地址是否是EOA判断，当EIP3074被引入了，这些判断都会失效，但结论是这部分判断失效不会产生严重的安全问题。简而言之，该次会议主要是EIP3074提出者向核心开发者介绍3074的安全审计结果。会议最终的结论是3074还需要考虑invoker合约问题，建议不要在London硬分叉内加入。
在2021年6月25日的Meeting#116内，ERC4337的核心作者Yova提交了AcaseforasimpleralternativetoEIP3074的材料，该材料指出EIP3074存在较多安全问题，建议修改其中部分内容，比如限制签名内的commit字段内容，要求commit字段为{nonce,to,gas,calldata,value,chainid}形式。使用此签名模式后，EIP3074仅可以用于执行某些特定交易以保证交易的安全。
此处会议中EIP3074的作者对Yova提交的材料进行了回应:
希望将invoker合约地址纳入EIP规范，然后由以太坊核心开发者编写一个安全的invoker合约避免安全问题关于签名中commit的内容，EIP3074开发者认为这完全是用户和钱包软件方面的问题，并不需要在EIP内进行规范Vitalik在此次会议中提出以下三点内容:
EIP3074仍使用了传统的secp256k1签名方案无法实现抗量子特性。EIP3074没有未来兼容性，使用EIP3074也无法使得一个EOA进化为智能合约账户EIP3074生命周期有限。3074引入了AUTH和AUTHCALL两个预汇编代码，但是按照账户抽象的路线图，未来以太坊内所有的钱包都可能是智能合约钱包，EIP3074的预汇编代码在未来会被废弃在2022年2月4日的Meeting#131内，开发者讨论ShangHai升级内应该包含的EIP类型。EIP3074被纳入讨论范围，但开发者只是简单同步了EIP3074的开发动态。值得注意的，在会议开始前，nethermind编写了Ethereumwalletstodayandtomorrow—EIP-3074vs.ERC-4337一文，文章内没有包含对EIP3074的反对意见。
在2023年8月3日的Meeting#167内，核心开发者在讨论另一个EIP5806时提及了EIP3074。EIP5806是一个允许EOA在交易过程中使用delegatecall的方式调用外界合约。该方案在某种程度上类似EIP7702。但核心开发者对此方案的安全性也提出了质疑，Ansgar指出过去EIP3074因为可能存在的安全问题一直无法被纳入硬分叉，而EIP5806是一个更加激进的方案。
在2024年2月29日的Meeting#182内开发者详细讨论了EIP3074的是否应该被纳入Pectra升级。Vitalik提出任何账户抽象标准都需要具有以下三种功能:
密钥轮换密钥弃用可兼容抗量子签名Vitalik对指出EIP5806可能是一个优于EIP3074的选择。Andrew认为EIP3074相比于EIP5806更加通用，建议使用EIP3074。Vitalik对Andrew进行了反驳，Vitalik认为未来所有的钱包可能都是智能合约钱包，一旦此情况发生，EIP3074引入的预汇编操作码就会失效。Yoav作为ERC4337的作者在此次会议中进行了篇幅较长的发言，其发言内容主要包括:
EIP3074可能导致对以太坊内存池的DoS攻击，而ERC4337对这部分进行大量研究给出了一些规则避免攻击EIP3074在用户发起批量交易时需要签名两次，这是不合理的EIP3074要求使用中心化中继器Yova更加倾向于使用EIP5806作为账户抽象方案。
在2024年3月14日的Meeting#183会议内部，核心开发者邀请MetaMask的DanFinlay讨论关于钱包对EIP3074的看法。Dan对EIP3074持赞成态度，同时指出MetaMask也会为EIP3074的测试提供支持。MetaMask认为EIP3074在功能上可以使得EOA享受账户抽象的全部功能。在安全上，EIP3074为钱包服务商提供了一种方案，即冷热密钥分离。钱包服务商可以持有EOA的EIP3074签名发起交易，用户在正常交易中都可以使用热私钥，但冷私钥可以保存在用户的硬件钱包内，当发现紧急情况时，用户可以使用冷钱包内的冷私钥发起交易撤销EIP3074的签名。这种冷热私钥分离的方案为钱包提供商带来了灵活性。
Vitalik指出在EIP3074内，钱包设计者必须设计严格的授权逻辑，避免用户的EIP3074签名被滥用。有趣的是，在讨论MetaMask增加EIP3074功能支持时，Vitalik指出可以使用L2作为过渡方案，即任何新的执行层修改应该在L2内进行率先实践，因为L2资金体量有限，即使发生严重问题也会造成严重损失。
DrorTiros在讨论中指出确保EIP3074安全的最好方式是以太坊官方直接给定invoker合约。但DanFinlay反对官方给出合约的意见，Dan认为invoker合约应该完全由用户决定，市场最终会选择出最安全的invoker合约。
Ansgar仍坚持EIP3074一次签名应该只对应一笔交易，钱包服务商不应该复用用户签名发起交易，但DanFinlay也表达了反对意见。DanFinlay认为EIP3074应该由冷钱包签名，然后钱包服务商可以复用该签名直接为用户发起交易，假如每次都要求用户重新签名，可能导致冷私钥被多次使用。这与冷热私钥分离的思想不符。
在此次会议中，核心开发者讨论了另一个重要的话题是包含列表。包含列表是增加以太坊抗审查属性的一种手段。简单来说，包含列表允许一些交易被承诺直接包含在下一个区块内。但核心开发者指出EIP3074与包含列表是抵触的。
在2024年4月11日的Meeting#185会议内部大部分的客户端实现都同意EIP3074加入Pectra硬分叉中，但Geth表示反对，原因是EIP3074可能导致Verkle树方面的问题。Danno仍表示反对，因为EIP3074可能出现签名复用的情况。Yoav也表示反对，Yoav给出了一种使用EIP3074和Blob交易对内存池进行攻击的方案。简单来说，攻击者可以发起大量的Blob交易，这些Blob交易都包含大量的数据，然后使用EIP3074使这些Blob交易全部失效。
简而言之，在此次会议中，所有客户端开发者都同意EIP3074被纳入最终的升级。
在2024年5月9日的Meeting#187内，核心开发者第一次讨论EIP7702替代EIP3074的问题。而EIP7702是在Vitalik在核心开发者会议开始前前90分钟内完成的。在会议中，核心开发者认可EIP7702是一种更加优于EIP3074的标准。此次会议没有出现对EIP7702的反对声音，只是存在部分研究员认为EIP7702也存在类似EIP3074的不可撤销属性，可能导致资金安全问题。
在2024年5月23日的Meeting#188会议内核心开发讨论了EIP7702替换EIP3074的可能性。此次会议的最终结论是使用EIP7702替换掉EIP3074作为Pectra硬分叉中的账户抽象标准。Vitalik指出EIP7702也具有一些与EIP3074一致的不可撤销性，这些属性在讨论EIP3074时已经得到了大量讨论。比较有趣的是，会议中存在大量ERC4337的代表参与发言。
事实上，EIP3074被EIP7702替换的讨论在188次核心开发者会议之前就已经被广泛讨论，当时的讨论结果就是3074会被替换，所以在核心开发者会议中并没有大量的争执。
路线图与裁决账户抽象的核心基础设施Zerodev在得知EIP3074会被替换后，发表了一篇有趣的文章，该文章标题为ReflectionsonEthereumGovernanceFollowingthe3074Saga，这篇文章的结论是EIP7702是一个好的提案，该提案可以使得所有用户收益。但EIP7702替换EIP3074的治理流程不是最佳的，原因包括:
EIP3074经过了漫长的讨论流程，在上文中我们已经介绍了EIP3074在核心开发者会议中的多次讨论EIP3074被确定纳入Pectra升级后收到了ERC4337社区的大量反对。当然，在上文中，我们已经指出ERC4337的核心开发者yova曾多次在核心开发者会议中表达自己对EIP3074的反对Zerodev认为最好的治理路径应该是在EIP3074过去漫长的核心开发者讨论过程中，ERC4337社区应该广泛参与并表达自己的意见。
EIP3074开发者认为ERC4337应该对治理失败负责。因为EIP3074在过去几年内积极参与治理，并多次和ERC4337核心开发者yova进行了交流。
而ERC4337社区则认为EIP3074应该对治理失败负主要责任。ERC4337社区成员认为Yova作为ERC4337的核心开发者在多次核心开发者会议中对EIP3074表达对反对意见，但核心开发者似乎并没有听取意见。ERC4337中大部分社区成员没有关注EIP3074的治理动态，大部成员都认为EIP3074是一个死掉的标准。ERC4337社区也认为核心开发者没有积极与ERC4337社区积极沟通。
EIP3074和ERC4337都认为自己进行了正确的治理工作，而对方应该对治理失败负主要责任。显然，在此次治理过程中存在一个更加深层的原因在发挥作用。
简单来说，这个更加深层的原因其实是以太坊的路线图。以太坊路线图具有高于核心开发者会议的权力。账户抽象的路线图则是以ERC4337为核心的。EIP7702完全兼容ERC4337标准，但是EIP3074没有充分兼容ERC4337标准。所以从以太坊路线图角度来看，EIP3074被替换是一定会发生的。
当然，以太坊路线图都是Vitalik个人对以太坊未来愿景的展示。以太坊在治理过程中一旦发生严重的争论，那么作为路线图定义者Vitalik拥有最终的裁决权。而正是Vitalik的裁决使得EIP3074被替换。
以太坊的治理模式是values⇒vision⇒roadmaps⇒clients模型，或者简称为VVRC模型。其治理流程如下:
values价值观，特别是社区的价值观，以太坊社区的价值观包括去中心化、抗审查等vision愿景，实际上就是Vitalik个人对以太坊未来的思考roadmaps路线图，研究员在愿景的基础上给出一些技术细节上的考虑给出较为完整的实现路线图clients客户端实现，客户端的核心开发者利用核心开发者会议等工具讨论路线图，并将路线图内的需求实现上述流程才是以太坊真正的治理流程。我们可以看到Vitalik个人愿景位于以太坊治理模型中的底层部分，所以一旦客户端实现内出现严重的争论，Vitalik的个人意见将进行最终裁决。
参考资料
ZeroDevIntroduction
null
https://docs.zerodev.app/blog/3074-governance
ZeroDevIntroduction
null
https://docs.zerodev.app/blog/4337-and-3074-disagreements
NotesontheAccountAbstractionroadmap-HackMD
#NotesontheAccountAbstractionroadmap*SpecialthankstoVitalikandtheAAteamforfeedback
https://notes.ethereum.org/@yoav/AA-roadmap-May-2024
