Ethereum przygotowuje się do największej aktualizacji w historii: EVM zostanie wycofany, 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 architektura 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 żółtej księgi) → umożliwia rygorystyczną weryfikację;

· Ścieżka dowodzenia sprzętowego (ASICy/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 (niskie ryzyko testowe);

· Era dwóch 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:

· Optimistic Rollupy (takie jak Arbitrum i Optimism) będą musiały przebudować mechanizm dowodów oszustwa;

· Zero-knowledge Rollupy (takie jak Polygon, zkSync, Scroll) uzyskają ogromną przewagę → taniej, szybciej, prościej;

· Deweloperzy będą mogli korzystać z bibliotek 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 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ś: „Koniec obejmuje... ZK-Snark-owanie wszystkiego.”

Era zero-knowledge (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 punkt docelowy protokołu — osiągnięcie jego ostatecznej formy poprzez rekonstrukcję L1, napędzaną wysokowydajnym zkVM wspieranym przez zespoły core dev (takie jak Succinct).

Z tą wizją jako celem, Ethereum stoi przed najważniejszą transformacją architektury od 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 kluczowe moduły: Lean Consensus, Lean Data i Lean Execution. Wśród kluczowych problemów Lean Execution, najważniejsze pytanie brzmi: czy EVM, jako silnik napędzający rewolucję 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”, co jest potężnym narzędziem wzmacniającym wszystkie warstwy protokołu. Jednak przez długi czas cel ten wydawał się „odległym 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 może uwolnić niespotykaną dotąd skalowalność, ale także uprościć strukturę protokołu i dostosować Ethereum do przyszłości weryfikowalnych obliczeń.

Co się właściwie zmienia?

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

EVM (Ethereum Virtual Machine) to środowisko uruchomieniowe 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ę ogólnego przeznaczenia, której potrzebujemy”.

· Modularność: Bardziej złożone funkcje są dodawane poprzez opcjonalne rozszerzenia. To kluczowa cecha, bo pozwala zachować prostotę rdzenia, a jednocześnie rozszerzać funkcjonalność w razie potrzeby, bez narzucania zbędnej złożoności podstawowemu protokołowi.

· Otwarty ekosystem: RISC-V posiada rozbudowane i dojrzałe wsparcie narzędziowe, w tym kompilator LLVM, co pozwala deweloperom korzystać z popularnych języków programowania, takich jak Rust, C++ i Go. Jak zauważył 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 wartościowe.” RISC-V pozwala Ethereum bezpłatnie odziedziczyć te gotowe narzędzia.

Problem narzutu interpretera

Powodem do zastąpienia EVM nie jest pojedyncza wada, lecz zbieżność wielu fundamentalnych ograniczeń, które w przyszłości opartej na zero-knowledge nie mogą być ignorowane. Ograniczenia te obejmują wąskie gardła wydajności w systemach zero-knowledge proofs oraz rosnące ryzyko wynikające z narastającej 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 przez dowody 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 RISC-V, to dlaczego nie udostępnić natywnego RISC-V deweloperom smart kontraktów? To pozwoliłoby 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 natywnemu programowi, 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 z EVM najtrudniejszą przeszkodę w skalowaniu L1. Usunięcie tej warstwy, według Vitalika, może zwiększyć wydajność nawet 100-krotnie.

Pułapka długu technologicznego

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

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

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 nowych 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 odpowiada już współczesnym potrzebom obliczeniowym. EVM wybrał 256-bitową architekturę do obsługi wartości kryptograficznych, ale dla typowych 32- lub 64-bitowych liczb całkowitych używanych w smart kontraktach 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 nie oszczędza żadnych zasobów, a złożoność wzrasta dwukrotnie lub czterokrotnie.”

Poza tym 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 silniejszych fundamentach

Siła RISC-V nie polega tylko na brakach EVM, ale na wewnętrznej sile jego filozofii projektowej. Jego architektura zapewnia solidną, prostą i weryfikowalną podstawę, idealną dla środowisk o wysokim ryzyku, takich jak Ethereum.

Dlaczego otwarty standard jest lepszy niż projekt niestandardowy?

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

Dojrzały ekosystem

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

„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 obsługujesz RISC-V, automatycznie obsługujesz wszystkie języki wysokiego poziomu wspierane przez LLVM.”

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

Minimalistyczna filozofia projektowa Minimalizm RISC-V to celowa cecha, a nie ograniczenie. Podstawowy zestaw instrukcji obejmuje tylko około 47 instrukcji, co utrzymuje rdzeń maszyny wirtualnej niezwykle prostym. 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 świecie zero-knowledge proofs Co ważniejsze, ekosystem zkVM już dokonał wyboru. Jak zauważa Justin Drake, dane z 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ż sprawdzonego i uznanego przez projekty budujące zero-knowledge przyszłość.

Stworzone dla zaufania, nie tylko wykonania

Poza szerokim ekosystemem, 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. W porównaniu do specyfikacji EVM (głównie tekstowej „żółtej księgi”), to ogromny postęp. Żółta księga jest nieco niejasna, podczas gdy specyfikacja SAIL zapewnia „złoty standard”, umożliwiający matematyczne dowody poprawności, co jest kluczowe dla ochrony protokołu o ogromnej wartości. Jak zauważa Alex Hicks z Ethereum Foundation na Ethproofs, pozwala to obwodom zkVM na bezpośrednią weryfikację względem oficjalnej specyfikacji RISC-V. Po drugie, RISC-V zawiera architekturę uprzywilejowaną, często pomijaną, ale 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 wyjaśnia to szczegółowo:

„System operacyjny musi chronić się przed innym kodem. Musi izolować różne programy od siebie, 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ą wysłać specjalną instrukcję ECALL (environment call) do zaufanego jądra działającego w trybie nadzorcy (Supervisor Mode). 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 scenariuszach, np. jako zamiennik funkcji prekompilowanych.” Oznacza to wstrzymanie dodawania nowych prekompilacji EVM, a zamiast tego implementację wymaganych funkcji przez zatwierdzone programy RISC-V na białej liście. To podejście pozwala na testowanie nowej VM na mainnecie w środowisku niskiego ryzyka, przy czym klient Ethereum pośredniczy 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 zrealizowana 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 wieczyste wsparcie dla starszych aplikacji i pozwoli deweloperom klienta 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, ale także głęboka transformacja całego ekosystemu Ethereum. Ta zmiana nie tylko przekształci doświadczenie deweloperów, ale także zasadniczo zmieni krajobraz konkurencji rozwiązań warstwy 2 i odblokuje nowe modele ekonomii weryfikacji.

Nowe pozycjonowanie Rollupów: Pojedynek Optimistic i ZK

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

Optimistic Rollupy (takie jak Arbitrum, Optimism) stoją 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, ten model 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 swojej wewnętrznej architektury instrukcji (ISA). L1 „mówiący tym samym językiem” pozwoli na ściślejszą i bardziej wydajną integrację. Justin Drake przedstawia wizję „natywnych Rollupów”: L2 staje się specjalizowaną instancją środowiska wykonawczego L1, wykorzystując wbudowaną VM L1 do bezproblemowego rozliczania. To dopasowanie 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 stworzone dla środowiska RISC-V L1 mogą być bezpośrednio używane przez L2, znacznie obniżając koszty rozwoju.

· Dopasowanie 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 uzyskają dostęp do szerszego i bardziej dojrzałego ekosystemu narzędzi programistycznych. Jak zauważa Vitalik Buterin, deweloperzy „będą mogli pisać kontrakty w Rust, a te opcje będą współistnieć”. Jednocześnie przewiduje, ż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 rewolucyjna zmiana. Vitalik porównuje to do „doświadczenia NodeJS”, gdzie deweloperzy mogą pisać kod zarówno on-chain, jak i off-chain w tym samym języku, integrując cały proces rozwoju.

Dla użytkowników ta transformacja 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ść otworzy wizję „Gigagas L1”, z celem osiągnięcia 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 dowodów przyszłości już dziś

Ethereum jest gotowe do działania. „Skalowanie L1, skalowanie bloków” to strategiczne, pilne zadanie w klastrze protokołów EF. Oczekuje się, że w ciągu najbliższych 6–12 miesięcy nastąpi znaczący wzrost 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 wydajny, open-source'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 powolnych, zakodowanych na sztywno prekompilacjach, SP1 przenosi operacje wymagające dużej mocy obliczeniowej, takie jak Keccak hash, do specjalnie zaprojektowanych, ręcznie zoptymalizowanych obwodów ZK, wywoływanych przez standardowe instrukcje ECALL. To 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 proofs (ZK-ify) do Optimistic Rollupów. 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, prezentują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 głównych 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 względem oficjalnej specyfikacji RISC-V w 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, zużywając dużo zasobów przy minimalnym 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 podatności. Atakujący może wykorzystać luki w kompilatorze, aby przekształcić pozornie nieszkodliwy kod źródłowy w złośliwy bytecode. Ponadto zapewnienie, że binarka po kompilacji na łańcuchu jest identyczna z publicznym kodem źródłowym („reproducible builds”), jest bardzo trudne. Najmniejsze różnice w środowisku kompilacji mogą prowadzić do różnych plików binarnych, co wpływa na przejrzystość i zaufanie. To poważne wyzwanie 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. Najpierw wprowadzenie RISC-V jako zamiennika prekompilacji, potem uruchomienie w środowisku dwóch VM, pozwoli społeczności zdobyć doświadczenie w niskiego ryzyka środowisku i zbudować zaufanie, unikając nieodwracalnych zmian. To stopniowe podejście zapewnia stabilne podstawy dla transformacji technologicznej.

Pełny audyt: fuzzing i formalna weryfikacja

Choć formalna weryfikacja jest celem końcowym, musi być połączona z ciągłym, intensywnym testowaniem. Jak pokazał 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 daje silniejsze gwarancje bezpieczeństwa systemu.

Standaryzacja

Aby uniknąć fragmentacji ekosystemu, społeczność powinna przyjąć jedną, standardową konfigurację RISC-V. Może to być kombinacja RV64GC i ABI kompatybilnego z Linuxem, ponieważ ta konfiguracja ma najszersze wsparcie w głównych językach programowania i narzędziach, maksymalizując korzyści nowego ekosystemu. Standaryzacja nie tylko zwiększa efektywność deweloperów, ale także 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, lecz 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 obliczeń ogólnego przeznaczenia. Mimo ogromnych wyzwań technicznych i społecznych, długoterminowe korzyści strategiczne uzasadniają to śmiałe przedsięwzięcie.

Ta transformacja koncentruje się na szeregu kluczowych kompromisów:

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

· Kompromis między korzyściami bezpieczeństwa wynikającymi z uproszczenia protokołu a inercją ogromnych efektów sieciowych EVM;

· Wybór między potężnym ekosystemem ogólnego przeznaczenia a ryzykiem zależności od złożonych narzędzi firm trzecich.

Ostatecznie ta transformacja architektury będzie kluczowa dla realizacji obietnicy „Lean Execution” i stanowi ważną część 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 obsługi wszechświata weryfikowalnych obliczeń.

Jak powiedział Vitalik Buterin, „celem jest... ZK-snark dla wszystkiego.”

Projekty takie jak Ethproofs dostarczają obiektywnych danych i platformy współpracy dla tej transformacji, a zespół Succinct Labs, poprzez praktyczne zastosowanie SP1 zkVM, oferuje wykonalny plan na tę 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 następnej generacji Internetu — napędzana przez trzecią po hashach i podpisach kryptograficznych prymityw SNARK.

Dowodzenie oprogramowania świata, otwarcie nowej ery kryptografii.

Dowiedz się więcej: