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