在比特币(以及一般的工作量证明)的情况下，有一个简单的规则，当出于任何原因有 2 个不同的账本副本时，提供自动冲突解决。这个规则是链条越长，越长赢。
但是，在 Fabric 的情况下，如何解决冲突？说 Fabric 中永远不会发生冲突并不是一个答案，因为如果冲突从未发生过，那么获得多个同行认可的目的是什么？
或者，如果你的答案是 Fabric 中永远不会发生冲突，那么请解释为什么有人想要得到多个同行的认可？
另一种构建这个问题的方法：假设托管在另一个组织的对等节点上的账本副本在他们不知道的情况下被黑客入侵。现在，您的组织和其他组织具有不同的记录。如何调和冲突？并且不要忘记这将造成的破坏 - 在冲突解决之前，用户提交的所有交易现在都将无法获得认可。对另一个组织的黑客攻击扰乱了您的业务，即使您的分类账没有受到损害。
在工作证明中：
客户将提交一笔交易，它将在池中，任何矿工都可以接受并验证交易，然后进行挖矿，如果他很快得到解决，那么他将发布给其他矿工。这里很多节点都涉及Orderer创建一个区块
在Hyperledger Fabric [HighLevel]中：
客户端将事务发送给背书对等方(多个)，背书对等方将向客户端发送回 R/W 和签名，如果背书失败意味着数据一致，那么它将标记为失败并发送回客户端。
客户端会将整个有效负载发送到排序器。Orderer 只需创建一个区块并交付给提交节点，提交节点只需非常背书(不止一个)并提交到账本
不告诉我，通过比较两者，你认为超级账本结构中仍然会出现冲突吗？
获得代言的目的：为了真实更多代言更准确。
低级别：
第 1 阶段：[主动启动 Tx]
客户端 A 正在发送更新账本的请求。 此请求针对对等 A 和对等 B，它们分别是 客户A和客户B的代表。背书政策规定 两个对等方都必须背书任何交易，因此请求 转到对等 A 和对等 B。
第 2 阶段：背书对等方验证签名并执行交易
背书对等方验证 (1) 交易提案是否良好 形成，(2)过去尚未提交 (重放攻击保护)，(3)签名有效(使用 MSP)，以及 (4) 提交者(在本例中为客户端 A)是 获得适当授权，可在该通道上执行建议的操作 (即，每个背书对等方确保提交者满足 频道的作家政策)。背书对等方接受交易 提案输入作为调用链码函数的参数。这 然后针对当前状态数据库执行链码以 生成事务结果，包括响应值、读取集和 写集(即表示要创建的资产的键/值对或 更新)。此时不会对账本进行任何更新。这套 这些值以及背书对等方的签名将传回作为对SDK的"提案响应"，用于解析有效负载 要使用的应用程序。
第 3 阶段：检查客户提案响应
应用程序验证背书对等签名并比较 建议响应，以确定建议响应是否为 相同。如果链码只查询账本，则应用程序 将检查查询响应，并且通常不会提交 交易到订购服务。如果客户端应用程序打算 将交易提交到订购服务以更新 账本，应用程序确定指定的背书策略是否 在提交之前已经满足(即对等A和对等B都 背书)。体系结构是这样的，即使应用程序选择 不检查回复或以其他方式转发未经认可的回复 交易，背书策略仍将由对等方执行 并在提交验证阶段得到支持。
第 4 阶段：客户将背书组装成交易并广播
应用程序"广播"交易提案和响应 在"事务消息"中发送给排序服务。这 事务将包含读/写集，背书对等方 签名和通道 ID。订购服务不需要 检查事务的全部内容以执行其 操作，它只是从 网络，按通道按时间顺序对它们进行排序，并创建 每个通道的事务。
第 5 阶段：验证并提交事务
交易块被"交付"给 渠道。区块内的交易经过验证，以确保 符合背书政策，并确保没有 自读取集由事务执行生成。区块中的交易是 标记为有效或无效。
第 6 阶段：账本更新
每个对等体将块附加到通道的链中，并且对于每个有效的 事务 写集提交到当前状态数据库。一 发出事件，以通知客户端应用程序 交易(调用)已不可变地附加到链中，如 以及交易是否经过验证的通知，或 失效。