Hyperledger fabric 在Hyperledger结构中使用背书设计流程

我真的很想了解在Hyperledger结构中背书是如何工作的，以便帮助我设计问题的解决方案

让我们假设我是一个背书人，一个交易提案刚刚到达。我会在我的组织内随机选择一名参与者，使用其身份执行验证、检查重播攻击等，然后使用该参与者的私钥签署认可。假设我使用了管理员的凭据，管理员（人员）可能不知道我使用了其身份来验证和认可交易提案。这个例子正确吗

---

最初的讨论让我感觉越深入，我就越困惑。有人能帮忙吗？

首先，背书人是能够处理传入调用、维护和运行链码的对等方。流程如下所示，支持您拥有一个客户端（C）和一个运行链码（CC）的背书对等方（P）

客户机形成交易建议请求，其中包括链码调用的参数

为了获得该提案的支持，他将其发送给支持同行

背书对等方打开一个事务建议，并在传递所有参数的过程中将请求转发给所需的链码

调用链码，生成一个RWset（调用期间读取的一组键和值）

同行收集RWset并形成提案响应并签名

客户收到建议书回复，并签字，然后将其发送给订购服务

订购服务收集提案响应，并削减分配给网络中对等方的块

到达后，对等方打开一个块并验证所有事务，其中一个验证是在事务符合背书策略时进行检查，基本上是在事务具有足够的签名满足策略时进行检查

回到您的问题，请注意，在每个步骤中，每个人都使用自己的密钥和证书进行签名，没有人随机选择参与者使用他们的身份进行签名或其他任何操作

注意，上面的过程有点简化，缺少很多技术细节

---

PPS。有一个新的课程，它涵盖了很多技术方面的超分类帐结构和不同组件之间的相互作用，我会敦促你考虑这门课。

谢谢你的简化说明，这对我来说是有意义的。我会考虑参加这门课程。如果我们使用这个例子，我估计在第1步、第5步和第6步，我们将分别有3个签名。客户为1和6，背书人为5。这是有道理的。让我困惑的是，当一些描述开始提到成员时，例如和。然后，似乎背书对等方中的成员/管理员也可以签名。