fabric
fabric copied to clipboard
hyperledger
Allow the peer delivery client to select between the Deliverer or BFTDeliverer
Current Status
the deliverclient core/deliverservice/deliveryclient.go
Uses either the Deliverer common/deliverclient/blocksprovider/deliverer.go
or the BFTDeliverer common/deliverclient/blocksprovider/bft_deliverer.go
depending on the consensus type - etcdraft/BFT.
Goal
We want to add to the core.yaml a key "peer.deliveryclient.policy" = "simple" / "cluster" that would allow the use of "simple" even when the consensus type is BFT. When consensus type is etcdraft this key is ignored.
Solution
We want to add to the core.yaml a key "peer.deliveryclient.policy" = "simple" / "cluster" that would allow the use of "simple" even when the consensus type is BFT. When consensus type is etcdraft this key is ignored.
@tock-ibm Why do you want to do this? What problem in the fabric will it solve?
@tock-ibm Why do you want to do this? What problem in the fabric will it solve?
It was suggested by @yacovm that in case the peer organization trusts the ordering service and wants to save bandwidth, it could select the "simple" policy that consumes blocks from a single orderer, rather than the "cluster" policy that consumes blocks from a single orderer and block headers from every other orderer.
Thinking about it, there is also another policy we could easily implement, in which the peer specifies the ordering-org it trusts and wants to pull blocks from. @pfi79 @yacovm @denyeart what do you think?
Thinking about it, there is also another policy we could easily implement, in which the peer specifies the ordering-org it trusts and wants to pull blocks from. @pfi79 @yacovm @denyeart what do you think?
Yes that's also an option.
Thinking about it, there is also another policy we could easily implement, in which the peer specifies the ordering-org it trusts and wants to pull blocks from. @pfi79 @yacovm @denyeart what do you think?
It can be done. But why? I mean, the configuration and code will become more difficult. And what do we get?
This is not the only “simple” option for delivering blocks to peer.
Thinking about it, there is also another policy we could easily implement, in which the peer specifies the ordering-org it trusts and wants to pull blocks from. @pfi79 @yacovm @denyeart what do you think?
It can be done. But why? I mean, the configuration and code will become more difficult. And what do we get?
This is not the only “simple” option for delivering blocks to peer.
I think what you get is lower costs.
Since in a multi cloud deployment, the account pays for traffic sent from the server, but not for traffic sent to the server. Therefore, in a simple policy that selects a random block source, you will most likely cause the account that deployed the orderer to pay for traffic, while it may be that you can select to pull from a source which is routable through the internal network and then the account that deployed the orderer doesn't pay for sending these blocks.
By the way, I suggested the "simple" option just because the BFT one has more complex code, so if there is a bug we don't know about, we could always have the users fallback on the "simple" option with the code that already existed for quite a while.
I think what you get is lower costs.
Since in a multi cloud deployment, the account pays for traffic sent from the server, but not for traffic sent to the server. Therefore, in a simple policy that selects a random block source, you will most likely cause the account that deployed the orderer to pay for traffic, while it may be that you can select to pull from a source which is routable through the internal network and then the account that deployed the orderer doesn't pay for sending these blocks.
Еxcellent use.
I'm sorry, but I'm gonna be a little bit of a nerd.
Your use case, speaks to full control and management of block delivery. But it doesn't. There are alternative delivery methods that I don't think we have control over yet.
Please see #4856 @tock-ibm
@semil merged
Lets do an integration test for it.