"無信任性"、"通過離開測試"和"自我主權"的一個重要且長期被低估的方面是協議的簡單性。 即使一個協議是超級去中心化的，擁有數十萬個節點，並且具有49%的拜占庭容錯能力，節點完全用量子安全的peerdas和starks驗證所有內容，但如果該協議是一個繁瑣的、數十萬行代碼和五種博士級別的密碼學的混亂，那麼最終該協議將無法通過這三個測試： * 它不是無信任的，因為你必須信任一小部分高僧告訴你該協議擁有什麼屬性 * 它不通過離開測試，因為如果現有的客戶端團隊消失，新的團隊很難達到相同的質量水平 * 它不是自我主權的，因為即使是最技術性的人也無法檢查和理解這個東西，它就不完全屬於你 它的安全性也較低，因為協議的每個部分，尤其是如果它可以以複雜的方式與其他部分互動，承擔著協議崩潰的風險。 我對以太坊協議開發的一個擔憂是，我們可能過於急於添加新功能以滿足高度特定的需求，即使這些功能使協議膨脹或添加整個新類型的互動組件或複雜的密碼學作為關鍵依賴。這對於短期功能增益來說可能很好，但對於保持長期自我主權和創造一個超越帝國和意識形態興衰的百年去中心化超結構來說是非常具破壞性的。 核心問題是，如果從"對現有協議的變更有多大"的角度來評判協議變更，那麼保留向後兼容性的願望意味著添加的頻率遠高於刪除，協議不可避免地隨著時間的推移而膨脹。為了對抗這一點，以太坊開發過程需要一個明確的"簡化" / "垃圾回收"功能。 "簡化"有三個指標： * 最小化協議中的總行數。一個理想的協議應該能夠適合在一頁上——或者至少幾頁上 * 避免對根本複雜的技術組件的無謂依賴。例如，安全性僅依賴於哈希的協議（甚至更好：僅依賴於一個哈希函數）比依賴於哈希和格的協議要好。引入同態映射是最糟糕的，因為（對於那些真正聰明且努力的極客來說，抱歉）沒有人理解同態映射。 * 添加更多的_不變性_：協議可以依賴的核心屬性，例如EIP-6780（自毀移除）增加了每個槽最多可以改變N個存儲槽的屬性，顯著簡化了客戶端開發，而EIP-7825（每交易的燃料上限）增加了處理一筆交易的成本上限，這對ZK-EVM和並行執行有很大幫助。 垃圾回收可以是零散的，也可以是大規模的。零散的方法試圖對現有功能進行簡化，使其更簡單且更有意義。一個例子是Glamsterdam的燃料成本改革，使許多之前任意的燃料成本依賴於少數幾個明確與資源消耗相關的參數。 一個大規模的垃圾回收是用PoS取代PoW。另一個可能會作為Lean共識的一部分發生，開放空間以同時修正大量錯誤（ ）。 另一種方法是"Rosetta風格的向後兼容性"，其中複雜但使用不多的功能保持可用，但被"降級"為不再是強制協議的一部分，而是成為智能合約代碼，因此新的客戶端開發者不需要擔心它們。例子： * 在我們升級到完整的原生賬戶抽象後，所有舊的交易類型都可以被退役，EOA可以轉換為智能合約錢包，其代碼可以處理所有這些交易類型 * 我們可以用EVM或後來的RISC-V代碼替換現有的預編譯（除了那些_真的_需要的） * 我們最終可以將虛擬機從EVM更改為RISC-V（或其他更簡單的虛擬機）；EVM可以在新虛擬機中變成一個智能合約。 最後，我們希望不再讓客戶端開發者感到需要處理以太坊協議的所有舊版本。這可以留給在docker容器中運行的舊客戶端版本。 從長遠來看，我希望以太坊的變更速度能夠放慢。我認為出於各種原因，最終這_必須_發生。這前十五年應該部分被視為一個青春期階段，我們探索了許多想法，看看什麼有效，什麼有用，什麼沒有用。我們應該努力避免那些不有用的部分成為以太坊協議的永久拖累。 基本上，我們希望以這樣的方式改善以太坊：