乙太坊維護其安全性和去中心化的一種未被充分討論但非常重要的方式是其多用戶端理念
原文：How will Ethereum's multi-client philosophy interact with ZK-EVMs？ （vitalik.eth）
編譯： Kyle，DeFi 之道
封面：zkEVM
特別感謝 Justin Drake 的反饋和審閱。
乙太坊維護其安全性和去中心化的一種未被充分討論但非常重要的方式是其多用戶端理念。 乙太坊有意沒有預設情況下每個人都運行的「參考用戶端」：相反，有一個協作管理的規範（目前是用非常易讀但非常慢的 Python 編寫的）並且有多個團隊實現規範（也稱為 “用戶端”），這是用戶實際運行的。
每個乙太坊節點運行一個共識用戶端和一個執行用戶端。 截至今天，沒有那個共識或執行用戶端占網路的 2/3 以上。 如果在其類別中份額低於 1/3 的用戶端出現錯誤，則網路將照常運行。 如果在其類別中佔有 1/3 到 2/3 份額的客戶（例如 Prysm、Lighthouse 或 Geth）出現錯誤，鏈將繼續添加區塊，但它會停止敲定（finalizing）區塊，從而為開發人員提供時間進行干預。
一個未被充分討論但非常重要的即將到來的乙太坊鏈驗證方式的重大轉變是 ZK-EVM 的興起。 用於證明 EVM 執行的 SNARK 已經開發多年，並且該技術正被稱為 ZK rollup 的第 2 層協定積極使用。 其中一些 ZK rollup 今天在主網上很活躍，很快就會有更多。 但從長遠來看，ZK-EVM 不僅僅用於 rollup; 我們也想使用它們來驗證第 1 層的執行情況（另請參閱：The Verge）。
一旦發生這種情況，ZK-EVM 實際上成為第三種類型的乙太坊用戶端，對網路安全的重要性與當今的執行客戶端和共識用戶端一樣重要。 這自然會提出一個問題：ZK-EVM 將如何與多用戶端理念交互？ 困難的部分之一已經完成：我們已經有多個正在積極開發的 ZK-EVM 實現。 但其他困難的部分仍然存在：我們如何真正為 ZK 證明乙太坊區塊的正確性創建一個「多用戶端」生態系統？ 這個問題提出了一些有趣的技術挑戰——當然還有權衡是否值得的迫在眉睫的問題。
乙太坊多用戶端理念的最初動機是什麼？
乙太坊的多用戶端哲學是一種去中心化，就像一般的去中心化一樣，人們可以關注架構去中心化的技術收益或政治去中心化的社會收益。 最終，多客戶理念受到雙方的推動併為雙方服務。
技術去中心化的論據
技术去中心化的主要好处很简单：它降低了一个软件中的一个错误导致整个网络灾难性崩溃的风险。 2010 年的比特币溢出漏洞就是一个例证这种风险的历史情况。 当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过总和超过最大整数 2^64-1 回绕到零，所以有人做了一个交易，正是这样做的， 给自己生产了数十亿枚的比特币。这个漏洞在几个小时内就被发现了，并迅速通过修复并在整个网络上部署，但如果当时有一个成熟的生态系统，这些币就会被交易所、桥梁和其他结构所接受 , 并且攻击者可能已经套取了很多钱。如果有五个不同的比特币客户端，他们不太可能都有相同的错误，因此会立即分裂，并且出现 bug 的 链分裂的那一边可能会输。
使用多客户端方法来最小化灾难性错误的风险需要权衡：相反，您会遇到共识失败错误。 也就是说，如果您有两个客户端，则存在客户端对某些协议规则有细微不同解释的风险，虽然两种解释都是合理的并且不允许偷钱，但分歧会导致链分裂成两半。 这种类型的严重分裂在以太坊的历史上发生过一次（还有其他更小的分裂，其中运行旧版本代码的网络的很小一部分被分叉了）。 单一客户端方法的捍卫者将共识失败作为不具有多个实现的原因：如果只有一个客户端，则该客户端不会不同意自己。 他们关于客户端数量如何转化为风险的模型可能如下所示：
我当然不同意这种分析。 我不同意的症结在于 (i) 2010 年的灾难性错误也很重要，并且 (ii) 你实际上永远不会只有一个客户端。 后一点在 2013 年的比特币分叉中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧而发生了链分裂，其中一个版本意外地限制了在单个块中进行修改的可以访问的对象数量。 因此，理论上一个客户端在实践中通常是两个客户端，理论上五个客户在实践中可能是六个或七个客户端 – 所以我们应该冒险并走在风险曲线的右侧，并且至少有几个不同的客户端。
政治去中心化的论点
垄断客户端开发人员处于拥有大量政治权力的位置。 如果客户端开发人员提出更改，而用户不同意，理论上他们可以拒绝下载更新版本，或者在没有它的情况下创建一个分支，但实际上用户通常很难做到这一点。 如果不愉快的协议更改与必要的安全更新捆绑在一起怎么办？ 如果主要团队威胁说如果他们不按他们的方式行事就退出怎么办？ 或者，更温和地说，如果垄断客户端团队最终成为唯一拥有最强大协议专业知识的群体，而使生态系统的其他部分处于不利地位，无法判断客户端团队提出的技术论点，从而使客户端团队面临有很大的空间来推动他们自己的特定目标和价值观，而导致可能与更广泛的社区不匹配？
对协议政治的担忧，特别是在 2013-14 比特币 OP_RETURN 战争的背景下，一些参与者公开支持歧视链的特定用途，是以太坊早期采用多客户端哲学的重要促成因素，这旨在让一小部分人更难做出此类决定。 以太坊生态系统特有的担忧——即避免权力集中在以太坊基金会内部——为这一方向提供了进一步的支持。 2018 年，基金会决定有意不实施以太坊 PoS 协议（即现在所谓的 “共识客户端”），将该任务完全留给外部团队。
未来 ZK-EVM 将如何进入第 1 层？
如今，ZK-EVM 用于 rollup。 这通过允许昂贵的 EVM 执行仅在链下发生几次来增加扩展性，而其他人只需验证链上发布的 SNARKs 即可证明 EVM 执行计算正确。 它还允许一些数据（特别是签名）不包含在链上，从而节省 gas 成本。 这给了我们很多可扩展性的好处，可扩展计算与 ZK-EVM 和可扩展数据与数据可用性采样的结合可以让我们扩展得更远。
然而，今天的以太坊网络也有一个不同的问题，一个再多的 layer 2 扩容也无法自行解决的问题：layer 1 难以验证，以至于没有多少用户运行自己的节点。 相反，大多数用户只是信任第三方提供商。 Helios 和 Succinct 等轻客户端正在采取措施解决这个问题，但轻客户端远非完全验证节点：轻客户端仅验证称为同步委员会的随机验证者子集的签名，并不验证该链实际上遵循协议规则。 为了让我们进入一个用户可以实际验证链是否遵守规则的世界，我们必须做一些不同的事情。
选项 1：限制第 1 层，强制几乎所有活动移动到第 2 层
随着时间的推移，我们可以将第 1 层每个区块的 gas 目标从 1500 万减少到 100 万，足以让一个区块包含一个 SNARK 和一些存款和取款操作，但其他的不多，从而强制几乎所有用户活动移动到第 2 层协议。 这样的设计仍然可以支持在每个块中提交许多 rollup：我们可以使用由定制构建器运行的链下聚合协议来从多个第 2 层协议收集 SNARK，并将它们组合成一个 SNARK。 在这样的世界中，第 1 层的唯一功能是成为第 2 层协议的交换所，验证它们的证据并偶尔促进它们之间的大笔资金转移。
这种方法可能有效，但它有几个重要的弱点：
- 它实际上是向后不兼容的，因为许多现有的基于 L1 的应用程序在经济上变得不可行。 拥有数百或数千美元资金的用户可能会陷入困境，因为费用变得如此之高，以至于超过了清空这些账户的成本。 这可以通过让用户签署消息以选择协议内大规模迁移到他们选择的 L2 来解决（参见此处的一些早期实施想法），但这增加了过渡的复杂性，让它真正足够便宜无论如何都需要在第 1 层使用某种 SNARK。 当涉及到 SELFDESTRUCT 操作码之类的东西时，我通常喜欢打破向后兼容性，但在这种情况下，权衡似乎不太有利。
- 它可能仍然无法使验证变得足够便宜。 理想情况下，以太坊协议应该不仅在笔记本电脑上而且在手机、浏览器扩展程序甚至其他链中都应该易于验证。 第一次同步链，或者长时间离线后，应该也很容易。 笔记本电脑节点可以在大约 20 毫秒内验证 100 万 gas，但即使这样也意味着在离线一天后需要 54 秒进行同步（假设单时隙最终性将时隙时间增加到 32 秒），而对于手机或浏览器扩展，则需要几百毫秒每个块，并且可能仍然是不可忽略的电池消耗。 这些数字是可控的，但并不理想。
- 即使在 L2 优先的生态系统中，L1 至少在某种程度上可以负担得起也是有好处的。 如果用户在注意到新的状态数据不再可用时可以提取资金，Validiums 可以从更强大的安全模型中受益。 如果经济上可行的跨 L2 直接转移的最小规模较小，套利将变得更加有效，尤其是对于较小的代币。
因此，尝试找到一种使用 ZK-SNARKs 来验证第 1 层本身的方法似乎更合理。
选项 2：SNARK-验证第 1 层
Type 1（完全等效于以太坊）ZK-EVM 可用于验证（第 1 层）以太坊块的 EVM 执行。 我们可以编写更多的 SNARK 代码来验证区块的共识方面。 这将是一个具有挑战性的工程问题：今天，ZK-EVM 需要几分钟到几小时来验证以太坊区块，并且实时生成证明需要一个或多个（i）改进以太坊本身以删除对 SNARK 不友好的组件，（ii）) 要么通过专门的硬件获得巨大的效率提升，要么 (iii) 通过更多的并行化改进架构。 然而，没有根本的技术原因不能做到这一点——所以我预期，即使需要很多年，它也会完成。
这是我们看到与多客户端范例的交集的地方：如果我们使用 ZK-EVM 来验证第 1 层，我们使用哪个 ZK-EVM？
我看到三个选项：
（1）单一 ZK-EVM：放弃多客户端范式，选择我们用来验证区块的单一 ZK-EVM。
（2）封闭式多 ZK-EVM：就一组特定的多个 ZK-EVM 达成一致并达成共识，并有一个共识层协议规则，即一个区块需要来自该集合中超过一半的 ZK-EVM 的证明才能被认为是有效的。
（3）开放式多 ZK-EVM：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个块为有效之前等待与自己的实现兼容的证明。
对我来说，（3）似乎是理想的，至少直到并且除非我们的技术改进到我们可以正式证明所有 ZK-EVM 实现彼此等效的程度，此时我们可以选择哪个高效的。 (1) 会牺牲多客户端范式的好处，并且 (2) 会关闭开发新客户端的可能性并导致更加集中的生态系统。 (3) 有挑战，但这些挑战似乎比其他两个选项的挑战要小，至少目前是这样。
实施 (3) 不会太难：每个类型的证明可能都有一个 p2p 子网络，使用一种类型证明的客户端将监听相应的子网络并等待直到他们收到他们的验证者认为有效的证明。
(3) 的两个主要挑战可能如下：
- 延迟挑战：恶意攻击者可能会延迟发布一个块，以及对一个客户端有效的证明。 生成对其他客户有效的证明实际上需要很长时间（即使例如 15 秒）。 这段时间足够长，可能会创建一个临时分叉并中断几个插槽的链。
- 数据效率低下：ZK-SNARKs 的一个好处是可以从块中删除仅与验证相关的数据（有时称为 “见证数据”）。 例如，一旦你验证了一个签名，你就不需要将签名保存在一个块中，你可以只存储一个表示签名有效的位，以及区块中确认所有签名的单个证明。 存在有效签名。 但是，如果我们希望能够为一个块生成多种类型的证明，则需要实际发布原始签名。
在设计单时隙最终协议时要小心，可以解决延迟挑战。 单时隙最终协议可能需要每个时隙超过两轮的共识，因此可能需要第一轮包含区块，并且只需要节点在第三轮（或最后一轮）签署之前验证证明。 这确保了在发布区块的截止日期和预计证明可用的时间之间始终有一个重要的时间窗口可用。
数据效率问题必须通过单独的协议来 rollup 与验证相关的数据来解决。 对于签名，我们可以使用 ERC-4337 已经支持的 BLS 聚合。 另一大类与验证相关的数据是用于隐私的 ZK-SNARKs。 幸运的是，这些往往有自己的聚合协议。
还值得一提的是，SNARK 验证第 1 层有一个重要的好处：链上 EVM 执行不再需要由每个节点验证这一事实使得可以大大增加发生的 EVM 执行量。 这可以通过大幅增加第 1 层 gas 限制或引入 enshrined rollup 或两者兼而有之。
结论
使一個開放的多用戶端 ZK-EVM 生態系統運行良好需要大量的工作。 但真正的好消息是，這項工作的大部分正在發生或無論如何都會發生：
- 我們已經有多個強大的 ZK-EVM 實現。 這些實現還不是類型 1（完全等同於乙太坊），但其中許多正在積極朝著這個方向發展。
- 在 Helios 和 Succinct 等輕用戶端上的工作最終可能會變成對乙太坊鏈的 PoS 共識端進行更全面的 SNARK 驗證。
- 客戶可能會開始嘗試使用 ZK-EVM 來證明自己的乙太坊塊執行，特別是當我們有無狀態客戶端並且沒有技術需要直接重新執行每個區塊來維護狀態時。 我們可能會從客戶端通過重新執行它們來驗證乙太坊區塊，過渡到大多數客戶端通過檢查 SNARK 證明來驗證乙太坊區塊。
- ERC-4337 和 PBS 生態系統可能會很快開始使用 BLS 和證明聚合等聚合技術，以節省 gas 成本。 關於 BLS 聚合，工作已經開始。
有了這些技術，未來看起來非常美好。 乙太坊區塊會比今天更小，任何人都可以在他們的筆記型電腦甚至他們的手機或瀏覽器擴展程式中運行一個完全驗證的節點，這一切都會發生，同時保留乙太坊多用戶端理念的好處。
從長遠來看，當然任何事情都有可能發生。 也許 AI 會加強形式驗證，使其可以輕鬆證明 ZK-EVM 實現等效並識別導致它們之間差異的所有錯誤。 這樣的專案甚至可能是現在就開始著手的實用專案。 如果這種基於核查的正式方法取得成功，則需要建立不同的機制以確保該議定書的政治權力下放持續進行; 也許到那時，協定將被視為「完整的」，不變性規範將更加強大。 但即使這是更長遠的未來，開放的多用戶端 ZK-EVM 世界似乎也是一個天然的墊腳石，無論如何都有可能發生。
從短期來看，這仍然是一段漫長的旅程。 ZK-EVM 就在這裡，但 ZK-EVM 在第 1 層真正可行將需要它們成為 Type 1，並使證明足夠快以使其可以實時發生。 有了足夠的並行化，這是可行的，但要實現這一點仍然需要做很多工作。 共識變化，如提高 KECCAK、SHA256 和其他哈希函數預編譯的 gas 成本，也將是重要組成部分。 也就是說，過渡的第一步可能比我們預期的要早：一旦我們切換到 Verkle 樹和無狀態用戶端，用戶端就可以開始逐漸使用 ZK-EVM，並且可以過渡到「開放的多 ZK-EVM」世界 開始自行發生。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
