jakiro
作者：Macauley Peterson，Blockworks；編譯：鄧通，比特鏈視界
如果有一個以太坊升級曾經是永遠的伴娘，那就是EVM Object Format（EOF）。
曾一度訂婚，計劃在上海舉行婚禮，但很快被開發者拋棄，他們對Proto-Danksharding的未來充滿了期待。
如果你不明白這句話的意思，別擔心。這是對多年以太坊全核心開發者電話討論的一個比喻。
在周四的ACD（All Core Dev）電話會議後，我們仍然不知道EOF是否最終有機會成為新娘。但至少桌上有一個明確的提案。
開發者們曾經強烈考慮在Shapella硬分叉中引入EOF。然而，一年前，在經過一番深思熟慮後，他們決定放棄EOF，而是將焦點完全放在質押提款上。
一旦Shapella安全交付後，Dencun的候選項目中再次出現了EOF。然後，它再次被擱置，讓該功能的兩位主要支持者Danno Ferrin和Greg Colvin感到遺憾。
2023年4月的共識是EOF太過龐大，無法與EIP-4844（Proto-Danksharding）共同進行，因此必須選擇其中之一。而後者，憑藉其潛力顯著改善第二層Rollups的用戶體驗，最終獲勝。
作為安慰，以太坊基金會的Ansgar Dietrichs建議將EOF作為下一個升級（Prague）的重點。「它太龐大，不適合成為硬分叉中的第二位，」他說。因此，它應該有自己的升級。
以 4844 作為「驅動程序」的 Dencun 仍有望在 3 月份進入主網，因為開發人員周二報告了 Sepolia 測試網的 「uneventful」硬分叉。
在主網發布前，只剩下一個測試網Holesky，Dencun應該在2月7日接受最後的測試。
將 EOF 正式提上日程
周四的電話會議主要旨在了解下一個重大功能分叉的當前狀態。這個名為「Prague」的共識層升級得名於Devcon 4的舉辦地。與此同時，「Electra」——這個名稱靈感來自金牛座內的一顆藍白色巨星——是執行客戶端用來指代相同升級的術語。
「Pectra」的優先事項正在慢慢顯現。
Ferrin再次為EOF做了宣傳，稱其「在未來幾年對EVM至關重要」。
作為EOF實施工作組的領導者，Ferrin表示開發者們「已經進入了『交付』模式」。
EOF的目標是使以太坊智能合約更安全、高效和對於開發者更友好。這對以太坊dapp開發者來說尤為重要，因為他們通常不參與每兩周一次的全核心開發者電話會議。
這導致一些客戶端團隊認為EOF在過去並不重要，這種印象一直很難改變。
在1月4日的電話會議上，來自Reth客戶端團隊的Dragan Rakita表示強烈支持EOF，而Nethermind開發者Lukasz Rozmej指出EOF比Verkle樹更容易測試——這是下一個分叉的主要競爭焦點。
甚至Go Ethereum (Geth)的Marius van der Wijden，曾經對EOF持懷疑態度，似乎對這個想法表示相對支持。
van der Wijden表示：「我一直在逐漸接受EOF，只是對我來說不是首要任務。」
在1月18日的電話會議上，Paradigm的首席技術官Georgios Konstantonopolous表示，這是「一個人在幾個月內可以完成的事情」。
Ferrin在最近的電話會議上重申了這種觀點，認為在客戶端團隊內，EOF和Verkle的工作由不同的工程師完成，因此承諾對EOF的支持不會妨礙對Verkle的工作進展。
然而，以太坊基金會的Geth開發者Guillaume Ballet尚未被說服，擔心EOF可能會對Verkle產生不利影響。
Ballet表示：「如果它確實先行，我需要確保我們不會發布一些東西，然後發現我們陷入了困境。」
Erigon客戶端團隊的軟體工程師Andrew Ashikhmin建議在EOF上做出承諾的同時，在Verkle測試網上嘗試，並在未來幾周劃出時間讓Verkle和EOF的實施者進行合作。
這有點像「先有雞還是先有蛋」的問題，正如Ferrin所觀察到的那樣。
「在我們可以將其放入Verkle的測試網之前，我們需要在客戶端上讓其運行，」他說，並補充說他的Besu客戶端團隊可能很快就能使EOF運行起來以進行測試。
但他確信EOF應該與Verkle兼容。
Ballet反駁道：「我不想要『應該』，我想要看到它運作。」
EOF仍在努力抓住花束，等待有意者將其帶上紅毯。
