windowPoSt是Filecoin时空证明的审核机制，它可以检查存储供应商是否在一段时间内持续有效地存储了数据。封装量转化想要为有效存储，就需要向链上提交subWindowPoSt消息，提交成功之后才能转换为算力。
这一基础概念，绝大部分读者都非常清楚，也非常关心自己的存储是否及时增长、下掉、被损坏。我们也经常哭笑不得地收到类似的问题：今日新增500T封装量，但是有效存储增长只有200T，甚至有的第三天才变成了有效存储，这里面是不是有问题啊？
事实上，这和封装流程、故障、技术等完全无关，一切都是windowPoSt的工作原理造成的。
windowPoSt的工作原理：横向排队、纵向提交
windowPoSt的工作原理，我们先简单的打个比方，假设有windowA、B、C、D……，如果把window A比喻成学生，整个流程就类似每隔24小时学生A、B、C、D……需要到链上按顺序签到，每轮签到时间是30分钟，学生A需要在第一个30分钟间隔内需要完成签到，学生B需要在第二个30分钟内完成签到，依次类推…..;如果A在30分钟内没有完成签到，则会受到惩罚。
但是，封装量具体是怎么提交subWindowPoSt消息的呢？window排序规则是什么？数量要求是多少？时间间隔又是从哪里开始算？
我们利用举例，按步骤拆解说明：
1、首先，每一个节点都有一个windowPoSt的起始提交时间，起始时间可能是一天的任何时间点。
我们假定64GiB节点α的起始提交时间为00:00:00。
2、其次，windowPoSt是每30分钟一个时间窗口，一天48个。
按此逻辑，节点α的window提交窗口如下：第一轮00:00:00-00:30:00，第二轮00:30:00-01:00:00……第四十八轮23:30:00-24:00:00。
3、节点α到了0点的起始提交时间，首先将节点的所有扇区，按照2300扇区组成一个window，48个window组成一行partition的方式排列。当window数量超出48后，新增的window按照顺序排到第二行，以此类推，排列成多行，形成多个partition，如下图所示：
4、第一轮window提交窗口00:00:00-00:30:00期间，节点α提交如图第一列黄色框选区域的window。每一条subWinowPoSt消息可以包含1-4个window，一个window提交窗口可以提交多条subWinowPoSt消息。
也就是说，假设节点α的window有如图4行，在第一轮window提交窗口，它可以提交4条subWinowPoSt消息，每一条包含一个window；也可以提交1条，包含4个window等。
分多条消息提交的优势，在于该条subWinowPoSt消息中包含错误扇区时，影响的window比较少；而尽量合并提交，可以节约资源，减少消息堵塞和GAS消耗。Filecoin官方通过FIP-0015还原FIP-009，以此鼓励后一种做法，这一点我们曾在《增长时代来临|HyperBrive批量预提交和聚合证明分析》进行过详尽分析。
5、如果从0点开始提交，而中途新增了封装量该怎么办呢？
答案是老老实实排队。所有的扇区，其window轮次，由扇区的起始高度决定，基本是不更改的。新增的扇区，按队列排在末尾，如下图中的A、B、C板块，就是节点α在当日17:30封装完成的扇区，排列完成后，发现其window提交窗口排布在当日第35轮-次日的9轮。
但是，如图示右侧的黄色框选区所示，这个节点的window轮次已经是第40轮，当前时间为20:00。
A部分的当日新增封装量已经错过它们所对应的window轮次。而B部分正好赶上了20:00之后的第40-48轮。C部分将在次日的1-9轮提交。
也就是，C部分比起A部分增长在后，但是首条subWindowPoSt消息时间竟然更早，更早转化为有效存储。
相信现在你已经明白了，为什么当日新增500TiB，但是转化为有效存储的部分可能只有200TiB了。
但是，现实情况中的windowPoSt，远比举例的图示更为复杂。比如节点的起始提交时间，不可能是正好的00:00:00；各存储供应商统计节点的新增封装量和有效存储的时间也不尽相同，0点、6点、8点等均有可能。
比较极端的举例：如果新增封装量正好在刚刚错过的轮次，也错过了统计时间，那么很有可能第三天才能统计到这一部分 新增存储。当然，一般情况下，最多在24小时内，新增封装量就能转化为有效存储。
