-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Build a WindowPoSt disputer #5379
Conversation
b453799
to
644cea6
Compare
cli/disputer.go
Outdated
continue | ||
} | ||
|
||
// TODO: Might be worth building a cache of miner actors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, but reorgs are annoying to handle correctly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eh, maybe? the cache would basically be remembering "this ID address corresponds / doesn't correspond to a miner actor at a depth of at least 60 epochs"...probably okay to just ignore reorgs?
d96da90
to
c29e028
Compare
032ebdc
to
d412ccd
Compare
c29e028
to
c256572
Compare
c256572
to
c103c63
Compare
Ran this on mainnet, and it seems pretty okay. Building the deadlineMap doesn't seem to take too long. That's excluding the majority of the work, which is simulating the |
c103c63
to
d5f5c1d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach looks like a good MVP. It needs some tests but nothing's blocking merging.
Note: this is going to be a pretty inefficient and very slow approach. I think it'll be able to keep up with mainnet, but it's not taking advantage of any of the things we can do off-chain.
The next steps are to:
- Parallelize this. Maybe call the gas estimator instead of actually trying to submit messages so we can try multiple in parallel?
- Ideally, check before actually trying to submit. We can play a lot of optimization games if we can skip the VM.
cli/disputer.go
Outdated
|
||
for _, dpmsg := range dpmsgs { | ||
fmt.Println("disputing a PoSt from miner ", dpmsg.To) | ||
_, err := api.MpoolPushMessage(ctx, dpmsg, mss) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: log something if it actually works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I don't think this works. It'll fail with an error if we fail to dispute (returning and skipping everything else). We need to inspect the error).
NG Design
The key part here is parallelism and caching. The parallelism will git us an NCORE speedup and the caching/parallel disk access will cut the time in ~half for large partitions. |
cli/disputer.go
Outdated
fmt.Println("disputing a PoSt from miner ", dpmsg.To) | ||
_, err := api.MpoolPushMessage(ctx, dpmsg, mss) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be run in parallel (but doesn't really need to be done now)
cli/disputer.go
Outdated
|
||
for _, dpmsg := range dpmsgs { | ||
fmt.Println("disputing a PoSt from miner ", dpmsg.To) | ||
_, err := api.MpoolPushMessage(ctx, dpmsg, mss) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I don't think this works. It'll fail with an error if we fail to dispute (returning and skipping everything else). We need to inspect the error).
cd6ed9d
to
1839dfb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of nits, nothing really blocking
1839dfb
to
29d3d74
Compare
Co-authored-by: Łukasz Magiera <[email protected]>
Run a DisputerAfter your node is fully synced, you can run
Start a Window PoSt DisputerSimply run Manual DisputeYou can also send a specific |
Motivation
FIP-0010 necessitates the creation of "auditors" that try to disprove recent WindowPoSt submissions. We need this to be something easily launched, and so it makes sense to build it within a Lotus node.
Design considerations
There are 2 chief designs we could go with:
Design 1: Periodically audit every miner's PoSt submissions (that are in the
OptimisticPoStSubmissionsSnapshot
of their deadlines). This is fairly comprehensive, but could be slow unless we have high efficiency (never re-audit a post). We could also modify this to be random, auditing some configurable number (or percentage) of miners in every period.Design 2: Subscribe to updates to the head, and listen for WindowPoSt submissions whose windows have closed (and are therefore challenge-able). Try to dispute every single one.
Implementation
This is a first draft that implements Design 1.
Testing
Based on a quick simulation in devnets, it achieves the two key requirements:
Next big thing to test will be performance.
TODOs
Fixes #5285