公众呺：Web3团子
以太坊是世界上最受欢迎的区块链网络之一，以其智能合约功能和去中心化应用程序 (dApps) 而闻名。以太坊维护其安全性和去中心化的方式之一是通过其多客户端理念。
与其他区块链网络不同，以太坊没有每个人都默认运行的默认“参考客户端”。相反，有一个协作管理的规范，用人类可读性强但速度非常慢的 Python 语言编写，多个团队实现规范，称为“客户端”，这是用户实际运行的。
每个以太坊节点运行一个共识客户端和一个执行客户端。目前，没有共识或执行客户端占网络的 2/3 以上。这意味着如果在其类别中份额低于 1/3 的客户端出现错误，网络将照常运行。如果在其类别中拥有 1/3 到 2/3 份额的客户有错误，链将继续添加块，但它会停止敲定块，从而为开发人员提供时间进行干预。
以太坊链验证方式即将发生的一个重大转变是 ZK-EVM 的兴起。证明 EVM（以太坊虚拟机）执行的 SNARK 已经开发多年，该技术正被称为 ZK 汇总的第 2 层协议积极使用。这些 ZK 汇总今天在主网上很活跃，很快就会有更多。从长远来看，ZK-EVM 不仅仅用于汇总；它们也将用于验证第 1 层的执行情况。一旦发生这种情况，ZK-EVM 实际上成为第三种类型的以太坊客户端，对网络安全的重要性与当今的执行客户端和共识客户端一样重要。
然而，这种转变引发了一些有趣的问题，即 ZK-EVM 将如何与多客户端理念交互。困难的部分之一已经完成：正在积极开发多个 ZK-EVM 实现。但其他困难的部分仍然存在：我们如何真正为 ZK 证明以太坊区块的正确性创建一个“多客户端”生态系统？这个问题提出了一些有趣的技术挑战——当然，还有一个迫在眉睫的问题，即权衡是否值得。
ZK-EVM，或零知识以太坊虚拟机，用于汇总以通过使昂贵的 EVM 执行仅在链外发生几次来增加扩展性。其他人只需验证链上发布的 SNARK，以证明 EVM 执行计算正确。
这也允许一些数据，特别是签名，不包含在链上，从而节省 gas 成本。将可扩展计算与 ZK-EVM 以及可扩展数据与数据可用性采样相结合，可能会带来显着的扩展优势。然而，以太坊网络在验证第 1 层时面临困难，因为在第 1 层运行自己节点的用户并不多。相反，大多数用户信任第三方提供商。Helios 和 Succinct 等轻客户端正在采取措施解决这个问题。然而，轻客户端远非完全验证节点，不验证链是否遵循协议规则。需要一种不同的解决方案来将我们带到一个用户可以验证链是否遵守规则的世界。
以太坊网络的多客户端理念对其安全性和去中心化至关重要。ZK-EVM 的兴起是网络即将到来的重大转变。以太坊的扩展方法可能是将第 1 层每个区块的 gas 目标减少到 100 万，这可能会迫使几乎所有用户活动转移到第 2 层协议。在这种情况下，第 1 层的唯一功能是成为第 2 层协议的票据交换所，验证它们的证据并偶尔促进它们之间的大笔资金转移。
这种设计仍然可以支持在每个块中提交的许多汇总。我们可以使用由自定义构建器运行的链下聚合协议，将来自多个第 2 层协议的 SNARK 聚集在一起，并将它们组合成一个 SNARK。SNARK 验证第 1 层有一个重要的好处：它可以大大增加 EVM 执行的数量。这可以通过大幅提高第 1 层气体限制、引入 enshrined rollup 或两者兼而有之。
随着以太坊不断发展壮大，在使用 ZK-SNARK 验证网络的第 1 层时，需要考虑几个挑战。虽然这种方法可能会带来很多好处，但也有很多障碍需要克服。
ZK-SNARK 验证的主要挑战之一是向后不兼容的可能性。如果实施这种方法，许多现有的基于 L1 的应用程序在经济上可能变得不可行。随着费用变得如此之高以至于超过清空这些账户的成本，用户资金可能会陷入困境。虽然用户可能会签署消息以选择加入到他们选择的 L2 的协议内大规模迁移，但这会增加过渡的复杂性。让它足够便宜将需要在第 1 层使用一些 SNARK，这可能很困难。
另一个挑战是验证是否可以针对不同的设备变得足够便宜。理想情况下，以太坊协议应该不仅在笔记本电脑上而且在手机、浏览器扩展程序甚至其他链中都应该易于验证。第一次同步链，或者长时间离线后，应该也很容易。虽然笔记本电脑节点可以在大约 20 毫秒内验证 100 万气体，但离线一天后同步可能需要长达 54 秒（假设单时隙最终性将时隙时间增加到 32 秒）。为手机或浏览器扩展验证每块几百毫秒可能仍然是一个不可忽略的电池消耗。这些数字是可控的，但并不理想。
尽管存在这些挑战，但即使在 L2 优先的生态系统中，让 L1 在某种程度上负担得起也是有好处的。如果用户在注意到新的状态数据不再可用时可以提取资金，Validiums 可以从更强大的安全模型中受益。如果经济上可行的跨 L2 直接转移的最小规模较小，套利将变得更加有效，尤其是对于较小的代币。
鉴于这些挑战，找到一种使用 ZK-SNARKs 来验证第 1 层本身的方法可能更合理。这种方法可能行得通，但仍有重大障碍需要克服。主要挑战之一是向后不兼容的可能性。尽管如此，仍有一些潜在的解决方案，例如允许用户签署消息以选择加入到他们选择的 L2 的协议内大规模迁移。此外，在不同设备上快速有效地验证链仍然具有挑战性。然而，通过解决这些挑战，有可能释放 ZK-SNARK 验证可以提供的许多好处，同时仍然保持以太坊网络的安全性和效率。
一个提议的解决方案是 SNARK 验证第 1 层，这将涉及使用类型 1（完全等效于以太坊）ZK-EVM 来验证（第 1 层）以太坊块的 EVM 执行。这将是一个具有挑战性的工程问题，因为 ZK-EVM 需要几分钟到几小时来验证以太坊区块，并且实时生成证明需要一个或多个（i）改进以太坊本身以删除对 SNARK 不友好的组件，（ii）要么通过专用硬件大幅提高效率，要么 (iii) 通过更多并行化改进架构。然而，没有根本的技术原因不能做到这一点——因此预计即使需要很多年也能完成。
SNARK 验证第 1 层有三个选项，每个选项都有自己的一组挑战。
第一种选择是使用单个 ZK-EVM 来验证块，这将放弃多客户端范例。
第二种选择是就一组特定的多个 ZK-EVM 达成一致，并制定共识层协议规则，即一个区块需要来自该组中超过一半的 ZK-EVM 的证明才能被视为有效，这将关闭开发新客户并导致更集中的生态系统的可能性。
目前，第三种也是最可行的选择是让不同的客户端使用不同的 ZK-EVM 实现。这将保持多客户端范例的优势，但它有其自身的一系列挑战。
实施第三种选择不会太困难。每个类型的证明都可以有一个 p2p 子网，使用一种类型证明的客户端将监听相应的子网络，并等待他们收到验证者认为有效的证明。但是，此选项的两个主要挑战可能如下：延迟挑战和数据效率低下。
在设计单时隙最终协议时要小心，可以解决延迟挑战。单时隙最终协议可能需要每个时隙超过两轮的共识，因此可能需要第一轮包含区块，并且只需要节点在第三轮（或最后一轮）签署之前验证证明。这确保了在发布区块的截止日期和预计提供证明的时间之间始终有一个重要的时间窗口可用。
数据效率问题必须通过单独的协议来汇总与验证相关的数据来解决。对于签名，我们可以使用 ERC-4337 已经支持的 BLS 聚合。另一类与验证相关的重要数据是用于隐私的 ZK-SNARKs。幸运的是，这些通常都有自己的聚合协议。
SNARK 验证第 1 层有一个重要的好处：它可以大大增加 EVM 执行的数量。这可以通过大幅提高第 1 层气体限制、引入 enshrined rollup 或两者兼而有之。通过使链上 EVM 执行不再需要由每个节点验证，可以增加 EVM 执行的数量。
尽管 SNARK 验证第 1 层有潜在的好处，但仍有几个挑战需要考虑。虽然 ZK-EVM 的实施可以实现可扩展的计算和数据采样，但仍然需要解决向后兼容性和设备验证问题。可用于 SNARK 验证第 1 层的三个选项都有其自身的一系列挑战，但第三个选项目前似乎是最可行的。实施此选项不会太困难，但它有其自身的一系列挑战，例如延迟挑战和数据效率低下。然而，通过解决这些挑战，有可能释放 SNARK 验证层 1 可以提供的许多好处，同时保持以太坊网络的安全性和效率。
以太坊的多客户端理念对其安全性和去中心化至关重要，而 ZK-EVM 的兴起将成为网络即将到来的重大转变。尽管仍有技术挑战需要克服，但多个 ZK-EVM 实施的开发是网络未来的一个有希望的迹象。随着网络的不断发展和演变，找到使用 ZK-SNARKs 验证第 1 层的方法，同时解决向后兼容性和设备验证的挑战将非常重要。通过这样做，有可能释放 ZK-SNARK 验证可以提供的许多好处，同时保持以太坊网络的安全性和效率。
在加密行业你想抓住下一波牛市机会你得有一个优质圈子，大家就能抱团取暖，保持洞察力
想抱团取暖，或者有疑惑的，欢迎加入我们——公众呺：Web3团子
