零点课堂 | 账户抽象的动机、历史和分析（2）

taotao 深度 2021年6月29日
1.51W 0

账户抽象的发展史

根据Matt Garnett整理的账户抽象发展历史[2]，从以太坊2015年上线起，账户抽象的讨论没有停止。本文将按照时间顺序，对账户抽象相关的EIP进行简要介绍。需要说明的是，该历史漏掉了EIP-208，我做了相应补充。

EIP-101：货币与密码学抽象

[[November 15th, 2015]]

在这个EIP[3]中，Vitalik讨论了对Serenity中的账户体系的设计。这个方案的主要思想是，每个账户都拥有自己的“代码”，也即逻辑部分。由于该方案改动过大，与当前事务的兼容性不好，会造成许多安全隐患，该方案被搁置到分片之后。

EIP-86：事务来源和签名抽象

[[February 10th, 2017]]

经过漫长的讨论，Vitalik提出了EIP-86。EIP-86是为账户抽象做技术准备，它定义了一种新的账户类型，允许用户创建基于智能合约的账户，该账户是一个代理合约（forwarding contract），存储Ether，在入口点检查事务的签名，并将验证合法的事务转发到指定的地址，并支付相应的费用。这种机制对多签钱包、环签名混币、自定义的密码算法（例如ed25519）等场景的实现有更多帮助。

对EIP-86的讨论展开了很久，值得说明的是，Vitalik丰富了协议细节，提出了EIP-208。EIP-86/208计划于Metropolis阶段升级，但在第19次核心开发者会议[4]上，开发者提出了很多问题，并决定在Metropolis中暂缓引入，主要理由如下。

  • 账户抽象带来新类型的事务，与传统事务必须有一个EOA作为发送者相比，这些事务没有发送者。这种事务破坏了事务哈希的唯一性，尽管这不会对EVM的执行造成影响，但是所有基于“唯一性”假设的外部操作都会收到影响。例如，所有通过事务哈希来定位事务的RPC接口。
  • 此外，账户抽象的“无气支付”是一个优化，但是必要性不足。因为其功能可以通过“代理合约”实现，唯一的问题是其开销会比原生实现要大一些。
  • 矿工的挖矿策略会受到极大影响，在被广泛接纳前，这些新类型的事务可能无法被很快广播。
  • 这种新类型的事务仍然保留了nonce、gasprice、value字段，且被设为0。这非常不优雅，希望未来用新的事务类型解决，而不是引入技术债。

EIP-859：主网上的账户抽象

[[January 30th, 2018]]

与前两个EIP不同，EIP-859并没有形成确定性的草案，而是始终在讨论过程中，没有定稿。该提案希望账户合约有一个相对规范的实现，即（1）检查签名（2）支付手续费（3）调用目的账户。

如果EIP-859实现，可以抽象（1）签名算法（2）更复杂的逻辑，并且不会破坏“事务哈希唯一”的特性，但仍然不能允许使用ERC-20支付费用。

这个提案在第34次和第40次核心开发者会议的笔记中被提及。根据会议笔记，第33次核心开发者会议上决定搁置该提案，而是聚焦于Casper。而Vitalik在第34次会议[5]上承认该提案仍不成熟，但“不管怎样在分片时会实现”。Hudson指出，君士坦丁堡升级包含的内容太多了，因此不再考虑该提案。第40次核心开发者会议上，大家决定永久搁置该提案，无人反对。

EIP-2938：账户抽象

[[September 4th, 2020]]

时间又过了两年，ETH 2.0的Phase 0已经启动，而账户抽象也被重新提上议程。出乎意料的是，该提案建议在ETH 1.x上首先实现。

简单来说，账户抽象的目标是让智能合约成为顶级的账户类型，而非受限制的必须由外部账户调用的账户，这样智能合约账户就可以主动发起事务并支付手续费。这个目标与EIP-86已经有了很大区别，当时的提案希望彻底消灭外部账户，或者说将所有的外部账户都变成合约账户，而此提案仍然保留了外部账户的存在。

以太坊当前的事务合法性只通过三个参数判断：ECDSA签名、自增nonce和账户余额，因此节点非常容易判断一笔事务的合法性。然而，这势必造成了很多限制。EIP-2938实现后，以下场景可以主动实现：

  • (1)智能钱包使用ECDSA之外的算法验证签名；
  • (2)智能钱包的其它特性，包括多重签名和社交恢复；
  • (3)保护隐私的系统，例如Tornado.cash；
  • (4)提高DeFi协议gas效率；
  • (5)用户使用其它token，而不是ETH支付手续费。

目前，以上用户场景也可以通过间接的方式实现。该提案认为这种方式在技术和经济上都不高效。

EIP-2938分为单租户和多租户两个阶段，顾名思义，其区别在于账户的拥有者是单个用户还是多个（不特定的）用户。在单租户阶段能满足(1)、(2)和(5)场景的需求，而只有在多租户阶段(3)和(4)才能实现。多租户阶段的技术方案仍未成型。

本文由 零点财经 作者：tao 发表，其版权均为 零点财经 所有，文章内容系作者个人观点，不代表 零点财经 对观点赞同或支持。如需转载，请注明文章来源。
分享生成图片
♥赞60

相关文章

发表回复

零点课堂 | 账户抽象的动机、历史和分析（2）

2021-06-29 10:18:52

账户抽象的发展史

根据Matt Garnett整理的账户抽象发展历史[2]，从以太坊2015年上线起，账户抽象的讨论没有停止。本文将按照时间顺序，对账户抽象相关的EIP进行简要介绍。需要说明的是，该历史漏掉了EIP-208，我做了相应补充。

EIP-101：货币与密码学抽象

[[November 15th, 2015]]

在这个EIP[3]中，Vitalik讨论了对Serenity中的账户体系的设计。这个方案的主要思想是，每个账户都拥有自己的“代码”，也即逻辑部分。由于该方案改动过大，与当前事务的兼容性不好，会造成许多安全隐患，该方案被搁置到分片之后。

EIP-86：事务来源和签名抽象

[[February 10th, 2017]]

经过漫长的讨论，Vitalik提出了EIP-86。EIP-86是为账户抽象做技术准备，它定义了一种新的账户类型，允许用户创建基于智能合约的账户，该账户是一个代理合约（forwarding contract），存储Ether，在入口点检查事务的签名，并将验证合法的事务转发到指定的地址，并支付相应的费用。这种机制对多签钱包、环签名混币、自定义的密码算法（例如ed25519）等场景的实现有更多帮助。

对EIP-86的讨论展开了很久，值得说明的是，Vitalik丰富了协议细节，提出了EIP-208。EIP-86/208计划于Metropolis阶段升级，但在第19次核心开发者会议[4]上，开发者提出了很多问题，并决定在Metropolis中暂缓引入，主要理由如下。

  • 账户抽象带来新类型的事务，与传统事务必须有一个EOA作为发送者相比，这些事务没有发送者。这种事务破坏了事务哈希的唯一性，尽管这不会对EVM的执行造成影响，但是所有基于“唯一性”假设的外部操作都会收到影响。例如，所有通过事务哈希来定位事务的RPC接口。
  • 此外，账户抽象的“无气支付”是一个优化，但是必要性不足。因为其功能可以通过“代理合约”实现，唯一的问题是其开销会比原生实现要大一些。
  • 矿工的挖矿策略会受到极大影响，在被广泛接纳前，这些新类型的事务可能无法被很快广播。
  • 这种新类型的事务仍然保留了nonce、gasprice、value字段，且被设为0。这非常不优雅，希望未来用新的事务类型解决，而不是引入技术债。

EIP-859：主网上的账户抽象

[[January 30th, 2018]]

与前两个EIP不同，EIP-859并没有形成确定性的草案，而是始终在讨论过程中，没有定稿。该提案希望账户合约有一个相对规范的实现，即（1）检查签名（2）支付手续费（3）调用目的账户。

如果EIP-859实现，可以抽象（1）签名算法（2）更复杂的逻辑，并且不会破坏“事务哈希唯一”的特性，但仍然不能允许使用ERC-20支付费用。

这个提案在第34次和第40次核心开发者会议的笔记中被提及。根据会议笔记，第33次核心开发者会议上决定搁置该提案，而是聚焦于Casper。而Vitalik在第34次会议[5]上承认该提案仍不成熟，但“不管怎样在分片时会实现”。Hudson指出，君士坦丁堡升级包含的内容太多了，因此不再考虑该提案。第40次核心开发者会议上，大家决定永久搁置该提案，无人反对。

EIP-2938：账户抽象

[[September 4th, 2020]]

时间又过了两年，ETH 2.0的Phase 0已经启动，而账户抽象也被重新提上议程。出乎意料的是，该提案建议在ETH 1.x上首先实现。

简单来说，账户抽象的目标是让智能合约成为顶级的账户类型，而非受限制的必须由外部账户调用的账户，这样智能合约账户就可以主动发起事务并支付手续费。这个目标与EIP-86已经有了很大区别，当时的提案希望彻底消灭外部账户，或者说将所有的外部账户都变成合约账户，而此提案仍然保留了外部账户的存在。

以太坊当前的事务合法性只通过三个参数判断：ECDSA签名、自增nonce和账户余额，因此节点非常容易判断一笔事务的合法性。然而，这势必造成了很多限制。EIP-2938实现后，以下场景可以主动实现：

  • (1)智能钱包使用ECDSA之外的算法验证签名；
  • (2)智能钱包的其它特性，包括多重签名和社交恢复；
  • (3)保护隐私的系统，例如Tornado.cash；
  • (4)提高DeFi协议gas效率；
  • (5)用户使用其它token，而不是ETH支付手续费。

目前，以上用户场景也可以通过间接的方式实现。该提案认为这种方式在技术和经济上都不高效。

EIP-2938分为单租户和多租户两个阶段，顾名思义，其区别在于账户的拥有者是单个用户还是多个（不特定的）用户。在单租户阶段能满足(1)、(2)和(5)场景的需求，而只有在多租户阶段(3)和(4)才能实现。多租户阶段的技术方案仍未成型。