search

filecoin-project / research

Home for Filecoin Research
Other
74 stars 10 forks source link

PoSt construction #54

Closed mhammersley closed 4 years ago

mhammersley commented 5 years ago

Background: May 2019 plan June 2019 plan

If it's possible that a PoSt without VDFs works, we'll do it (see the options in "Removing VDFs", below).

Options including VDFs are in "PoSt-VDF", below that.

mhammersley commented 5 years ago

Per Nicola, this is "in progress"

nicola commented 5 years ago

Update on PoSt constructions:

Candidates Today we have three candidates:

Assumptions They all share similar components, however they have different assumptions.

Current recommendation The current recommendation for PoSt construction today is PoSt VDF, this is due to some still open questions in PoSt Committee and PoSt Stamps. This however, does not mean we will not be doing progress on either, but we will be prioritizing the PoSt VDF.

In addition, we are looking into an economic argument in case the VDF speedup assumption breaks: even if an attacker has a tremendously fast VDF (faster than Apoll times), then in order to pull off an attack to re-use their storage, they would be: (1) needing to encode their data continuosly: this has a very high energy cost, and it would be much cheaper for the attacker to behave honestly in order to increase their power, (2) they would still need to put collateral for the storage they are introducing.

In other words, if the VDFs are not broken, we have cryptographic guarantees, if VDFs are broken, we have rational guarantees. (Note, this require more work)

Note that this is just a recommendation and more work needs to go into this for solidification, ping @bvohaska, @lucaniz

mhammersley commented 5 years ago

@nicola this is thrilling! are you planning on making those clarifications anytime soon, or would you like any assistance from @bvohaska and/or @lucaniz in fleshing it out? (or wait on the cryptoecon analysis?)

porcuquine commented 5 years ago

A preponderance of researchers requested that I add a comment noting that PoRep includes a VDE (Sloth). We wanted to track possible shared dependencies support for that (or some) VDE and any VDF work that gets done, and this comment serves as a stub for that tracking.

mhammersley commented 5 years ago

A preponderance of researchers requested that I add a comment noting that PoRep includes a VDE (Sloth). We wanted to track possible shared dependencies support for that (or some) VDE and any VDF work that gets done, and this comment serves as a stub for that tracking.

Note that, whether or not PoSt ends up requiring one, EC is likely to require a VDF (probably a construction fairly similar to PoSt, but quite different from PoRep).

nicola commented 5 years ago

added a new intuition for removing VDFs: https://github.com/filecoin-project/research/issues/115

lucaniz commented 5 years ago

There is also a "second version of post committee that could help in removing VDFs

The idea is the following: instead of using a committee for proposing a seed for a single prover, we can use a committee for validating a global seed for a single prover. Seed can be the output of the beacon and that seed is validated if at least a threshold T of committee members sign the seed itself (after checking that the prover was behaving correctly until his previous step). In this way a prover that collects at least T signatures can aggregate them and use the aggregate signature as a proof that the Beacon's output was validated in that step.

nicola commented 5 years ago

Needs update with the current state of progress (@nicola and @nikkolasg notes from IC3 and other notes).

So far the spec describes BeaconPost, but it does not define how to use the VDF.

nikkolasg commented 5 years ago

Updated the post surprise ticket with my notes and here is a personal note I have on the different solutions for post (it may be outdated / incomplete / erroneous, as the aim was mostly for my own understanding!)

nicola commented 4 years ago

old issue, closing