谁是验证同行？

Question

我在Glossary中没有看到“验证对等”和“非验证对等”这两个术语的定义。重要的是要有这个定义，因为大量的文献似乎依赖于这些类型的同行。

来到我的主要问题。

将区块链视为数据存储，很明显，此数据存储区将公开要更改的函数并读取其存储的状态。因此，验证对等体是否会验证以下事实：X在状态之前，T是应用的事务而X是结果状态？

或者，验证对等体是否也会验证T代表的业务逻辑以及调用T应该存在的访问级别？

集中式比喻是使用SQL引擎公开商店状态的RDBMS。这个商店可以通过业务逻辑（例如规则引擎）和SQL命令（例如INSERT，SELECT等）的组合进行更新。我的问题是，是否有兴趣确保SQL命令成功运行？或者，它是否也将验证扩展到规则引擎？

Answer 1

v0.6 of Hyperledger Fabric中使用了验证对等体这一术语。他们是订货人，没有验证的同行，同行。

在v1.0中有：

• 背书同行：他们收到一笔交易。然后，他们针对Smart Contrat执行交易并签署结果。他们将签名的交易发送给发送它的对等方。
• Committer Peers：Peers获取Blocks（带有validates事务）并将它们提交到其分类帐。
• Orderes：对事务进行排序并生成块的节点。

修改（添加以下内容）：

对等方可以是Endorser和Comitter。此外，Endorser Peer可以执行自己的交易。

流程（简要）：

• 对等方获取客户端请求。该对等方（最初的Peer）向Endorser Peers发送相应的请求。
• 背书同行根据其智能合约执行请求。他们签署回复并将其发送给最初的同行。
• 如果所有响应的结果相同且签名正确，则初始Peer使用符号构建事务。它被发送给de orderer。
• 在订购服务中，验证签名。订购服务按时间顺序和渠道创建块。他们被送到了Comitter Peers。
• 每个Comitter Peer验证Block的每个事务。如果正常，它会将阻止附加到每个本地分类帐。

Answer 2

背书人验证交易并将RWset和背书签名一起发送到投标。然后，提案将交易请求发送给订购者，订购者将交易分成多个块，然后将这些块传递给提交者对等方。