Luca @Luca @Peter Rabbitson @Kubuxu
WIP: Looking for a better name
A way of proving persistent space which Implicitly proving access to data encoded into sectors
Quick Links
📊 Motivation
One key feature Filecoin should enable is efficient retrievals. A key insight from the growing data-owner base of filecoin, is that this efficiency is of utmost importance. This holds both for the clients themselves and for SPs who are faced with difficult choices on how to optimize their hardware for the most common use-case.
In essence, given the way our sealing process is designed today, the easiest way to ensure such a feature is via asking providers to arrange reliable access to the clear data. One key question is how to assure clients that, once they hand their data to an SP, this reliable access to their data is continuously maintained.
We propose to do so via Proof of Access, which is implicitly provided every time a WindowPost and a WinningPost is posted on-chain.
🗺️ How to get there
There are two ways we can get Proof of Access
In this doc, we describe the scenario of re-using existing circuits.
🚀 Impact on Filecoin
Why Proof of Access in Filecoin?
Unique features of Proof of Access vs status quo
Filecoin improvements
For a more detailed description of the above, please see
🔥 Current Risks
📦 Fil-PoA Protocol
With Fil-PoA (Filecoin Proof of Access) we want to introduce a change in the way PoRep are produced and verified in order to make efficient retrieval of filecoin data possible and easy to implement.
We do so by
- Slightly augmenting the way PoRep is computed
- Entangle Proof of Access with consensus
- Give periodical guarantee of Proof of Access (via existing PoST schedule)
🏗️ Overview
Today, at PoRep step, SPs prove that the replica was built correctly in a probabilistic way.
- For CC sectors, this means that the
SectorKeyis well formed - For sector with deals, this means that
Replica=SectorKey+Datais well formed
Note that we have a unique commitment CommR onchain for each sector in the network, which in case of CC sectors “degenerate” in a commitment to SectorKey
At WindowPost, SP need to prove that they are still storing all the replicas in a given partition, while at WinningPost they got challenged on a randomly selected sector for which they need to prove they are actually storing the replicated format.
We propose to slightly modify the flow above for sectors with data in the following way:
Porep Step
In addition to the current CommR commitment flow, for each sector with data, an SP should add on chain
- A proof that
SectorKeyis correctly built
WindowPoSt
Each sector in a proven partition should answer challenges against both CommR (Replica) and CommK (SectorKey)
fund
WinningPoSt
A challenged sector should answer challenges against both CommR (Replica) and CommK (SectorKey)
🌈 Outcomes
Efficient retrieval provably enabled
Proving both Replica and SectorKey implicitly proves access to a copy of clear data, encoded into the sector, while allowing an SP to not double the amount of space needed to answer challenges. Indeed:
- An SP can share a copy of the clear data and persistently store an encoded version of it.
- When challenged, he derives
SectorKey=Replica-Dataand answers the challenges - Even if an SP decides to store both
ReplicaandSectorKeyand does not access the data,Datacan be easily derived asData=Replica-SectorKey
A unique proof entangling Proof of Access to the data to Consensus
Given now PoRep, WindowPost and WinningPost all consist of two components, failing any of the two would invalidate the whole proving step. This means that not (implicitly) proving data access would result into the same countermeasures which today are in place for the current PoRep, WindowPost and WinningPost respectively
Enabling SnapDeals for Sector Natively with Deals
Today SnapDeals can not be applied to sector which are natively with Deals, since in order to do so, we miss a commitment to SectorKey onchain required to check against when proving the SnapDeals step. This limitation would be totally removed by introducing a proof and a commitment to SectorKey for all sectors (for existing sectors natively sealed with deals, this might require re-computing the SectorKey).
(Optional) Equalizing proving cost of CC Sectors and Sector with Deals
If we introduce Fil-PoA for sectors with deals only, one drawback is that sectors with deals will have a 2x proving overhead compared with CC sectors. We could re-balance this by requiring CC sectors to be snapped with a pre-determined set of non-neutral elements (non- 0x00 ) . On one hand, this would make CC sectors also more expensive to prove but, on the other hand, we would minimize the operational difference between CC and Data sectors, thus reducing the expense an SP would need to pass on to a client.