Vitaliks långsiktiga L1 exekutiva lagerförslag: att ersätta EVM med RISC-V

Källa: Vitalik Buterin

Sammanställning: KarenZ, Foresight News

Den 20 april presenterade Vitalik Buterin ett viktigt förslag på Ethereum Magicians-plattformen för Ethereums långsiktiga L1-exekveringslager. Han föreslog att ersätta den befintliga EVM (Ethereum Virtual Machine) med RISC-V-arkitekturen som ett virtuellt maskinspråk för att skriva smarta kontrakt, i syfte att i grunden förbättra den operativa effektiviteten i Ethereums exekveringslager, bryta igenom en av de nuvarande stora skalningsflaskhalsarna och avsevärt förenkla enkelheten i exekveringsskiktet.

Foresight News har sammanställt den fullständiga texten till förslaget för att hjälpa läsarna att förstå denna tekniska vision. Följande är en sammanställning av det ursprungliga förslaget:

Detta dokument presenterar en radikal idé om framtiden för Ethereums exekveringslager, inte mindre ambitiöst än konsensuslagrets Beam Chain-initiativ. Förslaget syftar till att dramatiskt förbättra effektiviteten i Ethereums exekveringslager, ta itu med en av de största flaskhalsarna i skalningen och avsevärt förenkla exekveringslagret – i själva verket kan detta vara det enda sättet att uppnå detta.

Kärnidé: Ersätt EVM med RISC-V som ett virtuellt maskinspråk för smarta kontrakt.

Viktiga anmärkningar:

• Begrepp som kontosystem, kontraktsöverskridande samtal, lagring etc. kommer att behållas fullt ut. Dessa abstrakta mönster fungerar bra och utvecklare är vana vid att använda dem. OPKODER SOM SLOAD, SSTORE, BALANCE, CALL OSV. KONVERTERAS TILL RISC-V-SYSTEMANROP.

• I det här läget kan smarta kontrakt skrivas i Rust, men jag förväntar mig att de flesta utvecklare fortsätter att skriva kontrakt i Solidity (eller Vyper), som kommer att anpassa sig till RISC-V som den nya backend. Eftersom smarta kontrakt skrivna i Rust faktiskt är mindre läsbara, medan Solidity och Vyper är tydligare och lättare att läsa. Utvecklingsupplevelsen kanske knappt påverkas, och utvecklare kanske inte ens märker ändringen.

• Det gamla EVM-kontraktet kommer att fortsätta att löpa och är helt kompatibelt med det nya RISC-V-kontraktet. Det finns flera sätt att göra detta, som kommer att diskuteras mer i detalj senare i den här artikeln.

Nervos CKB VM har skapat ett prejudikat och är i huvudsak en RISC-V-implementering.

Varför?

På kort sikt kommer kommande EIP:er (t.ex. åtkomstlistor på blocknivå, uppskjuten exekvering, distribuerad historiklagring och EIP-4444) att ta itu med de stora skalningsflaskhalsarna i Ethereum L1. Fler problem kommer att lösas på medellång sikt med statslöshet och ZK-EVM. På lång sikt kommer de viktigaste begränsande faktorerna för Ethereum L1-skalning att bli:

1. Stabilitet för datatillgänglighet, sampling och historiska lagringsprotokoll

2. Upprätthålla efterfrågan på konkurrens på marknaden för blockproduktion

3. Bevis på ZK-EVM

Jag kommer att argumentera för att ett byte av ZK-EVM med RISC-V kan lösa de viktigaste flaskhalsarna i (2) och (3).

Följande tabell illustrerar antalet cykler som krävs för varje steg i det kortfattade ZK-EVM Proof EVM-utförandelagret:

Diagrambeskrivning: De fyra huvudsakliga tidskrävande segmenten är deserialize_inputs, initialize_witness_db, state_root_computation och block_execution

initialize_witness_db och state_root_computation är relaterade till statsträd, och deserialize_inputs involverar processen att konvertera block- och vittnesdata till interna representationer – varav mer än 50 % faktiskt är proportionell mot storleken på vittnesdata.

Dessa sektioner kan optimeras avsevärt genom att ersätta det nuvarande keccak 16-ary Merkle patricia-trädet med ett binärt träd som använder en hash-funktion som är lätt att bevisa. Om vi använder Poseidon kan vi bevisa 2 miljoner hash per sekund på en bärbar dator (jämfört med cirka 15 000 hash/sek för keccak). Förutom Poseidon finns det många andra alternativ. Sammantaget finns det mycket utrymme för optimering för dessa komponenter. Dessutom kan vi eliminera accrue_logs_bloom genom att ta bort blomning.

De återstående block_execution står för ungefär hälften av de nuvarande jäsningscyklerna. För att uppnå en 100x ökning av den totala beviseffektiviteten krävs en EVM-beviseffektivitet på minst 50 gånger. Den ena lösningen är att skapa en mer effektiv proof-implementation för EVM, och den andra är att märka att den nuvarande ZK-EVM-provaren faktiskt kompilerar EVM till RISC-V för bevis, vilket ger utvecklare av smarta kontrakt direkt tillgång till den virtuella RISC-V-maskinen.

Vissa data visar att effektivitetsvinster på mer än 100 gånger kan uppstå i vissa situationer:

I praktiken kan den återstående bevisartiden till största delen vara upptagen av den aktuella förkompileringsåtgärden. Med RISC-V som primär virtuell dator kommer gasschemat att återspegla den faktiska bevistiden, och det ekonomiska trycket kommer att driva utvecklare att minska användningen av högkostnadsförkompilering. Även då kommer vinsterna inte att vara så betydande, men vi har goda skäl att tro att de kommer att vara betydande.

(Det är värt att notera att den tid det tar för "EVM-operationer" och "andra operationer" i vanlig EVM-körning också är nära 50/50, så vi antar intuitivt att det kommer att ge en lika betydande vinst att ta bort EVM som ett "mellanlager".)

Information om implementering

Det finns flera sätt att genomföra detta förslag. Den minst störande lösningen är att stödja båda virtuella maskinerna och låta kontraktet skrivas i en av dem. Båda typerna av kontrakt har tillgång till samma funktioner: beständig lagring (SLOAD/SSTORE), möjligheten att hålla ETH-saldon, initiera/ta emot samtal och mer. EVM- och RISC-V-kontrakt kan anropas till varandra – ur ett RISC-V-perspektiv är anrop av EVM-kontraktet likvärdigt med att utföra ett systemanrop med speciella parametrar; EVM-kontraktet som tar emot meddelandet kommer att tolka det som ett CALL.

Ett mer radikalt tillvägagångssätt ur ett protokollperspektiv är att konvertera ett befintligt EVM-kontrakt till ett anrop till ett EVM-tolkkontrakt skrivet i RISC-V för att köra dess befintliga EVM-kod. Det vill säga, om ett EVM-kontrakt har kod C och EVM-tolken är på adressen X, kommer kontraktet att ersättas med logik på toppnivå som, när det anropas utifrån med ett anropsargument D, anropar X och passerar in (C, D), sedan väntar på returvärdet och vidarebefordrar. Om EVM-tolken själv anropar kontraktet och ber om att få köra CALL eller SLOAD/SSTORE, utförs dessa åtgärder i kontraktet.

Kompromissen är det andra alternativet, men med uttryckligt stöd för konceptet med en "virtuell maskintolk" genom ett protokoll som kräver att dess logik skrivs i RISC-V. EVM kommer att vara den första instansen, med stöd för andra språk i framtiden (Move kan vara en kandidat).

Den största fördelen med det andra och tredje alternativet är att de avsevärt förenklar specifikationen för utförandelagret. MED TANKE PÅ SVÅRIGHETEN ATT ENS TA BORT INKREMENTELLA FÖRENKLINGAR SOM SJÄLVFÖRSTÖRELSE, KAN DETTA TANKESÄTT VARA DEN ENDA MÖJLIGA VÄGEN ATT FÖRENKLA. Tinygrad följer den hårda regeln om "inte mer än 10 000 rader kod", och den optimala underliggande blockkedjan bör enkelt kunna uppfylla denna gräns och effektivisera den ytterligare. Beam Chain-initiativet lovar att dramatiskt förenkla Ethereums konsensuslager, och en sådan radikal förändring kan vara det enda sättet att uppnå ett liknande uppsving i exekveringsskiktet.