-
Notifications
You must be signed in to change notification settings - Fork 95
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
feat: check posted output root for fraud #87
Comments
Wondering if it'd be a good idea to interop with the op-challenger here rather than add fault detection to magi? This service is meant to work with a trusted rollup client to both detect and respond to fault in a post-permissionless output proposals world. |
For some extra context, see the challenger specification |
I agree with @clabby here - it should be an isolated service. |
This makes a lot of sense @clabby @refcell. Agree that we should lean into the optimism-rs modularity and use op-challenger instead. Can op-challenger be setup to not try and do the dispute game (since it doesn't exist yet if I understand correctly), and just alert if fraud is detected? I think that can still be useful as it would allow people to raise the alarm for the multisig to act in the case of the proposer being hacked for example. If so, I would love to integrate op-challenger into our docker configs once #102 is merged and update our grafana dashboard to freak out if fraud is detected. |
That sounds like a great idea. If it's not already configurable, i think it would make sense to add a "watch or listen mode" to the challenger. Thoughts @clabby ? |
Agree. The plan for the challengers is to have a dedicated grafana dashboard + an optional call out to a webhook - we can also add a way for the node to hook into the process, but imo it's also fine to sidecar this responsibility to the challenger process to keep magi purpose-driven. There is a bit of a trade-off here, though - before PoPs goes live (which should be late Q2 / early Q3, but no promises other than soon™️ atm), we really do want something to yell at you if the proposer is misbehaving. I think that @ncitron's idea about adding a mode where the challenger only listens but does not respond is a good short-term solution here that wouldn't add bloat to magi. |
Check the L1 to compare any output roots posted by the proposer to what we expect. If a mismatch is detected, very loudly warn the user via continuously posting warning messages to the CLI.
Might also be cool to have the Grafana dashboard display something if fraud is detected too.
related to #86
The text was updated successfully, but these errors were encountered: