零点课堂 | 账户抽象的动机、历史和分析(2)-零点财经

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

账户抽象的发展史

根据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 发表,其版权均为 零点财经 所有,文章内容系作者个人观点,不代表 零点财经 对观点赞同或支持。如需转载,请注明文章来源。
分享生成图片
66

发表回复

零点课堂 | 账户抽象的动机、历史和分析(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)才能实现。多租户阶段的技术方案仍未成型。