Execute-Order-Validate
Execute-Order-Validate（执行-排序-验证）是 Hyperledger Fabric 的共识架构：把「共识」拆成**排序（ordering）+ 背书（endorsement）+ 验证（validation）**三段——排序层只给已经过背书的交易排全序，交易合法性由背书策略与 peer 本地验证决定。排序层实现可选 CFT（Raft）或 BFT（SmartBFT，v3.0 起）；无论哪种，共识不裁决交易内容。模型对照见 BFT。
三段流水线
- Endorse（执行 + 背书）。客户端提交提案，endorser 按背书策略执行交易，返回读写集（RW set）与背书签名；执行结果不立即写账本。
- Order（排序）。客户端把背书后的交易交给 ordering service；orderer 不执行、不判断内容，只按接收顺序打包成区块并广播。
- Validate（验证 + 提交）。每个 peer 收到区块后本地验证——背书策略是否满足、背书是否一致、读写集是否与最新状态冲突（MVCC）；无效交易保留在区块里但标记 invalid，不更新状态。
关键：执行发生在排序之前且多副本各自执行，所以「哪个执行结果合法」不由共识裁决，而由背书策略 + 本地验证决定。区块一旦生成即最终，账本不分叉。
排序层：Raft 与 SmartBFT
| 实现 | 容错 | 节点数 | 状态 |
|---|---|---|---|
| Raft（etcd/raft） | CFT | \(\ge 2f+1\)，过半可用 | 生产默认（v1.4.1 起） |
| SmartBFT | BFT | \(\ge 3f+1\)，恶意 \(< 1/3\) | v3.0 起可用 |
| Kafka / Solo | — | — | 已弃用 / 移除 |
- Raft：leader 选举 + 日志复制，确定性、无分叉。恶意节点可重排或审查，联盟链信任模型通常靠治理兜底。
- SmartBFT：源自 BFT-SMART（非流水线的 PBFT）。leader 被怀疑故障时轮转更换；客户端把交易发给所有 orderer，以对抗 leader 故意忽略交易（审查）。
- 排序层只解决「全序」，不解决「对错」——即使 orderer 诚实，恶意交易也会在 validate 阶段被 peer 拒绝。
与 BFT 系协议的关系
| Fabric | CometBFT / TBFT | |
|---|---|---|
| 交易执行 | 背书阶段（排序前） | 提案打包（共识中） |
| 排序层容错 | 可选 CFT / BFT | 必须 BFT |
| 验证 | peer 本地（背书策略 + MVCC） | 共识内 |
| 非确定性 | 背书策略约束（endorser 结果须一致） | 共识剔除（TBFT） |
- Fabric 把「确定最终状态」下放到每个 peer：验证独立于排序，故排序层可以退到 CFT 而不破坏账本一致性。
- 代价：执行放大（同一交易被多个 endorser 与 peer 重复执行）、MVCC 冲突导致交易失效需重试、背书策略成为信任集中点。
- SmartBFT 把排序层推到 \(3f+1\)，对应「orderer 本身不可信」的场景；但交易正确性仍由背书 + 验证负责，与 BFT 系「共识裁决一切」的分工不同。
对照
Fabric 是「把共识职责最小化」的代表：排序只管全序，正确性放应用层。与之相对，CometBFT / TBFT 把打包与验证绑进共识，Gasper 用分叉选择 + FFG 裁决。联盟链的信任模型决定选哪种：orderer 可信则 Raft，orderer 可能作恶则 SmartBFT。