播客鏈目前已經到了測試階段了。
很多熟悉我文章的讀者都知道，播客鏈採用的是DPos的共識機制。那播客鏈是如何將Pow修改成DPos的呢？除了修改成DPos之外，播客鏈還修改了很多地方，例如：在交易中增加了擴展字段、取消了基礎合約的Gas消耗、增加了合約的等級、定時基礎鏈與合約產生交互，從而獲取合約中所設置的一些信息……嗯，真改得蠻多的。
下面這張PPT是播客鏈對於以太坊修改的整個情況。
修改了這麼多的內容，如何將它們聯合起來，讓播客鏈正常運行呢？
從今天開始，我和大家聊聊播客鏈增加的這些內容都是如何實現的。
首先是如何改造以太坊Pow的問題。
大家都知道以太坊採用了兩種共識機制，在正式鏈上採用的是Pow的共識機制，在測試鏈上採用的是Poa的共識機制。那如何將以太坊公網的Pow機制改成DPos機制呢？
DPos機制其實就是一種出塊節點輪詢的模式。
例如有100個節點，其中有23個節點作爲出塊節點，那麼我們只要能夠精確地計算出某一個時刻，應該是由哪一個出塊節點來進行出塊，就可以了。
這要怎麼做呢？
我們需要知道一些信息，例如出塊速度是多少？這裏的速度一定是確定的，而不像以太坊那樣出塊時間不確定。爲了讓我們得到某一個時刻應該由哪一個出塊節點來進行出塊，我們需要定義一些術語：
1.出塊週期：就是從確定一批出塊節點開始，到這一批出塊節點結束的一個週期時間。假設我們設置每2天爲一個出塊週期，這就意味着，我們每2天就有機會修改出塊節點的成員信息。
2.出塊時間：說明我們每一次出塊的時間間隔是多久。這裏和Pow有點區別：對於以太坊來說，一個出塊時間大致是在12秒左右浮動。這就意味着我們無法確切地知道某一刻是否應該出塊。這在Dpos中是不允許的，因爲Dpos機制中每一個出塊節點之間的關係不再是競爭關係，而是協作關係，這也就意味着每一刻，、每一個節點都能計算出當前時間應該由哪一個節點來進行出塊打包。
3.出塊節點數量：對於Pow來說每一個節點都可以進行出塊，但對於DPos來說，只能是特定的節點來進行出塊。
有了以上三個術語信息，我們就可以計算出任意一個時刻應該出塊的節點信息了。
我們來舉個例子，說明如何計算出某一時刻該有哪個出塊節點來進行出塊的。
假設：
出塊週期（EpochInterval） = 1天 = 86400秒
出塊時間 （ProducerInterval）= 5秒
出塊節點 （producerSize）= 23個
當前時間 = 21006055
根據當前時間計算當前出塊節點的實現如以下代碼：
根據這段代碼我們可以計算出：
Offset= 21006053 % 86400 = 10855
Offset= 10855 / 5 = 2171
Offset= 2171 % 23 = 9
計算這三個Offset的代碼分別是：
這樣可以得到當前時間出塊節點，應該是出塊節點數組中第9個位置的節點。
所有節點都通過上面的公式來計算，出來的結果一定是相同的，這樣所有的節點就達成了共識。
假設其中有一個節點的公式被人爲做了修改，他所計算出來的結果和別人的不相同，他所打包的區塊，將不會被其它節點所承認，這就意味着它打包失敗了。
這個過程是怎麼做的呢？
在播客鏈中，節點打好包以後，會在包頭中寫入打包這個區塊的賬號信息，以及這個區塊的打包時間。這樣一來，當這個區塊發送給其它節點後，其它節點就可以根據這兩個信息來檢測這個區塊是否是由當時改打包節點來進行打包的。
這個過程就是播客鏈的DPos運行機制。
其實這個機制比較簡單，麻煩的會是下一個：如何確定打包者節點的方式。
網上的很多做法都是定義一個特殊的交易，然後在每一個週期開始的時候，節點讀取本節點的候選人的Hash樹信息，根據規則來生成打包者。但是這種方式我們覺得靈活性非常差，要對這種生成打包者的規則進行修改的時候，那就意味着必須要更新鏈才能做到。
這種方式還無法做到手動限制。
所以播客鏈採用的是：基礎鏈和合約進行交互的方式，將這種規則放到合約之中，這樣可以大大增加生成打包者的靈活性。
下一期我將簡單介紹一下播客鏈是如何做到這一點的。