IF: Implement computing finality digest

[linh2931]

A finality digest is a hash of a series sub-digests required for IBC verification. It is built from a hash of a serialization of light_header_protocol_version, active_finalizer_policy_generation, finality_tree_digest, and a combination of base_digest and active_finalizer_policy_digest. base_digest is a hash of a serialization of deterministic fields of block_header_state, including header, core, finalizer_policies, active_proposer_policy, proposer_policies, and activated_protocol_features.

finality_tree is defined as following:

1. A Finality Merkle Tree is a Merkle tree over a sequence of Finality Leaf Nodes,
   one for each block starting from the IF Genesis Block and ending at some
   specified descendant block.
2. The Validation Tree associated with a target block is the Finality Merkle
   Tree over Finality Leaf Nodes starting with the one for the IF Genesis Block
   and ending with the one for the block that is the parent of the the target Block.
3. The Finality Tree ssociated with a target block is the Validation Tree of the
   block referenced by the target block's final_on_strong_qc_block_num.
   That is, validation_tree(core.final_on_strong_qc_block_num))

A valid structure is introduced into block_state to hold all necessary information.

This PR implemented computing finality digest based on finality merkle tree, validation tree, finality tree, and validated structure.

See #2080 for design details.

Resolved #2080

[ericpassmore]

Note:start
group: IF
category: INTERNALS
summary: Implementation of finality digest, a hash of a series sub-digests, required for IBC verification.
Note:end

[arhag]

There is no need for this to be optional within a snapshot.

[greg7mdp]

Yes, I remember you mentioned that it should always be present, and the std::optional was just because the valid_t is not be available when block_state is initially created.

I assume that when the snapshot is initiated, and we save the chain head to the snapshot, we can FC_ASSERT that the valid member is populated, right?

[arhag]

Yes, we can assert that the valid structure exists at the time the snapshot is being produced. It must always be the case.

In the snapshot itself, the valid structure must always be present, which is why I say it shouldn't be an optional type within this struct. It should still be optional within block_state. But when loading the root block_state from a snapshot, valid should always end up populated.

[heifner]

I believe this change means it is now possible to skip propser_schedule.version numbers. We should modify the set_proposed_producers logic so we don't skip version numbers. Need a test to cover that case so we don't break it again.

[linh2931]

Does

leap/libraries/chain/controller.cpp

Lines 481 to 484 in 7f3d5e6

	return (--parent.proposer_policies.end())->second->proposer_schedule.version + 1;
	}
	assert(active_proposer_policy);
	return active_proposer_policy->proposer_schedule.version + 1;

ensure the version number not being skipped?

[heifner]

No, that doesn't help. We need to make sure that if a proposer policy is scheduled for the same proposer_policy.active_time that it replaces the current one there but doesn't increment the schedule version. I think we will need to change controller::set_proposed_producers to check if there is an existing one that would have the same active_time and replace it and use its version. We should return the correct version to the contract.

[heifner]

Feel free to create a follow-on issue for this.

[linh2931]

#2313

Thanks.