账户抽象提案：pros and cons

每晚八点，我们在社区分享知识，等你。

NervosFans 微信公号：Nervosfans

入群请加乐乐微信：sensus113 美果大冰微信：xj73226

备注入群，谢谢！

---

根据EIP 86等提案，“帐户抽象”的目标是把帐户类型的数量从2（EOA、合约）减少到1（合约），并把签名验证、gas支付以及重放保护等功能从核心协议转移至虚拟机。但是，这么做是有代价的。比方说开发时长、迁移成本、区块链存储额外代码成本、打破现有不变量等问题。有鉴于目前的分片路线图中，分片可以从零开始，所以有些代价相比之下要低许多，且无需对已有账户进行升级，但还是有问题值得探讨。

以下为一些抽象可能，以及各自的优缺点。

懒人完全抽象

· 原理：唯一的账户类型就是合约。交易类型只有一种，包含如下字段：[gas，addr（地址），data（数据）]。执行交易包括广播消息，其中msg.sender代表某标准“ENTRY_POINT（入口）”地址（比如0xff ... ff）；msg.to代表addr；gas及数据代表提供值。

用户需将资金存储在合约账户中，由合约代码进行以下操作：将提供数据解释为[nonce（随机数），signature（签名），gasprice（gas价格），value（价值），data（数据）]的ABI编码、验证随机数与签名、向矿工支付gas、向目标地址发送带有目标价值的消息、要求退还剩余gas。

· 优点：协议变得非常简单。apply_tx变成了apply_msg一个非常简单的包装器

· 缺点：帐户内部用来验证随机数和签名并支付gas费用的代码会相当复杂。其次，用来确定哪些交易一定会支付gas的矿工代码也会相当复杂。第三，发送人与矿工创建新帐户需要附加逻辑。最后，由于账户以“非标准”方式构造，带有相同哈希的一笔交易有可能被打包多次。

矿工的问题如下。矿工决定处理交易并打包入块时，需要在O（1）时间内验证给定交易必定支付gas费用。抽象系统中，涉及要求矿工运行一些（比方说gas上限是200000的）代码，但矿工要确定在此之后，交易的执行能处于gas费用已支付的状态，且支付不可逆。现在的话，由协议自动处理这些事；而在完全抽象的情形下，则全部由代码实现，方式很可能比较复杂的说。

去除随机数抽象

· 原理：原理同上，但交易还包含nonce字段。规定交易的随机数必须与账户随机数相等，且nonce随交易成功递增。

· 优点：避免一笔交易在多个地方出现。

· 缺点：略微增加基础协议的复杂性，且堵死了UTXO、可并行nonce等替代方案的后路。

标准化签名方案

· 原理：为交易添加字节数组字段sig。顶层消息中，向交易的返回数据添加sighash ++ sig，其中sighash代表未包含签名交易的sha3。

· 优点：简化签名验证。

· 缺点：略微增加基础协议的复杂性。

添加BREAKPOINT（断点）操作码

· 原理：添加BREAKPOINT操作码，该操作码有如下属性：交易在断点后抛出异常时，恢复仅至断点处。

· 优点：简化矿工检测交易是否支付gas；矿工代码长成大概其‘运行N步或直至断点，看看是否已经到达断点处且gas已支付’的样子就可以了。

· 缺点：引发EVM大变样，所以一直以来都不算太好的主意。

添加PAYGAS操作码

· 原理：用变量（gasprice）作输入，立即将gasprice * tx.gas转移至临时账户，然后在执行交易结束时退还全部未消耗gas。

· 优点：简化了gas支付，主要是因为交易不用必须包含Merkle分支才能处理对coinbase的调用。避免了调用coinbase的开销。

· 缺点：增加了基础协议的复杂性。也不支持对gas支付抽象，比方说不让用ERC20代币支付gas。

Gasprice + PANIC

· 原理：交易添加gasprice参数。执行开始时，减去gasprice * startgas。添加PANIC操作码，仅能在顶层执行环境（比如，若msg.sender == ENTRY_POINT）中被调用，其中(tx.gas - msg.gas) <=PANICLIMIT（比如，PANICLIMIT = 200000）。此操作码被触发时，整笔交易无效。为避免无效交易消耗gas，用户帐户肯定要对LIMIT之内的签名和nonce进行检查。矿工会处理gas价格充足的交易，拒绝掉panic（gas不足）交易。

· 优点：帐户代码、矿工代码都比较简单，同时仍有完全的签名和随机抽象。

· 缺点：略微增加了基础协议的复杂性；也不支持gas支付抽象；签名验证耗时没有灵活性（Casper对这个时长是有限制，因此耗时限制可以设置为（与Casper）相同）。

还有种变体是啥呢，是说用剩余gas在顶层环境中调用时，就直接把交易无效行为变成THROW行为的一部分。

PANIC & PAYGAS结合

· 原理：删除PANIC。尚未调用PAYGAS时，让所有异常都有与PANIC等效的行为。

· 优点：支持帐户自行设置各自基础验证的gas上限。矿工可以运行‘运行价值N个gas的代码’这种算法，其中N由矿工决定，直至调用PAYGAS。此外，该方法下gasprice不必作为交易的一部分。

· 缺点：消息输出状态变得有点复杂，原因是消息输出还要带上PAYGAS操作码是否被触发，以及被触发，gasprice为多少的信息。

交易Salt + code

· 原理：交易包含两个新字段：salt和code。交易的目标帐户为非空账户时，两个字段必为空[忽略variant:]。目标帐户为空账户时，sha3（salt + code）的最后20个字节必与账户相等，该情形下将代码置于帐户代码中的该位置[用variant：作初始化代码]。

· 优点：开辟了标准简洁的新账户创建方式。

· 缺点：增加协议的复杂性。

新创建账户支付

· 原理：指定salt和code时，交易可以是合约创建交易。目标地址为空时，交易从空地址获取资金支付gas，然后创建合约。

· 优点：与现有合约创建类似。

· 缺点：从帐户发送的第一笔交易会多出一个步骤。

结论

目前来讲，我个人比较倾向gasprice + PANIC的两种变体。当然了，不排除还有其他方式。

---

https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263