跨链 如何建立链间信任？

在一条区块链中，链上各参与方借助区块链共识机制建立信任体系。那么问题来了，在多条区块链的跨链场景中，链与链间的信任如何传递？链间的信任，信的是什么？这种跨链信任，又该如何建立？

建立链间信任，需经四层验证

执行结果虽然在不同区块链有不同实现方式，但万变不离其宗，区块链的核心数据结构是以区块为单位的链式结构，交易存在于区块中（本文不讨论DAG形式的区块链）。

因此，我们可将执行结果的验证划分为以下四层：

验区块共识：此步骤验证区块的共区块被验证合法后，需验证指定交易是否属于此区块。各层次验证机制的实现方案

上节所述四层验证，在不同区块链上有不同的实现方式。WeCross的插件化框架，定义了通用的编程接口，开发者只需按照链类型实现四个层次的验证逻辑即可。

下面，我们来看看各层次的具体实现方案。

  验区块连续

在不同区块链上的实现大同小异。当前区块中记录着上一个区块的哈希值，当前区块的哈希值又在下一个区块中被记录，多个区块依次相连形成区块链。不同区块链只在哈希算法和计算区块哈希的字段上存在差异。

在WeCross中，验证区块链连续性，只需按照相应链的实现，验证区块依次相连成链即可。

  验区块共识

验区块共识，即验证区块的共识信息是否符合对应的算法条件。不同算法有不同的实现。此处给出最具代表性的两种共识算法：POW（工作量证明）和PBFT（实用拜占庭容错）。

• 验难度：验证区块的nonce是否满足工作量证明条件
• 验延迟：验证当前块是否低于已知最高块N个块（N可取为10，表示1个小时前的区块）

• 验最长链：引入多方，验证当前区块处于最长链上，防止单方面谎造最高块高和伪造分叉链进行作恶

PBFT算法在多方共识后立即达成一致，区块链不存在分叉和回滚的可能。在算法中，节点通过多次相互广播签名以达到共识。

• 配置公钥：事先配置对方链共识节点的公钥

• 验签名：用事先配置的公钥验证区块中签名的有效性，并判断有效签名数量是否达到PBFT共识条件

  验交易存在

验交易存在同样需要根据不同实现判断，比较有代表性的是SPV（简单支付验证）和背书策略。

SPV的初衷是为了实现轻客户端，目前已在大多数区块链上实现。随着跨链技术兴起，此技术也被用作验证区块中某数据的存在性。

以交易为例，区块头中记录了当前区块内所有交易哈希组成Merkle树的树根，即“交易根”。任何一笔交易，都唯一对应了一条通向交易根的Merkle path。区块内不存在的交易，无法伪造出通向交易根的Merkle Path。

因此，在WeCross中只需验证某交易的Merkle Path，即可判断某交易是否属于某区块。

背书策略为Hyperledger Fabric所采用。在Fabric中，每笔交易都需满足某个事先定义好的背书策略。

交易在执行时会被多个背书节点签名，当各方签名满足背书策略时，此交易才被认为有效。Fabric将背书节点签名信息作为交易的一部分保存于区块中。多笔交易组成区块内的交易列表。交易列表以二进制形式计算哈希值，此哈希值被记录于区块头中。

因此，在WeCross目前的实现中，仅需判断交易是否在交易列表中（且对应flag有效），并校验交易列表哈希值，即可初步判断交易的存在性。

WeCross后续将结合背书策略，验证交易的背书节点签名，进一步增强交易存在验证的有效性。

  验交易正确

验交易正确，是根据业务的预期参数判断前叁步验证的交易哈希（或二进制）是否是业务预期的那个操作。

例如，预期操作为transfer(a, b, 100)，则相应的交易内容不能是get(a)。验证时，需根据交易的编码方式和哈希算法，校验业务预期参数与交易哈希（或二进制）是否对应。不同区块链实现的差别只体现在交易编码和哈希算法上，根据链实现采用相应方法进行校验即可。

WeCross中不同链的插件实现了不同的校验逻辑。FISCO BCOS插件采用的是RLP编码和SHA-256哈希算法，验证的是交易哈希是否正确；而Fabric插件则采用ProtoBuf编码，验证的是交易二进制是否正确。

总结

链间的信任，以信任对方链的执行机制为前提，信的是符合执行机制的执行结果。执行结果是否正确，验的是四个层次的数据。验证机制在不同链有不同的实现，WeCross以插件化的方式提供支持。

目前WeCross已实现FISCO BCOS和Hyperledger Fabric的互认互通，更多区块链平台的接入方案正在热烈讨论中，欢迎加入，共同推动跨链基础设施的发展！