刺猬文│从启动方式来看播客链的运行机制—设置验证者

刺猬文│从启动方式来看播客链的运行机制—设置验证者

创新互联公司专业为企业提供翠屏网站建设、翠屏做网站、翠屏网站设计、翠屏网站制作等企业网站建设、网页设计与制作、翠屏企业网站模板建站服务,十多年翠屏做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。

(图片出自网络,版权归原作者所有)


上一篇刺猬文我们介绍了播客链是如何实现Dpos的,其实质过程就是:节点A打包,将打包的区块发送给其它的节点,其它节点根据当前时间,判断是否应该由A节点进行打包。如果是,则认为打包成功;如果不是,则认为打包失败。


我们看上面的过程,发现一个问题:第一个打包节点是如何确定的呢?


这里似乎出现了一个先有鸡或者先有蛋的的问题。


节点产生一个由自己作为打包节点的交易,这个交易发送给其它节点,其它节点在得到这个交易后,要先确定这个节点是打包节点。


看吧,把自己绕进去了。


播客链是如何解决这个问题的呢?


这里要先介绍几个概念:


验证者:就是打包节点打包所使用的账号。例如节点A打包,那么它打包的时候就需要有一个账号,这个账号就是一个验证者。


我们知道以太坊有一个概念叫做Coinbase,是设置这个节点挖矿时使用的账号,那么在播客链启动时的流程就应该是这样的:

刺猬文│从启动方式来看播客链的运行机制—设置验证者

大家来看一下第五步、第六步和第七步:


第五步是将指定的账号解锁。这样一来,这个账号就是这个节点的Coinbase。


第六步,将这个Coinbase设置为本地验证者,这个设置是不会产生交易的。有这一步的原因,是为了产生交易判断的时候,可以通过判断避免上面说的先有鸡或者现有蛋的问题。


第七步,将这个Coinbase设置为验证人,这个设置会产生一个交易。


第八步,挖矿。由于刚才产生了一个交易,第八步挖矿可以保证将这个交易打包到区块中,这样一来,后面所有启动的节点,都将得到这个区块,都将知道这个账号("0x86bfbc33d4bef890c347d28fb714c00bf66c37a7")是验证者。


有了第一个验证者以后,播客链就可以正常的处理交易、打包区块了。


但总不能只有这么一个验证者吧。


我们知道,DPOS需要好多个验证者,验证者的数量和超级节点的数量是一致的。那就意味着播客链需要有23个验证者。

这些验证者是怎么产生的呢?产生以后如何全网通知,并让他们起作用呢?

下次我们就来说说播客链的第一个重要合约——投票合约,同时说一下播客链如何与合约进行交互,并获取到合约产生的结果的。


分享题目:刺猬文│从启动方式来看播客链的运行机制—设置验证者
分享地址:http://scyanting.com/article/gsgpds.html