在Filecoin中，存储提供者必须生成具有特定属性的有效Proofs-of-Storage（请参阅Proof-of-Replication）以获得用于存储数据的奖励。
每个复制证明显示副本存储在挑战的时间周围。这意味着证明文件被存储一段时间需要多轮交互。相反，我们提出了一个新的证明方案 - 空间时间证明，其中存储提供者可以非交互方式生成一组存储证明，并且只发布保证文件一直存储的最终证明。
问题定义
空间时间证明（PoSt）是存储提供者和验证者之间的协议，其中存储提供者必须说服验证者他们已经存储了特定时间的特定文件。
直觉
客户希望确保存储提供者在一段时间t内一直存储文件D.使用经典的可检索性证明/证明数据拥有方案，客户必须通过在整个t期间发出挑战来检查文件是否已经存储在整个时间。天真地说，客户可以选择一个安全参数λ，并对每个时间单元发出挑战λ，使得交互次数（发出的挑战次数）O（t）和总通信复杂度（所有数据的大小由验证者接收）O（pt），其中p是单个存储的证明的大小。
通过实际的空间证明解决的需求是：
问题1：我们如何构建一个交互次数少于的方案O（T）？
问题2：我们如何构建总通信复杂度小于O（pt）的方案？
候选建筑
天真的构造：在接受挑战时，提供者生成一个存储验证，并使用证明的输出（假设Random Oracle）作为下一个存储验证的挑战。提供者将重复这个步骤t次。所有证明的连接将是发送给验证者的证明，验证者可以验证：（1）个体证明的正确性和（2）串联的正确性。该方案具有O（1）交互，但是总的通信复杂度为O（pt）。
递增可验证的计算：在接受挑战时，提供者运行天真的构造，但是在完成每个存储验证时，它使用递增可验证的计算来证明证明是正确生成的，并且它使用先前证明的输出。该方案具有交互O（1）和总通信复杂度O（1）（取决于方案）。这些方案的一个问题是，使用诸如SNARKs之类的方案来实现递增可验证的计算会增加证据生成的大量开销。
批量可验证计算：在接受挑战时，提供商运行天真的建设;一旦完成，它将运行验证者算法（验证个体证明的正确性和串联的正确性）。该方案具有交互和总体通信复杂性。该方案具有交互O（1）和总通信复杂度O（1）（取决于方案，这可能涉及SNARK）。
理想的属性
透明度：没有这样的额外信息（或陷门），证明者可以用来生成有效的PoSt证据，而不用随时间存储数据。
验证时间短：如果验证时间在安全参数O（λ）中保持不变，对于一个小常数或对于数据大小是次线性的，则验证时间很短。 （注意：对于合理的数据大小，例如10GB，持续验证具体可能需要比次线性验证更长的时间）
短证明：如果证明在安全参数O（λ）中是常量，对于小常量是常数，或对于数据大小是次线性的，则证明是短的（注意：对于合理的数据大小，例如10GB，恒定证明大小可能具体地大于次线性证明大小）
具体实践证明开销：生成证明的开销内存和计算时间应该切实可行（例如，可以在商品硬件上执行大型文件），而不会影响安全性。
顺序证明生成：生成证明空间时间的持续时间由底层证明存储的顺序（不可并行）组成。
开放问题
虽然存在一些空间证明的候选结构，但仍然有改进使这种结构更加实用（更快的验证时间）或更弱的加密假设。理想的PoSt结构应尽可能具有以下几个特性。
具体开放问题
新的空间时间证明结构：是否存在具有快速验证时间，小的证明计算/内存开销和短期证明的透明PoSt？ （或者，是否有完全不同的结构来实现相同的目标？）
优化重复计算：空间证明需要证明存储证明序列的知识。 有没有方法利用重复来实现更实用的结构（例如Hyrax）？
没有可信任的安装程序：PoSt中是否存在不需要可信任安装的实用构造？
没有算术电路：是否存在Proof-of-Spacetime实现（使用复制证明），它不需要使用通用可验证计算？
优化算术电路：是否存在使用复制证明的空间证明电路的优化（例如，更多SNARK友好原语）？ （请参阅当前的复制构建或联系我们获取更多信息）
重要资料
Filecoin白皮书
复制证明
Filecoin复制动机证明（视频）
复制构建证明（视频）
信息来源：https://github.com/protocol/research/issues/5