一、构建环境
项目
下载地址:github/fabric-sample
环境与搭建基本教程:【Fabric】SOLO 共识网络搭建
PBFT算法实现:github/fabric-sample
版本
- Hyperleger/fabric v1.4.4
- Hyperleger/caliepr-cli v0.3.0
- node v8.10.0
- npm v5.6.0
- docker 19.03.5
- docker-compose 1.25.4
文件
chaincode/demo: 测试 chaincode
chaincode/callback: hyperleger/caliper测试用例
pbft: 可插拔 PBFT 共识算法简单实现
rbft: 可插拔 RBFT 共识算法简单实现
solo-network: solo共识配置
pbft-network: pbft共识配置
rbft-network: rbft共识配置
multi-channel-network: solo多链配置
二、共识算法 PBFT 开发流程
configtxgen
工具源码修改,使其识别pbft
共识配置。
// common/tools/configtxgen/localconfig/config.go:388
switch ord.OrdererType {
case 'pbft':
}
// commom/tools/configtxgen/encoder/encoder.go:38
const ConsensusTypePbft = "pbft"
// commom/tools/configtxgen/encoder/encoder.go:215
switch conf.OrdererType {
case ConsensusTypePbft:
}
- 添加共识算法实例
// orderer/common/server/main.go:664
consenters["pbft"] = pbft.New()
- 实现共识接口
/orderer/consensus/consensus.go
// 接口说明 - Consneter
// 返回 Chain 用于实现处理区块接口
type Consenter interface {
HandleChain(support ConsenterSupport, metadata *cb.Metadata) (Chain, error)
}
// Chain 处理区块接口
type Chain interface {
// 处理 Normal 交易
Order(env *cb.Envelope, configSeq uint64) error
// 处理配置交易
Configure(config *cb.Envelope, configSeq uint64) error
// 等待接收交易,处理函数交易前
WaitReady() error
// 发送错误 chan
Errored() <-chan struct{}
// 初始化 Chain 中资源
Start()
// 资源释放
Halt()
}
三、网络拓扑
类型/组织 | 域名 | IP/端口/PBFT端口 | 组织名 |
---|---|---|---|
Orderer | orderer0.yzm.com | 172.22.0.100:6050/6070 | OrdererOrg |
Orderer | orderer1.yzm.com | 172.22.0.101:6051/6071 | OrdererOrg |
Orderer | orderer2.yzm.com | 172.22.0.101:6052/6072 | OrdererOrg |
Orderer | orderer3.yzm.com | 172.22.0.101:6053/6073 | OrdererOrg |
Peer/OrgA | peer0.orga.com | 172.22.0.2:7051 | OrgAMSP |
Peer/OrgB | peer0.orgb.com | 172.22.0.3:8051 | OrgBMSP |
四、环境变量说明
PBFT_LISTEN_PORT
:PBFT 节点监听端口PBFT_NODE_ID
:PBFT 节点 IDPBFT_NODE_TABLE
:PBFT 网络列表
五、测试方法
$ npx caliper launch master --caliper-workspace <pbft或rbft-network> --caliper-benchconfig benchmarks/config.yaml --caliper-networkconfig benchmarks/network.yaml
22 条评论
您好,有几个问题请教一下。看到Fabric说他的PBFT还在开发中,但是他为什么抛弃了v0.6中的pbft,而是用现在的raft呢?现阶段fabric的共识可不可以理解成通过背书少数服从多数来保证1/2的拜占庭容错?另外一个问题是在哈希、签名等各种密码学算法的加持下,恶意节点能够篡改而又不被发现的情况有哪些?是否真的能够造成账本的错误?以上问题,感谢您的回复。
1. 从工程实践来看,raft有现成的实现,比较可靠,至于fabric为什么放弃pbft可以问下上游
2. 共识算法比较流行的有 2f+1 和 3f+1 ,raft使用的是 2f+1 也就是大多数一致(一半),pbft 用的 3f+1 需要更多的节点一致(2f+1)比一半还要多
3. 恶意节点篡改后还能达到大多数一致,就不会被发现
我之前一直以为在prepare 和 commit 阶段只需要 2f+1个消息,并不需要一致,就能保证最坏情况下也是少数服从多数(2f+1 中 f个恶意节点,f+1个正确节点),进而继续执行。看到您消息后回去又看了一遍PBFT,发现确实是需要2f+1个匹配pre-prepare以及消息m。那如果在最坏的情况下,f个恶意节点,f个宕机节点,二者没有重合,那么不可能收集足够2f+1一致的消息,此时PBFT如何处理?一直等待节点恢复吗?这是否符合liveness的要求?问题比较多,感谢您的解答。
严格按照 PBFT 如果有 2f 个节点没法工作是无法达成一致的,f->指的就是最大不会工作的节点。存活节点会一致等待,且无法对外提供写服务。具体处理工程里面就比较复杂了,都是根据特定需要场景讨论,如果需要满足 liveness 需要更换其他共识算法。liveness 是指在满足条件下的工作方式。
大概明白了,谢谢您
明白了,谢谢您,收获很大!
您好,请问大佬为什么添加了pbft算法后无法生成创世区块呢,报错显示无法识别“pbft”
2022-04-20 19:47:46.946 PDT [common.tools.configtxgen.localconfig] completeInitialization -> PANI 004 unknown orderer type: pbft
2022-04-20 19:47:46.946 PDT [common.tools.configtxgen] func1 -> PANI 005 unknown orderer type: pbft
panic: unknown orderer type: pbft [recovered]
panic: unknown orderer type: pbft
看起来是你的 pbft 算法并没有编译成功
请问作者大大,基于fabric1.4.4平台修改的pbft算法测试的话用到的caliper版本是多少啊
文章里面的版本用的时 0.3.0 其他的好像有问题
请问大大什么时候方便出个用caliper做压测的文章啊,十分期待啊~
楼主,第664行,consenters["pbft"]=pbft.new;//orderer/common/server/main.go:664。请问这个是怎么解决的呢?
没懂什么意思
大佬,您好。按照教程 docker 启动成功, 接下来是按照官网教程执行创建通道、加入通道、安装合约、实例化合约吗? 如果是这样的话,我目前在创建通道时未能成功(指定的 orderer0,端口6050),希望您得空能指点一下,谢谢大佬。
(指定的orderer0,端口6050,6070都试了)
CMD:
export CHANNEL_NAME=testchainid && peer channel create -o orderer0.yzm.com:6050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/yzm.com/orderers/orderer0.yzm.com/msp/tlscacerts/tlsca.yzm.com-cert.pem
LOG:
2021-11-13 11:47:23.530 UTC [msp] GetDefaultSigningIdentity -> DEBU 034 Obtaining default signing identity
2021-11-13 11:47:23.530 UTC [grpc] DialContext -> DEBU 035 parsed scheme: ""
2021-11-13 11:47:23.530 UTC [grpc] DialContext -> DEBU 036 scheme "" not registered, fallback to default scheme
2021-11-13 11:47:23.531 UTC [grpc] watcher -> DEBU 037 ccResolverWrapper: sending new addresses to cc: [{orderer0.yzm.com:7050 0 }]
2021-11-13 11:47:23.531 UTC [grpc] switchBalancer -> DEBU 038 ClientConn switching balancer to "pick_first"
2021-11-13 11:47:23.531 UTC [grpc] HandleSubConnStateChange -> DEBU 039 pickfirstBalancer: HandleSubConnStateChange: 0xc0003b0490, CONNECTING
2021-11-13 11:47:23.536 UTC [grpc] createTransport -> DEBU 03a grpc: addrConn.createTransport failed to connect to {orderer0.yzm.com:7050 0 }. Err :connection error: desc = "transport: error while dialing: dial tcp 172.22.0.100:7050: connect: connection refused". Reconnecting...
2021-11-13 11:47:23.536 UTC [grpc] HandleSubConnStateChange -> DEBU 03b pickfirstBalancer: HandleSubConnStateChange: 0xc0003b0490, TRANSIENT_FAILURE
Error: failed to create deliver client: orderer client failed to connect to orderer0.yzm.com:7050: failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 172.22.0.100:7050: connect: connection refused"
看起来是有server没启动成功吧
大佬是否可以留个联系方式 可有偿
是pbft没改配置成功的意思? 在创建通道时指定的是指定orderer0 6050还是6070 呢),希望您能指点一下,谢谢大佬。
您好,请问可以详细交流一下关于搭建pbft的fabric教程吗,我这边更改了配置文件报错vender缺少包,但是我从golang官网重新下载了一遍还是没有用
你好请问你在“添加共识算法实例”这步是怎么改的?
我按照教程上修改,无法实现。
还有 case 'pbft': 不应该是 case "pbft":嘛
重载它的共识算法类即可
我在修改rbft时,使用用kyber一直版本不对,请问您知道需要怎么修改嘛?