硬核：在以太坊「最後一夜」，必讀 ETH2.0 最全工程手冊

近日，「以太坊君士坦丁堡分叉」成爲區塊鏈領域熱門話題，而作爲以太坊的計劃替代方案，真正的「硬菜」——ETH 2.0 也將逐漸揭開面目。拋開對於枯燥術語定義的解讀， James Prestwich 討論當前的以太坊路線圖。同時，他腦洞大開，在這些具體討論中設想關於以太坊後期階段可能方向。

原文標題：《以太坊進化的「最後夜晚」：程序員的 ETH2.0 指南》
作者：James Prestwich
編譯：袁輝騰

ETH2.0 是什麼？

ETH2.0 是以太坊的計劃替代方案。在接下來的幾年裏，ETH2.0 的開發者們打算將現在以太坊的共識系統以及狀態完全納入其中。由於其範圍如此廣泛，我們也無法準確地傳達出 ETH2.0 將會包含或不包含的具體內容。確實，我們已建構部分切實可行的操作規範，同時也有相當多的團隊力量致力於開發早期的實現。ETH2.0 開發者暫時計劃包括分片技術（Sharding）、Casper 協議、狀態租賃（State Rent）、以太坊虛擬機 EVM 的升級項目 eWASM。

如今，ETH2.0 初始客戶端已經上線測試，並預計在三個月內（2019 年第一季度）推出輕量級 ETH2.0 測試網絡。首先，ETH2.0 會讓以太坊鏈中的以太幣映射過去，但 ETH2.0 設計者最終計劃通過將 ETH2.0 成爲主鏈，而 Ethereum 1.X 則是其管理下的分支鏈來改變這種局面。

對工程師意味着什麼？

如果你是專業的 Solidity 程序員或 Dapp 開發人員，並且是部署 ETH2.0 智能合約「鐵桿粉絲」。那麼，你可能需要進行大量的更新迭代。ETH2.0 是以太坊的完全替代品，其將推翻我們在編寫智能合約時所做的諸多假設。其計劃的多年階段性推出並不像是升級週期，更像是一個產品發佈週期。我們爲 ETH1.X 編寫的工具和智能合約或需要推倒重來。幸運的是，我們有幾年的時間來建構這個生態系統。

爲了推動這項工作，我打算討論下當前的路線圖，並介紹一些工程上的影響。

分階段推出

目前，分片路線圖（ETH2.0 路線圖的兩倍）列出了七個階段。只有階段 0 有明確的規範，並定期更新。階段 1 規範的嚴格性、準確性要低很多，且可能處於消極的開發狀態。從階段 1 後，路線圖轉變爲目標列表，而不再是技術文檔。

舉個例子，在階段 2 中，路線圖鏈接到 ethresear.ch 的次數是鏈接到 Github 的三倍。由於未來的任何一步都更像是推測，而不是工程，因此我們的具體討論僅限於階段 0、1、2。同時，在這些具體討論中也涉及幾個關於後期階段可能方向的粗略輪廓概述。

階段 0: 信標鏈（ The Beacon Chain）

階段 0 引入了「信標鏈」，（Odaily 星球日報注：信標鏈是一條全新的區塊鏈，並且在新的以太坊中佔據核心位置。這條鏈承擔的其中一個職能是讓驗證者可以參與質押系統、替代礦工的角色而成爲鏈的構建者。另一個職能是存儲分片狀態的索引）。ETH2.0 設計者希望信標鏈能夠成爲 ETH2.0 生態系統的核心，成爲其他分片的安全和驗證的根源。信標鏈部署完畢後，將使用 PoW/PoS 混合機制的 Casper the Friendly Finality Gadget （Casper FFG）進行股權證明。

顯然，像「信標鏈」的這種早期迭代在設計之初就儘可能簡單，這也是階段 0 並不支持智能合約、賬戶、資產轉移，也不包括任何分片的原因。同時，基於信標鏈上的以太幣也無法實現鏈上轉移，這意味着用戶不能將其存入交易所。

BETH：新的以太幣

作爲一種新資產類型，Beacon ETH （BETH）僅由信標鏈上的 Stakers （持幣者或用戶）使用。BETH 能夠以下兩種方式創建。

作爲驗證信標鏈的獎勵（以及階段 1 之後的分片）；

任何 ETH1.X 用戶可以通過 ETH1.X 合約購買 1 個 ETH 的 BETH，合約將其稱爲「存款 / 充值」（Deposit）。

工程師可能會注意到，合約內並未提到撤銷功能。這是由於階段 0，用戶無法從信標鏈中撤回 BETH。也就是說，用戶一旦在存儲在 ETH1.X 驗證者註冊合約中，ETH1.X 以太幣則被銷燬。信標鏈驗證者會觀察該合約，並向信標鏈提交充值信息，信標鏈將向充值用戶發行新的 BETH。

因此，在 ETH 發送給驗證註冊合約不久，用戶便會收到信標鏈發佈的對應數量的 BETH。這一過程中，可以對充值進行臨時審查，但根據 Casper 協議規定，不能對其進行永久性審查。

一直到階段 2，以太幣才能夠在信標鏈上進行傳輸。在我看來，在 ETH1.X 沒有完全融入分片生態系統之前，沒有任何辦法可以將 BETH 移回 ETH1.X。鑑於階段 0 並不完整，且不存在可靠明確的階段 1 規範，因此可以合理的假設：BETH 作爲獨立切不可轉讓的資產類型至少還需兩年。當階段 2 完成，BETH 實現分片轉移自然「水到渠成」，但 ETH 卻不會，而這並不會造成不可逆的經濟困難。

過去，一些類似 BETH 這種低功能的 Token 項目已通過 IOU （欠條）在交易所進行交易。例如，在 Tezos 衆籌期間，其就曾推出 HitBit 和 BitMEX XTZ 期貨市場。因此，若是對 BETH 存在需求，我們應該致力於構建一個支持受託管 BETH 的交易和入股（Staking）的交易所生態系統。然而，用戶當下對於 BETH 的需求或許存在懷疑。由於從 ETH 到 BETH 的單向掛鉤導致 BETH 價格上限爲 1 ETH，BETH 並不是一個絕佳的投資標的。換言之，BETH 永遠不會比 ETH 更值錢，甚至有可能價值更低。

0 階段+：入股（staking）

在信標鏈上，用戶可以投注 32 個 BETH 保證金成爲驗證者。在階段 0 中，驗證者只需管理信標鏈即可；而從階段 1 伊始，驗證者在管理信標鏈的同時，還將管理 1024 條分片鏈。信標鏈以及每一條分片鏈將使用 Casper FFG 來完成出塊。FFG 是一種權益證明算法（Proof of Stake），用於對鏈上不良行爲實施罰沒（即削減權益）。

細心的讀者會發現 FFG 在分片路線圖的「以太坊 3.0」部分的表兄弟 Casper CBC。雖然對 FFG （當然還有 CBC）的細緻解讀已超出本文的討論範圍。若是感興趣，可以閱讀以太坊創始人 V 神（Vitalik Buterin）關於混合 PoW / FFG 的說明，以及其關於最小化削減條件和 FFG 論文。

用戶（stakers）需做些什麼？

分片目的在於節點之間分割（Split）分片的狀態信息，而無需要求任何節點都同時具備網絡的全部圖景。基於此，驗證者不會驗證所有分片。相反，信標鏈將協調其他分片的驗證，所有驗證者將進行信標鏈的驗證。

經過一個固定時期（64 個塊或約 6.4 分鐘），信標鏈將對驗證者進行「洗牌」，並將其隨機分配給分片。分配給分片的一組驗證者被稱爲委員會（Committee），其中包括 128 名委員。在階段 0 中，委員會機制意味着信標鏈大約每隔 6 分鐘就需要選擇可用的驗證者，隨後在接下來的 6 分鐘內組成一個完整的委員會；在階段 1 中，信標鏈將 1024 個分片指定一個驗證者委員會。指定的過程是極其複雜的，涉及多階段隨機數生成過程以及可驗證的延遲函數，從而能夠阻止試圖操縱委員會遴選的過程。

委員會將負責保護其分片的安全性、活躍度以及完整性，同時還需證實（Attest）信標鏈上的分片狀態，其存在的重要性不言而喻，ETH2.0 因此會隨機進行委員會的選擇，並經常輪換委員會成員。同時，這也是信標鏈能夠知悉分片狀態的唯一方式，反之亦然。

從所有的驗證池中隨機選擇驗證者，可以做大限度地減少委員會作爲一個整體撒謊或欺騙的可能性。委員會的輪換也能夠降低糟糕的委員會可能造成的傷害。換句話說，對於目的不純或者試圖利益最大化的驗證者很難將委員會作爲攻擊網絡任何部分的工具。退一步講，假如驗證者獲得對分片委員會的控制權，其能夠控制的區塊也不會超過 64 個。

PoS 證明的影響有哪些？

雖然，ETH1.X 的工作量證明（Proof of Work）與 ETH2.0 權益證明（Proof-of-Stake）之間的哲學差異記錄是一個持續過程，但值得注意的是，一些 PoW/PoS 特性的差異確實會直接影響到工程師。例如，PoW 鏈支持無狀態簡化支付驗證（SPV）和工作量證明的非交互式證明（NIPoPoW）遠程狀態跟蹤，但 PoS 則禁止任何低狀態通信。主觀性阻礙輕狀態（State-light）查看證明（Attestations）。

換句話說，關於權益證明的遠程狀態證明將包含 PoW 無狀態 SPV 驗證大致相同的數據量，但需要對整個 PoS 歷史進行預先驗證。相比之下，無狀態 SPV 驗證不需要其他信息進行驗證。這意味着在主觀權益證明環境中，跨分片或跨鏈應用程序功能減少，但開銷增加。

階段 1：分片

階段 1 旨在就分片鏈的內容達成共識，並非對其意義達成共識。換言之，這是一次對分片結構的「試運行」，而不是嘗試使用分片進行擴容（Scale）。信標鏈將分片鏈視爲沒有結構或意義簡單的位（Bit）集合。分片鏈尚未擁有賬戶、資產或智能合約。分片驗證者是由信標鏈爲每個時間段（Epoch）的分片進行隨機選擇產生的。其僅僅對每個塊的內容達成一致。在分片中出現什麼信息並不重要，只要所有委員會成員達成共識，並定期更新分片上的信標鏈即可。

通過一個稱爲交聯（Crosslinking）的過程，分片驗證者可以驗證分片的內容及狀態。簡單來說，委員會必須在信標鏈中包含關於分片（例如根哈希）的可驗證信息。在階段 2 甚至更高階段，交聯將支持跨分片通信（Cross-Shard Communication）。信標鏈從多個委員會收到給定交聯的準確性證據後，信標鏈就可以相信交聯是分片的真實表示，而無需驗證整個分片。如果委員會對交聯的有效性存在分歧，即很明顯其中一個委員會是錯誤的，驗證者應該予以罰沒。

這是所有分片的安全根源，即其驗證者的不當行爲最終會被信標鏈發現並受到懲罰。

階段 1 並不存在任何特別有趣的內容。從根本上說，這只是用於交聯的引導階段，也可以說是分片引用信標鏈的對稱機制。設計者們似乎對這些工作機制充滿信心，這些機制開放問題主要圍繞規範和策略實施。鑑於階段 0 花費一年多的時間才達到合理的規範水平，階段 1 估計亦是如此。

有趣的是，階段 0 的實現與規範的制定同時推進。即使當下——距離測試網絡還不到三個月的時間，階段 0 規範也會定期修改。對於時間線的預估也意味着未來 ETH2.0 階段在開發時間上會存在極大的差異。樂觀主義者告訴我 6 個月就已足夠，但在我看來，在看到階段 0 進入測試之後，階段 1 需要 12 個月至 18 個月的開發週期。

階段 2：智能合約

最終，階段 2 會帶來一個與我們所熟悉的以太坊相似的系統。隨着階段 2 發佈，分片鏈從簡單的數據容器過渡至結構化的鏈狀態。此時，新的以太幣 BETH 可實現轉讓，並且將重新引入智能合約。每個分片將基於 eWASM （我們稱之爲「EVM2」）管理一個虛擬機。

在這個階段，EVM2 將支持我們熟悉的賬戶、合約、狀態以及其他抽象內容。然而，大量的幕後更改可能會破壞大多數現有工具。幸運的是，eWASM 技術團隊已爲 Solc 編譯器、以太坊的開發和測試框架 Truffle、Ganache 做了一些基礎工作。在階段 2 的測試網絡之前或期間，我們能夠看到最常用的工具移植於此支持 EVM2。

狀態租賃（State Rent）或包含在階段 2，這也對當前 Solidity 編程語言工程師們提出一些有意思的挑戰。狀態租賃並不是無限期地存儲代碼和數據，而是要求合約開發者以及用戶在一段時間內爲 EVM2 存儲付費。通過確保未使用的信息隨着時間的推移而脫離狀態來防止狀態膨脹，最終實現其目標——讓用戶而不是讓整個節點來支付狀態成本。人們爲此提出不同的模式，「百家爭鳴」，但仍沒有明確的定論。

隨着一些以太坊升級計劃推進，以及著名以太坊核心開發者極力舉薦，狀態租賃可能是不同路線圖中唯一重疊的部分。因此，我強烈建議計劃在當前部署的合約上對狀態租賃的支持，並設計模型，以便未來將狀態租賃轉移至用戶。雖然我們還不曾參透狀態租賃的精確設計，但當下能做的是應該爲成本制定具體計劃。

此外，我們並不知道階段 2 的最終歸處，其依然處於早期的研究階段，包括幾個尚未解決的主要問題。鑑於非正式規範和開發過程，以及階段 2 在階段 1 的拓展範圍。在 2020 年之前啓動階段 2 似乎並不合理。也就是說，雖然 ETH2.0 或在今年推出，但預計 ETH2.0 版本至少要到 2020 年才能支持資產轉移或智能合約。

階段 3：鏈下狀態存儲

現在，爲了更好地討論智能合約，我們將幾乎完全跳過階段 3。

通過儘可能多地將狀態轉移至鏈下，階段 3 儘可能減少鏈上狀態。鏈上存儲時並不用存儲整個狀態，只需將一些狀態信息和聚合器（聚合器是表示長數據列表的短數據；Merkle 樹即爲聚合器的一種）進行存儲。用戶將負責在鏈下存儲完整的狀態。

當用戶與狀態進行交互時，其會在交易中包含當前狀態的證明。這樣，運行驗證節點的資源要求便會相對低很多。如今已經出現一些聚合器的設計，其存在不同特性和性能特徵，但目前尚未作出具體選擇。在這個階段，由於鏈不再能夠保證數據的可用性，我們會停止使用鏈上通信來進行用戶協調。在階段 3 中，維護和獲取鏈下狀態將成爲限制設計 DApp 的關鍵性因素之一。

階段 4：分片智能合約

然而，一個不可逾越的問題依然存在。雖然 ETH2.0 合約與以太坊的合約同樣強大，但其必然會被綁定到一個分片上，且永遠無法與另一個分片上的合約進行直接交互。這是分片的直接結果，分片目的在於在分片之間實現狀態分割，而無需直接瞭解其他分片。通過分割狀態以及儘可能的減少驗證者的工作量來實現拓展。

直接交互需要直接知識儲備。根據設計，分片不具有其他分片的直接知識。它僅通過與信標鏈的跨鏈通信來了解其他分片。因此，當用戶要進行跨分片交互時，就必須等待信標鏈。具體來說，這意味着如果在分片 A 上部署 SafeMath 模塊，分片 B 上的用戶必須等待訪問，或者在分片 B 上部署新的 SafeMath 模塊。

像 SafeMath 這樣的簡單實用程序將被部署到每個分片，即 1024 個分片上會部署 1024 個 SafeMath。但是像 Maker 或 Compound 這樣的市場呢？#DeFi 對可組合金融的允諾或許會變得難以跨越分片邊界。

CDP 激活與 DAI 收取之間的長時間延遲會導致難以負擔的經濟損失。若市場發生變化，同時 CDP 在用戶收到 DAI 之前被清算情況又會如何？在實際操作中，這可能意味着用戶需要在每個包含智能合約的分片上擁有一個賬戶，但跨分片的結構則毫無用武之地。Maker 和 0x 只有在其均部署在同一個分片上時才能進行交互，並且 0x 用戶也需要在該分片上擁有一定數量的資產。

根本性權衡：同步或是擴展

ETH2.0 版本的設計人員並不知曉跨分片通信系統的最終模樣。通過閱讀諸多提案，該系統或許會在即時反饋與可預測性之間進行根本性權衡。分片的本質不會改變，任何用戶都必須等待跨分片通信。但是，我們可以緊密或鬆散地將交易的本地和遠程執行階段耦合到每個分片上。

緊密耦合會使得等待處於優先級。在分片通信之前，交易不會執行任何操作。相反，我們可以通過現在執行部分以及稍後執行部分來鬆散地進行耦合交易。交易在本地分片上執行，然後在跨分片通信之後在遠程分片上執行。

鬆散耦合提供了更好的用戶體驗。用戶能夠即時看到其交易在本地執行，且知道遠程執行將在未來的某個時刻發生。但福禍相依，用戶必須在等待的情況下才能夠知道鬆散耦合交易遠程階段的結果。相較於鬆散耦合交易，緊密耦合的交易更具可預測性。同時，由於遠程狀態不會在本地和遠程執行階段之間轉換，用戶更瞭解結果。但「心急吃不了熱豆腐」，緊密耦合需要用戶在看到任何結果之前必須等待。

關於 ETH2.0 通信模型的信息少之又少。我們知道，該模型必須在犧牲幾乎所有擴展優勢的情況下提供跨分片合約調用。如果你在這裏停止閱讀，我不會責怪你，因爲階段 4 只存在思維導圖和一些模糊的鏈接。這種情況的一個不明顯的結果就是，ETH2.0 在階段 4 之前並不會爲複雜的智能合約系統提供顯著的擴容優勢。在此之前，希望與其他合約交互的智能合約必須與一個分片共存，並且侷限於該分片的速度和擴容效果。與 ETH1.X 相比，分片可能最多隻能獲得一個小常數因子的加速量。這意味着在階段 4 發佈之前（2025 年前後），由於其優勢不大，沒有理由將智能合約代碼或用戶進行遷移。

與此同時，爲了更好地理解工程師和 DApp 用戶的權衡，我研究了一些社區或者開發者建議的模型。在我看來，這些模型都不會被採用，但我相信這些模型有助於理解這其中所涉及的權衡。劃重點：下面所有的內容都是推測性的。

基本模型：收據（Receipt）和證明（Proof）

所有形式的跨鏈通信都藉助信標鏈。由於信標鏈能夠檢索所有分片的狀態，並且每個分片會影響到信標鏈的狀態，因此將其用作分片鏈生態系統中的核心。從某個鏈到另一個鏈的信息在某種意義上必須通過信標鏈傳輸，考慮到這需要信標鏈來處理每筆交易本身，完全無法實現擴容的效果，故並不希望發送完整的消息。

相反，當分片 A 上的用戶或合約想要與分片 B 進行交互時，分片 A 會生成帶有該交互消息的「收據」。分片 A 在其塊頭中提交其所有收據，信標鏈再等待 A 確認完成後，將提交至分片 A 的塊頭（包括對收據的提交）。分片 B 也必須等待信標的最終確認，之後提交至信標塊頭。

該階段完成之後，可以向分片 B 提交新交易，包括收據和證明。證明顯示收據包含在分片 A 中，分片 A 包含在信標中，且信標包含在分片 B 中。這樣，分片 B 上的用戶或合約可以信任從分片 A 發送的消息。如果分片 B 上的合約想要發送回覆（或返回值、錯誤），則需要反過來重複整個過程：分片 B 發出一個收據，最終回至分片 A。

不難看出，該過程需要消耗大量時間。四個通信步驟中的每一步都需要等待幾分鐘才能完成。不幸的是，我們無法完全避免等待。如果我們想確定遠程狀態，那麼在每一步都必須等待最終結果。往返通信的最佳情況是四個最終確認週期。換言之，由於用戶可以在分片 A 看到分片 B 的數據之前看到它們，在三個確認週期後用戶可獲得信心。使用 ETH2.0 的 6.4 分鐘的時間段（Epoch）長度，用戶必須等待 19 分鐘才能看到結果，並且需要 26 分鐘才能獲得鏈上結果。

具體收據（Concrete Receipts）：分片之間的代幣遷移

ERC20 Token 的多功能性使其在如今的以太坊中無處不在。但是，ETH2.0 也給 Token 帶來部分邏輯問題。由於智能合約管理所有的 Token 餘額，且智能合約僅存在於單個分片上。因此，分片 B 上根本不存在來自分片 A 的 Token。但通過一些智能跨分片通信，我們可以在多個分片上部署相同的 Token，並允許在分片之間進行 Token 轉移，有效地在 Token 合約之間建立雙向掛鉤。

解決方案非常簡單。

在部署 Token 時（讓我們稱之爲「酷酷的跨分片 Token」或「CCT」），我們將基於 ERC20 添加兩個小附加功能——MigrateSend 和 MigrateReceive 函數功能。藉助使用 MigrateSend 銷燬 Token 並生成收據，其中將包括已銷燬的 Token 和接收的分片。之後，通過調用 MigrateSend 來銷燬一個分片上的 Token，然後在另一個分片上調用 MigrateReceive 來有效地進行 Token 轉移。

我們需要在每個分片上重新部署我們的 Token 合約，但這似乎是值得的。遷移是單向的，至少需要兩個跨分片通信的最終確認。因此，我們調用 MigrateSend 之後大約需要 10 分鐘，「CCT」纔可以在接收分片上使用。

Yanking （拉拽）

收據是跨分片進行信息傳遞的一種通用方式。我們可以在收據中放置任何鏈上信息，甚至包括整個智能合約。Yanking 是一種通過將合同的代碼存儲包含在收據中，從而實現跨分片合同遷移的提議。合約將從分片 A 中刪除（Yanked），然後在收據到達之後在分片 B 上重新部署。合約一旦進入分片 B，其可以直接與分片 B 合約進行通信，並且與分片 B 的狀態進行交互。同時，該合約甚至可以被 Yank 回至分片 A。

這將允許任何一個智能合約與任何其他智能合約進行通信（在跨分片等待時間之後）。但由於收據包含整個合約及其所有存儲，因此轉移大型或用戶體量大合約的成本會很高。收據在運輸過程中，合約將完全無法使用。其已從分片 A 中抽出，但尚未到達分片 B。這意味着所有其他用戶均無法使用該合約，直到其到達分片 B。同時，只有已在分片 B 上的用戶才能與之進行交互。因此，Yank 最適合用戶很少的小智能合約，它使緊密耦合的執行成爲可能，但並非是通用的解決方案。

分片配對（Shard Pairings）

我們轉而談談一些更具創意的構建想法。

收據旨在使異步（鬆散耦合）通信成爲可能。但我們也可能需要同步通信。爲此，我們必須更有創意。通過一個簡單設計，分片配對可以實現在緊密耦合執行的同時，儘可能地將麻煩最小化。

分片配對是一個簡單的解決方案。在文章的第三段中就已經提到，我們在每個高度將分片混合成同步對。每次一個分片與另一個分片進行配對時，任一分片的用戶都可以跨越這兩個分片執行緊密耦合的狀態更新。如果分片 A 和 B 在高度 7 處配對，則 A 和 B 的所有驗證者必須知道 A 和 B 的全部狀態，並且分片必須一起前進或根本不前進。

在此模型中，如果 A 和 B 之間需要進行跨鏈交易，則需要等待 A 和 B 隨機配對。但是 Vitalik 描述了 100 種分片案例。存在 1024 個分片，我們預計其需要 512 個區塊，因此大約需要一個小時。但由於配對是隨機的，它可能需要更長或更短。正如 Vitalik 所說，當你想要與多個分片進行交互時，這種擴容性並不好。

分片區域（Shard Zones）

這是分片配對的更廣泛版本。

每個時間段（Epoch），我們將分片分成幾個由多個分片組成的「區域」。區域內的分片必須同步進行，因此需要共同更新其本地狀態。通過同步進行，區域保證了分片之間的自由移動，以及與區域中的任何合約直接交互，但與區域外的任何分片進行通信則沒有任何優勢。

此外，由於區域需要驗證者知悉區域中所有分片的狀態，會導致其否定分片的許多擴容優勢。假如一個區域由 16 個分片組成，則犧牲約 15/16 （ 94％）的擴容優勢，僅獲得總網絡的 15 / 1024 （1％）的緊密耦合的執行。

產權負擔（Encumbrances）

跨分片（和跨鏈）通信的一個不明顯的特性是，用戶可以比所涉及的鏈更快地獲得對消息的信任。Alice 從分片 A 向分片 B 發送 5 BETH，其知道這些資產會在發送後立即到達。Bob 看到交易發送，知道一旦發送至分片 A 上進行確認後，BETH 將到達分片 B。然而，分片 B 及其合約必須等待幾分鐘，才能使信標鏈對分片 A 的確認進行最終確認。這意味着資金在分片 A 上花費以後，一個錢包能夠很快在分片 B 上進行接收和花費這些資金。換句話說，由於 Bob 很有信心 Alice 已發送足夠的 ETH，其將從分片 B 上 Alice 的錢包中獲得可執行的 IOU （欠條）。如果分片 B 存在足夠多的用戶願意觀察分片 A 並接受標準化的 IOU，則分片 A 上的 ETH 可能會在發送之後很快在分片 B 上花費。

然而，當應用於智能合約時，由於狀態永遠不可替代，這種解決方案就變得異常複雜。狀態的欠條是不可能實施的，因此其亦不適用通用交互。我們應該將產權負擔視爲鬆散耦合中的用戶體驗進行改進，允許松耦合模擬緊耦合，快速執行某些交易。

共識和狀態分離

更復雜和更讓人感興趣的一種方案是將共識過程與狀態更新過程分離。

只有在執行區塊中包含的所有狀態更新後，以太坊礦工和完整節點才接受區塊。事實並非如此。相反，其可以先接受區塊，而後進行狀態更新。在這種情況下，我們不會像在以太坊中那樣就係統狀態達成共識，而是會對所有分片中所有交易的總歷史（或「總順序」）達成共識。

這種解決方案意味着每個分片都可以快速添加區塊，而無需知道任何其他分片的狀態，這就是利用分片進行擴容的原理。但在所有分片完成之前，交易對分片狀態和整個網絡的影響將會被隱匿。換句話說，狀態的最終確認落後於分片內容的最終確認。

從用戶的角度來看，我們會立即提交交易，且知道該交易已被包含在內。但用戶必須等待一定時間來確定該交易的結果。隨着分片的最終確定，我們逐漸獲得有關狀態的更多信息，但在所有分片達到最終確認之前，用戶並不能完全確定。與產權負擔相似，在某些情況下，用戶可以提前確認交易的結果並相應地採取行動。

小結

ETH2.0 將是與以太坊完全不同的系統，二者將並行存在多年並具有不同的特徵集。在不久的將來，預計會出現從 ETH 到 BETH 的單向掛鉤。如果你經營交易所或託管服務，可以考慮 BETH 在鏈上實現轉移之前支持用戶進行 BETH 託管交易和押注。從長遠來看，還需要考慮智能合約如何在有無跨分片通信的情況下適應分片。

最重要的是要密切關注研發過程。ETH2.0 是一個複雜且不斷髮展的系統，所有 DApp 工程師都需要清楚地瞭解 ETH2.0 計劃和進度。

來源鏈接：hackernoon.com