以太坊2.0 都要來了你還不知道 Casper 嗎?

買賣虛擬貨幣

​《求真區塊鏈》是 Fractal 思想庫傾力打造的系列科普欄目,抱誠守真地輸出科普內容,旨在讓更多人的瞭解各項區塊鏈技術的內在價值與差異。

今年年初,以太坊進行了君士坦丁堡升級,伴隨著升級,以太坊何時能切換成 PoS 再次成為了大家熱切關注的一個問題。眾所周知,PoW 演算法存在大量資源浪費,算力集中等問題,以太坊從17年開始就一直想要切換到 PoS 演算法。但是由於種種客觀條件的限制,一直沒有實質性的發展。在放了廣大區塊鏈愛好者幾年鴿子後,以太坊 2.0 終於要使用 PoS 演算法了。本著獨樂樂不如眾樂樂的中國傳統美德,Fractal 的技工們決定跟大家分享一下,我們關於下一代以太坊共識協議——Casper 的看法。

本系列文章將會分為多個部分,這篇文章首先為大家解讀一下 Vitalik 關於 Casper FFG 的論文,既如何在現有以太坊的 PoW 協議上疊加一個 PoS,在減少礦工挖礦獎勵的同時提高系統的安全性。

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所示: 


圖1 區塊壓縮成checkpoint

將區塊壓縮之後我們得到了圖2,並且為每一個 checkpoint 提供了一個高度函式h(bi):區塊 bi 到根結點 r 的跳數。


圖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 都已經被確認。

Validator 投票

在將 PoW 產生的區塊壓縮成 checkpoint 之後,Validator 對於這棵樹進行投票,投票規則如下:

vote=

其中:

v :Validator的身份資訊;

s :任意一個justified的checkpoint的hash,可以理解為源checkpoint。關於justified的定義我們之後會詳細講解;

t  :任意一個 的子孫節點的hash,可以理解為目標checkpoint;

h(s) :  s的高度;

h(t) :  t的高度;

checkpoint 的兩種關係

在定義了投票規則之後,定義任意兩個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 之間關係的定義之後,定義 checkpoint——c 的兩種狀態:

- c justified

1)c = root :checkpoint c是根;

2)或 存在(c'→c),即 c' 到 c 的 supermajority link,並且c'是 justified;

-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= 和vote= ,如果存在以下兩種情況則罰抵押的 stake。

1、h(t1)=h(t2):對於同一個目標高度,不能發起兩個不同的投票。

2、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的更換

我們剛開始說過,先假定 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 主要的協議過程。​


免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;