Songbird / Flare Network状态连接器你了解多少？（下）

Flare Network ｜2022-05-11 23:13

Flare Network推出的状态连接器正是能够解决链下数据请求所使用的工具，它具有全新的安全保障、灵活性且速度更快。

本影片由Flare Network社区长期支持者Tim Rowley制作，不代表官方立场。

影片來源：https://www.youtube.com/watch?v=7hPkV8jktHo&t=176s

区块链网络之间的数据连接受限于各自网络的功能性且缺乏安全性，因而，在链之间能可靠的传递信息来驱动应用程序，就变得尤为重要，这类应用程序就包括在其他网络上允许使用封装代币的链桥。

这样的探讨其实很重要且极具价值，原因就是价值数十亿美元的加密货币依靠着这样的体系在区块链之间传递数据。我们已经见证了当缺乏安全性保障时，发生在Ronin、Wormhole以及Poly Network上的黑客攻击，这三起事件导致的代币损失价值已经接近16亿美元。

除了链桥外，当前区块链还面临缺乏互操作性，其原因是无法访问跨链数据，以允许针对其他区块链的各种数据组，亦或是链下真实世界的API接口的请求和验证。而现在，区块链领域迎来了一系列创新，Flare Network推出的状态连接器正是能够解决链下数据请求所使用的工具，但它具有全新的安全保障、灵活性且速度更快。

RCR协议

状态连接器之奇妙之处在于它的RCR（Request（请求）、Commit（提交验证）、Reveal（揭晓结果））协议和分叉协议。RCR协议允许任何网络参与者、自然人或智能合约对已连接的区块链/接口请求信息验证。其核心目的是验证数据是否存在。听到这，您或许会认为，您将收到一个二进制格式的答案。非也！它会给出答案：您回答请求验证的数据是否在链下真实存在，还会验证原始数据。

RCR是三个英文单词的缩写：Request（请求）、Commit（提交验证）、Reveal（揭晓结果）。这三个单词代表着协议的三个连续阶段，如果您熟悉我们的FTSO（Flare时间序列预言机）系统，就很好理解了，这个RCR协议的运作机制类似于数据提供商（data providers）提交验证并揭晓答案的过程。

Request 请求

在【请求】阶段，任何用户可以向状态连接器发送请求，验证链下某种类型信息。就可请求的信息类型而言，以状态连接器已完成集成的为限。因此，尽管状态连接器能请求大部分类型的数据验证，但这首先得经过构建且通过安全评估，方能成为一个选项。新的数据类型必须明确可确定，这能确保每一个提供者清晰了解如何来处理请求。同时，请求的新数据类型也能通过治理来提交。

Commit 提交验证

下一个阶段就是【提交验证】。这里，认证提供商会处理来自上一个阶段的所有用户请求，并决定每一个请求在链下是否存在。

这一过程也叫做认证（attestation）。每一次认证都会生成哈希，并构建一棵Merkle树，这也是一种极有效率的数据存储方式。但重要的是，另一个哈希会从所有哈希认证中创建。这个哈希就被称为Merkle树根（Merkle tree root），它代表着所有存于其中的数据。

这意味着，如果一个用户请求丢失了，或者认证提供商未能恰当处理该请求，这个哈希就会长得跟其他的不一样。这一特性的巨大差别稍后您就会发现。但在提供验证阶段，认证提供商的工作完成前，他们“混淆”处理这个Merkle树根并将其提交给状态连接器。注意，此处的“混淆”指的是这样处理后，没人能够读取所提交的哈希信息。这种做法是为了防止其他认证提供商查看提交的其他请求并复制，从而逃避工作。

Reveal 揭晓结果

最后一步即为【揭晓结果】阶段，这时认证提供商会提交未“混淆”处理的Merkle树根至状态连接器，与前面被“混淆”的哈希进行对比验证。每一个哈希可以被视作为一张投票（vote）。正如我们前文所述，同样的数据所创建的Merkle树总是相同的。因此，通过计算这个哈希被提交的次数，并用一个哈希总结RCR的三个阶段来达成大部分的共识，而且发现这个哈希是被大多数认证提供商所提交过的，那我们有理由认为，存于该Merkel树中的数据已被正确处理且结果准确。现在，Merkle树能够被解构，发出请求的原用户或智能合约能够读取该认证，且大多数认证提供商已经验证了其安全性。这意味着Merkle树上的每一片叶子都是一项数据认证，特别是针对所提交的信息类型，而作为Merkle树的一部分，它也是可验证的。

Attestation Providers 认证提供商

或许此刻，您会好奇谁是这些认证提供商呢？简单来说，认证提供商是一个软件，由去中心化网络的参与者来运行。也就是说，任何人都可以作为认证提供商来运行。

但并不是所有人在RCR协议中有投票权。这里，我们要定义一下认证提供商的默认组，他们被视作行为良好的参与者。鉴于FTSO投票权机制，这个默认组由已获得网络信任的FTSO数据提供商运营者来组成，因此，他们拥有投票优先权。所有认证提供商都必须全天候24/7来运行他们的软件，管理他们自己的区块链节点，包括他们的Flare节点。需要指出一点，他们必须为状态连接器所连接的每一条区块链都运行一个节点，使之能在RCR协议中处理认证。这种做法消耗很大，这意味着，他们必须获得一定的补偿。因此，所有在默认组的认证提供商都拥有Flare年度通胀的一定份额。通常来说，就经济效益而言，并不是每个人都适合作为认证提供商来运营。

或许，您会问，如果无法成为“带薪工作”的默认组一员，为什么还有人想成为认证提供商呢？答案是，很可能对于那些实体而言，他们已经在现有业务中运行区块链节点，比如交易所，他们中心化运行自己的认证提供商，作为他们本地组的一部分，来平行于其默认组。但这么做的激励之源是因为Flare的分叉协议。

分叉协议

分叉协议是一项安全性机制，构建在标记节点（flag node）之中用于防止错误信息利用状态连接器通过应用程序被录入。默认分支（default branch）其实始终存在，它是基于大多数认证提供商选项的状态。现在，假设一个认证提供商诚实地进行认证工作，在他们眼里，他们永远是正确的。因此，如果它所提供的信息与默认分支上大多数提交信息不符合，节点就会从默认分支“叉入”新分支。它会因为RCR认证轮次（RCR round）而丢弃那些认证，并自动停止，以提示提供商要么默认组出错，要么提供商所认证的信息不正确。