【发布时间】：2016-08-19 02:17:06
【问题描述】：
我一直在阅读有关 HyperLedger Fabric 项目如何实施开源区块链解决方案的文档：https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md
我看到使用了 PBFT 共识算法，但我不明白 BlockChain 网络中的所有 Validating Peers 是如何挖掘和共享块的。
【问题讨论】：
【发布时间】：2016-08-19 02:17:06
【问题描述】：
Hyperledger Validating Peers (VPs) 不会挖掘区块，也不会在它们之间共享区块。以下是它的工作原理：
- 交易被发送给一个受信任的 VP。
- VP 将交易广播给所有其他 VP。
- 所有 VP 就执行交易的顺序达成共识（使用 PBFT 算法）。
- 所有 VP 都按照总订单“自行”执行交易，并使用已执行的交易构建一个区块（主要计算哈希值）。
所有区块都将是相同的，因为：交易执行是确定性的（应该是），并且一个区块中的 tx 数量是固定的。
【讨论】：
-
PBFT == 实用的拜占庭容错en.wikipedia.org/wiki/Byzantine_fault_tolerance
-
听起来类似于 2 阶段提交协议。当然资源管理者和协调管理者不会那么简单。尽管如此，我还是想到了利用 IBM z/OS RRS 的解决方案。
-
这是关于上面的第 3 步。鉴于此，区块链技术是建立在拜占庭同行之间达成共识的基础上，为什么 VP 想要就交易顺序而不是交易结果达成共识？至少，在比特币的情况下，账户余额比交易顺序更重要。 bitcoin.stackexchange.com/a/3871/6975
-
我想说的是，在订单中达成共识比比较交易结果要容易得多，因为交易的结果可以是多种类型（因为链码允许在链码本身，或者交易可以只是一个查询交易）。
-
@MarcCayuelaRafols 但没有必要在所有 VP 中执行相同的事务，对吗？另外我的问题是“当其他授权用户提出交易以从分类帐中查询一些数据时，它将从哪个 VP 的链中提取？”
根据 Hyperledger Fabric 1.X
- 用户通过 Client SDK 将交易提案发送给 Endorsing Peers。
- Endorsing Peer检查交易并提出交易的背书建议（带有读/写集（先前值/更改值））并再次发送给客户端SDK。
- Client SDK 等待所有背书，一旦获得所有背书提案，它会发出一个调用请求并发送给 Orderer。
- Orderer 通过检查 Policies defined(Consensus) 验证客户端 SDK 的调用请求租用，验证交易并添加到区块。
- 根据为区块定义的配置，在指定的时间或交易次数后，使用交易哈希、元数据和前一个区块哈希形成区块的哈希。
- 交易块由 Orderer “交付”给通道上的所有对等方。
- 所有提交对等方验证背书策略，并确保自事务执行生成读取集后，读取集变量的账本状态没有发生任何更改。在此之后块中的所有交易并使用新块和当前资产状态更新分类帐。
分类帐包含
- 1) 当前状态数据库（Level BD 或 Couch DB）
- 2) 区块链（文件）（链接块）
【讨论】：
-
很好解释@pavan 感谢分享。
Hyperledger 是区块链技术的保护伞。上面提到的 Hyperledger Fabric 就是其中之一。 Hyperledger Sawtooth 也不使用挖矿，并添加了这些共识算法：
- PoET 经过时间的证明（用于 Sawtooth 的可选 Nakamoto 风格的共识算法）。 SGX 的 POET 有 BFT。 PoET Simulator 有 CFT。不像 PoW 风格的算法那样占用 CPU 资源，尽管它仍然可以分叉并拥有陈旧的块。请参阅https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/poet.html 上的 PoET 规范
- RAFT 一种共识算法，可以在任意时间内选举领导者。如果超时，则更换领导者。 Raft 比 PoET 快，但不是 BFT（Raft 是 CFT）。 Raft 也不会分叉。
- 使用可插拔共识，无需重新初始化区块链甚至重新启动软件即可更改另一个共识算法。
为了完整起见，比特币的原始共识算法（并且确实使用挖矿）是：
- PoW 工作证明。完成工作（CPU 密集型 Nakamoto 式共识算法）。通常用于无许可区块链
【讨论】：