如何在链条之间建立信任？

在一个区块链中，链中的每个参与者都借助区块链共识机制建立一个信任体系。所以问题是，在多个区块链的跨链场景中，如何在链之间传递信任？锁链之间的信任是什么？如何建立这种跨链信任？

01

锁链之间的信任是什么？

首先，得出结论：链之间的信任是建立在对另一方链的执行机制的信任基础上的，信任是按照执行机制执行的结果。

原因是从交叉链的基本操作入手。

交叉链的基本操作是本地链只有在另一个链完成一个操作后才能执行另一个操作。如下图所示：a区块链成功执行x操作后，B区块链执行y操作，x操作是y操作的前提。

在上面的操作中，一个请求x被签署并成为一个交易，发送给区块链a，在区块链a达成一致意见后，生成一个区块。块包含块头、事务列表等信息，块头包含共识结果信息。以上信息统称为区块链的执行结果，具体流程如下图所示：

区块链a的执行结果发送给区块链B，在执行请求y之前，区块链B必须首先确定x是否在链上。

判断方法是在区块链B的运行环境中，验证与A、X相关的执行结果是否有效，如果验证通过，则表示X已被放入链中，B区块链可以继续执行以下步骤：发送请求y，在B区块链中上传链。

需要注意的是，这种操作是基于区块链B必须信任区块链a的执行机制的前提下，区块链a上正确的执行结果代表了区块链a上各方的意愿，为了验证区块链a上的一笔交易是否有效，区块链B必须信任执行机制根据a区块链的执行机制，验证a区块链的执行结果，判断a区块链上的一笔交易在链上。

由此可见，在整个过程中，通过验证对方链的执行结果来确定请求是否在链上，是建立跨链信任的核心步骤。因此，链与链之间的信任是以信任另一链的执行机制为前提的，而信任是与执行机制一致的执行结果。

02

链间信任的建立需要四个层次的验证

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

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

块连续性验证：在验证开始时，需要确认数据源。基于区块链的连续性，需要验证该区块是否属于指定区块链，以防止攻击者伪造任意区块链的区块。

区块共识：确认来源后，需要验证区块是否代表另一链的整体意愿。该步骤验证块的一致性信息是否满足要求，防止攻击者在未达成一致的情况下锻造块。

验证交易是否存在：验证区块合法后，需要验证指定交易是否属于该区块。不同的链有不同的验证方法，这将在下一节中介绍。

验证事务是否正确：在验证事务是否存在后，并不意味着该事务确实是跨链场景中的预期操作。还需要根据业务场景判断交易的具体内容是否符合预期。

只有通过以上四个层次，验证才能通过。验证后，表示操作在对方的链上，本地链可以执行以下步骤。

03

不同层次验证机制的实现方案

上一节描述的四层验证在不同的区块链上有不同的实现方法。wecross的插件框架定义了一个通用的编程接口。开发人员只需要根据链类实现四个级别的验证逻辑。

接下来，我们来看看每个级别的具体实现。

试块连续性

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

在wecross中，为了验证区块链的连续性，只需根据相应链的实现情况依次验证区块链。

试块一致性

块一致性验证是验证块的一致性信息是否满足相应的算法条件。不同的算法有不同的实现。本文介绍了两种具有代表性的一致性算法：pow（工作负载证明）和pbft（实用拜占庭容错）。

POW算法属于最终一致性算法，通过最长链和延迟确认使一致性结果逐渐收敛和一致。Wecross提供了pow验证所需的步骤：

验证难度：验证块的nonce是否满足工作负载证明条件

验证延迟：验证当前块是否低于已知的**块n块（n可以取10，表示1小时前的块）

检查最长链条：引入多方核实当前区块在最长链条上，防止单边谎称**区块高度，锻造分叉链作恶

pbft算法在多方达成共识后立即达成一致，区块链不存在分叉和回滚的可能。在该算法中，节点之间通过多次广播来达成共识。

在一个块中，足够数量的签名代表块的合法性。因此，在wecross中对pbft的验证相对简单

配置公钥：预先配置对方链**识节点的公钥

签名验证：使用预先配置的公钥验证块中签名的有效性，判断有效签名的个数是否满足pbft共识条件

检查交易是否存在

SPV（简单支付验证）和背书策略是其中的代表。

SPV的初衷是实现轻客户端，目前已经在大多数区块链上实现。随着交叉链技术的兴起，这种技术也被用来验证数据块中是否存在数据。

以事务为例，块头记录当前块中所有事务哈希组成的Merkle树的树根，即“事务根”任何事务都只对应于事务根的Merkle路径。对于块中不存在的事务，无法伪造事务根的Merkle路径。

因此，在wecross中，我们只需要验证事务的Merkle路径就可以确定事务是否属于块。

hyperledger fabric采用背书策略。在fabric中，每个交易都必须满足预定义的认可策略。

交易执行时，会有多个背书人签字。当所有当事人的签名符合背书政策时，交易被视为有效。Fabric将认可节点签名信息保存为块中事务的一部分。多个事务在块内形成一个事务列表。计算以二进制表形式记录的事务的哈希值。

因此，在目前wecross的实现中，我们只需要判断事务是否在事务列表中（且相应的标志有效），并验证事务列表的哈希值，即可初步判断事务的存在。

未来，wecross将结合背书策略对交易的背书节点签名进行验证，从而进一步提高交易存在性验证的有效性。

交易已核实无误

验证事务是否正确，就是根据业务的预期参数判断前三步验证的事务哈希（或二进制）是否是业务期望的操作。

例如，如果预期的操作是transfer（a，B，100），则无法获取相应的事务内容（a）。验证时，需要根据事务的编码方式和哈希算法，验证期望的业务参数是否与事务哈希（或二进制）对应。不同区块链实现之间的差异只体现在交易编码和哈希算法上。根据链的实现，可以使用相应的方法进行验证。

wecross中不同链中的插件实现不同的验证逻辑。FISCO bcos插件使用RLP编码和SHA-256哈希算法验证事务哈希是否正确；fabric插件使用protobuf编码验证事务二进制是否正确。

04

完整验证过程示例

为了更直观地解释，下图显示了FISCO BCO的完整验证过程。

当一个链得到另一个链的执行结果时，可以在本地进行验证。

在块检查连续性方面，FISCO-bcos通过比较块头中父块的哈希值与实际的父块哈希值来验证块是否为方链的块。

在区块一致性验证中，检查当前区块的签名列表，确定合法签名的数量是否满足pbft共识条件，当前区块代表另一个链的整体意愿。

通过验证从交易哈希到交易根的Merkle路径的正确性，可以判断该交易已经存在于区块链上。

通过验证业务期望、事务二进制和事务哈希之间的对应关系，可以判断事务是业务期望的操作。四个层次的验证通过后，表明该业务的预期经营已经在对方的链条上，验证完成。

05

总结

链与链之间的信任是以信任对方链的执行机制为前提的，信任是与执行机制相一致的执行结果。执行结果是否正确取决于四个级别的数据。验证机制在不同的链中实现不同，wecross提供插件支持。