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

feat: check posted output root for fraud #87

Open
ncitron opened this issue Apr 17, 2023 · 6 comments
Open

feat: check posted output root for fraud #87

ncitron opened this issue Apr 17, 2023 · 6 comments

Comments

@ncitron
Copy link
Contributor

ncitron commented Apr 17, 2023

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

@ncitron ncitron added M-easy Meta: Good first issue and removed M-easy Meta: Good first issue labels Apr 17, 2023
@clabby
Copy link
Contributor

clabby commented Apr 24, 2023

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.

@clabby
Copy link
Contributor

clabby commented Apr 24, 2023

For some extra context, see the challenger specification

Permissionless Output Proposals

@refcell
Copy link
Collaborator

refcell commented Apr 24, 2023

I agree with @clabby here - it should be an isolated service. Exposing a trusted endpoint for faulty output detection would be high leverage here though. (this easily-consumable endpoint for downstream services should happen in the challenge as well i believe)

@ncitron
Copy link
Contributor Author

ncitron commented Apr 24, 2023

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.

@refcell
Copy link
Collaborator

refcell commented Apr 24, 2023

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 ?

@clabby
Copy link
Contributor

clabby commented Apr 24, 2023

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.

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

No branches or pull requests

3 participants