不要信任，去验证：轻客户端介绍

去中心化和自我主权对于 web3 的未来至关重要，但这些理想并非总是适用于每个项目或应用。在非托管钱包和桥等工具中，严格优先考虑安全而非便利性的用户可以选择运行完整节点，但所需的时间和硬件量极大地限制了可以直接与区块链数据交互的用户和设备类型。最近，更高效的“轻”客户端的演进，例如 Helios (a16z crypto) 和 Telepathy (Succinct Labs) 为这些问题提供了引人注目的解决方案；用户现在可以直接从他们的设备与区块链交互，并在区块链之间以无需信任的方式桥接资产和消息。

尽管最近取得了进展，但轻客户端并不是一个新概念；它们最早以简易支付验证（Simplified Payment Verification，或 SPV）的形式在 Satoshi Nakamoto 2009 年的 白皮书 中提出，允许不太强大的客户端以尽可能多的安全保证与网络交互。从那时起，轻客户端协议使用的技术迅速发展，以支持新的区块链协议。我们现在也可以超越 SPV 的安全性：使用最新的研究，很快就可以有效地验证共识、执行和数据可用性，从而使轻客户端与其效率较低的对应物（完整节点）一样安全。

在不久的将来，轻客户端有潜力消除用户和开发者面临的效率和安全性之间的权衡。随着新的区块链设计、零知识证明（zkps）以及对桥接和安全自我托管的日益增长的兴趣的出现，现在是探索、开发和采用轻客户端的理想时机。在本文中，我们从基础知识开始：什么是轻客户端，为什么它们很重要，以及它们今天的主要用例是什么。然后，我们评估了开发者在使用（和基于）轻客户端构建时必须考虑的一些设计因素。

首先，一些背景信息：什么是轻客户端？

让我们从一个基本定义开始：轻客户端协议 允许客户端（应用程序、设备、区块链等）与区块链交互，并使用加密方法有效地验证该区块链上的状态，而无需处理整个区块链状态，通常带有一些安全假设。

进一步分解...

• 协议：支持轻客户端协议的区块链（例如，比特币 SPV 和以太坊同步委员会）允许其他计算机从计算证明的完整节点或 RPC 节点下载数据，包括状态和轻客户端证明。该协议在轻客户端软件中实现。
• 状态：状态的一些示例包括个人帐户余额、智能合约中包含的数据、用户的交易列表或数据可用性。
• 效率：完整节点下载数千个交易，需要大量的 CPU、磁盘空间和 RAM。另一方面，轻客户端仅下载几千字节的数据，并且可以在几秒钟内同步。与完整节点不同，验证工作对于一个区块中的交易总数是恒定的或次线性的。
• 客户端：轻客户端协议可以在移动设备（具有电池寿命、带宽和 CPU 约束）或区块链本身（具有 gas 限制约束）上运行。更强大的计算机可能会同时为不同的链或链分片运行多个轻客户端。
• 安全假设：为了高效运行，轻客户端需要假设某些条件对于网络的安全性和可靠性、它们依赖的数据节点等成立。这些假设因协议而异，但如果条件不成立，它们可能会引入不同的风险。例如，以太坊轻客户端通常假设总网络权益的 ⅔ 是诚实的（例如，未签署伪造数据，所有区块都有效，并且数据可用），并且在每个选定的同步委员会中，权益的 ⅔ 是诚实的。执行证明、数据可用性证明或无状态客户端可以通过提供额外的安全层来帮助减少这些假设。

为什么轻客户端很重要：钱包和桥中的核心用例

在 web3 中，用户通常需要权衡一定程度的访问和体验，以优先考虑安全性和无需信任。例如，运行资源密集型完整节点与 dapps 交互远非理想；目前也无法在没有中介的情况下访问安全桥接的资产。但这正在开始改变：新的客户端可以在不使用中介的情况下改善用户体验，同时保持非常高的安全性。

在本节中，我们将通过两个核心用例来了解轻客户端是如何实现这一目标的：高安全性钱包和区块链桥。

高安全性钱包

并非所有自我托管的钱包都同样安全。

自我托管钱包的现状是连接到钱包公司的服务器。服务器处理所有区块链交互和查找，并运行完整节点，无论是在钱包公司的基础设施上还是使用第三方提供商。用户永远不会直接与区块链节点交互——只能通过中介。虽然方便，但这种体验伴随着权衡；例如，如果钱包公司或其依赖的任何中介被黑客入侵，不正确的余额和其他误导性信息可能会诱骗用户进行他们原本不会进行的交易。更邪恶的一方甚至可能故意歪曲 DEX 价格，强迫用户接受非常糟糕的价格，或者隐藏或审查他们的交易。

虽然 web2 应用程序通常在没有问题的情况下依赖于中心化中介，但我们不能在 web3 中做同样的事情，因为 web3 缺乏一些预期的安全措施，这些安全措施可以为用户提供额外的保护：

• 钱包开发者是软件提供商；他们不持有资金，也不一定是金融机构。
• 区块链交易是最终且不可变的。由于用户无法通过其钱包提供商撤销交易，因此务必格外小心，确保所有交易都是正确且合法的。
• 区块链具有保证的最终性（一旦确认，加密交易就无法更改或撤销），因此加密用户接受来自未知或不受信任的交易对手的付款并不罕见。此功能也吸引了攻击者和其他不良行为者，他们可以保留设法窃取的任何资产。

然而，与传统金融不同，区块链的加密性质使我们能够验证状态的正确性，并防止这些攻击和其他最坏情况的发生。可以通过运行完整节点来采取这些预防措施，但（但由于我们上面讨论的原因）大多数用户不会选择这样做。当嵌入到钱包的移动应用程序中时，轻客户端可以提供更实用的替代方案：如果公司的服务器向轻客户端钱包提供无效数据，钱包将不会接受它——确保安全、无需许可地访问余额、价格、NFT 和任何区块链操作的执行。

区块链桥

日益重要的区块链桥接领域通常依赖于少量参与者之间的多重签名，并且 充斥着 黑客攻击。轻客户端可以帮助使桥更安全。

我们可以将区块链视为低功耗计算机，如移动设备，理论上可以运行代码来验证其他区块链。Gas 费用会使运行完整节点不切实际，但验证比特币轻客户端（以及一些 PoS 协议）实际上非常有效：归结为执行一些 SHA256 哈希。

这对于桥来说是一个有趣的机会，桥依赖于一个或多个受信任的方，这些方可能成为黑客攻击的目标，接受贿赂以签署无效数据，或遇到其他安全故障。此外，最终性方面的任何活跃性问题或延迟都可能严重影响用户资金。只要任何人都可以中继数据，轻客户端就可以解决这些问题。首先，中继者创建一个证明，证明某个交易和区块在源链上已完成；例如，源链验证者在区块头上的 ⅔ 签名，以及交易相对于头的 Merkle 证明。然后，中继将证明提交给目标链上的合约。合约以加密方式验证数据的正确性，从而形成高度安全的桥。这方面的例子包括 Near 上的 Rainbow bridge，Cosmos 上的 IBC 和 Axelar。

使用轻客户端进行桥接可以防止一整类攻击。即使中介被黑客入侵，桥接的资金和数据仍然安全。

区块链客户端的类型及其权衡

在我们深入研究不同轻客户端设计的细节之前，我们将讨论用户与区块链交互的不同方式及其各种权衡。从最不安全（受信任）到最安全（无需信任），这些是：（1）受信任的中介，（2）轻客户端，（3）无状态客户端，以及（4）完整节点。依赖于受信任的中介是更方便的选择，但它会带来很大的风险。运行完整节点是最安全的方法，但效率低下。

有关轻客户端及其当前功能的更全面的概况，请参阅此 SoK 论文。轻客户端通常被视为运行完整节点和依赖受信任中介之间的中间地带。近乎即时的同步和对许多区块链的支持使轻客户端成为无状态客户端的有用替代方案，后者以更高的资源使用为代价提供更多的保证。

轻客户端的设计考虑因素

构建轻客户端的工程师将不得不选择在其协议中支持哪些属性，而应用程序开发人员将不得不选择哪些轻客户端最适合他们的用例。本节将解释最基本的轻客户端协议（SPV）如何工作，然后深入研究轻客户端协议的各种属性及其在安全性和性能方面的权衡。

简易支付验证 (SPV)

SPV 客户端被认为是第一个轻客户端，随着比特币的发明而引入。它们在最初的 白皮书 中定义，以分离客户端功能，以便不太强大的客户端可以尽可能多地以安全保证与网络交互。该方法非常简单：SPV 客户端不会像完整节点那样下载包含数百个交易的整个区块，而是仅下载每个区块的 80 字节的头（每个区块 10 分钟，总共 80 万个区块），然后向完整节点请求与客户端地址之间的交易。每个交易还附带一个 Merkle 证明，其 Merkle 根提交到其中一个区块头中。

客户端验证每个头上的工作量证明，以查看它是最重的链（对它的工作量证明最多的链），因此他们的交易实际上是在规范区块链上。

比特币白皮书 (Satoshi Nakamoto), SPV 可视化

这种方法非常安全，因为它客观地验证了实际工作的执行。创建一个对轻客户端看起来真实的替代链，需要执行类似于自创世区块以来所有比特币矿工的哈希数，或者控制接近当前比特币哈希算力的近一半。但由于以下几个原因，SPV 不适合较新的区块链协议：首先，在 PoS 系统中没有执行实际工作，因此可以立即创建替代区块链。其次，SPV 要求验证每个头，这对于具有更大、更快区块的新协议来说效率不高。最后，该方法不是私有的，因为所有地址都会发送到服务器。

以下各节解释了轻客户端的一些变化，这些变化有助于解决这些问题，并更普遍地改进轻客户端。

客观性 vs 弱主观性

通过工作量证明（Proof-of-Work，以及空间时间和时间证明，Proof of Space and Time，或 PoST），客户端可以通过加密方式验证验证者是否在特定时间段内分配了实际资源，从而轻松区分假链和真实链。诚实的链客观上比假链执行了更多的工作。PoS 系统的情况并非如此，PoS 系统中没有执行实际工作。由于以太坊转向 PoS，创世区块和以太坊代码库已不足以验证区块链。现在，新客户端首次同步时，还需要检查点（或社交信息）。这被称为 弱主观性。

因此，Naive PoS 算法容易受到 “无利害关系”攻击 的影响，其中没有当前权益的旧质押密钥可以以很少或没有成本生成替代历史记录并创建较长的替代链。攻击者还可以执行无效的状态转换以给自己更多的权益，并创建更多的假区块。为了避免这些攻击，轻客户端必须依赖于一个或多个受信任的方来报告哪个链是真实的。同步时，轻客户端可以从检查点客观地开始同步，而不是从创世区块（弱主观性）。检查点也可以发布到更安全的链（如比特币）以提高透明度。

这种方法有其挑战和好处：轻客户端需要信任检查点是有效的；但是，即使是从创世区块同步的客观轻客户端也已经通过同步应用程序、它们连接的节点等引入了信任。从检查点客观地同步效率更高，因为不需要客户端下载区块链中存储的所有头。

还有其他潜在的解决方案来解决没有弱主观性的无利害关系攻击。其中一些包括密钥演化签名方案（Cardano Ouroboros）、VDF（Solana，Chia）和在单独链上进行时间戳记（Babylon Chain）。

完整验证者集 vs 同步委员会

运行轻客户端需要验证共识算法（因此需要验证区块头）。对于包括以太坊在内的一些区块链，这意味着跟踪和验证成千上万甚至数百万验证者的签名——这一过程使得客户端的“轻”程度大大降低，因为这些证明可能需要花费数十分钟才能下载和验证。这就是为什么以太坊开发了 同步委员会，这是一组 512 个随机选择的验证者，每 27 小时更改一次，并以快速可验证的方式签署区块头（ Helios 就是一个例子）。由于签名是 BLS，因此可以聚合它们以提高验证效率。

虽然同步委员会对于轻客户端来说效率更高，但以太坊区块链目前没有对签署无效区块头的同步委员会成员进行处罚。因此，同步委员会中的验证者 有可能 接受贿赂，或者通过欺骗轻客户端来进行恶意行为，而不会受到区块链削减其权益的后果。尽管 Ethereuem 的确对根本不签名处以不活动惩罚，但它不是完整权益的有意义的百分比。即使有处罚，它们可能也不会增加足够的安全性，因为同步委员会可能仅代表权益的一小部分（即以太坊中的 512 个验证者与 80 万个验证者）。

其他系统不依赖于委员会；例如，Cosmos IBC 是一种链间协议，它定义了链相互通信的标准。这些链运行轻客户端（验证整个验证者集的签名，或代表 67% 权益的签名，如果存在明显的长尾，这将非常有效）。

手动验证 vs 共识的 SNARK 证明

轻客户端更广泛采用的一个障碍是需要手动验证每个区块头及其共识。此过程要求客户端下载大量数据，这会花费时间、CPU 周期和电池寿命。为了提高效率，客户端可以改为验证区块头有效的 SNARK (zk) 证明。SNARK 轻客户端不是验证每个头和共识签名，而是验证其他人知道头链和制作哈希到区块哈希 H 的区块头所需的签名的证明。对于某些类型的 SNARK，验证是恒定时间的，并且可以在 100 毫秒以下。

这些证明非常适合桥轻客户端，在这些客户端中，资源限制非常严格，并且完整的轻客户端可能太昂贵了。这些证明也比下载数十或数百 MB 的数据以进行同步更快、更便宜。

目前正在开发几个 SNARK 库，旨在验证同步委员会轻客户端和完整共识轻客户端，这使得同步到以太坊区块链的速度更快。对于某些区块链（如比特币、Near 或 Cosmos），这些证明已经可以在实践中生成；包括 Succinct、Polyhedra/ LayerZero 和 Electron 在内的几家公司正在取得重大进展。

尽管这项工作近年来取得了很大进展，但对于所有区块链而言，它尚未在生产中实际可行。证明共识的 SNARK 需要 数十分钟，即使使用数百个 GPU，因此该领域的进展非常重要（并且正在快速发生）。

SNARK 桥的风险

当前 SNARK 的复杂性为轻客户端引入了几种不同的风险层。至关重要的是，SNARK 的电路、数学或软件中的错误可能会对桥造成灾难性的影响，这些桥通常是金融基础设施的一部分，并受用户资金的信任。此外，某些 SNARK 证明系统具有额外的加密假设或受信任的设置，这确实会略微增加风险面。例如，zkSync 的系统 假设 设置仪式中至少有一名成员表现诚实并丢弃了密钥。此外，SNARK 不保证经过验证的头位于最长的链上（我们将在下面讨论）。

最后，SNARK 共识证明不会向验证者（本例中为轻客户端）显示区块头内的签名，这使得惩罚不良行为者变得困难。如果验证者签署无效区块以创建伪造的证明，则轻客户端将无法将此证据提交给源链；源链将无法削减验证者的权益。由于签名者没有诚实的经济动机，因此轻客户端的安全性大大降低。数据可用性 (DA) 委员会可以通过确保以便宜的价格将签名发布在某个地方并允许系统惩罚不良行为者来提供帮助。

验证哪些头

正如我们上面所描述的，SNARK 可以使验证每个区块头更加高效，但鉴于带宽、CPU 和时间限制，验证 数百万 个头仍然是不切实际的（如果不是不可能的）。对于某些 PoS 系统，轻客户端可以在链尖附近的检查点开始同步，以便验证更少的头，从而大大减少同步所需的时间。

此外，在大多数 PoS 协议中，验证者集可以更改的速度存在限制，这是使验证效率大大提高的另一种方法。在这些协议中的一种中，客户端可以快速转发足够的区块，以使得不超过 n% 的权益权重可能已撤回。如果此时的区块具有超过 67+n% 的权益权重，即使 n% 的权益已撤回，也保证有效。从那里，客户端可以下载新的验证者集（假设对它有承诺）并验证它以进行刷新。

还有几种协议，例如 FlyClient、工作量证明的非交互式证明 (NIPoPoW) 和 链知识的简洁非交互式论证 (SNACK)，它们适用于 PoW/PoST 客观生态系统。这些协议只需要下载和验证 O(log(N)) 个头，其中 N 是链的高度。Flyclient 客户端（例如在 Chia 上）通过根据区块头的难度在整个链中抽取区块头样本，并使用 Merkle 山脉范围 (MMR) 来提交过去的头。如果证明者试图伪造真实链中数量可忽略不计的区块而没有正确的工作量证明，则其中一个采样的头将无法验证。

PoPos 是一种解决方案，它使轻客户端能够通过仅从完整节点下载对数（以区块数计）量的数据来简洁地与以太坊中最终确定的头链和 PBFT 风格的 PoS 协议同步。与 PoS 以太坊的同步委员会结构相比，像 Kevlar 这样实现此功能的软件在共识执行 10 年后同步时可以将通信提高 180 倍。

执行和数据可用性 (DA) 证明

需要证明三件事，客户端才能验证状态：共识（验证者选择了区块）、执行（正确应用了区块交易）和数据可用性（节点正在存储区块数据）。

即使使用验证共识证明的轻客户端（在前一节中介绍），仍然需要信任验证者才能正确执行交易并提供区块数据。在具有大区块的系统中，假设这一点是不安全的：如果客户端不验证执行 和 DA，则恶意验证者集可能会声称无效状态是有效的。

减少这些假设的一种方法是让人创建整个交易验证和执行逻辑的 SNARK 证明，从而向轻客户端证明将交易应用于区块 N 的状态哈希会导致区块 N+1 的状态哈希和相应的区块头。值得注意的是，创建这些执行证明比区块头的 SNARK 在计算上更加intensive，并且该领域仍处于早期阶段。即使使用具有数百个 GPU 的数据中心，这些证明也可能需要花费数十分钟才能生成。

某些系统（例如由 Celestia 和 EigenDA 开创的系统）利用 DA 证明，这允许客户端抽样和验证一些随机数据片段，从而确保验证者没有删除数据。这些 DA 轻客户端可以提供整个区块可用的统计保证。为什么这很重要：在某些具有高数据吞吐量的区块链中，惰性节点可能根本不存储任何数据，因为它们没有受到激励这样做。这意味着轻客户端可能会收到无效（不存在）区块的数据。这对于处理大量数据的Validium（如 zkPorter）尤其重要，并且不想在安全的 L1（太昂贵）或中心化提供商（太不安全）中提供数据。

Mina 是一个提供正确执行证明的系统的示例，它更进一步，通过创建一个递归 SNARK，将整个区块链压缩成一个小的、几十 KB 大小的数据结构。其他示例包括 zk 汇总，如 zkSync Era、Polygon zkEVM、Scroll 和 Zeth，它们使用 SNARK 证明执行。虽然可以使用轻客户端验证这些 L2 而无需验证 L1，但使用更分散的 L1 作为额外的结算层可以减少信任假设。

谁提供证明

使用所有先前的技术，轻客户端证明既可以非常安全又可以高效验证。但是，仍然存在谁向客户端提供证明的问题，因为此方可能会隐藏信息。

如果轻客户端钱包仅连接到钱包公司的服务器，则客户端必须信任该公司没有隐藏最新的区块。这可能导致多种类型的攻击，例如审查数据或提供不正确的状态。在 PoW 和某些非削减 PoS 协议中，该公司可以提供区块链的有效分叉的证明，该证明未被其他人识别或看到。验证某个区块链是否有效与验证它是否最长不同。这会导致更糟糕的攻击，可以使用 削减 和 Merkle 排除证明来缓解。

理想情况下，钱包或桥合约将从多个方收到证明；例如，来自多个公司的硬编码服务器地址，甚至来自网络中的随机 RPC 节点。只要这些方中有一个是诚实的，客户端就会收到有效的规范证明，并且撒谎或审查变得困难。此假设（N 方中至少有 1 方是诚实的）称为 存在诚实 假设。另一种说法是，客户端需要抵抗 日蚀攻击，在日蚀攻击中，客户端仅连接到不诚实的节点，并且无法访问正确的信息。

还值得注意的是，钱包开发人员在使用网络中不受信任的 RPC 节点来获取证明时必须小心。这些节点没有性能保证，并且可能会影响开发人员应用程序的用户体验。相反，客户端可以选择依赖中央服务器，还可以从后台的其他节点获取签名以证明结果。Kevlar 目前采用的这种方法可以帮助加强轻客户端的安全性，而不会牺牲用户体验。

加密经济安全性

在 PoS 系统中，签名者不会因创建伪造区块而被削减，因此不诚实的验证者签署无效头或数据并将其提供给轻客户端存在风险。作为最坏的情况，如果轻客户端不验证执行，则对网络的 51% 攻击将是灾难性的。在桥的上下文中尤其如此，因为攻击者可以铸造伪造资产。开发人员可以阻止这种攻击，方法是编写一个智能合约（或核心 L1 功能），该合约会削减签署无效数据的节点的权益——请参阅来自 Etan（Nimbus 团队）的这个有趣的 提案，其中讨论了以太坊同步委员会的削减。

正如先前各节中所述，验证执行和 DA 以及共识的轻客户端不太容易受到不诚实验证者的攻击。也就是说，削减仍然可以通过防止某些攻击来提供额外的安全性。

隐私

最后，让我们快速介绍一下一些用户的最后一个考虑因素：轻客户端本身的隐私。尽管使用轻客户端可以减少对中心化公司服务器的依赖，但这样做也会将用户的区块链地址与其 IP 之间的链接暴露给多个随机节点。某些轻客户端协议（如 Neutrino（比特币））可以在获取数据时隐藏用户的地址，但这对于 EVM 系统和具有大量状态的系统来说可能更难。有可能 像 Tor 或 Nym 这样的隐私基础设施可以通过隐藏用户的 IP 来提供帮助。

为轻客户端钱包用户提供隐私的一种可能更安全的方法是通过使用钱包服务器上的可信执行环境（TEE）。钱包服务器可以使用只有 TEE 才能访问的密钥加密区块链状态的数据。发出请求时，用户使用 TEE 的密钥加密该请求，将消息传递到服务器，并且 TEE 处理该请求而不向服务器显示结果。安全地执行此操作并不容易，并且需要高效的加密内存方案，例如 ORAM。

以太坊轻客户端的属性

合并通过 epoch 和同步委员会为以太坊带来了高效的轻客户端，以及对构建以太坊轻客户端的兴趣的提高——包括 Lodestar、Nimbus、Kevlar 和 a16z 开发的 Helios。让我们快速看一下它们的一些属性：

同步委员会和弱主观性。 以太坊的共识算法使用弱主观性，因此该协议允许极快的同步——在我们的以太坊轻客户端 Helios 的情况下，只需两秒钟。我们在 这篇文章 中更详细地解释了我们的方法，包括同步委员会、BLS 签名和弱主观性如何加速同步。

验证执行。 尽管以太坊轻客户端尚未验证执行，但未来可以使用像 zeth 这样的 zkEVM 证明者添加此功能，从而使轻客户端更加安全。

在 L2 中验证状态。 随着 L2 越来越受欢迎，自然而然地会问轻客户端是否可以在以太坊 L2 中访问状态？简短的答案是肯定的。更长的答案：要在 L2 中验证状态，应用程序必须为 L1 和 L2 运行轻客户端。L2 轻客户端将验证 L2“共识”，它可以是来自中心化方的签名，也可以是更复杂的东西，如 tendermint。StarkNet 轻客户端 Beerus 探索的另一个选项是，使用 L1 轻客户端和 L2 无状态客户端来验证由 L2 创建的实际 SNARK 和乐观证明。这提高了安全性，但增加了复杂性并降低了性能。

要解决的一个问题是，L2 的承诺可能需要相当长的时间才能发布到链上。汇总中的 SNARK 证明可能需要花费长达数十分钟才能发布，这同样适用于乐观 Rollup。a16z 加密工程师 Noah Citron 描述的一种有趣的提高效率的方法是允许任何人（例如，排序器和其他 L2 节点）对 L2 状态哈希进行承诺。如果这些方看到发布在 L1 上的数据并且知道它将导致某个状态哈希，他们可以质押它并质押他们的资金。当证明最终完成并发布时，如果与证明对应的结果状态不同，则各方将被削减。这将提供一些加密经济保证，几乎可以立即让用户对发布的状态更有信心。

采用障碍

即使技术不断进步，大多数加密钱包也不使用轻客户端（并且许多仍是托管的）。大多数桥依赖于 1 到 30 方的多重签名（或中心化区块链），其中许多方是密切相关的公司或个人，并且不使用轻客户端来保护他们的消息传递安全。那么为什么轻客户端没有得到更广泛的采用呢？

可能有很多原因导致这种情况，并且钱包和桥之间的原因各不相同。以下是一些：

• 并非所有区块链都支持轻客户端（或很好地支持它们）。
• 高效的以太坊轻客户端非常新；许多客户端仍然资源密集且验证成本高昂。
• 以服务形式提供证明的成本很高。
• 由于需要大量请求，客户端可能会很快达到速率限制。
• 轻客户端库（所有这些库都相当新）直到最近才准备好投入生产或非常高效。

特别是对于钱包而言，目前添加轻客户端的激励措施并不大于缺点。自我托管通常被认为是 真正拥有 加密货币的途径；这个普遍的看法，尽管它不 一定是这种情况，是许多用户所重视的，而不是 轻客户端的安全性。轻客户端目前并不能让开发人员更容易遵守法律法规；它们也可能使开发复杂化，延长工程时间，并可能降低客户体验。

另一方面，对于桥来说，用户和开发人员都希望升级到轻客户端的安全性，但还存在其他障碍。这些协议的效率还不高，而且区块链还不够强大来验证证明。通过目标端的更多计算（Solana、Sui、Aptos、以太坊 L2，如 zkSync 和 Optimism）以及源端的协议支持（以太坊同步委员会），这两个方面都在迅速发展。

前瞻：轻客户端的未来方向

轻客户端在理论和实现上都还有很长的路要走。尽管如此，很明显，轻客户端可以实现安全的桥接和钱包的未来，同时保持极高的效率。区块链协议团队可以通过标准化和发布轻客户端协议来访问状态，从而推动 web3 行业的发展，而钱包和桥接开发者可以使用轻客户端来提高其应用程序的安全性。

一些潜在的探索领域：

• 过渡到 SNARKs：轻客户端不仅可以使用 SNARKs 来验证共识，还可以验证执行和数据可用性。一个验证所有这三者的轻客户端，为用户提供了极高的安全保证。
• 与完整节点对齐激励：通常，完整节点免费为客户端提供证明。但是数千万个轻客户端同步到少数几个节点，这项服务对于节点来说可能是昂贵的。为执行证明和数据查找的节点付费可以帮助系统的长期可扩展性。
• 分片系统： 轻客户端也可用于通过分片扩展区块链。这样的系统可以将验证者分成多个分片，并允许验证者使用轻客户端检查其他分片（无论是执行还是数据可用性），因为他们没有能力为每个分片运行完整节点。这是以太坊上 Danksharding 计划的一部分。
• 更安全的轻客户端桥： 代码可能会变得复杂（尤其是使用 zk 轻客户端），即使是一个小 bug 也可能是 灾难性的，可能会耗尽桥中的所有资产。开发者必须极其谨慎并采取额外的保护措施（例如多个证明系统）来发布桥，因为只有在大量资金安全存放数月且没有漏洞后，才能证明它们是安全的。

在过去的五年中，学术研究人员、区块链设计师和工程师在轻客户端协议设计、部署和 SNARK 证明方面取得了重大进展。

随着时间的推移，我们可以开始越来越依赖这种基础设施，并希望生活在一个每个人都可以无需许可地访问全球加密网络并与之互动的世界中。

加粗 特别感谢：Noah Citron, Nusret Tas, Guy Wuollet, Joseph Bonneau, Valeria Nikolaenko, Eddy Lazzarin, and Stephanie Zinn

• 原文链接： a16zcrypto.com/posts/art...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～