bitget消息：上一篇文章中，我们探讨了Stefan Dziembowski[14]从数学角度对PoC的形式化模型和证明的讨论，Burst则是在工程角度实际运行的PoC完备系统。
两者在理念上是完全一致的，但Burst在实现细节上却与该论文提出的模型和交互不完全相同。
本篇文章我们会从Plot文件和出块流程两方面讨论PoC的算法细节，同时末尾结合Stefan Dziembowski的模型讨论Burst是否可以纳入其框架之下。
PoC硬盘利用与Plot文件
Plot文件即每一个参与出块的节点或是矿工需要在硬盘中存储的文件，其内容由大量特定结构的Hash值组成。Plot文件包含以下的几个基本概念:
Shabal256：Shabal256是BurstCoin所使用的Hash算法，相比SHA256等Hash算法，Shabal需要更多的CPU计算时间和计算量。结合上一章节的内容我们可以了解，BurstCoin选用Shabal一方面是因为在出块阶段矿工并不需要进行大量的Hash运算，另一方面也可以通过计算代价来防止可能的恶意矿工在每个出块阶段临时计算需要的Hash值而非存储中的Hash值。Nonce：Nonce是Plot文件中拥有固定编号的基本单元，由256KB的数据构成，是矿工用来参与PoC过程的基础逻辑单元。Scoop：每个Nonce文件由4096个Scoop文件构成，同样拥有编号，其编号范围为0-4095。而每个Scoop文件包含2个Hash值，也即一个Nonce文件包含8192个Hash值。
Nonce的生成流程如下：
1.Nonce文件的种子由Account Id(即BurstCoin网络中的用户地址或者用户Id) 与Nonce Id(即nonce编号)组成，经过第一次Hash，生成Hash #8191，即Non中的编号为8191的Hash值。
2.#8190Hash值由之前一个#8191Hash值与Account Id，Nonce Id 生成。
3.#8189Hash值由之前两个#8191Hash，#8190Hash值与Account Id，NonceId 生成，依次类推，每下个Hash值，都有其之前计算的所有Hash值与AccountId，Nonce Id 生成。如果过程中超过了4096个bytes，则取最近生成的4096bytes作为下一次的Hash函数输入参数。
4.最终Hash的生成，由Hash#0-8191与Account Id，Nonce Id共同生成，之后对8192个Hash值都分别对其进行异或操作，作为每个Hash最终的值。
5.得到了8192个Hash值后，Scoop文件的结构如下图所示:
至此，我们生成了1个完整的Nonce文件，一个Nonce文件包含8192个Hash值，占用空间256KB。
这同时也是矿工参与挖矿的最低门槛，即只要有大于等于1个Nonce文件即可参与挖矿。
按照目前BurstCoin全网算力估计，3PB大约占全网算力的百分之一，那么需要多少个Nonce？经过简单计算我们得知，大约需要117亿左右个这样的Nonce。
而一般的家用主机以500G为例，仅可以存储200万个Nonce。
故在BurstCoin的世界里，低算力基本也都是以参与矿池的形式参与挖矿的过程。
PoC的共识与出块
上一章节我们介绍了Plot文件与其基本结构，本章节我们将介绍PoC作为区块链共识，其完整的挖矿流程是怎样的，其同时探讨几个共识中的核心问题，最后与Stefan Dziembowski的理论相结合，探讨两套体系的关联和异同。
上图是一个完整的PoC共识出块流程，下面我们将结合图示分别介绍其每一个步骤。
步骤1-2，GenHash的生成：GenHash类似于BitCoin中BlockHash的概念，用于形成前后相继的区块链结构。
BurstCoin中，由于该Hash同时参与共识过程中参数的建立，其将概念拆分为两个：
GenSig由上一个区块中的GenSig与上个区块的出块者做Hash得出，GenHash由GenSig与快高信息做Hash得出。通过这样两次Hash计算，即将当前区块前的所有区块形成了不可修改历史区块的链式结构，同时也得出了PoC共识中的重要参数GenHash。
步骤3-4. Scoop Number的计算：钱包生成GenHash后，将此值发送给矿工，矿工由此计算本次出块需要的Scoop Number。GenHash Modulo 4096 即是Scoop Number的值。该Scoop Number用来定义本次出块中，全网的所有矿工应当查询自己拥有的所有Nonce中的Scoop的数据。结合上一章节内容我们可以得知，也即其拥有的某个Scoop中两个Hash的值。
步骤5，计算target，deadline：首先，矿工需要遍历磁盘，找到自己拥有的所有nonce中对应于上一步计算出的Scoop Number的两个hash，记为scoopdata，使表达式 target=Hash(scoopdata, GenSig)的值最小。之后利用该最小值targer，计算target/BaseTarget得出deadline。target类似bitcoin中的difficulty_target参数，控制全网挖矿难度，而dealine决定了了该矿工产生的区块在全网中是否成功得到该区块铸造权。
上述每个参数：
deadline：是一个整数类型数值，一个拥有特定deadline的区块，在全网中需要等待对应于该deadline所指定的时间之后，才可以被作为一个合法的区块。举例来说，如果deadline为60，则代表在上一个块出块时间一分钟后，这个块可以被允许添加到主网作为合法区块。由此我们可以得知，计算得出deadline越小的矿工，越有胜算得到当前块的铸造权。而deadline的计算过程是矿工通过遍历自己所有随机生成的Nonce中的值计算得出，也即代表所拥有Nonce个数越多，磁盘占用空间越大，获取数值更低的deadline的概率更大，从而得到铸块权的概率也更大。BaseTarget：BurstCoin设定的全网平均出块时间为4分钟，全网的存储算力是波动，如何在波动的算力下控制全网平均出块时间？类似与BitCoin，BaseTarget代表挖矿难度，其值越小，说明全网挖矿难度越高。在burstcoin中，最小的target需要除BaseTarget得到最后deadline。所以对BaseTarget的动态调整，可以直接控制全网的区块间的间隔，也即区块时间。
步骤6-9，打包交易，铸造区块，广播区块。此过程与所有区块链系统类似。值得一提的是，BurstCoin的区块负载大小限制为176KB，平均可以承载19k个左右的交易，不难得出其理论tps上限控制在80左右，与Bitcoin和Eth等PoW类型的区块链系统相比，其性能量级也是相类似的。
综上所述，本次我们以BurstCoin为例，详细介绍工程中的PoC共识算法的实现，主要集中在Plot文件内容的生成，与出块的详细交互和计算流程。
在下一篇文章中，我们提取几个PoC共识过程的核心问题，帮助读者更好地理解PoC算法，同时结合Stefan Dziembowski的模型讨论Burst是否可以纳入其框架之下和一些思考的分享，敬请期待。
