Jeśli istnieje jedna aktualizacja Ethereum, która kiedykolwiek była druhną, jest to format obiektowy EVM (EOF).
Raz zaręczona, planując ślub w Szanghaju, wkrótce potem została odrzucona przez programistów marzących o mglistej przyszłości w Proto-Danksharding.
Jeśli nie masz pojęcia, co oznacza to zdanie, nie martw się. To metafora godzin dyskusji prowadzonych przez lata rozmów z programistami zajmującymi się wszystkimi rdzeniami Ethereum.
Po czwartkowej rozmowie ACD nadal nie wiemy, czy EOF w końcu dostanie szansę zostać panną młodą. Ale przynajmniej jasna propozycja jest na stole.
Czytaj więcej: Dencun i Pralectra: twórcy rdzenia Ethereum planują ambitny rok 2024
Deweloperzy mocno rozważali EOF dla hard forku Shapella. Jednak rok temu, po krótkiej introspekcji, zdecydowano się na skupienie się wyłącznie na wypłatach ze stakowania.
Po bezpiecznym wysłaniu Shapelli wśród kandydatów do włączenia do Dencun ponownie znalazł się EOF. I znowu film został odłożony na półkę, ku wielkiemu rozczarowaniu dwóch głównych mistrzów tej produkcji, Danno Ferrina i Grega Colvina.
W kwietniu 2023 r. konsensus był taki, że EOF był zbyt duży, aby dzielić scenę z EIP-4844 – Proto-Danksharding – i dlatego trzeba było odejść. Zwyciężyła ta ostatnia opcja, posiadająca potencjał radykalnej poprawy komfortu korzystania z pakietów zbiorczych warstwy 2.
Na pocieszenie Ansgar Dietrichs z Fundacji Ethereum zasugerował, aby EOF był głównym tematem kolejnej aktualizacji, czyli Pragi. „Jest zbyt duży, aby zajmować drugie miejsce w widelcu” – powiedział. Powinien zatem mieć swój własny.
Czytaj więcej: Kolejna aktualizacja Ethereum skupiająca się na obiektach typu blob
Dencun, którego „sterownikiem jest 4844”, pozostaje na dobrej drodze do uruchomienia sieci głównej w marcu, ponieważ programiści zgłosili we wtorek „bezproblemowy” hard fork sieci testowej Sepolia.
„Widzieliśmy ostateczność, a także plamy pojawiające się dokładnie wtedy, gdy tego chcieliśmy” – powiedział Parithosh Jayanthi z Fundacji Ethereum.
Przed siecią główną pozostała tylko jedna sieć testowa, Holesky, a ostateczny test Dencun powinien nastąpić 7 lutego.
Przepychanie EOF przez linię mety
Większość czwartkowych rozmów miała na celu zrozumienie bieżącego statusu kolejnego dużego rozwidlenia funkcji. To ulepszenie warstwy konsensusu, nazwane „Praga”, pochodzi od lokalizacji Devcon 4. Tymczasem „Electra” — oznaczenie inspirowane niebiesko-białym olbrzymem w konstelacji Byka — to termin używany przez klientów egzekucyjnych w odniesieniu do to samo uaktualnienie.
Priorytety „Pectry” powoli nabierają kształtu. Bardzo powoli.
Ferrin po raz kolejny zaproponował EOF, nazywając go „istotnym dla EVM w ciągu najbliższych kilku lat”.
Jako lider grupy roboczej ds. implementacji EOF Ferrin powiedział, że programiści „przechodzą w tryb „wyślij to”.
Celem EOF jest uczynienie inteligentnych kontraktów Ethereum bezpieczniejszymi, wydajniejszymi i przyjaznymi dla programistów. Ma to szczególne znaczenie dla programistów dapp Ethereum, którzy zazwyczaj nie biorą udziału w dwutygodniowych rozmowach z programistami poświęconymi wszystkim rdzeniom.
To pozostawiło w niektórych zespołach klientów wrażenie, że EOF nie było w przeszłości ważne, co było piętnem, z którego trudno było się pozbyć.
Podczas rozmowy telefonicznej 4 stycznia Dragan Rakita z zespołu klienta Reth wyraził silne poparcie dla EOF, a twórca Nethermind Łukasz Rozmej zauważył, że EOF jest znacznie łatwiejszy do przetestowania niż drzewa Verkle — główny cel konkurencji w następnym forku.
Czytaj więcej: Użytkownicy Big Geth dywersyfikują swoich klientów w związku z błędem Nethermind
Nawet Marius van der Wijden z Go Ethereum (Geth), wcześniej sceptyczny wobec EOF, wydawał się stosunkowo zgodny z tym pomysłem.
„Przygotowywałem się do startu w zawodach EOF, ale po prostu nie jest to dla mnie [priorytet]” – powiedział van der Wijden.
Dalsze wsparcie nastąpiło w wyniku rozmowy telefonicznej z 18 stycznia. Dyrektor ds. technologii w firmie Paradigm, Georgios Konstantonopolous, powiedział, że jest to „wykonalne przez jedną osobę w ciągu kilku miesięcy”.
Ferrin powtórzył to zdanie podczas ostatniej rozmowy, argumentując, że prace nad EOF i Verkle są wykonywane przez różnych inżynierów w zespołach klientów, w związku z czym zaangażowanie się w nie nie przeszkodzi w postępie prac nad Verkle.
Jednak Guillaume Ballet, programista Geth w Fundacji Ethereum, nie był jeszcze przekonany, martwiąc się, że EOF może niekorzystnie wpłynąć na Verkle.
„Jeśli tak się stanie, muszę się upewnić, że czegoś nie wyślemy i nie odmalujemy się w kącie, zdając sobie sprawę, że coś zepsuliśmy” – powiedział Ballet.
Andrew Ashikhmin, inżynier oprogramowania w zespole klienta Erigon, zaproponował zaangażowanie się w EOF z zastrzeżeniem, że zostanie on wypróbowany w sieci testowej Verkle i że w nadchodzących tygodniach będzie przewidziany czas na współpracę pomiędzy Verkle i wdrażającymi EOF.
Jak zauważył Ferrin, jest to trochę problem jajka i kury.
„Zanim będziemy mogli umieścić go w sieci testowej w Verkle, musimy go uruchomić na klientach” – powiedział, dodając, że jego zespół kliencki w Besu może wkrótce uruchomić EOF w celach testowych.
Jest jednak przekonany, że powinien być kompatybilny z Verkle.
„Nie chcę „powinien”, chcę zobaczyć, jak to działa” – odparował Ballet.
EOF nadal próbuje złapać bukiet, czekając na zalotnika, który poprowadzi go do ołtarza.
Nie przegap kolejnej ważnej historii – dołącz do naszego bezpłatnego, codziennego biuletynu.
Źródło: https://blockworks.co/news/ethereum-developers-consider-evm-upgrade