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

Filecoin update #15

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

Filecoin update #15

wants to merge 1 commit into from

Conversation

Menduist
Copy link

@Menduist Menduist commented Aug 17, 2021

AFAICT,

- Proof of spacetime is much more complex than simple challenges, and only
  required to make the blockchain work (§3.3, §6.2)

If this is implying that the PoST is only used for the consensus mechanism of the blockchain, it's not true:
Every block (~30s), a proof of storage is generated locally, and then every 24h they're all merged into a PoST and committed the the blockchain.
So the PoST is not only used to make the blockchain work, it's more importantly used to publish the proofs in a compact format.

Though I do wonder, what stop the users of retroactively computing the PoST (inside the 24h window)? I could shut down my hard drive for 23h, spin it up, compute all the proofs of the last 24h and send it to the blockchain?
Maybe it's explained somewhere and I missed it.

Last paragraph source (not in the whitepaper): https://docs.filecoin.io/about-filecoin/faq/#even-though-filecoin-will-be-backed-up-to-our-normal-ipfs-pinning-layer-we-still-need-to-know-how-quickly-we-can-access-data-from-the-filecoin-network-how-fast-will-retrieval-be-from-the-filecoin-network

@Menduist
Copy link
Author

It may also be worth mentioning that:

+ The network actively tries to repair storage faults by introducing new
  orders in the storage market. (§4.3.4).

Is very vague in the whitepaper, and no implementation has currently been done.
The plan for integration is very different and more complex that what is explained in the whitepaper.

But since this is supposed to be an evaluation of the whitepaper, not sure if it belongs here.

@dryajov
Copy link
Contributor

dryajov commented Aug 17, 2021

Though I do wonder, what stop the users of retroactively computing the PoST (inside the 24h window)? I could shut down my hard drive for 23h, spin it up, compute all the proofs of the last 24h and send it to the blockchain?

PoST are computationally expensive and recursive (VDF?), you need the proof from the previous run to generate the next one. We intend to use something similar for our proofs as well.

As far submitting the proofs, I have the same intuition, even tho you can't generate the proofs at once, because that would be computationally infeasible, revealing the proofs once every 24h limits data loss detection to the same time frame (i.e. 24h window), which limits reaction time and recoverability?

@@ -26,8 +26,6 @@ Dagger. It is not meant to be a criticism of Filecoin.
- Filecoin requires its own very specific blockchain, which influences a lot
of its design. There is tight coupling between the blockchain, storage
accounting, proofs and markets.
- Proof of spacetime is much more complex than simple challenges, and only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a better wording would be that "proofs of space time are (by design) computationally intensive and non-parallelizable (afaik)"

@markspanbroek
Copy link
Member

markspanbroek commented Aug 30, 2021

If this is implying that the PoST is only used for the consensus mechanism of the blockchain, it's not true

You're correct, it does serve a purpose. What is hinted at here, if I remember correctly, is that the proofs in themselves aren't very useful if you can't retrieve the data. Because this is already addressed in one of the next points about incentives, it's good to change the wording here.

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

Successfully merging this pull request may close these issues.

3 participants