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

Question

Fabric中的事务流表明：

1. 客户提出交易
2. 此提案已传递给网络的所有认可同行
3. 背书的对等实体模拟链码，对提案进行签名并将其发送回客户端。
4. 客户端收集签名并等待，直到签名总数与背书策略中指定的数量相符
5. 一旦客户端具有足够的签名，它就会将该请求发送给订购者
6. 定购者创建块并将其发送给锚点对等点，后者进行验证并提交到其分类帐中

如果我们正在使用Composer REST服务器，那么如何处理所有这些步骤？它们是从客户端抽象出来的吗？还是我们需要在T​​P功能或客户端中明确编写逻辑来处理提案响应？

我的困惑来自这样一个事实，当我们使用节点SDK时，我们必须显式实现用于处理所有这些的逻辑。在here上进行操作。

Answer 1

Composer实现了一个Submit / Notify模型，其中包括Rest Server。它将提交建议，收集背书，将其发送给订购者，并等待提交交易的一个区块，然后通知调用者交易完成。

由于Composer无法看到背书策略，它将向通道中的所有对等方发送建议（已被定义为在连接配置文件中具有endorsingPeer角色，如果未指定，则默认为true），并收集尽可能多的响应在将其发送订购之前，请尽可能。然后，对等方将决定这些背书是否满足背书政策。

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