原文標題:《Annotated Ethereum Roadmap》
原文編譯:domothy ,ETH中文站
譯者註:本文基於最新以太坊路線圖進行內容註解,下圖為 ECN 譯製的中文版。

本文檔旨在為讀者了解以太坊路線圖上各個部分提供入口點,每一部分都做了簡單的概要介紹,如想深入了解,文內亦附上了詳細的鏈接。
這是一份持續更新的文檔,如果發現這裡提供的任何信息出現不清楚、不准確、過時或是遺漏的情況,請隨時聯繫我。
注意:如路線圖上箭頭所示,所列出的各個部分並非連續進行的工作,它們的推進是並行的。
目標:實現一個理想化的、簡潔的、擁有魯棒性的以及去中心化的 PoS 共識機制
2020 年 12 月 1 日—信標鏈啟動
· 引入以太坊 PoS 共識層,由驗證者質押 ETH 來維護該層網絡安全
· 信標鏈在共識規範中被稱為階段 0 (Vitalik 的註釋版本以及 Danny Ryan 的註釋版本)
2021 年 10 月 27 日—熱身分叉 (Altair) - 共識層客戶端開發者們在協調硬分叉升級方面進行了一次試運行
· Altair 引入了同步委員會來支持輕客戶端,並對懲罰進行了一些調整
· 「What’s new in ETH2」中對 Altair 進行解釋的那期
2022 年 9 月 15 日,—合併! PoW 退休 - 在區塊高度 15,537,394 處完成共識層和執行層的合併
提款 —允許驗證者提取全部或者部分質押金
· Capella 分叉 指定共識層中的變更
· EIP-4895 指定執行層中的變更
· 提款元規範和其他信息
分佈式驗證者 —「多簽,不過是用於質押的」,這項技術中,n 人共享同一個驗證者並且 m-of-n 必須就其行為方式達成共識
· 通過防止意外的罰沒來強化質押機制,並使其更加容易參與 (比如,通過在多個參與者之間去信任地切分所需的 32 個 ETH)
· 這並非協議內的工作,SSV 和 Obol 等團隊正致力於這項研究
視域合併 (View merge) —調整分叉選擇規則 (驗證者投票的方式) 以減輕一類攻擊
· 本質上就是「強制」誠實的驗證者能夠看到正確的鏈頭,以減少作惡驗證者分裂投票並重組對其有利的區塊的機會。
· ethresear.ch post 中有許多關於這項研究的 (非常技術性的) 背景
改良的聚合 —以太坊努力支持盡可能多的驗證者,但是讓每個驗證者對每個區塊投票 (並驗證每個其他驗證者的投票) 太佔用帶寬了。退而求其次就是聚合簽名,但這也有其局限性,而且可以做得更好
· 潛在的候選簽名技術:Horn
單個 slot 實現最終確定性 (SSF) —每隔一個 slot (12 秒) 敲定一次鏈狀態,而不是每隔一個 epoch (12.8 分鐘)
· 通往單個 slot 實現最終確定性之路 (中文版) 除了改良簽名聚合之外,我們還必須弄清楚兩件事:
SSF 共識算法 - 現有的與 SSF 兼容的算法是不夠的,我們想要一個即便是超過 1313 名驗證者離線也能保持鏈的活性的算法。
SSF 驗證者經濟學 - 如果我們最終不得不限制驗證者的數量,我們如何限制參與率,以及我們需要做出什麼犧牲?
秘密領導選舉 (SLE)
· 目前,被選中提議一個區塊的驗證者 (單個 slot 的領導者) 是稍微提前知道的,這使得潛在的 DoS 攻擊能夠專門針對即將到來的區塊的領導者
· ethresear.ch 有一篇帖子是關於基於隨機混洗的單一秘密領導選舉的協議:除了領導者自己,沒有人知道誰將是這個 slot 的領導者,直到他們將自己的區塊與領導者證明一起公佈出來。
· 非單一秘密領導者選舉可能也是一種選擇。
支持更多驗證者 —正在進行的長期努力:安全地支持更多的驗證者始終是我們的目標
量子安全的、聚合友好的簽名 —在量子計算機成為一個合理的擔憂之前,使以太坊成為量子安全的是我們長期努力的一部分
· 所用的 BLS 簽名方案基於的密碼學已知會被量子計算機破解,但已知是量子安全的替代簽名方案並不像 BLS 那樣有效地聚合簽名 (因此需要一個既量子安全又聚合友好的方案)。
· 兩個主要的量子安全方案是基於 STARK 的和基於 Lattice 的。
目標:確保可靠且可信中立的交易打包過程,避免 MEV 帶來的中心化以及其他協議上的風險。
Relevant links:相關鏈接:
協議外的 MEV 市場—MEV-Boost 中間件允許普通驗證者從 MEV 中獲利,而無需自己運行複雜的 MEV 策略
· 這個解決方案本身不完整,因為它有審查問題
· 閱讀文章 "The Cost of Resilience" 和 "The Future of MEV is SUAVE",了解使得這些協議外的 MEV 市場更加有彈性的計劃
打包列表或者備選方案 —讓區塊提議者對區塊構建者進行限制,即強迫他們納入交易
· 打包列表相關筆記研究如何在不增加提議者負擔的情況下約束構建者
· 協議內 PBS —將區塊構建市場直接寫入協議內
MEV 銷毀 —讓區塊鏈獲取原本從鏈上經濟中提取的價值
· 委員會驅動 MEV 均勻分配讓協議意識到 MEV
· 通過經濟激勵措施設置驗證者子集的上限,將通過負增發間接銷毀 MEV
應用層 MEV 最小化 —這個工作與 L1 沒有直接關係,它涉及到開發者在設計他們的 dapp 時需要記住 MEV。這裡有幾個採用 MEV 最小化策略的 dapp 的例子
由於區塊提議過程是保持去中心化的,我們現在有一個單獨的問題,即區塊構建變得中心化。即便路線圖上的所有其他部分都旨在最大限度地減少區塊構建中心化可能帶來的最壞情況,能夠將區塊構建分佈在許多節點中仍然是一個很大的好處。
· Blob 結構 - 尋找方法來減輕數據分片在許多節點上的高帶寬和處理要求,而這些節點是普通消費者級別的硬件可以運行的。
· 預確認服務 - 給予用戶強有力的保證,他們的交易將被打包進下一個區塊中
· 搶跑保護 - 盡量減少有毒的 MEV,如三明治攻擊,使得分佈式的構建過程保持可信的中立
這依然是一個活躍的研究領域,具有非常開放的設計考慮,所以目前還不清楚前面兩個框框是否應該被寫入協議內 (因此路線圖上有問號),這裡是相關的鏈接:
· 關於合併后區塊構建的演講,提到了去中心化區塊構建
· 關於去中心化構建者的演講
目標:驗證區塊應當超級容易—下載 N 個字節數據、執行一些基本計算、驗證一個 SNARK 然後你就完成驗證了。
這一部分基本上是關於通過使得輕客戶端最終可行,以填補 「客戶端方面的不足」:並非每個人都想或者能夠運行一個全節點。 The Verge 的目標是引入去信任或者信任最小化的替代方案,這種節點易於運行,不需要大量的存儲和帶寬。 The Verge 的最終目標是讓這些輕客戶端提供與目前全節點相同的安全保障。
這一切都依賴於零知識技術,如 SNARKs 和 STARKs,它們本身依賴於多項式承諾方案。這裡有一些關於這方面的鏈接:
· 剖析 STARK
解決了最嚴重的 EVM DoS 問題 —主要是 gas 定價問題,已在柏林昇級中解決
基本的輕客戶端支持 (同步委員會) —多虧了同步委員會,很容易構建遵循共識層的輕客戶端
· 了解 Helios 客戶端是如何利用同步委員會的 (很好地解釋了這些委員會是如何運作的)
EIP-4844 實現 —在主網部署 EIP-4844
· 將需要一個「儀式」來創建受信任初始化:解釋、預估時間線、規範
基本的 rollup 擴容 —依賴於下面的工作:
· EIP-4844 - 所實現的可擴展性依然被認為較基礎/有限,這是因為「每一個節點下載所有數據」的性質限制了 blobspace 的可用容量
· rollup 的有限輔助輪階段 (文章中提議了去掉 rollup 輔助輪的路線圖) (中文版)
完整的 rollup 擴容 —依賴於下面的工作:
· DAS (數據可用性採樣) 的 P2P 設計:涉及數據分片網絡連接問題的一些工作以及研究
· 數據可用性採樣客戶端:開發輕量級客戶端,可以通過對幾千字節的隨機採樣快速判斷數據是否可用
· 有效的 DA 自我恢復:能夠在最惡劣的網絡條件下有效地重建所有數據 (比如,惡意驗證者攻擊、或者大塊節點的長時間停機)
· 不使用輔助輪的 rollup:完全去中心化的定序者、去信任的欺詐證明、不可變的合約等等
量子安全的、無需受信任初始化的承諾 —在量子計算機成為一個合理的擔憂之前,使以太坊成為量子安全的是我們長期努力的一部分
· 雖然高效且強大,但到處使用的多項式承諾 (KZG) 並不是量子安全的,並需要一個受信任初始化。對更理想的長期使用的承諾的研究正在進行中,最終目標是在底層對 KZG 進行熱轉換 (hot swap)
SNARK / STARK 專用集成電路 —專門用來創建證明的硬件
Verkle tree —將用於全局狀態的數據結構替換成一個更高效的版本
· 關鍵的好處是能夠生成非常簡潔的證明,輕客戶端可以只通過區塊頭很容易地驗證這些證明,以核實像賬戶餘額這樣的東西 - 它們已經可以利用同步委員會來驗證給定區塊頭實際上是主鏈的一部分
· 需要編寫出合適的規範、確保安全地遷移,以及搞清楚它將如何影響更新/編輯狀態的 EVM gas 開銷 (這也取決於 The Purge 那部分中取消「SELF-DESTRUCT」的工作)
基於 SNARK 的輕客戶端 —對同步委員會的狀態轉換生成 SNARK 證明,以快速證明哪些驗證者組成當前的同步委員會
完全基於 SNARK 的以太坊 —以下 3 項加在一起構成了 「以太坊最終圖景」(中文版) 的一個重要里程碑,即實現極其高效以及去信任的區塊驗證:
· 用於 Verkle 證明的 SNARK - 通過將 Verkle 證明合併進單個 SNARK 中,區塊將包含一個關於它們修改的部分狀態的簡短獨立證明,因此不需要驗證區塊 N-1 的整個狀態來驗證區塊 N 是否正確修改了它。
· 用於共識狀態轉換的 SNARK —從信任最小化的同步委員會轉變為對共識層上發生的所有事情進行完全去信任的驗證
· 用於 L1 EVM 的 SNARK —利用 rollup 團隊在 zk-EVM 上所做的工作,將 zk-EVM 直接集成到 L1 中
· 閱讀關於寫入協議內的 rollup 的帖子
提高 L1 gas 上限 —通過消除目前「每個節點都需要存儲所有東西」的負擔來實現去信任地驗證區塊,這將更容易地形成更大的區塊以獲得更多 L1 可擴展性 (這會自動地加強所有 L2 擴容的效果)
轉向量子安全的 SNARK (如 STARK) —在量子計算機成為一個合理的擔憂之前,使以太坊成為量子安全的是我們長期努力的一部分
· SNARK 基於的密碼學是已知能夠被量子計算機破解的,而 STARK 不是
目標:簡化協議、清楚技術債和通過清理歷史數據限制參與網絡的成本
· 清楚大多數 gas 返還 —所有的 gas 重新定價工作已在柏林昇級完成
· 信標鏈快速同步 —從最近敲定的 epoch 同步 (在大多數共識層客戶端中稱為 "檢查點同步") 而不是從創世開始同步,這方面的所有開發工作已完成
· EIP-4444 規範 —閱讀 EIP 規範了解
歷史數據休眠 —通過讓舊的歷史狀態休眠來降低存儲需求、減少同步時間和代碼複雜性
· 閱讀此條推特長文
· 依賴於 EIP-4444 的實現,即通過其他方式 (如門戶網絡) 來訪問歷史狀態的替代方案
狀態休眠 —關於狀態,修復「一次性支付,數據永久儲存」的問題
· 這個想法主要關於讓狀態未使用的部分自動休眠,只保留一個 verkle tree 根,如果需要的話,用戶可以用它來激活休眠的狀態
· 依賴於這些工作:
- 基本的狀態休眠規範:我們打算如何實現它,請看這個潛在的路線圖 (和其他選項)
- 地址空間擴展:增加地址尺寸大小,從 20 字節增加到 32 字節,以防止衝突,並增加關於狀態週期的數據
- 應用分析:搞清楚它會如何破壞當前的應用/合約,以及這些應用/合約需要如何適應
日誌改革—簡化事件日誌的工作方式,以便更有效地搜索歷史事件
序列化協調—執行層使用 RLP 進行數據序列化,而共識層使用 SSZ,這將會使得逐漸拋棄 RLP,而使用 SSZ
移除舊的交易類型—停止支持舊的交易類型 (參閱 EIP-2718) 以移除客戶端的代碼複雜性 (犧牲一些向後兼容性)
EVM 簡化路線
· 取消 SELFDESTRUCT—這個操作碼是許多問題的根源
- 消除 SELFDESTRUCT 的實用解決方法 解釋了為什麼以及怎麼樣移除這個操作碼
- 相關 EIP:EIP-4758、 EIP-4760 以及討論
· 簡化 gas 機制—涉及移除許多與 gas 相關的 EVM 功能,在此處提及過
· 預編譯 -> EVM 實現—捨棄預編譯合約,採用直接 EVM 實現 (即大型模運算,見 The Splurge)
目標:完善其他東西
所有那些不需要更高優先級的好東西都屬於 The Splurge 這一部分中。最大的一項就是賬戶抽象,但也有對現有內容的小調整。
· EIP-1559 —這個著名的 EIP 帶來了許多好處,而不僅僅是銷毀
· ETHERC-4337 規範 —這個ERC 旨在不修改核心協議的情況下引入賬戶抽象
EIP-1559 的最終形式 —通過使其變得多維度的來完善 EIP-1559,更像一個 AMM 曲線和感知時間的
· EVM 完善路線和 The Purge 中的簡化路線一起形成了 EVM 的最終形式
· EVM 對象格式 (EOF)—一組多個 EIP,允許在部署 EVM 字節碼時對其進行驗證和版本控制。請看這篇解釋文章和推特帖子
· 大型模運算—路線圖中的許多密碼學依賴於大量數字的模運算,這可以直接在 EVM 中更有效地完成
· 進一步完善 EVM—任何其他值得添加以改進 EVM 的東西,或者移除一些東西以消除複雜性
實現賬戶抽象最終形式的賬戶抽象路線。有關以下內容的詳細信息,請參閱 Vitalik 的描述:
· ERC-4337—開發兼容的、實際獲得採用的智能錢包
· 自願對 EOA 賬戶進行轉換—通過一個 EIP,允許普通賬戶不可逆地添加代碼將其轉換為合約,即成為 4337 兼容的智能錢包。
· 寫入協議內—對所有現有賬戶強制進行上述轉換
可驗證延遲函數 (VDFs)—本質上是「非並行的工作量證明」,這將增強 PoS 和其他東西中使用的隨機性
· 參閱這篇貼文,介紹 VDFs 以及其潛在用途
探索針對老舊賬戶的解決方案—拯救這些「塵封的資產」需要花的 gas 成本超過它們本身的價值。在這裡看到一堆想法
原文鏈接
歡迎加入律動 BlockBeats 官方社群:
Telegram 訂閱群:https://t.me/theblockbeats
Telegram 交流群:https://t.me/BlockBeats_App
Twitter 官方帳號:https://twitter.com/BlockBeatsAsia