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

（圖片出自網(wǎng)絡(luò)，版權(quán)歸原作者所有）

上一篇刺猬文我們介紹了播客鏈?zhǔn)侨绾螌崿F(xiàn)Dpos的，其實質(zhì)過程就是：節(jié)點A打包，將打包的區(qū)塊發(fā)送給其它的節(jié)點，其它節(jié)點根據(jù)當(dāng)前時間，判斷是否應(yīng)該由A節(jié)點進行打包。如果是，則認為打包成功；如果不是，則認為打包失敗。

我們看上面的過程，發(fā)現(xiàn)一個問題：第一個打包節(jié)點是如何確定的呢？

這里似乎出現(xiàn)了一個先有雞或者先有蛋的的問題。

節(jié)點產(chǎn)生一個由自己作為打包節(jié)點的交易，這個交易發(fā)送給其它節(jié)點，其它節(jié)點在得到這個交易后，要先確定這個節(jié)點是打包節(jié)點。

看吧，把自己繞進去了。

播客鏈?zhǔn)侨绾谓鉀Q這個問題的呢？

這里要先介紹幾個概念：

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

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

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

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

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

第七步，將這個Coinbase設(shè)置為驗證人，這個設(shè)置會產(chǎn)生一個交易。

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

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

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

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

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

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