Add committed block to viewchange

[ineiti]

Discussing this with @LefKok today, I though this issue already exists, but I can't find it anymore. So here you go. When a new block is created, the following happens:

1. the leader proposes a block
2. the followers sign the propose and send their signatures to the leader
3. the followers sign the commit and send their signatures to the leader
4. the leader sends the block to the followers

If, for any reason, there is a viewchange between 3. and 4., the block is silently dropped, and the chain is effectively forked, as the new leader will create a different block at the same height.

To avoid this, the view-change must include an additional step:

• for the commit-phase of blscosi, the leader must send his commitment, so that all other nodes can include it if the leader fails
• when asking for a view-change, the nodes must not only indicate their latest block, but also the latest block for which they sent a commit signature
• if there is a pending block, then the new leader must collect all commit signatures and propagate that new block

For an example where this happened, see #2079

[Gilthoniel]

I'm not sure it works for any situation. If the collective signature is only almost accepted, meaning one less signature would have been refused then without the previous leader signature, the block won't be created and thus preventing from moving forward.

[ineiti]

I'm not sure it works for any situation. If the collective signature is only almost accepted, meaning one less signature would have been refused then without the previous leader signature, the block won't be created and thus preventing from moving forward.

Correct - added one step to the issue itself.

[Gilthoniel]

I recently noticed that the PBFT implementation using CoSi is not implemented correctly as it is effectively doing two prepare phases. If that was the case, the commit phase would provide the proof that enough nodes have committed the block (n+1). The chain would be approved only if the commit signature exists for the block n+1 so if the leader fails between 3 and 4, the commit signature couldn't exist thus making the proposed block (n+1) not committed. Participants should then accept a view change and continue from the latest fully committed block (n).

For the case where the leader is malicious and keep the commit signature for himself, it is important that a node only signs a commit once for a given leader and only accepts to sign a view change otherwise. In the worst case, a leader could create a valid block but the chain could not continue.

[Gilthoniel]

@jeffallen FYI