PERA:以太坊钱包的变革:账户抽象与ECR-4337的机遇与挑战_Pera Finance

SevenXVentures

投资参考。

钱包的外部账户方案的劣势逐步显露,其功能简单而且性能一般,不支持并发交易,且存在密钥管理的难题。智能合约钱包使用合约账户作为钱包地址,是一种相对来说新型的以太坊钱包解决方案,它能解决EOA钱包的短板并且带来更强大的功能。未来,你将可以选择不去小心翼翼保护好自己的私钥,也能够享受几乎同等级别的安全性;你还可以在去中心化的交易所里享受到目前中心化交易所才有的便捷,但同时资金又是始终掌握在自己的手中,不用担心交易所暴雷的可能……

以太坊的账户类型

以太坊有两种类型的账户:外部账户和合约账户。外部账户是以太坊原生记录用户余额的钱包账户地址,合约账户一开始的设计目的并不是用来记录用户钱包地址余额的。

EOA是以太坊以及其他EVM兼容链才有的概念,严格来说包括BTC在内的主流非EVM链都没有这个设定。Metamask钱包使用的就是外部账户,这一类的钱包也被称为“EOA钱包”,由用户私钥控制,其生成规则是:

私钥→公钥→Keccak256哈希→最后20Bytes→十六进制字符串

这个生成规则完全由数学变换而来,该地址未对应任何一段智能合约。使用该类型地址进行交易的时候,其节点验证规则是:

交易签名→ec_recover→公钥→地址→对比要操作的地址

如果验证通过,则继续后面的流程,不通过则拒绝交易。EOA在以太坊中的核心设定是作为交易的发起方并支付gas,即交易的触发器,一笔交易无论后面有多少合约调用,一开始都必须由一个EOA发起并且支付足够的gas才可以进行。一个EOA地址的交易流程如下图所示。

目前EOA账户是用户使用钱包类型的绝对主流的钱包形态。以太坊社区对EOA表达了一些担忧,包括:

?密钥管理:获取资金的唯一方法是知道私钥,最大的问题是在于单点故障,对于用户来说,私钥即资产。对于用户来说,一旦私钥丢失或者被盗,那么就意味着资产损失。

?依赖ECDSA签名:更简单且抗量子的数字签名是对当前ECDSA的明显改进。

?事务与操作是一对一的:一次不能执行多个操作会产生不必要的成本和糟糕的用户体验。

随着区块链应用场景的不断扩大,用户在区块链上管理的不仅仅是自己的链上资产,可以还会有链上身份、社交关系甚至链上信用等等。而目前这些内容大多数都简单地通过钱包映射到假匿名的个人,不仅是用户挣扎在以助记词为主的EOA钱包私钥管理方案中,而且应用也因EOA钱包的简单性在很多应用场景上受到限制。

有很多钱包方案尝试解决这些问题:

?围绕着单点故障,MPC钱包通过使用阈值签名方案(TSS)提供了一个更好的私钥管理方案,而智能合约钱包则可以通过社交恢复、多重签名等方案解决这个问题。

?诸如批量交易、自定义验证逻辑等而更好的用户体验、更强大的功能和可扩展性,则主要由智能合约钱包带来。

MPC钱包和智能合约钱包并不是完全独立的方案,智能合约钱包也可以使用MPCTSS技术实现智能合约钱包的管理,Unipass是一个很好的例子。

注:MPC钱包指的是使用多方安全计算技术的钱包,它相当于为你的资产金库雇佣了M个管家,每个管家都不能够独立打开金库,而使用阈值签名方案(TSS)相当于给你的金库设置了一把需要N把钥匙才能打开的锁,那么MPCTSS钱包方案相当于提供了一个多角色金库管理方案,M个管家中需要有N个管家同时提供他们所管理的钥匙才能够打开金库。

CA是具备内部逻辑的以太坊账户,里面既可以是业务逻辑,也可以是账户逻辑,而后者就是智能合约钱包。Argent钱包使用的就是智能合约钱包,其开创了社会恢复这种模式,合约由内部逻辑代码控制,其生成规则有CREATE和CREATE2两种方式,这里不展开。

与EOA不同的是,CA和公钥没有必然对应关系。比如gnosissafe创建的CA里可以设定任意多把公钥来解锁它的地址对应的资产;当然CA也可以不设定任何密钥,而是由其他CA的逻辑决定是否可以解锁,比如DeFi的借贷合约,只要还了钱就能取回质押的资产。

以太坊上除ETH之外的所有资产都是由CA承载,DeFi等业务逻辑就更是全都由CA来实现。然而CA无法主动进行操作和支付gas的设定也限制了它的能力,早在2016年就有提案希望能让CA自己支付gas。

目前来说,智能合约钱包没有运行标准,所以每个项目都必须使用像以太坊加气站网络这样的元交易解决方案,或者努力创建和管理自己的中继服务,以及管理费用机制和审计他们复杂的智能合同。

智能合约钱包

顾名思义,智能合约钱包就是用CA作为地址的钱包方案,特点是具备内部逻辑,智能合约钱包可以实现很多EOA无法实现的功能,比如gas代付、批量交易、多重签名、权限管理、离线授权和社交恢复等等。

合约账户是与签名者分离的智能合约,它可以有自己的签名和恢复逻辑。这意味着,如果您失去对Signer的访问权限,并不一定意味着您失去了对帐户的访问权限。同样,这就是AccountAbstraction这个名字的由来。账户是从签名者那里抽象出来的。

目前以太坊的现状是绝大多数人都在使用EOA钱包,因为目前以太坊中的所有交易都必须从EOA开始,EOA必须有一些ETH来支付gas,这使得新用户无法快速进入。我们需要一种方案,来允许用户使用包含任意验证逻辑的智能合约钱包,这种方案称为账户抽象。

简单的来说,账户抽象的结果是:

过去你将钱存在以太坊EOA钱包地址上,受到各种EOA地址限制的同时享受拥有私钥就拥有资产的简单便捷;

现在你将钱存在以太坊智能合约地址上,你可以通过不管理私钥的方式控制你的钱包资产,签名者和账户本身的分离使得你可以在一个更低安全级别进行交易的操作,而将账户本身放置于更高的安全级别。

“账户抽象”的目标是将账户类型的数量从2种减少到1种,并将签名验证、gas支付和重放攻击保护等功能从核心协议中移到EVM。一直以来,实现账户抽象都是许多以太坊开发者的努力方向,这一点从EIP的历史可以看出。

EIP历史

账户抽象的概念从2016年开始最早由Vitalik提出,2017年他本人发起了第一个提案。这么多年来,账户抽象相关的提案有非常多,其中最主要的解决方案是EIP-3074和EIP-4337。EIP-3074的提出比EIP-4337要早一年,但EIP-4337却被纳入了以太坊的新版路线图,其主要原因是EIP-4337的实现要更为轻量,无需修改以太坊的核心协议,同时也没有EIP-3074那样的安全隐患。而EIP-4337存在的用户迁移问题、Gas过高问题以及潜在智能合约安全问题是智能合约钱包的共通问题,Vitalik认为账户抽象最佳现实途径是在短期内开始大力支持ERC-4337,然后随着时间的推移添加EIP来弥补其弱点。

EIP-1014:这些转发合约将根据它们的代码被部署到一个特定的地址,引入了后来演变成EIP-1014的想法,提出了CREATE2操作码。由于EIP-86需要对协议进行重大更改,最终没有被合并,而EIP-1014于2018年合并。

EIP-2938:2020年9月,VitalikButerin、AnsgarDietrichs和MattGarnett提出了EIP-2938,该协议要求被识别为智能合约钱包的特殊智能合约将只接受账户抽象交易,这一新型交易由EIP-2718引入。他们将以编程方式设置交易的最大gas并实施任意验证方法。EIP-2938需要在EVM中添加两个新的操作码才能使交易可行。这些操作码显着改变了核心协议,包含此类更改的过程可能会拖很长时间。

EIP-3074:2020年10月,AnsgarDietrichs和MattGarnett等人提出了EIP-3074,引入了两个新的操作码:AUTH和AUTHCALL。当一起使用时,它们允许智能合约代表EOA发送交易,这使得例如多重签名、批量和赞助交易、密钥恢复以及更易于访问的CeFi交易所存款变得可能。但该EIP存在一些安全风险,受到了一些批评,新的操作码还会修改核心协议,研究人员开始思考一个更好的解决方案,最终被提议为EIP-4337。

Optimism和Starknet都有自己的账户抽象实现,ArgentX是Argent在Starknet上的钱包版本,使用受EIP-4337启发的自定义帐户抽象实现。最近的例子是VisaCryptoAutoPaymentsonStarkNet,Visa的以太坊自动支付解决方案是利用账户抽象概念并创建一种新型账户合约——可委托账户,其主要想法是扩展交易的可编程有效性规则以包括预先批准的允许列表。简单来说,账户抽象可以将用户账户发起的自动支付操作委托给预先批准的自动支付智能合约。StarkNet的账户模型就是Visa目前所说的账户抽象,其实现受ERC-4337的启发,抽象账户则会检查交易是否来自给定地址。

Visa在StarkNet上实施账户抽象

EIP-4337:2021年9月,VitalikButerin与来自OpenGSN和Nethermind的以太坊研究人员吸取了以往努力的经验教训,提出了EIP-4337。EIP-4337添加了新的UserOperation内存池希望完全取代当前的交易内存池,从而实现账户抽象。用户将UserOperation对象发送到以太坊节点,而不是交易,他们将一组这些对象打包成一个包含在以太坊链中的交易。这种打包交易称为“入口点”智能合约,它处理UserOperation对象并为其部署智能合约钱包。

EIP-5792:2022年10月,MoodySalem提出了EIP-5792,该EIP添加JSON-RPC方法,用于从用户钱包发送多个函数调用,并检查其状态。新方法在底层交易方面比现有交易发送API更抽象,以允许钱包实现之间存在差异,例如使用EIP-4337的智能合约钱包或支持通过EIP-3074捆绑交易的EOA钱包。Dapps可以使用这个更抽象的接口来支持不同类型的钱包而无需额外的工作量,并提供更好的用户体验来发送函数调用包。

EIP-4337详解

在EIP-4337中,一共有6个组件:入口点合约、出纳合约、用户操作、打包器、发送人合约和聚合器。

EntryPoint:入口点合约处理传递给它的交易操作的执行和验证。全局入口点合约接收来自各个Bundler的打包交易,并通过每个UserOperations来运行验证和执行循环。

Paymaster:这是可选合约,可以代表用户为交易支付gas。用户可以不依赖他们的钱包,而是获得由出纳员赞助的交易费用。

UserOperations:这些是为代表用户执行交易而创建的交易对象。执行发生在SenderContract确认之后。这些操作由Dapp生成。

Bundlers:Bundler从内存池中获取UserOperations,并将它们打包在一起以将它们发送到EntryPointcontract以供执行。

SenderContract:这些是智能合约形式的用户钱包账户。

Aggregator:聚合器是钱包信任的辅助合约,用于验证聚合签名。

整个ERC-4337标准的运行逻辑包括两个循环:验证循环的执行循环,它们组合在一起完成了账户抽象的逻辑。

验证循环:入口点合约通过每个UserOperation并调用SenderContract中的“检查功能”。SenderContract运行此功能以检查UserOperation的签名并补偿打包这些交易的Bunder。

执行循环:将每个UserOperation中的调用数据发送到SenderContract。钱包运行执行操作以执行操作中指定的交易。然后SenderContract将在操作执行后退还剩余的气体。

在执行循环中,入口点合约必须在主执行调用后调用paymaster上的Post-op。它必须通过在内部调用环境中进行主要执行来保证Post-op的执行,并且如果内部调用环境回撤,则尝试在外部调用环境中再次调用Post-op。

Vitalik总结认为,ERC-4337作为一个纯自愿的ERC可以做很多事情。然而,在一些关键领域,它比真正的协议内解决方案更弱:

用户迁移问题,现有用户如果不将其所有资产和活动移动到新帐户,则无法升级;

额外的gas开销;

智能合约安全问题,它较少受益于协议内抗审查技术,该技术以交易为目标而会忽略用户操作

而实现最佳效果的一条现实途径,是在短期内开始大力支持ERC-4337,然后随着时间的推移添加EIP来弥补其弱点。这并不一定需要大家专门承诺遵守ERC-4337。相反,可以将协议内支持设计为更通用,并支持ERC-4337及其替代方案和改进。目前ERC-4337的实现方案有Biconomy、SoulWallet和eth-infinitism,他们都编写了自己的入口点合约实现方案,而入口点合约是该标准下智能合约安全的核心所在。

Vitalik提出了账户抽象的可能路线图。

短期

将ERC-4337全面投入生产。理想情况下,可以使用签名聚合功能对其进行扩展,以实现rollup友好性。

应该有接入ERC-4337的易于使用的浏览器钱包。

考虑实现签名聚合和压缩,以使ERC-4337对L2更加友好;

在L2协议中引导ERC-4337生态,其中gas成本问题会较少;

中期

实施Verkle树,添加EIP以降低gas成本;

添加可选的EOA-to-ERC-4337转换;

在提议者/建设者分离推出的同时或不久之后添加crList逻辑;

长期

考虑强制转换,执行不规则的状态转换,将字节码部署到每个可能是EOA的帐户中,但这种方法的缺点是需要修改核心协议以及对于矿工/验证者来说成本很高。

SevenXVentures对市场上的智能合约钱包进行了简单扫描,收集整理了一些市场上比较主流的智能合约钱包项目,其综合情况如下:

Unipass

UniPassWallet是一个支持邮件社交恢复的智能合约钱包解决方案。通过UniPassWallet,开发者可以在产品内提供流畅的免私钥、免gas的用户体验,从而快速地吸引海量的Web2用户。其特点是:免私钥、抗审查、免gas、邮件恢复、隐私保护、多平台和支持多链。

免私钥、抗审查、邮件恢复和隐私保护的特性主要是由Unipass的秘钥管理方案带来的。UniPassWallet的合约账户中支持用户设置多种类型的密钥。已经支持的密钥类型包括:

我们经常使用的外部地址,支持EIP-1271协议的合约账户。

UniPass的用户还可以使用邮箱来作为密钥。我们在链上部署的智能合约,可以通过DKIM来以密码学的手段验证用户对于一个互联网邮箱的所有权

在验证过程中,UniPass采用了零知识证明技术,确保用户邮件信息的隐私安全。

在未来,UniPassWallet还将考虑支持相比于secp256k1更高效更简洁的签名算法,后量子安全签名算法等等。

秘钥主要有三种角色:

Owner是账户的所有者。Owner控制账户的部署、升级、销毁等核心功能,是账户的最高权限控制者。

Operator是账户资产的执行者。Operator负责账户的资产转账、合约调用、授权许可等功能,是用户日常使用的密钥。

Guardian是账户的守护者。当账户内的密钥损毁或丢失,用户失去账户控制时,可以通过guardian来恢复账户。UniPass提供的一大特色功能就是:链上邮件社交恢复。

在UniPassWallet的智能合约中,用户是通过一系列具有角色权重的密钥来管理账户的。除了以安全多方计算方案实现的Masterkey外,用户还可以设置多种其他类型的密钥。每一个密钥都有一个对应的角色及权重。用户只有在集齐了总角色权重门限超过要求的密钥后,才可以获得该角色的授权。

一个密钥允许被赋予单个或多种角色。密钥在被赋予某个角色的时候,会同时被设定对应的权重。而用户要开始执行某身份的相关操作时,需要用该角色总权重达到100及以上的单把或多把密钥进行签名。例如在初始注册账户时,用户可以跳过守护者设置。相关参数可以设置如下:

免gas的特性是通过一个第三方relayer实现的,用户发起交易时需要relayer帮助用户发起交易。在这个过程中,relayer可以支持用户使用任意代币支付gas,甚至可以完全帮助用户代付gas,实现免gas的体验。Relayer是个开源的服务端程序,UniPass会运行默认的relayer,合作方或者任意第三方也都可以运行relayer。

Candide

CANDIDE是一群贡献者,他们公开合作构建的公共产品,没有单一的实体或公司控制其发展。CandideWalletBeta是一款自托管移动智能合同钱包。它目前部署在Goerli测试网上。它现在可以在AndroidTest和IOSTestflight上使用。

CandideBeta其技术基础是Stackup分叉的ERC-4337实现和GnosisSafe的开源框架,其特性包括无助记词、社会恢复、批量交易、免Gas费等。

其中,无助记词、批量交易、免Gas费等特性其实现逻辑与ERC-4337的逻辑相同,采用eth-infinitism开发的入口点合约完成。Candide运行自己的打包器,将UserOperation打包为自己钱包的服务。该方案中,大部分的安全取决于入口点合约,而非钱包本身的构建。

此外,社会恢复的特性来源于Candide将Safe用于其基础钱包合约。这让Candide可以利用最受信任的DAO合约来管理数字代币。Candide将使用GnosisSafe模块化设计来交付其核心功能,包括社交恢复,以及未来的功能,如时间锁定和取款限制。该社交恢复模块与Unipass的逻辑相同,不同的是Unipass主要是邮件恢复,但Candide的守护人可以是任何具有公共地址的签名者,如家人朋友、机构和硬件钱包。

早期的智能合约钱包都是根据非常具体的问题进行合约开发,如GnosisSafe的多签以及Argent的社会恢复功能。早期的这些产品设计复杂,很多时候也不公开透明,且没有形成统一的标准,很难作为中间件插入到其他的应用当中。对于这一类型的产品,其判断标准更多需要从使用场景出发,有没有抓住用户的核心需求,如Safe的多签功能就抓住了用户的核心需求之一。

随着ERC-4337的诞生,快速构建一个拥有无助记词、批量交易、免Gas费的钱包变得非常方便,统一的标准也让基于该标准构建的开发套件具有可组合性,能够作为中间件插入不同的应用,并且保持互操作性。

因此,在考量早期的智能钱包方案的时候,能够ERC-4337兼容是非常重要的一点。而对于基于ERC-4337的解决方案,由于技术大多是开源的,其考量方案建议围绕以下几点:

技术:入口点合约、打包器和聚合器的构建方案,以及除了ERC-4337带来的功能以外的功能构建方案,如社会恢复功能

运营:如何构建社区、推向市场和赢得用户

体验:钱包使用用户体验是否足够好,如流畅、稳定等

以及一些其他toC产品的主要考察逻辑

未来钱包的模式更有可能是类似B2B2C的模式。钱包作为一个C端产品存在的同时,更重要的是提供一套成熟的SDK方案用于其他应用集成为应用内钱包,再面向C端用户。其中,打包器和聚合器在早期主要是中心化的构建方式,后面有可能形成模块化的网络,但由于这一块是价值捕获的核心,钱包采用他人构建的打包器网络需要经过经济收益的博弈。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

大币网

[0:0ms0-4:682ms