Fix getting epoch number.

[Frozen]

Issue

Test

Unit Test Coverage

Before:

<!-- copy/paste 'go test -cover' result in the directory you made change -->

After:

<!-- copy/paste 'go test -cover' result in the directory you made change -->

Test/Run Logs

Operational Checklist

1. Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)

   YES|NO

2. Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.

3. Describe how the plan was tested.

4. How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?

5. What are the planned flag epoch numbers and their ETAs on Pangaea?

6. What are the planned flag epoch numbers and their ETAs on mainnet?

   Note that this must be enough to cover baking period on Pangaea.

7. What should node operators know about this planned change?

8. Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)

   YES|NO

9. Does the existing node.sh continue to work with this change?

10. What should node operators know about this change?

11. Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?

TODO

[sophoah]

hey Konstantin, the code you are pushing was working fine before, it only recently it showed the weird issue we had at node start on testnet. Do you have an explanation for the issue (ie why we just have that issue now) ? I am worried shard.Schedule.CalcEpochNumber(blockNum) might be called somewhere else and the same issue may happened in another edge case scenario

[Frozen]

It's difficult to say, that all calls of that method are correct, but exactly this line is really weird, because calculate epoch when we already have epoch doesn't make any sense. And this why i want to test it on testnet before.

[MaxMustermann2]

Some more color on this PR:

Within InitConsensusWithValidators a node is supposed to determine the BLS keys with which it will sign the blocks. This is done once at startup, and again at epoch change as part of the regular syncing process (via UpdateConsensusInformation). The inaccurate epoch number calculation, fixed in this PR, does not directly impact the epoch number of the block produced. It is calculated by the below code after each block of all shards.

harmony/node/worker/worker.go

Lines 353 to 371 in b1ec028

	func (w *Worker) GetNewEpoch() *big.Int {
	parent := w.chain.CurrentBlock()
	epoch := new(big.Int).Set(parent.Header().Epoch())
	shardState, err := parent.Header().GetShardState()
	if err == nil &&
	shardState.Epoch != nil &&
	w.config.IsStaking(shardState.Epoch) {
	// For shard state of staking epochs, the shard state will
	// have an epoch and it will decide the next epoch for following blocks
	epoch = new(big.Int).Set(shardState.Epoch)
	} else {
	if parent.IsLastBlockInEpoch() && parent.NumberU64() != 0 {
	// if parent has proposed a new shard state it increases by 1, except for genesis block.
	epoch = epoch.Add(epoch, common.Big1)
	}
	}
	return epoch
	}

Within our testing, this bug was discovered as a potential cause to the following issue (but it was not). A specific external validator's BLS key was retained in committee, even though it was not voting. Another key was added to that validator, which never got elected. This is because the shardState is repeated at the next epoch if there are no auction winners - which happened because it was the singular validator.

harmony/shard/committee/assignment.go

Lines 383 to 386 in b1ec028

	if len(completedEPoSRound.AuctionWinners) == 0 {
	utils.Logger().Warn().Msg("No elected validators in the new epoch!!! Reuse old shard state.")
	return stakerReader.ReadShardState(big.NewInt(0).Sub(epoch, big.NewInt(1)))
	}

[ONECasey]

This will be merged to dev once state sync has been merged to main. Lets create a testing plan for devnet/testnet