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

What is a FaultSet, why does a submitPoSt message allow for multiple FaultSet, and how do they "stack"? #119

Open
laser opened this issue Jan 25, 2019 · 6 comments

Comments

@laser
Copy link
Contributor

laser commented Jan 25, 2019

The submitPoSt message includes a parameter faults of type []FaultSet.

The GeneratePost operation can return a slice of faults.

Couple of questions:

  1. What is a FaultSet? Is it just a set of the faulty sector ids returned from an invocation of GeneratePost?
  2. The type of faults is []FaultSet. Under what circumstances would someone send a submitPoSt message containing more than one FaultSet?
  3. The spec says that the miner actor needs to "ensure the fault sets properly stack." What does this mean?
@laser
Copy link
Contributor Author

laser commented Jan 25, 2019

cc @ZenGround0 @whyrusleeping

@whyrusleeping
Copy link
Member

A faultset is a bitfield and a timestamp. If a miner does not have some of their data when they need to prove it for their post, they mark it in the faultset as missing, and denote the timestamp (blockheight, or challenge index, not 100% sure yet) that the failed challenge occurred at. Miners must pay a fee for every failed sector. If the failure was only temporary (say they had to replace a disk or something) the miner can also mark the sectors in the 'recovered' set so that they don't get removed from the proving set.

Ensuring the fault sets properly stack means that no fault set overlaps with any other fault set.

The reason you need several fault sets and not just one, is because in order to properly validate the PoSt, you need to know when the failed challenges happened.

@pooja pooja added the P2 label Apr 5, 2019
@pooja
Copy link
Contributor

pooja commented Apr 5, 2019

Needs documentation in the spec

@whyrusleeping
Copy link
Member

further work here relies on the completion of #133

@pooja
Copy link
Contributor

pooja commented Apr 17, 2019

Moving forward with usage of rle+. Just needs to be written into the spec. @dignifiedquire Could you help with the spec'ing part?

@anorth
Copy link
Member

anorth commented Jun 5, 2019

Separate to the bitfield representation, the spec needs content similar to @whyrusleeping's comment above. This was also quite opaque to me.

Go-filecoin needs this to be specified so that the implementation can compute the appropriate fee to attach for temporary sector failures.

@nicola nicola added the proofs label Jul 1, 2019
@pooja pooja added the faults label Jul 2, 2019
@pooja pooja mentioned this issue Jul 3, 2019
19 tasks
@pooja pooja mentioned this issue Jul 30, 2019
18 tasks
@pooja pooja mentioned this issue Aug 27, 2019
22 tasks
@pooja pooja removed proofs labels Sep 10, 2019
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

7 participants