Datachain - ELC for Bridge - Ethereum

The `Fraction` struct consists of a `numerator` and a `denominator` and it doesn't currently perform any validation of the values when a new instance is created. The following fractions can be created without errors: - A fraction whose `numerator` is greater than its `denominator`; - A fraction whose `denominator` is zero. While it is in principle possible for a mathematical fraction to have a numerator that is greater than its denominator, such instances do not appear to fit the intended use case, i.e. representing the `trust_level` field in a `ClientState` instance.

When canonicalizing the `ClientState` to generate a consistent `StateID`, the code resets `latest_execution_block_number` to zero. However, if `frozen_height` is set (i.e., not `None`), it remains unchanged. This can lead to different state IDs when they should be identical, causing unexpected inconsistencies in downstream logic that rely on stable identifiers.

The function `apply_updates()` is designed to mirror the function of the spec named `apply_light_client_update()`. In the latter function, when the stored consensus state lacks a next sync committee, it is checked that the update's finalized header's sync committee period is equal to the stored consensus state's sync committee period, and the update's next sync committee is added to the stored consensus state. However, this assignment does not take place at any point in `apply_updates()`. However, this appears not to be a problematic issue as it appears that the stored consensus state will never be lacking a next sync committee. This is despite the fact that when the new consensus state is validated in `ConsensusState::validate()`, it is not checked whether there is a next sync committee.