作者：Vitalik Buterin
译者：Alan，Plancker DAO
原文链接：https://vitalik.ca/general/2023/09/30/enshrinement.html
特别感谢 Justin Drake、Tina Zhen 和 Yoav Weiss 的反馈和审阅
以太坊项目从一开始就秉承着一个强烈的理念，即尽量简化以太坊核心，并通过在其上构建协议来实现尽可能多的功能。在区块链领域，"在 L1 上构建"与"专注于 L2 "的争论通常被认为主要是关于扩展的，但实际上，在满足多种以太坊用户的需求方面也存在类似的问题：数字资产交换、隐私、用户名、高级密码学、账户安全、抗审查、前置保护等等，不胜枚举。然而，最近，人们对将更多此类功能封装（enshrine）进以太坊核心协议的意愿产生了一些谨慎的兴趣。
这篇文章将深入探讨最初的"最小封装"理念背后的一些哲学推理，以及最近对其中一些想法的一些思考方式。我们的目标是开始建立一个框架，以便更好地识别可能的目标，在这些目标中，封装某些功能或许值得考虑。
在当时被称为"以太坊 2.0"的历史早期，人们强烈希望创建一个干净、简单、美观的协议，尽可能减少自身的工作量，将几乎所有事情都留给用户在上面构建。理想情况下，协议只是一个虚拟机，验证一个区块只需调用一次虚拟机。
我和 Gavin Wood 在 2015 年初绘制了一张白板图，当时我们正在讨论以太坊 2.0 会是什么样子。
"状态转换函数"（处理区块的函数）只调用单一的虚拟机，所有其他逻辑都将通过合约实现：其中有一些系统级合约，但大部分是用户提供的合约。这种模式一个非常好的特点是，即使是整个硬分叉，也可以描述为对区块处理器合约而言的单笔交易，该合约将通过链外或链上治理批准，然后以升级权限运行。
2015年的这些讨论尤其适用于我们思考的两个领域：账户抽象和扩容。就扩容而言，我们的想法是尝试创建一种最大程度的抽象化扩容，让人感觉就像上图的自然延伸。合约可以调用大部分以太坊节点都没有存储的数据，而协议会检测到这一点，并通过某种非常通用的扩展计算功能来解决调用问题。从虚拟机的角度来看，该调用会进入某个独立的子系统，然后在一段时间后神奇地反馈正确答案。
我们曾短暂地探索过这一思路，但很快就放弃了，因为我们太专注于验证任何区块链扩展都是可能的。不过，正如我们稍后将看到的，数据可用性采样和 ZK-EVM 的结合意味着以太坊扩容的一个可能的未来，实际上似乎与这一设想非常接近！另一方面，对于账户抽象来说，我们从一开始就知道某种实现是有可能的，因此我们立即开始研究，试图将"交易只是一个调用"这一纯粹的出发点变为现实。
在处理交易和从发件人地址调用实际的底层 EVM 之间有大量的模板代码，之后还有更多的模板代码。如何尽可能减少这些代码？
这里的主要代码之一是 validate_transaction(state, tx), 它的作用是检查交易的 nonce 和签名是否正确。从一开始，账户抽象的实际目标就是允许用户用自己的验证逻辑取代基本的 nonce-递增和 ECDSA 验证，这样用户就能更轻松地使用社交恢复和多重签名钱包等功能。因此，找到一种方法将 apply_transaction 重构为一个简单的 EVM 调用，并不是简单的 "为了使代码整洁而使代码整洁 "的任务；而是要将逻辑移到用户的账户代码中，为用户提供所需的灵活性。