通过回顾我们之前的一些研究文章，我们可能已经很清楚，我们是模块化区块链和特定应用区块链设计范式的信仰者。这样做的一个结果是，我们设想了一个具有很多不同的区块链的世界，用于各种应用、垂直行业等等。我们相信，将会有各种各样的区块链，而且这些区块链会随着应用程序数量的增加而增长。
更多的区块链，无论是以滚动的形式还是其他形式，一个不可避免的结果是，互操作性将变得成倍的重要。因此，随着世界变得越来越模块化，我们预计会看到大量的桥梁出现。我们看到的更令人兴奋的是Polymer。我们将在下面深入探讨他们是如何将IBC带入所有生态系统的。
IBC
区块链间通信（IBC）的核心是同质区块链的跨链信息传递协议。这意味着它连接了具有类似功能的链，在这种情况下，由Tendermint共识算法提供的即时确定性和具有轻型客户端功能的链。IBC的工作方式是，两个有意相互连接的链将在目的地链上提出治理建议。这通常是，首先，通过Cosmos Hub或Osmosis（目前Osmosis有45个对等店，而Cosmos有40个）。这意味着在协议层面上有一个协议，因此，不需要外部桥梁中的可信第三方。
然后，这两条链需要对方链上的一个轻客户端来加密验证两条链之间的共识状态，还需要一个中继器在两条链上的轻客户端之间传递信息。中继器是有效性所必须的——能够在节点之间交换信息，节点成功达成共识的能力。让我们来探讨一下这在实践中是怎样的。
这意味着信任假设在于连接的区块链的两个验证器集，因为这样的信任假设比其他类型的桥和消息传递协议少得多。例如，在Polkadot生态系统中的XCMP，信任假设只在于中继链（Polkadot）。
为了显示IBC在Cosmos生态系统中的兼容性和广泛性，以及它所连接的链的数量–让我们看一下当前的实时连接地图。
mapofzones.com
对于IBC，有两个内涵是需要注意的。这两个是连接和通道。
1. 连接是两个独立链上的有状态对象——CosmosSDK中的IBC模块。
2. 通道是与一个链/应用程序的特定连接，并提供消息传递信息，如订购，这就是所谓的relayer。
ICS
ICS是Interchain Standard（跨链标准）的缩写，为使用IBC的链之间发生的交易设置参数。ICS基本上是IBC交易的模块规范。两条链要使用IBC进行通信，就必须拥有相同的ICS规范。其中一个更有趣和独特的ICS是ICS-27，也被称为跨链账户。
Polymer将支持现有的ICS。因此，连接到Polymer的链子将能够利用更广泛的IBC社区所做的大量工作，而Polymer也是一个长期的贡献者。
轻型客户端
轻客户端是区块链的一个重要组成部分。在目前的形式下，它们使硬件密集度较低的机器能够参与区块链的验证过程，并有助于促进与他人的连接。它们通过只下载区块头而不是整个区块来做到这一点。他们信任诚实的完整节点会提供准确的信息，因此并不是无信任的。有几种类型的轻客户端实现，甚至可以说，以太坊上的Rollup Bridge合约的功能类似于Cosmos生态系统中IBC连接的区块链的轻客户端功能。
轻客户端随着Cosmos生态系统的出现而受到关注，并因其在区块链的扩展功能方面所允许的可能性而获得极大的欢迎。这里我们指的是Celestia如何利用轻客户端参与数据可用性采样，以随着网络中的节点数量而扩展。这将允许轻客户端拥有与完整节点几乎相似的信任假设，同时仍然不需要下载整个区块。这导致轻客户端，以及由此产生的终端用户，成为他们居住的网络的一等公民。
在大多数原始的单体区块链中，用户需要运行一个完整的节点，假如他们想参与验证，就必须存储整个区块链数据。这给去中心化带来了障碍，因为随着区块链的规模和历史的增长，对全节点的硬件要求也在增加。这个问题通常被称为 “状态膨胀”。对于轻型客户端，只要他们连接到一个诚实的完整节点，他们就能够通过扫描区块头来参与，而不是像完整节点那样扫描整个区块。区块头是区块中的一个部分，作为区块其余部分的摘要–例如区块被开采的时间和难度，以及包括交易的根。
轻客户端在PoS链中验证一个区块所需的信息
轻客户端被用于桥接，以促进两个桥接链通过链外中继器的帮助来验证彼此的状态的可能性。通过验证对方的状态机，两个连接的链能够在协议层面上达到彼此之间的最终结果。在目前的轻客户端设置中，这确实意味着有一定程度的信任，正如刚才所解释的那样。在IBC中，链与链之间的连接是由每个链上的轻客户端建立的，以验证链的状态。
中继器根据连接链的状态建立交易，然后提交给网络中的其他节点。在IBC中，这是通过Hermes中继器的实现完成的，且在对中继者给予激励，以实现进一步的去中心化和安全。目前，中继器是手动运行的，许多是由各种验证者运行的，他们也在连接的链上运行完整的节点，通常使他们能够从链间MEV中获得大量的利润。目前正在进行中的中继器激励工作，以减轻这带来的一些问题，Polymer也在其中发挥了积极作用。
Tendermint的轻型客户区块验证如下。
请记住，这是一个完整节点和轻型客户端之间关系的简化图。在实际情况下，许多节点参与了对等网络。
ZK轻型客户端
所以，轻型客户端显然是一个伟大的发明，但我们如何才能使其更加伟大？在Polymer的案例中，他们正在利用ZK轻型客户端，这是一项新发明。ZK轻型客户端将允许增加信任的最小化和交易的效率。通过利用ZK证明，有可能将轻客户端验证逻辑编码到电路中，从而使成批的区块头的验证更加有效。我们在前面简单介绍了区块头，但需要注意的是，区块头中也有前一个区块的哈希值，这就是让我们创建区块 “链 “的原因。从本质上讲，区块头包含了任何不属于原始元数据列表本身的数据。
轻客户端效率的一个很好的例子是，假设你的区块链有10.000个1MB的区块，你将在每个完整的节点上消耗10GB的空间（为了简单起见，我们不考虑数据剪裁等技术）。然而，如果只是对这些相同的块使用块头，你所占用的空间会少一个数量级。通过利用ZK证明和它们的递归性质，这将进一步增加空间。至关重要的是，它们允许资源较少的设备进行验证，支持轻型客户端的区块链可以读取另一个区块链的状态。
通过递归zk证明，可以提高中继过程的效率，并使用更少的空间。递归zk证明是指你采取多个证明，然后汇总成一个单一证明。只有在所有内在证明都有效的情况下，这个单一证明才是有效的，而且它更容易验证，成本更低。当证明在链上被验证时，这一点特别有吸引力。成千上万的证明可以被压缩成一个证明，在验证过程中节省了巨大的成本。这是因为一个递归的zk证明证明了之前有效证明的存在。由于验证本身是一个计算，它可以用一个电路来表达。这个计算/电路上的一个证明证明了一个内部证明的有效性，这个内部证明可能包括另一个证明，如此反复。
想要递归ZK snarks进行链上验证的另一个原因是，在以太坊上运行Tendermint “轻客户端 “是相当昂贵的，正如你在这篇文章中看到的那样。即使它被优化了，实际的验证成本也很昂贵。如果你要在以太坊上仅仅验证Tendermint轻客户端的验证逻辑，甚至有可能超过区块气体的限制。递归验证ZKPs将允许一个更简单的链上验证过程。
想要递归证明来验证区块头的原因是要平行生成几个证明，然后一起递归证明。这意味着，通常验证一个区块头的成本，其中可能只有一个跨链交易，可以递归地平行降低。这也意味着，你现在只需要验证链上的有效性证明，而不是整个区块头。与我们用ZK-rollups实现可扩展性的方式类似。
递归ZK证明
实际的链上头验证将在secp256k1椭圆曲线参数下进行（目前，但也有可能使用其他曲线），采用ECDSA算法。secp256k1是以一种系统化的方式构建的，它允许特别有效的计算。因此，如果实施充分优化，它通常比其他曲线快30%以上。Secp256k1曲线在比特币和以太坊中都有使用。然而，它不是对SNARK最友好的，因此其他曲线也将被研究。
secp256k1的椭圆曲线图–在现实中，它看起来会像散乱的点。
有一点需要注意的是，所有交易的一般calldata和它们的Merkle树仍然需要被存储。我们将在下一节中讨论如何使之更有效率。如果你有兴趣阅读更多关于实现ZK轻型客户端和IBC逻辑与ZK证明背后的推理，那么我建议你去阅读新发布的Polymer文章，它涵盖了这些问题的一部分。
参考文献
https://github.com/tendermint/tendermint/blob/v0.34.x/spec/core/data_structures.md
https://github.com/tendermint/tendermint/blob/v0.34.x/spec/light-client/verification/verification_002_draft.md
https://docs.rs/tendermint/0.23.7/tendermint/block/index.html
https://ipld.io/specs/codecs/dag-cosmos/tendermint_chain/
https://pkg.go.dev/github.com/tendermint/tendermint/light
https://www.researchgate.net/publication/344663049_A_Tendermint_Light_Client
https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98
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树被用来在节点之间共享交易数据，特别是在全节点和光节点之间，以便光节点验证某个区块。在这种情况下，光节点从全节点获得承诺，并获得证人，这使得轻型客户端能够在区块头中构建根。
在以太坊中，Merkle树被用于执行层，其中区块头由Merkle树的3个根组成。这些是状态根、交易根和收据根。
还有以太坊全局状态树，随着时间的推移而更新，因此，也会随着时间的推移而增加大小。这也是为什么以太坊也在探索在未来的版本中使用Verkle树的原因之一，以尽量减少以太坊全节点所需持有的状态量。这就是所谓的无状态（弱），我们稍后会触及这一点。这同样也巩固了为什么轻客户端的兼容性对区块链如此重要，以及为什么以太坊也希望在未来增加它们，因为它使硬件较差的客户能够验证区块链本身。状态膨胀问题也是为什么需要历史过期的原因，因为EIP-4844的结果是增加了calldata（交易数据）的数量。一般来说，如果你没有兴趣或愿意增加节点的硬件要求，状态膨胀是区块链的一个巨大问题，因为它阻碍了去中心化。有各种方法来缓解这个问题，其中之一就是Verkle树。
让我们看看Merkle树在纸上的样子，然后让我们以后能够看到它们与Verkle树有什么不同。
Merkle树的实现
Merkle树中的证人的大小为lgxN(x-1)。在Merkle树中，证明是树中与通往被证明节点的路径上的节点共享一个父节点的整个节点集。这意味着你必须在见证中包括大量的节点，以使你能够证明一个承诺。当然，这在非常大的树中会呈指数级增长，因为你需要证明的树顶也会变得非常大。
Merkle树和Verkle树的主要区别在于它们如何构造它们的证人，因此它们的大小也是如此。在我们看Verkle树的结构之前，让我们详细介绍一下证人在其中是如何工作的。首先，需要注意的是，对于所有的正面来说，都是有取舍的。在Verkle树的情况下，通过移动到lgxN(2)的证人大小，你失去了计算效率。然而，它使我们能够减少证明的大小，因此也降低了证明链上的验证成本。如果你试图与以太坊进行桥接，这一点尤其重要，因为以太坊的气体成本目前来说是相当高的。一个很好的例子是，在以太坊上桥接的链上证明是多么昂贵，看看电子实验室为他们的 “ZK IBC “想法所做的测试计算。为了降低成本，verkle树和递归证明可以与许多其他正在进行的以太坊整体可扩展性解决方案一起提供巨大的帮助。
在Verkle树中，你不需要提供所有共享一个父节点的节点，而只需要提供到根的路径。因此，在一棵非常宽的树上，与Merkle树承诺中必须提供的所有姐妹节点（证人）相比，路径将是相当小的。在Verkle树中，与路径一起需要的另一个附加承诺是矢量承诺（多项式，可以为任何一个点创建证明，如果你想复习一下点，可以参考前面的曲线），它取代了Merkle树中姐妹节点的功能。这意味着它们给出的验证是某个子节点（父节点下的节点）实际上是树中的正确节点，而只提供路径本身。
简单的Verkle树的实现
在树的证明构造中不需要姐妹节点。你只需提供路径本身，加上一些简短的证明，将路径中的每个承诺与下一个承诺联系起来。
如果您有兴趣了解Verkle树是如何在Polymer中构建的，那么我们强烈建议您查看他们对Verkle树内部以可视化方式呈现的精彩介绍——链接。在开始时，Polymer不会使用Verkle树。然而，在未来由于状态的膨胀和证明验证的价格，进行转换是有意义的。因此，Polymer正在为未来做准备。
除了Verkle树和多项式承诺的基本功能外，我们还可以添加更多的优化，这些优化可以使未来有无数其他不可思议的实现。让我们简单介绍一下：
这些优化是通过多项式承诺的属性来实现的。主要是能够做出固定大小的证明，将任何长度或路径上的节点连接起来。这是通过Fiat Shamir Heuristics(FSH)为非交互式证明提供一个确定性的随机性来源来实现的。FSH使我们能够通过随机评估实现多重证明。 这也是Merkle和Verkle树之间的权衡所在–计算多项式的证明生成。这个单一的多项式证明就可以起到证明正确路径的作用。
高效的Verkle树实现
如果你有兴趣深入挖掘单项有效的多重证明是如何实现的，我们强烈建议你去看看伟大的Dankrad关于他们的文章。
Verkle树的实现将允许一些相当独特和有趣的功能，可以帮助区块链的可扩展性和去中心化。让我们特别看一下无状态，同时也略微触及另一种方法，即状态租用。这两种方法都是为了缓解所有区块链都会出现的状态膨胀问题。正如Vitalik在大约一年前的 “状态过期和无状态路线图 “中指出的，”以太坊的状态大小正在迅速增长。目前，仅状态就有35GB左右，包括所有Merkle证明在内，超过100GB，并且每年大约增加一半。”
无状态或弱无状态是指只要求区块提议者存储状态，然后让网络中的其他节点验证该区块，而不必持有和存储区块链的状态。这是需要Verkle树和多重验证的东西，这将使客户能够验证全局状态，而自己实际上不持有任何状态。计划与以太坊上的弱无状态一起增加的另一个功能是状态过期，这一点我们在前面提到过。通过状态过期，状态仍然需要去某个地方。这可能是在存档节点上，或者我们也可以利用一种被称为状态租用的方法。
状态租借是 “租借 “状态来存储的概念，并在其他链上或链上的特定节点中证明其可访问性。有很多项目正在研究允许这样做的解决方案，例如Laconic，但以Polymer的结构，你也可以设想一个Polymer也被用于状态租用的世界。也有一种方法，你可以用可证明的可检索性来分散状态。Joachim Neu在模块化峰会上发表了一篇非常有趣的论文，我们很高兴与Celestia共同主办了这次峰会。
参考文献
https://docs.google.com/presentation/d/1IZqyFgb6VwLBxieR0_wUFdzmAIC_ZAMicbKWL0fidMg/edit#slide=id.g119a168c71b_0_122
https://docs.google.com/presentation/d/1zv26gsBiU-xsepXnrpmcBIFVP49QN9jvbbcI_AZKssA/edit?pli=1
https://vitalik.ca/general/2021/06/18/verkle.html
https://notes.ethereum.org/@vbuterin/verkle_tree_eip
https://github.com/o1-labs/verkle-tree
https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html
https://github.com/lunfardo314/verkle
https://ethereum-magicians.org/t/proposed-verkle-tree-scheme-for-ethereum-state/5805
https://beamstart.com/news/merkle-trees-vs-verkle-trees-16609184619683
https://eprint.iacr.org/2021/599.pdf
https://github.com/polymerdao/go-verkle
https://hackmd.io/@vbuterin/state_size_management
Solidity中的IBC在Ethereum上的应用及以后的递归Snarks
最近几个团队研究的东西是如何在以太坊增加轻量级客户端兼容性之前将IBC带到以太坊。例如，Electron Labs提出了一个IBC的 “版本”，他们让Ethereum上的智能合约充当链上轻客户端（IBC需要）。这类似于桥梁/滚动合约对以太坊滚动的工作方式。然而，这样做的问题是，你本质上是在信任一个智能合约（它通常是可升级的或由中心化团队控制的），这显然不允许在协议层面上进行信任最小化的桥接，因为信任在于连接的两条链的两个验证器组。IBC在Tendermint/CosmosSDK链上的好处是，它们内置了轻量级的客户端支持，它使链在协议层面达成一致，以信任最小化的方式在它们之间建立连接。目前，Electron Labs只有一个用于ed25519签名验证的电路，而没有实际的轻客户端逻辑。为了使智能合约能够作为一个具有IBC逻辑的轻客户端，他们需要进行其他必要的改变。
那么，Polymer是如何计划在以太坊生态系统中提供IBC的，包括滚动。让我们深入了解一下Polymer的GitHub，看看他们到目前为止所做的工作。
目前，实现IBC的最佳方式是实现ZK-IBC结构，以便它在以太坊上发挥作用。这里的有效性证明是在链上验证的，证明在连接链上进行的交易的有效性。如前所述，Electron Labs也有一篇很好的博文介绍了如何实现这一点，但有几件事我觉得确实需要注意。IBC模块需要转换为solidity，以便IBC交易能够被正确验证+我们还需要一个用于Plonky2的solidity验证器（这是目前递归snarks的最快证明系统–这是我们对zkIBC的高效实现所需要的东西之一）。如果你有兴趣跟随Polymer正在进行的Plonky2验证器的开发，我强烈建议你查看他们的GitHub
目前，Polymer已经在devnets上创建了智能合约，作为Ethereum和BSC的链上轻客户端。这使得智能合约能够接收IBC数据包，因为他们已经在Solidity中重写了IBC模块。同样，Polymer也为其他各种兼容EVM的链做了测试，如Binance、Avalanche、Fantom、Polygon和Solana。
参考资料
https://github.com/polymerdao/plonky2-solidity-verifier
https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634
聚合体
IBC e2e
除了标准的IBC，Polymer还将推出一种叫做端对端IBC的副产品。这非常符合我们看待模块化世界形成的方式，因为连接的链子在这个产品中被认为是 “卷轴”。E2E IBC是远程虚拟机，可以实现原生IBC和轻型客户端支持。E2E IBC可以被所有的链采用，包括特定应用、其他L1、L2和各种执行环境。
这意味着连接的链可以有自己的 “卷轴”，作为远程虚拟机工作，其中有轻型客户端支持和本地IBC连接。因此，通常不能利用轻型客户端的链可以有一个环境，他们可以连接和使用IBC逻辑，而不需要实际执行模块本身。
这些远程虚拟机将通过Polymer的链间账户智能合约API进行互动。通过这种方式，他们将链子通常依赖的网络层解耦，而允许远程虚拟机作为支持原生IBC连接的Polymer本身的扩展来操作。这意味着，Polymer能够代表连接的链子维持IBC连接。
E2E IBC的状态将在Polymer上得到验证，就像通常通过轻型客户端进行滚动一样，CosmosSDK和Tendermint支持这种滚动。在聚合体方面，将存在IBC智能合约（有时也被称为Ethereum的桥梁合约）。这些将处理从聚合体到非IBC链的移动。原生的轻客户端支持意味着信任最小化可以轻松实现。
Polymer也将具有他们所谓的xApps，它将作为多链应用程序在聚合体之上以滚动的形式运作。这将使他们能够立即访问各种各样的链，在上面进行结算和处理交易。
聚合物理论
Polymer正在利用现有的Cosmos技术，通过建立一个通用的IBC路由协议，使非Tendermint链之间的端到端IBC连接和通道，如第1层，甚至在这些第1层之上的滚动，来利用IBC的优势。聚合物公司还采取了一种模块化的方法来构建其网络协议，以便在堆栈的每个部分都得到优化。
因此，他们将使IBC连接到所有连接的链上，这将使建立在Polymer之上的应用程序具有原生的链间组合能力。Polymer的功能是作为一个与链无关的IBC网络层，他们通过解耦网络层来实现这一点，这将允许卷起的IBC作为数据层在不同链上的应用逻辑发挥作用。这是通过使用IBC所依赖的轻客户端来实现的，通过使用ZK轻客户端来增加安全性和验证逻辑，允许将验证逻辑编码到电路中，使成批的块头验证更有效率。
e2e IBC是与远程虚拟机的集成，它允许IBC层与聚合体连接链解耦。这是通过通过Merkle/Verkle树发布分批承诺来实现的，以滚动链合同。通过在fturue中启用Verkle树，验证时间和证明大小将被减少，Verkle树是Merkle树的 “升级版”，允许更小的证人。
因此，Polymer将代表连接的链维护IBC连接和通道，这实际上可以作为多链IBC卷的功能，并可以在上面建立应用程序。这也应该允许在非本土的Cosmos链上进行链间结算。
Polymer也与Celestia合作，通过IBC的Optimistic轻客户端实施，成为建立在Celestia之上的Optimistic Rollups之间的桥接供应商。
责任编辑：MK
微信扫一扫 
