編者注：本文原題為 The Finality Gadget，直譯即為 “確定性小工具”，這個名字來源于一種 Casper 算法的代號 Friendly Finality Gadget（即 Casper FFG）。在一開始的時候，Casper FFG 意在成為一種可以提供最終確定性的組件，可以部署在任何 PoW 鏈上（所以叫 “Friendly”）。

這篇文章的主要內容是介紹一種讓以太坊 1.0 和 2.0 鏈雙向耦合的方案，讓信標鏈為 1.0 鏈提供最終確定性。熟悉 FFG 的讀者可以從中看出 FFG 的深深的影子。

隨著以太坊 2.0 的上線時間越來越近，你可能會對現行以太坊區塊鏈的命運感到好奇。在 “以太坊 1.x” 這個大概念下，人們已經提出了大量方案，旨在在短期內實現對現有網絡的擴容。這些努力是為了確保現行區塊鏈的持續平穩運行，從而促進當前生態系統發展的可持續性。

本文介紹了一種名為 “確定性小工具（finality gadget）” 的計劃。它利用以太坊 2.0 在 Phase 0 （階段 0）的共識來加強現有的以太坊 1.0 鏈的安全性。通過這個計劃，以太坊 2.0 從它部署的第一天起就可以給以太坊社區帶來一定的好處。我們先詳細介紹一下“確定性小工具”這個概念，然后討論它是如何運作的、會為社區帶來什么好處以及具體的部署流程是什么樣的。最后，我們會對一些突出風險和開放式問題進行思考。

介紹

“確定性小工具” 背后的想法利用了即將部署在以太坊 2.0 上的權益證明共識協議 Casper 的屬性，即 最終確定性 。以太坊 2.0 的階段 0 計劃就是部署信標鏈，即分片后的以太坊系統的核心主鏈。參與信標鏈共識的驗證者在滿足 Casper 算法的某些條件之后就能為生成的數據提供最終確定性。之所以稱之為最終確定性，是因為一旦某個區塊被確定下來，將會一直存在于合法的那條鏈上；經證明，要想更改鏈上的數據，必須燃燒 ETH 總質押量的 1/3 以上。假設系統中質押了一千萬個 ETH ，一次成功的攻擊會導致大約 330 萬個 ETH 被罰沒，在寫本文時，其成本已經超過了 6 億美元。如果你想要了解更多細節，可以看看我寫的另一篇有關最終確定性的文章，鏈接如下：https://medium.com/@ralexstokes/how-secure-is-ethereum-2-0-consensus-41523a59f270

確定性小工具旨在利用信標鏈中的這一流程來敲定（finalize）以太坊 1.0 的區塊。如果我們可以將以太坊 1.0 的區塊數據提供給 Casper 的 “確定性引擎” ，那么我們就可以利用權益證明協議來增強現行工作量證明網絡的安全性。安全性增強之后就可以實行一些改進方案，例如減少挖礦補貼（從而減少發行量），以及將最終確定的區塊數據提供給以太坊虛擬機（EVM），從而創建穩健度更強的用戶級應用。利用階段 0 的確定性小工具意味著以太坊 2.0 一旦上線，我們就能從中獲得切實的利益，盡管以太坊 2.0 各個階段的部署預計還需要更多時間才能全部完成。

利用 PoS 共識來最終確認基于 PoW 的區塊鏈的這一構想已經在生態系統中醞釀了一段時間了（ 例如，請參考 EIP-1101 https://eips.ethereum.org/EIPS/eip-1011 或者 Casper FFG 的文檔 https://arxiv.org/abs/1710.09437 ），另外 Alexey Akhunov 有一個很好的演示文檔（ 就在這個幻燈片的開頭：https://drive.google.com/file/d/16KLZKAutK79NxMh8L7B6hpNKuoOaAPZT/view ），講的是在以太坊 2.0 背景下確定性小工具的一些發展情況。

確定性小工具如何運作？

現在讓我們了解一下，在以太坊 2.0 的當前狀態下，第一版確定性小工具（finality gadget）是如何運作的。注意，盡管我們信標鏈的最終規范即將完成，但是一些細節（特別是系統所用參數）仍在討論之中，而且可能會有所變化。

構建確定性小工具需要兩個東西：（i） 一個確定性引擎和 （ii） 一個給該引擎提供以太坊 1.0 區塊數據的方案。事實證明，信標鏈在正常運行過程中是可以達成這兩個需求的。信標鏈通過 Casper 協議達成共識，因此任何鏈上數據都能通過正常的操作得到最終確認。要實現第二個需求有點困難，因為這就意味著信標鏈需要成為以太坊 1.0 的一個輕客戶端。幸運的是，以太坊 2.0 將從以太坊主網開始引導啟動，而且在這個引導過程中，以太坊 1.0 的區塊哈希最終會納入以太坊 2.0 的信標鏈上。

追蹤質押保證金的輕客戶端

要成為新的以太坊 2.0 系統的一名驗證者，你需要將自己的質押保證金和注冊數據發送到現行主網上的智能合約中，之后會在主網上生成一個日志。這是一種單向質押行為，只有將注冊證明提交到信標鏈上才能取回質押保證金。一旦這個質押事件得到處理，你就可以進入激活隊列，最終成為以太坊 2.0 網絡中一名活躍的驗證者。

為了驗證這些質押證明的有效性，信標鏈必須記錄以太坊 1.0 上處理質押事件的智能合約的當前狀態。在撰寫本文時，需要記錄的狀態有 （i） 迄今為止所有質押保證金的默克爾樹的根哈希 （ii） 迄今為止質押保證金的總量（參見當前規范中的 Eth1Data 結構 https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md ）。質押證明通常情況下是在這個默克爾樹根哈希的基礎上生成的，對質押保證金總量的記數則用來確保這個默克爾樹根哈希中的所有質押保證金都得到了處理（如果一個區塊內未注明最大質押量，那么這個區塊就是無效的）。重要的是，對確定性小工具來說，還需要包括與該合約狀態相對應的以太坊 1.0 區塊的哈希。

信標鏈上每生成一個區塊，驗證者都必須提交他們對于質押合約的狀態記錄。如果在指定時間段內被提交的記錄大多數都吻合的話，那么以太坊 2.0 協議即可視為對以太坊 1.0 的數據達成了共識，并將它記錄在信標鏈的狀態中。隨著信標鏈上的區塊最終確定下來，則每個區塊相對應的狀態也隨之確定；一旦以太坊 1.0 上的某區塊數據被包含在最終狀態里，我們就可以說相應的以太坊 1.0 區塊被最終確定了。這就是確定性小工具的基本構造。

確定性小工具的參數

在將以太坊 1.0 上的數據更新至信標鏈的過程中，時序（timing）和頻率是兩大重要參數。它們是用于保證確定性小工具質量的不可或缺的一部分。

第一個參數就是 SLOTS_PER_ETH1_VOTING_PERIOD（每段以太坊 1.0 投票周期內的時隙）數量，也就是將針對以太坊 1.0 數據更新的未決投票留存在狀態中的時隙（slot）數量（一個時隙就是一個時間段，比如 6 秒）。在這段時間內，每個驗證者需對以太坊 1.0 數據進行投票，而他們的投票都會保存在狀態中。每經過一個 SLOTS_PER_ETH1_VOTING_PERIOD 整數倍大的時間周期（即 slot），未決投票的滾動集合就清理一次。只有大多數驗證者在這段時間里達成共識的情況下，用作質押證明的以太坊 1.0 數據才能進行更新。反之則會清理未決投票，并重新進行投票，不會改變現有的 1.0 數據。

第二個重要的參數為 ETH1_FOLLOW_DISTANCE（跟隨以太坊 1.0 鏈的距離）。這個數字限定了驗證者可用于更新信標鏈狀態的 1.0 區塊范圍：只有與 1.0 鏈末端距離大于該值的區塊才能成為驗證者的候選區塊。驗證者需要監聽新的以太坊 1.0 鏈的候選數據，并選出其中得票數最多的候選數據。如果沒有這樣的候選數據（比如我們剛剛才經歷過一個取得一致意見的 slot），那么驗證者就應該跳回 1.0 鏈末端并找到與之相距 ETH1_FOLLOW_DISTANCE 的那個區塊。例如，如果這個距離為 1024 ，且這條鏈的末端為區塊 # 8，000，000，那我們就應該找到質押合約在區塊 # 7，998，976 的狀態，并將這個狀態以及這個區塊的哈希都整合進我們的信標鏈區塊中。

該參數不包含在信標鏈的共識中，卻是誠實的驗證者所要遵循的守則。這個常數有助于驗證者圍繞不斷生長的以太坊 1.0 區塊形成協調（不斷更新質押機制），同時存在的一個副作用是，會（在某一給定時間點）對以太坊 1.0 鏈可以最終確認的區塊設定一個最大高度。

這么做不是會跳過很多區塊嗎？

要注意的是，鑒于以太坊 1.0 區塊鏈的本質，只要我們能夠最終確認位于高度 N 處的區塊，就可以認為從創始塊到位于高度 N 的區塊之間的所有區塊都得到了最終確認。這就意味著，以太坊 1.0 鏈上得到最終確認的區塊集會根據前兩個參數確定的周期性循環以及信標鏈上的最終確認時間突然跳過一定數量的區塊。根據信標鏈目前設定的常數來看，這個時間段最好控制在 2 小時左右。根據下文的解釋可知，在不利條件下，這一進展可能會放緩甚至停止。

周而復始

正如之前說的，現行的以太坊 1.0 鏈不需要了解新系統的任何信息。為了完全實現確定性小工具的所有功能，我們還得更進一步。最后這一步是修改以太坊 1.0 的分叉選擇規則，使其滿足最終確定性。具體地說，以太坊 1.0 仍然會使用 GHOST 協議來找到合法鏈，但是它會從最新確認的區塊（由信標鏈驗證者確認），而非像如今一樣從創世塊開始搜索。使確定性小工具可用的這一步更新，是對以太坊 1.0 影響最大的，因為以太坊 1.0 的客戶端現在必須接收 2.0 的共識。但是，修改分叉選擇規則可以將最終確定性帶來的安全性延伸到 PoW 鏈上，從而實現這種額外的安全性帶來的所有優點。

通過防回滾機制來改進確定性小工具

如果確定性小工具能按上述細則成功部署，客戶端就可以借由它來大幅提高質量。這種質量上的提升是因為盡可能縮小了 2.0 鏈與 1.0 鏈的更新距離。最終確定性越接近以太坊 1.0 鏈的末端，帶來的安全性就會越強，給用戶提供的具有最終確定性的數據質量就越高。

考慮到區塊廣播總會有一定延遲，理想情況是使 “跟隨距離” 只有幾個區塊。以太坊 2.0 一開始的跟隨距離要大得多（目前是 1024 個區塊），一部分原因是確定性小工具還不存在（已經在引入！）。另一個原因是質押機制。質押需要按照順序依次處理，一旦被鏈知道了，就要提交至下一個可用的區塊內。如果 PoW 鏈的重組發生在被信標鏈認為合法的區塊上，那么以太坊 1.0 鏈該區塊之后的質押將會視為無效（也就使 2.0 的驗證者集無效），并且可能（會打破確保質押按序處理的機制，進而）破壞未來質押行為，甚至可能使 2.0 鏈停止運行（因為沒有驗證者可以提交有效的區塊）。如果跟隨距離較大（以目前的 1024 個區塊來說），則不太可能出現這種情況，因為 1.0 鏈上達到最終確認性的區塊之上還有 1024 個由 PoW 確定了的區塊。如果 2.0 的客戶端可以信賴 1.0 的客戶端來保障最終確認性（避免超過某個深度的鏈重組），就可以縮短跟隨距離。從抽象角度來看，我們可以想象，隨著 “跟隨距離” 的縮短，候選區塊的 “最大高度” 可以按照 “可進不可退（ratchet）” 的方式不斷逼近 1.0 鏈的末端，直到達到一個最小的安全距離。跟隨距離能縮短到多少也是未來需要研究/討論的主題。

為何我們想要 FG？

減少發行量

將 1.0 鏈最終確定下來有很多優點。其中一個較大的優點是，假設確定性小工具能夠良好運行的話，是可以減少挖礦補貼的。通過將信標鏈的安全性與 PoW 鏈共享，PoW 鏈可以在降低對于礦工算力的依賴性的同時達到同等程度的安全性。由于我們不需要這么多哈希算力來保證鏈的安全性，完全可以降低挖礦補貼（這會降低對礦工的激勵，并減少挖礦活動的總量）。最直接的一個副作用就是會降低 ETH 的發行率和相應的總供應量，這一目標似乎得到了社區的廣泛支持。在主網上成功部署確定性小工具，并修改分叉選擇規則后，可以通過另一個分叉逐步降低出塊獎勵來實現這個好處，就像在 EIP-1011 中描述的一樣：http://eips.ethereum.org/EIPS/eip-1011#block-reward。

雖然確切的計劃還有待商榷，但是通過確定性小工具減少發行量是將以太坊 1.0 鏈遷移到 2.0 系統的第一步。我們會平穩地轉移，這個過程將從逐漸減少發行量開始。作為社區的一員，我們目前可以從支持這個舉措開始，推進后續的遷移工作。

應用程序的最終確定性

一旦 1.0 的客戶端接收到了最終確定下來的數據，這些數據就可以通過以太坊虛擬機暴露給智能合約和相關的應用程序。最終確定性是一個非常有用的屬性，因為現階段所能達到的最高水平的確定性需要等待 “足夠多” 的 “確認” 數，并且 PoW 鏈只是 “不太可能”（但還是有可能）發生重組。想象一下，有這樣一個交易所，用戶進行提款操作后需要等待很多次確定才能收到取款。如果這個交易所只需等到最終確定，就可以大幅縮短提款時間，給用戶更好的體驗。

智能合約也可以利用最終確定性。預測市場就是一個例子，在確認一個事件的結果之前，等待某個高度實現最終確定性是有用的。實現這類好處似乎也要通過一個分叉（可能跟減少發行量的分叉同時進行）來部署，也就是增加一組操作碼，以便以太坊虛擬機確定某個區塊哈希或某個高度的區塊是否已經得到最終確認。一個與此類似（添加新的操作碼）的 EIP 案例是 EIP-145 （按位移動指令）（https://eips.ethereum.org/EIPS/eip-145）。

以太坊 2.0 的運作

確定性小工具意味著以太坊 2.0 的階段 0 一啟動時就能帶來一定的好處。以太坊 2.0 目前正在分階段進行部署：階段 0 、階段 1 和階段 2 。每個階段都為分片系統引入新的復雜性，而 2.0 團隊目前正致力于在 2019 年底上線階段 0 ，其余階段預計需要更多的時間。由于類似于以太坊 1.0 中的用戶層賬戶系統也要等到階段 2 才可能實現，有必要讓大家理解到，以太坊 2.0 的每個階段都可以為我們帶來一些好處。

隨著階段 0 的上線，我們可以將確定性小工具引入 1.0 鏈，獲得本文提到的所有好處。在階段 1 ，以太坊 2.0 就可以實現能夠保存任意數據的分片鏈。確定性小工具的實現意味著以太坊 1.0 的客戶端成了以太坊 2.0 的輕客戶端。借助輕客戶端的功能，可以通過以太坊 1.0 的智能合約為分片鏈中的數據生成證明。這個功能為 layer 2 擴容技術解鎖了許多有趣的用例，比如高性能的 Plasma 鏈和能夠提供隱私性的 zk-SNARKs 應用程序。我向你推薦 Vitalik 最近一篇關于 “作為數據層的可擴展區塊鏈” 的演講，詳情：https://www.youtube.com/watch？v=mOm47gBMfg8。

如何部署？

確定性小工具的部署涉及到許多正在開發的部件，可能需要多次升級才能增強其效果；簡而言之，這是一個復雜的方案，需要投入大量工作 ：）

第一步就是以概念證明原型和模擬的形式提煉出確定性小工具的思路，以便更好地理解通過這種方式實現兩個系統耦合所產生的影響。比較理想的情況是在一個比較流行的主網客戶端上部署確定性小工具。通過這種方式，我們可以收集到確定性小工具在運行過程中的實時數據，讓我們知道確定性小工具會追隨現有客戶端達成的共識。

與確定性小工具同步進行的還有開發和上線信標鏈；我們在部署確定性小工具之前先要通過信標鏈來對區塊進行最終確定，這點無需多做解釋。

一旦我們明白了我們需要部署什么，我們就可以撰寫一個 EIP 來闡明部署流程，并一步一步將其納入接下來的分叉計劃中。我認為比較明智的選擇是先部署確定性小工具，然后再討論減少挖礦補貼或者引入新的 EVM 操作碼的問題。這個提議秉承著 “一次只做一項更改” 的思想，并且表明了在每個階段確定性小工具的哪些部分會產生哪些影響。我們不希望在減少區塊獎勵之后發現確定性小工具沒有如預想般有效，這樣會導致主網安全性的降低。

確定性小工具的風險

從廣義上來說，確定性小工具代表了 1.0 鏈和 2.0 信標鏈的雙向耦合。兩個系統的耦合度越高，受攻擊面就越廣，從而引起更大的擔憂。在針對確定性小工具提出一些具體的設計建議之前，我們會對耦合進行全方位的分析。

確定性小工具的主要功能就是將新的 1.0 鏈數據導入到信標鏈中。信標鏈上的驗證者必須是以太坊 1.0 的輕客戶端；若某個 1.0 區塊哈希不在特定 1.0 鏈驗證者視圖中，那么由該哈希形成的信標鏈區塊共識會被視為無效。這一有效性條件確保了只要大多數 2.0 驗證者是誠實的，1.0 鏈上就不會有任何無效的數據得到最終確定。如果超過 2/3 的驗證者是惡意的，他們就有可能會串通起來確定一個可能并沒有遵循底層 PoW 共識的 1.0 區塊。通過設置一個較大的初始驗證者集并采取保守的確定性小工具部署方案，我們就可以降低對這種情況的擔憂。如果信標鏈啟動，且我們知曉驗證者集中作惡者占大多數的話，那我們還有機會重新考慮我們的方案。以太坊 2.0 和確定性小工具的設計方案需要確保即使這種情況發生，也不會對以太坊 1.0 區塊鏈帶來任何改變或影響。

另一個擔憂是，鑒于驗證者要在一個投票周期內協同提議下一個區塊，這雖然不會影響確定性小工具的正確性，但會影響其性能。當前規范建議驗證者選擇先前區塊發起人提議的多數區塊，同時要保證該區塊是在自己的視圖中。實際上，這就意味著誠實的驗證者只需要在每輪投票中選擇第一個被提議的有效區塊，并且最終達成共識。下一個得到最終確定的區塊將從所有被提議的區塊中選出。因此，如果不能（在劃分好的 SLOTS_PER_ETH1_VOTING_PERIOD 時間段中）選出下一個區塊，即表明確定性小工具沒辦法將 1.0 的區塊盡快確定下來。通過進一步研究更好的投票策略來促進對 1.0 鏈的最終確定，我們就可以減少這樣的擔憂。

最后一類風險是在跟隨距離非常短，且 1.0 鏈在受到攻擊時，在可能產生很多短分叉情況下的 1.0 鏈的分叉選擇。這是最終確定性的質量（由得到最終確定的頭和鏈的 GHOST 頭部之間的距離決定）和 PoW 鏈上不穩定分叉選擇所產生的風險之間存在權衡關系。在今后的研究中，我們會通過模擬的方式更好地理解二者之間的權衡關系，并給出確定性小工具的最終提議。

這類攻擊會造成 1.0 鏈的最終確定機制延緩甚至癱瘓，導致確定性小工具的性能降級，在我們依賴最終確定性來保障 1.0 鏈的安全性的情況下，就會產生很大的風險。

未解決的問題

· 假設確定性小工具投入運行，我們如何調整挖礦補貼（亦或完全不調整）？應該通過硬分叉來削減挖礦補貼嗎？發行量是否應該是跟隨距離的一個函數？我們是否可以將最終確定性所帶來的經濟安全性（用 ETH 來計價）當前主網算力所實現的安全性上作同質比較？

· 跟隨距離可以減少到什么程度？又該如何調整？是隨著時間的推移慢慢縮短，還是在部署完確定性小工具后就縮短至最小值？

· 在信標鏈上進行的以太坊 1.0 數據塊投票過程是否足以支持確定性小工具的高性能運作？

結論

希望你能更好地理解什么是確定性小工具，為什么我們需要它以及我們應該如何規劃后續進展。我們還有一些問題尚需解決，我們也很期待你能夠提供任何有用的幫助。

如果你想要為我們提供幫助的話， Alexey 和我正在組建一個工作群，致力于實現確定性小工具。你可以點擊這里進行參與：以太坊 1.x 確定性小工具工作小組

我要感謝 Danny Ryan 與我進行了很多有用的討論，以便更好地理解信標鏈以及如何通過它來為以太坊 1.0 帶來最終確定性，還要感謝 Alexey Akhunov 在工作組中的貢獻。感謝 Terence Tsao 對本文的反饋。