I am having troubles understanding the precise moment of finality in Libra.
To my understanding finality occurs when at least 2f+1 nodes have committed the block.
When reading Libra’s papers and source code, as soon as block
qc_j+2 it gets committed.
As there are 3 consecutive qc’s. When a client queries this node it responds positively that the transaction is final, but when querying the other nodes they respond negatively that the transaction is not final, first green vertical arrow at
qc_j+2 in the graph. Only after the other nodes receive the next proposal, that includes this
qc_j+2, they can commit block
b_i as well(last 3 green vertical arrows). Is this not the moment of finality?
Then consider the scenario where
Node 3 crashes just after forming
qc_j+2 and replying to the clients request that his transaction is final. The round times out and the next leader creates a block with the highest qc is knows, which is
qc_j+1 currently. It will take another 3 rounds of qc’s before
b_i can be committed again, is this correct? Does this not create a inconsistent state where only
node 3 knows that
b_i is already committed and all the other nodes do not?
Is it true that a round leader also votes on his own block?
When a node receives a proposal and also happens to be the next round leader, does he vote?
To make this situation more clear I created the figure below.