《求真區塊鏈》是 Fractal 思想庫傾力打造的系列科普欄目,抱誠守真地輸出科普內容,旨在讓更多人的瞭解各項區塊鏈技術的內在價值與差別。算法
今年年初,以太坊進行了君士坦丁堡升級,伴隨着升級,以太坊什麼時候能切換成 PoS 再次成爲了你們熱切關注的一個問題。衆所周知,PoW 算法存在大量資源浪費,算力集中等問題,以太坊從17年開始就一直想要切換到 PoS 算法。可是因爲種種客觀條件的限制,一直沒有實質性的發展。在放了廣大區塊鏈愛好者幾年鴿子後,以太坊 2.0 終於要使用 PoS 算法了。本着獨樂樂不如衆樂樂的中國傳統美德,Fractal 的技工們決定跟你們分享一下,咱們關於下一代以太坊共識協議——Casper 的見解。安全
本系列文章將會分爲多個部分,這篇文章首先爲你們解讀一下 Vitalik 關於 Casper FFG 的論文,既如何在現有以太坊的 PoW 協議上疊加一個 PoS,在減小礦工挖礦獎勵的同時提升系統的安全性。網絡
Casper 其實有兩個版本,一個是 Vitalik 領導的 Casper FFG,另外一個是 Vlad 領導的 Casper CBC,他們的不一樣之處就在於 FFG 更多的是做爲一個過渡協議,使得以太坊可以從 PoW 成功過渡到PoS;而 CBC 則是以太坊切換到 PoS 後一個更好的版本,但從目前來看 CBC 仍有不少細節須要進一步研究和探討。函數
FFG 的主要思想是藉助 PoS 幫助 PoW 產生的區塊最終確認,進而在減小礦工獎勵的狀況下來提升系統的安全性。區塊鏈
參與者經過抵押必定量的 stake 成爲 Validator,Validator 負責運行 PoS 協議,爲描述的便利性,假設在協議的過程當中 Validator 保持不變。PoW 的以太坊會產生一棵樹,若是 Validator 對每個區塊進行投票,會增長網絡傳播開銷,爲了減小 Casper 中投票的數量,將 100 個區塊壓縮成一個 checkpoint,如圖1所示: spa
圖1 區塊壓縮成checkpointcode
將區塊壓縮以後咱們獲得了圖2,而且爲每個 checkpoint 提供了一個高度函數h(bi):區塊 bi 到根結點 r 的跳數。blog
圖片描述
圖2: checkpoint 高度函數圖片
首先,咱們從總體上描述一下 Casper 的共識過程。參與共識的 Validator 會對上文中所述的 checkpoint 進行投票。每一個 Validator 投的是一段 checkpoint,從 justified checkpoint 開始到若干個 checkpoint 以後的一個 checkpoint。咱們規定第一個 justified checkpoint 是創世區塊,當一個 checkpoint 收到了超過 2/3 的從 justified checkpoint 到它的投票,那麼這個區塊就變成了justified。資源
例如,在圖2中存在超過了2/3的從創世塊 r 到 b1 的投票,那麼 b1 就變成 justified;當存在超過 2/3 從 b1 到 b2 的投票,那麼 b2 就是justified,以此類推。當一個 justified checkpoint ,收到了超過 2/3 從它出發到它的某個子 checkpoint 的投票時,那麼這個 checkpoint 以及其以前到全部的 checkpoint 都已經被確認。
在將 PoW 產生的區塊壓縮成 checkpoint 以後,Validator 對於這棵樹進行投票,投票規則以下:
vote=<v , s , t , h(s) , h(t)>
其中:
v :Validator的身份信息; s :任意一個justified的checkpoint的hash,能夠理解爲源checkpoint。關於justified的定義咱們以後會詳細講解; t :任意一個 的子孫節點的hash,能夠理解爲目標checkpoint; h(s) : s的高度; h(t) : t的高度;
在定義了投票規則以後,定義任意兩個checkpoint之間的關係:
supermajority link:對於一對checkpoint (a , b),寫做(a→b),若是有超過 2/3 的 validator 投票 vote= , 可稱做(a→b)是一條supermajority link,而且h(b)≥h(a)+1
conflicting:若是兩個checkpoint在不一樣的分支上稱之爲conflicting。
圖片描述
圖 3:Casper結構示意圖
如圖3所示,其中, (r→b1)(b1→b2)(b2→b3)是supermajority link,b2,a3是conflicting。
在有了 checkpoint 之間關係的定義以後,定義 checkpoint——c 的兩種狀態:
-c 是 justified:
1)c = root :checkpoint c是根; 2)或 存在(c'→c),即 c' 到 c 的 supermajority link,而且c'是 justified;
-c 是finalized:
a)c 是justified; b)存在(c'→c) , c' 到 c 的supermajority link; c) c , c' not conflicting; d) h(c')=h(c)+1;
在圖3中, (r , b1 , b2 , b3)是 justified,(a2 , b3) 是 finalized。若是一個 checkpoint 狀態是 finalized,那麼它以及它以前全部的 block 都會確認。
爲了防止 Validator 在運行的過程當中做惡,Casper 制定了一套懲罰機制以下:對於相同的 Validator,發佈了兩個不一樣的投票vote=<v , s1 , t1 , h(s1) , h(t1)> 和vote=<v , s2 , t2 , h(s2) , h(t2)> ,若是存在如下兩種狀況則罰抵押的 stake。
一、h(t1)=h(t2):對於同一個目標高度,不能發起兩個不一樣的投票。
二、h(s1)<h(s2)<h(t2)<h(t1):兩個投票的投票範圍不能存在一個包含一個。
咱們來看一下在合法的交易的狀況下,justified 和 finalized 是如何保證 checkpoint 的安全性的。當一個 checkpoint : c 成爲了 justified,說明有超過2/3的 Validator 支持 c 以前全部的 checkpoint,配合着第一個懲罰條件,在h(c)有超過2/3的 Validator 惟一支持 checkpoint c。對於 finalized 的checkpoint : f,他會有一個從f出發,鏈接到f的子節點的 supermajority link。配合第二個懲罰條件,當一個 checkpoint f 成爲了 finalized,說明全網超過2/3的Validator不能發出跨越f的投票,這2/3的 Validator 只能對f以後的checkpoint 進行投票。如圖4所示:對於任意一個 Validator,在投出了 vote1以後就沒法投 vote2,所以 f 以前的 checkpoint 將不會被改變,由於任意對於f以前 checkpoint 的投票都沒法得到超過2/3的投票。
圖片描述
圖4 finalized以前的checkpoint會被確
爲了讓 PoS 可以提升 PoW 鏈的安全性,在如何進行分叉選擇的時候,FFG 對最重鏈進行了些許的修改:首先在視圖中找到高度最高的 justified checkpoint,並在該 checkpoint 以後的區塊上進行最重鏈選擇。這樣作有兩個好處,第一個是相比於原有的 ghost 算法,區塊的確認是機率性的,等了足夠多的高度以後,只有很低的機率顛覆以前的區塊,雖然機率很低,可是仍是有這種可能性;FFG 中只要是在 finalized 以前的區塊都是被確認的,沒有被顛覆的可能性。
第二點是一個確認的區塊的安全性是須要礦工不斷將本身的工做量提供給該區塊的,所以爲了激勵礦工須要更多的挖礦獎勵;FFG中,只要是 finalized 的區塊都是被確認了的,無需後續的礦工用工做量爲已經確認的區塊增長安全性,所以能夠下降挖礦獎勵,下降通脹率。
咱們剛開始說過,先假定 Validator 是固定的,可是一個真正的區塊鏈系統確定是可以讓參與者自由進出的,所以 FFG 有一套本身的 Validator 出入原則。首先,定義區塊b的 dynasty 爲:從創始區塊到b的父區塊之間 finalized checkpoint 的數量。
抵押:
用戶想要成爲 Validator 須要抵押必定的 stake,當用戶v的抵押交易被包含在一個dynasty=d的區塊中,那麼定義一個Start Dynasty,寫做SD(v) = d+2。
贖回:
Validator v想要取回抵押的 stake,須要發起一個贖回交易,當這個交易信息被包含在一個 dynasty爲 的區塊中, 那麼定義一個End Dynasty,寫做ED(v) = +2。爲了不處理多個 SD 和 ED,一個用戶在贖回以後不能再抵押成爲 Validator。同時爲了不壞人做惡後馬上贖回 stake,在贖回交易執行後stake 仍須要鎖定必定時間。
對於一個區塊 b,假設其 dynasty 爲 d,只有 d 在 ED 和 SD 之間的 Validator 才能夠進行投票。
本篇介紹到這裏結束,若是你們以爲有疑惑的地方能夠掃描下方二維碼加入 Fractal 官方羣討論,Fractal 的技工們在線解疑,在下篇文章中,咱們將爲你們介紹一下以太坊 2.0 中將要使用的 Casper 主要的協議過程。