Vitalik：HF1 提案

2021-03-01 17:03:45

HF1 為信標鏈首次硬分叉的暫時代碼名稱 (點進鏈接參與協議升級永久命名的討論)，這次升級的主要目標為：

1. 增加輕客戶端支持

2. 修復一些信標鏈上的漏洞，這些漏洞發現時間比較晚，來不及在創世前修復

3. 在需要進行較大的更新 (分片、合並) 之前，先在相對較小的更新中對硬分叉機制進行測試

HF1 提議的共識改變

同步委員會

我們在信標鏈上添加了隨機取樣的 “同步委員會”。這樣做的目的是讓輕客戶端以較低的开銷 (每天至少需要約20KB來保持，需要約500個字節來確定單個區塊) 來確定信標鏈頭。這將使得輕客戶端實際上可用於移動設備、信標鏈之類的瀏覽器內的應用案例 (以及合並後的整個以太坊)，從而為更加去信任的錢包生態打好基礎。

在每個時間段（約27小時）內，隨機選擇 1024 位驗證者作為同步委員會的成員。同步委員會中的驗證者將發布證明當前鏈頭的籤名。這些籤名將作為LightClientUpdate對象的一部分被廣播至區塊鏈，這可以幫助輕客戶端找到鏈頭；並且籤名會被打包進鏈，驗證者會分得獎勵。

主要PR：

https://github.com/ethereum/eth2.0-specs/pull/2130

核算改革 (第一層)

給驗證者的獎勵不再通過計算得出。此前，我們的方法為存儲PendingAttestation對象然後在最後對它們進行處理。而現在我們添加了一個位字段以存儲每個驗證者的狀態，從而可以實時收集參與數據。位字段按照“混洗”的方法進行排序，以確保同一個委員會的驗證者的記錄同時顯示。這一改變的目的是簡化客戶端實現，並使得更新默克爾樹的成本更低。

主要PR：

https://github.com/ethereum/eth2.0-specs/pull/2176

核算改革 (第二層)

我們每 64 個 epochs 更新一次驗證者集並進行一次懲罰核算，而不再每個 epoch都計算一次。這樣做是為了極大地降低處理“空時段過渡 (empty epoch transitions)”的復雜性——比如，在一條參與率非常低的鏈中，兩個相繼的區塊之間隔了一千個 slot，其間僅有空塊。目前為了處理這樣的鏈，客戶端們將需要每個epoch重新計算一次驗證者的余額以對驗證者執行怠工懲罰。而這項提案應用之後，客戶端僅需要每隔 64 個 epoch 核算一次。

此外，我們對怠工懲罰 (inactivity leaks) 增加了兩項變動：

1. 每個驗證者的怠工懲罰力度降低至1/4。也就是說，如果鏈上出現怠工懲罰，當一個完全離线的驗證者損失其余額的~10%的數額時，在此期間另一個90%都在线的驗證者僅損失其余額的~0.1% (而不是~1%)。這樣做是為了加大對作惡節點的懲罰力度，對那些僅僅由於網絡連接不佳而掉线的驗證者則降低懲罰力度。點進鏈接查看更多的討論

2. 區塊敲定後怠工懲罰會逐漸減少，而不會停止。即區塊被敲定後，離线節點的余額將持續減少，這樣確保了參與率顯著高於2/3，而不是剛剛超過閾值。點進鏈接查看更多的討論 (不過請注意與此處略有不同)。

主要PRs：

https://github.com/ethereum/eth2.0-specs/pull/2192

https://github.com/ethereum/eth2.0-specs/pull/2194

懲罰常數調整

很慶幸，盡管我們還沒有完全解決驗證者懲罰的問題，但在某種程度上已經擺脫了困境。我們會改變以下常數：

1. INACTIVITY_PENALTY_QUOTIENT：

從2**26(= 67,108,864) 減少至3 * 2**24(= 50,331,648)

2. PROPORTIONAL_SLASHING_MULTIPLIER：

從1提高至2

3. MIN_SLASHING_PENALTY_QUOTIENT：

從2**7 (= 128)減少至2**6(= 64)

HF1 提議的分叉選擇變更(大概)與HF1同步部署

通過 (block, slot)對來做分叉選擇

目前，如果在最近的 slot 裏沒有區塊發布，那么出於 LMD GHOST 證明的目的，該 slot 裏面的證明會被算作支持證明者所支持的最近區塊。例如，在下圖，空白 (BLANK) 區塊的證明也會算入 A 的證明裏。

Vitalik：HF1 提案

但是，這容易招致 34% 攻擊。如果有m名驗證者被分配到每個 slot，那么一個惡意攻擊者就可以控制每個 slot 的0.34 * m。攻擊是這樣進行的：攻擊者不發布 B，且不發布任何他們的證明。所有的誠實證明者對他們在slotn看到A、在slotn+1什么都沒看到的聲明進行投票，在slot n+2，誠實提議者會在區塊A上生成區塊C，而誠實的驗證者們會支持C。此時，惡意提議者發布B並對slot n+1和n+2做證明。這樣，底部分叉有0.68 * m的驗證者支持它，而頂部分叉只有0.66 * m的驗證者支持，由此底部分叉勝出。

這樣的攻擊在此論文的 3.1部分有詳細描述：

https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf

提議的修復方案是改變分叉選擇的運作方式——讓分叉選擇在 (block, slot) 對的樹上操作，而不是在區塊樹上。因此，在slotn+1的誠實投票會算作在上圖對 (BLANK, n+1)的投票，也就是會被正確算作支持頂部分叉，那么頂部分叉的支持率會變成1.32 * m，由此能夠打敗攻擊。

主要PR:

https://github.com/ethereum/eth2.0-specs/pull/2197

分叉選擇對稱攻擊修復

分叉選擇還存在“對稱攻擊” (balance attack)，攻擊是這樣形成的：有2%的驗證者在一個slot結束之前發布少量證明，讓大於49%的網絡的人認為區塊A勝出，讓大於49%的網絡的人認為區塊B勝出。如果他們對廣播計時准確，針對每組人群的信息會及時到達，且在slot的邊界時間結束前不夠時間重新廣播信息到其他組。如果網絡環境對攻擊者而言是最理想的話，這樣的攻擊他們可以無限重復。

提議的修復方案是通過賦予下一個slot的提議者暫時但重要的分叉選擇權來“打破對稱” ，他們能決定所有驗證者在分叉的哪一邊。

重要的文檔：

https://notes.ethereum.org/@vbuterin/lmd_ghost_mitigation

原文鏈接：

https://notes.ethereum.org/@vbuterin/HF1_proposal#Proposed-consensus-changes-in-HF1

來源 | notes.ethereum.org/@vbuterin

作者 | Vitalik Buterin