Ethereum 升級，
難的不是把程式寫完
當簽章變大、網路規則變多、團隊各自實作時，協定升級的真正工作，是把「大家都能跑」變成一條可量測、可協作、可回頭檢查的路。
來源：Zero Knowledge Podcast Episode 395 ｜ 原始發表日期：2026 年 3 月 18 日
SCROLL
當簽章變大、網路規則變多、團隊各自實作時，協定升級的真正工作，是把「大家都能跑」變成一條可量測、可協作、可回頭檢查的路。
來源：Zero Knowledge Podcast Episode 395 ｜ 原始發表日期：2026 年 3 月 18 日
這集是 lean Ethereum 系列的一部分。Will Corcoran 與 Raúl Kripalani 談的重點，不是又多了一個密碼學元件，而是那些元件如何進入真實的客戶端與網路。後量子簽章、SNARK 聚合與 leanVM 的設計，最後都必須被不同團隊各自實作、互相連線、在相同邊界條件下運作。
因此 devnet 的角色不只是「先跑一次測試」。它是一個讓規格、實作與操作假設相遇的環境：誰的訊息格式不同、誰的節點在壓力下掉速、哪一段協商沒有被文件寫清楚，都會在這裡浮現。
訪談的核心提醒：協定升級不是把一份設計交給工程師照做；它要不斷把設計變成跨團隊可重現的行為。
節目討論後量子簽章與聚合設計時，特別指出資料尺寸會直接改變 P2P 網路的工作方式。更大的 payload 不只多耗一點頻寬：它會影響訊息怎麼廣播、節點如何排程、執行層與共識層如何競爭資源，以及慢節點是否因此被排除在外。
這也是為何團隊談到新的 Eth P2P 方向、廣播層、erasure coding 與控制平面。這些是正在研究與迭代的工程選項，不是已經完成的單一升級承諾；它們要先在 devnet 中量測，才能知道哪種拓撲與傳播策略能承受真實條件。
訪談提到 throughput、goodput 與效率等觀察方式。它們的價值不在於挑一個漂亮數字，而在於把「網路看起來正常」拆成可討論的問題：有效資料占多少、重複傳播造成多少浪費、在不同網路條件下哪些節點落後，以及一個改動是否只是把成本轉嫁到某一類參與者。
這種測量也讓升級討論離開抽象宣稱。若一項協議調整能提高理論吞吐，卻讓廣播延遲、頻寬需求或客戶端複雜度失控，它仍不是完成的答案。
從訪談能讀到的，不是一份固定時程，而是一種工作方法：獨立團隊先用共同規格與 devnet 對齊，讓網路、客戶端與研究假設承受壓力，再依證據修正。這同時是技術工作與協作工作；文件、測試網、監測指標和溝通節奏都會決定一個設計能否安全地走向更廣泛部署。
對讀者而言，遇到「某協定即將升級」時，值得追問的不是只有功能清單：它在哪個測試階段？哪些客戶端參與了？測了哪些壓力條件？尚未解決的相容性或資源問題是什麼？這些問題比一個宣布日期更接近升級是否準備好了。
協定升級真正要完成的，
不是一段新程式，
而是讓不同人、不同客戶端與不同網路條件下，
都能反覆得到同一個可檢查的結果。
選完之後，分享你的觀點
Zero Knowledge Podcast Episode 395 保留 Will Corcoran 與 Raúl Kripalani 對 devnet、升級協作、P2P 網路與 Lean Ethereum 的完整討論。
閱讀完整文章 →