抽象帐户(Account Abstraction ):EIP-3074 与EIP-4337 简介

Connor 火币app下载 2022-10-23 159 0

抽象帐户(Account Abstraction ):EIP-3074 与EIP-4337 简介

免责声明:本文旨在传递更多市场信息,不构成任何投资建议合约交易技巧。文章仅代表作者观点,不代表MarsBit官方立场。

免责声明:本文旨在传递更多市场信息,不构成任何投资建议合约交易技巧。文章仅代表作者观点,不代表MarsBit官方立场。

小编:记得关注哦

来源:Mirror

原文标题:抽象帐户(Account Abstraction ):EIP-3074 与EIP-4337 简介

以太坊的社群其实讨论了好一阵子究竟要如何设计新一代的帐户合约交易技巧,不同的思路也对应了不同的提案,本文主要介绍AA 在以下这两种方向的相关内容:

Table of Contents

EIP-3074

EIP-4337

Closing

本文主要继承自前篇: Account Abstraction 抽象帐户:EIP-2938 简介,因此会希望读者已经阅读完前篇,以及具备相关的背景知识合约交易技巧

▎EIP-3074

EIP-3074: AUTH and AUTHCALL opcodes打算在EVM 中加入两个新的OpCodes,分别是 AUTH 和AUTHCALL,让EOA 能透过这两个opcode 授权合约代替EOA 的身份去呼叫其他合约合约交易技巧

此提案仍在review 阶段,请大家谨慎服用合约交易技巧

EIP-3074 的主要目的并非设计一个崭新的protocol 来扩展EOA 的functionality,因为随着protocol 与相关的介面标准越来越复杂,能被攻击的地方也会越来越多合约交易技巧

它倾向让User(EOA)可以以合约(Invoker Contract)代理自己执行各种动作,同时让开发者能以一个更具弹性的框架来设计交易物件和验证机制(签章演算法),使任何的EOA 可以像一个合约帐户(Contract Account)一样运作,却不用自己布署任何合约合约交易技巧

展开全文

Overview

Image Source: Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337

概括来说一个EOA 能将一则已签的讯息(交易)送至 自己信任的合约(称作Invoker)上,合约可以利用 AUTH 和 AUTHCALL 代替这个EOA 送出这笔交易合约交易技巧

由于EOA / User 提交给Invoker 的形式是合约自订的,搭配新的OpCodes 之后能让各种需求变得很好实现,例如批次交易、包装交易、手续费缴交方式、多签、签章验证方式等合约交易技巧。EOA 也能透过他喜欢的方式(ERC-20、法币等)给予Invoker 手续费。

特别注意:

EIP-3074 可以视为是EOA 的扩充而非必要合约交易技巧

Invoker 是 不可升级的,因为可升级合约的新逻辑可能会让Invoker 无法适当地验证commit,导致造成非常严重的问题,例如让不该通过的交易签章通过,或该通过的无法通过合约交易技巧

此外,commit可以利用平行的call 和在其之中的nonce,达到multi-call 的「包装交易」效果合约交易技巧。例如我们在面对ERC-20 的交易时,就可以把approve-transfer包在一个动作里面。

关于这个部分每一个call frame 里面的角色及运作,可以见下文合约交易技巧

EIP-3074 相关的缺点与改进建议的部分可以看: A case for a simpler alternative to EIP 3074 、 EIP-3074 Threat Models 和Reference 处的内容合约交易技巧

authorized是一个型态为 address 的变数(合约除了 tx.origin 和 msg.sender 之外现在还能读取authorized),表示当今合约是被哪个帐户授权的合约交易技巧。被授权的合约能够使用 AUTHCALL 代表此帐户(authorized的address)执行各种行为。

authorized和其他以太坊中的变数不同,它没有预设值,每次合约开始一个执行前就会将其初始化为unset,代表当前没有EOA 授权此合约执行合约交易技巧

authorized是 AUTH 及 AUTHCALL 这两个新OpCodes 会去查看的变数,存在当前合约执行时的EVM 中,用于确认是否已经正确设置授权帐户(看 authorized 是否不是unset),如果已经被设置且所有签章合法则 authorized 的值会被 AUTH 及 AUTHCALL 取用(下一节会说明)合约交易技巧

合约每一次只能有一个authorized,也就是说合约不能同时代替两个EOA 执行动作合约交易技巧

每次执行(Call)时(separate execution frames),每次的 authorized 是独立的,不能监听到别人的authorized合约交易技巧。即便是利用DELEGATECALL,或同样 address 授权加上同样一笔交易,当前 authorized 都不能离开作用域影响别人。

不能跨出execution frame(call frame)的原因是同一笔交易里面可能有多个call frame,而每一个call frame 都有一个经过 AUTH 授权的authorized,这个授权只停留在自己的call frames 里面,也就是 authorized 不能影响他人及被影响的原因合约交易技巧

AUTH(0xf6):会基于ECDSA 签章演算法去设定 authorized 的值

AUTH会从Stack 中取出三个元素:authority、offset、length,首项代表signer address,后两者代表memory 的range,会接收EOA 的(v, r, s) 以及commit合约交易技巧

由于是接收dynamic memory range,因此 AUTH 未来是有机会升级来支援与Contract Account 互动或使用其他验证方法的合约交易技巧

此处EOA 送来的签章仍然是使用 secp256k1 这个演算法,签章结果为:(v, r, s)合约交易技巧

如果 签章合法且签章recover 后 authority == signer或authority == tx.origin(允许简单的Batch 交易,例如ERC-20 中的approve-transfer),则将 authorized 设为authority合约交易技巧

如果 authorized 被成功设定成 authority 也就是signer,那 AUTH 会回传1,否则回传0合约交易技巧

commit是EOA 提交的交易资讯,Invoker Contract 会验证这里面的内容,包含nonce(replay protection)、to、gas、calldata合约交易技巧

AUTHCALL(0xf7):会代理 authorized 这个帐户发送call

AUTHCALL会从Stack 中取出八个元素,包含:gas、addr、value等,用于发送call(建置一笔交易物件)合约交易技巧

与 CALL(0xF1) 的行为很像,差别主要在于一些参数的逻辑判断,例如:authorized如果是unset 的状态,则这次执行动作就不合法合约交易技巧

在EIP-3074 中还有 dynamic_gas 的设计,这个部份因为比较琐碎我就先略过,如果有兴趣或是想知道其他参数的Spec. 可以详阅此处合约交易技巧

▎EIP-4337

EIP-4337: Account Abstraction via Entry Point Contract specification则希望可以把原本交易在底层运作的逻辑拉到合约中:

在这里我们有许多名词是第一次碰到合约交易技巧,下文我会慢慢解释!

此提案仍在draft 阶段,请大家谨慎服用合约交易技巧

Source: ERC 4337: account abstraction without Ethereum protocol changes

首先,这个提案最大的特点就如同上图来源, Vitalik 文章的标题叙述一样,不用去更改Ethereum 底层的Protocol 就能完成AA 的实作合约交易技巧

严谨来说是不用去修改或增加共识层的Protocol合约交易技巧

EIP-4337 可以达到以下目标合约交易技巧,某些点可能与我们之前介绍过的EIP-2938 和EIP-3074 稍微不同:

我们可以把EIP-4337 的AA 实作当成是一个Contract 的Spec.,它的目的是要把底层的交易与帐户运作拉到合约层面执行合约交易技巧。这边我会边解释名词,边顺过整个交易在AA 被执行的过程。

1. UserOperation & 2. UserOperation mempool

在合约里面,用户送上来的交易物件是一个在合约中名为 UserOperation 的struct合约交易技巧。这个 struct 的members 和我们认识的交易很像,包含sender、nonce、callData、callGas、signature等,细节可见原提案。

为了避免Replay Attack(跨链或跨不同的EntryPoint),Signature 的制作必须要包含 chainid 和 EntryPoint address 等元素合约交易技巧

Bundler 有可能是矿工,或是能作为User 和Miner 之间的中介人合约交易技巧。会去聆听UserOperation mempool 中新加入的UserOperation,并且将从这些交易中挑选一部分捆绑成Bundle Transactions。

这边我们可以假设UserOperation 一定会被打包处理,因为可能会有类似Flash Bot 的Bundler 去快速过滤出有利润(手续费)可图的交易合约交易技巧

首先Bundler 会在Local 使用RPC Call 呼叫Entry Point Smart Contract 中的simulateValidation,以此先确保这些UserOperation 的签章没问题和Gas Fee 被正常支付合约交易技巧。关于模拟交易结果的部分可见此处。

最后Bundle Transactions 会呼叫Entry Point Smart Contract 中的函式handleOps合约交易技巧

5. handleOps & 6. Entry Point Smart Contract

Entry Point Smart Contract(EntryPoint)是一个早就被布署的合约,将在未来被相关的AA Transaction 呼叫使用,例如某一个Dapp 有它想要的AA 交易模式,它就需要布署一个它的EntryPoint合约交易技巧

EntryPoint会处理UserOperations 的内容和替Bundle Trandactions 布署一个Wallets Contract(使用标准EIP-2470: Singleton Factory以及CREATE2,initCode来自于UserOperation.initCode,salt来自于UserOperation.nonce)合约交易技巧

Wallet Contract 会用来处理nonce 与signature 的验证并且执行交易合约交易技巧

Entry Point Smart Contract

在进到 EntryPoint 与 handleOps 的解释之前,我们先回忆一下之前在EIP-2938 提到的,节点需要负责验证一笔AA 交易是否合法的两个阶段:PAYGAS以前的验证阶段(verification phase),与 PAYGAS 以后的执行阶段(execution phase)合约交易技巧

前者限制交易只能阅读合约的storage(eg public keys, anti-replay nonces, Merkle roots) 以及不能更改任何状态,如果交易在这个阶段失败,矿工会拒绝这笔交易合约交易技巧

后者因为已经支付了fee,如果交易在这个阶段失败,矿工仍然可以选择要不要加入这笔交易合约交易技巧

Source: Implementing account abstraction as part of eth1.x

在 handleOps 中有很类似的举动,面对每一个UserOperation,handleOps会用两个For Loop 来实作上述两个phases,一个是verification loop,另一个是execution loop合约交易技巧

Verification Loop

补充说明:

用户在送上 UserOperation 这个物件时,必须先用EIP-1014自行计算UserOperation.sender,也就是 CREATE2 创建的Wallet Contract 的地址合约交易技巧

validateUserOp和我们之前提到Bundler 会预先呼叫 EntryPoint 的 simulateValidation 要做相同的检查合约交易技巧

需要特别注意Verification Loop 中,如果再用call 呼叫其他合约时(depth > 2)有禁止执行的OpCodes,这个部份对应到之前EIP-2938 的「限制交易在 PAYGAS 之前只能阅读合约自己的storage 以及不能更改任何状态」合约交易技巧

handleOps中的第二个步骤(回圈)会以 UserOperation 作为calldata,去呼叫Verification Loop 布署的Wallet Contract合约交易技巧。并且执行交易本身该执行的内容。(可想而知Wallet Contract 要有办法去parse 这个calldata。)

执行完以后,会将剩余的gas fee 给予Wallet Contract合约交易技巧

Paymasters

在EIP-4337 还有特别重要的一个Features 叫做 Paymasters合约交易技巧

大家还记得在之前的文章中有介绍过的其他支付手续费的方式,以及Tornado Cash 的AA Example 吗合约交易技巧。Paymasters 可以做到第三方代替别人支付一笔交易的手续费的行为,此时就可以去接收其他种的Fee(eg 信用卡、ERC-20 等)。

要如何判断这笔交易的手续费是Wallet Contract 还是Paymasters 支付,得看 validateUserOp 中的参数 requiredPrefund 是否为0合约交易技巧。如果我们已经确定要用Paymaster 支付的话,可以对应着看上方示意图。

EntryPoint中要特别去实做一些属于Paymaster 的函式合约交易技巧,例如:

在以上的示意图中合约交易技巧,对应的步骤如下:

Image Source: Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337

上面这张图也蛮漂亮的合约交易技巧,大家可以参考一下:

补充说明:

第一到第四步为Verification Loop,第五与第六步为Execution Loop合约交易技巧

为了防止Paymasters 可能DoS 系统的风险,我们需要一个Paymaster 的声望机制(reputation system) ,详细可见:reputation, throttling and banning section合约交易技巧

可以有多个Paymasters 来分担一笔交易的手续费合约交易技巧

整个系统的安全假设有一个前提是Node(miner / bundler)必须在包装这笔UserOperation 时就先利用上文提到的模拟行为确保交易会成功、手续费会被支付(细节可见 此处)合约交易技巧。如果这件事情没有做到,那我们可以假设有恶意人士会提交很多个operations,并且被包装抵达 EntryPoint 但在最后一刻(执行了很久之后),才被revert。但如果有在每次提交到EntryPoint 前确实模拟,那系统就可以预设是DoS Safe 的。

虽然无论是使用Wallet Contract 还是Paymaster 支付手续费,都可以利用模拟行为避免交易在最后一步才被revert,但Paymaster 是被第三方制造出来的,因此我们可以想像有一种恶意情况是模拟行为中 paymaster.validatePaymasterUserOp 会成功,但之后的 postOp 等真正要执行时会失败合约交易技巧

Closing

和前一篇介绍AA 的文章相同,由于是简介所以非常多设计细节还有实作的设计想法我都没有提到,如果想要了解的话可以细细品尝该EIP 本身还有下方Reference 提到的资料合约交易技巧

由于以上介绍的两个提案都还不是定案合约交易技巧,在研究时也会找到许多旧版提案的内容,因此如果大家发现认知与资料不一的情况,可以先去确认EIP 内文,那里肯定是最准确的!

本文要感谢

NIC Lin老师的Review(这篇超级长的?)合约交易技巧!Reference: EIP-3074

Ethereum Magicians: EIP-3074: AUTH and AUTHCALL opcodes

We should be moving beyond EOAs, not enshrining them even further (EIP 3074-related)

EIP-3074 (Batch) Transaction Invoker

EIP-3074 Invoker Examples

EIP-3074 Security Audit Report Ethereum Foundation

PEEPanEIP #27: EIP-3074: Native Sponsored Transactions with Sam Wilson

Ethereum Magicians: ERC 4337: Account Abstraction via Entry Point Contract specification

Proposed initial abstraction changes for Metropolis

stackupfinance/stackup

eth-infinitism/account-abstraction

PEEPanEIP#65: EIP-4337: Account Abstraction via Entry Point Contract specs. with Yoav W., Kristof G.

EIP-4337 — Ethereum Account Abstraction Audit

chihaolu.me

chihaolu.eth

责编:Lynn

评论