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!: ni-porep PoC in lotus-miner pipeline #12398

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Aug 16, 2024

This is a draft PoC to demonstrate NI-PoRep using the existing lotus-miner pipeline. It's far from complete, but it works with mock proofs under the very limited conditions of the integration test that exercises this. Someone else would need to take this further and do all of the additional pieces required.

This functionality is for using lotus-miner to seal NI-PoRep sectors itself, not the "buy sector and onboard" workflow. So for this to be worthwhile, the economics of the more expensive porep (8x?) would have to justify the lack of wait time to onboard and the ability to select your sector proving deadlines. Does the maths of that work out for anyone?

Some thoughts from doing this about what else would be needed here:

  • I don't know how lotus-miner normally queues up CC sectors, I've just hijacked the PledgeSector API which is labelled Temp api for testing (although it's wired up through the CLI, so maybe that's wrong), the additional arg I've added isn't exactly ideal. There needs to be some coherent mechanism to queue NI-PoRep sectors up to the pipeline.
  • Juggling NI-PoRep and non-NI-PoRep would be an interesting challenge to consider here, how would you properly manage a mixture? Right now the main thing I've added here to manage that is that when we have a batch of commits to process we only take batches of the same proof type: starting from the first in the queue, collect all commits with the same proof type in the queue and submit those. That's pretty unintelligent.
  • I've also mainly hijacked the PC1, PC2, C1, C2 process for this, with the variation being that C2 becomes a SealCommit2CircuitProofs, but I think it looks the same from an events perspective. Maybe you'd want to have a C2CP worker to do these specially? Not sure how that works.
  • I've only implemented this to work with local workers, you'd want remote workers wired up for this (probably not hard).
  • I've hard-coded deadline in here, but you'd really want to be able to control that somehow. I'm not sure what lotus-miner users would want here, maybe an algorithm to balance them across a particular range? Maybe a fixed deadline for all sectors? Not my area of expertise. The code in here also doesn't watch for deadline mutability, this code will fail if the sector is committed during the requested deadline or the one after because of deadline "mutability" rules. So there'd have to be some logic to either select the deadline for the current window, or wait for an immutable window before committing.

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

Successfully merging this pull request may close these issues.

3 participants