Vitalik Buterin chce, aby Ethereum było tak proste jak Bitcoin
07 May, 2025 ● Kryptoznawcy
Współzałożyciel Ethereum, Vitalik Buterin, zaproponował uproszczenie podstawowego protokołu blockchain w celu zwiększenia jego wydajności, bezpieczeństwa i dostępności.
Korzystając z inspiracji usprawnioną architekturą Bitcoina, jego celem jest uczynienie Ethereum łatwiejszym w utrzymaniu i skalowaniu w dłuższej perspektywie.
W poście na blogu z 3 maja zatytułowanym "Simplifying the L1", Buterin nakreślił plan przeglądu struktury Ethereum w zakresie konsensusu, wykonania i współdzielonych komponentów.
"Ten post opisze, w jaki sposób Ethereum za 5 lat może stać się prawie tak proste jak Bitcoin" - napisał Buterin, podkreślając, że przyjęcie prostoty jest niezbędne dla trwałości Ethereum i przyszłego wzrostu.
Chociaż ulepszenia takie jak proof-of-stake i integracja zk-SNARK poprawiły możliwości Ethereum, Buterin przyznał, że rosnąca złożoność techniczna wprowadziła dłuższe ramy czasowe rozwoju, wyższe koszty i większą podatność na błędy:
"Historycznie rzecz biorąc, Ethereum często tego nie robiło (czasami z powodu moich własnych decyzji), a to przyczyniło się do wielu naszych nadmiernych wydatków na rozwój, wszelkiego rodzaju ryzyka bezpieczeństwa i wyspiarskiej kultury R&D, często w pogoni za korzyściami, które okazały się iluzoryczne."
Głównym celem propozycji jest warstwa konsensusu Ethereum. Sercem sugerowanych zmian jest koncepcja "3-slotowej ostateczności", która wyeliminowałaby kilka złożonych elementów, takich jak epoki, komitety synchronizacji i tasowanie walidatorów.
"Zmniejszona liczba aktywnych walidatorów w danym momencie oznacza, że bezpieczniejsze staje się stosowanie prostszych implementacji zasady wyboru widelca" - napisał Buterin.
Inne proponowane ulepszenia obejmują uproszczenie logiki wyboru rozwidlenia i wprowadzenie agregacji opartej na STARK w celu poprawy decentralizacji i koordynacji bez zwiększania złożoności.
Po stronie wykonawczej Buterin zaproponował zastąpienie obecnej maszyny wirtualnej Ethereum (EVM) bardziej minimalnym, przyjaznym dla wiedzy zerowej systemem, takim jak RISC-V.
To znacznie poprawiłoby wydajność dowodu ZK - potencjalnie 100-krotnie - i zmniejszyłoby złożoność protokołu.
RISC-V to architektura procesora o otwartym kodzie źródłowym, która wykorzystuje niewielki zestaw podstawowych instrukcji, zgodnie z minimalistyczną filozofią mającą na celu zwiększenie wydajności i łatwości użytkowania.
Aby utrzymać wsparcie dla istniejących inteligentnych kontraktów, Buterin zaproponował dalsze uruchamianie kontraktów EVM za pośrednictwem interpretera RISC-V w łańcuchu, umożliwiając współistnienie obu systemów w okresie przejściowym.
Buterin wezwał również do standaryzacji kilku elementów protokołu w całym Ethereum.
Zalecał wybór jednej metody kodowania kasowania, ujednolicenie wokół formatu serializacji SSZ i przyjęcie spójnej struktury drzewa w celu wyeliminowania niepotrzebnej złożoności i uproszczenia infrastruktury Ethereum.
"Prostota jest pod wieloma względami podobna do decentralizacji" - napisał Buterin. Opowiedział się za tym, by Ethereum wdrożyło próg "maksymalnej linii kodu", taki jak ten stosowany w Tinygrad, aby utrzymać krytyczne dla konsensusu części bazy kodu szczupłe i łatwiejsze do skontrolowania.
Zauważył, że nieistotne starsze funkcje będą nadal obsługiwane, ale będą działać poza podstawową specyfikacją.
Dążenie Buterina do uproszczenia architektury Ethereum pojawia się, gdy dominacja blockchaina nadal słabnie w obliczu konkurencji ze strony innych sieci.
Podczas panelu na wydarzeniu LONGITUDE by Cointelegraph 2 maja, dyrektor generalny Nansen Alex Svanevik skomentował malejący wpływ Ethereum w ekosystemie Layer 1.
"Gdybyś zapytał mnie 3-4 lata temu, czy Ethereum zdominuje kryptowaluty, powiedziałbym, że tak" - powiedział Svanevik podczas dyskusji panelowej na wydarzeniu LONGITUDE by Cointelegraph. "Ale teraz jest jasne, że tak się nie stanie."
Źródła:
https://cointelegraph.com/news/vitalikbuterin-ethereum-simplification-bitcoin-inspired-redesign
https://vitalik.eth.limo/general/2025/05/03/simplel1.html
.
