Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine aggregated proof retrieval methods #54

Open
3 tasks
Tracked by #29
Farhad-Shabani opened this issue Jan 11, 2024 · 0 comments
Open
3 tasks
Tracked by #29

Determine aggregated proof retrieval methods #54

Farhad-Shabani opened this issue Jan 11, 2024 · 0 comments
Labels
relayer Related to relayer

Comments

@Farhad-Shabani
Copy link
Member

Farhad-Shabani commented Jan 11, 2024

Context

To enable relayers to craft MsgUpdateClient, it's essential to query the aggregated proof data from the DA layer at intervals corresponding to the number of headers it covers. The aggregated proof validates that the rollup executes correctly over a specified height range. Currently, with Celestia as our DA layer, the primary available methods seem to be Get and GetAll blob, necessitating the specification of a height at min. The following points should be determined for properly querying aggregated proofs:

Key Considerations

  • Connection to DA layer
    How should the relayer establish a connection to the DA layer? Are subscription endpoints available for getting notifications on when proofs are emitted, or should RPC methods suffice (poll-based approach)?

  • Available RPC methods
    What PRC methods are available by DA layer or own rollup for retrieving these proofs?
    We need a way/endpoint to determine the latest height at which an aggregated proof is present.
    Additionally, a query interface for querying a range of aggregated proofs by specifying the start and/or end height.

  • Efficiency Concerns (missed proofs)
    Is there a risk that an aggregated_proof submission to the DA layer fail? If such failures occur intermittently, relayers might miss certain proofs. Then, how can relayers be informed of such occurrences? Should relayers operate optimistically, assuming they have processed all committed proofs up to their current height, despite potential gaps due to missed submissions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relayer Related to relayer
Projects
Status: 📥 To Do
Development

No branches or pull requests

1 participant