• 🎯 Goals
• Goal 1: Enable other teams to work on Proof of Space by publishing a Proof of Space primer (theory, definitions and frameworks)
• Goal 2: New Proof of Space for Filecoin as a plan B for SDR
• Goal 3: New Proof of Space for Filecoin that improves on newly collected features set
• 👨‍💻 Scope of work and ongoing work
• 🛣️ Plan B PoRep
• Feature prioritization
• 👣 Misc
• Past Efforts

🎯 Goals

There are three main goals

Goal 1: Enable other teams to work on Proof of Space by publishing a Proof of Space primer (theory, definitions and frameworks)

Starting Proof of Space research is very difficult due to the lack of formalization of the problem. The published papers contain errors, have unclear requirements or are old. We want to decrease the difficulty into researching Proof of Space.

Goal 2: New Proof of Space for Filecoin as a plan B for SDR

WindowPoSt is soon to be broken in the cost model (see No access), which means Filecoin will only rely on the latency model of SDR which we deem to be a strong assumption.

The goal is to have a plan B for the current proof of space that we deem to increase the security of Filecoin (e.g. better cost model, better latency assumption,..)

Goal 3: New Proof of Space for Filecoin that improves on newly collected features set

Unsealing is slow and expensive, sealing takes a long time and special hardware. We want re-design (or reassess parameters) of the current proof of space to enable new important features.

👨‍💻 Scope of work and ongoing work

• Project 1: Proof of Space primer (P0)
• Solving Goal 1
• Tasks
1. Systematizing notions of (useful) PoS and literature review ✅
• Systematization effort for definitions
2. Accessible rewriting of existing proofs
• Project 2: Plan B PoRep - SDR and NSE improvements and tighter analysis (P0)
• Solving Goal 2
• Tasks
1. Prioritize features for the Plan B Proof of Space
2. Tighten the security proofs of SDR and NSE
• Improvements to NSE by Leonid Reyzin
3. Explore potential new pebbling-based construction with little disruptions (e.g. taller and thinner SDR)
4. Simulate improvements and time to implement the different solutions
• On-going solutions:
‣
Option 1: Leave SDR as it is
• Level of confidence: high
• Time for deployment:
‣
~2 months of research
• Complete proof write up (4 weeks)
• Audit the result (2-3 weeks)
1. 0 months of development
• Side effects: retrievability speed stays the same
‣
Option 2: Minor SDR adjustments
• Level of confidence: high
• Time for deployment:
‣
~3 months of research
• Complete the proof work (4 weeks)
• Simulate performance (1-2 weeks)
‣
~3 months of engineering
• Add support for new PoRep (1 week)
• New trusted setup or alternative proof scheme (6 weeks)
• Proof engineering work (4 weeks)
• External audits (potentially none)
• Additional unknown complexity (2-3 weeks)
• Side effects: retrievability cost stays the same
‣
Option 3: NSE
• Level of confidence: high (with caveats; see below)
• Time for deployment:
‣
~4 months of research
• Complete proof work (4 weeks)
• Simulate performance (1-2 weeks)
• Audit NSE (2 weeks)
‣
~4 months of engineering time
• Add support for new PoRep (1 week)
• Implement basic NSE (4 weeks)
• New trusted setup or alternative proof scheme (6 weeks)
• Make NSE performant (4-8 weeks)
• Additional unknown complexities (2-3 weeks)
• Side effects: currently latency model is not well understood for NSE; more expensive WindowPost

• Project 3: Radical New PoS (P4)
• Solving goal 3
• Tasks
1. Gather requirements across the organization for key features needed and new opportunities from recent and future protocol changes
2. Find new assumptions for cost and latency (P4)
• Possible avenues to radical New PoS (and new space-hardness assumptions)
3. Formalize open problems and develop a plan for other teams to work on this

🛣️ Plan B PoRep

Feature prioritization

Goals we picked:

• Must have: a security margin of 10x at roughly the same costs for storage provider as now; constructions that help against security erosion
• See also No access
• Must have: at most 10% higher costs, similar or at most 10% worst overall costs than current PoRep
• Nice to have:
• faster retrievability, we want to be able to at least improve time to first byte
• Nice to have:
• tunability: understanding what knobs need can be changed/how in the PoS to achieve what other outputs in the network
• NB: a non-PoS problem related to tunability is that changes should be easily deployable (e.g. through a universal setup). PoS-related efforts that help with tunability may not be as effective without that.

👣 Misc

Past Efforts

• 2021Q1 Request for community feedback on proof of space design
• 2021Q1 PoRep Effort Design constraints