以太坊是否应该同意在协议中确立更多内容？

特别感谢 Justin Drake、Tina Zhen 和 Yoav Weiss 的反馈和审阅。

从以太坊项目开始之初，就有一个强烈的理念，即尽量使核心以太坊尽可能简单，并通过在其上构建协议来尽可能多地完成任务。在区块链领域，“在L1上完成”与“专注于L2”之间的辩论通常被认为主要是关于扩展，但实际上，类似的问题也存在于满足许多种以太坊用户需求的情况下：数字资产交换、隐私、用户名、高级密码学、账户安全、抗审查、抢先交易保护等等。然而，最近一些人开始谨慎地对将更多这些功能正式纳入核心以太坊协议表示兴趣。

本文将探讨最初的最小化纳入哲学背后的一些理论推理，以及最近对其中一些想法的思考方式。目标是开始建立一个更好地识别可能值得考虑将某些功能纳入协议的目标的框架。

早期协议最小主义的理念

在当时被称为“以太坊2.0”的历史早期，人们强烈希望创建一个干净、简单和美丽的协议，尽量少地自行完成任务，几乎所有事情都留给用户来构建。理想情况下，协议将“只是”一个虚拟机，验证一个区块将“只是”一个单一的虚拟机调用。

这是我和 Gavin Wood 在2015年初所做的一个白板草图的非常粗略的重建，当时我们在讨论以太坊2.0的样子。

“状态转换函数”（处理区块的函数）将只是一个VM调用，所有其他逻辑都将通过合约进行：一些系统级别的合约，但主要是由用户提供的合约。这种模型的一个非常好的特性是，即使整个硬分叉也可以被描述为对区块处理器合约的单个交易，该交易将通过链下或链上治理获得批准，然后以升级的权限运行。

这些讨论特别适用于我们当时关注的两个领域：账户抽象和扩展。在扩展方面，想法是尝试创建一种最大程度抽象的扩展形式，使其感觉像上面的图表的自然延伸。合约可以调用大多数以太坊节点未存储的数据，协议会检测到这一点，并通过某种非常通用的扩展计算功能解决调用。从虚拟机的角度来看，调用将进入某个单独的子系统，然后一段时间后以正确的答案神奇地回来。

这种思路曾经被简要探讨过，但很快被放弃，因为我们过于忙于验证任何一种区块链扩展是否可能。然而，正如我们将在后面看到的，数据可用性抽样和ZK-EVMs的结合意味着以太坊扩展的一种可能未来实际上可能看起来出奇地接近那个愿景！另一方面，对于账户抽象，我们从一开始就知道某种实现是可能的，因此研究立即开始，试图使“交易只是一个调用”的纯粹起点尽可能接近现实。

在处理交易并从发送者地址进行实际的底层EVM调用之间有很多样板代码，之后还有更多的样板代码。我们如何将这些代码减少到尽可能接近于零？

这里的一个主要代码片段是validate_transaction(state, tx)，它做的事情包括检查交易的nonce和签名是否正确。账户抽象的实际目标从一开始就是允许用户用自己的验证逻辑替换基本的nonce递增和ECDSA验证，以便用户更容易地使用诸如社交恢复和多重签名钱包之类的功能。因此，重新设计apply_transaction成为简单的EVM调用并不仅仅是一个“为了代码整洁而使代码整洁”的任务；相反，它是将逻辑移入用户的账户代码，以给予需要灵活性的用户。

然而，坚持尽量减少apply_transaction中固化逻辑的努力最终带来了许多挑战。为了理解原因，让我们来看一下最早的账户抽象提案之一，EIP 86：

规范

如果 block.number >= METROPOLIS_FORK_BLKNUM，那么：1. 如果交易的签名为 (0, 0, 0)（即 v = r = s = 0），则将其视为有效，并将发送者地址设置为 2**160 - 1 2. 将通过创建交易创建的任何合约的地址设置为 sha3(0 + init code) % 2**160，其中 + 表示连接，替换之前的地址公式 sha3(rlp.encode([sender, nonce])) 3. 在 0xfb 处创建一个新的操作码，CREATE_P2SH，将创建地址设置为 sha3(sender + init code) % 2**160。如果该地址处已经存在合约，则失败并返回 0，就像初始化代码已经用完了一样。

基本上，如果签名设置为 (0, 0, 0)，那么交易确实变成了“只是一个调用”。账户本身将负责具有解析交易、提取和验证签名和nonce，并支付费用的代码；请参见这里以获取该代码的早期示例版本，并参见这里以获取这个账户代码将要替换的非常相似的validate_transaction代码。

作为对协议层的简化，矿工（或者今天的区块提议者）获得了额外的责任，即运行额外的逻辑，只接受和转发交易，这些交易是发送到实际上支付费用的账户的。那么，这种逻辑是什么？嗯，老实说，EIP-86并没有对此进行过多的思考：

请注意，矿工需要制定接受这些交易的策略。这种策略需要非常歧视性，因为否则他们会面临接受不支付任何费用的交易的风险，甚至可能是没有任何效果的交易（例如，因为交易已经包含，所以nonce不再是当前的）。一个简单的方法是对他们接受发送到的账户的代码哈希值进行白名单处理；经批准的代码将包括支付矿工交易费用的逻辑。然而，这可能过于限制；一种更宽松但仍然有效的策略是接受与上述相同一般格式相符的任何代码，仅消耗有限数量的gas来执行nonce和签名检查，并保证交易费用将支付给矿工。另一种策略是，在其他方法之外，尝试处理任何要求少于 250,000 gas 的交易，并仅在执行交易后矿工的余额适当高于执行之前时才包含它。

账户抽象中的多无效问题。链上包含一个交易可能会使内存池中的成千上万个其他交易无效，从而使内存池容易受到廉价的洪水攻击。

账户抽象从那时起经历了几个阶段的发展。EIP-86 成为了 EIP-208，后来成为了这篇关于“账户抽象提案中的权衡”的 ethresear.ch 帖子，然后在半年后成为了这篇 ethresear.ch 帖子。最终，所有这些努力产生了实际上相当可行的 EIP-2938。

然而，EIP-2938 "一点也不简约"。该 EIP 包括：

一个新的交易类型
三个新的交易范围全局变量
两个新的操作码，包括非常笨重的 PAYGAS 操作码，它处理 gas 价格和 gas 限制检查，是 EVM 执行断点，并临时存储 ETH 以进行费用支付。
一套复杂的挖矿和重新广播策略，包括验证阶段交易的被禁止操作码列表

为了在不牵涉到正忙于优化以太坊客户端并实施合并的以太坊核心开发人员的情况下推动账户抽象，EIP-2938 最终被重新构建为完全基于协议外 ERC-4337。

ERC-4337。它确实完全依赖于 EVM 调用来完成一切！

因为它是一个 ERC，所以不需要硬分叉，并且在技术上“存在于以太坊协议之外”。那么…问题解决了吗？嗯，事实证明并没有。_当前的 ERC-4337 中期路线图实际上确实涉及最终将 ERC-4337 的大部分内容转化为一系列协议特性，这是一个有用的示例，可以看到为什么正在考虑这条路径的原因。

确立 ERC-4337

已经讨论了一些将最终将 ERC-4337 重新纳入协议的关键原因：

Gas efficiency: EVM 中的任何操作都会产生一定程度的虚拟机开销，包括对存储槽等 gas 昂贵特性的低效使用。目前，这些额外的低效性至少会增加约 20,000 gas，通常更多。将这些组件纳入协议是消除这些问题的最简单方法。
代码漏洞风险：如果 ERC-4337 的“入口点合约”存在足够严重的漏洞，所有兼容 ERC-4337 的钱包可能会被全部资金耗尽。用协议内功能替换合约会产生一种隐含的责任，即通过硬分叉修复代码漏洞，从而消除用户资金耗尽的风险。
支持像 tx.origin 这样的 EVM 操作码。单独的 ERC-4337 使 tx.origin 返回打包一组用户操作成交易的“打包者”的地址。本地账户抽象可以通过使 tx.origin 指向实际发送交易的账户来解决这个问题，使其与 EOA 的工作方式相同。
抗审查性：提议者/构建者分离的挑战之一是更容易审查个别交易。在一个世界中，个别交易对以太坊协议是可读的，这个问题可以通过包含列表得到很大程度的缓解，该列表允许提议者指定必须在几乎所有情况下在接下来的两个槽内包含的交易列表。但是，协议外的 ERC-4337 将“用户操作”包装在单个交易中，使得用户操作对以太坊协议不透明；因此，以太坊协议提供的包含列表将无法为 ERC-4337 用户操作提供抗审查性。确立 ERC-4337，并将用户操作作为“正式”的交易类型，将解决这个问题。

进一步探讨 gas 效率问题是值得的。在其当前形式中，ERC-4337 的成本比“基本”的以太坊交易显著更高：交易成本为 21,000 gas，而 ERC-4337 成本约为 42,000 gas。这份文档列出了一些原因：

需要支付大量的单独存储读/写成本，对于 EOA 而言，这些成本被捆绑成一个单独的 21000 gas 支付：

编辑包含公钥+nonce 的存储槽（~5000）

UserOperation calldata 成本（~4500，通过压缩可减少至 ~2500）

ECRECOVER（~3000）

对钱包本身进行预热（~2600）

对接收方账户进行预热（~2600）

将 ETH 转账给接收方账户（~9000）

编辑存储以支付费用（~5000）

访问包含代理的存储槽（~2100），然后访问代理本身（~2600）

除了上述存储读/写成本之外，合约还需要执行“业务逻辑”（解包 UserOperation，对其进行哈希处理，调整变量等），而 EOA 交易则由以太坊协议“免费”处理

需要花费 gas 来支付日志（EOA 不会发出日志）

一次性合约创建成本（~32000 基础费用，加上代理中每个代码字节的 200 gas，再加上设置代理地址的 20000 gas）

理论上，应该可以调整 EVM gas 成本系统，直到协议内成本和访问存储的协议外成本相匹配；在其他种类的存储编辑操作成本更便宜时，转账 ETH 为什么需要花费 9000 gas 也没有理由。事实上，与即将到来的 Verkle 树过渡相关的两个 EIP（[1] [2]）实际上试图做到这一点。但即使我们这样做了，也有一个巨大的原因，即为什么确立的协议功能最终肯定会比 EVM 代码显著便宜：确立的代码不需要支付预加载的 gas。

完全功能的 ERC-4337 钱包是 庞大的。这个实现，编译并上链后，占用了约 12,800 字节。当然，你可以部署这个庞大的代码一次，并使用 DELEGATECALL 允许每个个体钱包调用它，但该代码仍然需要在每个使用它的区块中被访问。根据 Verkle 树 gas 成本 EIP，12800 字节将占据 413 个块，并且访问这些块将需要支付 2 倍的 WITNESS_BRANCH_COST（总共 3800 gas）和 413 倍的 WITNESS_CHUNK_COST（总共 82600 gas）。这甚至还没有提及 ERC-4337 入口点本身，版本 0.6.0 中链上占用了 23,689 字节（根据 Verkle 树 EIP 规则，加载将需要约 158,700 gas）。

这导致了一个问题：实际访问这段代码的 gas 成本必须以某种方式在交易之间进行分配。ERC-4337 目前使用的方法并不理想：捆绑中的第一笔交易会消耗一次性存储/代码读取成本，使其比其他交易显得更加昂贵。在协议中确立这些常用共享库将使其成为协议的一部分，所有人都可以无需支付费用地访问。

从这个例子中，我们可以学到关于何时在协议中确立事物的一般性原则？

在这个例子中，我们看到了在协议中确立账户抽象方面的几种不同原因。

"将复杂性转移到边缘" 基于市场的方法在存在高固定成本时往往会出现问题。事实上，长期的账户抽象路线图看起来将会在每个区块中有很多固定成本。加载标准化钱包代码需要 244,100 gas 是一回事；但是聚合（更多细节请参见我今年夏天的演讲）可能会增加数十万 gas 用于 ZK-SNARK 验证，以及用于证明验证的链上成本。没有办法向用户收取这些成本而不引入大量市场效率低下的问题，而将其中一些功能转化为协议功能，所有人都可以无需支付费用地访问，干净地解决了这个问题。
社区范围内对代码错误的响应。如果某些代码片段被所有用户或者非常广泛的用户类使用，那么区块链社区通常更有意义地承担起责任，进行硬分叉以修复出现的任何错误。ERC-4337 引入了大量全球共享的代码，从长远来看，更有意义的是通过硬分叉修复该代码中的错误，而不是导致用户损失大量 ETH。
有时，可以通过直接利用协议的能力来实现功能的更强形式。这里的关键例子是协议内的抗审查功能，比如包含列表：协议内的包含列表可以更好地保证抗审查，而不是采用协议外的方法，为了使用户级操作真正受益于协议内的包含列表，个体用户级操作需要对协议“可读”。另一个较少为人知的例子是，2017 年的以太坊权益证明设计中有用于权益证明的账户抽象，但这被放弃，而是选择确立 BLS，因为BLS 支持了“聚合”机制，这将必须在协议和网络层面实现，可以使处理大量签名变得更加高效。

但重要的是要记住，即使在协议中确立的账户抽象与现状相比仍然是一种巨大的“去确立”。今天，以太坊的顶层交易只能由外部拥有账户（EOA）发起，其使用单个 secp256k1 椭圆曲线签名进行验证。账户抽象去除了这一限制，并留下了用户定义验证条件的空间。因此，在关于账户抽象的故事中，我们也看到了反对确立的最大论点：对多样化用户需求的灵活性。

让我们尝试进一步填补故事，看看最近考虑确立的一些功能的其他例子。我们将特别关注：ZK-EVMs、提议者-构建者分离、私有内存池、流动权益证明和新的预编译。

确立 ZK-EVMs

让我们把焦点转移到以太坊协议中另一个潜在的确立目标：ZK-EVMs。目前，我们有大量ZK-rollups，它们都必须编写相当相似的代码来验证在 ZK-SNARK 内执行类似以太坊区块。存在着一个相当多样化的独立实现生态系统：PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zeth，等等。

以太坊虚拟机 ZK-rollup 领域最近的一个争议与如何处理 ZK 代码中可能存在的错误有关。目前，所有正在运行的系统都有某种形式的“安全委员会”机制，可以在出现错误的情况下覆盖证明系统。在去年的这篇帖子中，我试图创建一个标准化框架，鼓励项目明确他们对证明系统的信任级别以及对安全委员会的信任级别，并逐渐减少安全委员会的权力。

在中期，Rollups 可能依赖多个证明系统，安全委员会只在两个不同的证明系统发生分歧的极端情况下才具有任何权力。

然而，从某种意义上说，这些工作中的一些部分显得多余。我们已经有了以太坊基础层，其中有一个 EVM，并且我们已经有了处理实现中错误的工作机制：如果存在错误，具有错误的客户端会更新以修复错误，链会继续进行。从有错误的客户端的角度看，看起来已经确认的区块最终会不再被确认，但至少我们不会看到用户损失资金。同样，如果一个 Rollup 只想要成为并保持与 EVM 等效，他们需要实施自己的治理来不断调整其内部 ZK-EVM 规则以匹配以太坊基础层的升级，这似乎是错误的，因为最终他们是在以太坊基础层之上构建的，而以太坊基础层知道何时进行升级以及新规则是什么。

由于这些 L2 ZK-EVM 基本上使用与以太坊相同的 EVM，我们是否可以以某种方式将“在 ZK 中验证 EVM 执行”作为协议功能，并通过应用以太坊的社会共识来处理异常情况，例如错误和升级，就像我们已经为基础层 EVM 执行本身所做的那样呢？

这是一个重要且具有挑战性的话题。有一些微妙之处：

我们希望与以太坊的多客户端哲学兼容。这意味着我们希望允许不同的客户端使用不同的证明系统。这反过来意味着对于任何使用一个 ZK-SNARK 系统证明的 EVM 执行，我们希望能够保证底层数据是可用的，以便其他 ZK-SNARK 系统可以生成证明。
虽然技术还不够成熟，但我们可能希望可审计性。 实际上，这意味着完全相同的事情：如果任何执行被证明，我们希望底层数据是可用的，以便在出现问题时，用户和开发人员可以检查它。
我们需要更快的证明时间，以便如果生成一种类型的证明，其他类型的证明可以被快速生成，以便其他客户端可以验证它们。可以通过制作一个在一段时间窗口之后具有异步响应的预编译来解决这个问题（例如 3 小时），但这会增加复杂性。
我们希望不仅支持 EVM 的副本，还支持“几乎-EVM”。 L2 的吸引力之一是在执行层面进行创新，并对 EVM 进行扩展。如果给定的 L2 的虚拟机与 EVM 仅有一点点不同，那么如果 L2 仍然可以使用本地的协议内 ZK-EVM 来处理与 EVM 相同的部分，并且只依赖于他们自己的代码来处理不同的部分，那将是很好的。这可以通过设计 ZK-EVM 预编译的方式来实现，使调用者能够指定一个位字段或操作码或地址列表，由外部提供的表来处理，而不是由 EVM 本身处理。我们还可以在一定程度上开放燃气成本的定制化。

在本地 ZK-EVM 中数据可用性的一个可能有争议的话题是状态性。如果 ZK-EVM 不必携带“见证”数据，它将更加高效。也就是说，如果某个特定的数据在之前的某个区块中已经被读取或写入，我们可以简单地假设证明者可以访问它，我们就不必再次提供它。这不仅仅是不重新加载存储和代码；事实证明，如果一个 Rollup 正确地压缩数据，那么状态性压缩相比无状态性压缩可以节省高达 3 倍的数据。

这意味着对于 ZK-EVM 预编译，我们有两个选择：

预编译要求所有数据在同一个区块中可用。这意味着证明者可以是无状态的，但也意味着使用这种预编译的 ZK-rollups 比使用自定义代码的 rollups 要昂贵得多。
预编译允许指向之前执行中使用或生成的数据的指针。这允许 ZK-rollups 达到接近最佳状态，但这更加复杂，并引入了一种必须由证明者存储的新类型状态。

我们可以从中得出什么教训？有一个相当充分的论点可以在某种程度上确立 ZK-EVM 验证：rollups 已经在构建它们自己的定制版本，而且让以太坊将其多个实现和链下社会共识的力量放在 L1 上的 EVM 执行背后，但是做完全相同工作的 L2 却必须实施涉及安全委员会的复杂装置，这感觉不对。但另一方面，细节中存在着重大问题：确立的 ZK-EVM 存在不同成本和收益的版本。有状态与无状态的区分只是皮毛；试图支持具有由其他系统证明的自定义代码的“几乎-EVM”可能会揭示更大的设计空间。因此，确立 ZK-EVM 既有前景又面临挑战。

确立提议者-构建者分离（ePBS）

MEV 的兴起使区块生产成为了一个重度规模经济活动，精明的参与者能够生成比简单监视内存池中的交易并包含它们的默认算法产生的收入要多得多的区块。迄今为止，以太坊社区尝试通过使用像MEV-Boost这样的协议外提议者-构建者分离方案来应对这一问题，该方案允许常规验证者（“提议者”）将区块构建外包给专门的参与者（“构建者”）。

然而，MEV-Boost 对一个新类别的参与者，称为中继，存在信任假设。在过去的两年中，已经有许多提案来创建“确立的 PBS”。这有什么好处？在这种情况下，答案非常简单：直接利用协议的权力构建的 PBS 在信任假设上更加强大（意味着信任假设更弱）的PBS，比起没有这些权力的PBS更加强大。这类似于确立协议内价格预言机的情况——尽管在那种情况下，也存在强有力的反对意见。

确立私有内存池

当用户发送交易时，该交易立即变为公开可见，即使在被包含在区块链之前。这使得许多应用程序的用户容易受到经济攻击，比如前置交易：如果用户在 Uniswap 上进行大额交易，攻击者可以在他们之前提交交易，提高他们购买的价格，并获取套利利润。

最近，出现了许多专门创建“私有内存池”（或“加密内存池”）的项目，这些项目会将用户的交易加密，直到它们被不可逆地接受到一个区块中。

然而，问题在于，这类方案需要一种特定类型的加密：为了防止用户淹没系统并在交易解密过程中进行前置交易，加密必须在交易实际被不可逆地接受后自动解密。

要实现这种形式的加密，有各种不同的技术和不同的权衡，Jon Charbonneau 在这篇文章（以及这个视频和幻灯片）中描述得很好：

加密给一个中心化的操作者，例如 Flashbots Protect。
时间锁加密，一种加密形式，可以在一定数量的连续计算步骤之后被任何人解密，这些步骤不能被并行化。
门限加密，信任一个诚实的多数委员会来解密数据。参见shutterized beacon chain 概念，这是一个具体的提案。
可信硬件，比如 SGX。

很遗憾，这些方案都有各种不同的弱点。由于明显的原因，中心化操作者不适合被纳入协议中。传统的时间锁加密在公共内存池中运行成本太高，无法覆盖成千上万的交易。一种更强大的原语称为延迟加密允许有效解密无限数量的消息，但在实践中很难构建，并且对现有构建的攻击有时仍然会被发现。就像哈希函数一样，在延迟加密变得足够成熟之前，我们可能需要更多年的研究和分析。门限加密需要信任大多数人不会勾结，在他们可以无法被察觉地勾结的情况下（不像51%攻击，那种情况下参与者立即显而易见）。SGX 会对单一可信制造商产生依赖。

对于每种解决方案，都有一些用户子集愿意信任它，但没有一种解决方案足够受信任，可以实际被接受到第一层。 因此，在延迟加密被完善或出现其他技术突破之前，将反前置交易固定在第一层似乎是一个困难的提议，即使这是一个非常有价值的功能，很多应用解决方案已经出现。

确立流动权益证明

以太坊 DeFi 用户普遍要求能够同时将他们的 ETH 用于权益证明和作为其他应用程序的抵押品。另一个常见的需求只是为了方便：用户希望能够进行权益证明，而不需要运行节点并始终保持在线（并保护他们现在在线的权益证明密钥）。

迄今为止，满足这些需求最简单的“接口”就是一个 ERC20 代币：将您的 ETH 转换为“锁定的 ETH”，持有它，然后稍后再转换回来。事实上，流动权益证明提供者，如Lido和Rocketpool已经出现来做到这一点。然而，流动权益证明存在一些自然的集中化机制：人们自然而然地选择最大版本的锁定 ETH，因为它最为熟悉、最为流动（并且最受应用程序的支持，而应用程序又支持它，因为它更为熟悉，而且因为大多数用户都听说过它）。

每个版本的锁定 ETH 都需要一些机制来确定谁可以成为基础节点运营商。它不能是无限制的，因为攻击者会加入并利用用户的资金加大攻击。目前，排名前两位的是 Lido，它有一个 DAO 白名单节点运营商，以及 Rocket Pool，它允许任何人运行节点，只要他们存入 8 个 ETH（即资本的四分之一）作为押金。这两种方法都有不同的风险：Rocket Pool 方法允许攻击者对网络进行 51% 攻击，并迫使用户支付大部分成本。而采用 DAO 方法，如果某个权益证明代币占主导地位，那将导致一个单一的、潜在的可攻击的治理机制控制着所有以太坊验证者的很大一部分。要赞扬像 Lido 这样的协议，他们已经实施了防范措施，但一层防御可能不足够。

短期内，一个选择是社会上鼓励生态系统参与者使用多样化的流动权益证明提供者，以减少任何一个单一提供者变得过大而构成系统风险的机会。然而，从长期来看，这是一个不稳定的均衡，过度依赖道德压力来解决问题存在危险。一个自然的问题是：在协议中确立某种功能是否有意义，以使流动权益证明不那么集中化？

在这里，关键问题是：什么样的协议功能？简单地创建一个协议中可交换的“锁定 ETH”代币存在一个问题，那就是它要么必须有一个确立的以太坊全面治理来选择谁运行节点，要么是开放入口，将其变成攻击者的工具。

一个有趣的想法是 Dankrad Feist 关于流动权益证明极端主义的文章。首先，我们要面对的是，如果以太坊遭受 51% 攻击，只有可能有 5% 的攻击 ETH 被削减。这是一个合理的权衡；目前已经有超过 2600 万个 ETH 被锁定，而攻击成本为其中的三分之一（约 800 万个 ETH）是远远过度的，特别是考虑到有多少种“超出模型”的攻击可以用更少的成本实施。事实上，类似的权衡已经在实施单槽终局的"超级委员会"提案中进行了探讨。

如果我们接受只有 5% 的攻击 ETH 会被削减，那么超过 90% 的锁定 ETH 将不会受到削减，因此 90% 的锁定 ETH 可以被放入一个协议中可交换的流动权益证明代币，然后可以被其他应用程序使用。

这条路线很有趣。但仍然留下一个问题：具体会被确立的是什么？RocketPool 已经以一种非常类似的方式运作：每个节点运营商都投入一些资本，而流动权益证明持有者则投入其余部分。我们可以简单地调整一些常数，将最大削减惩罚限制在例如 2 个 ETH，Rocket Pool 的现有 rETH 将变得无风险。就像在 ZK-EVM 的例子中，如果我们可以简单地确立 ZK-EVM 验证的关键硬件部分，而无需确立滚动的概念，那么如果我们可以简单地调整一些协议功能，使现有的锁定 ETH 代币无风险而不依赖于治理机制，那么也许就无需确立整个协议中的锁定 ETH 代币。

确立更多的预编译

预编译（或“预编译合约”）是以太坊合约，实现了复杂的加密操作，其逻辑是在客户端代码中本地实现的，而不是在 EVM 智能合约代码中实现的。预编译是以太坊发展初期采纳的一种妥协：因为虚拟机的开销对于某些非常复杂和高度专业化的代码来说太大，我们可以在本地代码中实现一些对重要类型的应用程序有价值的关键操作，以使它们更快。今天，这基本上包括一些特定的哈希函数和椭圆曲线操作。

目前正在推动添加secp256r1 的预编译，这是一种与用于基本以太坊账户的 secp256k1 稍有不同的椭圆曲线，因为它得到了受信任的硬件模块的良好支持，因此广泛使用它可以提高钱包安全性。近年来，还有推动添加BLS-12-377、BW6-761、广义配对和其他功能的预编译。

对于增加更多预编译的请求的反对意见是，之前添加的许多预编译（例如RIPEMD和BLAKE）最终被使用的程度远低于预期，我们应该从中吸取教训。与其为特定操作添加更多预编译，也许我们应该基于像EVM-MAX和沉寂但始终可复活的SIMD 提案等想法，采取更温和的方法，这将使 EVM 实现能够更便宜地执行广泛类别的代码。甚至甚至可以删除现有但很少使用的预编译，并用（不可避免地效率较低的）EVM 代码实现相同功能来替换。尽管如此，仍然可能存在特定的加密操作，其价值足以加速，因此将它们作为预编译添加是有意义的。

我们从中学到了什么？

希望尽可能少地确立是可以理解和积极的；它源自Unix 哲学传统，即创建极简主义软件，并且可以轻松地适应用户的不同需求，避免软件膨胀的诅咒。然而，区块链不是个人计算操作系统；它们是社会系统。这意味着在协议中确立某些功能存在超越纯个人计算环境中存在的理由。

在许多情况下，这些其他示例重新强调了类似于我们在账户抽象中看到的教训。但也有一些新的教训被学到了。

确立功能可以帮助避免堆栈其他领域的集中化风险。通常，保持基础协议的最小化和简单化会将复杂性推向协议外的生态系统。从 Unix 哲学的角度来看，这是好事。然而，有时存在风险，即协议外的生态系统会出现集中化，通常（但不仅仅）是因为高固定成本。确立有时可以减少实际上的集中化。
确立过多可能会过度扩展协议的信任和治理负担。这是关于早期帖子的主题，讨论了不要过度加载以太坊共识：如果确立特定功能削弱了信任模型，并使以太坊作为一个整体变得更加“主观”，那将削弱以太坊的可信中立性。在这些情况下，最好将特定功能留在以太坊之上的机制，而不是试图将其纳入以太坊本身。在这里，加密 mempool 是可能过于困难确立的最佳例子，至少在延迟加密技术改进之前/除非改进。
确立过多可能会使协议过于复杂。协议复杂性是系统性风险，过多功能的加入会增加这种风险。预编译是最好的例子。
确立可能会在长期内产生逆效果，因为用户的需求是不可预测的。许多人认为重要并且将被许多用户使用的功能在实践中可能并不会被广泛使用。

此外，流动权益、ZK-EVM 和预编译案例显示了一种中间道路的可能性：最小可行确立。与其确立整个功能，协议可以确立解决使该功能易于实现的关键挑战的特定部分，而不会过于主观或狭隘。其中的例子包括：

与其确立完整的流动权益系统，改变权益惩罚规则，使无信任的流动权益更具可行性
与其确立更多预编译，确立EVM-MAX和/或SIMD，使更广泛类别的操作更简单高效地实现
与其确立整个“rollups”概念，我们可以简单地确立 EVM 的“验证”。

我们可以扩展本文早期的图表如下：

有时，甚至可能有意义去“取消确立”一些东西。取消确立很少使用的预编译就是一个例子。正如之前提到的，账户抽象作为一个整体也是一种重要的取消确立形式。如果我们希望为现有用户提供向后兼容性，那么机制实际上可能会出人意料地与取消确立预编译的机制非常相似：其中一个提案是EIP-5003，该提案将允许外部拥有账户将其账户在原地转换为具有相同（或更好）功能的合约。

应该将哪些功能纳入协议，哪些功能应该留给生态系统的其他层面，这是一个复杂的权衡，我们应该期望这种权衡会随着我们对用户需求的理解和我们可用的想法和技术组合的不断改进而继续发展。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。