作者 | Rajeev Gopalakrishna 

深度丨Vitalik 提出的EIP-2938将给以太坊带来哪些改变?

以太坊有两种类型的账户。外部自有账户(EOA)和合约账户(CA)。EOAs由私钥操控,而CA由其间包含的智能合约代码操控。EOAs一直比CA更有特权,由于只需EOAs能够经过付出gas开端买卖履行。账户笼统(AA)是一个提案,它答应合约像EOA一样成为一个 "顶层 "账户,其能够付出费用并开端买卖履行。

账户笼统的动机是显著改进用户在钱包、DApps和DeFi等各种场景下与以太坊进行交互时的用户体会。账户笼统在以太坊中供给了一个根底层的功用,来决议什么时候能够付出gas,以及对谁付出gas等问题。

Status Messenger使用集成了一个以隐私为中心的信息体系,以及一个以太坊钱包和一个Web3 DApp浏览器。Status wallet现在是一个EOA钱包,它约束了咱们供给只需智能合约钱包才干供给的丰富的用户体会,如多重签名安全、交际康复、利率约束、答应/回绝地址列表和无gas的元买卖。现在智能合约钱包的用户体会到了gas 费波动的影响,并且第三方中继器无法有用处理这个问题。而账户笼统旨在处理这个问题。

在本文中,咱们提出了智能合约钱包背景下对账户笼统的需求。然后,咱们经过描绘协议改动和对节点的影响深入探讨账户笼统的要害方面。最终,咱们评论了一些扩展的提议,并经过合理化与以太坊接口的Status项目的方案路线图来结束,这些项目或许都会受到账户笼统的影响。

前史&动机

账户笼统开始是在2017年以EIP-86的方法提出的,目的是完成 "买卖来历和签名的摘要",但这一想法的起源能够追溯到更早的2016年。其时有人主张:"与其有一个协议内机制,将ECDSA和默认的nonce方案作为仅有的 「标准 」方法来保证账户的安全,不如采纳开始办法,建立一个模型,从长远来看,一切的账户都是合约,并且合约能够付出gas,用户能够自由定义自己的安全模型。"

开始的主张被认为是具有挑战性的,由于需求改动许多协议并且需求保证安全性。最近,Vitalik等人提出了EIP-2938的草案,该草案概述了一个更简单完成的办法:经过将协议/一致的改动最小化并经过节点mempool规矩强制履行所需的安全保证。由Sam Wilson和Ansgar Dietrichs(另外两位EIP作者)撰写的Vitalik的以太坊 Engineering Group Meetup presentation和ETH Online presentation(以及相关文章1和2)为这个主题供给了更具体的介绍。本文重点介绍了一切这些来历的要害内容。

动机:账户笼统背后的动机原理十分简略,但却是根本性的:今日的以太坊买卖具有可编程的效果(经过调用智能合约完成),但它们只具有固定的有用性,即只需当它们具有有用的ECDSA签名与有用的nonce,并且具有满足的账户余额时,买卖才是有用的。账户笼统经过引入一种新的账户笼统买卖类型,将买卖从固定有用性升级为可编程有用性。这种账户笼统买卖类型总是来自一个特别的地址并且协议不需求对其进行签名、Nonce或余额查看。这种账户笼统买卖的有用性由方针智能合约决议,方针智能合约能够履行自己的有用性规矩,之后它能够决议为这类买卖付款。

那么,为什么这个很有用呢?咱们以以太坊钱包为例来着重账户笼统的优点。

智能合约钱包:现在大多数以太坊钱包都是EOA钱包,它由种子短语生成的私钥保护。(BIP-39种子短语是一个由12-24个单词组成的有序列表,这些单词是从2048个单词中随机挑选的。这供给了取得二进制种子所需的熵,该种子运用PBKDF2函数生成。然后,二进制种子被用来生成BIP-32钱包的非对称密钥对。) 用户应该把种子短语写在安全的当地,由于以后在另一个钱包上康复密钥时或许需求它。可是,这种钱包很简单受到私钥被盗或种子短语丢失的影响,然后导致用户的资金损失。

智能合约钱包是经过智能合约在链上完成的。这种钱包经过完成多签名安全、交际或根据时间的康复、买卖或金额的速率约束、答应/回绝地址列表、无gas买卖和批量买卖等功用,供给可编程的功用缓解危险以及用户友爱体会。

尽管智能合钱包露出在易受进犯的智能合的安全危险之下,但钱包供给商履行的安全测验和审查能够减轻这种危险。EOA钱包的危险完全在于钱包用户,他们被委托担任种子短语的安全,而在智能合约中没有任何可保证安全的程序。

智能合约钱包的比方有Argent、Authereum、Dapper、Dharma、Gnosis Safe、Monolith和MYKEY。如下图所示,这类钱包的采用率似乎在添加。

  深度丨Vitalik 提出的EIP-2938将给以太坊带来哪些改变?

Argent经过他们的Guardians概念完成了无密钥交际康复功用,其间Guardians是用户信赖的人或设备,能够帮助找回用户的钱包。Argent还旨在完成相似银行的安全性(经过每日买卖限额、账户确认和可信联系人等功用)以及相似Venmo的可用性(经过运用ENS称号而非地址和支撑元买卖)相结合。

Gnosis Safe是一个多签名的智能合约钱包,专心于团队办理资金,需求团队成员的最低数量(m-of-n)同意买卖才干产生。它还能够经过元买卖完成无gas签名。

一切这些先进的钱包功用都需求运用完善的智能合约。钱包用户要么需求与EOA进行交互,要么依托钱包供给商经过供给商的中继器或第三方中继器网络(如 Gas Station Network)来支撑元买卖。前者依托于在KYC后的中心化买卖所购买ETH,而后者旨在经过将用户的担负转移到中继器上,以削减这种上链用户体会冲突,其本钱由钱包供给商链上/链下和/或用户链下补偿。

可是,根据中继器的架构有三个主要缺陷:(1)它们或许会被认为是中心化的中介机构,有或许会对买卖进行审查(2)由于中继者的买卖需求额定的21000根底gas fee,并且它们的业务需求在gas fee之外取得赢利,因而在技能/经济上效率低下(3)运用中继者专用协议迫使使用依托非基底层的以太坊根底设施,其用户群较小,可用性保证不确认。

账户笼统将使智能合约钱包能够承受用户的无gas买卖,并在不依托中继层网络的状况下为其付出gas 费。因而,这种基层能力将极大地改进这类钱包的入驻用户体会,而不会牺牲以太坊的去中心化保证。

Tornado Cash:一个相关的动机使用是混币器,如tornado.cash,其间Tornado经过运用智能合约打破地址之间的链上联系来改进买卖隐私,该合约承受ETH存款,随后可由不同的地址提取。用户在存款时需求供给隐秘的哈希值,之后在提现时供给zkSnark证明,以显示对隐秘的了解,而不泄露隐秘或之前的存款自身。这样就把提现和存款脱钩了。

但提现存在一个问题要从新生成的地址中履行提现买卖,用户需求在里面有一些ETH来付出gas。这个ETH的来历(一般是买卖所)会破坏Tornado的隐私。首选的替代方案是再次运用中继器网络,可是它有前面概述的缺陷。

账户笼统将处理这个问题,答应Tornado合约承受用户的提现账户笼统买卖,然后验证zkSnark并扣除一些gas费(从之前的存款金额中扣除),然后将剩下的存款金额转到提现地址。

账户笼统

EIP-2938号文件提出的账户笼统,答应合约成为付出费用和开端履行买卖的最高档账户。这是经过引入协议改动完成的,新的账户笼统买卖类型需求两个新的操作码:NONCE和PAYGAS,对mempool的规矩进行改动以及支撑高档用法的扩展。账户类型仍然有两种类型(EOA和合约账户),一切拟议的改动都与当时的买卖、智能合约和协议向后兼容。

账户笼统的使用分为两个方面考虑:1)单租户使用,如智能合约钱包,为每个用户创立一个新的合约 2)多租户使用,如tornado.cash或Uniswap,多个用户与同一套智能合约交互。

账户笼统对多租户使用的支撑需求更多的研讨,主张作为未来的作业。所以咱们将在本文中重点评论单租户账户笼统的支撑。

协议改动

引入了一种新的买卖类型,以及两个支撑NONCE和PAYGAS的操作码。这些是仅有的协议改动。

账户笼统买卖:引入了一种新的账户笼统买卖类型AA_TX_TYPE。它的有用类型被解释为RLP([nonce, target, data]),而不是现有的买卖类型。后者的有用类型是RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])。

账户笼统买卖中省略的gas_price和gas_limit在履行过程中由方针账户笼统合约指定。账户笼统买卖中省略的 ECDSA 签名 v、r、s 由特定合约对数据进行验证查看替代。to 地址由方针合约地址替代。之所以省略该值,是由于一切账户笼统买卖的始发地址是一个特别的ENTRY_POINT地址(0xFFFF...FFF),而不是与之相关联的EOA值。

假如查看失利,则买卖被认为是无效的,不然,tx.target.nonce将被递增,买卖持续进行。

账户笼统买卖的根本gas本钱主张为15000,而不是现在的21000(以反映缺乏内在ECDSA签名所节约的本钱)。此外,账户笼统买卖没有内在gas限额。在开端履行时,gas限值只需设定为该组的剩下gas。

NONCE操作码:NONCE操作码(0x48)将被调用者的NONCE(即账户笼统方针契约)压入EVM堆栈。因而,Nonce露出给EVM,以答应对一切买卖字段(包括nonce)进行签名验证,作为账户笼统合约中验证的一部分。

PAYGAS操作码:PAYGAS操作码(0x49)从堆栈中取出两个参数: (顶部)version_number, (顶部第二个)memory_start. version_number答应未来的完成改动opcode的语义。现在,该操作码的语义如下。

查看 version_number == 0 (不然抛出反常)

提取 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

提取 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])

查看contract.balance >= gas_price * gas_limit (不然抛出反常)

查看 globals.transaction_fee_paid == False (不然抛出反常)

查看AA履行结构==顶层结构,即假如当时EVM履行退出或复原,则整个业务的EVM履行终止(不然抛出反常)。

设置contract.balance -= gas_price * gas_limit(约束)。

设置 globals.transaction_fee_paid = True

设置 globals.gas_price = gas_price 和 globals.gas_limit = gas_limit。

设置当时履行上下文的剩下gas=gas_limit-现已耗费的gas。

在账户笼统买卖履行结束时,(globals.gas_limit - remaining_gas)*globals.gas_price转移给矿工,账户笼统合约退还 remaining_gas * globals.gas_price。

PAYGAS作为EVM履行查看点。在此点之后的任何复原都只会复原到这儿,然后合约不承受退款,globals.gas_limit * globals.gas_price转移到矿机

新的买卖类型和两个新的操作码构成了协议/一致层面的改动,它们的语义是比较简单了解。

Mempool规矩

"Mempool "指的是以太坊节点内部的一组内存数据结构,它在挖矿前存储候选买卖。Geth称其为 "买卖池";Parity称其为 "买卖行列"。无论称号怎么,它都是一个坐在内存中等候被归入区块的买卖池。把它看成是一个 "等候区",等候买卖被承受到一个区块中。"

现在,经过固定的买卖有用性规矩,矿工和其他节点只需求最小的尽力就能够验证其mempool中的买卖,然后防止DoS进犯。例如,假如一个矿工拥有有用的ECDSA签名、有用的nonce,并且有满足的账户余额,就能够确认某笔买卖将真正付出费用。该矿工的mempool中的其他买卖只需在来自同一地址,并且,添加nonce或充沛削减账户余额的状况下,才或许使这个待处理的买卖无效。这些条件在计算上是最小的,以使矿工和节点对其mempools有满足的信心,分别进行区块等候或重播。

账户笼统买卖以其可编程的有用性引入了更多的复杂性。账户笼统买卖不付出任何前期gas,并依托其方针账户笼统合约来付出gas(经过PAYGAS)。从概念上讲,账户笼统买卖处理分为两个阶段:较短的验证阶段(PAYGAS之前)和较长的履行阶段(PAYGAS之后)。假如验证阶段失利(或抛出反常),买卖无效(就像今日无效签名的非账户笼统买卖一样),不会被包含在一个区块中,矿工也得不到任何费用。

因而,矿工和节点需求一个可预测的机制来防止一个待处理的账户笼统买卖的有用性对mempool中其他待处理买卖的依托性。不然,一个买卖的履行或许会使mempool中的许多/一切账户笼统买卖无效,导致DoS进犯。为了防止这种状况,有两个主张的规矩要在mempools中的账户笼统买卖上履行(由矿工和节点履行,但不是在协议自身)。

Opcode Restriction

为了防止账户笼统买卖的有用性取决于账户笼统合约自身以外的任何因素,以下操作码在核对阶段(即在PAYGAS之前)被视为无效:PAYGAS之前):环境操作码(BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT)、BALANCE(任何账户,包括方针自身)、对方针以外的任何事物的外部调用/创立或预编译(CALL, CALLCODE、STATICCALL、CREATE、CREATE2)和读取代码的外部状况拜访(EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL),除非地址是方针。

节点要放弃mempool中以账户笼统合约为方针的账户笼统业务,打破这个操作码约束规矩。这保证了只需账户笼统合约状况不产生改动,mempool中的有用账户笼统业务将坚持有用。

字节码前缀约束

假如非账户笼统业务能够影响账户笼统合约的状况,那么就会影响mempool中账户笼统业务的有用性。为了防止这种状况的产生,账户笼统业务应该只答应针对那些在其字节码最初有AA_PREFIX的合约,其间AA_PREFIX完成了对msg.sender是账户笼统业务的特别ENTRY_POINT地址的查看。这有用地防止了非账户笼统买卖与账户笼统合约的交互。

节点要把账户笼统业务丢给在其字节码入口点没有这个AA_PREFIX的账户笼统合约。

对账户笼统合约施行的这两个约束共同保证了:(1)账户笼统买卖的有用性逻辑所能拜访的仅有状况是账户笼统合约内部的状况,(2)这个状况只能被其他针对这个特定账户笼统合约的账户笼统买卖修正。

因而,只需在另一宗针对同一份账户笼统合约的等候买卖中,未完成的账户笼统买卖才会失效。可是,鉴于这些不是协议/一致的改动,矿工能够自由地在区块中包含打破这些规矩的买卖。

扩展

上述协议改变和mempool规矩答应根本的账户笼统合约充沛而安全地完成单租户使用,如智能合约钱包。其他需求放宽上述规矩或需求完成多租户使用的高档用法,则需求账户笼统以扩展的方法供给更多的支撑,比方。

SET_INDESTRUCTIBLE opcode,禁用SELFESTRUCT,答应账户笼统合约在验证阶段安全地调用DELEGATECALL的库。

IS_STATIC opcode,假如当时上下文是静态的,则回来true,答应非账户笼统业务调用者覆盖之前的字节码前缀约束,安全地从账户笼统合约中读出值。

RESERVE_GAS opcode,当从一个非账户笼统业务调用时,它建立了一个账户笼统合约耗费的gas下限,该下限是寻求写入合约状况的。这样做的作用是迫使进犯者不耗费最低数量的gas,以按捺试图使mempool中任何账户笼统业务无效的行为。

还有其他的如多个待处理的买卖、验证的缓存成果、验证的动态gas约束和资助买卖,这些都是支撑多租户使用和zk证明所需求的,如Tornado Cash。关于它们的具体内容不在本文的评论范围内。

下一步作业

账户笼统EIP-2938现在处于草案形式,正在以太坊研评论坛中进行评论。EIP的下一步是被考虑归入即将到来的硬分叉之一。EIP作者的方针显然是Berlin之后的硬分叉(Berlin暂定于2021年初的某个时间),其时间表现在还不是很清晰。所以关于EIP-2938来说,现在还为时过早。

此外,也不清楚是否有必要在以太坊根底第1层(L1)参加EIP-2938。鉴于第2层(L2)处理方案的相对灵活性(如咱们之前的文章所述),账户笼统能够在特定的L2上完成,而不需求升级整个L1。可是,即使一些L2完成了自己的账户笼统版本,在L1上统一支撑账户笼统也有优点。因而,账户笼统在哪里完成,怎么完成,还有待观察。

“账户笼统不太重要是由于不管L1是否支撑,都能够在L2上完成。”--- Vitalik在他关于以汇总为中心的以太坊路线图的文章中谈到了在根底层将持续起作用的事情)。

Status:Status钱包现在是一个EOA钱包,它的区别在于捆绑了一个以隐私为中心的短信体系,并完成了谈天中的付出或Keycard的增强安全性等集成。正在考虑智能合约钱包的功用,如多签和交际康复,账户笼统 EIP-2938的支撑将有助于消除对集中式和低效的根据relayer的架构的依托,如前所述。

Status也在评估L2处理方案,既要支撑其钱包中的多链,又要为各种用例供给所需的扩展,如咱们在前面的文章中所述。例如,Keycard正在探索一个付出网络,其信用卡等级的可扩展性和近乎即时的终局性的规划要求是现在以太坊网络无法满足的。此外,还有许多其他的方案,如推荐方案、Tribute-to-Talk和ENS称号,一切这些方案都将获益于L2扩展性,以完成可行的布置和合理的用户体会。假如一个可行的L2处理方案完成了账户笼统,那么建立在该L2根底上的项目将能够利用账户笼统的优势,而不用依托L1。

总结

以太坊协议的一个根本方面是,只需外部自有账户(EOAs)能够付出gas费并开端履行买卖。合约账户(CA)不能这样做。账户笼统(AA)是一个提案,旨在改动这种区别,答应专门构建的CA以编程方法查看新型账户笼统买卖的有用性,决议代为付出gas,然后有用地发动其履行,而不需求EOA。

账户笼统关于显著改进钱包、混币器、DApps和DeFi等各种场景下的用户体会具有意义,而无需依托中心化和低效的根据relayer的架构。根本的单租户场景,如智能合约钱包,经过引入一种新的买卖类型、两种新的操作码和两种mempool规矩,账户笼统能够安全地支撑。高档多租户使用,如Tornado Cash,需求对这些协议改动和节点规矩进行扩展。

在这篇文章中,咱们提到了智能合约钱包背景下对账户笼统的需求。咱们经过描绘协议改动和对节点的影响来着重账户笼统的要害方面。咱们触及了一些针对高档用途的拟议扩展,最终,咱们在以太坊当时的路线图和Status的优先事项中对账户笼统进行了定位。

在Web3中削减冲突和改进用户体会是这个生态体系中一切项目的首要任务。账户笼统,以某种方法,或许肯定会在未来的尽力中发挥重要作用。

视野开拓

沃尔夫在美国各地对很多不同人士进行了深入调查,得出几乎一致的结论:作为个体,每个人都在按照自己的取向去选择自身的价值观和道德观。-《选择的悖论》

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注