-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow the peer delivery client to select between the Deliverer or BFTDeliverer #4847
Comments
@tock-ibm Why do you want to do this? |
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. |
It can be done. But why? 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. |
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. |
Е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. |
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.
The text was updated successfully, but these errors were encountered: