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

November 15 th, 2015

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

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

February 10 th, 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 30 th, 2018

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

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

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