Pełny tekst długoterminowej propozycji warstwy wykonawczej L1 firmy Vitalik: zastąpienie EVM przez RISC-V

Źródło: Vitalik Buterin

Kompilacja: KarenZ, Foresight News

20 kwietnia Vitalik Buterin przedstawił ważną propozycję na platformie Ethereum Magicians dotyczącą długoterminowej warstwy wykonawczej L1 Ethereum. Zaproponował zastąpienie istniejącego EVM (Ethereum Virtual Machine) architekturą RISC-V jako językiem maszyn wirtualnych do pisania inteligentnych kontraktów, mając na celu fundamentalną poprawę wydajności operacyjnej warstwy wykonawczej Ethereum, przełamanie jednego z obecnych głównych wąskich gardeł skalowania i znaczne uproszczenie prostoty warstwy wykonawczej.

Foresight News opracowało pełny tekst propozycji, aby pomóc czytelnikom zrozumieć tę techniczną wizję. Poniżej znajduje się kompilacja pierwotnej propozycji:

Niniejszy artykuł przedstawia radykalny pomysł na przyszłość warstwy wykonawczej Ethereum, nie mniej ambitny niż inicjatywy warstwy konsensusu Beam Chain. Propozycja ma na celu radykalną poprawę wydajności warstwy wykonawczej Ethereum, rozwiązanie jednego z głównych wąskich gardeł skalowania i znaczne uproszczenie warstwy wykonawczej – w rzeczywistości może to być jedyny sposób, aby to osiągnąć.

Podstawowa idea: Zamień EVM na RISC-V jako język maszyn wirtualnych dla inteligentnych kontraktów.

Ważne uwagi:

• Koncepcje takie jak system kont, połączenia międzykontraktowe, przechowywanie itp. zostaną w pełni zachowane. Te abstrakcyjne projekty działają dobrze, a programiści są przyzwyczajeni do ich używania. KODY OPERACYJNE, TAKIE JAK SLOAD, SSTORE, BALANCE, CALL ITP., SĄ KONWERTOWANE NA WYWOŁANIA SYSTEMOWE RISC-V.

• W tym trybie inteligentne kontrakty mogą być pisane w Rust, ale spodziewam się, że większość programistów będzie nadal pisać kontrakty w Solidity (lub Vyper), który dostosuje się do RISC-V jako nowego backendu. Ponieważ inteligentne kontrakty napisane w Rust są w rzeczywistości mniej czytelne, podczas gdy Solidity i Vyper są bardziej przejrzyste i łatwiejsze do odczytania. Środowisko programistyczne może być prawie nienaruszone, a programiści mogą nawet nie zauważyć zmiany.

• Stary kontrakt EVM będzie nadal obowiązywał i jest w pełni dwukierunkowo kompatybilny z nowym kontraktem RISC-V. Można to zrobić na kilka sposobów, które zostaną omówione bardziej szczegółowo w dalszej części tego artykułu.

Nervos CKB VM ustanowił precedens i jest zasadniczo implementacją RISC-V.

Dlaczego?

W perspektywie krótkoterminowej nadchodzące EIP (np. listy dostępu na poziomie bloków, odroczone wykonanie, rozproszone przechowywanie historii i EIP-4444) zajmą się głównymi wąskimi gardłami skalowania Ethereum L1. Więcej problemów zostanie rozwiązanych w perspektywie średnioterminowej dzięki bezpaństwowości i ZK-EVM. W dłuższej perspektywie głównymi czynnikami ograniczającymi skalowanie Ethereum L1 staną się:

1. Stabilność dostępności danych, próbkowania i historycznych protokołów przechowywania

2. Utrzymanie popytu na konkurencję na rynku produkcji bloków

3. Dowód na istnienie ZK-EVM

Będę argumentował, że zastąpienie ZK-EVM przez RISC-V może rozwiązać kluczowe wąskie gardła w (2) i (3).

Poniższa tabela ilustruje liczbę cykli wymaganych dla każdego kroku warstwy wykonawczej Succinct ZK-EVM Proof EVM:

Opis diagramu: Cztery główne, czasochłonne segmenty to deserialize_inputs, initialize_witness_db, state_root_computation i block_execution

initialize_witness_db i state_root_computation są związane z drzewami stanów i obejmują deserialize_inputs proces przekształcania danych blokowych i danych świadków w wewnętrzne reprezentacje – z których ponad 50% jest w rzeczywistości proporcjonalne do rozmiaru danych świadków.

Sekcje te można znacznie zoptymalizować, zastępując obecne 16-elementowe drzewo patricia Merkle keccak drzewem binarnym, które wykorzystuje łatwą do udowodnienia funkcję skrótu. Jeśli użyjemy Posejdona, możemy udowodnić 2 miliony skrótów na sekundę na laptopie (w porównaniu do około 15 000 hash/s w przypadku keccak). Oprócz Posejdona istnieje wiele innych opcji. Ogólnie rzecz biorąc, istnieje duże pole do optymalizacji dla tych komponentów. Ponadto możemy wyeliminować accrue_logs_bloom, usuwając nalot.

Pozostałe block_execution odpowiadają za około połowę obecnych cykli prover. Aby osiągnąć 100-krotny wzrost ogólnej wydajności dowodu, wymagana jest co najmniej 50-krotna sprawność dowodu EVM. Jednym z rozwiązań jest stworzenie bardziej wydajnej implementacji dowodu dla EVM, a drugim jest zauważenie, że obecny prover ZK-EVM faktycznie kompiluje EVM do RISC-V w celu dowodu, dając programistom inteligentnych kontraktów bezpośredni dostęp do maszyny wirtualnej RISC-V.

Niektóre dane pokazują, że wzrost wydajności ponad 100-krotny może wystąpić w pewnych sytuacjach:

W praktyce pozostały czas prover może być w większości zajęty przez bieżącą operację prekompilacji. W przypadku RISC-V jako podstawowej maszyny wirtualnej, harmonogram gazu będzie odzwierciedlał rzeczywisty czas próby, a presja ekonomiczna skłoni deweloperów do zmniejszenia użycia kosztownej kompilacji wstępnej. Nawet wtedy zyski nie będą tak znaczące, ale mamy powody, by sądzić, że będą znaczne.

(Warto zauważyć, że czas potrzebny na "operacje EVM" i "inne operacje" w regularnym wykonaniu EVM jest również bliski 50/50, więc intuicyjnie zakładamy, że usunięcie EVM jako "warstwy pośredniej" przyniesie równie znaczący zysk).

Szczegóły implementacji

Propozycja ta może zostać zrealizowana na kilka sposobów. Najmniej uciążliwym rozwiązaniem jest obsługa obu maszyn wirtualnych i umożliwienie napisania kontraktu w jednej z nich. Oba rodzaje kontraktów mają dostęp do tych samych funkcji: trwałego przechowywania (SLOAD/SSTORE), możliwości przechowywania sald ETH, inicjowania/odbierania połączeń i innych. Kontrakty EVM i RISC-V mogą być wywoływane do siebie nawzajem - z perspektywy RISC-V wywołanie kontraktu EVM jest równoznaczne z wykonaniem wywołania systemowego o specjalnych parametrach; Kontrakt EVM, który otrzyma wiadomość, zinterpretuje ją jako CALL.

Bardziej radykalnym podejściem z punktu widzenia protokołu jest konwersja istniejącego kontraktu EVM na wywołanie kontraktu interpretera EVM napisanego w RISC-V w celu uruchomienia istniejącego kodu EVM. Oznacza to, że jeśli kontrakt EVM ma kod C, a interpreter EVM znajduje się pod adresem X, to kontrakt zostanie zastąpiony logiką najwyższego poziomu, która po wywołaniu z zewnątrz za pomocą argumentu wywołania D, wywołuje X i przekazuje (C, D), a następnie czeka na wartość zwracaną i przekazuje dalej. Jeśli interpreter EVM sam wywoła kontrakt, prosząc o uruchomienie CALL lub SLOAD/SSTORE, kontrakt wykona te operacje.

Kompromis jest drugą opcją, ale z wyraźnym poparciem dla koncepcji "interpretera maszyny wirtualnej" poprzez protokół, który wymaga, aby jego logika była zapisana w RISC-V. EVM będzie pierwszym przypadkiem, z obsługą innych języków w przyszłości (Move może być kandydatem).

Główną zaletą drugiej i trzeciej opcji jest to, że znacznie upraszczają specyfikację warstwy wykonawczej. BIORĄC POD UWAGĘ TRUDNOŚCI NAWET W USUWANIU STOPNIOWYCH UPROSZCZEŃ, TAKICH JAK AUTODESTRUKCJA, TEN SPOSÓB MYŚLENIA MOŻE BYĆ JEDYNĄ REALNĄ ŚCIEŻKĄ DO UPROSZCZENIA. Tinygrad przestrzega twardej zasady "nie więcej niż 10 000 linii kodu", a optymalny blockchain powinien być w stanie z łatwością spełnić ten limit i jeszcze bardziej go usprawnić. Inicjatywa Beam Chain obiecuje radykalnie uprościć warstwę konsensusu Ethereum, a tak radykalna zmiana może być jedynym sposobem na osiągnięcie podobnego wzrostu w warstwie wykonawczej.