a16z：不要信任，要验证——轻客户端简介

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

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

在不久的将来，轻客户端有可能避免用户和开发人员同样面临的效率和安全性之间的权衡。随着新的区块链设计、零知识证明(zkps)的出现，以及人们对桥接和安全自我监管的兴趣日益浓厚，现在是探索、开发和采用轻客户端的理想时机。在这篇文章中，我们从基础开始：什么是轻客户端，为什么它们很重要，以及它们今天的核心用例是什么。然后，我们评估了许多开发人员在使用(或在)轻客户端上构建时必须考虑的注意事项。

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

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

进一步细分……

•协议：支持轻客户端协议的区块链(例如比特币SPV和以太坊同步委员会)允许其他计算机从计算证明的完整节点或RPC节点下载数据，包括状态和轻客户端证明。该协议在轻客户端软件中实现。

•状态：状态的一些例子包括个人账户余额、智能合约中包含的数据、用户的交易列表或数据可用性。

•效率：完整节点下载数千个交易，需要大量的CPU、磁盘空间和RAM。另一方面，轻客户端只下载几千字节的数据，并且可以在几秒钟内同步。与全节点不同，验证工作与块中的交易总数是恒定的或次线性的。

•客户端：轻客户端协议可以在移动设备(有电池寿命、带宽和CPU限制)上运行，也可以在区块链本身(有gas限制)上运行。更强大的计算机可能会同时为不同的链或链分片运行多个轻客户端。

•安全性假设：为了高效运行，轻客户端需要假设网络的安全性和可靠性、它们所依赖的节点以及其他方面的某些条件成立。这些假设因协议而异，但如果条件不成立，它们可能会引入不同的风险。例如，以太坊轻客户端通常假设总网络权益的三分之二是诚实的(例如，假数据未签名，所有区块都有效，数据可用)，并且每个选定的同步委员会中三分之二的权益是诚实的。执行证明、数据可用性证明或无状态客户端可以通过提供额外的安全层来帮助减少这些假设。

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

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

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

高安全性钱包

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

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

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

•钱包开发商是软件提供商，它们不持有资金，也不一定是金融机构。

•区块链交易是最终的和不可变的。因为用户不能通过他们的钱包提供商撤销交易，因此必须格外小心，确保所有交易均正确且合法。

•区块链保证了最终性(一旦确认，加密交易就不能更改或撤销)，因此加密用户接受来自未知或不受信任的交易对手方的支付并不罕见。这个特性也吸引了攻击者和其他不良行为者，他们可以保留他们设法窃取的任何资产。

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

区块链桥

日益重要的区块链桥接空间，通常依赖于少数各方之间的多重签名，但已经饱受黑客攻击。轻客户端可以使桥更加安全。

我们可以把区块链想象成低功耗的计算机，就像移动设备一样，理论上可以运行代码来验证其他区块链。Gas费用将使运行一个完整节点变得不切实际，但验证比特币轻客户端(以及一些权益证明协议)实际上是非常有效的：它归结为执行一些SHA256哈希。

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

与轻客户端的桥接可以防止整个攻击类别。即使中介机构遭到黑客攻击，过桥资金和数据仍然是安全的。

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

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

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

轻客户端的设计注意事项

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

简化付款验证(SPV)

SPV客户端被认为是第一个轻客户端，是随着比特币的发明而引入的。它们在最初的白皮书中被定义为解耦客户端功能，因此功能较弱的客户端可以在尽可能多的安全保证下与网络交互。这种方法非常简单：不像完整节点那样下载包含数百个交易的整个区块，SPV客户端只下载每个区块的80字节报头(每个区块10分钟，总共800K个区块)，然后向完整节点请求来自客户端地址的交易。每笔交易还附带一个默克尔证明，其默克尔根被提交到其中一个区块头中。

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

比特币白皮书(中本聪)，SPV可视化

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

下面几节将解释轻客户端中的一些变化，这些变化有助于解决这些问题，并更广泛地改进轻客户端。

客观性与弱主观性

使用工作量证明(以及空间和时间证明，或PoST)，客户端可以通过加密验证验证者在一定时间内分配真实资源来轻松区分假链和真实链。诚实的链条客观上比假的链条做了更多的工作。PoS系统不需要执行任何实际工作。由于以太坊转向PoS，以太坊的创世区块和代码库不再足以验证区块链。现在，检查点(或社交信息)在新客户端第一次同步时也是必需的。这就是所谓的弱主观性。

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

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

对于无利害关系攻击，还有其他不需要弱主观性的潜在解决方案。其中一些包括密钥演化签名方案(Cardano Ouroboros)， VDF(Solana, Chia)和单独链上的时间戳(Babylon Chain)。

完整的验证器集vs同步委员会

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

虽然同步委员会对于轻客户端效率更高，但以太坊区块链目前没有对同步委员会成员签署无效区块头的处罚。因此，同步委员会的验证者有可能接受贿赂，或者通过欺骗轻客户端进行恶意行为，而不会导致区块链削减他们的股份。尽管以太坊确实对没有签署任何东西的人执行不活动处罚，但这在全部质押中所占的比例并不大。即使有惩罚，它们也可能不会增加足够的安全性，因为同步委员会可以代表一小部分权益(即512对800k以太坊的验证者)。

其他制度不依赖委员会，例如，Cosmos IBC是一个链间协议，它定义了链之间相互通信的标准。这些链运行轻客户端(验证整个验证器集的签名，或代表67%权益的签名，如果存在显著的长尾，这可能非常有效)。

手动验证vs . SNARK共识证明

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

这些证明对于桥接轻客户端是理想的，在这种情况下，资源约束是限制性的，并且完整的轻客户端可能过于昂贵。与下载数十或数百mb的数据进行同步相比，这些证明也要快得多，也便宜得多。

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

尽管近年来这项工作已经取得了长足的进步，但在所有区块链的生产中，它还不是实用的。即使有数百个GPU，SNARK证明共识也需要几十分钟，所以这个领域的进展很重要(而且发生得很快)。

关于【a16z：不要信任，要验证——轻客户端简介】的延伸阅读

• 轻客户端，助力实现链上信息“云验证”

  分片主打的“并非每个人都必须运行每个碎片”的技术理念，成为轻客户端诞生的关键。

SNARK桥的风险

当前SNARK的复杂性为轻客户端引入了几个不同层次的风险。至关重要的是，SNARK的电路、数学或软件中的错误可能会对桥梁造成灾难性的影响，桥梁通常是金融基础设施的一部分，并被用户信任。此外，一些SNARK证明系统有额外的加密假设或可信设置，这确实会略微增加风险面。例如，zkSync的系统假设在设置仪式中至少有一个成员表现得很诚实，并且扔掉了密钥。此外，SNARK不保证证明的区块头在最长的链上(我们将在下面讨论这个问题)。

最后，SNARK共识证明不会将区块头中的签名透露给验证者(在这种情况下是轻客户端)，这使得很难惩罚不良行为者。如果验证者签署无效的区块来创建假证明，轻客户端将无法将此证据提交给源链，而且，源链将无法削减验证者的质押。由于没有经济激励促使签名者诚实，轻客户的安全性明显降低。数据可用性(DA)委员会可以通过确保签名以低廉的价格张贴在某处并允许系统惩罚不良行为者来提供帮助。

要验证哪些区块头

正如我们上面所描述的那样，SNARK可以更有效地验证每个区块头，但是在带宽、CPU和时间限制的情况下，验证数百万个区块头仍然是不切实际的(如果不是不可能的话)。对于一些PoS系统，轻客户端可以在链末端附近的检查点开始同步，以便验证更少的区块头，从而大大减少同步所需的时间。

此外，在大多数PoS协议中，验证器集的更改速度是有限的，这是另一种显著提高验证效率的方法。在其中一个协议中，客户端可以快进足够的区块，这样不超过n%的质押权重可能会被撤回。如果该点的区块拥有超过67+n%的质押权重，即使n%的质押被撤回，它也保证有效。从那里，客户端可以下载新的验证器集(假设有对它的承诺)并验证它，以刷新。

还有一些协议，如FlyClient、非交互式工作量证明(NIPoPoW)和简洁的非交互式链知识论证(SNACKs)，它们适用于PoW/PoST目标生态系统。这些只需要下载并验证O(log(N)) 区块头，其中N是链的高度。Flyclient客户端(例如在Chia上)通过基于难度在整个链中采样区块头来工作，并使用Merkle mountain range (MMR)提交过去的区块头。如果证明者试图在没有正确的工作量证明的情况下从真实链中获取不可忽略的区块数量，则其中一个采样区块头将无法验证。

PoPos是一种解决方案，它使轻客户端能够通过仅从完整节点下载对数(以块数量为单位)的数据，简洁地与以太坊和PBFT式PoS协议中的最终确定头链同步。与PoS以太坊的同步委员会建设相比，实现此功能的Kevlar等软件在经过10年的共识执行后，在同步时可以将通信提高180倍。

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

为了让客户端验证状态，需要证明三件事：共识(验证者选择了一个区块)、执行(正确应用了区块交易)和数据可用性(节点存储了区块数据)。

即使使用验证共识证明的轻客户端(在前一节中介绍)，验证器仍然需要被信任才能正确执行交易并拥有可用的块数据。在具有大块的系统中这样假设是不安全的：如果客户端不验证执行和数据处理，恶意验证器集可能会声称无效状态是有效的。

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

一些系统，比如由Celestia和EigenDA开创的系统，利用DA证明，允许客户端采样和验证一些随机的数据片段，确保验证者没有删除数据。这些DA轻客户端可以提供整个块可用的统计保证。为什么这很重要：在某些具有高数据吞吐量的区块链中，懒惰节点可能根本不存储任何数据，因为它们没有动力这样做。这意味着轻客户端可以接收无效(不存在)块的数据。这对于处理大量数据(如zkPorter)并且不想在安全L1(太昂贵)或集中式提供程序(太不安全)中提供数据的验证器尤其重要。

Mina是一个提供正确执行证明的系统的例子，它甚至更进一步，通过创建递归的SNARK，将整个区块链压缩成一个小的，几十kb大小的数据结构。其他例子包括zk-rollup，如zkSync Era, Polygon, Scroll和Zeth，它们使用SNARK证明执行。虽然这些L2可以在不验证L1的情况下通过轻客户端进行验证，但使用更去中心化的L1作为额外的结算层可以减少信任假设。

谁提供证明？

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

如果轻客户端钱包只是连接到钱包公司的服务器，客户端必须相信该公司没有隐藏最新的区块。这可能导致几种类型的攻击，如审查数据或提供不正确的状态。在PoW和一些非削减式PoS协议中，公司可以提供区块链有效分支的证明，而其他人无法识别或看到该分支。验证某个区块链是有效的与验证它是最长的是不同的。这会导致更严重的攻击，这可以通过削减和Merkle排除证明来缓解。

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

同样值得注意的是，钱包开发人员在使用网络中不受信任的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和optimistic证明。这增加了安全性，但增加了复杂性并降低了性能。

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

采用的障碍

即使技术有所改进，大多数加密钱包也不使用轻客户端(许多仍然是托管的)。大多数桥依赖于1到30个参与方的多重签名(或中心化区块链)，其中许多是密切相关的公司或个人，并且不保护他们与轻客户端的消息传递。那么，为什么轻型客户端没有得到更广泛的应用呢?

造成这种情况的原因有很多，它们在钱包和桥梁之间是不同的。几个：

•并不是所有的区块链都支持轻客户端(或者支持得很好)。

•高效的以太坊轻客户端是非常新的，许多仍然是资源密集型的，验证起来成本很高。

•提供证明即服务的成本很高。

•由于需要大量的请求，客户端可能很快达到速率限制。

•轻客户端库——它们都是相当新的——直到最近才被用于生产环境，或者非常高效。

特别是对于钱包来说，增加轻客户端的动机目前还没有超过它的缺点。自我托管通常被认为是真正拥有加密货币的途径，这是许多用户所重视的，而不是轻客户端安全性，尽管事实并非如此。轻客户端目前不能让开发者更容易遵守法律法规，它们还会使开发复杂化，延长工程时间，并潜在地损害客户体验。

另一方面，对于桥，用户和开发人员希望升级到轻客户端安全性，但还有其他障碍。这些协议的效率还没有达到，区块链还没有强大到足以验证证明。这在两个方面都在快速发展，通过目标端更多的计算(Solana, Sui, Aptos，以太坊L2，如zkSync和Optimism)和源端协议支持(以太坊同步委员会)。

展望未来：轻客户的未来方向

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

以下是一些潜在的探索领域：

•向SNARK过渡：轻客户端不仅可以使用SNARK来验证共识，还可以验证执行和数据可用性。一个轻客户端验证了这三个方面，为用户提供了极高的安全保证。

•与全节点的激励一致：通常，全节点免费向客户提供证明。但是数以千万计的轻客户端只同步到几个节点，这种服务对于节点来说可能是昂贵的。为执行证明和数据查找的节点付费可以帮助提高系统的长期可扩展性。

•分片系统：轻客户端也可以通过分片来扩展区块链。这样的系统可以将验证器拆分为多个分片，并允许验证器使用轻客户端检查其他分片(无论是执行情况还是数据可用性)，因为它们没有能力为每个分片运行完整节点。这是以太坊Danksharding计划的一部分。

•更安全的轻客户端桥：代码可能会变得复杂(特别是对于zk轻客户端)，甚至一个小错误都可能是灾难性的，可能会耗尽桥中的所有资产。开发人员必须非常小心地发布桥接，并采取额外的保护措施(如多重证明系统)，因为只有在大量资金被保护数月之后，它们才能被证明是安全的，并且没有漏洞。

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

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

感谢：Noah Citron、Nusret Tas、Guy Wuollet、Joseph Bonneau、Valeria Nikolaenko、Eddy Lazzarin 和 Stephanie Zinn

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Marsbit，如有侵权请联系删除。转载或引用请注明文章出处！

标签：轻客户端