本文系以太坊基金會研究員Dankrad Feist和PlatON演算法科學家謝翔博士聯合撰寫，主要剖析以太坊2.0在可拓展性、資料可用性、託管策略、MPC等方面的探索實現。目前PlatON已發起一個由以太坊基金會資助的專案，實現和最佳化託管證明的MPC協議，並在GitHub上開源。
1.以太坊2.0
以太坊是當前世界上使用最為廣泛的區塊鏈系統之一。經過約五年的發展，目前已進入第四個階段——『寧靜』（Serenity），也就是廣為所知的以太坊2.0，通常簡稱為ETH 2.0。
以太坊2.0 將會成為迄今為止最具雄心的一次升級，其設計目的涉及到改善去中心化系統的各個方面。一旦升級成功，目前以太坊網路的兩大難題將會被解決，它們分別是可擴充套件性和可持續性。
1.1.可擴充套件性
當前以太坊網路的能力大約為20 TPS，這遠無法滿足成百上千個應用程式的使用需求。以太坊社羣提出了許多解決擴充套件性的方案，Eth 2.0最終決定採用分片的方式來實現Layer 1 層的擴充套件。
簡而言之，透過分片的方式可將系統分為可管理的較小部分（分片鏈），並且每一分片各自獨立並行處理。最後，每個分片的結果將透過交聯（crosslink）到信標鏈連線在一起。
舉一個簡單的例子，假設一個區塊包含三筆交易。在當前的以太坊網路中，每個節點（例如節點A、B、C）必須驗證所有交易。若算力最差的節點需3 秒來驗證該塊，則系統的吞吐量為1TPS。顯然，系統的可擴充套件性取決於單個節點的處理能力。
在分片中，交易可被分配給不同的分片鏈，每一個節點僅需驗證其中一個分片即可。交易也被分成三部分，每一部分在單獨的分片中分別進行驗證。假設每筆交易可以在1 秒內完成驗證，那麼整個系統的吞吐量將變為3TPS！此外，每個節點不需要儲存鏈中的所有資料，它們僅需負責在某些時期對於一些特定分片資料的儲存。
當然，在實際情況中，每一分片可被多個驗證人節點驗證。若對此感興趣，可進一步參考Sharding FAQ【1】。ETH 2.0 目標是打造1024 個分片（現階段開啟64 個），其吞吐量相比當前網路預期將提高1000 倍。加上layer 2 層的擴充套件機制，其效能將會進一步提高。
1.2.Proof of Stake
當前的以太坊和比特幣一樣，依賴於工作量證明（PoW）來保證系統的共識。在PoW系統中，“礦工”透過消耗電力資源來解決密碼學難題，並且會因為解決難題而獲得獎勵。安全性源於計算問題的難度，由於“挖礦”所存在的鉅額收益，因此造成一些礦池的中心化和壟斷，使得系統的安全性大大折扣。
不僅僅是中心化，挖礦/工作量證明還存在許多其它的問題。譬如，由於計算所消耗的電力資源引起的極大浪費，而消耗能源本身是用來保證系統安全性的，所以這在PoW正規化中很難解決。另外，系統只有獎勵機制，卻不會因為惡意行為而受到懲罰。因此實際上，安全性的開銷要比所需的遠高的多。
為了解決這些問題，以太坊2.0 將會切換到Proof of Stake（PoS），該協議稱為Casper。在PoS系統中，“挖礦”過程替換為一個投票系統，驗證人節點需要質押32 個以太幣才能參與系統並進行投票。為了達成共識，驗證人節點輪流對下一個區塊進行提議和投票。如Ethereum Proof of StakeFAQ【2】所述。
此區塊鏈系統維護一組驗證人節點列表，任何持有其基礎密碼貨幣（以太坊中為以太幣）的使用者，都可透過傳送特定型別的交易進行“鎖倉”來成為驗證人節點。生成並就新區塊達成一致的的過程透過共識演算法來完成，共識過程所有節點都可參與。
信標鏈將成為以太坊2.0 的核心，它儲存並維護所有驗證人節點的註冊，處理跨分片通訊以及最終一致性的確認。所有的分片始終遵循信標鏈，持有32 個ETH（固定值）的使用者可成為驗證人節點。在一個週期中的每一時段，系統從信標鏈中隨機選擇委員會指派給不同的分片。驗證人節點最終被劃分為多個不同的委員會，每個委員會至少由128 位驗證人節點組成。該委員會負責在特定的分片上生成區塊。
另一方面，驗證人節點也會因出現不良行為或不誠實行為而受到懲罰，最嚴重的的一種懲罰（Slashing），將會銷燬節點所有質押的以太幣。其他一些情節輕微的懲罰行為包括：不在規定時間正常執行，證明尚未最終確定的區塊等。對於雙籤或者對錯誤的計算進行簽名都會施以最嚴厲的處罰。
2.資料可用性問題
資料可用性問題與欺詐證明高度相關，簡要說明如下。更多詳細資訊請參見這篇【3】。
2.1.欺詐證明
在上面對區塊鏈中的節點（不考慮分片）的描述中，我們實際上指的是全節點。全節點產生鏈的區塊，下載每個節點中的所有資料，並驗證所有交易和狀態的有效性。一個全節點要求機器配置大量的記憶體，強大的計算能力以及非常高的頻寬。而像手機這樣的受限裝置很難滿足這樣的配置要求。
輕節點或者輕客戶端是全節點的一種低成本替代方案。它們至少連線到一個全節點上，並且僅下載區塊頭和想要的區塊資料。他們信任全節點來檢查資料的有效性，並假定惡意全節點無法建立一條有效的分叉鏈。
欺詐證明是針對輕節點的一種機制，它用於降低被非法鏈欺騙的安全風險。每當誠實的全節點發現某種不一致的狀態時，全節點就會生成一個欺詐證明，併為輕節點發出“警報”。此欺詐證明很小，並且可快速在網路進行分發，而且可以肯定地證明某些鏈的確存在故障。這樣，輕節點就可以完全忽略此非法的鏈，並避免其可能導致的系統狀態不一致。
例如，若全節點發現一筆交易t是錯誤的，此交易的前後狀態分別為S_in和S_out。那麼全節點構造出此筆交易對應的欺詐證明為（S_in, t, S_out）以及相應的Merkle根（Merkle root）。證明本身非常小，很容易廣播以及驗證。輕節點可透過驗證Merkle根和交易三元組確定交易的非法性。
資料可用性問題指的是，若某些惡意的全節點對區塊頭進行了簽名，但卻不釋出區塊中的某些資料，該怎麼辦？特別是如果資料裡包含了一筆非法交易（例如，一筆竊取轉賬金額，並轉移至另一賬戶的交易）該如何？在這種情況下，誠實的全節點無法生成欺詐證明，這是由於缺乏生成欺詐證明所必需要的資料。
2.2.分片中的資料可用性
資料可用性問題在分片中也尤其重要。如前所述，ETH 2.0 中的驗證人節點不會驗證所有區塊，也不會去下載所有資料。這是為了讓分片機制充分發揮效用，並減輕單個驗證人節點的負擔。分片區塊將由委員會驗證，並且只有承諾值會儲存在信標鏈中。從這個角度來看，驗證人除了需要一直持續性的參與網路獲得之外，它們實際上可看做是大多數分片上的輕節點。
分片中的資料可用性問題描述如下圖所示：
整體過程可用以下步驟說明：
1. 分片資料以Merkle 結構儲存得到Merkle根。事實上這是交聯（crosslink）資料根，為簡便起見，將其稱為Merkle 根。
2. 提議人節點生產新區塊並對Merkle根進行簽名；
3. 其他驗證人節點對此區塊進行投票並簽名。其中，BLS簽名可聚合成一個簽名；
4. 當簽名的數量超出門限時，簽名的Merkle根就會被新增到信標鏈上。
在其它分片上發揮作用的分片無法獲知完整的區塊鏈資料，並且也不會去下載，否則，這會直接消除分片所帶來的優勢。這種情況下的資料可用性問題指的是，如何能夠驗證分片1 中的資料確實可被任何想要下載或驗證此資料的全節點所獲取。
3.託管策略（Custody Game）
Eth 2.0 假定2/3的驗證人節點是誠實的，並且以這樣一種方式將驗證人節點分配給對應的分片：若滿足2/3的驗證節點誠實，則永遠不會將不可用或者不正確的區塊包含在一個交聯中。但是，這裡的“誠實”意味著什麼呢？可能有一些驗證人節點“誠實但懶惰”：鑑於在大多數情況下，沒有人試圖作弊，因此節點可能永遠都需要真正驗證任何內容，而只是對任何傳入的區塊頭進行簽名。或者，為了更加安全一些，可先等待該區塊頭積攢了一些簽名之後，然後再繼續簽名。這種方式仍然可以獲得獎勵，但卻幾乎不需要做任何工作。
如果發生這種情況，攻擊者可以依靠這些驗證人節點促進無效區塊的傳播。這對於系統的整體執行狀況將會帶來災難性的影響。因此，我們希望儘可能避免使用“誠實但懶惰”的驗證人節點，這也正是採用Custody Game的目的。
Custody Game本身不能完全解決資料可用性問題。因此，需要額外進行資料可用性檢查。但是，它可以確保至少在分片1 中對此區塊進行簽名的驗證人節點都擁有資料。
粗略來說，在Custody Game中，每一個驗證人節點必須計算出另外的一個託管位元（custody bit）。此託管位元僅可由持有“秘密”金鑰（託管金鑰，custody key）和資料的驗證人節點計算出來。在公佈託管金鑰後，任何人都可使用資料來驗證這一託管位元。若發現一個無效的託管位元，可在鏈上對此進行挑戰。如果挑戰者是正確的，那麼他們將得到獎勵，並且託管位元生成方將會被處罰。
託管證明（proof of custody）存在以下幾個關鍵點：
1. 託管金鑰是從驗證人節點金鑰中確定性地計算出來，以避免採用新的金鑰增加系統複雜性。託管金鑰會週期性地生成，並且在託管週期結束時公佈出來。任何人都可驗證託管金鑰的有效性。它也被稱為臨時金鑰（ephermeral key），因為它僅在一個託管週期階段有效（Eth 2.0 中，託管週期大約為9 天）。
2. 若沒有託管金鑰和資料，那麼生成託管位元的方式與隨機猜測並無太大區別。
3. 任何人都可以使用託管金鑰和資料來檢驗託管位元的有效性。
在Eth 2.0 中，驗證人節點的公鑰將是BLS簽名系統的公鑰。一旦質押以太幣成為驗證人節點，對應的運營者將生成一個公私鑰對。對於每一個託管週期（9 天），驗證人節點都能夠生成臨時託管金鑰ek。臨時金鑰實際上是對計數器（當前週期的計數）的BLS簽名。由於BLS的簽名過程是確定性的，因此所有的臨時金鑰都可預先由公鑰完全決定。除了驗證人節點本身之外，任何人都無法計算出臨時金鑰。
託管位元是透過某一類mix函式計算而來，儘管函式的具體形式仍在討論中，但其規範傾向於使用MPC友好的構造，詳見eth2.0-specs【4】。總的來說，託管位元的生成方式為b=mix(ek,D)，其中D為區塊資料。
目前，mix函式的構造使用了通用雜湊函式（Universal Hash Function，UHF）和勒讓德偽隨機函式（Legendre PRF）。這些函式均為帶金鑰的函式並且是確定性的。因此，給定一個金鑰ek，將其表示成兩個元素ek0, ek1。然後，驗證人節點可計算出託管位元b= Leg_PRF(ek0, UHF(ek0,ek1,D))，如下圖中的流程所示：
簡而言之，UHF用於擴充套件輸入資料空間（密碼學中的常用的技術），同時避免外包計算（只有金鑰和資料所有者才能計算UHF 函式）。採用Legendre PRF的緣由主要有兩點：其一，它在MPC的計算中非常高效；其二，其可確保託管位元具備更好的隨機性。可參考這篇文章【5】獲取更多細節，並且，我們將會在後續的文章中給出更加深入的解釋。
4.MPC友好性
Eth 2.0 的設計目標之一是使其對MPC友好。其中包含了兩個原因：其一，透過允許運營節點在多個計算機甚至不同的資料中心之間分佈其驗證人節點，從而避免單點故障，這可以帶來額外的安全性；其二，透過一個無需信任（trustless）的驗證人節點池，能夠使資金較少的人可以參與Eth 2.0 驗證。因此，託管證明也應該對MPC友好，這也是使用Legendre PRF的主要原因。由此，這或許會開啟一種全新的業務模式，併產生許多其它有趣的應用。請參見此處【6】，獲取更多細節。
PlatON發起了一個由以太坊基金會資助的專案，以實現和最佳化託管證明的MPC協議，當前程式碼已在GitHub【7】上開源。後續會公佈更多細節，請持續保持關注！
註釋
[1]https://github.com/ethereum/wiki/wiki/Sharding-FAQ
[2]https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
[3]https://dankradfeist.de/ethereum/2019/12/20/>[4]https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/custody-game.md#misc
[5]https://ethresear.ch/t/using-the-legendre-symbol-as-a-prf-for-the-proof-of-custody/5169
[6]https://slideslive.com/38920085/ethereum-20-trustless-staking-pools
[7]https://github.com/PlatONnetwork/proof_of_custody
參考文獻
（1）The Beacon Chain Ethereum 2.0 explainer you need to read first.
https://ethos.dev/beacon-chain/
（2）Ethereum 2.0: A Complete Guide.
https://medium.com/chainsafe-systems/ethereum-2-0-acomplete-guide-d46d8ac914ce
（3）Ethereum 2.0: A Complete Guide. Scaling, Part One.
https://medium.com/chainsafesystems/ethereum-2-0-a-complete-guide-3739a74be61a
（4）Ethereum 2.0: A Complete Guide. Scaling Ethereum —Part Two: Sharding.
https://medium.com/chainsafe-systems/ethereum-2-0-a-complete-guide-scaling-ethereum-parttwo-sharding-902370ac3be
（5）Proof of Stake FAQ.
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
（6）Data availability checks.
https://dankradfeist.de/ethereum/2019/12/20/>（7）A note on data availability and erasure coding.
https://github.com/ethereum/research/wiki/Anote-on->（8）1-bit aggregation-friendly custody bonds.
https://ethresear.ch/t/1-bit-aggregation-friendlycustody-bonds/2236
（9）Using the Legendre symbol as a PRF for the Proof of Custody.
https://ethresear.ch/t/using-thelegendre-symbol-as-a-prf-for-the-proof-of-custody/5169
（10）Proof of custody game design.
https://github.com/ethereum/eth2.0-specs/issues/568
（11）The proof of custody game.
https://notes.ethereum.org/@vbuterin/rkhCgQteN#The-proof-ofcustody-game
（12）Ethereum 2.0 Trustless Staking Pools.
https://slideslive.com/38920085/ethereum-20-trustlessstaking-pools
