在 Hyperledger Composer 中验证和处理交易提议请求

Question

Fabric 中的交易流程指出：

1. 客户提出交易
2. 这个提案被传递给网络的所有背书节点
3. 背书节点模拟链码，签署提案并将其发送回客户端。
4. 客户端收集签名并等待签名总数与背书策略中指定的签名总数相匹配
5. 一旦客户端有足够的签名，它就会将这个请求发送给订购者
6. 排序者创建块并将其发送给验证并提交到其分类帐中的锚节点

如果我们使用 Composer REST 服务器，如何处理所有这些步骤？他们是从客户那里抽象出来的吗？或者我们是否需要在 TP 函数或客户端中显式编写逻辑来处理提案响应？

我的困惑来自于当我们使用节点SDK时，我们必须显式地实现处理所有这些的逻辑。当我们完成 here.

Answer 1

Composer 实现了一个 Submit/Notify 模型，其中包括 Rest Server。它将提交提案，收集背书，将它们发送给排序者并等待包含事务的块被提交，然后通知调用者事务完成。

由于 Composer 对背书策略不可见，它将向通道中的所有对等点发送提议（已在连接配置文件中定义为具有 endorsingPeer 角色，如果未指定则默认为 true）并收集为在发送订单之前尽可能多地回复。然后 Peer(s) 将决定这些背书是否满足背书策略。

Composer 还等待所有对等点（已在连接配置文件中定义为具有 eventSource 角色，如果未指定则默认为 true）在通知客户端之前通知事务已提交