了解 Hyperledger Fabric 设置
Understanding Hyperledger Fabric Setting
我是区块链新手，对比特币PoW方案有基本了解
在阅读了 Hyperledger Fabric 的关键概念后 https://hyperledger-fabric.readthedocs.io/en//latest/key_concepts.html，我在理解设置方面遇到了一些困难。
在会员部分here，它说"KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node."但是组织可以有多个对等节点。那么哪些节点负责私钥呢？我的理解是 private 应该只存储在一个地方。
对于整个Peer部分（参见this link），似乎表明Peer节点仅根据背书策略验证背书交易。共识算法呢？ （例如 PoW、PoS、PoET）
我知道 Fabric 实现了 Kafka（参见 Hyperledger Architecture, Volume 1). But then, I also find out the paper in arXiv that further confuses me A Byzantine Fault-Tolerant Ordering Service for the Hyperledger Fabric Blockchain Platform. This paper seems to suggest that the orderer nodes are also involved in Byzantine Fault Tolerance (BFT). However, my understanding of orderer nodes is that they are only responsible for ordering the endorsed transactions and broadcast them to all the peer nodes (see this link）。
现在，我对 Hyperledger Fabric 网络如何验证背书交易感到困惑。默认的共识算法是什么，它如何符合官网描述的同行部分的图片？
谢谢。
So which nodes are responsible of the private key then? My
understanding is that private should be stored at one place only.
每个节点都有自己的私钥，安全地存储在自己的文件系统中，或者存储在只有它可以访问的硬件设备上。
it seems to suggest that the Peer nodes only validate the endorsed
transactions according to the endorsement policy. What about the
consensus algorithms? (e.g. something like PoW, PoS, PoET)
共识是根据交易顺序而不是交易内容达成的。
背书策略决定了交易是否被网络视为有效。
This paper seems to suggest that the orderer nodes are also involved
in Byzantine Fault Tolerance (BFT). However, my understanding of
orderer nodes is that they are only responsible for ordering the
endorsed transactions and broadcast them to all the peer nodes
对，没错 - 当前的 Fabric 实现没有 BFT 排序器。但是，共识是可插入的，如果您实现自己的排序器，您只需将基于 Kafka 的排序器切换为 BFT 排序器即可。
Now, I am confused how the Hyperledger Fabric network verifies the
endorsed transactions. What is the default consensus algorithm and how
does it fit into the picture of the Peer section as described from the
official website?
它通过两种方式验证它们：
背书策略——每笔交易都有一个或多个链码（数据库中的命名空间）的目标。每个这样的命名空间都有一个链码，它有自己的背书策略。如果交易被peer签署满足背书策略，则认为该交易通过了背书策略。
MVCC（多版本并发控制）——一个事务在执行过程中读取键，记录它们的版本，然后在提交时对等体检查版本没有改变，所以因果关系数据仍然完好无损。
我是区块链新手，对比特币PoW方案有基本了解
在阅读了 Hyperledger Fabric 的关键概念后 https://hyperledger-fabric.readthedocs.io/en//latest/key_concepts.html，我在理解设置方面遇到了一些困难。
在会员部分here，它说"KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node."但是组织可以有多个对等节点。那么哪些节点负责私钥呢？我的理解是 private 应该只存储在一个地方。
对于整个Peer部分（参见this link），似乎表明Peer节点仅根据背书策略验证背书交易。共识算法呢？ （例如 PoW、PoS、PoET）
我知道 Fabric 实现了 Kafka（参见 Hyperledger Architecture, Volume 1). But then, I also find out the paper in arXiv that further confuses me A Byzantine Fault-Tolerant Ordering Service for the Hyperledger Fabric Blockchain Platform. This paper seems to suggest that the orderer nodes are also involved in Byzantine Fault Tolerance (BFT). However, my understanding of orderer nodes is that they are only responsible for ordering the endorsed transactions and broadcast them to all the peer nodes (see this link）。
现在，我对 Hyperledger Fabric 网络如何验证背书交易感到困惑。默认的共识算法是什么，它如何符合官网描述的同行部分的图片？
谢谢。
So which nodes are responsible of the private key then? My understanding is that private should be stored at one place only.
每个节点都有自己的私钥，安全地存储在自己的文件系统中，或者存储在只有它可以访问的硬件设备上。
it seems to suggest that the Peer nodes only validate the endorsed transactions according to the endorsement policy. What about the consensus algorithms? (e.g. something like PoW, PoS, PoET)
共识是根据交易顺序而不是交易内容达成的。 背书策略决定了交易是否被网络视为有效。
This paper seems to suggest that the orderer nodes are also involved in Byzantine Fault Tolerance (BFT). However, my understanding of orderer nodes is that they are only responsible for ordering the endorsed transactions and broadcast them to all the peer nodes
对，没错 - 当前的 Fabric 实现没有 BFT 排序器。但是，共识是可插入的，如果您实现自己的排序器，您只需将基于 Kafka 的排序器切换为 BFT 排序器即可。
Now, I am confused how the Hyperledger Fabric network verifies the endorsed transactions. What is the default consensus algorithm and how does it fit into the picture of the Peer section as described from the official website?
它通过两种方式验证它们：
背书策略——每笔交易都有一个或多个链码（数据库中的命名空间）的目标。每个这样的命名空间都有一个链码，它有自己的背书策略。如果交易被peer签署满足背书策略，则认为该交易通过了背书策略。
MVCC（多版本并发控制）——一个事务在执行过程中读取键，记录它们的版本，然后在提交时对等体检查版本没有改变，所以因果关系数据仍然完好无损。