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

Interop: op-supervisor devnet 1 readiness #12042

Closed
protolambda opened this issue Sep 21, 2024 · 1 comment
Closed

Interop: op-supervisor devnet 1 readiness #12042

protolambda opened this issue Sep 21, 2024 · 1 comment
Assignees

Comments

@protolambda
Copy link
Contributor

op-supervisor status:

  • PR open
  • Fixes X-head updating to handle edge-cases:
    • Empty blocks, using DB work that landed Friday
    • Difference between future blocks and conflicting blocks
  • Needs better testing:
    • Existing tests stub the DB, but make a lot of assumptions, and little coverage.
      • In favor of instead randomizing / fuzzing the DB:
        Create a DB, fill it with random data, and see if the x-head can be progressed.
    • Existing tests lock us into some earlier prototype-ish code abstractions:
      • Too synchronous
      • Slow: frequent map lookups, poor usage pattern of the heads DB
  • X-unsafe head progression works now:
    • Had to fix the prior fix to genesis block insertion;
      the empty-DB case is recognized correctly now.
  • X-safe head progression is broken:
    • op-supervisor polls op-geth for safe, to update local-safe.
    • But op-geth serves cross-safe, not local-safe.
    • And x-safe will only update after op-node learns from op-supervisor.
    • Thus stuck at genesis forever.
    • To fix: the node should not be polling the op-geth node for safe or finalized data.
      Instead, it should poll the op-node for safe and finalized data.
      • When using op-node, we can use the sync-status endpoint,
        and retrieve the finalized L1 block, and the derived-from info, at the same time.
  • X-finalized progression is broken:
    • As in prior op-node implementation change: cross-finalized is a bad idea.
      We should have just 1 level of finality in op-node / op-geth.
    • To fix: to determine what to finalize, the op-supervisor needs:
      • per L2:
        • what the latest cross-safe value is.
        • recent history of cross-safe L2 values, per L1 derived-from value,
          until we have the safety-index which covers a deeper history
          (see design doc).
      • global:
        • what the L1 finalized block is
    • We can then update cross-finalized of each L2 chain
      to the latest cross-safe value recognized in the recent history
      of the latest finalized L1 block.
@protolambda
Copy link
Contributor Author

Closing this:

  • cross-safe update fixes will be tracked in a separate issue
  • supervisor is being updated to take data from op-node, and not wait for local-safe from geth when it only has cross-safe info
  • L2 finality falls into place once we have data that registers what L2 block was cross-safe at which L1 point

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

Successfully merging a pull request may close this issue.

1 participant