作者：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 樹的提議還包括遷移到一種平衡良好的樹的單層設計。
最終，在任何給定情況下支持哪種類型的復雜性是一個沒有簡單答案的問題。 我們能做的最好的事情就是保持適度支持封裝復雜性的態度，但不要過多，並在每個具體情況下行使我們的判斷力。 有時，犧牲一點系統復雜性來大幅降低封裝的復雜性確實是最好的做法。 在其他時候，您甚至可能會誤判什麼是封裝的，什麼不是。 每種情況都不同。