You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The light client currently exposes the function verify_bisection to verify new header and update the trusted state according to the verificaiton spec. Users such as the Relayer execute the verify_bisection function in a loop to maintain the latest trusted state.
It would be better for the for light client users to have a consistent runtime and be exposed to light client state changes via events. This way enrichments to the light client protocol (for instance the addition of fork detection) could translate simply to the consumption of new events without changes to the overall runtime behaviour.
A potential design has already been sketched out and just needs to be integrated. This work is related to #229 and together will be the natural evolution of the ideas suggested in ADR-006.
The text was updated successfully, but these errors were encountered:
The light client currently exposes the function
verify_bisection
to verify new header and update the trusted state according to the verificaiton spec. Users such as the Relayer execute theverify_bisection
function in a loop to maintain the latest trusted state.It would be better for the for light client users to have a consistent runtime and be exposed to light client state changes via events. This way enrichments to the light client protocol (for instance the addition of fork detection) could translate simply to the consumption of new events without changes to the overall runtime behaviour.
A potential design has already been sketched out and just needs to be integrated. This work is related to #229 and together will be the natural evolution of the ideas suggested in ADR-006.
The text was updated successfully, but these errors were encountered: