編者註：本文為Vitalik 於2020 年10 月19 日在以太坊研究者論壇上發表的帖子，提議了他所設想的Eth1 如何轉換成分片化信標鏈的子系統的過程，並解釋了開發者、用戶對這個過程會有什麼知覺。確切來說，這並不是一個針對Eth1 的提案，因為提案的內容無涉於Eth1 的鍊和生態如何形成廣泛的社會共識來完成這種轉換，相反，它僅僅涉及到了分片化信標鏈的一個子系統（“Eth1 EE”）要按什麼樣的程序選取Eth1 上的哪個狀態作為自己的起始狀態。此外，讀者還可藉此一窺作者心中一個準備好完成轉換的分片化信標鏈應具備哪些基礎設施，例如，無狀態性和EE；藉此可反推分片化信標鏈的開發方向和進度。

本文介紹的路線圖被用來完成從eth1 向eth2 轉換，如果你是應用開發者或用戶，你所能感受到的變化乃至顛覆實際上非常有限。已有應用將繼續運行，而不會發生任何改變。所有賬戶餘額、合約代碼和合約存儲（包括ERC20 餘額、質押債倉等）都將繼續存在。

你需要應對以下情況：

IO 訪問操作碼（SLOAD、BALANCE、EXT*、CALL*）的gas 成本將增加。 CALL（調用）的gas 成本大概是每訪問1 字節的代碼需要消耗1 gas。你需要下載實現網絡升級的代碼。這在根本上與拜占庭和君士坦丁堡等其它升級沒有區別。但是下載量更大一點，因為如果你還沒有eth2客戶端，那你需要下載一個。以太坊區塊鏈可能會暫停大約1 小時。 1 小時後，“以太坊” 看似重新上線了，但是實際上eth1 不再是一個獨立的系統，而是成了在eth2 內運行的子系統。

就是這樣。如果你是開發者，只要你確保自己的應用所需的witness 規模不會太高（可通過單筆事務所訪問的全部存儲槽+合約+合約代碼的數量來衡量），你的應用因為gas 消耗量改變而崩潰的可能性就很小。

轉換將如何發生

假設phase 0-2 已經完成，並且eth2 鏈正在穩定運行。 eth1 鏈也在穩定運行中。 phase 0 規範已經安排了一個名為

eth1_data

voting 的機制。在這個機制中，驗證者會通過投票就eth1主鏈最新的區塊哈希值達成共識；這個機制目前被用來處理押金。我們將重新改變該機制的用途，用它來將eth1 的完整狀態（根）傳入eth2。

目前，該機制有大約6 小時的延遲（其中有4 小時的延遲是因為ETH1_FOLLOW_DISTANCE “Eth1 主鏈跟隨距離”，另外2 小時是因為投票期） ，但是在轉換完成前，這些參數會隨著時間的推移而減小，將延遲降至1 小時左右。

影響eth1 向eth2 轉換的基本機制如下圖所示：

指定一個（eth1 鏈的） 高度 TRANSITION_HEIGHT。高度為 TRANSITION_HEIGHT 的eth1 區塊將被視為eth1 鏈的“最終” 區塊。從該區塊往後，（原本是“正統鏈的”）eth1 將作為eth2 的子系統運行。 eth2 的“誠實驗證者” 代碼會根據（1）做出相應調整，不允許驗證者投票給區塊號> TRANSITION_HEIGHT 的eth1 區塊。如果投票算法已經選出了某個區塊編號> TRANSITION_HEIGHT 的eth1 區塊，則改成為 TRANSITION_HEIGHT 的eth1 區塊投票。此外，在已觸發（2）的情況下，驗證者會將deposit_count 設置為比實際值高2**63（就是將deposit_count 的top bit 作為“eth1 已完成” 的標記）當eth2 在“eth1 已完成” 標記開啟的情況下接受eth1data 時，eth2 會執行一次“非常規的狀態變換”，將該eth1 區塊的狀態根放到“eth1 執行環境”（eth2 上的一類系統級智能合約）的狀態中。與eth1 鏈上的總ETH 供應量等量的ETH 會添加到這個eth1 執行環境的餘額中。

在這之後，轉換完成。從技術層面來說，eth1 鏈會繼續運行，但它已經變成了一條毫無價值的鏈；等到冰河期到來時，這條eth1 鏈將徹底消失。

eth1 系統現在位於eth2 系統內部。因此，通過在eth2 上提交針對eth1 執行環境（即上文所述的eth2 子系統）的交易，eth1進一步轉換成eth2 的子系統。 eth1 執行環境擁有可以實現整個eth1 EVM 和交易處理邏輯的代碼；它有一個

update(state_root, transaction, witness) -> new_state_root

功能，可以按照eth1 鏈的規則，以交易和見證消息（狀態部分的默克爾證明）作為輸入處理該交易，並決定更新後的eth1 狀態根。關於見證消息和狀態根的運作原理，請閱讀《無狀態客戶端概念》。

eth1 執行環境代碼可以添加額外的功能，即，將ETH 和消息從eth1 執行環境提取到eth2 的其它部分，以及其它分片上的eth1 執行環境副本中。在默認情況下，所有eth1 賬戶/合約都會放在同一個分片上，因此為了利用eth2 更大的容量，你需要主動使用這個功能將你的ETH 或其它應用轉移到其它分片上，不過難度不大。我們需要通過擴展ERC20 標準來支持跨分片代幣轉賬。

用戶客戶端如何運作

在轉換至兩種代碼路徑之前，我們需要對客戶端面向用戶的部分進行修改。客戶端會檢查eth2，來查看轉換是否已經發生。如果轉換尚未發生，客戶端就會像之前那樣使用eth1 來發送交易，查看餘額等，不同之處在於客戶端會假裝所有區塊編號>

TRANSITION_HEIGHT

的eth1 區塊都不存在。如果轉換已經發生，客戶端就會在eth2 上查看eth1 執行環境。完整的客戶端將按順序處理eth2 上所有針對eth1 執行環境的交易，以便繼續更新完整的eth1 狀態樹。這使得完整的客戶端可以為它們想要發送的交易生成見證消息，並使用eth2 格式對其進行“打包”。輕客戶端（以及錢包，如metamask）會將它們的交易廣播給完整的客戶端，由後者為其添加見證數據。

從用戶的角度來看，以太坊能夠“感受到” 轉換前和轉換後（由於PoS 和EIP 1559，以太坊在感受後者時更加順暢）。雖然打包和廣播交易所使用的代碼路徑區別很大，但是它們所提供的功能都是一樣的。

我們甚至可以對這種轉換進行設計，以便錢包無需經過任何修改，即可通過RPC 與客戶端通信。

用戶案例

假設你在MakerDAO 上創建了一個質押債倉，然後就去睡覺了。等你醒來時，你發現轉換已經發生了。你可以像以前那樣發送交易來與你的質押債倉交互並將其清算，但是你的客戶端會看到轉換已經發送，於是會將見證數據添加到你的交易上，將其發送至eth2 網絡而非eth1 網絡上。

潛在優化

在eth1 鏈達到

TRANSITION_HEIGHT

至eth2 上的eth1 執行環境獲取該狀態的這段時間內，我們會對eth1 狀態進行一些預處理。特別是，我們可以：

將十六叉帕特里夏樹替換成二叉稀疏默克爾樹和一個專門的哈希函數，以確保分支的哈希開銷保持在O(log(n))。這可以將默克爾樹分支的大小減少4 倍左右。將RLP 替換成SSZ 哈希樹將狀態租金相關的數據字段添加到賬戶上清除“粉塵” 賬戶根據抽象提案修改賬戶結構

我們不會在EE 中照搬沿用Eth1 的狀態根生成方法，而是以適用上述修改後的方法來計算狀態根（Instead of including the actual eth1 state root into the EE, we would include the root of the state tree generated by performing all of these modifications）。這是確定性計算，因此所有驗證者都可以同時進行計算。這種一次性的計算支出可以大大提高eth1 轉換後的效率和可用性。

原文鏈接:

https://ethresear.ch/t/the-eth1-eth2-transition/6265

作者: Vitalik

翻譯&校對:

閔敏& 阿劍