Notify the application of a role change
pfi79 opened this issue · comments
Can add a function to the interface to notify the application of a change in the role of "leader" <---> "follower"? This is required for an application that is in the middle of the processing flow and will have to forward the result of its work to the next cluster (for example hyperledger fabric).
I don't think this is required, since the client should anyway send the transaction to at least 2f+1 orderer nodes, hence if a leader failover occurs, some other node will re-send the transaction after a timeout.
this is necessary to unambiguously select a node that will send the generated batches further, for example, to the HLF. If 2 or more nodes send the same batch to the HLF. This batch will be perceived as 2 different batch.
In case a leader fails we have 2 cases:
- A batch has been prepared by 2f+1 nodes
- No batch has been prepared by 2f+1 nodes
If the first case happens then it is ensured that the next leader will move this batch to the next view.
Else, no batch has been prepared, and the next leader is free to select the next batch on its own, because it's equivalent for the leader failing before it had a chance to prepare a batch.
In either cases - we are guaranteed that transactions will eventually get into some future block.
I have a different task. SmartBFT creates blocks. Another goroutine reads blocks from the right place and throws them into another cluster. I need any unambiguous criterion who does this (without additional coordination). I chose the role of leader.
@pfi79 you do not have to implement this by coupling your application logic and consensus. You can have a client which reads/receives blocks from the BFT replica set and forwards them into another cluster for further processing.
Such a client is not reliable, it can be compromised. With such a client, you do not need a smartbft before him and after him. Such a client will be the weakest link in the processing flow.
@pfi79 even if client compromised it forwards signed block you can always detect it, the only damage it can cause is to omit blocks. However you can put health checks and monitoring to detect it.
At any rate I wouldn't recommend tight coupling between your application and BFT library.
With such a client, you do not need a smartbft before him and after him
can you elaborate? smartbft can guarantee that provided block/batch is not forged, while client cannot not, why do you think this is even equal?
We already have a client that constantly pulls blocks from the consensus service and stores them on disk.... The Fabric peers do that all the time.
I see... well, in any case - you can observe who is the leader quite easily by simply looking at the view number.
The Proposal has a Metadata field which is a raw ViewMetadata that holds the said view number.
So if you want to implement something like that in your application, then after you commit the batch - you can look at the metadata and see if you were the leader that assembled the batch, and if so - do what you want to do.