与公链（以太坊、比特币）的"无许可、匿名、全公开"不同，企业级应用场景往往需要许可准入、身份认证、数据隐私和高吞吐量。Hyperledger Fabric 是 Linux 基金会旗下的企业级联盟链框架，被广泛应用于供应链金融、跨境贸易、医疗数据共享等领域。
一、Fabric 与公链的核心差异
| 维度 | 公链（以太坊） | Hyperledger Fabric |
|---|---|---|
| 准入机制 | 无许可（任何人参与） | 许可制（MSP 身份认证） |
| 共识节点 | 全网节点 | 特定排序服务节点（Orderer） |
| 隐私性 | 全透明（假名制） | 通道级隐私 + 私有数据 |
| 吞吐量 | 15-100 TPS | 3000+ TPS（实际部署） |
| 确定性 | 概率最终性 | 即时最终性（交易即确认） |
| 智能合约 | Solidity / EVM | Go / Java / JavaScript |
| 经济激励 | 原生代币（ETH） | 无代币，商业逻辑驱动 |
二、Fabric 模块化架构
┌──────────────────────────────────────────────────────────┐
│ Fabric 网络架构 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 成员服务 │ │ 排序服务 │ │
│ │ (MSP) │ │ (Orderer) │ │
│ │ 身份管理 │ │ Raft/Kafka │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │
│ ┌──────┴────────────────────┴──────┐ │
│ │ 通道 (Channel) │ │
│ │ ┌───────────────────────────┐ │ │
│ │ │ 账本 │ │ │
│ │ │ ┌─────┐ ┌─────┐ ┌────┐ │ │ │
│ │ │ │Block│→│Block│→│ ...│ │ │ ← 世界状态数据库 │
│ │ │ └─────┘ └─────┘ └────┘ │ │ (LevelDB/CouchDB) │
│ │ └───────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Peer A │ │ Peer B │ │ ← 背书节点 │
│ │ │(Org1) │ │(Org2) │ │ │
│ │ └────┬────┘ └────┬────┘ │ │
│ │ │ │ │ │
│ │ ┌────┴──────────────┴────┐ │ │
│ │ │ 链码 (Chaincode) │ │ │
│ │ │ (Go/Java/Node.js) │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
核心组件
| 组件 | 职责 | 高可用 |
|---|---|---|
| Peer | 维护账本、执行链码（背书）、提交区块 | 多节点 + CouchDB 集群 |
| Orderer | 交易排序、打包区块、广播 | Raft 共识集群（3/5 节点） |
| MSP | 身份验证、证书颁发、权限控制 | 独立 CA 服务 |
| Chaincode | 业务逻辑（智能合约） | 多背书节点执行 |
三、交易生命周期（Execute-Order-Validate）
Fabric 采用独特的 三阶段交易流程，与公链的 Order-Execute 截然不同：
阶段一：执行（Execute/Endorse）
├─ 客户端提交交易提案到背书节点
├─ 背书节点模拟执行链码（不提交账本）
├─ 返回读写集（Read-Write Set）+ 签名
└─ 收集足够的背书签名（背书策略）
阶段二：排序（Order）
├─ 客户端将背书后的交易提交给排序服务
├─ 排序服务按 FIFO/共识顺序打包成区块
└─ 广播区块给通道内所有 Peer
阶段三：验证（Validate）
├─ Peer 验证每笔交易的背书签名
├─ 验证读写集版本（MVCC 检查，防双花）
├─ 有效交易更新世界状态
└─ 无效交易标记但不删除（审计追踪）
Client Peer(Org1) Peer(Org2) Orderer
│ │ │ │
│──Proposal─────►│ │ │
│ │ 模拟执行 │ │
│◄──Response─────│ │ │
│ │ │ │
│──Proposal──────────────────────►│ │
│ │ │ 模拟执行 │
│◄───────────────Response─────────│ │
│ │ │ │
│──Transaction───────────────────────────────────►│
│ │ │ │ 排序打包
│ │◄─────────Block───────────────────│
│ │ 验证 & 提交 │◄─Block──────────│
│ │ │ 验证 & 提交 │
四、通道（Channel）与私有数据
通道：业务隔离的边界
通道是 Fabric 最核心的隐私机制——不同通道拥有完全独立的账本和链码。
组织关系:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Org A │ │ Org B │ │ Org C │
│ (银行A) │ │ (银行B) │ │ (审计方)│
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────┬──────┘ │
│ │
┌──────┴──────┐ │
│ Channel AB │◄────────────┘
│ (A-B 私有) │ Channel ABC
└─────────────┘ (三方共享)
私有数据集合（Private Data Collection）
通道内进一步细分隐私粒度：
// collection_config.json
[
{
"name": "tradePrivateDetails",
"policy": "OR('Org1MSP.member', 'Org2MSP.member')",
"requiredPeerCount": 1,
"maxPeerCount": 3,
"blockToLive": 0, // 0 = 永久保留
"memberOnlyRead": true
}
]
私有数据的存储方式：
- 私有数据：仅授权组织的 Peer 的 SideDB 中存储
- 哈希上链：私有数据的哈希写入公共账本（可验证完整性）
- 欺诈证明：非授权组织可通过哈希验证对方是否篡改数据
五、链码开发（Go 语言）
基础链码结构
package main
import (
"fmt"
"github.com/hyperledger/fabric-contract-api-go/contractapi"
)
type SmartContract struct {
contractapi.Contract
}
// Asset 定义资产结构
type Asset struct {
ID string `json:"ID"`
Color string `json:"color"`
Size int `json:"size"`
Owner string `json:"owner"`
AppraisedValue int `json:"appraisedValue"`
}
// CreateAsset 创建资产（写入账本）
func (s *SmartContract) CreateAsset(
ctx contractapi.TransactionContextInterface,
id string, color string, size int, owner string, value int,
) error {
exists, err := s.AssetExists(ctx, id)
if err != nil {
return err
}
if exists {
return fmt.Errorf("asset %s already exists", id)
}
asset := Asset{
ID: id,
Color: color,
Size: size,
Owner: owner,
AppraisedValue: value,
}
assetJSON, err := json.Marshal(asset)
if err != nil {
return err
}
// 写入世界状态
return ctx.GetStub().PutState(id, assetJSON)
}
// ReadAsset 读取资产
func (s *SmartContract) ReadAsset(
ctx contractapi.TransactionContextInterface,
id string,
) (*Asset, error) {
assetJSON, err := ctx.GetStub().GetState(id)
if err != nil {
return nil, fmt.Errorf("failed to read from world state: %v", err)
}
if assetJSON == nil {
return nil, fmt.Errorf("asset %s does not exist", id)
}
var asset Asset
err = json.Unmarshal(assetJSON, &asset)
return &asset, err
}
// TransferAsset 转移资产所有权
func (s *SmartContract) TransferAsset(
ctx contractapi.TransactionContextInterface,
id string, newOwner string,
) error {
asset, err := s.ReadAsset(ctx, id)
if err != nil {
return err
}
// 验证当前调用者是否为所有者
clientMSPID, err := ctx.GetClientIdentity().GetMSPID()
if err != nil {
return err
}
if asset.Owner != clientMSPID {
return fmt.Errorf("unauthorized: only owner can transfer")
}
asset.Owner = newOwner
assetJSON, _ := json.Marshal(asset)
return ctx.GetStub().PutState(id, assetJSON)
}
func main() {
chaincode, err := contractapi.NewChaincode(&SmartContract{})
if err != nil {
panic(err)
}
if err := chaincode.Start(); err != nil {
panic(err)
}
}
链码生命周期
# 1. 打包链码
peer lifecycle chaincode package mycc.tar.gz \
--path ./chaincode/ --lang golang --label mycc_1.0
# 2. 安装到 Peer
peer lifecycle chaincode install mycc.tar.gz
# 3. 批准链码定义（各组织分别执行）
peer lifecycle chaincode approveformyorg \
--channelID mychannel --name mycc --version 1.0 \
--package-id $PACKAGE_ID --sequence 1 \
--signature-policy "OR('Org1MSP.peer','Org2MSP.peer')"
# 4. 提交链码定义（只需一次）
peer lifecycle chaincode commit \
--channelID mychannel --name mycc --version 1.0 --sequence 1
# 5. 调用链码
peer chaincode invoke -C mychannel -n mycc \
-c '{"function":"CreateAsset","Args":["asset1","blue","5","Org1MSP","300"]}'
六、Raft 共识与排序服务
排序服务集群
Fabric v1.4.1+ 引入 etcd/Raft 作为排序服务的共识算法：
Orderer 集群（Raft，5 节点容忍 2 故障）:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Orderer │◄───►│ Orderer │◄───►│ Orderer │
│ (Leader)│ │ (Follower)│ │ (Follower)│
└────┬────┘ └─────────┘ └─────────┘
│
▼ 打包区块
┌─────────┐ ┌─────────┐
│ Orderer │ │ Orderer │
│(Follower)│ │(Follower)│
└─────────┘ └─────────┘
Raft 特性：
- 崩溃容错：5 节点最多 2 个故障
- 无分叉：单 Leader 出块，交易即时最终确认
- 动态成员：支持运行时增删 Orderer 节点
七、企业部署实践
生产环境架构
Kubernetes 部署:
┌──────────────────────────────────────┐
│ Namespace: fabric-production │
│ │
│ ┌─────────┐ ┌─────────┐ ┌───────┐│
│ │ Orderer │ │ Orderer │ │ CA ││
│ │ Pod x3 │ │ Pod x2 │ │ Pod x1││
│ └────┬────┘ └────┬────┘ └───┬───┘│
│ └─────────────┴────────────┘ │
│ │
│ ┌─────────┐ ┌─────────┐ ┌───────┐│
│ │ Peer │ │ Peer │ │CouchDB││
│ │ Org1 x2 │ │ Org2 x2 │ │ x4 ││
│ │ (StatefulSet) │ │ ││
│ └───────────────────────┘ └───────┘│
│ │
│ Storage: PersistentVolume (SSD) │
│ Network: NetworkPolicy 隔离 │
└──────────────────────────────────────┘
与公链的协同
| 场景 | 架构方案 |
|---|---|
| 供应链溯源 | Fabric 记录商业流程 → 哈希锚定公链 |
| CBDC | Fabric 发行和管理 → 跨链互操作 |
| 贸易金融 | 多银行 Fabric 联盟 + 与 SWIFT 对接 |
八、本章小结
Hyperledger Fabric 通过许可准入、通道隔离、私有数据和模块化的 Execute-Order-Validate 架构，为企业级区块链应用提供了高吞吐量、强隐私保护和灵活治理的解决方案。与公链不同，Fabric 不依赖经济激励，而是通过商业协议和 MSP 身份体系建立信任。理解其通道设计、背书策略和链码生命周期，是企业区块链开发的必备基础。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。