看 Polymer 如何将IBC引入所有生态系统

我们相信将会出现各种各样的区块链，而且这些区块链会随着应用程序数量的增长而增长。

更多的区块链带来的一个不可避免的结果是，互操作性将变得越来越重要。因此，随着世界变得越来越模块化，我们预计会出现大量的跨链桥。我们看到的最令人兴奋的是Polymer。我们将在下面深入探讨他们如何将IBC引入所有生态系统。

IBC

区块链间通信(IBC)的核心是同质区块链的跨链消息传递协议。这意味着它连接了具有类似功能的链，在本例中是Tendermint共识算法提供的即时确定性和具有轻客户端功能的链。IBC的运作方式是，两个有兴趣相互连接的链将在目标链上提出治理建议。这通常是通过Cosmos Hub或Osmosis(目前Osmosis有45个peer，而Cosmos有40个)来实现的。这意味着在协议层面上存在一致，因此，在外部跨链桥中不需要可信的第三方。

然后，这两条链需要对方链上的轻客户端以加密方式验证两条链之间的共识状态，此外还需要一个中继者在两条链上的轻客户端之间传递信息。让我们来探索一下这在实践中是怎样的：

这意味着信任假设位于连接的区块链的两个验证者集合中，因此与其他类型的跨链桥和消息传递协议相比，信任假设要少得多。例如，对于Polkadot生态系统中的XCMP，信任假设完全取决于中继链(Polkadot)。

为了展示IBC在Cosmos生态系统中的兼容性和广泛程度，以及它连接了多少条链，让我们看一看当前的实时连接图：

关于IBC，有两个重要的含义需要注意。那就是连接和通道：

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

2. 通道是与链/应用程序的特定连接，它将提供订购等消息传递信息，这就是所谓的中继者。

ICS

ICS是Interchain Standard的缩写，为使用IBC的链之间发生的交易设置参数。ICS基本上是IBC交易的模块规范。两条链要使用IBC进行通信，就必须拥有相同的ICS规范。其中一个有趣且独特的ICS是ICS-27，也被称为链间账户。

Polymer将支持现有的ICS。因此，与Polymer相连的链将能够利用Polymer长期贡献的更广泛的IBC社区所做的大量伟大工作。

轻客户端

轻客户端是区块链的重要组成部分。在目前的形式中，它们使硬件密集型较低的机器能够参与区块链的验证过程中，并有助于促进与其他设备的连接。它们通过只下载区块头而不是整个区块来实现这一点。他们相信诚实的全节点能够提供准确的信息，因此不是无信任的。

轻客户端随着Cosmos生态系统的出现而受到关注，并因其在区块链扩展功能方面所允许的可能性而获得了极大的欢迎。这里我们指的是Celestia如何利用轻客户端参与数据可用性抽样，以扩展网络中的节点数量。这将允许轻客户端拥有与全节点几乎相似的信任假设，同时仍然不需要下载整个区块。这导致轻客户端和终端用户成为他们所在网络的一等公民。

在大多数原始的单体区块链中，用户被要求运行一个全节点，如果他们想要参与验证，他们必须在那里存储整个区块链数据。这为去中心化带来了障碍，因为随着区块链的规模和历史的增长，对全节点的硬件要求也在增加。这个问题通常被称为state bloat。对于轻客户端，只要他们连接到一个诚实的全节点，它们就能够通过扫描区块头来参与，而不是像全节点那样扫描整个区块。

这是全节点和轻客户端之间关系的简化图。在实际情况下，许多节点都参与了点对点网络。

ZK轻客户端

因此，轻客户端显然是一个伟大的发明，但我们如何使其更伟大呢？在Polymer的案例中，他们正在使用ZK轻客户端这项新发明。ZK轻客户端将允许增加信任最小化和交易效率。通过利用ZK证明，我们可以将轻客户端验证逻辑编码到电路中，从而更有效地批量验证区块头。但是需要注意的是，区块头中还包含前一个区块的哈希值，这就是我们能够创建区块“链”的原因。从本质上讲，区块头包含了不属于原始元数据列表本身的数据。

轻客户端效率的一个很好的例子是，假设你的区块链有10.000个1MB的区块，那么你将在每个全节点上消耗10GB的空间。然而，通过对相同的区块使用区块头，你所占用的空间会少一个数量级。利用ZK证明及其递归性质将进一步提高这一点。至关重要的是，它们使资源较少的设备可以执行验证，并允许支持轻客户端的区块链读取另一个区块链的状态。

利用递归zk证明可以提高中继过程的效率，并使用更少的空间。递归zk证明是指你采取多个证明，然后将其汇总成一个单一证明。只有在所有内在证明都有效的情况下，这个单一证明才是有效的，而且验证起来容易得多，成本也低得多。当在链上验证证明时，这一点特别有吸引力。数以千计的证明可以压缩成一个证明，这在验证过程中节省了巨大的成本。这是因为递归zk证明证明了之前有效证明的存在。

另一个需要递归ZK snark进行链上验证的原因是，在以太坊上运行Tendermint“轻客户端”非常昂贵。即使进行了优化，实际的验证成本也很昂贵。如果你只是想在以太坊上验证Tendermint轻客户端的验证逻辑，它甚至有可能超过区块的gas限制。递归验证ZKP将使链上验证过程更加简单。

之所以要用递归证明来验证区块头，是为了并行地生成几个证明，然后一起递归地证明它们。这意味着验证单个区块头(其中可能只有单个跨链交易)的通常成本可以并行递归地降低。这也意味着你现在只需验证链上的有效性证明，而不是整个区块头。这与我们用ZK-rollup实现可扩展性的方式类似。

实际的链上区块头验证将在ECDSA算法的secp256k1椭圆曲线参数下进行。secp256k1是以一种系统的方式构建的，这使得计算特别高效。因此，如果实现得到充分优化，它通常比其他曲线快30%以上。Secp256k1曲线在比特币和以太坊中都有使用。然而，它不是对SNARK最友好的，因此我们也将研究其他曲线。

需要注意的一点是，仍然需要存储所有交易的通用调用数据及其Merkle树。我们将在下一节中讨论如何使之更有效率。如果你有兴趣深入了解实现ZK轻客户端和IBC逻辑背后的原因，那么我建议你阅读最新发布的Polymer文章，其中涵盖了这些问题的部分内容。

Verkle树

Verkle树是一种更有效的状态承诺数据结构。这样做的好处是可以减少证明的大小和链上证明的验证成本。一般来说，Merkle/Verkle树带来的能力是确保数据的绑定直到最后一个字节都是相同的，这使我们能够向区块链节点提供最终协议。

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

在Tendermint/CosmosSDK结构中，Merkle树用于在节点之间共享交易数据，特别是在全节点和轻节点之间，以便轻节点验证特定区块。在这种情况下，轻节点从全节点获得承诺并获得见证，这使轻客户端能够在区块头中构建根。

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

还有以太坊的全局状态树，它会随着时间的推移而更新，因此也会随着时间的推移而增加规模。这也是以太坊在未来版本中探索使用Verkle树，以最小化以太坊全节点需要持有的状态量的原因之一。这就是所谓的无状态(弱)，我们稍后会触及到这一点。这同样也说明了为什么轻客户端兼容性对区块链如此重要，以及为什么以太坊也在寻求在未来添加它们，因为它使拥有较小硬件的客户端能够验证区块链本身。状态膨胀问题也是为什么由于EIP-4844而增加的调用数据(交易数据)需要历史过期的原因。一般来说，如果你不感兴趣或不愿意增加节点的硬件需求，状态膨胀对区块链来说是一个巨大问题，因为它阻碍了去中心化。有多种方法可以缓解这个问题，Verkle树就是其中之一。

让我们看看Merkle树是什么样子的，这将使我们稍后能够了解它们与Verkle树的区别。

Merkle树中的见证者的大小为lgxN(x-1)。在Merkle树中，证明是树中所有节点的集合，这些节点与通往被证明节点的路径中的节点共享母节点。这意味着你必须在见证中包括大量的节点，以便能够证明承诺。当然，这在非常大的树中会呈指数级增长，因为你需要证明的树的顶部也会变得非常大。

Merkle树和Verkle树之间的主要区别在于它们如何构造它们的见证者，因此它们的大小也不同。在我们研究Verkle树的结构之前，让我们详细介绍见证者是如何在其中工作的。首先需要注意的是，所有积极的事情都有权衡。在Verkle树的情况下，移动到lgxN(2)的见证大小会降低计算效率。然而，它使我们能够减少证明的大小，因此也降低了证明的链上验证成本。如果你试图在以太坊之间进行桥接，这一点尤其重要，因为以太坊目前的gas成本相当高昂。为了降低成本，verkle树和递归证明可以与整个以太坊的许多其他可扩展性解决方案一起提供极大的帮助。

在Verkle树中，不需要提供共享母节点的所有节点，只需要提供到根的路径。因此，在一棵非常宽的树上，与Merkle树承诺中必须提供的所有姐妹节点(见证)相比，路径将是相当小的。在Verkle树中，与路径一起需要的另一个附加承诺是向量承诺(多项式，它可以为任何点创建证明)，它取代了Merkle树中姐妹节点的功能。这意味着它们会验证某个子节点(母节点下的节点)是否确实是树中的正确节点，而只提供路径本身。

在树中的证明构造中不需要姐妹节点。你只需给出路径本身，加上一些简短的证明，将路径中的每个承诺与下一个联系起来。

如果你有兴趣了解Verkle树是如何在聚合物中构建的，如何在Polymer中构建的，那么我们强烈建议你查看他们对Verkle树内部情况的精彩介绍。在开始时，Polymer不会使用Verkle树。然而，在未来由于状态的膨胀和证明验证的价格，进行转换是有意义的。因此，Polymer正在为未来做准备。

除了Verkle树和多项式承诺的基本功能之外，我们还可以添加进一步的优化，以支持无数其他不可思议的未来实现。让我们简单介绍一下：

这些优化通过多项式承诺所支持的属性实现。主要的能力是使固定大小的证明将任何长度或路径上的节点连接起来。这是通过Fiat Shamir Heuristics(FSH)为非交互式证明提供一个确定性的随机性来源来实现的。FSH使我们能够通过随机评估实现多重证明。这也是Merkle和Verkle树之间的权衡所在——计算多项式的证明生成。这个单一的多项式证明就可以起到证明正确路径的作用。

如果你有兴趣深入研究如何实现单一有效的多重证明，我们强烈建议你查看Dankrad的文章。

Verkle树的实现将允许一些相当独特有趣的功能，有助于区块链的可扩展性和去中心化。让我们特别看一下无状态，同时也略微触及另一种方法，即状态租用。这两种方法都是为了缓解所有区块链的状态膨胀问题。正如Vitalik在大约一年前的“状态到期和无状态路线图”中指出的那样：“以太坊的状态大小正在迅速增长。目前，仅状态就有35GB左右，包括所有Merkle证明在内的容量超过了100GB，而且还在以每年大约一半的速度增长。”

无状态或弱无状态是指只要求区块提议者存储状态，然后让网络中的其他节点验证该区块，而不必持有和存储区块链的状态。这需要Verkle树和多重证明，这将使客户端能够验证全局状态，而无需实际持有任何状态本身。计划在以太坊上与弱无状态一起添加的另一个附加功能是状态到期。在状态到期的情况下，状态仍然需要去往某个地方。这可能是在存档节点上，或者我们也可以使用一种称为状态租用的方法。

状态租用是“出租”要存储的状态并在其他链上或链本身的特定节点内证明其可访问性的概念。Laconic等各种各样的项目正在研究这种解决方案，但以Polymer的结构，你也可以设想一个Polymer也被用于状态租用的世界。还有一种方法可以通过可证明的可检索性来分散状态。Joachim Neu在模块化峰会上发表了一篇非常有趣的论文，我们很高兴与Celestia共同主办了这次峰会。如果你想了解更多，你可以阅读该论文。

以太坊上Solidity中的IBC及递归snark

最近有几个团队在研究如何在以太坊添加轻客户端兼容性之前将IBC引入以太坊。例如，Electron Labs提出了IBC的一个“版本”，他们让以太坊上的一个智能合约充当链上轻客户端(IBC需要)。这与以太坊rollup的跨链桥/rollup合约的工作方式类似。然而，这样做的问题是，你实际上信任的是一个智能合约(它通常是可升级的或由中心化团队控制的)，这显然不允许在协议层面上实现信任最小化的桥接。Tendermint/CosmosSDK链上的IBC的美妙之处在于，它们内置了轻客户端支持，并使链能够在协议层面上达成一致，以最小化信任的方式在它们之间建立连接。目前，Electron Labs只有一个用于ed25519签名验证的电路，而没有实际的轻客户端逻辑。为了使智能合约充当具有IBC逻辑的轻客户端，他们需要进行其他必要的更改。

那么，Polymer打算如何在以太坊生态系统中提供IBC呢。让我们深入了解一下Polymer的GitHub，看看他们到目前为止所做的工作。

目前，在某种程度上实现IBC，使其在以太坊上运行的最佳方法是实现ZK-IBC结构。这里的有效性证明在链上进行验证，以证明在连接链上进行的交易的有效性。如前所述，Electron Labs也有一篇很好的博文介绍了如何实现这一点，但我认为有几件事是需要注意的。IBC模块需要转换为solidity，以便IBC交易能够被正确验证+我们还需要一个用于Plonky2的solidity验证器这是目前对递归snark最快的验证系统——这是我们高效实现zkIBC所需要的东西之一)。如果你对Polymer正在进行的Plonky2验证器的开发感兴趣，我强烈建议你查看他们的GitHub

目前，Polymer已经在开发网络上创建了智能合约，充当以太坊和BSC的链上轻客户端。这使智能合约能够接收IBC数据包，因为他们已经在Solidity中重写了IBC模块。同样，Polymer也为其他各种兼容EVM的链做了测试，如币安、Avalanche、Fantom、Polygon和Solana。

Polymer

IBC e2e

除了标准的IBC之外，Polymer还将推出一种称为端到端IBC的副产品。这非常符合我们看待模块化世界形成的方式，因为连接的链在该产品中被认为是“rollup”。E2E IBC是允许本地IBC和轻客户端支持的远程VM。E2E IBC可以被所有的链采用，包括特定于应用程序的链、其他L1、L2和各种执行环境。

这意味着连接的链可以有自己的“rollup”，作为具有轻客户端支持和本机IBC连接的远程VM工作。因此，通常不能利用轻客户端的链可以拥有一个可以连接和使用IBC逻辑的环境，而无需实际实现模块本身。

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

E2E IBC的状态将在Polymer上进行验证，就像通过CosmosSDK和Tendermint支持的通过轻客户端进行rollup一样。在Polymer方面将会有IBC智能合约(有时也被称为以太坊上的跨链桥合约)。他它们将处理从Polymer到非IBC链的移动。原生的轻客户端支持意味着信任最小化可以轻松实现。

Polymer还将推出所谓的xApp，它将作为多链应用程序在Polymer的基础上以rollup的形式运作。这将使他们能够立即访问各种可在其上进行结算和处理交易的链。

Polymer理论

Polymer正在利用现有的Cosmos技术，通过构建一个通用的IBC路由协议来支持非 Tendermint 链之间的端到端IBC连接和通道，甚至在这些第1层顶部进行rollup来发挥IBC的优势。Polymer还采用了一种模块化方法构建其网络协议，以便在堆栈的每个部分进行优化。

因此，它们将使IBC能够连接到所有相连的链，这将使构建在Polymer之上的应用程序具有原生的链间组合性。Polymer的功能是作为一个与链无关的IBC网络层，他们通过解耦网络层来实现这一点，这将允许rollup IBC作为跨多个链应用程序逻辑的数据层发挥作用。这是通过使用IBC所依赖的轻客户端实现的，通过使用ZK轻客户端，可以将验证逻辑编码到电路中，从而使批量的区块头验证更有效率。

e2e IBC是与远程VM的集成，它允许IBC层与Polymer连接的链解耦。这通过以Merkle/Verkle树发布批量承诺来实现。验证时间和证明大小将通过在未来启用Verkle树而减少。

因此，Polymer将代表连接的链维护IBC连接和通道。这应该也将允许跨非原生Cosmos链的链间帐户。

Polymer还与Celestia合作，通过IBC的Optimistic轻客户端实现成为构建在Celestia之上的Optimistic Rollups之间的桥接供应商。