这是我们的用例： Anna 想将她的股份出售给 Peter，而 Olga 需要批准（作为公司所有者）。
这将如何在具有共识的区块链超级账本结构/组合器上工作？
具体来说，其中哪一部分是交易，什么是提案（提案是否需要一个活人对交易的实际批准？）以及在区块链上是如何处理的，在应用程序内外发生了什么的应用程序。
请尽可能具体。 谢谢！
【问题讨论】：
标签： hyperledger-fabric hyperledger-composer consensus
首先有几件事： Composer 使用底层区块链配置使用的任何共识算法。所以; Hyperledger Fabric 目前提供 SOLO 或 KAFKA。 KAFKA 只提供容错，不提供拜占庭容错。
所以： 确实存在您所描述的背书政策。它不需要活人的批准，您可以使一切程序化，甚至可以是物联网设备。审批者必须模拟交易并查看他们是否同意输出。 Olga 是您方案中的批准人。
使所有链代码（Composer 中的事务）具有确定性很重要，因此可以以这种方式模拟它们。
Fabric 的文档中对交易流程有很好的描述：http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
我将在一个月内发布一篇论文，其中有一节专门讨论共识比较和 Composer/Fabric。如果您有进一步的兴趣，我可以给您发一份草稿。
【讨论】：
你的问题有两个方面，一是活人的认可方面，二是账本状态的完整性（共识）。
我会按相反的顺序解释。
共识部分
因此，Hyperledger Fabric 是一种企业解决方案，旨在维护一个一致的分类账，联盟的所有组织都需要就该分类账达成一致。这是通过将多个组织的账本合并到一个账本中来实现的，并且在这个账本中记录的交易将包括来自各方的交易。
这些交易不是随机交易，而是智能合约的实现，在 Fabric 术语中称为链代码。每当将链码部署在 Fabric 通道（与其自己的分类帐关联的私有子网）上时，它都会初始化 World State，即默认资产及其值。
接下来每个组织都同意一个背书策略，例如每个组织的 1 个对等方应该背书交易（在此状态下称为交易提案），背书只是具有读取集的交易的读写集（值为交易模拟前的资产），写集（交易模拟后的资产值）。如果所有节点（所有满足背书策略的节点）的背书是相同的，这意味着资产的世界状态在所有节点（至少那些满足背书策略的节点）是一致的，因此账本数据的完整性得以实现。
共识进一步包括将交易批处理到区块中，并通过排序服务对区块内的交易进行排序，排序服务再次验证背书人签名，并且在区块到达对等方提交时，最后一次完成世界状态验证。
审批部分
当您有一个需要参与者交互的批准流程时，您必须在您的链代码中处理这件事。 Composer 是最好的起点。
从 Composer 示例中查看 CarAuction 示例，您将了解每个状态转换都必须注册，例如，卖方参与者拥有资产 Car，但当汽车被拍卖以出售时，必须将其添加到列表中注册使用所有投标人参与者都可以看到的交易，汽车资产状态的这种移动是通过由授权方在这里卖方调用的交易AuctionMyCardOrSomething实现的。然后，当拍卖师（另一个具有不同角色的参与者）执行另一个称为封闭竞标的交易时，如果满足所有条件，则可以将汽车所有权转让给出价最高的人。出价也是交易的节点。
请注意本示例中的 Auctioneer 和状态转换，相同的模型可以应用于您的案例。每次需要状态转换时，您都必须执行交易并更新分类帐。
希望这会有所帮助。
【讨论】：