Liveliness Requirements for the Ethereum Ligh Client

[KaiserKarel]

Problem

Ethereum has recently suffered another finalization failure. The client semantics define how we should handle this case.

If a client can no longer be updated (if, for example, the trusting period has passed), it will no longer 
be possible to send any packets over connections & channels associated with that client, or timeout 
any packets in-flight (since the height & timestamp on the destination chain can no longer be verified). 
Manual intervention must take place to reset the client state or migrate the connections & channels to 
another client. This cannot safely be done completely automatically, but chains implementing IBC could 
elect to allow governance mechanisms to perform these actions (perhaps even per-client/connection/channel 
in a multi-sig or contract).

In our case; on-chain governance should be used to reset the client state in case of a bricked light client. We however have to find a mechanism that can be used before the token and governance is fully live.

Proposed Solution

We should explore the exact semantics of Ethereum liveliness. Are existing blocks finalized, or does the beacon chain continue at a later block and implicitly finalize the intermediate epochs? In the second case, we will run into an issue, as we may no longer be able to determine the signing committee, given that the committee will have rotated, and the current provenance of the committee cannot be proven. In the first case, we may simply be able to await liveness and replay the epochs.

I think a feasible and practical intermediate solution would be to use a multisig wallet, to be used for rescue operations until governance is live.

Thoughts

Although IBC has specified how to handle liveness failures, there does not seem to exist a truly elegant solution to resolving them before governance is operational. A sync-committee-based light client will always suffer from this potential risk; whilst tracking the full validator set of Ethereum could resolve this. One can think of a hybrid model, where the trusting period is extended as long as one can prove that execution on Ethereum remains operational.

[hussein-aitlahcen]

I think we should be fine with a multisig until we reach full decentralization via governance. The goal may be to have governance ready before mainnet, hence relying on the multisig on testnet only?

[KaiserKarel]

Tend to agree with this

[KaiserKarel]

We could do something like use the current validator aggregated BLS signature to allow resets as well; as 2/3 could fork the network anyway. That would require each validator to run a sidecar/a module to orchestrate these resets.