Full tekst av Vitaliks langsiktige L1-eksekutivlagsforslag: erstatte EVM med RISC-V

Kilde: Vitalik Buterin

Samling: KarenZ, Foresight News

20. april presenterte Vitalik Buterin et viktig forslag på Ethereum Magicians-plattformen for Ethereums langsiktige L1-utførelseslag. Han foreslo å erstatte den eksisterende EVM (Ethereum Virtual Machine) med RISC-V-arkitekturen som et virtuelt maskinspråk for å skrive smarte kontrakter, med sikte på å fundamentalt forbedre driftseffektiviteten til Ethereums utførelseslag, bryte gjennom en av de nåværende store skaleringsflaskehalsene og i stor grad forenkle enkelheten til utførelseslaget.

Foresight News har samlet hele teksten til forslaget for å hjelpe leserne å forstå denne tekniske visjonen. Følgende er en samling av det opprinnelige forslaget:

Denne artikkelen presenterer en radikal idé om fremtiden til Ethereums utførelseslag, ikke mindre ambisiøs enn konsensuslagets Beam Chain-initiativer. Forslaget tar sikte på å dramatisk forbedre effektiviteten til Ethereums utførelseslag, adressere en av de største skaleringsflaskehalsene og forenkle utførelseslaget betydelig – faktisk kan dette være den eneste måten å oppnå dette på.

Kjerneidé: Erstatt EVM med RISC-V som et virtuelt maskinspråk for smarte kontrakter.

Viktige notater:

• Konsepter som kontosystem, samtaler på tvers av kontrakter, lagring, etc., vil bli beholdt fullt ut. Disse abstrakte designene fungerer bra, og utviklere er vant til å bruke dem. OPKODER SOM SLOAD, SSTORE, BALANCE, CALL, ETC., KONVERTERES TIL RISC-V-SYSTEMKALL.

• I denne modusen kan smarte kontrakter skrives i Rust, men jeg forventer at de fleste utviklere fortsetter å skrive kontrakter i Solidity (eller Vyper), som vil tilpasse seg RISC-V som den nye backend. Fordi smarte kontrakter skrevet i Rust faktisk er mindre lesbare, mens Solidity og Vyper er klarere og lettere å lese. Utviklingsopplevelsen kan knapt bli påvirket, og utviklere legger kanskje ikke engang merke til endringen.

• Den gamle EVM-kontrakten vil fortsette å løpe og er fullt toveis kompatibel med den nye RISC-V-kontrakten. Det er flere måter å gjøre dette på, som vil bli diskutert mer detaljert senere i denne artikkelen.

Nervos CKB VM har satt presedens og er i hovedsak en RISC-V-implementering.

Hvorfor?

På kort sikt vil kommende EIP-er (f.eks. tilgangslister på blokknivå, utsatt utførelse, distribuert historielagring og EIP-4444) adressere de store skaleringsflaskehalsene til Ethereum L1. Flere problemer vil bli løst på mellomlang sikt med statsløshet og ZK-EVM. På lang sikt vil de viktigste begrensende faktorene for Ethereum L1-skalering bli:

1. Stabilitet for datatilgjengelighet, prøvetaking og historiske lagringsprotokoller

2. Opprettholde etterspørselen etter konkurranse i blokkproduksjonsmarkedet

3. Bevis på ZK-EVM

Jeg vil argumentere for at å erstatte ZK-EVM med RISC-V kan løse de viktigste flaskehalsene i (2) og (3).

Tabellen nedenfor illustrerer antall sykluser som kreves for hvert trinn i det kortfattede ZK-EVM Proof EVM-utførelseslaget:

Diagrambeskrivelse: De fire viktigste tidkrevende segmentene er deserialize_inputs, initialize_witness_db, state_root_computation og block_execution

initialize_witness_db og state_root_computation er relatert til statlige trær, og deserialize_inputs involverer prosessen med å konvertere blokk- og vitnedata til interne representasjoner – hvorav mer enn 50 % faktisk er proporsjonal med størrelsen på vitnedataene.

Disse seksjonene kan optimaliseres kraftig ved å erstatte det nåværende keccak 16-ary Merkle patricia-treet med et binært tre som bruker en hash-funksjon som er lett å bevise. Hvis vi bruker Poseidon, kan vi bevise 2 millioner hashes per sekund på en bærbar datamaskin (sammenlignet med omtrent 15 000 hash/sek for keccak). I tillegg til Poseidon er det mange andre alternativer. Totalt sett er det mye rom for optimalisering for disse komponentene. I tillegg kan vi eliminere accrue_logs_bloom ved å fjerne blomst.

De resterende block_execution står for omtrent halvparten av de nåværende bevissyklusene. For å oppnå en 100x økning i total beviseffektivitet, kreves en EVM-sikker effektivitet på minst 50x. Den ene løsningen er å lage en mer effektiv bevisimplementering for EVM, og den andre er å legge merke til at den nåværende ZK-EVM-beviseren faktisk kompilerer EVM til RISC-V for bevis, noe som gir smarte kontraktsutviklere direkte tilgang til den virtuelle RISC-V-maskinen.

Noen data viser at effektivitetsgevinster på mer enn 100 ganger kan oppstå i visse situasjoner:

I praksis kan den gjenværende bevistiden for det meste være opptatt av den nåværende prekompileringsoperasjonen. Med RISC-V som primær VM vil gassplanen gjenspeile den faktiske prøvetiden, og det økonomiske presset vil drive utviklere til å redusere bruken av høykostig forhåndskompilering. Selv da vil ikke gevinstene være så betydelige, men vi har god grunn til å tro at de vil være betydelige.

(Det er verdt å merke seg at tiden det tar for "EVM-operasjoner" og "andre operasjoner" i vanlig EVM-utførelse også er nær 50/50, så vi antar intuitivt at fjerning av EVM som et "mellomlag" vil gi en like betydelig gevinst.)

Detaljer om implementering

Det er flere måter å implementere dette forslaget på. Den minst forstyrrende løsningen er å støtte begge virtuelle maskiner og la kontrakten skrives i en av dem. Begge typer kontrakter har tilgang til de samme funksjonene: vedvarende lagring (SLOAD/SSTORE), muligheten til å holde ETH-saldoer, starte/motta samtaler og mer. EVM- og RISC-V-kontrakter kan kalles til hverandre - fra et RISC-V-perspektiv tilsvarer det å ringe EVM-kontrakten å utføre et systemkall med spesielle parametere; EVM-kontrakten som mottar meldingen vil tolke den som en CALL.

En mer radikal tilnærming fra et protokollperspektiv er å konvertere en eksisterende EVM-kontrakt til en samtale til en EVM-tolkekontrakt skrevet i RISC-V for å kjøre den eksisterende EVM-koden. Det vil si at hvis en EVM-kontrakt har kode C og EVM-tolken er på adresse X, vil kontrakten bli erstattet med logikk på toppnivå som, når den kalles fra utsiden med et kalleargument D, kaller X og går inn (C, D), og deretter venter på returverdien og videresender. Hvis EVM-tolken selv ringer kontrakten og ber om å kjøre CALL eller SLOAD/SSTORE, utfører kontrakten disse operasjonene.

Kompromisset er det andre alternativet, men med eksplisitt støtte for konseptet med en "virtuell maskintolk" gjennom en protokoll som krever at logikken skrives i RISC-V. EVM vil være den første instansen, med støtte for andre språk i fremtiden (Move kan være en kandidat).

Kjernefordelen med det andre og tredje alternativet er at de i stor grad forenkler spesifikasjonen av utførelseslaget. GITT VANSKELIGHETEN MED Å FJERNE INKREMENTELLE FORENKLINGER SOM SELVDESTRUKSJON, KAN DENNE TANKEGANGEN VÆRE DEN ENESTE LEVEDYKTIGE VEIEN Å FORENKLE. Tinygrad følger den harde regelen om "ikke mer enn 10 000 linjer med kode", og den optimale blokkjeden som ligger til grunn skal enkelt kunne møte denne grensen og strømlinjeforme den ytterligere. Beam Chain-initiativet lover å dramatisk forenkle Ethereums konsensuslag, og en slik radikal endring kan være den eneste måten å oppnå et lignende løft på utførelseslaget.