light client轻节点简介

1. 引言

前序博客：

• Helios——a16z crypto构建的去中心化以太坊轻节点

去中心化和自我主权对于Web3的未来至关重要，但是这些理想并不总适用于每个项目或应用程序。在非托管钱包和bridges等工具中严格优先考虑安全性而不是便利性的用户，可选择运行全节点，但运行全节点所需的时间和硬件，将极大地限制可直接与区块链数据交互的用户和设备的种类。
效率更高的"light client"的最新进展，如：

• Helios——a16z crypto构建的去中心化以太坊轻节点
• Telepathy——Succinct Labs的去中心化zkSNARK互操作协议

为这些问题提供了引人注目的解决方案——用户设备可直接与区块链进行交互，并在区块链之间trustlessly桥接资产和消息。

除了以上最新进展，轻节点并不是一个新概念：

• 最早在中本聪(Satoshi Nakamoto)的2009年白皮书中以Simplified Payment Verification(或SPV )的形式提出，SPV允许功能较弱的客户端与网络进行交互，并提供尽可能多的安全保证。从那时起，轻节点使用的技术迅速发展，以支持新的区块链协议。
• 现在可超越SPV的安全性：最新研究表明，很快就可有效地验证共识、执行和数据可用性，使轻节点与效率较低的全节点一样安全。

在不久的将来，轻节点有可能消除用户和开发人员面临的效率与安全之间的权衡。随着新的区块链设计的出现，零知识证明（ZKP）以及对bridge和安全自托管的兴趣日益浓厚，现在是探索、开发、并采用轻节点的理想时机。

本文总体结构为：

• 什么是轻节点？
• 为什么需要轻节点？当今轻节点的核心应用场景？
• 评估开发人员在使用（和构建）轻节点时需考虑的许多设计考量。

2. 什么是轻节点？

轻节点协议：

• 允许（应用程序、设备、区块链等）客户端，在无需处理整个区块链状态的情况下，与区块链进行交互，并使用（通常需要一些安全假设的）密码学方法有效验证该区块链上的状态。

进一步分解来解释：

• 协议：支持轻节点协议的区块链（如比特币SPV和以太坊同步委员会）允许其他计算机，从全节点或（可计算轻节点proofs的）RPC节点那，下载（包括状态和轻节点proofs的）数据。该协议在轻节点软件中实现。
• 状态：状态可包含：
  • 个人帐户余额
  • 智能合约中所包含的数据
  • 用户的交易列表
  • 数据可用性
• 效率：全节点下载数千笔交易，需要大量的CPU、磁盘空间和RAM。而轻节点仅需要下载数千字节的数据，且可在几秒钟内同步。与全节点不同，验证工作是constant的或，与区块中的交易总数呈sub-linear关系的。
• 客户端：轻节点协议可在（具有电池寿命、带宽和CPU限制的）移动设备上运行，也可在（具有gas限制）的区块链本身上运行。更强大的计算机可能会同时为不同的链或chain shards运行多个轻节点。
• 安全假设：为有效运行，轻节点需假定某些安全性条件成立、网络可靠、以及所依赖的数据源节点符合特定条件等。这些假设因协议而异，但若条件不成立，可能会带来不同的风险。如：
  • 以太坊轻节点通常假定总网络stake的⅔是诚实的（如假数据未签名、所有区块均有效、且数据可用），且在每个选定的同步委员会中，stake的⅔都是诚实的。执行proofs、数据可用性proofs或stateless clients可通过提供额外的安全层来帮助减少这些假设。

3. 为什么需要轻节点？——钱包和bridge中的核心用例

在web3中，用户交易时通常需要牺牲一定程度的访问和体验，以优先考虑安全性和可信赖性。如：

• 运行资源密集型全节点与dapps进行交互远非理想。
• 当前，无法在没有中介的情况下，安全访问bridge资产。

但有了轻节点之后：

• 新客户端可在无中介的情况下改善用户体验，同时保持很高的安全性。

本节重点关注轻节点的两个核心用例：

• 高安全性钱包
• 区块链bridges

3.1 高安全性钱包

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

自托管钱包的status-quo（现状）与钱包公司的服务器相连。该服务器处理所有区块链交互和查找，并在钱包公司的基础架构或使用第三方提供商上运行全节点。用户永远不会直接与区块链节点进行交互，而是仅通过中介（如钱包公司）来与区块链节点进行交互。尽管这样方便，但有所取舍，如：

• 若钱包公司或其依赖的任何中介机构被黑客入侵，不正确的余额和其他误导性信息可能会诱使用户进行原本不会进行的交易。更邪恶的一方甚至可能会故意歪曲DEX价格，迫使用户接受非常糟糕的价格，或者隐藏或审查其交易。

尽管web2 app通常毫无问题地依赖于集中式中介，但在web3中却无法做到这一点，其缺少一些为用户提供额外保护的预期保护措施:

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

但与传统金融不同，区块链的密码学属性，使得能验证状态的正确性并防止攻击和其他最坏情况。可通过运行一个全节点来采取这些预防措施，但由于之前提及的原因，大多数用户不会选择自己运行一个全节点。将轻节点嵌入到钱包的移动应用程序中后，可提供更实用的选择：

• 若公司的服务器向轻节点钱包提供了无效的数据，钱包将不接受这些无效的数据，从而确保安全、无需许可地访问余额、价格、NFT以及执行任何区块链操作。

3.2 区块链bridges

越来越重要的区块链bridge空间，通常依赖于少数各方之间的多签，以被多次黑客攻击：

• 2022年6月，Harmony的horizon bridge被攻击，损失1亿美金
• 2022年3月，游戏公司Ronin网络被攻击，损失6.25亿美金
• 2023年7月，Multichain被攻击，损失1.27亿美金

轻节点可帮助使bridge更安全。
可将区块链视为低功耗计算机，如移动设备，从理论上讲，这些低功耗计算机可运行代码来验证其他区块链。gas fee会使运行一个全节点变得不切实际，但验证Bitcoin轻节点（以及某些Proof-of-Stake协议）实际上非常有效——对应为执行一些SHA256哈希。

对于bridge来说，这是一个有趣的机会，bridge依赖于一个或多个受信任方：

• 这些受信任方可被黑客攻击、接受贿赂以签署无效数据或遇到其他安全故障。
• 此外，任何活力问题或最终性的延迟都会对用户资金产生重大影响。

而轻节点可解决这些问题，使得任何人都可relay数据：

• 首先，某relayer创建一个proof，证明某交易和区块已在源链上完成。如：
  • 区块头上有源链⅔ Validator签名,
  • 以及，该交易对应该区块头的默克尔证明。
• 然后，该relayer将proof提交给目标链上的合约。目标链上的合约通过密码学方式验证数据是否正确，从而形成高度安全的bridge。

相关轻节点bridge用例有：

• Near的Rainbow bridge
• Cosmos的IBC
• Axelar

轻节点bridge可防止整个攻击类别。即使中介被黑客攻击，bridged资金和数据仍保持安全。

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

在深入研究不同轻节点的设计细节之前，将讨论用户与区块链及其各种权衡进行交互的不同方式。从最不安全的（信任的）到最安全的（信任的），分别为：

• 1）受信任的中介：依靠受信任的中介是更方便的选择，但会带来巨大的风险。
• 2）轻节点
• 3）无状态客户端（stateless client）
• 4）全节点：运行全节点是最安全的方法，但效率低下。

有关轻节点及其当前功能的更多知识，参看：

• 2021年论文SoK: Blockchain Light Clients

通常，轻节点被视为运行全节点和依赖受信任的中介之间的中间地带。对许多区块链的近乎即时的同步和支持，使得轻节点成为无状态客户端的有用替代。无状态客户端提供了更多的保证，但资源使用量却大大增加。

5. 轻节点的设计注意事项

构建轻节点的工程师将必须选择在其协议中支持的属性，而应用程序开发人员将不得不选择最适合其用例的轻节点。本节将说明最基本的轻节点协议（SPV）的工作原理，然后更深入地研究轻节点协议的各种属性及其在安全性和性能方面的权衡。

5.1 Simplified Payment Verification（SPV）

SPV客户端被认为是首个轻节点，是随着比特币的发明而引入的。在原始白皮书中，SPV客户端与客户端功能解耦，以使功能较弱的客户端可与网络进行交互，并提供尽可能多的安全保证。

SPV客户端实现方法非常简单：

• 与其像全节点那样下载具有数百个交易的所有区块不同，SPV客户端仅下载每个区块的区块头（10分钟下载80字节的区块头，总共下载80万个区块的区块头)，然后询问某全节点，获取与该客户端地址相关的交易。每笔交易还带有默克尔证明，其默克尔根在其中一个区块头中承诺。

SPV客户端验证每个区块头上的工作量证明（Proof of Work），以确保它是最重的链上（具有最大工作证明的链），使得其交易实际上在canonical链上。 Bitcoin白皮书上的SPV客户端示意图为：

这种方法非常安全，因为它可以客观地验证是否执行了实际工作。创建一个对轻节点而言真实的alternate链，将需要执行与自创世区块以来所有比特币矿工相似数量的哈希运算，或控制近一半的当前Bitcoin hashpower。

但SPV不适合较新的区块链协议，原因如下：

• 首先，PoS系统未执行任何实际工作，因此可立即创建alternate链。
• 其次，SPV要求每个区块头都经过验证，这对于具有更大、更快区块的较新协议而言并不是特别有效。
• 最后，该方法不是私有的，因为所有地址都发送到服务器。

以下各节介绍了轻节点的一些变化，这些变化有助于解决这些问题，并更普遍地改善轻节点。

5.2 客观性与弱主观性

使用工作量证明（和Proof of Space and Time，或PoST），客户端可通过密码学验证validators在特定时间内分配了真实资源，从而轻松地将假链与真实链区分开。诚实链客观地完成了比假链更多的工作。这不适用于没有执行实际工作量的PoS系统。
自从以太坊移至PoS以来，创世区块和以太坊代码库不再足以验证区块链。现在，首次新客户端同步时，检查点（checkpoint）(或社交信息)也是必需的。这被称为弱主观性。

naive PoS算法易于受 “nothing-at-stake” 攻击，其中old staking keys with no current stake可 以少量或无开销的情况下，用于生成alternate历史记录，创建长alternate链。攻击者还可以执行无效的状态转换，以给自己更多的stake，并创建更多的假区块。为了避免这些攻击，轻节点必须依靠一个或多个受信任方来报告哪个链是真实的。同步时，轻节点可从某checkpoint开始客观同步，而不是自创世区块开始同步（弱主观性）。也可对更安全的链（如Bitcoin）发布checkpoints，以提升透明度。

这种方法具有其挑战和好处：

• 轻节点需要相信checkpoints有效。
• 即使客观轻节点自创世区块开始同步，其仍然引入了对同步应用、所连节点等的信任。
• 从checkpoints客观同步更有效，因为不需要客户端下载区块链中存储的所有区块头。

对于 “nothing-at-stake” 攻击，还有其他不需要弱主观性的潜在解决方案。如：

• 包括key-evolving签名方案，如Cardano Ouroboros
• VDFs，如Solana、Chia。
• 在separate chain上打时间戳，如Babylon Chain。

5.3 Full validator set vs. syncing committee

运行轻节点需要验证共识算法（从而验证区块头）。对于某些区块链（包括以太坊），这意味着跟踪和验证数十万甚至数百万个validators的签名——该过程使客户端大大less “light”，因为这些proofs可能需要数十分钟来下载并验证。为此以太坊发展出syncing committee——一组512个随机选择的validators，每27小时更改一次，并以快速可验证的方式签署区块头（如Helios）。由于签名是BLS，因此可聚合签名以提高验证效率。

尽管同步委员会对轻节点而言效率更高，但以太坊区块链目前对签署无效区块头同步委员会成员没有处罚。所以 可能 同步委员会的validators接受贿赂，或通过欺骗轻节点而采取恶意行动，而不会削减其stake以示惩罚。尽管以太坊确实因为根本不签署任何东西而实施了不活动的惩罚，但这并不是全部stake的有意义百分比。即使受到处罚，它们也可能无法增加足够的安全性，因为同步委员会可以代表stake的一小部分（即，以太坊中的512 vs. 80万 validators）。

其他系统不依赖委员会。如：

• Cosmos IBC是一种链间协议，定义了链之间相互通信的标准。这些链运行轻节点（以验证整个validator set的签名，或代表67% stake的签名）。

5.4 手动验证与SNARK共识proofs

广泛采用轻节点的一个障碍是需要手动验证每个区块头及其共识。此过程要求客户端下载大量数据，这需要时间、CPU周期和电池寿命。

为提高效率，客户端可验证某区块头有效的(zk)SNARK proof。与其验证每个区块头和共识签名，SNARK 轻节点验证 其他人知道header链以及制作区块头使其区块哈希值为H的所有签名 的proof。对于某些类型的SNARK，验证是恒定时间，并可在100ms以下。

这些证明非常适合bridge轻节点，因为资源是有限的，且全节点可能太昂贵了。与下载数十或数百 MB的数据进行同步相比，这些证明也更快、更便宜。

当前正在开发多个SNARK库，这些库旨在验证同步委员会轻节点和全共识轻节点，这使得同步到以太坊区块链的速度更快。对于某些区块链，如比特币、Near或Cosmos，这些证明已经可以实际生成。当前：

• Succinct
• Polyhedra/LayerZero
• Electron

等多家公司，正在取得重大进展。

尽管这项工作近年来已经取得了长足的进步，但对于所有区块链而言，它尚不实用。SNARK证明共识 需数十分钟，甚至需要数百个GPU，因此该领域的进展很重要（且进展快速）。

5.5 SNARK bridge的风险

当前SNARK的复杂性为轻节点带来几层不同的风险：

• 至关重要的是，SNARK电路、数学或软件中的错误可能对bridge造成灾难性影响。bridge通常是金融基础设施的一部分，并受到用户资金的信任。
• 同样，某些SNARK证明系统具有其它密码学假设或trusted setup，这确实会稍微增加风险面。如zkSync的系统 假设 setup ceremony中至少有一位成员表现诚实并扔掉了keys。
• 同时，SNARK不能保证已证明的区块头位于最长的链上（后续将讨论）。
• 最后，（轻节点情况下）SNARK共识证明不会向verifier揭示区块头内的签名，这使得很难惩罚不良行为者。
  • 若validators签署无效的区块以创建伪造的证明，则轻节点将无法向源链提交相应证据，
  • 且源链将无法削减行为不当validators的stake。
  • 没有经济激励签名者诚实，轻节点的安全性将大大降低。
  • 数据可用性（Data availability，DA）委员会可通过确保以低廉的价格将签名张贴在某处并允许系统惩罚不良行为者，来提供帮助。

5.6 哪些区块头需要验证？

SNARK可更高效地验证每个区块头，但仍不适用于验证数百万个区块头，受限于带宽、CPU和时间限制。某些PoS系统的轻节点可在链最新高度附近的某checkpoint开始同步，以验证较少的区块头，从而大大减少了同步所需的时间。

此外，在大多数PoS协议中，validator set更改的速度受到限制，这是使验证效率显著提高的另一种方法。在PoS协议中，轻节点可以快速转发足够的区块，以使不超过n%的stake weight可被撤回。如果某时间点的区块拥有超过67 + n%的stake，则即使n%的stake已撤回，也可保证该区块有效。从那个时间点，轻节点可以下载并验证新的validator set进行更新。

当前：

• FlyClient
• Non-Interactive Proofs of Proof-of-Work (NIPoPoW)
• succinct non-interactive argument of chain knowledge (SNACKs)

这几种协议适于PoW/PoST生态。这些协议仅需要下载并验证$O(\log (N))$个区块头，其中$N$为链高度。在Chia链上的Flyclient轻节点：

• 基于difficulty对链的区块头进行采样，并使用Merkle mountain range（MMR）来对过去的区块头进行commit。
• 若某Prover试图基于real chain，在没有正确工作量证明的情况下，伪造一定数量的区块，则所采样的区块头将验证失败。

其它新的解决方案有：

• PoPos 为支持轻节点同步以太坊固化header chain的解决方案。
• PBFT风格的PoS协议可从全节点中下载对数量级的数据。
• 与PoS Ethereum的同步委员会构建方式相比，Kevlar在同步执行了10年共识执行的数据通信时，其性能提升了180倍。

5.7 执行proofs和数据可用性（DA）proofs

为让轻节点验证状态，需证明：

• 1）共识（某区块所选中的validators）
• 2）执行（该区块内交易执行正确）
• 3）数据可用性（节点存储了相应的区块数据）
  
  前面提及了，即使轻节点验证了共识proofs，仍需要信任validators正确执行了交易且区块数据可用。对于具有大区块的系统来说，这种假设并不安全：
• 若轻节点无法验证执行和DA，则某恶意validator set可声称某invalid state是有效的。

减少这些假设的一种方法是：

• 让某人创建整个交易验证和执行逻辑的SNARK证明，向轻节点证明：

  • 将交易应用于块N的状态哈希会导致块N + 1的状态哈希以及相应的区块头。

  值得注意的是，这些执行proofs的创建比区块头SNARKS在计算上更加密集，且该领域仍处于早期研究阶段。即使使用带有数百个GPU的数据中心，这些证明也可能需要数十分钟才能生成。

一些系统，如由Celestia 和EigenDA所引领采用的DA proofs，支持轻节点采样和验证数据的某些随机片段，从而确保validators未删除该数据。这些DA轻节点可为整个区块可用提供统计学保证。为什么这很重要：

• 在某些具有高数据吞吐量的区块链中，懒惰节点可能根本不存储任何数据，因为它们没有动机这样做。这意味着轻节点可能接收无效的（不存在）区块的数据。这对，像zkPorter这样的validiums，尤为重要，因其需要处理大量数据，并不想在L1上维护数据可用性（因太贵），或在某中心化提供商那存储数据（因太不安全）。

当前：

• Mina提供了正确执行proofs，且通过创建递归SNARK将整个区块链压缩为一个小的SNARK——数十KB大小的数据结构。
• zkRollups，如zkSync Era、Polygon zkEVM、Scroll和Zeth，使用SNARK证明执行。尽管可以在不验证L1的情况下通过轻节点验证这些L2，但使用更去中心化的L1作为附加的结算层可以减少信任假设。

5.8 谁提供proof？

使用以上所有技术，轻节点proofs可非常安全和有效地进行验证。但是，仍然存在谁来向轻节点提供proof的问题，因为proof提供方可能会隐藏信息。

若轻节点钱包仅连接到钱包公司的服务器，则该轻节点钱包必须相信该公司没有隐藏最新的块。这可能导致多种类型的攻击，如：

• 审查数据
• 或提供不正确的状态。

在PoW和某些无slashing惩罚机制的PoS协议中，钱包公司可提供区块链有效分支的证明，而其他人无法识别或看到该分支。验证某个区块链是否有效与验证其最长不同。这导致更严重的攻击，可以通过slashing惩罚和Merkle exclusion proofs来解决。

理想情况下，钱包或bridge合约将接收多方的proofs，如：

• 来自多个公司’硬编码服务器地址
• 甚至来自网络中的随机RPC节点。

只要这些当事方之一诚实，客户就会收到有效的canonical proof，且难于说谎或审查。N方中至少有1个是诚实的（这一假设称为 existential honesty 假设。表达这一点的另一种方法是，轻节点需要抵制 eclipse攻击——此时轻节点仅连接到不诚实的节点，且无法访问正确的信息。

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

5.9 密码学经济安全性

在PoS系统中，签名者不会因创建假区块而受到slash惩罚，不诚实的validators可能会签署无效的区块头或数据并将其提供给客户。在最坏的情况下，网络的51%攻击，使得轻节点无法验证执行，这将是灾难性的。对bridge场景尤其如此，因为攻击者可能会铸造假资产。开发人员可以通过编写智能合约（或核心L1功能）来阻止这种攻击，该合约会slash签署无效数据的节点的stake。具体见Etan（Nimbus团队）的提案，其讨论了以太坊同步委员会的slash方案。

如前几节所述，验证执行和DA以及共识的轻节点不易受到不诚实的validators的攻击。也就是说，大幅slash仍可以通过防止某些攻击来提供额外的安全性。

5.10 隐私

本节关注：

• 轻节点本身的隐私。

尽管使用轻节点可减少对集中式公司服务器的依赖，但这样做也可将用户的区块链地址及其IP之间的链接暴露给多个随机节点。
某些轻节点协议，如：

• Bitcoin的Neutrino 可在获取数据时隐藏用户的地址，但对于具有大量状态的系统和EVM系统而言，这可能更困难。可能需要 Tor或Nym等隐私基础设施来帮助隐藏用户的IP。

为轻节点钱包用户提供隐私的一种可能更安全的方法是通过在钱包服务器上使用trusted execution environments （或TEE）。钱包服务器可使用只能从TEE访问的密钥来加密区块链状态的数据。发出请求时，用户使用TEE的密钥对该请求进行加密，将消息传递到服务器，并且TEE在不向服务器透露结果的情况下处理该请求。这不容易安全地进行，并且需要有效的加密内存方案，如 ORAM。

5.11 以太坊轻节点的属性

以太坊merge之后，通过epoch同步委员会为以太坊带来了高效的轻节点，以及对构建以太坊轻节点新兴趣，包括：

• Lodestar
• Nimbus
• Kevlar
• Helios

这些新的以太坊轻节点方案具有如下属性：

• 同步委员会和弱主观性：以太坊的共识算法采用弱主观性，因此，轻节点协议支持快速同步——如Helios协议仅需2秒就可快速同步。详情见博客：Building Helios: Fully trustless access to Ethereum，详细解释了同步委员会、BLS签名和弱主观性如何加快同步。
• 执行验证。尽管以太坊轻节点尚未验证执行，但是将来有一条路径可以使用zkEVM Provers（如zeth来让轻节点更安全）。
• L2中的状态验证。由于L2越来越受欢迎，一个自然要问的问题是，轻节点是否可访问以太坊L2的状态？简短的答案是肯定的。
  更长的答案：
  • 要验证L2中的状态，应用程序必须为L1和L2运行轻节点。L2轻节点将验证L2 “共识”，可为中心化的签名，或Tendermint这样更复杂的共识。
  • StarkNet轻节点Beerus，具有一个L1轻节点和一个L2无状态客户端，以验证L2创建的实际SNARK proofs和optimistic proofs。这增加了安全性，但增加了复杂性并降低了性能。

要解决的一个问题是：

• 对L2的承诺可能需要花费大量时间才能发布到链上。

rollup中的SNARK proof可能要花数十分钟才能发布，optimistic rollup也是如此。a16z crypto工程师Noah Citron描述的一种有趣的提高效率的方法是：

• 允许任何人（如sequencer和其它L2节点）对L2状态哈希做出承诺。如果这些方（如sequencer和其它L2节点）看到L1上发布的数据并知道这将导致某种状态的哈希，则可投入所stake的资金对其进行stake。当该proof最终完成并发布时，若与证明相对应的结果状态不同，则各方将被slash。这将提供一些密码学经济保证，几乎可以立即使用户对发布状态更有信心。

5.12 实际使用轻节点的障碍

即使技术进步，大多数密码学钱包也不会使用轻节点（许多仍是托管钱包）。大多数bridges都依赖于1至30个方中的多点（或中心化区块链），其中许多是紧密相关的公司或个人，并且无法确保与轻节点消息传递的安全性。

那么，为什么轻节点看不到更广泛的使用呢？
原因有很多，钱包和bridge之间也有所不同。如：

• 如今，并非所有的区块链都支持（或很好地支持）轻节点。
• 高效的以太坊轻节点是极其新的。许多仍然占用大量资源,并且验证成本很高。
• 提供proofs作为服务很昂贵。
• 由于需要大量请求，轻节点很容易快速达到rate限制。
• 全新的轻节点库，并未达到生产级别或最近才非常高效。

特别是对于钱包，增加轻节点的动机目前并不超过弊端。人们普遍认为自托管是通往 真正拥有 crypto的必经之路，这是普遍持有的信念，但对于许多客户价值来说，轻节点的安全性并不是必须的。轻节点目前无法使开发人员更容易遵守法律法规，反而使开发复杂化、延长工程时间、并有可能损害客户体验。

另一方面，对于bridge，用户和开发人员希望升级到轻节点安全性，但还有其他障碍。这些协议的效率尚不满足实用要求，且区块链还不够强大，无法验证proofs。需在两方面发展：

• 在目标端（Solana,Sui,Aptos,以太坊L2(如zkSync和Optimism )）进行更多计算
• 在源端（以太坊同步委员会）支持轻节点协议。

6. 展望未来：轻节点的未来方向

在理论和实践方面，轻节点还有很长的路要走。但轻节点是在保持高效的同时实现安全bridge和钱包的未来。区块链协议团队可以通过标准化和发布轻节点协议来访问状态，从而推动Web3行业向前发展，钱包和bridge开发人员可以使用轻节点来升级其应用程序的安全性。

一些潜在的探索领域有:

• 过渡到SNARK：轻节点不仅可使用SNARK来验证共识、还可以验证执行和数据可用性。验证所有这三个功能的轻节点为用户提供了极高的安全性保证。
• 对全节点的激励对齐：通常全节点免费给轻节点提供proofs。但是数以千万计的轻节点仅同步到几个全节点，这项服务对于全节点而言可能成本很高。对执行证明和数据查找的全节点付费，可帮助系统的长期可扩展性。
• sharded系统：轻节点也可通过sharding来扩容区块链。这样的系统可将validators拆分为shards，并允许validators使用轻节点检查其他shards（的执行或数据可用性），因为它们没有能力为每个shard运行全节点。这是以太坊Danksharding的规划。
• 更安全的轻节点bridge：该代码可以变得复杂（尤其是对zk轻节点），甚至一个小错误也可能是灾难性的，可能会损失bridge中的所有资产。开发人员必须谨慎行事，并采取额外的保护措施（如多证明系统），因为只有在获得大量资金多个月担保后，才能证明它们是安全的、没有漏洞的。

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

随着时间的流逝，将开始越来越依赖此基础设施，并希望生活在 每个人都可 无许可地访问全球加密网络并与之交互 的世界中。

参考资料

[1] a16z crypto团队2023年9月博客 Don’t trust, verify: An introduction to light clients