大家好，上次分享我们讲解了区块大小和出块时间跟扩容的关系，我们特别的阐述了在区块链的系统中这两个变量是如何互动和制约的。今天我们会详细讨论在DAG的系统中这两个变量的关系，以及在SoteriaDAG的设计里，我们是怎么处理这个问题的。
并发下的亲子关系
上一篇我们讲到，在BlockDAG区块图的大背景下，因为没有赢者通吃的这一限制，于是矿工们可以并行的挖矿，并及时的把挖出来的区块广播出去。网络的传输导致了延迟，所以在网络的任何一个地方我们能听到的其他矿工的广播也可能是不一样的。不过没关系，对于我们收到的块，我们想尽办法把他们纳入到我们的区块图里就行了。而我们下一个要挖的新块一定要引用我们区块图里的每一个还没有被引用的块。燃鹅，你会发现我们可能收到下图这样的一些区块，他们的引用都不一样，而且他们都是诚实节点挖出来的合法区块。这是怎么回事儿呢？这正是由我们之前谈到的区块大小，传输时间和出块时间所导致的。
ETC将正式激活DAG限制和MESS两项提案:10月1日，Ethereum Classic官方发推称，ETC核心开发者大会针对51％攻击解决方案和Epoch校准提案（DAG限制）进行了讨论。最终结果为：
1.ECIP-1099提案，即固定DAG大小限制将正式激活；
2.ECIP-1100（MESS）提案将正式激活，即修正指数主观评分，为网络安全提升了额外的指数难度；
3.其他所有应对51%攻击的ECIPs仍保留在草案中。[2020/10/1]
假设上边这个状态是下图里节点B所观测到的状态。那么之所以每个收到的区块的父辈链接不同是因为信息在网络上传播耗时不同所导致:假设网络因为地理或者逻辑的链接被切分成三个传播区域，绿色的区域夹在红色的和蓝色之间，信息从绿色区域传到红色或者蓝色区域有一定的延迟，蓝色和红色区域之间传送信息要经过绿色区域所以延时更大。为了简单，我们就认为这种跨区域的延迟是临区域延迟的两倍。节点A，节点B和节点C分别生成了区块a，区块b和区块c，他们马上把区块向网络的所有方向广播出去。在红色区域的节点D和在蓝色区域的节点E和节点F都会在不同时间收到这些区块。因为节点ABC在网络上相对于节点D和节点E/F的网络位置，带宽，延迟都不一样，所以他们收到完整的区块abc的时间也不一样。所以在某个时刻，节点D只收到了区块a和区块b而区块c还在传播的路上；节点E/F只收到了区块b和区块c，而区块a还在路上。节点B最为和出块的节点最近的节点，除了他自己生成的区块b以外，所有其他的区块也都收到了。
ETC社区即将实施ETCIP1099升级提案，将缩减ETC的DAG大小至3G以下:ETC社区即将实施ETCIP1099升级提案。该提案将缩减目前ETC的DAG（有向无环图）大小至3G以下，提案实施后，4G显卡挖掘ETC的寿命将被延长至少3年。注，当前ETC的DAG大小为3.91GB。[2020/9/27]
当节点D，E，F开始挖下一个区块的时候，根据“包容”的原则，他们会把新的区块的父辈链接锁定在他们刚刚收到的这些区块上，然后再马上广播出去。也就是，节点D生成了一个链接在区块a和区块b的区块d，节点B生成了一个链接在区块a,b,c上的区块b'，而节点E和节点F分别生成了链接在区块b，c的区块e和区块f。这恰恰是之前我们看到的BlockDAG的状态。很明显，区块a，b'，e，f之间不可能有任何链接，也就是说他们都是一代的，或者说他们都是兄弟姐妹。跟之前区块链的构造里“独生子女”的政策比起来，在区块图的环境下会出现“多子多福”的情况了。我们没有调整区块大小和出块速度，就自动扩容了。而兄弟姐妹的数量就反映着我们扩容的能力。我们暂且叫它K。为了科学地描述K，我们给出如下的表述：对于任何一个节点，当它在时间t的时候产生了一个区块b；而网络对区块的最大传输延迟为Dmax，即在任何两个节点完成传输一个标准大小的区块所需的时间；那么在如下这个区间：
动态 | F2Pool鱼池：建议使用Linux系统解决DAG文件体积过大问题:F2Pool鱼池官方微博表示，有1063矿机的矿工可以使用Linux系统，这种本身不需要界面渲染不占用显存的系统。按照DAG文件体积的增加速度推算，DAG文件体积达到3GB，大概需要到明年4月份。但在这之前，ETH可能已开始逐步转向PoS。[2018/12/15]
里面整个系统里生成的区块都应该是区块B的兄弟姐妹。这个非常好理解：在t时刻，因为网络传输，所有在这段时间里产生的区块还没有传到这个节点，所以在生成B的时候不会把这些区块当成父辈节点用来链接。同理，在这段时间里开始挖矿的节点也因为传输延迟，还没有听到区块B，所以那些节点生成的区块中也不能把B当作父辈节点来链接。那么，如果系统的出块速度是r的话，那么平均下来，这段时间产生的区块数量的上限就是：
声音 | 神鱼：建议使用Linux系统解决DAG文件体积过大问题:F2Pool 鱼池联合创始人神鱼微博发文称，不少ETH矿工又遇到了今年四五月份遇到过的问题，1063显卡在挖ETH时，DAG文件体积超出可用显存，导致ETH挖矿异常。但不同的是，当时还可以通过升级挖矿软件或者换用Windows7系统来降低显存占用率，来拯救1063矿机。经过半年多时间，DAG文件体积已经从半年前的2.4G提升到2.79G，进一步压缩了系统可用显存的空间。根据Investoon数据显示，ETH的DAG文件体积还在日益增加，也许一个月后，部分还侥幸残存的1063矿机也将告别ETH挖矿。
神鱼建议，有1063矿机的矿工可以使用Linux系统，这种本身不需要界面渲染不占用显存的系统，比如目前做的比较优秀的minerOS等Linux挖矿系统。按照DAG文件体积的增加速度推算，DAG文件体积达到3GB，大概需要到明年4月份。但在这之前，ETH可能已经开始逐步转向POS了。[2018/12/15]
(t+Dmax)-(t-Dmax)
——————————
r
也就是
2Dmax
———
r
所以，扩容能力仍然是被网络传输延迟和出块速度所制约的，但是这一次，没有了之前的那些限制了。真的没有这些限制了吗？当然不是了。首先，上边的描述是非常近似的结果，更加严谨的结果大家可以参考Phamtom的paper的第四章；另外更重要的是即使是严谨的结果放在工程实现的环境下就会出现更多的限制条件，比如接收区块的处理时间，区块图链接的时间，区块的验证时间。这些时间都直接的影响到实际运行中区块图的链接特性。所以真正能够实际操作的并发扩容参数比理论值可能会小一个数量级。从工程的角度上，我们采用了根据应用场景反推K的方法：首先确定一个吞吐量的要求范围，然后根据系统运行环境的网络传输性能的范围，确定一个Dmax，之后在Dmax的基础上认为添加一些软件方面的延迟，最后把上述几个参数通过在仿真系统里多次运行得出一个优化的系数。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。