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