Ethereum może przejść największą w historii aktualizację: EVM zostanie wyłączony, a RISC-V przejmie kontrolę

Oryginalny tytuł: Goodbye EVM, Hello RISC-V

Oryginalny autor: jaehaerys.eth, badacz kryptowalut

Oryginalne tłumaczenie: TechFlow

Streszczenie

Ethereum przygotowuje się na najważniejszą transformację architektury od czasu swojego powstania: zastąpienie EVM przez RISC-V.

Powód jest prosty — w przyszłości opartej na zero-knowledge (ZK), EVM stał się wąskim gardłem wydajności:

· Obecnie zkEVM polega na interpreterze, co powoduje spowolnienie wydajności od 50 do 800 razy;

· Moduły prekompilowane komplikują protokół i zwiększają ryzyko;

· 256-bitowa konstrukcja stosu jest bardzo nieefektywna podczas generowania dowodów.

Rozwiązania RISC-V:

· Minimalistyczny design (około 47 podstawowych instrukcji) + dojrzały ekosystem LLVM (wsparcie dla Rust, C++, Go i innych języków);

· Stał się de facto standardem dla zkVM (90% projektów go używa);

· Posiada formalną specyfikację SAIL (w porównaniu do niejasnej Yellow Paper) → umożliwia rygorystyczną weryfikację;

· Ścieżka dowodzenia sprzętowego (ASICs/FPGAs) jest już testowana (SP1, Nervos, Cartesi itd.).

Proces migracji składa się z trzech etapów:

· Zastąpienie prekompilowanych modułów przez RISC-V (testy niskiego ryzyka);

· Era podwójnych maszyn wirtualnych: EVM i RISC-V współistnieją i są w pełni interoperacyjne;

· Ponowne zaimplementowanie EVM w RISC-V (strategia Rosetta).

Wpływ na ekosystem:

· Rollupy optymistyczne (np. Arbitrum i Optimism) muszą przebudować mechanizm dowodów oszustwa;

· Rollupy zero-knowledge (np. Polygon, zkSync, Scroll) zyskają ogromną przewagę → taniej, szybciej, prościej;

· Deweloperzy będą mogli korzystać z bibliotek języków takich jak Rust, Go i Python bezpośrednio na warstwie L1;

· Użytkownicy będą korzystać z około 100 razy niższych kosztów dowodzenia → droga do Gigagas L1 (około 10,000 TPS).

Ostatecznie Ethereum ewoluuje z „maszyny wirtualnej dla smart kontraktów” do minimalistycznej, weryfikowalnej warstwy zaufania internetu, której ostatecznym celem jest „ZK-Snark-owanie wszystkiego”.

Skrzyżowanie Ethereum

Vitalik Buterin powiedział kiedyś: „Celem końcowym jest... ZK-Snark-owanie wszystkiego.”

Era zero-knowledge proofs (ZK) jest nieunikniona, a jej główny argument jest prosty: Ethereum przebudowuje się od podstaw, opierając się na zero-knowledge proofs. To oznacza techniczny koniec protokołu — osiągnięcie jego ostatecznej formy poprzez rekonstrukcję L1, napędzaną przez wysokowydajny zkVM wspierany przez zespoły core dev (takie jak Succinct).

Z tą wizją jako celem, Ethereum stoi przed najważniejszą transformacją architektury od czasu swojego powstania. Ta dyskusja nie dotyczy już stopniowych ulepszeń, lecz całkowitej rekonstrukcji rdzenia obliczeniowego — zastąpienia Ethereum Virtual Machine (EVM). Ten krok jest kamieniem węgielnym szerszej wizji „Lean Ethereum”.

Wizja Lean Ethereum ma na celu systematyczne uproszczenie całego protokołu, dzieląc go na trzy główne moduły: Lean Consensus, Lean Data i Lean Execution. Wśród kluczowych kwestii Lean Execution najważniejsze pytanie brzmi: czy EVM, jako silnik rewolucji smart kontraktów, stał się głównym wąskim gardłem dla przyszłego rozwoju Ethereum?

Jak powiedział Justin Drake z Ethereum Foundation, długoterminowym celem Ethereum zawsze było „Snarkify everything” — potężne narzędzie wzmacniające wszystkie warstwy protokołu. Jednak przez długi czas cel ten wydawał się „nieosiągalnym planem”, ponieważ wymagał koncepcji real-time proving. Teraz, gdy real-time proving staje się rzeczywistością, teoretyczna nieefektywność EVM stała się pilnym problemem do rozwiązania.

W tym artykule przeanalizujemy techniczne i strategiczne argumenty za migracją Ethereum L1 do architektury instrukcji RISC-V (ISA). Ten krok nie tylko uwolni bezprecedensową skalowalność, ale także uprości strukturę protokołu i dostosuje Ethereum do przyszłości weryfikowalnych obliczeń.

Co się właściwie zmienia?

Zanim omówimy „dlaczego”, należy najpierw wyjaśnić „co” się zmienia.

EVM (Ethereum Virtual Machine) to środowisko uruchomieniowe dla smart kontraktów Ethereum, nazywane „światowym komputerem” przetwarzającym transakcje i aktualizującym stan blockchaina. Przez lata jej projekt był rewolucyjny i umożliwił powstanie DeFi oraz ekosystemu NFT. Jednak ta niemal dziesięcioletnia, niestandardowa architektura nagromadziła ogromny dług technologiczny.

Dla porównania, RISC-V nie jest produktem, lecz otwartym standardem — darmowym, uniwersalnym „alfabetem” projektowania procesorów. Jak podkreślił Jeremy Bruestle na konferencji Ethproofs, jego kluczowe zasady czynią go doskonałym wyborem do tej roli:

· Minimalizm: Podstawowy zestaw instrukcji RISC-V jest niezwykle prosty, obejmuje tylko około 40–47 instrukcji. Jak mówi Jeremy, czyni to z niego „niemal idealną maszynę do naszego super-minimalistycznego uniwersalnego zastosowania”.

· Modularność: Bardziej złożone funkcje są dodawane poprzez opcjonalne rozszerzenia. To kluczowa cecha, ponieważ pozwala utrzymać prostotę rdzenia przy jednoczesnym rozszerzaniu funkcjonalności w razie potrzeby, bez narzucania niepotrzebnej złożoności podstawowemu protokołowi.

· Otwarty ekosystem: RISC-V posiada rozbudowane i dojrzałe wsparcie narzędziowe, w tym kompilator LLVM, umożliwiający programistom korzystanie z popularnych języków, takich jak Rust, C++ i Go. Jak zauważa Justin Drake: „Narzędzia wokół kompilatorów są bardzo bogate, a budowa kompilatorów jest niezwykle trudna... więc posiadanie tych narzędzi jest bardzo cenne.” RISC-V pozwala Ethereum bezpłatnie odziedziczyć te gotowe narzędzia.

Problem narzutu interpretera

Powodem zastąpienia EVM nie jest pojedyncza wada, lecz zbieżność wielu fundamentalnych ograniczeń, które w przyszłości opartej na zero-knowledge proofs stały się nie do zignorowania. Ograniczenia te obejmują wąskie gardła wydajności w systemach zero-knowledge proofs oraz rosnące ryzyko wynikające ze złożoności protokołu.

Najpilniejszym motorem tej transformacji jest wrodzona nieefektywność EVM w systemach zero-knowledge proofs. W miarę jak Ethereum przechodzi na model weryfikacji stanu L1 za pomocą dowodów ZK, wydajność proverów staje się największym wąskim gardłem.

Problem tkwi w sposobie działania obecnych zkEVM. Nie dowodzą one bezpośrednio EVM, lecz interpreterowi EVM, który sam jest kompilowany do RISC-V. Vitalik Buterin jasno wskazał ten kluczowy problem:

„...jeśli implementacja zkVM polega na kompilowaniu wykonania EVM do kodu, który ostatecznie staje się kodem RISC-V, to dlaczego nie udostępnić bezpośrednio RISC-V deweloperom smart kontraktów? Można w ten sposób całkowicie wyeliminować narzut zewnętrznej maszyny wirtualnej.”

Ta dodatkowa warstwa interpretacji powoduje ogromne straty wydajności. Szacunki wskazują, że w porównaniu do dowodzenia natywnym programom, ta warstwa może powodować spadek wydajności od 50 do 800 razy. Po zoptymalizowaniu innych wąskich gardeł (np. przez przejście na algorytm haszujący Poseidon), ta część „wykonania bloku” nadal zajmuje 80–90% całego czasu dowodzenia, czyniąc EVM ostateczną i najtrudniejszą przeszkodą w skalowaniu L1. Usunięcie tej warstwy może, według Vitalika, zwiększyć wydajność nawet 100-krotnie.

Pułapka długu technologicznego

Aby zrekompensować niską wydajność EVM w określonych operacjach kryptograficznych, Ethereum wprowadziło prekompilowane kontrakty — specjalne funkcje zakodowane bezpośrednio w protokole. Choć było to praktyczne rozwiązanie w swoim czasie, dziś prowadzi do sytuacji, którą Vitalik Buterin określił jako „fatalną”:

„Prekompilacje są dla nas katastrofalne... znacznie powiększyły zaufaną bazę kodu Ethereum... i kilkukrotnie niemal doprowadziły do poważnych problemów z konsensusem.”

Ta złożoność jest szokująca. Vitalik podaje przykład, że kod opakowujący pojedynczy prekompilowany kontrakt (np. modexp) jest bardziej złożony niż cały interpreter RISC-V, a logika prekompilacji jest jeszcze bardziej skomplikowana. Dodanie nowej prekompilacji wymaga powolnego i politycznie kontrowersyjnego procesu hard forka, co poważnie hamuje innowacje wymagające nowych prymitywów kryptograficznych. Vitalik wyciąga jasny wniosek:

„Uważam, że powinniśmy od dziś przestać dodawać jakiekolwiek nowe prekompilacje.”

Dług technologiczny architektury Ethereum

Podstawowy projekt EVM odzwierciedla priorytety minionej epoki, ale nie nadaje się już do współczesnych potrzeb obliczeniowych. EVM wybrał 256-bitową architekturę do obsługi wartości kryptograficznych, ale dla typowych w smart kontraktach liczb 32- lub 64-bitowych jest to bardzo nieefektywne. Ta nieefektywność jest szczególnie kosztowna w systemach ZK. Jak wyjaśnia Vitalik:

„Gdy używasz mniejszych liczb, każda z nich w rzeczywistości nie oszczędza żadnych zasobów, a złożoność wzrasta dwukrotnie lub czterokrotnie.”

Oprócz tego, architektura stosu EVM jest mniej wydajna niż architektura rejestrów RISC-V i nowoczesnych CPU. Wymaga więcej instrukcji do wykonania tych samych operacji i utrudnia optymalizację przez kompilatory.

Te problemy — wąskie gardła wydajności ZK, złożoność prekompilacji i przestarzałe wybory architektoniczne — razem stanowią przekonujący i pilny powód: Ethereum musi wyjść poza EVM i przyjąć architekturę lepiej dostosowaną do przyszłości.

Plan RISC-V: Przebudowa przyszłości Ethereum na solidniejszych podstawach

Siła RISC-V nie polega tylko na brakach EVM, ale na wewnętrznej sile jego filozofii projektowej. Jego architektura zapewnia solidne, proste i weryfikowalne podstawy, idealne dla środowiska o wysokim ryzyku, jakim jest Ethereum.

Dlaczego otwarte standardy są lepsze od projektów niestandardowych?

W przeciwieństwie do niestandardowych architektur instrukcji (ISA), które wymagają budowy całego ekosystemu oprogramowania od zera, RISC-V to dojrzały, otwarty standard z trzema kluczowymi zaletami:

Dojrzały ekosystem

Przyjmując RISC-V, Ethereum może korzystać z dziesięcioleci postępu w informatyce. Jak wyjaśnia Justin Drake, daje to Ethereum możliwość bezpośredniego użycia światowej klasy narzędzi:

„Jest komponent infrastruktury zwany LLVM, to zestaw narzędzi kompilatora, który pozwala kompilować języki wysokiego poziomu do różnych backendów. Jednym z obsługiwanych backendów jest RISC-V. Jeśli wspierasz RISC-V, automatycznie wspierasz wszystkie języki wysokiego poziomu obsługiwane przez LLVM.”

To znacznie obniża próg wejścia, umożliwiając milionom programistów znających Rust, C++ i Go łatwe rozpoczęcie pracy.

Minimalistyczna filozofia projektowa Minimalizm RISC-V to celowa cecha, a nie ograniczenie. Podstawowy zestaw instrukcji obejmuje tylko około 47 instrukcji, utrzymując rdzeń maszyny wirtualnej w skrajnej prostocie. Ta prostota daje znaczące korzyści w zakresie bezpieczeństwa, ponieważ mniejsza zaufana baza kodu jest łatwiejsza do audytu i formalnej weryfikacji.

De facto standard w dziedzinie zero-knowledge proofs Co ważniejsze, ekosystem zkVM już dokonał wyboru. Jak zauważa Justin Drake, dane Ethproofs pokazują wyraźny trend:

„RISC-V jest wiodącą architekturą instrukcji (ISA) dla backendów zkVM.”

Spośród dziesięciu zkVM zdolnych do dowodzenia bloków Ethereum, dziewięć wybrało RISC-V jako docelową architekturę. Ta rynkowa konwergencja wysyła silny sygnał: przyjmując RISC-V, Ethereum nie podejmuje spekulacyjnej próby, lecz dostosowuje się do standardu już zweryfikowanego i uznanego przez projekty budujące zero-knowledge przyszłość.

Stworzone dla zaufania, nie tylko dla wykonania

Oprócz szerokiego ekosystemu, wewnętrzna architektura RISC-V jest szczególnie odpowiednia do budowy bezpiecznych i weryfikowalnych systemów. Po pierwsze, RISC-V posiada sformalizowaną, maszynowo czytelną specyfikację — SAIL. To ogromny postęp w porównaniu do specyfikacji EVM (głównie tekstowej Yellow Paper). Yellow Paper jest nieco niejasny, podczas gdy specyfikacja SAIL zapewnia „złoty standard”, umożliwiając kluczowe matematyczne dowody poprawności, co jest kluczowe dla ochrony protokołu o ogromnej wartości. Jak zauważa Alex Hicks z Ethereum Foundation podczas Ethproofs, pozwala to obwodom zkVM na bezpośrednią weryfikację „w stosunku do oficjalnej specyfikacji RISC-V”. Po drugie, RISC-V zawiera architekturę uprzywilejowaną, często pomijaną, lecz kluczową dla bezpieczeństwa. Definiuje ona różne poziomy operacji, głównie tryb użytkownika (dla nieufnych aplikacji, takich jak smart kontrakty) i tryb nadzorcy (dla zaufanego „jądra wykonawczego”). Diego z Cartesi szczegółowo to wyjaśnia:

„System operacyjny musi chronić się przed innym kodem. Musi izolować różne programy, a wszystkie te mechanizmy są częścią standardu RISC-V.”

W architekturze RISC-V smart kontrakty działające w trybie użytkownika (User Mode) nie mają bezpośredniego dostępu do stanu blockchaina. Zamiast tego muszą wysyłać żądania do zaufanego jądra działającego w trybie nadzorcy (Supervisor Mode) za pomocą specjalnej instrukcji ECALL. Ten mechanizm tworzy granicę bezpieczeństwa wymuszaną sprzętowo, bardziej solidną i łatwiejszą do weryfikacji niż model EVM oparty wyłącznie na sandboxie programowym.

Wizja Vitalika

Ta transformacja została zaplanowana jako stopniowy, wieloetapowy proces, aby zapewnić stabilność systemu i kompatybilność wsteczną. Jak wyjaśnia założyciel Ethereum, Vitalik Buterin, podejście to ma na celu „ewolucyjny” rozwój, a nie całkowitą „rewolucję”.

Krok pierwszy: Zastąpienie prekompilacji

Początkowy etap przyjmuje najbardziej konserwatywne podejście, wprowadzając ograniczoną funkcjonalność nowej maszyny wirtualnej (VM). Jak sugeruje Vitalik Buterin: „Możemy zacząć używać nowej VM w ograniczonych przypadkach, np. zastępując funkcje prekompilowane.” Konkretnie, wstrzyma to dodawanie nowych prekompilacji EVM, zastępując je funkcjami realizowanymi przez zatwierdzone na whitelist RISC-V programy. Takie podejście pozwala na testowanie nowej VM na mainnecie w środowisku niskiego ryzyka, przy jednoczesnym pośrednictwie klientów Ethereum między dwoma środowiskami wykonawczymi.

Krok drugi: Współistnienie dwóch maszyn wirtualnych

Kolejny etap to „udostępnienie nowej VM bezpośrednio użytkownikom”. Smart kontrakty mogą być oznaczone jako EVM lub RISC-V. Kluczową cechą jest bezproblemowa interoperacyjność: „Oba typy kontraktów mogą się wzajemnie wywoływać.” Funkcjonalność ta zostanie osiągnięta przez wywołania systemowe (ECALL), umożliwiając współpracę obu VM w tym samym ekosystemie.

Krok trzeci: EVM jako kontrakt symulowany („strategia Rosetta”)

Ostatecznym celem jest maksymalne uproszczenie protokołu. Na tym etapie „EVM staje się jedną z implementacji w nowej VM.” Sformalizowany EVM stanie się formalnie zweryfikowanym smart kontraktem działającym natywnie na RISC-V L1. Zapewni to nieprzerwane wsparcie dla starszych aplikacji, a jednocześnie pozwoli deweloperom klientów utrzymywać tylko jeden uproszczony silnik wykonawczy, znacznie redukując złożoność i koszty utrzymania.

Efekt fali w ekosystemie

Przejście z EVM na RISC-V to nie tylko zmiana rdzenia protokołu — wpłynie ono głęboko na cały ekosystem Ethereum. Ta transformacja nie tylko zmieni doświadczenie deweloperów, ale też fundamentalnie przekształci konkurencję rozwiązań warstwy 2 i odblokuje nowe modele ekonomicznej weryfikacji.

Nowe pozycjonowanie Rollupów: Pojedynek Optimistic vs ZK

Wprowadzenie warstwy wykonawczej RISC-V na L1 będzie miało zupełnie różny wpływ na dwa główne typy rollupów.

Optimistic Rollupy (np. Arbitrum, Optimism) staną przed wyzwaniami architektonicznymi. Ich model bezpieczeństwa opiera się na ponownym wykonaniu spornej transakcji przez L1 EVM w celu rozstrzygnięcia dowodu oszustwa. Jeśli EVM na L1 zostanie zastąpiony, model ten całkowicie się załamie. Projekty te będą musiały dokonać trudnego wyboru: albo przeprowadzić ogromną przebudowę inżynieryjną, projektując system dowodów oszustwa dla nowej VM L1, albo całkowicie odejść od modelu bezpieczeństwa Ethereum.

Dla kontrastu, ZK Rollupy zyskają ogromną przewagę strategiczną. Zdecydowana większość ZK Rollupów już używa RISC-V jako wewnętrznej architektury instrukcji (ISA). L1 „mówiący tym samym językiem” pozwoli na ściślejszą i bardziej wydajną integrację. Justin Drake przedstawił wizję przyszłości „natywnych rollupów”: L2 staje się w rzeczywistości wyspecjalizowanym środowiskiem wykonawczym L1, wykorzystującym wbudowaną VM L1 do bezproblemowego rozliczania. To wyrównanie przyniesie następujące zmiany:

· Uproszczenie stosu technologicznego: Zespoły L2 nie będą już musiały budować złożonych mostów między wewnętrznym środowiskiem RISC-V a EVM.

· Współdzielenie narzędzi i kodu: Kompilatory, debugery i narzędzia do formalnej weryfikacji opracowane dla środowiska RISC-V L1 mogą być bezpośrednio używane przez L2, znacznie obniżając koszty rozwoju.

· Wyrównanie bodźców ekonomicznych: Opłaty za Gas na L1 będą dokładniej odzwierciedlać rzeczywiste koszty weryfikacji ZK opartej na RISC-V, tworząc bardziej racjonalny model ekonomiczny.

Nowa era dla deweloperów i użytkowników

Dla deweloperów Ethereum ta transformacja będzie stopniowa, a nie destrukcyjna.

Deweloperzy zyskają dostęp do szerszego i dojrzalszego ekosystemu narzędzi programistycznych. Jak zauważa Vitalik Buterin, deweloperzy będą „mogli pisać kontrakty w Rust, a te opcje mogą współistnieć”. Przewiduje on również, że „Solidity i Vyper pozostaną popularne ze względu na swoją elegancję w logice smart kontraktów”. Możliwość korzystania z głównych języków programowania i ich ogromnych bibliotek przez narzędzia LLVM to prawdziwa rewolucja. Vitalik porównuje to do „doświadczenia NodeJS”, gdzie deweloperzy mogą pisać kod on-chain i off-chain w tym samym języku, ujednolicając proces rozwoju.

Dla użytkowników transformacja ta ostatecznie przyniesie niższe koszty i wyższą wydajność sieci. Oczekuje się, że koszty dowodzenia spadną około 100 razy, z kilku dolarów za transakcję do kilku centów lub mniej. Bezpośrednio przełoży się to na niższe opłaty L1 i koszty rozliczeń L2. Ta ekonomiczna wykonalność odblokuje wizję „Gigagas L1”, której celem jest wydajność na poziomie około 10,000 TPS, torując drogę dla bardziej złożonych i wartościowych aplikacji on-chain w przyszłości.

Succinct Labs i SP1: Budowanie przyszłości dowodzenia już dziś

Ethereum jest gotowe do działania. „Skalowanie L1, skalowanie bloków” to strategiczne, pilne zadanie w ramach EF Protocol Cluster. Oczekuje się, że w ciągu najbliższych 6–12 miesięcy nastąpi znaczna poprawa wydajności.

Zespoły takie jak Succinct Labs już w praktyce demonstrują teoretyczne zalety RISC-V, a ich praca stanowi mocny dowód na wykonalność tej propozycji.

SP1, opracowany przez Succinct Labs, to wysokowydajny, otwartoźródłowy zkVM oparty na RISC-V, który potwierdza wykonalność nowego podejścia architektonicznego. SP1 przyjmuje filozofię „precompile-centric”, doskonale rozwiązując kryptograficzne wąskie gardła EVM. Zamiast polegać na wolnych, twardo zakodowanych prekompilacjach, SP1 przenosi operacje takie jak Keccak hash do specjalnie zaprojektowanych, ręcznie zoptymalizowanych obwodów ZK, wywoływanych przez standardowe instrukcje ECALL. Takie podejście łączy wydajność sprzętu dedykowanego z elastycznością oprogramowania, oferując deweloperom bardziej wydajne i skalowalne rozwiązania.

Wpływ Succinct Labs jest już widoczny. Ich produkt OP Succinct wykorzystuje SP1, aby dodać możliwości zero-knowledge proof (ZK-ify) do Optimistic Rollups. Jak wyjaśnia współzałożyciel Succinct, Uma Roy:

„Rollupy korzystające z OP Stack nie muszą już czekać siedmiu dni na ostateczne potwierdzenie i wypłatę... Teraz potwierdzenie trwa tylko godzinę. To ogromny postęp.”

To przełomowe rozwiązanie rozwiązuje kluczowy problem całego ekosystemu OP Stack. Ponadto infrastruktura Succinct — Succinct Prover Network — została zaprojektowana jako zdecentralizowany rynek generowania dowodów, pokazując wykonalny model ekonomiczny dla przyszłości weryfikowalnych obliczeń. Ich praca to nie tylko proof-of-concept, ale realny plan na przyszłość, jak opisano w tym artykule.

Jak Ethereum minimalizuje ryzyko

Jedną z największych zalet RISC-V jest to, że umożliwia osiągnięcie „świętego Graala” formalnej weryfikacji — matematycznego dowodu poprawności systemu. Specyfikacja EVM jest napisana w języku naturalnym w Yellow Paper, co utrudnia formalizację. RISC-V posiada oficjalną, maszynowo czytelną specyfikację SAIL, która stanowi jasny „złoty wzorzec” zachowania.

To toruje drogę do większego bezpieczeństwa. Jak zauważa Alex Hicks z Ethereum Foundation, trwają już prace nad „formalną weryfikacją obwodów zkVM RISC-V w stosunku do oficjalnej specyfikacji RISC-V wyodrębnionej do Lean”. To kamień milowy, który przenosi zaufanie z zawodnych implementacji ludzkich na weryfikowalne dowody matematyczne, otwierając nowy poziom bezpieczeństwa blockchaina.

Główne ryzyka transformacji

Mimo licznych zalet architektury RISC-V na L1, niesie ona także nowe, złożone wyzwania.

Problem pomiaru Gas

Stworzenie deterministycznego i sprawiedliwego modelu Gas dla uniwersalnej architektury instrukcji (ISA) to nierozwiązany problem. Prosty licznik instrukcji jest podatny na ataki typu denial-of-service. Przykładowo, atakujący może zaprojektować program wielokrotnie wywołujący cache miss, powodując wysokie zużycie zasobów przy niskim koszcie Gas. To poważne wyzwanie dla stabilności sieci i modelu ekonomicznego.

Bezpieczeństwo narzędzi i problem „reproducible builds”

To najważniejsze i często niedoceniane ryzyko w procesie transformacji. Model bezpieczeństwa przesuwa się z zależności od VM on-chain na zależność od kompilatorów off-chain (np. LLVM), które są bardzo złożone i znane z błędów. Atakujący mogą wykorzystać luki w kompilatorze, aby przekształcić pozornie nieszkodliwy kod źródłowy w złośliwy bytecode. Ponadto zapewnienie, że binarka na łańcuchu jest identyczna z publicznym kodem źródłowym („reproducible builds”), jest bardzo trudne. Nawet drobne różnice w środowisku budowania mogą prowadzić do różnych binarek, co wpływa na przejrzystość i zaufanie. To poważne wyzwania dla bezpieczeństwa deweloperów i użytkowników.

Strategie łagodzenia ryzyka

Dalsza droga wymaga wielowarstwowych strategii obronnych.

Wdrażanie etapowe

Stopniowy, wieloetapowy plan przejścia to kluczowa strategia zarządzania ryzykiem. Wprowadzając najpierw RISC-V jako zamiennik prekompilacji, a następnie uruchamiając środowisko podwójnej maszyny wirtualnej, społeczność może zdobyć doświadczenie operacyjne i zbudować zaufanie w środowisku niskiego ryzyka, unikając nieodwracalnych zmian. To stopniowe podejście zapewnia stabilne podstawy dla transformacji technologicznej.

Kompleksowy audyt: fuzzing i formalna weryfikacja

Choć formalna weryfikacja jest celem końcowym, musi być połączona z ciągłymi, intensywnymi testami. Jak pokazuje Valentine z Diligence Security podczas telekonferencji Ethproofs, ich narzędzie Argus do fuzzingu wykryło już 11 krytycznych luk w czołowych zkVM. To pokazuje, że nawet najlepiej zaprojektowane systemy mogą mieć luki wykrywalne tylko przez rygorystyczne testy kontradyktoryjne. Połączenie fuzzingu i formalnej weryfikacji zapewnia większe bezpieczeństwo systemu.

Standaryzacja

Aby uniknąć fragmentacji ekosystemu, społeczność powinna przyjąć jedną, standaryzowaną konfigurację RISC-V. Może to być kombinacja RV64GC i ABI kompatybilnego z Linuksem, ponieważ ta konfiguracja ma najszersze wsparcie w głównych językach programowania i narzędziach, maksymalizując korzyści nowego ekosystemu. Standaryzacja zwiększa efektywność deweloperów i zapewnia solidne podstawy dla długoterminowego rozwoju ekosystemu.

Weryfikowalna przyszłość Ethereum

Propozycja zastąpienia Ethereum Virtual Machine (EVM) przez RISC-V to nie tylko stopniowa aktualizacja, ale fundamentalna przebudowa warstwy wykonawczej Ethereum. Ta ambitna wizja ma na celu rozwiązanie głębokich wąskich gardeł skalowalności, uproszczenie złożoności protokołu i dostosowanie platformy do szerszego ekosystemu uniwersalnych obliczeń. Mimo ogromnych wyzwań technicznych i społecznych, długoterminowe strategiczne korzyści uzasadniają to śmiałe przedsięwzięcie.

Transformacja ta skupia się na szeregu kluczowych kompromisów:

· Równowaga między ogromnym wzrostem wydajności architektury ZK-native a pilną potrzebą kompatybilności wstecznej;

· Wybór między korzyściami bezpieczeństwa wynikającymi z uproszczenia protokołu a inercją ogromnego efektu sieciowego EVM;

· Wybór między potęgą uniwersalnego ekosystemu a ryzykiem zależności od złożonych narzędzi zewnętrznych.

Ostatecznie ta transformacja architektury będzie kluczowa dla realizacji obietnicy „Lean Execution” i ważną częścią wizji „Lean Ethereum”. Przekształci L1 Ethereum z prostego smart contract platform w wydajną i bezpieczną warstwę rozliczeniową i dostępności danych, zaprojektowaną do wspierania szerokiego świata weryfikowalnych obliczeń.

Jak mówi Vitalik Buterin, „Celem końcowym jest... ZK-snark dla wszystkiego.”

Projekty takie jak Ethproofs dostarczają obiektywnych danych i platformy współpracy dla tej transformacji, a zespół Succinct Labs, dzięki praktycznemu zastosowaniu SP1 zkVM, oferuje wykonalny plan na przyszłość. Przyjmując RISC-V, Ethereum nie tylko rozwiązuje własne wąskie gardła skalowalności, ale także pozycjonuje się jako podstawowa warstwa zaufania dla następnej generacji internetu — napędzana przez trzeci prymityw kryptograficzny po hashach i podpisach: SNARK.

Dowodzenie światem oprogramowania, otwarcie nowej ery kryptografii.

Dowiedz się więcej: