在本文中，我们将提取PoC共识过程中的几个核心问题，并比较Stefan Dziembowski的模型，讨论其与Burst的模型的异同，并介绍PoC的基本文件结构和挖掘过程，可以帮助我们更好地理解PoC算法。
如何解决基于截止期的阻塞过程中分布式节点的时间同步问题？
区块链系统作为一种特殊类型的分布式系统，继承了分布式系统的特点和问题。熟悉分布式系统的读者可能知道，在设计分布式系统时，必须考虑到分布式系统的一个重要特性，那就是缺少全局时钟，即分布式系统中不存在唯一的全局时钟。
在BurstCoin系统中，不同的矿工向不同的节点广播不同期限的块，不同的节点对当前时钟有不同的理解。节点如何确定当前块是否满足广播条件？在网络中收到同步块后，如何验证截止时间是否合法？
要解决时钟不同、步调不一致造成的不同步问题，在分布式系统中，一般需要尽量形成一个逻辑“时钟”，让每个人都能认出这个“时钟”而不是自己的。
这个逻辑时钟的第一个实现是Lamport时间戳。虽然Lamport时间戳的学术价值大于实际价值，并没有被系统实际使用，但是，在其中出入的向量时钟，却被AWS S3、DynamoDB、Riak等系统广泛使用，以保证同一对象的因果关系。
矢量时钟算法严重依赖于节点间的信任，因此只适用于可靠的分布式环境。然而，作为一个运行在节点互不信任的P2P网络上的区块链系统，这是无法保证的。那么，比特币这样的分布式系统是如何确定时间(因果)的呢？在中本聪比特币的设计中，PoW的产物block被巧妙地应用为系统的逻辑时间(引用比特币白皮书):
我们提出的解决方案从时间戳服务器开始。时间戳服务器的工作方式是获取一组要打上时间戳的项目的散列，并广泛地公布该散列，例如在报纸或《新闻组邮报》上公布。时间戳证明数据当时一定存在，显然是为了进入散列。每个时间戳的散列中都包含前一个时间戳，形成了一个链，每个额外的时间戳都会加强前一个时间戳。
每个块包含一个Unix时间戳。除了作为块散列的变化源之外，它们还使得对手更难以操纵区块链。如果一个时间戳大于前11个块的中值timestamp，并且小于网络调整时间2小时，则该时间戳被视为有效。“网络调整时间”是连接到您的所有节点返回的时间戳的中间值。因此，块时间戳并不精确，也不需要精确。封锁时间精确到一两个小时以内。每当一个节点连接到另一个节点时，它都会从该节点获取一个UTC时间戳，并存储它相对于节点本地UTC的偏移量。网络调整时间则是节点本地UTC加上所有连接节点的中间偏移量。但是，网络时间的调整不会超过本地系统时间的70分钟。比特币使用无符号整数作为时间戳，因此2038年的问题又被推迟了68年
BurstCoin也在一定程度上继承了比特币的核心思想。时间戳以逻辑时间顺序存在，而不是真正准确的时间。
一般它和真正的UTC时间有1-2个小时的误差。同时，BurstCoin的特殊性在于，一个区块链接成功与否，与其计算的截止日期直接相关。因此，我们可以在BurstCoin源代码中找到以下验证过程：
验证流程：
该过程将当前块截止时间的值与当前块时间戳和其前任时间戳之间的差值进行比较。其中时间戳是块高度为0的第一块的时间偏移，允许一定程度的误差。在误差允许的范围内，全球时钟的存在没有必要，区块链系统在“计时”上已经形成共识。
死亡的
当我开始阅读BurstCoin源代码时，我很疑惑，块数据库中没有使用完整的勺子，也不涉及Merkle的操作。如何检查一个块的截止日期的合法性？
还记得在系列的第二篇文章中，我们讨论过在Stefan Dziembowski提出的PoC系统中，使用Merkle树来简化验证过程，BurstCoin中没有关于Merkle树的计算。
kle树的相关性计算。
笔者在通读了BurstCoin源代码后，发现BurstCoin中采用了一种更巧妙的计算方法，来检查根据PoC consensus中存储的内容计算出来的consensus参数deadline。下面我们来解释一下：
1.当一个节点接收到P2P网络中的一个历史块或矿工广播的一个广播块时，它必须首先对该块进行预校验操作。这是调用者提交的参数，scoopData始终为null，因为在burstCoin使用的数据存储中，scoopData不存储在Block的字段中。那如何完成验证呢？
2.答案就在calculateHit方法中。BurstCoin将其节点的一些函数方法放在burstKit的一个单独的jar包中。找到它的calculateHit方法后，我们发现它调用了MiningPlot的初始化方法。
3.在MiningPlot方法中，我们可以看到，通过两个参数nonce Id和accountId来回忆Nonce文件的生成算法，就可以知道通过Nonce Id和accountId完全可以生成两个Nonce文件。因此，在BurstCoin中，矿工不需要向节点发送大小为256KB的Nonce文件，只需要在参与分块时向wallet节点发送分块内容和这两个参数，wallet就可以计算出整个Nonce值。同时，整个网络中的每个节点在接收到每个块后都会计算这个Nonce。
了解BurstCoin中Deadline的合法性验证流程，并与Stefan Dziembowski的协议流程进行对比。在BurstCoin中，因为没有Merkle树的计算，所以BurstCoin的存储文件F的初始化是完全非交互的。
f初始化是完全非交互式的。
挖掘者只需要遵循协议，生成一个特定图结构的Nonce文件。(在Burst中，也就是Nonce文件的算法方法可以批量生成Nonce。实际上，Nonce文件的计算过程可以完全符合Stefan Dziembowski的图模型，其中每个Hash都是Nonce图结构中的W值。BurstCoin使用的图结构与Stefan Dziembowski的不完全相同，但也有复杂的前件、后继和连接关系。理论证明不是突发给出的，总体证明思路是
这无疑是一个非常重要的优化，因为在分布式系统中，复杂的交互往往会带来协议的复杂性，而由于网络中节点数量众多，交互的复杂性往往会因为P2P网络中的网络延迟和网络波动而难以实现。
现有的网络延迟和网络波动变得难以实现。
Stefan Dziembowski在验证阶段使用Merkle的结构使验证变得极其高效，但是在具有巨大网络容量、交互
在这一点上，BurstCoin选择了节点在验证阶段需要额外的8192次哈希计算，从而带来初始阶段完全非交互的文件初始化，以及验证阶段更小的网络数据传输量(只需要像节点一样发送包括nonce Id和accountId在内的少数固定参数)，这对于区块链系统本身来说无疑是更合适的选择。
固定参数)，这对于区块链系统本身来说无疑是更合适的选择。
的选择。
另一方面，Stefan Dziembowski提出的相对复杂的初始化过程更适用于网络条件相对不同的联盟链系统和授权区块链系统，以及一些网络条件相对较好的对等系统。
BurstCoin如何处理叉子？在战俘共识的区块链体系中，与福克斯打交道的逻辑非常简单明了。所有诚实的节点都应该认为当前网络中最长的链就是主链。但在PoC共识中，事情并不那么明显。相对于十分钟的比特币分块时间，大部分时间都花在矿工计算当前分块的nonce上，用于消耗大量的CPU时间。
BurstCoin挖矿本身不需要密集的CPU运算时间，所以矿工总是可以在30秒内遍历磁盘，计算出来的截止时间就是真相。
在比特币共识中，链的长度反映了当前链投入的CPU计算量，而在Burst中，反映硬盘空间占用量的指标是累计了多少个有效截止期。在所有区块高度为一加一的竞争者中，产生较小区块截止时间的矿工在概率上使用更多的存储空间，所以
区块内的矿工在概率上使用了更多的存储空间，因此获得了施放区块的权利。
，从而获得铸块权。
类似地，如果你考虑分叉场景，爆裂
在实际的Burstcoin系统中，引入了累积困难。
累积困难的概念。
它的计算
ty的概念。
其计算公式如下：
公式如下：
同时，需要为每个块重新计算baseTarget:
在BurstCoin中，所有诚实的节点应该
其实这个结论理解起来并不复杂。
观察baseTarget的计算过程，我们知道当前块的截止时间会影响下一个块的挖掘难度，即当前截止时间越小，下一个块的baseTarget就越小，当前块的附加难度就越大，所以累计难度指数反映了每个子链中所有块的难度之和。
MulativeDifficulty是一个指标，反映了每个子链中所有块的难度之和。
与PoW类似，链的长度本质上代表了链中投入的计算资源量。在PoC中，通过c
通过对这三个问题的详细讨论，结合源代码分析，相信读者能够透彻理解PoC共识的内容、思想和算法细节。
读者可以对PoC共识的内容、思路、算法细节有一个透彻、详细的了解。
#硬盘挖掘
试着理解。
#硬盘挖矿# #硬盘狗社区#
我的# #硬盘狗社区#