以太坊開發者考慮對EVM進行EOF升級

作者: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仍在努力抓住花束,等待有意者將其帶上紅毯。

Total
0
Shares
Related Posts