原文標題：《引介 | eth1 -> eth2 轉換》
撰文：Vitalik Buterin，以太坊聯合創始人
翻譯 & 校對：閔敏 & 阿劍，來自以太坊愛好者
本文為 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 轉換后的效率和可用性。
來源鏈接：ethresear.ch
