ETH2.0 都要來了你還不知道 Casper 嗎？(二)

​在上篇文章中，咱們介紹了Vitalik原始論文中的Casper FFG，其藉助PoS對PoW產生的區塊進行確認來提升系統的安全性，但這只是一種過渡的方案，在以太坊2.0中會使用一個純PoS的Casper協議，這篇文章中將爲你們介紹在以太坊2.0中將要使用的Casper協議。

如何成爲Validator

---

首先咱們看看以太坊2.0的架構是什麼樣子，如圖1所示，在以太坊2.0中會有一條稱之爲Beacon chain的主鏈，其經過PoS的Casper產生。在beacon chain下，存在1024個分片，每一個分片能夠獨立地處理數據。

圖1 以太坊2.0架構

從圖1能夠看出，以太坊2.0和以太坊1.0將會是兩條鏈，在2.0分片實現以後，1.0將做爲以太坊2.0的一個分片繼續運行。在上一篇文章中，咱們介紹過能夠經過抵押stake成爲Validator參與到PoS共識中，爲了使以太坊平穩得過分到2.0，如何經過抵押以太坊1.0中的stake成爲以太坊2.0中的Validator是Casper須要解決的一個重要問題。

在以太坊2.0中，原有的用戶能夠經過抵押以太坊1.0中的ETH成爲Validator，參與到2.0的PoS中，而且能夠經過贖回操做，在2.0的以太坊中取回代幣。這裏須要注意的是，以太坊1.0和2.0中的代幣並不相同，用戶抵押的是1.0中的ETH（燒燬ETH），贖回的是2.0中的代幣（鑄造新的token）。

用戶想要成爲Validator，首先要向以太坊1.0中的一個特殊合約發送一筆交易抵押必定數量的ETH（目前最小值爲32ETH），而後用戶會獲得關於這筆交易的一個證實。用戶經過向以太坊2.0展現這個證實，在驗證經過後成爲Validator，如圖2所示：

圖2 抵押以太坊1.0中的ETH成爲以太坊2.0中的Validator過程

爲了驗證用戶抵押交易的正確性，以太坊2.0中須要保存當前以太坊1.0中的區塊信息、抵押合約中當前全部交易構成的Merkle的根哈希<root>，用戶向以太坊2.0展現其抵押交易，以及該抵押交易到<root>完整的Merkle樹的證實，就能夠驗證這幣交易的合法性。經過驗證的用戶成爲以太坊2.0中的Validator。

以太坊2.0中Capser的出塊過程

---

在上一篇文章中，咱們介紹的Casper是經過PoW進行出塊，使用PoS對區塊進行最終的肯定。所以，純PoS的Casper一個須要解決的問題是如何產生區塊。在正式介紹協議過程前，咱們先明確幾個定義：

Validators 集合： V = V1 … Vn，假設每一個Validator擁有相同的stake；
slot：基本的時間單位，目前設定爲6s；
epoch：64個slot組成一個epoch；
隨機數生成器：根據須要產生一個隨機數；

在明確了上述的定義以後咱們來進一步描述以太坊2.0中的Capser出塊過程，如圖3所示。

圖3 以太坊2.0中Casper共識過程

一、每個epoch開始，經過隨機數生成器產生隨機數，將Validator集合V平均分爲64份，獲得S一、S2，…，S64。
二、在一個epoch中，每個slot i根據步驟1中產生的隨機數，選取Si中的一個Validator提交一個候選區塊，在slot i中提交候選區塊的Validator寫做proposer_i，提交的候選區塊寫做B_i。
三、對於每個slot i，Si中除 proposer_i 外的剩餘Validator對 B_i 進行投票，該投票寫做attestation。
四、在每個slot i中， proposer_i 負責將上一個slot中的attestation信息打包到當前slot的候選區塊中。即

五、對於每個slot i，Si中除 proposer_i 外的剩餘Validator在收到了slot i的block（B_i）或等待了3s後，其公佈一個在他看來的當前鏈的頭部。

LMD GHOST（Lastest Message Driven GHOST）

---

至此，咱們介紹了Casper如何進行出塊以及Validator對於候選區塊的投票過程。須要注意的是，上文中說起到Validator須要對在它看來爲鏈的頭部進行投票，以太坊2.0使用了一種新的最優鏈選擇算法來選擇鏈的頭部。

在介紹這種新的最優鏈選擇算法以前，讓咱們回憶一下以太坊1.0的最優鏈選擇算法——GHOST。GHOST算法的主要思想是，對於一條區塊鏈由於時間延遲和惡意節點的存在會產生許多的分叉，當發現分叉時，選擇子樹的總Difficulty最大做爲最優鏈，如圖4所示：

圖4 GHOST協議

鏈在紅色的點產生分叉，假設每一個區塊的Difficulty相同爲1，藍色子樹的總Difficulty爲8，紫色子樹的總Difficulty爲4，所以選擇藍色做爲最優鏈上的點。

GHOST協議在在PoW協議中是沒有問題，可是PoS協議自然受到 Lang Range 攻擊的影響，即攻擊者能夠經過少許資金購買曾經擁有大量stake可是目前爲空的帳戶，回到過去，在過去的位置進行分叉產生大量的非法的區塊，GHOST協議將沒法保證系統的安全性。如圖5所示：

圖5：Lang Range 攻擊

攻擊者經過在過去位置產生黃色的區塊，子樹B的總Difficulty爲10，紫色區塊將成爲最優鏈上的點。雖然在投票前須要抵押token，可是在贖回本身的token後，攻擊者就能夠在其仍是Validator的epoch中肆意妄爲，不擔憂token會被罰沒。

所以，爲了解決這個問題，以太坊2.0設計了一個新的算法——LMD GHOST（Lastest Message Driven GHOST）。LMD GHOST的主要思想是，對一條存在分叉的鏈，在找尋鏈的頭部過程當中，當其遇到分叉點時，選擇當前epoch中Validator支持多的那棵子樹。協議的主要過程爲：

對於一條存在分叉的鏈：

​一、H等於創世區塊；
​二、M=[M1,…,Mn] 是Validator的最新消息；
​三、選擇M中支持率最多的孩子節點，將其設置爲H；
​四、重複步驟（2-3）直到沒有孩子節點；

雖然LMD GHOST的使用是爲了解決Long Range攻擊，可是筆者認爲， 購買曾經的帳戶至關於時光倒流，造成了一個新的平行宇宙，當一個新用戶進入時，面對兩條分叉鏈在不借助額外信息（checkpoint）的狀況下很難判斷哪一個是攻擊者構造的鏈，所以LMD GHOST沒法完全抵禦Long Range攻擊。

至此咱們已經介紹鏈以太坊2.0中的Casper如何進行出塊，接下來將是最後一個部分，如何對候選區塊進行最終的確認。

區塊確認

---

在上一篇文章中，咱們解釋了justified和finalized的checkpoint，finalized的checkpoint以前的節點被最終確認。歸納的說，以太坊2.0中的Casper將每一個epoch當成一個checkpoint，attestation對checkpoint進行投票，進而肯定checkpoint的justified和finalized狀態，肯定justified和finalized的核心邏輯和上文中描述的相似。接下來，來講明一下block如何進入到justified和finalized狀態。

如何 justify block

如今Casper將一個epoch分紅64個slot，最後一個slot稱之爲epoch_boundary_slot，用它的hash寫做epoch_boundary_hash表明一個epoch，將一個epoch看做一個checkpoint。讓鏈維護一個map，咱們叫他justified_hashes，存儲的格式是<slot, hash>。爲Validator 的 attestation增長兩個字段 epoch_boundary_hash（上一個epoch中slot最小的block的hash） 和 latest_justified_hash（epoch_boundary_hash引用區塊中的justified_hash epoch最新的block的hash），只有當attestation中的latest_justified_hash 等於justified_hashes中的slot最新的hash，這個attestation才合法。

鏈會跟蹤最新的justified hash，所以選擇相同epoch_boundary_hash會投票給相同的latest_justified_hash。如今咱們來看看在一個 epoch boundary 中，狀態是如何轉變的。假設對於一條鏈，最近的4個 epoch的epoch_boundary_block B1, B2, B3, B4 其中B4是epoch最新的epoch_boundary_block，他們的 slot 寫做 B1_slot, B2_slot, B3_slot, B4_slot, B3_slot = B4_slot - 64, etc。若是有超過2/3的Validator選擇B4做爲epoch_boundary_block，那麼把<B4_slot, hash(B4)> 加入justified_hashes。

一個epoch_boundary_block成爲justified的條件是超過2/3的Validator在其attestation中epoch_boundary_hash指向該block，當一個block被含在justified_hashes中表示，該block是justified，而且證實該block已是justified的狀態被記錄到了鏈上。

如何finalize block

在確認了justified的狀態後，下一步須要肯定如何讓block進入finalize狀態。

若是B4和B3在justified_hashes中，投票給B4做爲epoch_boundary_block的attestation選擇B3做爲latest_justified_hash，finalize B3。
若是B四、B三、B2在justified_hashes中，投票給B4做爲epoch_boundary_block的attestation選擇B2做爲latest_justified_hash，finalize B2。
若是B三、B二、B1在justified_hashes中，投票給B3做爲epoch_boundary_block的attestation選擇B1做爲latest_justified_hash，finalize B1。
能夠類比上一篇文章，Validator的投票爲<v, s, t, h(s), h(t)>，能夠將epoch_boundary_block當作h(t)，latest_justified_hash當作h(s)，這樣能更方便的理解block的確認過程。

其餘的一些小事

---

爲了Casper完整的運行，還有一些小事須要解決，因爲篇幅比較短小咱們放在一塊兒來講吧。

懲罰條件

爲了抵禦noting at stake攻擊，用戶經過抵押token成爲Validator進行PoS，當Validator非法操做時，沒收其抵押的token，來防止壞人做惡。Validator的懲罰條件爲：

一、同一個Validator不能在相同的epoch中發出兩個不一樣的attestation。
二、同一個Validator不能發出兩個attestation，他們的 epoch_boundary_block 分別爲t1和t2，latest_justified_hash 爲s1和s2，且 s1<s2<t2<t1。

這個懲罰條件和上一篇文章中的懲罰條件是相同的。

Validator更換條件

dynasty(B)表示從block B開始到創世區塊之間，finalized epoch的個數。兩個dynasty之間能夠更換1/64的Validator。

分叉選擇條件

從最新的finalized block開始，進行LMD GHOST。

《求真區塊鏈》本系列關於Casper的文章到此爲止就結束了，若是你們以爲有疑惑的地方能夠掃描下方二維碼加入社區討論，Fractal 的技工們在線解疑。