cothority
cothority copied to clipboard
dedis
BFTCosi Byzcoinx FtCoSi: about Strong Consistency
When using BFTcosi，byzcoinx or FTcosi, Only the root node finally get the aggregate-signature and then broadcast or propagate to other nodes. So i think that is different from classic PBFT, because we can't guarantee Broadcast or propagate stage . Is it right? Should we still need a checkpoint? Assume a majority slow honest nodes are still waiting for the aggregate-signature for blockN propagated in the network and then a view change happens and leader changes. How does the new leader know blockN is still in the network and wait(start blockN+1 ) until blockN aggregate-signature arrives？
Edited by @jeffallen to add:
We want to identify if we have an existing test that checks this situation, and if not we want a new test that causes the leader to end up with block latest+1 committed to it's local database, but no other nodes to be aware of it. Then we expect another transaction to be successfully logged into block latest+2, and for the followers to catch up and get it.
We should also create a test that creates a fork by causing a view change after a level 0 link is accepted into the old leader's DB, but before the new block is communicated to the network. We would like that the old leader, when it rejoins the network as a follower, resolves the fork situation during catch-up.
It is best to consider ByzCoin as a version of Parsimonious broadcast ( https://link.springer.com/chapter/10.1007/11795490_9). The key idea is that even if the leader does not release the final signature (proof of consensus), the only other option is a view-change. After that (or many more) view-change the honest leader will have no option but to re-run consensus for exactly the same blockN hence creating a similar signature (maybe it has a different subset of participants but it still means the same). Just like PBFT, consensus for blockN in view i does not guarantee that blockN will be committed in view i, it might be committed in view i+1,i+2,...
Στις Δευ, 1 Απρ 2019 στις 2:15 μ.μ., ο/η liangyangThree < [email protected]> έγραψε:
When using BFTcosi，byzcoinx or FTcosi, Only the root node finally get the aggregate-signature and then broadcast or propagate to other nodes. So i think that is different from classic PBFT, because we can't guarantee Broadcast or propagate stage . Is it right? Should we still need a checkpoint? Assume a majority slow honest nodes are still waiting for the aggregate-signature for blockN propagated in the network and then a view change happens and leader changes. How does the new leader know blockN is still in the network and wait(start blockN+1 ) until blockN aggregate-signature arrives？
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dedis/cothority/issues/1787, or mute the thread https://github.com/notifications/unsubscribe-auth/AK70stL0vLjnEq66XhFUaldXObwv2_52ks5vcfhngaJpZM4cVkLj .
--
Kokoris-Kogias Eleftherios PhD Candidate at School of Computer and Communication Sciences EPFL
@LefKok Thanks. I really appreciate your time.
- I will read the paper later.
- As said above, the aggregate-signature for blockN is swimming in the network and a majority doesn't receive yet. At the same time the view change is done, new leader complete blockN'. Now I can image that there are two valid blocks(blockN and blockN') in the network. As a common node which is not participate in BFTCosi maybe take blockN or blockN'. It seems that double spending will happen. How does the skipchain guarantee it?
If a majority has committed to the block then they will never prepare for BlockN'. This part is classic PBFT. If they have not then there is not problem as blocks are considered valid only after commitment.
On Tue, Apr 2, 2019, 7:21 AM liangyangThree [email protected] wrote:
@LefKok https://github.com/LefKok Thanks. I really appreciate your time.
- I will read the paper later.
- As said above, blockN is swimming in the network and a majority doesn't receive yet. At the same time the view change is done, new leader complete blockN'. Now I can image that there are two valid blocks(blockN and blockN') in the network. As a common node which is not participate in BFTCosi maybe take blockN or blockN'. It seems that double spending will happen. How does the skipchain guarantee it?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dedis/cothority/issues/1787#issuecomment-478848935, or mute the thread https://github.com/notifications/unsubscribe-auth/AK70st8XN9DZ9RSj22wW8UTLvxBbEXQdks5vcujzgaJpZM4cVkLj .
There is an error on my previous description； It is not "blockN is swimming", but "the aggregate-signature for blockN is swimming"; it means blockN is still not committed. and at the same time the view change is done, new leader completes blockN' and broadcast the aggregate-signature. So i am considering that a few nodes may finally get blockN-aggregate-signature and blockN'-aggregate-signature for the others .
If the aggregate signature is a result of a prepare round, then blockN might or might not be committed depending on how many see the signature before the view-change. Notice that there is no doublespending possible since it is "just" a prepare certificate.
If the aggregate signature is a result of the commit round then 2f+1 nodes hold/guard the prepare certificate of blockN meaning that they can convince the new leader to re-commit blockN in his view orelse view-change him.
Notice that both scenarios can also happen in PBFT since there is no reliable delivery of messages.
Στις Τρί, 2 Απρ 2019 στις 11:36 π.μ., ο/η liangyangThree < [email protected]> έγραψε:
There is a error on my previous description； It is not "blockN is swimming", but "the aggregate-signature for blockN is swimming"; it means blockN is still not committed. and at the same time the view change is done, new leader completes blockN'.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dedis/cothority/issues/1787#issuecomment-478920527, or mute the thread https://github.com/notifications/unsubscribe-auth/AK70slnv6QBm5CDGvNKmTaBnDfTRAyM-ks5vcyS5gaJpZM4cVkLj .
--
Kokoris-Kogias Eleftherios PhD Candidate at School of Computer and Communication Sciences EPFL
@LefKok The aggregate signature which I told is calculated by root.Signature() on the bftcosi_test.go after the Two Round cosi finish. Root finally get the aggregate signature and broadcasts. so Root broadcasts the final aggregate signature is beyond pbft. @ineiti Does 'one more feature request' mean that still not handle or guarantee Root broadcasts the final aggregate signature on byzcoin?
The aggregate signature is broadcasted to all nodes. But as far as I know we don't handle the failure you describe, where the leader cannot broadcast the link to the new block (the aggregate signature) to the followers.
I think what would happen is that another leader would step up and re-create a block with the same index...
At the moment the leader has a valid 0-level forward link, this means that a threshold of followers agreed on the contents of the last block. Now, if the leader fails to tell them about it, and they find out about that forward link (and the new latest block) later, as long as the forward link is valid, they will integrate that block into their local database too.
In the case where a leader succeeds in getting a new level 0 forward link for a new block, and saves it, and then crashes, then a view change happens and the next leader makes a different block with the same index, and saves it and broadcasts it to the network... this would seem to cause a fork, and it is not clear how the deposed leader would ever be able to fix his chain and rejoin the cothority.
I've updated to issue description to be about creating test cases to check our behaviour in these cases.
