原文標題：《可視化以太坊的未來之路》
今天的以太坊就是 eth2 開發者所稱的“eth1”，也即當前我們熟知和喜愛的 PoW 鏈；明天的以太坊既不是 eth1，也不是 eth2，而就是…以太坊：綜合了在今天的執行層 (eth1) 之上部署 PoS 和分片的一系列 eth2 工作，
我們先來回顧一下今天的以太坊 (eth1)：
今天的 eth1 鏈的運作方式
在今天的以太坊上，當用戶想要做一些事情 (即“事務”)，他們會把事務 (transactions) 發送給礦工，然后礦工把事務打包進區塊，并將這些區塊添加到一條不斷增長的區塊鏈 (eth1) 中，礦工運行 PoW 共識機制，以此來決定由誰來添加下一個區塊，礦工也執行區塊中包含的事務，以確保這些事務是有效的。
PoS 替代 PoW：驗證者替代礦工，小型服務器替代大量挖礦設備
PoW 需要大量的硬件設備來運行密集運算，進而造成了過高的能耗，在此，我們不會像大多數加密貨幣批評者那樣討論能源浪費問題 (比如“為什么我們要使用一個消耗<某個國家的>能源的支付系統？”)，但如果我們可以消耗絕對更少的 kWh (千瓦時) 來做一些事情，那么這 (PoW) 就確實是存在能源浪費，我們應該減少能耗。
因此，這將我們帶入 PoS，使用小型的服務器來取代大量挖礦設備，并使用驗證者 (validator) 取代礦工，
在 PoS 中，如果驗證者不執行驗證工作 (圖中第2步)，則將會適當地損失質押金
那么，上圖中的第2步 (即驗證) 是什么呢？驗證者到底要驗證什么？
我們可以將以太坊的活動分為兩部分：共識層→“哪個是正確的數據？”；執行層→“數據的含義是什么？”
共識層 (consensus layer) 確保所有人都對正確的數據達成共識，執行層 (execution layer) 實際上是“解釋”這些數據，使數據有意義，“數據”是指與區塊鏈進行的任何交互，比如部署一個智能合約，在交易所進行交易，發送一筆付款等等…
區塊鏈的核心是在鏈中引入新的區塊。當新區塊被添加進來時，新區塊進來之前的狀態和進來之后的狀態之間，會發生一次狀態轉換 (state transition)。區塊鏈的當下狀態匯總了之前所有區塊的數據。
例如，如果當前狀態維持著一個記錄了 Alice 和 Bob 的賬戶余額的賬本，而新區塊中包含了一筆 Bob 向 Alice 支付了 10 枚幣的交易，那么這個新區塊被添加進區塊鏈中之后，狀態將會記錄新的余額資訊，一個新區塊添加進來之后，要么會更改當前的狀態 (比如，更新 Alice 和 Bob 的余額)，要么會創建一個新的狀態 (比如部署一個智能合約，或者將 Carol 新添加進賬本中…)，
根據以太坊計劃，第1步是將共識與執行解耦；第2步是把PoW共識換成PoS共識
根據我們的計劃，Rollups 和 eth2 工作的總體要點就是處理上圖中的第1步，也即將共識與執行解耦 (decorrelate consensus and execution)。那么，這方面進展如何了呢？
第1步已經完成了！
自 2020 年 12 月以來，我們已經有了兩條并行運行的區塊鏈 (見上圖)：
- 上方的是 PoS 共識鏈 (即信標鏈)
- 下方的是可靠的 PoW 共識+執行鏈 (即 eth1 鏈)
這兩條鏈并行運行，但它們會相互“交流”，當然目前是單向的…
如何成為一名驗證者？
要成為 PoS 共識鏈 (即信標鏈) 的驗證者，用戶需要在部署于 PoW 共識+執行鏈 (即eth1) 上的存款合約中鎖定 32 ETH，該質押金會自動轉移到 PoS 共識鏈中，一旦驗證者被激活，就可以開始 (對 PoS 共識鏈) 進行驗證并獲取獎勵，
合并之后，信標鏈 (紫色) 是共識鏈，切換為 PoS 共識的 eth1 鏈 (紅色) 將作為執行鏈，什么時候實現合并？可能在2021年實現…
預計這種單向的“交流”將不會持續很長時間。合并這兩條鏈將永久地連接 PoS 共識鏈 (信標鏈) 和 PoW 共識+執行鏈 (eth1) 之間的鴻溝，從而允許驗證者為執行層 (即合并之后切換為 PoS 共識的 eth1 鏈) 生成區塊，因此，合并之后，我們將有兩條鏈：
- 同一條 PoS 共識鏈 (即信標鏈)
- 基于 PoS 的執行鏈 (即切換為 PoS 共識的 eth1 鏈)
合并之后，PoS 共識鏈 (信標鏈) 的驗證者們將終于能夠贖回和提取他們的收益和存款，并將收益和存款發回至 PoS 執行鏈 (eth1) 中，
所有這些使我們從 PoW 環境轉移到了一個完全合格的 PoS 環境中！但需要注意的是，此時并沒有增加這條鏈的帶寬——這是分片 (sharding) 要實現的目標，在這之前，在我們尚且只有一條執行鏈 (即 eth1 鏈) 之際，我們來討論一下如何通過其它方式來對執行進行擴展，
擴展計劃：1. 將執行轉移至鏈下；2. 將數據提交至鏈上。
Rollups 是眾多可用的擴展解決方案之一，但從協議設計的角度來看，它可能提供了最優折衷的方案。Rollups 的理念很簡單：通過在鏈上提交重建狀態轉換執行所需的數據，來綜合地處理狀態轉換，并將執行轉移至鏈下進行。如果有人對執行結果有異議，或者有人忘記了在第一時間執行，那么數據就在那里等著所有人處理，Rollups 是無需許可的！
更準確地說，在 Rollups 中，執行所需的數據 (事務輸入) 與它的載體 (事務) 是分開的，且這些數據是以節省空間的方式“捆綁”起來，同時，Rollups 在執行鏈 (即eth1鏈) 之外運行，提交數據并加以執行，見下圖：
如今 eth1 鏈的擴展正在發生，Rollups 已經部署，其它擴展方案也在開發中，
想要“使用某條 Rollup 鏈”的用戶，需要在該 Rollup 位于執行鏈 (eth1) 上的合約中存儲一些資產，之后用戶就可以在該 Rollup 上做一些事情了，比如使用自己的資產與該 Rollup 鏈上的其它資產進行交易。一旦用戶完成了想要做的事情，就可以將資產從 Rollup 撤回至執行鏈中。就是這樣！
Rollups 有什么其它替代性方案？如果我們沒有這些并行運行的 Rollps 鏈(上圖中的黃色鏈)，而是擁有很多條并行運行的執行鏈(上圖中的紅色鏈)，那會如何？比如，如果 eth1 鏈被“復制”，并與其它幾條復制鏈并行運行，那會怎樣？
其中的問題在于我們如何處理幾條平行運行的執行鏈。如果其中某條執行鏈想要知道另一條執行鏈中發生的事情，那該如何做到？這正是分片 (sharding) 遇到的棘手問題 (注：也即所謂的跨分片通信問題)，
你可能會說，“Rollups 差不多也有這樣的問題！”，實際上確實如此，當你在某條 Rollup 鏈上想要與另一條 Rollup 鏈進行交互時，同樣的棘手問題也會出現 (即跨Rollup通信問題)。但重點是，當前存在幾種 Rollup 設計，這一問題的解決方案空間很廣闊，且在很大程度上尚未被探索，因此，在將某種方案納入協議層之前，為何不通過 Rollups 先啟動試驗呢？
這將我們帶向了以 Rollup 為中心的以太坊路線圖，
以 Rollup 為中心的 eth2：使用分片來保存 Rollups 發布的數據
你聽說過區塊空間的稀缺性吧？Rollups 需要發布數據，而 eth1 的區塊空間是稀缺的！且如上所述，跨分片很難。因此，為什么不使用分片來保存 Rollups 需要發布的數據呢？借助于 64 條分片鏈，就能帶來比當前可用的多出 64 倍的帶寬，而且可能更多，因為一個分片區塊將可能保存比當前的 eth1 區塊更多的數據量。
應該強調的是，這并不意味著在分片層的執行功能會永遠被排除在外，當前以 Rollup 為中心的以太坊路線圖是一種短期到中期的前進方式，直到 (例如) 找到更好的加密原語來保證正確地將執行劃分到多條鏈中 (注：即實現可執行分片)。這一切都非常迷人，應該會讓很多人忙上很長一段時間，在此期間，Rollups 是解決之道，
每條 Rollup 鏈都是其自身的“執行環境”：如何輕松地遷往/遷出 Rollup？我們可以進行跨Rollup操作嗎？Rollups 應該如何處理擁堵問題？
這方面還有很多工作要做！首先，我們不要忘記，合并和數據分片是非常復雜的工作，目前有多個團隊在致力于其中一項或兼顧這兩項工作，而即便是在 Rollup 方面，仍然有一些非常有趣的問題有待探討，以下僅是其中一些：
- 如何大規模地實現用戶向 Rollups 的遷移或者從 Rollups 遷回至鏈上，這是一個很酷的概念。如果你有足夠多的公共交通工具讓你往返于 Layer1 (eth1) 和Layer2 (Rollps) 之間，為何你還要自己開車往返呢？其中的經濟機制是什么呢？
- 如果你想在臨近的一條 Rollup 鏈做一些事情，因為該 Rollup 中有著一些你所在的 Rollup 中沒有的酷東西，那你該怎么辦？你是否必須從當前的 Rollup 撤回至 Layer1 上，然后再從 Layer1 轉移至該臨近的 Rollup 中？這似乎相當的不經濟。
- 對于當前的鏈上操作來說，Rollups 是一個巨大的帶寬提升，這是毫無疑問的。但是，Rollups 并不是用戶所期望的無限高速公路。在 Rollups 中，仍然會有很多人想要做很多事情，且有時候是同時發生的！因此，Rollups 將與生俱來地要應對擁堵問題，但與 Layer1 協議保護的擁堵市場 (EIP-1559 很快就會實施) 不同，Rollups 有著更大的設計空間可供探索，
- 說到擁堵問題，這是更特定于協議的，但我們還將看到 EIP-1559 扮演交通警察的角色，來規范每個數據分片上發布的數據量，以確保驗證者能夠處理這個數據量，如果你認為 EIP-1559 機制在一條鏈 (eth1) 上很酷，那么等到有 64 條分片鏈同時運行該機制時會更酷，那么，Rollups 應該在哪里發布它們的數據呢？是將數據僅發布在單個分片上，使數據僅在該條分片上可獲取？還是發布在多個分片上，從而受益于計劃中的分片交錯出塊？其中，分片交錯出塊 (shard staggering) 是 Vitalik 最近提出的想法，即所有分片輪流出塊，這樣 Layer2 項目 (如 Rollups) 在發布數據時，距離一個新區塊的時間間隔不會超過幾百毫秒，這對于需要快速敲定的應用來說是理想選擇。
