关注:波卡跨链信息的解决方案

  过去几个月,Web3基金会的研究团队一直在撰写一篇概述跨链消息传递(XCMP)的文章。跨链消息传递是Web3基金会旗舰协议Polkadot的重要组件,是Polkadot协议的子集。它定义了如何在中继链之间传递消息,而不需要中继链的经济安全性之外的其他信任假设。本文涵盖了平行链通信协议,很大程度上依赖于Polkadot独特的中继链架构和设计。
头等仓APP下载

 关注:波卡跨链信息的解决方案

过去几个月,Web3基金会的研究团队一直在撰写一篇概述跨链消息传递(XCMP)的文章。跨链消息传递是Web3基金会旗舰协议Polkadot的重要组件,是Polkadot协议的子集。它定义了如何在中继链之间传递消息,而不需要中继链的经济安全性之外的其他信任假设。本文涵盖了平行链通信协议,很大程度上依赖于Polkadot独特的中继链架构和设计。

该协议涵盖:

· 共识方面:消息排队和排序的机制。

· 配合中继链的其余链,尤其是GRANDPA的终结性:数据可用性。

· 配合平行链验证功能:消息输入和输出。

· 本文还回顾了交付,如何实现一致的历史记录以及防止DoS攻击的思路。最后,结合SPREE回顾了XCMP,总结了XCMP实现的属性。

本文未涵盖消息语义和网络详细信息(例如查找对等节点)。

介绍

Polkadot“1.0版”的一个关键特性是,让原本孤立的平行链在担保的情况下,以一种安全、无需信任的方式发送信息。

当前,我们几乎将“交易”定义为“消息”。两者都是引用接收链以外的数据,都要求链引用数据要遵循链的内部逻辑。

由于实际系统中通常存在的某种程度的延迟,链无法拒绝或混淆数据的含义。例如,在比特币环境中,这种属性意味着比特币中有缺陷或恶意的矿工无法重新定向资金,因此是良性加密经济共识系统的基础。

交易和消息之间的主要区别在于,交易中包含证明数据来源的签名(证明指令的权威性),而消息的来源则仅通过Polkadot的内部抗拜占庭的加密经济基础设施来证明,与以太坊内部合约消息传递的方式几乎相同。

示例

在详细介绍XCMP的每个组件之前,先来看一个示例,如何将智能合约平行链上的出口消息(图1中的A),连接到去中心化金融(DeFi)平行链的入口队列中(图1中的B),将消息打包进DeFi平行链整理者的下一个候选区块中。

在中继链区块300,智能合约平行链给“32”端点发送消息,也就是DeFi平行链的平行链ID。这条消息将首先包含在智能合约平行链的出站或出口队列中。

智能合约平行链的全节点开始在网络中gossip发送消息。如果智能合约平行链的某些节点也是DeFi链的全节点,而且,这些全节点也通过转发消息充当两个gossip网络之间的连接点。如果网络上可以遍历的共享节点,则调用后备机制。

一旦消息到达DeFi平行链的整理者后,整理者接收消息(及其收到的任何其他消息),并将消息输入到入站或入口队列中,等待下一个候选区块进行处理。

 关注:波卡跨链信息的解决方案

图1:两条平行链A和B,以及它们对应的整理者和全节点。有两个节点既是A网络全节点,也是B网络的全节点(头等仓:粉色长条为A链,蓝色长条为B链,蓝色小球为B链的整理者,粉色小球为A链整理者,绿色与黄色小球为共同的全节点)。

DeFi平行链上的整理者将为中继链区块301生成一个候选区块。候选区块需要证明它从A区块中引用的是正确的消息。中继链区块300包含A区块的平行链头,少量包含消息根哈希的数据,用于验证消息。

候选区块将打包中继链的轻客户端证明,也就是中继链的消息根,将消息根与发送链发送的消息证明结合起来。

DeFi链的平行链验证人可以用这些证明来验证DeFi链候选区块的完整性。然后,智能合约链的来源消息将包含在DeFi全节点中,无需其他信任假设,并且依赖于Polkadot的100%安全性。

排队和排序消息

Polkadot中的每条平行链区块都可能生成空白的消息列表,路由到其他各个区块,这叫做出口队列。消息路由后,便进入平行链的入口队列。平行链必须按顺序处理入口列表。

整理者或验证人要为某个特定的平行链出口队列收集消息,调用入口队列,在广播池搜索相关消息,等待还未参与gossip的节点。

传递信息

假设每条平行链都有一个连接全节点的网络,每个全节点都知道其他全节点的子集,这里的子集也就是相邻的节点。但我们不对这些网络的拓扑和直径做任何假设。

发送消息的最简单方法是使用gossip协议。回想一下,对等节点之间经常就当前的叶子视图相互通信。要实现更高效的传递,未选择路径的消息仅被广播到具有相同视图的相邻节点。

如果这两个网络之间存在同一节点,则消息可以从一条平行链网络广播到另一条平行链网络。

 关注:波卡跨链信息的解决方案

图2:使用gossip的传递消息。假设消息是由生成最新平行链区块的粉色整理者发出。

撤回发送

但是,如果B链验证人认识到消息没有在自己的全节点广播,则B链(接受方)验证人向A链(发送方)的验证人请求信息。一旦B链验证人收到了消息,就在B链的网络进行广播。

 关注:波卡跨链信息的解决方案

图3:当发送方A链和接收方B链之间没有共同的全节点时,消息被撤回发送

撤回发送原理如图3所示,我们假设的是平行链A想要向平行链C发送消息,但两条链间没有任何共同全节点。一旦平行链C的验证人注意到消息没有发送到A链上,C链验证人就会向A链验证人请求消息,A链的验证人负责把关链上的出口消息。一旦C链验证人的请求的消息得到响应,C链的验证人将消息广播给C链。

获取一致的交易历史

我们希望从XCMP获得的一个关键属性是规范的平行链区块,即我们就这些发生过的交易达成一致。这意味着,当前的平行链区块,只处理平行链区块发送的消息,这些平行链区块是规范的,并早于当前的平行链区块。

中继链定义所有平行链的历史。例如,平行链B的区块头是在中继链区块301中,可以说区块301处理了区块300的所有消息,这样的话,当且仅当A链的区块头出现在中继链区块300中,或更早的区块中时,区块301应该处理平行链A的平行链区块发送的消息。

这意味着中继链要担起验证消息的角色。而我们又不能在平行链头放入大量数据,中继链本身不能有消息负载。所以,我们使用嵌套的Merkle树来有效地保持一致的历史记录。中继链的区块头中相应的已发送消息会有单独的消息根哈希,也就是默克尔树的根。

反过来,此默克尔树的叶子是从该平行链到另一条平行链的消息的哈希链的头部。

这意味着有一个包含每条消息哈希的哈希序列,验证所有从一条平行链发送到另一条平行链的消息(哈希过的消息)。这样的话,整理者可以构建一个由多条消息组成证明,证明处理了这些消息,也只有这些消息经过他们处理。整理者可以通过先展示中继链中的消息根,然后给出一个证明,证明这些消息来自消息根哈希的方式来做到。

输入和输出验证

回想一下,Polkadot由一条中继链和许多(暂定最多100条)平行链组成。

平行链头部包含出口消息的消息根。要在平行链上生成一条平行链区块,而这个平行链区块构建在特定的中继链区块上,整理者需要查看在这条中继链与包含平行链前一条平行链区块头的中继链之间,构建了哪些平行链头部。要获得这些消息,平行链需要处理相关的消息数据。

关注:波卡跨链信息的解决方案                                                 图4:显示了在0、1、2三轮当中,为三条平行链A、B、C平行链构建的平行链区块,以及每轮当中,这三条平行链发送的消息。

平行链状态转换验证函数(简称STVF)使用验证函数来检验是否有处理输入消息。验证函数是WebAssembly的一段代码,用于检查平行链的状态转换是否真实有效。它将平行链的新状态和一组输出消息,关联到平行链的前一状态摘要、平行链区块数据以及一组从其他平行链或中继链路由的真实输入消息。

图4是一个在0、1、2三轮中,A、B、C三条链之间生成的平行链区块和消息的示例。假设B链在0轮没有生成任何平行链区块,C链在第1轮没有生成区块。在第1轮生成平行链区块B1,需要将消息m1作为输入消息,并通过发送消息m3在第1轮将消息复述给平行链A。在第2轮生成的平行链区块C1,需要将消息m2和m4放入未处理的输入队列中。

消息的可用性

一旦消息包含在出口队列中,发送链全节点的整理者和全节点就会保留这些消息。当发送链区块的头部已包含在中继链中时,接收链验证人还将保留消息。接收链的整理者和全节点还需要注意在平行链之间发送的消息的有效负载。所有其他需要了解消息是否存在的实体都只能存储哈希,用于验证消息。

为了保证可用性,我们要求所有验证者都持有擦除编码的片段,这些片段可以恢复任何平行链消息。这些擦除编码的片段是由发送链的平行链验证人生成和分发的。拥有擦除编码片段的1/3足以恢复所有消息。最终性要求这些擦除编码的片段必须已被选民(验证人)接收,否则将因投票而受到惩罚。因此,一旦达成最终性,必须有2/3的擦除编码片段。因此,我们可以保证最终消息也可用。

防止DoS攻击

XCMP的作用不是确定消息的所有标准格式。但是,每条平行链可以限制发送到另一条平行链的消息的整体大小。而且,gossip协议使用边界传递,避免了较大的开销。 

对于平行线程这种较少使区块进入中继链的情况,未处理的消息队列可能会大大增加。为此,发送方平行链将为此链保留一个限制消息大小的出口队列。仅当知道已收到旧消息时,才能删除旧消息。接收链发布一个水印,说明已经处理到哪个区块号的消息,以及包括了哪些平行链。发送链可以使用此水印来修剪自己的出口队列。

而且,我们打算设计让接收链可以阻止另一条平行链发送的消息(此功能尚未实现)。平行线程还可以禁用XCMP功能,避免必须处理大量消息。

XCMP和SPREE

共享受保护的运行时执行区域(SPREE)是类似于运行时模块的逻辑片段,但它们是中继链上的逻辑,平行链可以选择是否应用这些逻辑。

这些逻辑片段是WebAssembly代码的blobs,通过治理机制或平行链上传到Polkadot。将Blob上传到Polkadot后,其他平行链可以决定是否加入逻辑。 SPREE模块将独立存储,与平行链不关联,但是可以通过平行链的接口调用。平行链同步将消息发送到SPREE模块。

如果将XCMP消息寻址到SPREE模块,可以确保当处理消息时,其他平行链会使用SPREE模块中的同一段代码。

SPREE模块对整个XCMP体系结构很重要,它们保证对代码的某种解释在目标全节点上执行。尽管XCMP保证会传递消息,但不能保证会执行什么代码,即无法保证接收链如何解释消息。 

SPREE模块代码会在平行链之间同时更新。除了具有安全优势外,还无需协调多条平行链更新,就可以更改消息格式。

总之,虽然XCMP传递了无需信任消息,但SPREE是对消息的无需信任解释,也是XCMP得以使用的关键。XCMP消息寻址到SPREE模块,使分发消息的开发人员和用户清楚如何处理消息。

总结XCMP的属性

XCMP方案具有以下属性:

无需信任,由于相同的验证人可以确保平行链彼此安全,同时还可以确保传递正确的消息,因此XCMP所需要的信任并不多于单一区块链。

一致性,提供绝对保证,即使有任何链重组,收到的消息也正是发送的消息。

可用性,通过分发可重建消息的擦除码片段,Polkadot保证消息不会丢失并保持可用状态。

保持正确的顺序,通过输入与输出验证,确保平行链区块的输出信息是正确的顺序。

高效,避免了过多的带宽开销,保持消息尽快送达。

本文由 区块链资讯平台头等仓 作者:Mark 发表,其版权均为 区块链资讯平台头等仓 所有,文章内容系作者个人观点,不代表 区块链资讯平台头等仓 对观点赞同或支持。如需转载,请注明文章来源。
头等仓APP下载

发表评论