一般来说，包装复杂性较低的选择也是系统复杂性较低的选择，所以有一个显然更简单的选择。但在其他时候，你必须在一种复杂性和另一种复杂性之间做出艰难的选择。在这一点上，应该清楚的是，如果会更低。系统复杂性带来的风险不是一个简单的规范长度函数；一个 10 行代码的小片段比 100 行代码的函数更复杂，否则将被视为黑盒。

然而，这种偏好包装复杂性的方法是有限的。软件 可能出现在任何代码中bugs，当代码越来越大时，错误的概率接近 1。有时，当你需要以意想不到的新方式与子系统交互时，原始的包装复杂性可能会变成系统复杂性。

后者的一个例子是以太坊目前的两级状态树 (two-level state tree)，其特点是账户对象树，其中每个账户对象都有自己的存储树。

树的结构很复杂，但一开始，它似乎被包装得很好：协议的其他部分作为可读写键/值存储与树交互，因此我们不必担心树是如何构造的。

然而，这种复杂性后来被证明是系统性的：账户有任何大型存储树的能力，这意味着没有办法可靠地期望特定状态部分 （例如，所有 0x1234 开头的账户) 大小可预测。这使得将状态分成多个部分更加困难，同步协议的设计和分布存储过程的尝试更加复杂。为什么包装的复杂性变得系统化？因为 interface 变了。解决方案是什么？目前转向 Verkle 树的建议还包括转向平衡的单层树设计。

最后，在任何给定的情况下，没有简单的答案，哪种类型的复杂性更受欢迎。我们能做的最好的事情是适度支持包装的复杂性，但不要太多，并在每个具体情况下练习我们的判断。有时，牺牲一点系统的复杂性来大大降低包装的复杂性确实是最好的方法。在其他时候，你甚至会误判什么是包装，什么不是。每种情况都是不同的。