刺猬文│从启动方式来看播客链的运行机制—设置验证者-创新互联
(图片出自网络,版权归原作者所有)
上一篇刺猬文我们介绍了播客链是如何实现Dpos的,其实质过程就是:节点A打包,将打包的区块发送给其它的节点,其它节点根据当前时间,判断是否应该由A节点进行打包。如果是,则认为打包成功;如果不是,则认为打包失败。
我们看上面的过程,发现一个问题:第一个打包节点是如何确定的呢?
这里似乎出现了一个先有鸡或者先有蛋的的问题。
节点产生一个由自己作为打包节点的交易,这个交易发送给其它节点,其它节点在得到这个交易后,要先确定这个节点是打包节点。
看吧,把自己绕进去了。
播客链是如何解决这个问题的呢?
这里要先介绍几个概念:
验证者:就是打包节点打包所使用的账号。例如节点A打包,那么它打包的时候就需要有一个账号,这个账号就是一个验证者。
我们知道以太坊有一个概念叫做Coinbase,是设置这个节点挖矿时使用的账号,那么在播客链启动时的流程就应该是这样的:
大家来看一下第五步、第六步和第七步:
第五步是将指定的账号解锁。这样一来,这个账号就是这个节点的Coinbase。
第六步,将这个Coinbase设置为本地验证者,这个设置是不会产生交易的。有这一步的原因,是为了产生交易判断的时候,可以通过判断避免上面说的先有鸡或者现有蛋的问题。
第七步,将这个Coinbase设置为验证人,这个设置会产生一个交易。
第八步,挖矿。由于刚才产生了一个交易,第八步挖矿可以保证将这个交易打包到区块中,这样一来,后面所有启动的节点,都将得到这个区块,都将知道这个账号("0x86bfbc33d4bef890c347d28fb714c00bf66c37a7")是验证者。
有了第一个验证者以后,播客链就可以正常的处理交易、打包区块了。
但总不能只有这么一个验证者吧。
我们知道,DPOS需要好多个验证者,验证者的数量和超级节点的数量是一致的。那就意味着播客链需要有23个验证者。
这些验证者是怎么产生的呢?产生以后如何全网通知,并让他们起作用呢?
下次我们就来说说播客链的第一个重要合约——投票合约,同时说一下播客链如何与合约进行交互,并获取到合约产生的结果的。
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网站标题:刺猬文│从启动方式来看播客链的运行机制—设置验证者-创新互联
标题来源:http://scjbc.cn/article/dhjihg.html