超越 IBC

通过我们的部分前期研究，可以看出我们相信模块化区块链和应用特定区块链的设计范式。这一结果是我们设想的世界将拥有许多不同的区块链，用于各种应用、行业等。我们相信，随着应用程序的普及，区块链的种类将会呈现广泛的多样性，并且将继续增长。

更多区块链的不可避免结果，无论以rollup形态还是其他形式，会使得互操作性变得越来越重要。因此，随着世界变得越来越模块化，我们预计会看到大量桥梁的出现。我们观察到的一些更令人兴奋的项目之一是Polymer。接下来，我们将深入探讨它如何将IBC带入所有生态系统。

IBC

为了让大家回顾一下，这里有我们在之前的一篇文章中关于IBC的一部分。

跨链通信（Inter-Blockchain Communication，简称IBC）本质上是一种用于同质区块链的跨链消息传递协议。这意味着它连接了具有类似功能的区块链，在这种情况下，是由Tendermint共识算法提供的即时最终性，以及具有轻客户端功能的区块链。IBC的工作方式是，两个希望相互连接的链在目标链上提交治理提案。这通常是通过Cosmos Hub或Osmosis进行的（目前Osmosis有45个对等节点，Cosmos有40个）。这表明在协议层面达成了一致，因此外部桥梁不需要信任的第三方。

这两个区块链需要在彼此的链上有一个轻客户端，以加密验证这两条链之间的一致性状态，并且需要一个中继者在这两条链的轻客户端之间传递信息。中继者是保证活性的关键——即能够在节点之间交换消息，并且节点能够成功达成共识。我们来看看这在实践中是如何实现的：

这意味着信任假设位于连接区块链的两个验证者集中，因此与其他类型的桥和消息协议相比，其信任假设要少得多。例如，在Polkadot生态系统中的XCMP，其信任假设仅依赖于中继链（Polkadot）。

为了展示IBC在Cosmos生态系统中的兼容性和普及程度，以及它连接的链的数量，我们来看看当前实时连接的地图。

mapofzones.com

在IBC中，有两个重要的内涵需要注意：连接和通道：

1. 连接是两个在两个独立链上的状态对象——CosmosSDK中的IBC模块。

2. 通道是与某个链/应用的特定连接，并提供消息传递信息，如排序，这就是所谓的中继者。

ICS

ICS代表跨链标准（Interchain Standard），为使用IBC进行的链间交易设定参数。ICS实际上是IBC交易的模块规范。为了使用IBC进行通信，两条链需要具备相同的ICS规范。其中一个更有趣和独特的ICS是ICS-27，也称为跨链账户（Interchain Accounts）。

Polymer将支持现有的ICS。因此，连接到Polymer的链将能够利用更广泛的IBC社区所做的大量优秀工作，而Polymer已经是这个社区的长期贡献者。

轻客户端

轻客户端是区块链的重要组成部分。在其当前形式中，它们使得硬件需求较低的机器能够参与区块链的验证过程，并帮助与其他链建立连接。它们通过只下载区块头而不是整个区块来实现这一点。它们信任诚实的全节点提供准确信息，因此不是去信任的模式。轻客户端的实现有多种类型，甚至可以说以太坊上的rollup桥合约在某种程度上就像Cosmos生态系统中与IBC连接的区块链的轻客户端运作方式。

轻客户端在Cosmos生态系统涌现之际显著引起了关注，并在区块链的扩展功能方面赢得了相当大的普及。我们在这里提到的是Celestia如何利用轻客户端参与数据可用性采样以随着网络中节点的数量扩展。这将使得轻客户端与全节点几乎相似的信任假设，而仍然无需下载整个区块。这使得轻客户端、因此最终用户，成为他们所处网络的第一公民。

在大多数原始的单一链（monolithic）区块链中，用户被要求运行一个全节点，如果希望参与验证，他们必须存储全部的区块链数据。这在去中心化方面增加了障碍，随着区块链规模和历史的增长，全节点所需的硬件要求也随之增加。这个问题通常被称为状态膨胀（state bloat）。通过轻客户端，只要它们连接到一台诚实的全节点，就能通过扫描区块头而不是像全节点那样下载整个区块参与。区块头是区块中的一个部分，作为其余区块的摘要——例如，当区块被挖掘时的时间和难度，以及包含的交易的根。

轻客户端在PoS链中验证区块所需的信息

在桥接中使用轻客户端可以实现使两个桥接链得以通过离线中继者彼此验证状态。通过相互验证各自的状态机，这两个连接的链能够在协议层面上相互达成最终性。在当前轻客户端的设置中，这确实意味着要涉及一定程度的信任，如前所述。在IBC中，链之间的连接通过在每条链上设置一个轻客户端来验证链的状态。

中继者根据连接链的状态构建交易，然后提交给网络中的其他节点。在IBC中，这一过程是通过Hermes中继者实现的。当前正在进行的一些工作是中继者激励机制，以实现更大的去中心化和安全性。目前，中继者是手动运行的，许多由运行连接链全节点的各种验证者运行，通常使他们能够从链间MEV中获益丰厚。在此，Polymer也在积极参与缓解与之相关的一些问题。

在Tendermint中，轻客户端的区块验证如下；

简化的轻节点与全节点之间的关系

请注意，这是全节点和轻客户端之间关系的简化图。实际上，许多节点参与了对等网络。

ZK轻客户端

因此，轻客户端显然是一个伟大的发明，但我们如何能让它们变得更伟大呢？在Polymer的案例中，他们利用了ZK轻客户端，这是一个新的发明。ZK轻客户端将允许进一步降低信任的最低限度并提高交易效率。通过利用ZK证明，能够将轻客户端验证逻辑编码到电路中，这将使得批量处理区块头的验证更加高效。我们之前简单介绍过区块头，但需要注意一个重要的点是，区块头中还包含前一个区块的哈希，这使我们能创建区块的“链”。本质上，区块头包含的任何数据均不是原始元数据列表本身。

举个例子，假设你的区块链有10,000个1MB的区块，你将在每个全节点上消耗10GB的空间（为了简化示例，我们省略了数据修剪等技术）。然而，仅使用这相同区块对应的区块头，你的空间占用将减少一个数量级。通过利用ZK证明及其递归特性，这种占用进一步减少。关键是，它们允许资源较少的设备进行验证，并使支持轻客户端的区块链能够读取其他的状态。

使用递归ZK证明，可以提高中继过程的效率并使用更少的空间。递归ZK证明是将多个证明聚合为一个单一证明。单个证明仅在所有固有证明有效的情况下有效，并且验证此证明更容易且成本更低。这在证明在链上验证时尤其具有吸引力。数千个证明可以被压缩为一个证明，从而在验证过程中节省大量成本。这是因为递归ZK证明证明了先前有效证明的存在。由于验证本身是一个计算过程，可以在电路中表达。通过这种电路的单一证明，证明一个内部证明的有效性，该内部证明可能包含另一个证明，依此类推。

另一个希望使用递归ZK SNARK进行链上验证的原因是，在以太坊上运行Tendermint“轻客户端”相当昂贵，正如你在本文中所看到的。即便经过优化，验证的实际成本也很高。如果只是验证Tendermint轻客户端验证逻辑在以太坊上，甚至可能超过区块的油气限制。递归验证ZKP将使得链上验证过程变得更简单。

希望使用递归证明来验证区块头的原因是生成多个证明并将其在并行状态下进行递归验证。这意味着单个区块头的验证成本将会在并行状态中降低。这同样意味着你现在只需在链上验证有效性的证明，而不是整个区块头。与我们如何通过ZK-rollups实现扩展类似。

递归ZK证明

实际的链上头验证将会在secp256k1椭圆曲线参数下进行（目前是这样，但也可以使用其他曲线），使用ECDSA算法。secp256k1以系统化的方式构造，使得计算特别高效。因此，如果实现得足够优化，其速度通常比其他曲线快30%以上。secp256k1曲线在比特币和以太坊中均被使用。然而，它并不是最友好的SNARK曲线，因此也将研究其他曲线。

secp256k1椭圆曲线图——实际上，它将看起来像分散的点。

需要注意的是，所有交易及其Merkle树的一般calldata仍需要存储。我们将在下一部分中讨论如何提高这一点的效率。如果你想更深入了解ZK轻客户端及通用ZK证明的实现背后的原因，建议你阅读近期发布的Polymer文章，其中涵盖了这些问题的部分内容。

参考文献

1. https://github.com/tendermint/tendermint/blob/v0.34.x/spec/core/data_structures.md

2. https://github.com/tendermint/tendermint/blob/v0.34.x/spec/light-client/verification/verification_002_draft.md

3. https://docs.rs/tendermint/0.23.7/tendermint/block/index.html

4. https://ipld.io/specs/codecs/dag-cosmos/tendermint_chain/

5. https://pkg.go.dev/github.com/tendermint/tendermint/light

6. https://www.researchgate.net/publication/344663049_A_Tendermint_Light_Client

7. https://learnblockchain.cn/article/12558

8. https://github.com/0xPolygonHermez/pil-stark/blob/main/circuits.bn128/stark_verifier.circom.ejs

Verkle树

Verkle树是一种更高效的状态承诺数据结构。其优势在于能够实现减少证明大小和链上验证成本。一般来说，Merkle/Verkle树提供的能力是确保数据的绑定在最后一个字节上都是相同的，从而使我们能够向区块链节点提供最终性协议。

要理解Verkle树与Merkle树的不同，首先需要了解后者。Merkle树和Verkle树的结构非常相似，但有几个组成部分使它们在状态承诺的数据结构上有很大不同。

在Tendermint/CosmosSDK结构中，Merkle树用于共享节点之间的交易数据，尤其是全节点和轻节点之间，以便轻节点验证某个区块。在这种情况下，轻节点从全节点获得承诺，并获取证人（witness），使得轻客户端能够构造区块头中的根。

在以太坊中，Merkle树用于执行层，区块头由3个Merkle树的根组成。这些是状态根、交易根和收据根。

还有以太坊全局状态树，随着时间的推移而更新，因此随着时间推移也逐渐增大。这也是以太坊未来在不断探索使用Verkle树的原因之一，以最小化以太坊全节点所需存储的状态数量。我们通常称这一过程为无状态性（statelessness）（弱），我们稍后将触及这一点。这同样也巩固了轻客户端兼容性对区块链的重要性，以及为什么以太坊也希望在未来将其添加进去，因为它能够使资源较少的客户端能够验证区块链本身。状态膨胀问题也是为什么历史过期在来自EIP-4844的额外calldata（交易数据）增加的情况下是必要的。一般来说，如果区块链不愿意增加节点的硬件要求，状态膨胀是一个巨大的问题，因为这会妨碍去中心化。解决此问题的方法有很多，其中之一就是Verkle树。

让我们看看Merkle树在纸面上的样子，这将使我们随后了解它们与Verkle树的不同。

Merk树实现

Merkle树中的证人大小为lgxN(x-1)。在Merkle树中，证明是树中与需要被证明的节点路径上的节点共享父节点的整个节点集。这意味着你必须在证人中包括大量节点，以证明承诺。这在非常大的树上会呈指数增长，因为需要证明的树的顶部也会很大。

Merkle树与Verkle树之间的主要区别在于它们如何构造证人以及因此引发的大小。在查看Verkle树结构之前，让我们详细说明一下它们中的证人是如何工作的。首先，需要注意的是，所有的正面都有权衡。在Verkle树的情况下，通过将证人大小移动到lgxN(2)，你会失去计算效率。然而，这使我们能够减少证明的大小，并因此降低链上对证明的验证成本。如果你试图与以太坊进行桥接，这尤其重要，因为目前的油气成本相当高。关于在以太坊进行桥接的链上证明成本有多高，Electron Labs对其"ZK IBC"想法进行了测试计算。为了降低成本，Verkle树和递归证明能与以太坊的许多其他扩展解决方案一起大有帮助。

在Verkle树中，不需要提供所有共享父节点的节点，而只需提供通往根节点的路径。因此，在非常宽的树中，与在Merkle树承诺中提供的所有“姐妹节点”（证人）相比，路径将非常小。对于Verkle树中路径外还需要的额外承诺是向量承诺（vector commitments）（多项式，可以为任意点创建证明，想回顾一下点儿的内容可以参考前面的曲线），这个承诺则替代了Merkle树中的姐妹节点功能。这意味着它们可以证明某个子节点（父节点下的节点）实际上是树中正确的节点，同时只提供路径本身。

简单的Verkle树实现

在证明构造中不需要姐妹节点。你只需提供路径本身以及一些简短的证明，以将路径中的每个承诺链接到下一个承诺。

如果你对Polymer中Verkle树的构建方式感兴趣，强烈建议你查看他们出色的演示文稿，这份精彩的视觉化演示展示了Verkle树的内部构造——链接。起初，Polymer不会使用Verkle树。但是由于状态膨胀和证明验证定价，未来转换使用这种结构是有意义的。因此，Polymer正在为未来做准备。

除Verkle树的基本功能和多项式承诺外，我们可以增加进一步的优化，这些优化可以实现其他多种惊人的未来实现。我们简要概述一下：

这些优化来自多项式承诺所赋予的性质。主要能够为任何长度或路径链接路径中的节点而生成固定大小的证明。这是通过非交互证明的确定性随机数来源，即Fiat Shamir启发（FH），实现的。FH使我们能够通过随机评估实现多证明（multiproofs）。这也是Merkle树和Verkle树之间权衡的地方——证明生成的计算多项式。因此，这个单一的多项式证明可以用来证明正确路径。

高效Verkle树实现

如果你想深入了解如何实现单个高效多证明，强烈建议你查看Dankrad的文章。

Verkle树的实现将允许一些独特和有趣的功能，这可以有助于区块链的扩展性和去中心化。我们特别来看无状态性，并稍微触碰到另一种方法，即状态租赁。两者都是缓解所有区块链面临的状态膨胀的方法。正如Vitalik在大约一年前的“状态过期和无状态性路线图”中指出：“以太坊状态大小正在迅速增长。目前，仅状态就约为35GB，包括所有Merkle证明在内的大小超过100GB，并且每年增加的量约为一半。”

无状态性或弱无状态性（weak statelessness）是仅要求区块提议者存储状态，随后网络中的其他节点可以验证区块而无需持有和存储区块链的状态。这需要Verkle树和多证明的实现，使得客户端能够在不实际持有任何状态的情况下验证全球状态。另一个计划在以太坊上添加到弱无状态性的功能是状态过期，这一点我们之前触及过。进行状态过期时，状态仍然需要存放某个地方。这可以是在归档节点上，或者也可以利用称为状态租赁的方法。

状态租赁是将状态“租用”出来以进行存储，并在链上特定节点或其他链上提供其可访问证明的过程。有多个项目正在研究解决方案，例如Laconic，但是根据Polymer的结构，可以设想出一个使用Polymer进行状态租赁的世界。还有一种方法是可以分散状态，并保持可证明的可检索性。Joachim Neu在模块化峰会上就此提出了一份非常有趣的论文，我们很高兴与Celestia共同举办了这次活动。如果你想了解更多，可以在这里阅读这篇论文。

参考文献

1. https://docs.google.com/presentation/d/1IZqyFgb6VwLBxieR0_wUFdzmAIC_ZAMicbKWL0fidMg/edit#slide=id.g119a168c71b_0_122

2. https://docs.google.com/presentation/d/1zv26gsBiU-xsepXnrpmcBIFVP49QN9jvbbcI_AZKssA/edit?pli=1

3. https://vitalik.ca/general/2021/06/18/verkle.html

4. https://notes.ethereum.org/@vbuterin/verkle_tree_eip

5. https://nethermind.io/verkle-trees/

6. https://github.com/o1-labs/verkle-tree

7. https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html

8. https://github.com/lunfardo314/verkle

9. https://ethereum-magicians.org/t/proposed-verkle-tree-scheme-for-ethereum-state/5805

10. https://beamstart.com/news/merkle-trees-vs-verkle-trees-16609184619683

11. https://eprint.iacr.org/2021/599.pdf

12. https://github.com/polymerdao/go-verkle

13. https://hackmd.io/@vbuterin/state_size_management

在以太坊及其它地方实现递归snarks的IBC

最近，一些团队进行了一项研究，探讨如何在以太坊中实现IBC，在其轻客户端兼容性上线之前。例如，Electron Labs提出了一种经过“版本化”的IBC，其中他们让以太坊上的智能合约充当链上的轻客户端（IBC要求）。这类似于以太坊rollup合约的工作方式。但是，问题在于你实际上是信任一个智能合约（这通常是可升级或由一个中心化团队控制），这显然不允许在协议层面上实现信任最小化的桥接——因为这里的信任应位于连接的两条链的验证者集中。在Tendermint/CosmosSDK链上，IBC的美妙之处在于它们内置支持轻客户端，并使得链能够在协议层面以信任最小化的方式达成一致，开启彼此之间的连接。目前，Electron Labs仅有关于ed25519签名验证的电路，而没有实际的轻客户端逻辑。如果智能合约要作为具备IBC逻辑的轻客户端，其就需要做出其他必要的更改。

那么，Polymer打算如何在以太坊生态系统中提供IBC，包括rollup？让我们深入了解Polymer在GitHub上所做的工作。

目前，在以太坊上实现IBC的最好方法是实施ZK-IBC结构。在这种结构下，验证证明在链上进行，以证明已在连接链上完成的交易的有效性。如前所述，Electron Labs有一篇很好的博客文章，讲述如何实现这一点，但我认为有几件重要的事情需要注意。IBC模块需要转换为solidity，以便正确验证IBC交易，并且我们还需要一个用于Plonky2的solidity验证器（目前这是递归snarks的最快证明系统，这是实现高效zkIBC所需的关键内容）。如果你想跟随Polymer正在进行的Plonky2验证器的开发，强烈建议你查看他们的GitHub。

目前，Polymer已经在开发网络上创建了智能合约，充当以太坊和BSC的链上轻客户端。这使得智能合约能够接收IBC数据包，因为他们已经用solidity重写了IBC模块。同样，Polymer还对 Binance、Avalanche、Fantom、Polygon以及Solana等各种兼容EVM的链进行了测试。

参考文献

1. https://github.com/polymerdao/plonky2-solidity-verifier

2. https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634

Polymer

IBC端到端（e2e）

除了标准IBC，Polymer还将包括一个名为_端到端IBC（end-to-end IBC）_的副产品。这非常适合我们对模块化世界的看法，因为连接的链被视为该产品中的“rollups”。E2E IBC是远程VM，允许原生IBC和轻客户端支持。E2E IBC可以被所有链采用，包括应用特定的、其他Layer 1、Layer 2以及各种执行环境。

这意味着连接的链可以拥有自己的“rollup”，作为远程VM在其中提供轻客户端支持和原生IBC连接。因此，那些通常无法利用轻客户端的链也可以运行一个环境，从而通过IBC逻辑进行连接，且无需自己实施模块。

这些远程VM将通过Polymer通过链间账户智能合约API进行交互。通过这种方式，他们将链通常依赖的网络层解耦，并允许远程VM作为支持原生IBC连接的Polymer扩展进行操作。这意味着Polymer能够代表连接链保持IBC连接。

远程VM将位于非IBC区块链上，以启用IBC逻辑

E2E IBC的状态将在Polymer上进行验证，这与rollup通过轻客户端的方式类似，CosmosSDK和Tendermint均支持此方式。在Polymer方面，将存在IBC智能合约（有时也被称为以太坊上的桥合约）。这些将处理从Polymer到非IBC链的移动。原生轻客户端支持意味着可以轻松实现信任最小化。

Polymer还将包括他们称之为xApps的功能，该功能可以在Polymer之上以rollup形式运行多链应用程序。这将使它们即时能够接入处理交易的各种链。

Polymer理论

Polymer利用现有的Cosmos技术，利用IBC来建立一种通用的IBC路由协议，以启用非Tendermint链之间的端到端IBC连接和通道，这样的链包括Layer 1乃至于Layer 1上构建的rollups。Polymer还在构建其网络协议时采取模块化的方法，以便在堆栈中的每个部分进行优化。

因此，他们将为所有连接的链启用IBC连接，这将允许在基于Polymer构建的应用之间实现原生的跨链组合。Polymer将作为一种链无关的IBC网络层运行，解耦网络层将使rollup IBC作为各链应用逻辑的数据层运作。这是通过使用轻客户端实现的，IBC依赖于轻客户端来增加安全性，并通过利用ZK轻客户端来编码验证逻辑进入电路，使得批量区块头的验证更为高效。

E2E IBC是与远程VM的集成，以便将IBC层从Polymer连接的链解耦。这是通过通过Merkle/Verkle树向rollup链合约发布批量承诺来实现的。通过在未来启用Verkle树，可以减少验证时间和证明大小，这是对Merkle树的“升级”，允许更小的证人。

Polymer因此会维持连接链的IBC连接和通道，实际上可以作为多链IBC rollups，支持可在其上构建的应用程序。这也应该允许在非原生Cosmos链之间实现跨链账户。

Polymer还与Celestia建立了合作关系，通过优化的轻客户端实现的IBC成为构建于Celestia之上的乐观Rollup的桥接提供商。阅读更多内容请点击这里。

如果这听起来有趣，并且希望工作在困扰区块链的问题上，那么Polymer正在招聘——查看他们的职位列表请点击这里。

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