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

（图片出自网络，版权归原作者所有）

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

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

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

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

看吧，把自己绕进去了。

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

这里要先介绍几个概念：

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

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

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

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

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

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

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

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

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

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

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

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