我是Hyperledger Fabric的新手。我正在阅读最新版本的Fabric文档，但我对Fabric的共识不太清楚。Fabric使用了什么共识算法？它是如何工作的？请解释一下。
3个回答
9
我假设您已经了解区块链背景下的共识基础知识。Hyperledger Fabric的共识可以视为同一概念的特殊情况，可能是一个强大的情况。它在多个阶段检查交易以确保正在写入分类账的更改的权限、顺序和正确性。
在Fabric中，当您执行交易时，如果没有错误，您希望该交易提交到分类账中，即按正确顺序将交易写入分类账中。然后，通过协作过程，使其在网络中的所有参与者之间保持一致同步。因此，确保正确顺序和数据同步的这个过程被称为共识。
HLF标准定义如下：
保持分类账交易在网络中同步的过程 - 确保仅在经过适当参与者批准交易时分类账才会更新，并且当分类账更新时，它们以相同的顺序更新相同的交易 - 被称为共识。
这是通过以下方式在整个交易周期内完成的。
当您提交交易时，即调用智能合约中的函数时，您使用的客户端SDK必须将该交易提议发送给背书人（特定于该频道中的智能合约）。此交易提议需要采取用户的加密凭据以生成唯一签名。
背书节点会进行其所需的检查，例如提议是否有效，试图执行交易的用户在该频道中是否具有相应权限等等。然后他们会模拟交易，并创建响应和R/W集。这被发送为提议响应，返回到SDK。
SDK累计它们并检查它们，然后将它们发送到订购者。订购者将按照时间顺序排序事务，并创建一个块，并将该块发送到相关频道的所有对等方。
接收该块的对等方开始检查块中的每个事务（使用验证系统链代码），以查看所有事务是否都已经背书并且R/W集是否正确（MVCC检查）。根据检查结果，可能会将事务标记为有效或无效。
当所有检查都通过后，交易将被标记为有效并更新当前状态，最后块将被写入，并相应地生成事件。这样，在Hyperledger Fabric中的共识就在多个阶段完成了。如果您参考下面的链接Hyperledger Fabric Transaction Flow，您会更好地理解。
在Fabric中，当您执行交易时，如果没有错误，您希望该交易提交到分类账中，即按正确顺序将交易写入分类账中。然后，通过协作过程，使其在网络中的所有参与者之间保持一致同步。因此，确保正确顺序和数据同步的这个过程被称为共识。
HLF标准定义如下：
保持分类账交易在网络中同步的过程 - 确保仅在经过适当参与者批准交易时分类账才会更新，并且当分类账更新时，它们以相同的顺序更新相同的交易 - 被称为共识。
这是通过以下方式在整个交易周期内完成的。
当您提交交易时，即调用智能合约中的函数时，您使用的客户端SDK必须将该交易提议发送给背书人（特定于该频道中的智能合约）。此交易提议需要采取用户的加密凭据以生成唯一签名。
背书节点会进行其所需的检查，例如提议是否有效，试图执行交易的用户在该频道中是否具有相应权限等等。然后他们会模拟交易，并创建响应和R/W集。这被发送为提议响应，返回到SDK。
SDK累计它们并检查它们，然后将它们发送到订购者。订购者将按照时间顺序排序事务，并创建一个块，并将该块发送到相关频道的所有对等方。
接收该块的对等方开始检查块中的每个事务（使用验证系统链代码），以查看所有事务是否都已经背书并且R/W集是否正确（MVCC检查）。根据检查结果，可能会将事务标记为有效或无效。
当所有检查都通过后，交易将被标记为有效并更新当前状态，最后块将被写入，并相应地生成事件。这样，在Hyperledger Fabric中的共识就在多个阶段完成了。如果您参考下面的链接Hyperledger Fabric Transaction Flow，您会更好地理解。
- Ashishkel
1
在第三个进程中，Orderers支持RAFT / Kafka-Zookeeper / Solo（dev）方法用于ordering-service。现在，Fabric文档推荐使用RAFT。 - myeongkil kim
1
Consensus在Hyperledger Fabric中分为三个阶段：背书、排序和验证。
背书由策略（m个签名中的n个）驱动，参与者对交易进行背书。（由我们定义）
排序阶段将获取被背书的交易，并同意将交易提交到分类帐中。（我们可以使用任何排序服务，如solo、Kafka和Raft）
验证会取得一系列已排序的交易块，并验证结果的正确性。在验证期间，节点将验证区块中的交易是否有效。（由orderer发送）
背书由策略（m个签名中的n个）驱动，参与者对交易进行背书。（由我们定义）
排序阶段将获取被背书的交易，并同意将交易提交到分类帐中。（我们可以使用任何排序服务，如solo、Kafka和Raft）
验证会取得一系列已排序的交易块，并验证结果的正确性。在验证期间，节点将验证区块中的交易是否有效。（由orderer发送）
- deepak tholia
0
根据Hyperledger Fabric v1.4
平台最重要的特点之一是支持可插拔共识协议，使得平台可以更有效地定制以适应特定的用例和信任模型。例如，在单个企业内部部署或由受信任的机构运营时，完全拜占庭容错共识可能被认为是不必要的，并且会对性能和吞吐量造成过度负担。在这种情况下，崩溃容错(CFT)共识协议可能已经足够了，而在多方分散的用例中，则可能需要更传统的拜占庭容错(BFT)共识协议。
交易的排序委托给一个模块化的共识组件，该组件在逻辑上与执行交易和维护账本的节点分离。具体来说，就是排序服务。由于共识是模块化的，因此其实现可以根据特定部署或解决方案的信任假设进行定制。这种模块化架构允许平台依赖于CFT（崩溃容错）或BFT（拜占庭容错）排序的成熟工具包。
Fabric目前提供了两种CFT排序服务实现。
平台最重要的特点之一是支持可插拔共识协议，使得平台可以更有效地定制以适应特定的用例和信任模型。例如，在单个企业内部部署或由受信任的机构运营时，完全拜占庭容错共识可能被认为是不必要的，并且会对性能和吞吐量造成过度负担。在这种情况下，崩溃容错(CFT)共识协议可能已经足够了，而在多方分散的用例中，则可能需要更传统的拜占庭容错(BFT)共识协议。
交易的排序委托给一个模块化的共识组件，该组件在逻辑上与执行交易和维护账本的节点分离。具体来说，就是排序服务。由于共识是模块化的，因此其实现可以根据特定部署或解决方案的信任假设进行定制。这种模块化架构允许平台依赖于CFT（崩溃容错）或BFT（拜占庭容错）排序的成熟工具包。
Fabric目前提供了两种CFT排序服务实现。
- 第一个基于Raft协议的etcd库。
- 另一个是Kafka（内部使用Zookeeper）。
- asing177
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接