Vitalik Buterin：协议设计中的封装复杂性和系统复杂性权衡
Kyle作者：Vitalik Buterin，原文来源：vitalik.ca?
以太坊协议设计的主要目标之一是最小化复杂性：使协议尽可能简单，同时仍然使区块链能够完成一条有效区块链需要做的事情。 以太坊协议在这方面远非完美，尤其是因为它的大部分是在 2014-16 年设计的，当时我们对它的了解要少得多，但我们仍然尽可能地积极努力降低复杂性。
然而，这一目标的挑战之一是复杂性是难以定义的，有时，您必须在两种选择之间进行权衡，这两种选择会引入不同类型的复杂性并具有不同的代价。 我们如何比较？
允许对复杂性进行更细致入微的思考的一种强大的智力工具是区分我们称之为封装复杂性和系统复杂性的东西。
当一个系统具有内部复杂的子系统但对外提供一个简单的“接口”时，就会出现封装复杂性。 当一个系统的不同部分甚至不能完全分开并且彼此之间具有复杂的相互作用时，就会出现系统复杂性。
下面有一些例子。
BLS 签名与 Schnorr 签名
BLS 签名和 Schnorr 签名是可以用椭圆曲线制作的两种流行的加密签名方案类型。
BLS 签名在数学上看起来非常简单：
签署：
验证：
H是一个哈希函数，m是消息，k和K是私钥和公钥。 到这里为止，看起来都很简单。 然而，真正的复杂性隐藏在e函数的定义中：椭圆曲线配对，这是所有密码学中最难理解的数学题之一。
现在，再看看Schnorr 签名。 Schnorr 签名仅依赖于基本的椭圆曲线。 但是签名和验证逻辑要复杂一些：
那么......哪种类型的签名“更简单”？ 这取决于你关心什么！ BLS 签名具有巨大的技术复杂性，但复杂性都隐藏在e函数的定义中。 如果将e函数视为黑盒，BLS 签名实际上非常简单。 另一方面，Schnorr 签名的总体复杂性较低，但它们有更多可能以棘手的方式与外部世界交互的部分。
例如：
进行一个BLS 多重签名（来自两个密钥k1和k2的组合签名）很容易：只需
。但是 Schnorr 多重签名需要两轮交互，并且需要处理棘手的密钥取消攻击。
Schnorr 签名需要随机数生成，BLS 签名不需要。
椭圆曲线配对就像是一个强大的“复杂性海绵”，因为它们包含大量封装的复杂性，但可以实现系统复杂性低得多的解决方案。 在多项式承诺领域也是如此：将 KZG 承诺的简单性（需要配对）与内积参数的更复杂的内部逻辑（不需要）进行比较。
密码学与密码经济学
许多区块链设计中出现的一个重要设计选择是密码学与密码经济学的选择。通常（例如在Rollup中）这以在有效性证明（又名 ZK-SNARK）和欺诈证明之间进行选择的形式出现。
ZK-SNARK是一种复杂的技术。虽然可以在一篇文章中解释它们如何工作背后的基本思想，但实际上实现 ZK-SNARK来验证某些计算所涉及的复杂性是计算本身的许多倍（因此，为什么用于 EVM 的 ZK-SNARK仍在开发中，而用于EVM的欺诈证明已经在测试中）。有效地实施 ZK-SNARK 涉及具有特殊目的优化的电路设计、使用不熟悉的编程语言以及许多其他挑战。另一方面，欺诈证明本质上很简单：如果有人提出挑战，您只需直接在链上运行计算。为了提高效率，有时会添加二进制搜索方案，但即使这样也不会增加太多复杂性。
但是，虽然 ZK-SNARK 很复杂，但它们的复杂性是封装的复杂性。另一方面，欺诈证明的相对简单的复杂性是系统性的。以下是欺诈证明引入的系统复杂性的一些示例：
- 他们需要谨慎的激励工程来避免验证者的困境。
- 如果在达成共识的情况下完成，他们需要额外的交易类型来证明欺诈，以及推理如果许多参与者竞争同时提交欺诈证明会发生什么。
- 它们依赖于同步网络。
- 它们允许审查攻击被用来提交盗窃行为。
- 基于欺诈证明的Rollup要求流动性提供者支持即时提款。
由于这些原因，即使从复杂性的角度来看，基于 ZK-SNARKs 的纯加密解决方案也可能长期更安全：ZK-SNARKs 存在一些人必须考虑的更复杂的部分，但它们存在更少的每个人不得不考虑的悬而未决警告。
其他示例
- 工作量证明（中本聪共识）——低封装复杂度，因为机制极其简单易懂，但系统复杂度更高（例如自私挖矿攻击）。
- 哈希函数——高封装复杂性，但非常易于理解的属性，因此系统复杂性低。
- 随机洗牌算法——洗牌算法可能内部复杂（如在 Whisk 中）但导致易于理解的强随机性保证，或者内部更简单但导致更弱且更难以分析的随机性属性（系统复杂性）。
- 矿工可提取价值（MEV）——一个强大到足以支持复杂交易的协议在内部可能相当简单，但这些复杂的交易可能会对协议的激励产生复杂的系统性影响，因为它有助于以非常不规则的方式提出区块的激励。
- Verkle 树——Verkle 树确实有一些封装的复杂性，实际上比普通的 Merkle 哈希树要复杂得多。 然而，从系统上讲，Verkle 树呈现出与密钥值映射完全相同的相对简洁的界面。 主要的系统复杂性“泄漏”是攻击者操纵树以使特定值具有非常长的分支的可能性； 但是对于 Verkle 树和 Merkle 树，这种风险是相同的。
我们如何进行权衡？
通常，封装复杂度较低的选择也是系统复杂度较低的选择，因此有一个选择显然更简单。 但在其他时候，您必须在一种复杂性和另一种复杂性之间做出艰难的选择。 在这一点上应该清楚的是，如果将复杂性封装起来，那么它的危险性就会降低。 系统复杂性带来的风险并不是规范有多长的简单函数； 与其他部分交互的一个小的10行规范比原本被视为黑匣子的一个100 行函数增加了更多的复杂性。
然而，这种偏好封装复杂性的方法存在局限性。 软件错误可能出现在任何一段代码中，并且随着它变得越来越大，错误的概率接近 1。有时，当您需要以一种意想不到的新方式与子系统交互时，最初封装的复杂性可能会变得系统化。
后者的一个例子是以太坊当前的两级状态树，它具有一棵账户对象树，其中每个账户对象又拥有自己的存储树。
这种树结构很复杂，但一开始复杂性似乎得到了很好的封装：协议的其余部分与树交互，作为您可以读取和写入的密钥/值存储，因此我们不必担心关于树的结构。
然而，后来证明复杂性产生了系统性影响：账户拥有任意大存储树的能力意味着无法可靠地期望状态的特定部分（例如，“所有以 0x1234 开头的账户”） 有一个可预测的大小。 这使得将状态拆分为多个部分变得更加困难，从而使同步协议的设计和尝试分配存储过程变得复杂。 为什么封装的复杂性会变成系统性的？ 因为接口变了。 修复？ 当前迁移到 Verkle 树的提议还包括迁移到一种平衡良好的树的单层设计。
最终，在任何给定情况下支持哪种类型的复杂性是一个没有简单答案的问题。 我们能做的最好的事情就是保持适度支持封装复杂性的态度，但不要过多，并在每个具体情况下行使我们的判断力。 有时，牺牲一点系统复杂性来大幅降低封装的复杂性确实是最好的做法。 在其他时候，您甚至可能会误判什么是封装的，什么不是。 每种情况都不同。
