本文的目標是概述Paradigm Reth 團隊[4]對於布拉格硬分叉的看法，布拉格（Prague）是坎昆之後的下一個EL 硬分叉，以及我們2024 年「EL 核心發展」計畫的概況。以下觀點正在發展中，僅代表Reth 團隊目前的觀點，不一定代表更廣泛的Paradigm 團隊。
我們認為布拉格硬分叉可能在2024 年第三季在以太坊測試網路上實現，年底在主網上實現。
它應該包括：
任何與質押相關的EIP，例如EIP-7002，它使重質押(re-staking)和無信任質押池成為可能。
獨立的EVM 更改。
我們願意與任何希望進一步研究布拉格或其他未來EL 硬分叉的團隊合作，樂意指導或提供指導以修改Reth 程式碼庫的位置。
支持:
我們認為以下EIP 必須優先考慮：7002[5]6110[6]2537[7]。
我們支持EOF，如規範[8]中所述，但希望盡快確定範圍，並建立一個元EIP，承諾遵守該範圍。
我們願意增加EIP-4844 最大Blob Gas[9] 的版本。我們對正確的數字沒有看法，但我們邀請數據人員與我們合作調查這個問題。
我們願意發布EIP-7547：包含列表[10]的版本，以幫助基礎層抗審查。
不支援:
我們不支持在布拉格中使用Verkle Tries[11]，但我們支援客戶端團隊從2024 年第二季開始努力實現它，並承諾在2025 年中期/晚期在大阪發布。
我們不認為應該增加L1 執行Gas 限製或合約大小，但我們邀請資料人員與我們合作調查對網路的影響。我們願意修改我們的看法，因為過去的測試表明Reth 節點可以處理增加的負載而沒有問題。
我們認為錢包/帳戶抽象化EIP 需要更多相互對抗的測試，以更好地理解權衡空間。如果它們不是相互排斥的，那麼我們願意在未來部署多個AA 相關的EIP。
如果社區對傳聞中[12]的NSA[13]後門[14] OK ，我們可以接受EIP-7212（secp256r1）。
其他路線圖主題：我們對CL EIP 或CL/EL 分叉的耦合沒有具體看法，但EIP 7549[15]和7251[16] 似乎很有前景。我們也希望在EL 方面盡可能為PeerDAS 的工作做出貢獻。我們希望暫時避免引入SSZ 根（EIP 6404, 6465, 6466）。最後，我們注意到為過期的Blob、歷史和狀態提供長期資料存檔解決方案的機會，因為EIP-4844[17] 和EIP-4444[18]都沒有指定這一點，以及以太坊是否願意提供這樣的解決方案。
以下是推理。
支援
抽像地說，我們支持1)進一步彌合CL 和EL 之間的差距，2) EVM 修改可以作為單人工作執行，並且可以在隔離和並行測試。
EIP-7002[19]
這個EIP 透過使EL 側的智能合約控制CL 側的一個或多個驗證者，解鎖了無信任的重新質押和質押池。從我們的角度來看，這是一個不需要思考的EIP，因為至少它將使現有的質押池能夠從實施其提款的智能合約中去除一層中心化。
在EVM 實作中引入有狀態的預編譯是我們需要在EVM 實作中捕獲的新抽象，但除此之外，我們認為這是一個可以直接執行的EIP。
EIP-6110[20]
這個EIP 在EL 狀態中引入了存款，簡化了CL 上需要進行的狀態管理。在實施上，這類似於追蹤CL 提款，因此總體上我們認為這也是一個容易實現且獨立的EIP 。
EIP-2537[21]
現在外面有多個BLS12-381 的實現，它是許多SNARKs、BLS 簽章演算法和EIP-4844 中經常使用的曲線。我們認為實現複雜性低，因為它只是透過預編譯介面公開了曲線的驗證演算法。可能我們還想要一個Hash 到BLS12-381 曲線的預編譯。
EOF[22] 以太坊物件格式
TL;DR：支援一個Solidity 和Vyper 將採用的範圍明確的版本。使分析更容易的程式碼格式和驗證調整是一個不需要思考的事情，我們建議進一步修剪。
好處：
只有EVM 的更改，可以透過以太坊/tests 進行測試，並由一人實施。
做Vyper 和Solidity 想要的EVM 變更！
有助於性能和提高合約限制大小。
透過EVM 在運行時消除了對字節碼的分析的需要，當沒有快取時，這可能佔用時間的50%，隨著合約大小的增加而增加。
可以部分載入程式碼，有助於執行大型合約。
Devex：將允許在Solidity 中使用dupN/swapN 修復“Stack Too deep”，以及其他工具改進。
未來驗證：可以安全地引入新功能到L2，並且工具將知道什麼是相容的。
不足：
變化了目標。
沒有支持者極力推動它的加入。
仍然需要支援舊代碼
直到被採用之前，以太坊主網和其他EVM 鏈之間會有暫時的分歧。
我們認為以下EOF 功能應該在2024 年部署。我們建議盡快確定範圍並承諾遵守。其他任何事情都應該考慮後續部署。我們的建議：
EIP-3540: EOF – EVM 物件格式v1[23]：引入程式碼和資料容器，並為以太坊字節碼添加結構和版本。
EIP-3670: EOF – 程式碼驗證[24]：部署時拒絕任何不遵循EOF 格式的合約。強制更結構化的程式碼，並停用無效和未定義的指令。
EIP-663: 無限的SWAP 和DUP 指令[25]：這解決了Solidity 中的「Stack Too Deep」問題，透過JUMPDEST 分析作為即刻值可能會產生副作用。 EVM 語言非常希望有這樣的功能。
EIP-4200: EOF – 靜態相對跳轉[26]：更好的靜態分析，沒有不確定的跳躍。更好的aot 編譯。相對跳轉對程式碼的可重用性較好。
EIP-4750: EOF – 函數[27]：需要處理可能具有動態跳轉但不具有靜態跳轉的子程式。它還允許部分程式碼加載，這與Verkle 很好地配合使用，並增加了合約大小限制。
EIP-5450: EOF – 堆疊驗證[28]：驗證程式碼和堆疊要求。除了CALLF（EIP-4750）之外的所有指令都刪除了執行時堆疊下溢和上溢檢查。
EIP-7480: EOF – 資料段存取指令[29]：允許存取字節碼的資料段。
EIP-7069: 改進的CALL 指令[30]：使CALLs 中的gas 可觀察性消失，這樣將來更容易進行gas 重新定價。雖然獨立於EOF，但我們認為這是引入它的好機會。
我們對EIP-6206: EOF – JUMPF and non-returning functions[31] 的確定性較低。雖然它允許在EOF 函數中進行尾調用優化，但我們仍需要看到語言分析其有用性。如果我們沒有這個，我們認為可以將其從範圍中剔除，並包含在後續EOF 更新中。
我們將以上工作預算為1-2 個月，由1 人全職完成。如果這意味著保持動力，我們願意進一步削減上述提到的範圍。
關於傳統字節碼的說明：
雖然我們可以禁止新的傳統/非EOF 字節碼，但無法廢棄現有的傳統字節碼，它實際上充當EOF“v0”。傳統字節碼仍需要在EOF 後進行JUMPDEST 分析，並且仍需要特殊的程式碼處理來將其分段到Verkle Tries 中。
據我們所知，在不需要存取來源工件情況下，沒有從非EOF 字節碼到EOF 的可驗證轉換，但我們願意調查促進這種轉換的機制。
或者，我們願意探索強制將狀態遷移到EOF 的到期方法。
增加EIP-4844 Blob 數量
我們願意接受這項變化，這將對MAX_BLOB_GAS_PER_BLOCK和TARGET_BLOB_GAS_PER_BLOCK增加，有關上下文，請參閱EIP-4844[32]：
TARGET_BLOB_GAS_PER_BLOCK 和MAX_BLOB_GAS_PER_BLOCK 的值被選為每個區塊的目標為3 個blob（0.375 MB），最大為6 個blob（0.75 MB）。這些較小的初始限制旨在最大限度地減少此EIP 對網路造成的壓力，並且預計將在未來的升級中增加，以便網路在更大的區塊下表現出可靠性。 *
實際上，這是一個小的程式碼更改，我們需要調查它在txpool 中的實際影響，但我們認為我們可以重複使用EIP-4844 的壓力測試基礎設施。共識層可能在傳播更多blob 時遇到困難；我們聽取CL 團隊的意見。
不支援
Verkle Tries[33]
TL;DR：我們認為沒有辦法在2024 年底/2025 年初部署Verkle tries。我們建議團隊在2024 年第二季分配資源，並承諾在大阪硬分叉中在2025 年第二季至第三季部署。
好處：
透過更小的儲存證明實現更便宜的輕客戶端。
透過在區塊頭中包含讀取的預狀態來實現無狀態執行，這也可能由於靜態狀態存取而導致效能改進。
透過對字節碼進行分塊和啟用部分程式碼載入來提高合約大小限制。
由於「復活」狀態的成本較低，狀態到期變得更具吸引力。
不足：
工作量大：變更的影響、整合工作實現以及測試。
Gas 計費變更：Verkle Tries 將見證的大小引入到gas 計算函數中。我們擔心儲存定價的變化尚未被探索（例如，Verkle 後的頂級gas 消耗者的成本將是多少）？
應用整合：當Overlay 過渡運行時，具有Merkle Patricia Trie 驗證器的應用程式該怎麼做？ eth_getProof行為應該怎樣的？
雖然我們理解Verkle Tries 的好處，但我們認為需要更多的思考，以了解第三方工具/合約需要如何適應，以及過渡對例如第2 層解決方案的影響。最初，我們對遷移策略持懷疑態度，因為它規定Verkle trie 應在從現有MPT 讀取狀態時進行更新，但現在似乎並非如此。因此，我們支援Overlay 樹方法作為可行的遷移路徑。
Verkle 遷移策略的文檔似乎普遍過時，因為大多數資源仍然指出Verkle trie 應在從MPT 讀取狀態時進行更新，儘管情況並非如此。我們希望看到關鍵的過渡文檔更新為最新的方法，例如這篇優秀的文檔[34] 。我們也希望看到一份關於過渡策略的草案EIP。
因此，我們仍然支援在2025 年推出Verkle，但在布拉格升級沒有看到部署路徑。
L1 Gas Limit
我們認為從引發需求的角度，提高L1 gas 限制在實務上不會有太大作用。我們也認為大多數客戶端可以處理平均負載的增加，但我們希望對最壞情況保持警惕，因此我們暫時不建議增加L1 gas 限制。我們認為在短期內增加blob gas 限制是更有前景的解決方案。
我們邀請大家與我們合作，進行任何關於這方向的研究，以及圍繞突破EVM 中的資源計量方式。 Broken Metre paper[35] 是這研究方向的一個很好的起點。
帳戶抽象
我們願意包含1 個或多個這些EIP（或協議實現ERCs），但我們希望更理想地看到更多的用戶體驗和開發體驗比較，以更好地理解各個提案的權衡空間和工具集成的工作量。我們正在關注以下EIP/ERCs，但請隨時向我們建議更多：
EIP-3074: AUTH and AUTHCALL opcodes[36]
ERC-4337: Account Abstraction Using Alt Mempool[37]
EIP-5806: Delegate transaction[38]
EIP-5920: PAY opcode[39]
EIP-6913: SETCODE instruction[40]
EIP-7377: Migration Transaction[41]
RIP-7560: Native Account Abstraction – Core EIPs – Fellowship of Ethereum Magicians[42]
我們想要說明，在上述內容中，「帳戶抽象」指的是「抽象驗證功能，主要目標是啟用金鑰輪換，使多簽章成為一等功能，並為我們提供自動的量子抵抗路徑」（h /t VB），只適用於4337 和7560，而其他提案則分為兩個類別，即gas 贊助和操作批次。
作者：
Georgios Konstantopoulos
Georgios Konstantopoulos[43]
Georgios Konstantopoulos 是Paradigm 的技術長和研究合夥人，專注於Paradigm 的投資組合公司和開源協議的研究。在此之前，Georgios 是一名獨立顧問和研究人員。