刺猬文│從啟動方式來看播客鏈的運行機制—設置驗證者

（圖片出自網絡，版權歸原作者所有）

上一篇刺猬文我們介紹了播客鏈是如何實現Dpos的，其實質過程就是：節點A打包，將打包的區塊發送給其它的節點，其它節點根據當前時間，判斷是否應該由A節點進行打包。如果是，則認為打包成功；如果不是，則認為打包失敗。

我們看上面的過程，發現一個問題：第一個打包節點是如何確定的呢？

這里似乎出現了一個先有雞或者先有蛋的的問題。

節點產生一個由自己作為打包節點的交易，這個交易發送給其它節點，其它節點在得到這個交易后，要先確定這個節點是打包節點。

看吧，把自己繞進去了。

播客鏈是如何解決這個問題的呢？

這里要先介紹幾個概念：

驗證者：就是打包節點打包所使用的賬號。例如節點A打包，那么它打包的時候就需要有一個賬號，這個賬號就是一個驗證者。

我們知道以太坊有一個概念叫做Coinbase，是設置這個節點挖礦時使用的賬號，那么在播客鏈啟動時的流程就應該是這樣的：

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

第五步是將指定的賬號解鎖。這樣一來，這個賬號就是這個節點的Coinbase。

第六步，將這個Coinbase設置為本地驗證者，這個設置是不會產生交易的。有這一步的原因，是為了產生交易判斷的時候，可以通過判斷避免上面說的先有雞或者現有蛋的問題。

第七步，將這個Coinbase設置為驗證人，這個設置會產生一個交易。

第八步，挖礦。由于剛才產生了一個交易，第八步挖礦可以保證將這個交易打包到區塊中，這樣一來，后面所有啟動的節點，都將得到這個區塊，都將知道這個賬號（"0x86bfbc33d4bef890c347d28fb714c00bf66c37a7"）是驗證者。

有了第一個驗證者以后，播客鏈就可以正常的處理交易、打包區塊了。

但總不能只有這么一個驗證者吧。

我們知道，DPOS需要好多個驗證者，驗證者的數量和超級節點的數量是一致的。那就意味著播客鏈需要有23個驗證者。

這些驗證者是怎么產生的呢？產生以后如何全網通知，并讓他們起作用呢？

下次我們就來說說播客鏈的第一個重要合約——投票合約，同時說一下播客鏈如何與合約進行交互，并獲取到合約產生的結果的。