（圖片出自網絡，版權歸原作者所有）
上一篇刺蝟文我們介紹了播客鏈是如何實現Dpos的，其實質過程就是：節點A打包，將打包的區塊發送給其它的節點，其它節點根據當前時間，判斷是否應該由A節點進行打包。如果是，則認爲打包成功；如果不是，則認爲打包失敗。
我們看上面的過程，發現一個問題：第一個打包節點是如何確定的呢？
這裏似乎出現了一個先有雞或者先有蛋的的問題。
節點產生一個由自己作爲打包節點的交易，這個交易發送給其它節點，其它節點在得到這個交易後，要先確定這個節點是打包節點。
看吧，把自己繞進去了。
播客鏈是如何解決這個問題的呢？
這裏要先介紹幾個概念：
驗證者：就是打包節點打包所使用的賬號。例如節點A打包，那麼它打包的時候就需要有一個賬號，這個賬號就是一個驗證者。
我們知道以太坊有一個概念叫做Coinbase，是設置這個節點挖礦時使用的賬號，那麼在播客鏈啓動時的流程就應該是這樣的：
大家來看一下第五步、第六步和第七步：
第五步是將指定的賬號解鎖。這樣一來，這個賬號就是這個節點的Coinbase。
第六步，將這個Coinbase設置爲本地驗證者，這個設置是不會產生交易的。有這一步的原因，是爲了產生交易判斷的時候，可以通過判斷避免上面說的先有雞或者現有蛋的問題。
第七步，將這個Coinbase設置爲驗證人，這個設置會產生一個交易。
第八步，挖礦。由於剛纔產生了一個交易，第八步挖礦可以保證將這個交易打包到區塊中，這樣一來，後面所有啓動的節點，都將得到這個區塊，都將知道這個賬號（"0x86bfbc33d4bef890c347d28fb714c00bf66c37a7"）是驗證者。
有了第一個驗證者以後，播客鏈就可以正常的處理交易、打包區塊了。
但總不能只有這麼一個驗證者吧。
我們知道，DPOS需要好多個驗證者，驗證者的數量和超級節點的數量是一致的。那就意味着播客鏈需要有23個驗證者。
這些驗證者是怎麼產生的呢？產生以後如何全網通知，並讓他們起作用呢？
下次我們就來說說播客鏈的第一個重要合約——投票合約，同時說一下播客鏈如何與合約進行交互，並獲取到合約產生的結果的。