以太坊 2030 願景：運算走向密碼學證明，但誰來驗證結果？

Vitalik Buterin 在 9 月 27 日提出的願景，描述了以太坊從一個每個驗證者都重複大部分工作的系統，轉向一個可以對數據進行抽樣、並能用簡潔證明檢查執行的系統。其中一部分，PeerDAS，已經上線。更大的執行轉變仍在開發中。證明可以確立某項計算遵循了指定規則，但用戶仍然需要數據、一種提交交易的方式，以及一個決定誰的結果成為最終結果的協議。

標題問題有兩個答案。證明者產生密碼學證明；驗證者，可能是任何運行相關軟件的驗證節點，根據規則和公開輸入檢查該證明。以太坊基礎層 zkEVM 的路線圖表示，驗證應該比重新執行每筆交易便宜得多。但判斷一個證明是否可靠，並不能單獨解決交易數據是否可用，或運營者是否可以扣留用戶交易的問題。

Buterin 的9 月 27 日文章「The cryptographic world computer」，將目標描述為區塊鏈、密碼學隱私與驗證，以及去中心化鏈下組件的結合。他將下載並重新執行的舊模式，與節點抽樣數據並驗證證明的模型進行對比。他描述了對共識和區塊構建的其他可能改變。這是個人的技術願景，不是所有以太坊客戶端團隊批准的最終升級規範。

現有事物與願景之間的區別很重要。根據以太坊基金會 2026 年 2 月的協議更新，PeerDAS 隨 Fusaka 於 2025 年 12 月到來。基金會表示，驗證者現在抽樣 blob 數據，而不是下載全部數據。全網轉向驗證基礎層區塊的簡潔執行證明，並未被描述為已經部署。聽到以太坊「將在 2030 年驗證證明」的讀者應該問：哪個證明、它涵蓋誰的計算，以及哪些參與者可以獨立測試它。

PeerDAS 檢查數據訪問，而非每項計算

已經部署的部分是PeerDAS，即點對點數據可用性抽樣。Rollup 將交易數據放入以太坊 blob 空間，以便其他參與者可以檢索足夠信息來重建狀態，並讓運營者遵守規則。讓每個節點下載每個 blob 的舊方法，會使更大的數據量對普通驗證者來說變得昂貴。抽樣要求節點根據密碼學承諾檢查小塊數據，同時網絡分發足夠的編碼塊用於重建。

以太坊的解釋稱，擴展後的 blob 數據被分為 128 列。普通節點加入至少 8 個隨機選擇的列子網。8 除以 128 是擴展數據的十六分之一。編碼增加了冗餘，因此根據文檔描述，該數量相當於原始數據量的約八分之一。這些數字指的是默認節點的數據工作量，而不是聲稱一個節點可以親自以八分之一的成本持有每個 rollup 的完整歷史。

Reed-Solomon 風格的編碼會產生冗餘資料片段，而密碼學承諾可協助節點檢查被抽樣的片段是否屬於所公告的內容。抽樣在參與節點之間提供機率性的可用性保證。它並不能取代執行驗證。一批完全可用的交易仍可能包含無效的狀態轉換。同樣地，若重建帳戶狀態所需的資料在可用性保證之外被隱匿，那麼關於狀態轉換的有效證明也不足以讓使用者重建帳戶狀態。

以太坊基金會表示，Fusaka 使理論上的 blob 容量增加了八倍。理論上這個詞很重要：實際的持續吞吐量取決於預定的參數增加、網路狀況以及 rollup 的使用情形。Crypto.news 已經解釋了 rollup 如何使用以太坊的資料層。Buterin 的新文章將 PeerDAS 視為邁向一個驗證更多、重複更少的系統的第一個可見步驟；它不應被重新包裝為最終的執行證明升級。

證明者做繁重的工作；獨立節點進行檢查

在以證明為基礎的執行模型中，仍然必須有人執行交易並建構關於結果的證據。該方可能會使用昂貴的專業硬體和軟體。簡潔證明讓驗證者能以低得多的成本檢查所聲稱的狀態變更是否遵循程式以及依協議規則所承諾的輸入。數學檢查並不需要驗證者僅因為證明公司生成了證明就信任它。

該陳述附帶一些條件。驗證者必須執行一個健全的證明系統，並具備正確的驗證金鑰、公開輸入以及商定的執行規則。有缺陷的電路可以完美地證明錯誤的陳述。客戶端實作中的錯誤可能會接受一個本應拒絕的證明。一個能在缺乏穩健控制的情況下更改驗證者程式碼的升級金鑰，可能會削弱該保證。在實際運行的協議中，獨立實作與審查與快速生成證明同樣重要。

以太坊的L1 zkEVM 路線圖頁面描述了一個未來，其中節點檢查區塊執行的證明，而不是重複每一筆交易。其既定目標是降低驗證的資源成本。如果證明驗證在可取得的硬體上仍然實用，這將使更多人更容易檢查區塊。這並不意味著每個家庭都能產生區塊證明，也不意味著證明產生將會平均分布。

Crypto.news 報導了圍繞證明的硬體競賽。有用的區別在於誰能及時為鏈生成證明，以及誰能廉價地驗證證明。證明生成可能會集中在擁有專業硬體的公司手中，但這不會自動讓這些公司能夠偽造有效的狀態轉換。它仍可能引入活性依賴：如果能夠足夠快速地產生證明的參與方太少，即使證明系統在數學上仍然健全，區塊或最終性也可能會變慢。這與接受無效證明的風險不同。

因此，驗證問題既有人類的答案，也有數學的答案。開發者設定電路，研究人員對其進行審計，客戶端團隊實作它，節點營運者運行驗證者，而參與者決定是否接受協議升級。Buterin 可以提出一個方向。他無法獨自使未來的驗證者對網路而言安全或強制。

三個承諾經常被折疊進「證明」這個詞中

以一個透過 rollup 發送付款的使用者為例。該交易必須被包含在一個有序批次中。該批次的資料必須在 rollup 所選模型下可用。最後，所產生的狀態變更必須遵循其規則。排序、可用性與正確性是各自獨立的承諾。正確性證明針對指定的計算處理最後一項。PeerDAS 處理以太坊 blob 資料的可用性。排序器或區塊建構機制則影響哪些交易被包含以及以何種順序被包含。

Crypto.news 將排序器視為一個獨立的控制點進行了審視。一個完全有效的證明可以證明某個批次是按照規則處理的，即使其營運者排除了某個特定客戶的交易。根據該 rollup 的設計，使用者可能有逃逸或強制納入的路徑，但證明本身並不強制要求公平的存取。排序器還可以在仍產生有效狀態轉換的同時重新排序交易。被證明的陳述不應被誤認為是使用者希望從市場獲得的所有屬性。

資料方面同樣容易被模糊。以太坊的 validium 文件描述了使用有效性證明但不將交易資料發布到以太坊主網的系統。根據驗證者的判斷，它們的執行可能是正確的，但資料可用性故障可能阻止使用者重建狀態或如預期般提款。一個在以太坊上發布足夠資料的以太坊 rollup 具有不同的可用性模型。將兩者簡單地稱為「ZK」掩蓋了使用者在沒有營運者的情況下恢復帳戶狀態能力上的關鍵差異。

最簡單的測試是一個三欄的心智檢查清單。問誰能將交易放入批次中。問重建餘額所需的資料可以從哪裡檢索。問哪個合約或節點驗證狀態正確性的證明。如果一個專案只回答了第三個問題，它就沒有回答前兩個。這就是為什麼 Buterin 的文章在討論密碼學的同時也談到區塊構建和網路資料分發，而不是用一個神奇的證明來取代整個系統。

基礎層無法從現有 rollup 借用每一個屬性

ZK rollup 已經在其自己的合約和規則下向以太坊提交有效性證明。以太坊關於 ZK rollup 的文件描述了營運者為批次建立證明，以及驗證者合約僅在驗證後接受新的狀態根。這對於證明計算是有用的先例。這並不意味著以太坊的基礎層已經將所有執行驗證轉移到此類證明上。

範圍不同。一個 rollup 在其自己的虛擬機和合約下證明自己的狀態轉換，而以太坊的基礎層驗證者則必須以客戶端團隊接受的方式檢查協議的區塊執行。rollup 的自訂邏輯與以太坊主網執行規則之間的不匹配，不是一個更快的證明器可以隨意消除的細節。證明系統還必須在協議升級、新交易類型和對抗性輸入中保持穩健。

一個應用可以將其算術外包給協處理器並提供帶有證明的結果，但基礎鏈仍然決定是否接受公開輸入、儲存承諾並結算最終狀態。一個應用或許能夠選擇自己的證明器設計；而基礎層規則需要跨客戶端和驗證者的廣泛協調。Buterin 的「密碼學世界電腦」這一說法作為架構方向是有用的，但並非承諾單一證明服務將運行整個以太坊。

有一個明顯的矛盾值得解決。如果節點停止重新執行，那麼任何人如何在被證明的計算中發現錯誤？一個答案是開發者可以運行獨立的完整執行，並在開發期間和部署後將其與證明結果進行比較。另一個是多個證明實現和電路的形式化檢查。確切的以太坊設計尚未最終確定。一個減少所需重新執行的協議並不禁止人們執行額外的檢查；它改變的是每個普通驗證節點為達成共識必須做的事情。

基金會的 九月協議優先事項更新將 L1 zkEVM 和形式化驗證視為主要工作流。這是活躍工程的證據，而非確定的發布日期。安全標準很高，因為基礎層證明系統中的錯誤將影響其他應用所依賴的基礎。

證明可能會改善驗證，而狀態問題卻在增長

Buterin 將對一個非常龐大的共享狀態的存取列為一個特別困難的未解決問題。Crypto.news 審視了他關於基於證明的記憶池擴展的獨立提案，該提案針對的是與最終狀態執行不同的瓶頸。一個證明可以證明一個計算，但證明者必須獲取該計算所依賴的資訊：餘額、合約儲存和其他帳戶狀態。如果許多交易同時觸及相同的狀態，將計算拆分到多台機器上就變得更加困難。來自一個帳戶的付款和觸及流動性池的兌換無法從不一致的快照中同時最終確定。

這篇文章指出，應用程式可能會將排序與非交換性狀態變更放到鏈上，同時在納入之前聚合其他計算。這是一種架構上的誘因，而非今日對開發者具約束力的規則。「非交換性」意味著改變順序就會改變結果。兩個人從同一個稀薄資金池購買，可能因為處理順序不同而得到不同價格。沒有任何證明能讓這兩筆訂單在經濟上等價。

這是對「免費擴容」這種過度簡化承諾的有用制衡。當任務能被安全地分離時，平行處理會更容易。共享狀態會產生依賴關係。一個證明者可以快速執行許多獨立計算，卻仍須等待取用有爭議的狀態或區塊建構者的排序選擇。單單提升證明速度，並不能解決資料庫爭用、審查，或讓足夠資訊提供給其他參與者的成本問題。

在 Buterin 看來，一個更強大的去中心化中間層可以平行處理工作，並在某些情況下保護關於請求來源的元資料。這類基礎設施或許能改善效能或隱私，但它必須明確規定資料如何分散、誰可以加入，以及哪些故障有逃逸路徑。使用者付款的隱私並不是使用有效性證明的自動結果。公開輸入、錢包活動與網路元資料仍可能洩露資訊，除非系統也保護這些部分。

獨立性可以在最終分叉之前被衡量

「任何人都能驗證」有其實際條件。一個普通節點需要驗證器程式碼、相關的公開輸入、與鏈上已接受狀態的連線，以及足夠的處理能力，以便在協議時限內完成檢查。如果一個證明在一台普通機器上只需幾秒就能檢查，卻要在昂貴硬體上花數小時才能產生，該系統或許能達成廣泛驗證，但生產卻很狹窄。就正確性而言，這可以是可接受的工程取捨，前提是生產者的停機不會成為結算的永久阻塞。

這個實驗在概要上很直接。讓來自多個客戶端團隊的驗證器軟體，對同一個有效區塊證明執行驗證，並確認它們接受該證明。提供被改動的公開輸入，並確認其被拒絕。詢問不同的證明團隊是否能為相同規則產生被接受的證明、他們能多快做到，以及各自需要什麼硬體。在公開測試網路上於高負載下重複這項實驗，會比在實驗室展示一個快速證明更能說明準備程度。確切的以太坊接受標準仍取決於協議工作；這些是可觀察的問題，而非官方的通過門檻。

證明產生還有另一種失效模式，是有效性檢查本身無法捕捉的。證明者可能拒絕為某個被提議的區塊產生證明。驗證者無法接受一個尚未送達的證明。設計可以透過允許多個獨立證明者、備援執行路徑、調整時序或其他機制來處理這點。這項選擇將影響複雜度、成本與達到最終性的時間。以太坊目前的基礎層規則，不應僅因為某份路線圖說證明驗證是目標，就被描述為已經選定了那些未來解決方案之一。

獨立性也意味著使用者能取得所需資訊，以驗證自己對資產的主張。一個證明某個狀態根遵循程式碼的證明很強大，但若使用者無法從自己的帳戶資料重建通往該狀態根的路徑，那麼在實際餘額檢查上，他們仍然依賴中介者。PeerDAS 讓每個節點對 blob 資料可用性的要求降低，同時依賴整個網路的分發與抽樣。保存在其他地方的應用程式資料，需要有自己的可用性保證。鏈上的證明驗證器無法強迫外部營運者發布被扣留的紀錄。

最後，被驗證的程式必須是使用者所認為的那個程式。驗證器程式碼的公開雜湊、有文件記錄的升級流程，以及對電路行為的獨立測試，能讓外部人士比較所宣稱的規則與節點實際執行的內容。形式化驗證可以縮小邏輯錯誤的機率，但它同樣始於由人類撰寫的規格。可檢查的結果並不是「密碼學解決了信任」。而是當某項被指明的聲明其證據無效時，該聲明可以被獨立拒絕，而不必讓每個節點都付出產生該證明的全部成本。

Hegota 是一個標記，而非 2030 年發布的保證

Buterin 提到 Hegota，一個計畫於 2027 年的分叉，可能是最後一個其組成部分對 2015 年的以太坊觀察者而言仍屬熟悉的升級。在他的敘述中，後續工作將涉及遞迴 STARKs、形式化驗證、優化共識與量子安全。Crypto.news 報導了另外的 2029 年量子目標，作為一項規劃目標。無論是該文章或某個目標日期，都無法證明每個提議的組成部分都會如期準備就緒並被採用。

以太坊升級需要規格、客戶端實作、測試網路、安全審查以及參與者之間的協調。草圖地圖是一份研究與候選里程碑的地圖，而非鏈上頒布。人們可以透過查看 Fusaka 發布與當前節點規則來驗證 PeerDAS 已部署。人們無法透過查看一篇文章的藍色 2030 年欄位來驗證未來的通用基礎層 zkEVM。證據將首先出現在公開規格與測試中，然後才是具體的分叉計畫與生產環境啟用。

支持 Buterin 做法的論點很強。如果驗證變得便宜，且資料能被安全地取樣，更多使用者便能獨立檢查一個更大的系統，而無需購買與其所有運算和資料成比例的機器。挑戰同樣真實：證明堆疊必須安全、具競爭力地產出，且速度足以維持系統運作，同時資料與排序仍須保持可存取。一個驗證便宜但只有單一不可或缺的證明者或排序者的網路，可能仍然脆弱。

這篇文章並未解決誰將建構每一個證明，或哪個證明系統會勝出。它確實指出了一項對使用者至關重要的測試：一位普通的獨立參與者能否拒絕一個壞結果、取回了解自身狀態所需的資料，並在任何單一營運者存在的情況下提交交易？每個答案都需要一套獨立的機制。密碼學檢查之所以強大，正是因為它可以由未從事繁重工作的人重複進行。

值得關注的重點

• L1 zkEVM 規範。尋找一個具體的驗證器、公開輸入格式，以及各客戶端普遍接受的執行規則。
• 證明器多樣性。多個獨立實作與實測硬體需求，將檢驗證明生成是否存在單一瓶颈。
• PeerDAS 測量。在 2025 年 12 月上線後，隨著參數增加，檢查 blob 吞吐量與節點頻寬。
• Hegota 決策。在草案路線圖中，最終分叉範圍比候選功能更為重要。
• 資料與排序保障。檢視 rollup 與未來基礎層設計是否維持獨立重建與交易納入。

常見問題