觀點 | 以太坊 1.x：主網升級路線圖草案
編者注：本文為 cdetrio 於 2018 年 11 月 24 日在 ethereum-magicians.org 上釋出的文章。近期，一些社群成員已經表示了對這些想法的支援，並選擇了“以太坊 1.0”而不是“1.x”來概括這種思路。
本文沒有獲得其他核心開發者的預先審閱或反饋意見，純屬我個人對 1.x 的看法。如果存在任何錯誤或誤解，責任均由我個人承擔。
摘要
以太坊 1.x 是近期以太坊主網的一系列全面升級的代號。1.x 採用的一系列升級將對主網進行重大改造，與此同時，以太坊 2.0 （又名 Serenity）正在進行原型設計與開發。1.x 計劃包含三個主要目標：（1）通過優化客戶端大幅提高區塊的 gas limit，從而增加每秒交易吞吐量，提高主網的可擴充套件性; （2）通過“儲存空間租賃”的方式降低並限制磁碟空間要求，確保全節點可持續執行; （3）通過升級虛擬機器（包括 EVM 1.5 和 Ewasm）改善開發者體驗。
背景介紹
“以太坊 1.x”的想法源自 Devcon4 期間核心開發者之間的討論。在討論 1.x 之前，以太坊 1.0 的路線圖上僅有幾處針對主網硬分叉（例如拜占庭和君士坦丁堡）提出的相對保守的變更。在拜占庭硬分叉前後（2018 年 10 月），Casper-FFG 正處於開發階段，它引入了混合工作量證明（PoW）與權益證明（PoS）共識機制的區塊獎勵，是主網的一次重大變革。2018 年 6 月，ofollow,noindex">Casper-FFG 被捨棄 ，PoS 的研究工作轉向了開發“信標鏈（beacon chain）”，該鏈將作為獨立於以太坊 1.0 主網的新鏈釋出。這次開發重點的轉移令以太坊 1.0 客戶端的開發人員迷失了方向，以太坊 2.0 顯然還要經歷一段漫長的開發週期，我們不禁開始產生疑惑，這段時間內我們能對主網做些什麼？
以太坊 1.0 客戶端的維護人員有兩個選擇：一種是隻對主網進行簡單保守的改進，不作任何重大變更（將大刀闊斧的改進任務留給以太坊 2.0 ）。另一種是對以太坊 1.0 的主網進行重大改革，同時將以太坊 2.0 的研發交給另外的團隊進行。而這後一種選擇則被稱為 1.x 計劃。
以太坊 1.x 計劃的制定
在宣佈 1.x 計劃之前，一些核心開發者希望能有充足的時間制定詳細的提案，並收集具體資料來回答相關問題（例如，在對客戶端進行簡單的優化後，可擴充套件效能立即提升到什麼程度？2 倍，5 倍，還是更高？）。因此，核心開發者組成的工作小組希望在宣佈計劃之前有機會私下調整以太坊升級提案 （EIP），但是社群希望能儘早對 1.x 的初步計劃進行公開討論。因此，核心開發小組制定出了一個可靠的 1.x 分步計劃固然不錯，但這個計劃最好從一開始就在一個包容、公開、透明的環境中制定 。
如果制定計劃的過程從一開始就保持公開透明，還是會有不足之處，因為初期披露的只是一個半生不熟的計劃，所以無法回答公眾的所有疑問，就會出現含混不清的表述，從而引發其他開發者和社群成員的爭議和反對。而且 1.x 計劃是對主網進行大幅度改進，難免會引起爭議，因此其核心開發小組不願意將一個不成熟的計劃公之於眾 。
核心開發者對於 1.x 計劃的開發程序也是難以評估的。1.x 改進計劃不僅顯示出了技術和治理上的野心，而且需要付出巨大的努力付諸實現，推進計劃的動力還可能會因為早期的爭議和阻力而受到削弱。簡單一些的解決方式就是避免爭議，將那些雄心壯志留給以太坊 2.0 去實現。由此可見，對主網進行重大改革將是一個巨大的挑戰。
接下來，本文將概述 1.x 計劃的三個主要目標。第一個和第二個目標（可擴充套件性和可持續性）可以說是相互關聯的，而第三個目標（虛擬機器升級）則是獨立的。
1. 優化客戶端，提高可擴充套件性
提高主網的交易吞吐量是 1.x 計劃的第一個目標。交易吞吐量由區塊的 gas limit 決定，目前在 800 萬左右。礦工們會對每個區塊進行投票，決定是提高還是減少區塊 gas limit。如果 gas limit 過高，就會產生副作用，即，挖到叔塊的機率會增加。叔塊率過高的壞處在於會導致礦池中心化（主要是那些叔塊率高的小礦池，導致它們的收入降低，無法與叔塊率較低的大礦池競爭）。因此，礦工不能隨意提高 gas limit ，否則就會降低有競爭力的礦池的多樣性。
一個好訊息是，最近發現有一種客戶端優化或能在大幅增加區塊 gas limit 的同時保持較低的叔塊率。這種優化改進了 Parity 廣播區塊的方式（是turbogeth 創始人 Alexey Akhunov 發現的）。 現在 Parity 在廣播區塊前都會仔細校驗區塊的工作量證明與交易流程。經過這種優化之後，Parity 只會校驗工作量證明，然後在處理交易時開始廣播區塊。這種優化可能會大大降低網路的叔塊率，使礦工能夠大幅提高區塊的 gas limit（注意還有另一種辦法：如果不將區塊 gas limit 提高 2 倍，也可以把計算操作碼重新定價為原來的 1/2）。
那麼通過這種優化，我們可以將區塊的 gas limit 提高多少呢？目前還是一個未知之數，所以我們不能高興得太早。核心開發者希望通過網路模擬和收集更多的資料來解答這個問題。然而，要解答這個問題，有許多複雜因素（例如全節點之間的網路拓撲結構和傳播延遲）尚待研究。除了這這種優化方式之外，還有一些簡單的方法可以優化區塊廣播。
除了簡單的優化之外，開發人員還在研究一些更加激進的優化方法，以增加主網的吞吐量。一種方法是實現交易的並行處理，緊接著之前 EIP 中斷的地方開始。另一種大幅提升主網可擴充套件性的方法是改變 PoW 協議，很早以前在分片 FAQ 中提到過：“Bitcoin-NG 的設計能夠......將交易量的可擴充套件性恆定提高 5-50 倍 ...... （這種方法）不會與分片相互排斥，而且兩者可以同時執行。”
因此，一些簡單的優化可能會立即提高主網的吞吐量（隨便猜測一下，可能有 2-5 倍吧）。通過對協議進行更全面的修改，也許可以將主網吞吐量提升 50 倍（這可不是我猜出來的！而是在分片 FAQ 上看到的）。
但是，將吞吐量提高 2 至 5 倍也會將主網當前的問題放大 2 至 5 倍。最大的問題是磁碟空間的需求增大，如果我們要提高主網吞吐量，那麼必須首先解決磁碟空間的問題。
2. 減少磁碟空間使用量，實現可持續網路
減少磁碟空間使用量的長期解決方案，儲存租金（storage rent），是 1.x 計劃中最具爭議的部分。關於實施儲存租金的必要性，存在著許多爭論和不同的觀點。一方面，一些 1.0 客戶端的維護人員認為狀態資料已經增長得太快，即使不提升吞吐量，也需要作出改進。這些核心開發者認為，這樣下去，以太坊主網最多還能維持三年。如果在此之前沒有做出任何有效的措施來減少磁碟空間的負擔，那麼以太坊將會走向滅亡。
另一方面，專注於研發 2.0 擴充套件計劃的研究人員認為，新的硬碟驅動器足以應對目前 1.0 主網狀態資料的增長率，直到 2.0 推出，然後使用者就可以從 1.0 的合約遷移到 2.0 中的合約。 他們還認為，在主網上作出大幅度的變更會違背使用者對 1.0 合約的期望，而且 1.0 網路會在接下來三年中產生 70G 的狀態資料也沒什麼大不了（我查了一下，目前 的狀態資料大小大約是 7 GB）。 此外，在以太坊 1.0 上引入租賃機制可能會使使用者感到困惑，因為它可能與 2.0 中引入的租賃機制不同。
有一個儲存租賃的替代方案是無狀態客戶端 ，但要想把無狀態客戶端付諸實現，那麼就得把狀態樹的格式更改為適用於無狀態範例的格式（即，客戶端需要從當前的十六進位制字首樹切換到二進位制或稀疏默克爾樹）。核心開發者認為從有狀態轉換為無狀態是對 1.0 客戶端的巨大改變，實現起來要複雜得多。因此，比較簡單的方法的是保持當前有狀態的十六進位制字首樹，然後加入儲存租賃。
一個好訊息是，也可以採用一些簡單，無異議的措施來減少所需的磁碟空間。PéterSzilágyi（go-ethereum 創始人）提出了減少磁碟空間使用量的三條措施中的前兩條（簡要說明一下這三條措施：1. 刪除過去的區塊；2. 刪除過去的日誌；3. 刪除狀態，即儲存租賃）。目前， geth 節點同步需下載超過 100gb 的資料，其中大部分資料是以前的區塊和日誌。實際帳戶狀態只佔總資料的一小部分。為了使資料條理更清晰，以前的區塊和日誌應該儲存在其他某個地方方便以後使用，而不應該儲存在佔據網路主導地位的公共全節點上。相反，全節點將只儲存一些最近的區塊和日誌記錄，大概也就是幾個月內產生的資料。
這兩個簡單的變更（刪除以前的區塊和日誌）只會破壞一些希望通過全節點來檢索和查詢過去所有日誌的 dApp。這些 dApp 將停止使用純節點（它們將要求使用者執行更加儲存密集型的 Archive 節點（直譯為歸檔節點），或查詢能檢索日誌的服務）。對大多數使用者來說，資料同步將變得快速而輕鬆（就像早期年輕且輕便的以太坊主網），但這只是一個臨時性的修復，隨著帳戶數量的不斷增長，同步資料將逐漸變得緩慢，負擔也變得更重。
抑制帳戶數量增長的解決方案是儲存租賃。
在多個有潛力的儲存租賃提案中，它們在使用者友好性和可行性（核心開發者友好性）方面存在差異。最簡單的方案對使用者是不夠又要的。例如，直接刪除不支付租金的帳戶，不向使用者提供任何方式來“復活”或反對刪除他們的帳戶。相比之下，那種使用者以後可以恢復未支付租金的帳戶的租賃機制雖然對使用者更有利，但實施起來更復雜。
儲存租賃的另一個問題是多個使用者簽訂合約時的激勵問題。例如，一個代幣合約涉及到若干持有代幣的使用者，但簡單的租賃機制要求合約支付租金。這時就沒有相應的激勵機制使得單個使用者願意為合約支付租金，每個代幣持有者都希望由其他使用者來支付合約的租金。解決這一激勵問題需要改善合約儲存的所有權模式。
儲存租賃提案是 1.x 計劃中最難的部分。在治理上也是有爭議的，因為對使用者和開發者來說，儲存租賃向主網引入了一個全新的模式，而且從技術上說，執行起來非常複雜，尤其是要提供使用者友好型的租賃機制的話。因此，我們的目標是制定一個詳細的提案，儘可能讓大多數人滿意（從核心開發者到 dapp 開發者，再到 dapp 使用者）。
3. 升級 VM，改善開發者體驗
升級 VM 是 1.x 計劃中完全獨立於前兩個目標的第三個目標。EIP 615 提議升級 EVM。這個EIP 也被稱為“EVM 1.5”，因為它被認為是 EVM 的近期改進，相對於長期改進的Ewasm （又名“EVM 2.0”）。
Ewasm 最初被設計為與 EVM 向後相容（即 Ewasm 合約可以與 EVM 合約互動），以便運用在主網上。後來，Casper-FFG 遭到反對，PoS 路線圖轉向Ethereum 2.0 ，在階段 0/1 開發一條信標鏈，在階段 2 開發基於 Ewasm 的執行引擎。但是因為 2.0 上的執行引擎是在一條獨立的鏈上而不是在 1.0 的主鏈上，所以 2.0 Ewasm 就不需要與 EVM 向後相容。 這意味著“Ewasm 2.0”設計是一個懸而未決的問題，而且可能與“Ewasm 1.0”（即當前與EVM向後相容的 Ewasm 設計）大不相同。
Ewasm 的 1.x 計劃意味著要追求最初的目標：適用於主網並能與 EVM 向後相容的 Ewasm 版本。未來的提案會詳細介紹在主網上引入 Ewasm 的多階段路線圖。
結論：1.x 路線圖還說不上完備
上面的 1.x 計劃只是一個不成熟的綱領。目前還無法迴應所有相關的問題，仍需要進行研究來收集有關主網可擴充套件性潛力的資料。此外，我們還必須寫清楚讓全節點在中期和長期中可持續執行所需的革命性變更，出版詳盡的提案以供社群參考。
原文連結:https://ethereum-magicians.org/t/ethereum-1-dot-x-a-half-baked-roadmap-for-mainnet-improvements/1995
作者:cdetrio
翻譯&校對:楊哲 & 閔敏