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