特别感谢 Justin Drake, Tina Zhen 和 Yoav Weiss 的反馈和审查。
从以太坊项目开始，就有一个强烈的理念，即试图使核心以太坊尽可能简单，并通过在其上构建协议来尽可能实现这一点。在区块链领域，「在 L1 上构建」与「专注于 L2」的争论通常被认为主要是关于扩展的，但实际上，在满足多种以太坊用户的需求方面存在类似的问题：数字资产交换、隐私、用户名、高级加密、账户安全、抗审查、抢先交易保护，等等。然而，最近有一些谨慎的想法愿意将更多这些功能封装（enshrine）进核心以太坊协议中。
这篇文章将深入探讨最初的最小封装哲学背后的一些哲学推理，以及一些最近思考这些想法的方法。目标将是开始建立一个框架，以便更好地确定可能的目标，在这些目标中，封装某些功能可能值得考虑。
在当时被称为「以太坊 2.0」的早期历史中，人们强烈希望创建一个干净，简单和美观的协议，该协议尽可能少地尝试通过自身来构建，并将几乎所有这类工作都留给用户。理想情况下，协议只是一个虚拟机，而验证一个区块只是一个虚拟机调用。
「状态转换函数」（处理区块的函数）将只是单个 VM 调用，所有其他逻辑将通过合约发生：一些系统级合约，但主要是由用户提供的合约。这个模型的一个非常好的功能是，即使是整个硬分叉也可以被描述为对于区块处理器合约而言的单笔交易，该交易将通过链下或链上治理进行批准，然后以升级的权限运行。
2015 年的这些讨论特别适用于我们考虑的两个领域：账户抽象和扩容。在扩容的情况下，我们的想法是尝试创建一个最大程度的抽象形式的扩容，感觉就像上面图表的自然扩展。合约可以调用大多数以太坊节点未存储的数据，协议将检测到这一点，并通过某种非常通用的扩展计算功能来解决调用。从虚拟机的角度来看，该调用将进入某个单独的子系统，然后一段时间后神奇地返回正确的答案。
我们对这种思路进行了简短的探索，但很快就放弃了，因为我们太专注于验证任何类型的区块链扩容都是可能的。尽管我们稍后会看到，数据可用性采样和 ZK-EVM 的结合意味着以太坊扩容的一个可能的未来实际上看起来非常接近这个愿景！另一方面，对于帐户抽象，我们从一开始就知道某种实现是可能的，因此研究立即开始尝试使一些尽可能接近「交易只是一个调用」的纯粹出发点的东西变为现实。
在处理交易和从发送方地址发出实际的底层 EVM 调用之间，会出现大量的样板代码，之后还会出现更多的样板代码。我们如何将这些代码尽可能减少到接近于零？
这里的主要代码之一是 validate_transaction(state, tx)，它负责检查交易的 nonce 和签名是否正确。从一开始，帐户抽象的实际目标就是允许用户用自己的验证逻辑替换基本的非增量验证和 ECDSA 验证，这样用户就可以更轻松地使用社交恢复和多签名钱包等功能。因此，找到一种方法将 apply_transaction 重新架构为一个简单的 EVM 调用，这不仅仅是一个「为了使代码干净而使代码干净」的任务；相反，它是关于将逻辑移动到用户的帐户代码中，为用户提供所需的灵活性。
然而，坚持让 apply_transaction 包含尽可能少的固定逻辑的做法最终带来了很多挑战。我们可以看下最早的帐户抽象提案之一 EIP-86 。
如果按原样包含 EIP-86 ，它将降低 EVM 的复杂性，代价是大量增加以太坊堆栈其他部分的复杂性，需要在其他地方编写本质上完全相同的代码，除了引入全新的怪异类别之外，例如具有相同哈希值的同一交易可能会在链中多次出现，更不用说多重失效问题了。
账户抽象中的多重失效问题。在链上包含的一笔交易可能会使内存池中的数千笔其他交易无效，从而使内存池很容易被廉价地充斥。
从那时起，帐户抽象分阶段发展。EIP-86 后来变成了 EIP-208 ，最终出现了实际可行的 EIP-2938 。
然而，EIP-2938 一点也不简约。其内容包括：
· 新的交易类型
· 三个新交易范围的全局变量
· 两个新的操作码，包括非常笨拙的 PAYgas 操作码，用于处理 gas 价格和 gas 限制检查，作为 EVM 执行断点，以及临时存储 ETH 以一次性支付费用
· 一组复杂的挖矿和转播策略，包括交易验证阶段禁止的操作码列表