Interrupt production on irreversible block

[heifner]

Interrupt production if an irreversible block received on a different branch.

See new test in #1570

Resolves #1492

[greg7mdp]

Why would head not be a descendant of pending_lib?

[heifner]

Why would head not be a descendant of pending_lib?

b3 <- b4 <-b5 <-b6
Producer A starts producing on b3 because it has not received b4, b5, b6.
Producer A: b3 <- b4'.
Meanwhile the rest of the network votes on and moves LIB to b4.
After starting to produce, producer A receives blocks b4, b5, b6 and moves pending lib to b4.
Before this change, producer A would keep producing all of its blocks b5', b6', etc even though it has received b4, b5, b6 and put them in the forkdb and updated pending_lib.

[greg7mdp]

After starting to produce, producer A receives blocks b4, b5, b6 and moves pending lib to b4.
Before this change, producer A would keep producing all of its blocks b5', b6', etc even though it has received b4, b5, b6 and put them in the forkdb and updated pending_lib.

When pending lib is moved to b4, shouldn't we do a fork switch and update head to b6?
Which would prevent the producer pluging from comtinuing to produce on an obsolete branch

[heifner]

When pending lib is moved to b4, shouldn't we do a fork switch and update head to b6? Which would prevent the producer pluging from comtinuing to produce on an obsolete branch

Yes, which is the point of this PR.

[greg7mdp]

When pending lib is moved to b4, shouldn't we do a fork switch and update head to b6? Which would prevent the producer pluging from comtinuing to produce on an obsolete branch

Yes, which is the point of this PR.

So if we do a fork switch and update head to b6 when pending lib is updated to b4, why check !chain.head_child_of_pending_lib() in producer plugin? Why would it ever be true?

[heifner]

So if we do a fork switch and update head to b6 when pending lib is updated to b4, why check !chain.head_child_of_pending_lib() in producer plugin? Why would it ever be true?

Sorry, I'm not being clear. Before this PR, once block production was started by the producer plugin it would produce its complete round of 12 blocks before evaluating anything in the forkdb. Blocks might be coming into the node and put into the forkdb, but a needed fork switch was not performed until all 12 blocks of the producer was complete. This PR makes the producer plugin checks to see if there is a pending lib greater than head before it produces each block which allows it to switch to that pending lib if available.

Before Savanna, we actually dropped those blocks on the floor so they were not even in the forkdb. Pre-Savanna the longest chain would win which would mean that normally the 12 blocks produced by the producer would win and any dropped blocks would not become final. With Savanna, voting can happen on those late blocks so they can become the canonical chain. In practice, if the producer was running slow or had some hiccup so that everyone else had those blocks then those blocks are going to be the canonical chain.

This PR takes the very conservative approach of only interrupting production on proof of LIB that makes the produced chain impossible to become LIB. We talked about and might in the future switch to a diff fork if we find it is likely to become the canonical chain. For example, if we know that there are not enough outstanding votes to allow our branch to win.

[greg7mdp]

So if we do a fork switch and update head to b6 when pending lib is updated to b4, why check !chain.head_child_of_pending_lib() in producer plugin? Why would it ever be true?

Sorry, I'm not being clear. Before this PR, once block production was started by the producer plugin it would produce its complete round of 12 blocks before evaluating anything in the forkdb. Blocks might be coming into the node and put into the forkdb, but a needed fork switch was not performed until all 12 blocks of the producer was complete. This PR makes the producer plugin checks to see if there is a pending lib greater than head before it produces each block which allows it to switch to that pending lib if available.

Before Savanna, we actually dropped those blocks on the floor so they were not even in the forkdb. Pre-Savanna the longest chain would win which would mean that normally the 12 blocks produced by the producer would win and any dropped blocks would not become final. With Savanna, voting can happen on those late blocks so they can become the canonical chain. In practice, if the producer was running slow or had some hiccup so that everyone else had those blocks then those blocks are going to be the canonical chain.

This PR takes the very conservative approach of only interrupting production on proof of LIB that makes the produced chain impossible to become LIB. We talked about and might in the future switch to a diff fork if we find it is likely to become the canonical chain. For example, if we know that there are not enough outstanding votes to allow our branch to win.

Thanks for the explanation! I finally understand the logic of what we are trying to do, but I find the code hard to follow.
It could probably use a refactor eventually, but it may be risky to change it.

[linh2931]

Is it possible to add a test for the new code logic in producer_plugin?