Follower: check if join block different from fetched block

[tock-ibm]

Change-Id: I7089df4f1bfc200a5f17582df0da7d4172f8f09b

Type of change

• Bug fix

Description

Follower: revert check of join block different from fetched block

Related issues

Addresses #4264

[yacovm]

I don't think that simply removing the check without providing a countermeasure in the same fix is a good idea.

With this change, the code allows an orderer to pull blocks while disregarding the join block, which obviously was retrieved from somewhere.

The genesis block cannot be validated, and thus the current code completely puts the validity of the genesis block in the mercy of the orderer it is retrieved from.

This check lets you know that you have diverged from the chain.

[tock-ibm]

I don't think that simply removing the check without providing a countermeasure in the same fix is a good idea.

With this change, the code allows an orderer to pull blocks while disregarding the join block, which obviously was retrieved from somewhere.

The genesis block cannot be validated, and thus the current code completely puts the validity of the genesis block in the mercy of the orderer it is retrieved from.

This check lets you know that you have diverged from the chain.

@yacovm I agree with what you said. I am changing the mechanism such that:
The follower checks if join block different from fetched block, both header and data, and

• it happens before fetched block is committed, otherwise if the orderer is restarted, the follower continues past that block
• don't panic, since it can affect other channels
• continue to retry, as it might have been an error in a single remote orderer

In the future, we may consider to stop the chain in events like this and reflect it in the status, as proposed in FAB-18106
https://jira.hyperledger.org/browse/FAB-18106

I also added a couple of unit tests for this scenario.

[yacovm]

I don't think that simply removing the check without providing a countermeasure in the same fix is a good idea.
With this change, the code allows an orderer to pull blocks while disregarding the join block, which obviously was retrieved from somewhere.
The genesis block cannot be validated, and thus the current code completely puts the validity of the genesis block in the mercy of the orderer it is retrieved from.
This check lets you know that you have diverged from the chain.

@yacovm I agree with what you said. I am changing the mechanism such that: The follower checks if join block different from fetched block, both header and data, and

* it happens before fetched block is committed, otherwise if the orderer is restarted, the follower continues past that block

* don't panic, since it can affect other channels

* continue to retry, as it might have been an error in a single remote orderer

I also added a couple of unit tests for this scenario.

As long as the follower doesn't evolve into a fully fledged consenter, we're good.