路安
Vitalik：协议设计中的“封装复杂性”vs.“系统复杂性”
原文作者：VitalikButerin，以太坊联合创始人
南风
以太坊协议设计的主要目标之一是最小化复杂性：使协议尽可能简单，区块链仍然可以做一个有效的区块链网络需要做的事情。以太坊协议在这方面远不完美，特别是因为它的许多部分都在 2014年-16 年设计的，当时我们对它的理解要少得多，但我们仍然在尽可能地积极努力降低复杂性。然而，这个目标的挑战之一是复杂性很难定义，且有时，你必须在两个引入不同种类复杂性和具有不同代价的选择之间进行权衡。我们如何比较？
有一个强大的智能工具可以让我们更仔细地思考复杂性，即区分所谓的包装复杂性(encapsulated complexity) 和系统复杂性(systemic complexity)。
当系统的子系统内部复杂时，向外部呈现一个简单的接口 (interface) 出现的时候「封装复杂性」。当系统的不同部分甚至不能清楚地分开，并且相互交互复杂时，「系统复杂性」就出现了。
以下是几个例子。
BLS 签名 vs. Schnorr签名BLS 签名和Schnorr 签名是由椭圆曲线组成的两种常用加密签名方案。
BLS 数学上的签名看起来很简单：
H是哈希函数，m是消息，k和K是私钥和公钥。到目前为止，这很简单。然而，真正的复杂性隐藏在隐藏之中e函数定义：椭圆曲线配对(elliptic curve pairings)，这是所有密码学中最难理解的数学部分之一。
现在，让我们来看看 Schnorr 签名。Schnorr 签名仅依赖于基本的椭圆曲线。但签名和验证逻辑有点复杂：
所以…哪种签名更简单？这取决于你在乎什么！BLS 签名具有巨大的技术复杂性，但复杂性隐藏在其中e在函数的定义中。假如你把e函数被视为黑盒，BLS 签名其实很简单。另一方面，Schnorr 签名的整体复杂性较低，但更多的部分可以以微妙的方式与外部世界互动。
例如：
进行 BLS 多签 (两个密钥 k1 和 k2 组合签名) 很简单:只要 σ1 σ2。但是 Schnorr 多签名需要两轮交互，需要处理一些困难Key Cancellation 攻击。Schnorr 签名需要生成随机数，BLS 不需要签名。椭圆曲线配对通常是一种强大的复杂海绵，因为它包含大量的包装复杂性，但使解决方案具有较少的系统复杂性。这也适用于多项承诺领域：将KZG 承诺(需要匹配) 的简单性和更复杂的内积证明 (inner product arguments，不需要配对) 比较内部逻辑。
密码学 vs. 加密经济学密码学 是许多区块链设计中的一个重要设计选择(cryptography) 加密经济学 (cryptoeconomics) 比较。这个 (比如在 Rollups 中) 常在有效性证明(即 )ZK-SNARKs) 和欺诈证明之间做出选择。
ZK-SNARKs 是一项复杂的技术。尽管 ZK-SNARKs 工作原理背后的基本思路可以在一篇文章中解释清楚，但实际上实现了 ZK-SNARK 来验证一些计算涉及比计算本身多很多倍的复杂性 (因此，这就是为什么用于 EVM 的 ZK-SNARKs 证明仍在开发中，用于 EVM 欺诈证书已处于测试阶段)。有效实现一个ZK-SNARK 证书包括优化特殊目的的电路设计、使用不熟悉的编程语言和许多其他挑战。另一方面，欺诈证书本身很简单：如果有人提出挑战，你只需要直接在链上运行计算。为了提高效率，有时会添加二进制搜索计划，但即便如此，也不会增加太多的复杂性。
虽然 ZK-SNARKs 很复杂，但它们的复杂性是包装的复杂性。另一方面，欺诈证书的相对较低的复杂性是系统的复杂性。以下是欺诈证书引入的一些系统复杂性的例子：
他们需要仔细激励项目，以避免验证人的困境。如果达成共识，他们需要为欺诈证书提供额外的交易类型，并考虑如果许多参与者竞相提交欺诈证书会发生什么。它们依赖于一个同步网络。它们允许审查攻击 (censorship attacks) 也用于盗窃。 基于欺诈证明Rollups 要求流动性提供者支持即时提款。由于这些原因，即使从复杂性的角度来看，也是基于 ZK-SNARKs 纯加密解决方案也可能是长期安全的：ZK-SNARKs 有更复杂的部分，有些人在选择 ZK-SNARKs 时必须考虑；但 ZK-SNARKs 悬空警告较少，这是每个人都必须考虑的。
各种例子PoW(中本聪共识):包装复杂性低，因为机制简单易懂，但系统复杂性高 (如自私挖掘攻击)。哈希函数:包装复杂性高，但属性容易理解，系统复杂性低。随机洗牌算法：洗牌算法可以是内部复杂 (例如Whisk)，但能保证强大的随机性，易于理解；也可以是内部简单但能产生弱且难以分析的随机性属性 (如系统复杂性)。矿工提取价值 (MEV)：足以支持复杂的事务(complex transactions)协议内部可能相当简单，但这些复杂的事务可能会对协议的激励机制产生复杂的系统影响，因为它们会以非常异常的方式提出块。Verkle 树：Verkle 树确实有一些复杂的包装，实际上比普通 更复杂Merkle 哈希树要复杂得多。然而，从系统上讲，Verkle 树提供键值 (key-value) 相对干净简单的界面映射完全相同。主要系统复杂性泄漏 (leak) 是攻击者操纵 Verkle 树使一个特定值有一个非常长的分支 (branch) 的可能性；但 Verkle 树和 Merkle 树的风险是一样的。如何权衡？一般来说，包装复杂性较低的选择也是系统复杂性较低的选择，所以有一个显然更简单的选择。但在其他时候，你必须在一种复杂性和另一种复杂性之间做出艰难的选择。在这一点上，应该清楚的是，如果会更低。系统复杂性带来的风险不是一个简单的规范长度函数；一个 10 行代码的小片段比 100 行代码的函数更复杂，否则将被视为黑盒。
然而，这种偏好包装复杂性的方法是有限的。软件 可能出现在任何代码中bugs，当代码越来越大时，错误的概率接近 1。有时，当你需要以意想不到的新方式与子系统交互时，原始的包装复杂性可能会变成系统复杂性。
后者的一个例子是以太坊目前的两级状态树 (two-level state tree)，其特点是账户对象树，其中每个账户对象都有自己的存储树。
树的结构很复杂，但一开始，它似乎被包装得很好：协议的其他部分作为可读写键/值存储与树交互，因此我们不必担心树是如何构造的。
然而，这种复杂性后来被证明是系统性的：账户有任何大型存储树的能力，这意味着没有办法可靠地期望特定状态部分 （例如，所有 0x1234 开头的账户) 大小可预测。这使得将状态分成多个部分更加困难，同步协议的设计和分布存储过程的尝试更加复杂。为什么包装的复杂性变得系统化？因为 interface 变了。解决方案是什么？目前转向 Verkle 树的建议还包括转向平衡的单层树设计。
最后，在任何给定的情况下，没有简单的答案，哪种类型的复杂性更受欢迎。我们能做的最好的事情是适度支持包装的复杂性，但不要太多，并在每个具体情况下练习我们的判断。有时，牺牲一点系统的复杂性来大大降低包装的复杂性确实是最好的方法。在其他时候，你甚至会误判什么是包装，什么不是。每种情况都是不同的。
- 免责声明
- 世链财经作为开放的信息发布平台，所有资讯仅代表作者个人观点，与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论，请提供相关材料，发送到：2785592653@qq.com。
- 风险提示：本站所提供的资讯不代表任何投资暗示。投资有风险，入市须谨慎。
- 世链粉丝群：提供最新热点新闻，空投糖果、红包等福利，微信：juu3644。
