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

ADR: Rollapp hub sync #1088

Open
3 tasks
danwt opened this issue Sep 24, 2024 · 5 comments
Open
3 tasks

ADR: Rollapp hub sync #1088

danwt opened this issue Sep 24, 2024 · 5 comments
Assignees
Labels

Comments

@danwt
Copy link
Contributor

danwt commented Sep 24, 2024

Problem:

There are assumptions in several ADRs (TODO: link) that the L2 has a recent view of the Hub. These aren't actually necessarily satisfied, given current dymint code.

Closing criteria:

  • ADR is reviewed and agreed by reviewers
  • Node maintains 'recent' view of Hub state, with recent well defined
  • Defined behavior if the view gets out of sync/becomes too delayed

Remarks:

  • @testinginprod mentioned polling is good and websocket is bad
  • use existing health status functionality to indicate when the view is out of date
  • should collab with @zale144 @mtsitrin to find out the needs

Related:

https://github.com/dymensionxyz/research/issues/365

@danwt
Copy link
Contributor Author

danwt commented Sep 24, 2024

not strictly security related but labeled anyway to be easier to manage

@omritoptix omritoptix changed the title ADR: Node needs to have continuous recent view of Hub state ADR: Rollapp hub sync Sep 29, 2024
@omritoptix
Copy link
Contributor

I will add on top of it - Currently our events relay on WS which is obviously not reliable.
We need a way to:

  1. get messages from the hub
  2. get the messages BY ORDER (very important)
  3. avoid applying messages not by order (e.g if I get a sequencer_created message after the sequencer_rotation message - that's not gonna end up good)

My intuition is to assert order using only polling will be easier vs a mechanism of both polling and WS.

@danwt
Copy link
Contributor Author

danwt commented Oct 14, 2024

It sounds like we are going towards a scheme where the rollapp nodes consume 'messages' from the hub from an increasing sequence of hub heights, and they need to stick to that order?

To me, the more natural way is to always require ONLY the last hub height to derive everything the rollapp needs to know. Whether it be in events from that height or by querying. Nodes can then update themselves by jumping to a more recent (latest) hub height. Rather than having to go and look at the events in all the blocks in between

@omritoptix
Copy link
Contributor

not gonna pursue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants