Volledige tekst van Vitalik's langetermijnvoorstel voor de L1-uitvoerende laag: vervanging van de EVM door RISC-V

Bron: Vitalik Buterin

Compilatie: KarenZ, Foresight News

Op 20 april presenteerde Vitalik Buterin een belangrijk voorstel over het Ethereum Magicians-platform voor Ethereum's L1-uitvoeringslaag op de lange termijn. Hij stelde voor om de bestaande EVM (Ethereum Virtual Machine) te vervangen door de RISC-V-architectuur als een virtuele machinetaal voor het schrijven van slimme contracten, met als doel de operationele efficiëntie van de uitvoeringslaag van Ethereum fundamenteel te verbeteren, een van de huidige grote knelpunten in de schaalbaarheid te doorbreken en de eenvoud van de uitvoeringslaag aanzienlijk te vereenvoudigen.

Foresight News heeft de volledige tekst van het voorstel samengesteld om lezers te helpen deze technische visie te begrijpen. Het volgende is een compilatie van het oorspronkelijke voorstel:

Dit artikel presenteert een radicaal idee over de toekomst van de uitvoeringslaag van Ethereum, niet minder ambitieus dan de Beam Chain-initiatieven van de consensuslaag. Het voorstel heeft tot doel de efficiëntie van de uitvoeringslaag van Ethereum drastisch te verbeteren, een van de belangrijkste knelpunten in de schaalvergroting aan te pakken en de uitvoeringslaag aanzienlijk te vereenvoudigen - in feite is dit misschien de enige manier om dit te bereiken.

Kernidee: vervang EVM door RISC-V als virtuele machinetaal voor slimme contracten.

Belangrijke opmerkingen:

• Concepten als accountsysteem, cross-contract calling, opslag, etc. blijven volledig behouden. Deze abstracte ontwerpen werken goed en ontwikkelaars zijn gewend om ze te gebruiken. OPCODES ZOALS SLOAD, SSTORE, BALANCE, CALL, ETC. WORDEN OMGEZET IN RISC-V-SYSTEEMAANROEPEN.

• In deze modus kunnen slimme contracten in Rust worden geschreven, maar ik verwacht dat de meeste ontwikkelaars contracten zullen blijven schrijven in Solidity (of Vyper), die zich zullen aanpassen aan RISC-V als de nieuwe backend. Omdat slimme contracten geschreven in Rust eigenlijk minder leesbaar zijn, terwijl Solidity en Vyper duidelijker en gemakkelijker te lezen zijn. De ontwikkelingservaring wordt mogelijk nauwelijks beïnvloed en ontwikkelaars merken de verandering misschien niet eens op.

• Het oude EVM-contract blijft lopen en is volledig bidirectioneel compatibel met het nieuwe RISC-V-contract. Er zijn verschillende manieren om dit te doen, die later in dit artikel in meer detail zullen worden besproken.

Nervos CKB VM heeft een precedent geschapen en is in wezen een RISC-V-implementatie.

Waarom?

Op korte termijn zullen aankomende EIP's (bijv. toegangslijsten op blokniveau, uitgestelde uitvoering, gedistribueerde geschiedenisopslag en EIP-4444) de belangrijkste knelpunten in de schaalbaarheid van Ethereum L1 aanpakken. Op de middellange termijn zullen meer problemen worden opgelost met staatloosheid en ZK-EVM. Op de lange termijn zullen de belangrijkste beperkende factoren voor Ethereum L1-schaling worden:

1. Stabiliteit van de beschikbaarheid van gegevens, steekproeven en historische opslagprotocollen

2. Behoud van de vraag naar concurrentie op de markt voor blokproductie

3. Bewijs van de ZK-EVM

Ik zal betogen dat het vervangen van ZK-EVM door RISC-V de belangrijkste knelpunten in (2) en (3) kan oplossen.

De volgende tabel illustreert het aantal cycli dat nodig is voor elke stap van de beknopte ZK-EVM Proof EVM-uitvoeringslaag:

Beschrijving van het diagram: De vier belangrijkste tijdrovende segmenten zijn deserialize_inputs, initialize_witness_db, state_root_computation en block_execution

initialize_witness_db en state_root_computation zijn gerelateerd aan toestandsbomen, en deserialize_inputs het proces van het omzetten van blok- en getuigengegevens in interne representaties omvatten - waarvan meer dan 50% in feite evenredig is met de grootte van de getuigengegevens.

Deze secties kunnen sterk worden geoptimaliseerd door de huidige keccak 16-ary Merkle patricia-boom te vervangen door een binaire boom die een gemakkelijk te bewijzen hash-functie gebruikt. Als we Poseidon gebruiken, kunnen we 2 miljoen hashes per seconde op een laptop aantonen (vergeleken met ongeveer 15.000 hash/sec voor keccak). Naast Poseidon zijn er nog vele andere mogelijkheden. Over het algemeen is er veel ruimte voor optimalisatie voor deze componenten. Daarnaast kunnen we accrue_logs_bloom wegnemen door bloem te verwijderen.

De overige block_execution is goed voor ongeveer de helft van de huidige provercycli. Om een 100x hogere totale proof-efficiëntie te bereiken, is een EVM-proof-efficiëntie van ten minste 50x vereist. De ene oplossing is om een efficiëntere proof-implementatie voor de EVM te creëren, en de andere is om op te merken dat de huidige ZK-EVM-bewijzer de EVM daadwerkelijk compileert naar RISC-V voor bewijs, waardoor slimme contractontwikkelaars directe toegang krijgen tot de virtuele RISC-V-machine.

Uit sommige gegevens blijkt dat in bepaalde situaties efficiëntiewinsten van meer dan 100 keer kunnen optreden:

In de praktijk kan de resterende tijd van de bewijzer grotendeels in beslag worden genomen door de huidige precompilatiebewerking. Met RISC-V als primaire VM zal het gasschema de werkelijke proeftijd weerspiegelen en zal de economische druk ontwikkelaars ertoe aanzetten het gebruik van dure precompilatie te verminderen. Zelfs dan zullen de voordelen niet zo groot zijn, maar we hebben goede redenen om aan te nemen dat ze aanzienlijk zullen zijn.

(Het is vermeldenswaard dat de tijd die nodig is voor "EVM-bewerkingen" en "andere bewerkingen" in reguliere EVM-uitvoering ook dicht bij 50/50 ligt, dus we gaan er intuïtief van uit dat het verwijderen van de EVM als een "tussenlaag" een even aanzienlijke winst zal opleveren.)

Details van de implementatie

Er zijn verschillende manieren om dit voorstel uit te voeren. De minst storende oplossing is om beide virtuele machines te ondersteunen en het contract in een van beide te laten schrijven. Beide soorten contracten hebben toegang tot dezelfde functies: persistente opslag (SLOAD/SSTORE), de mogelijkheid om ETH-saldi aan te houden, oproepen te starten/ontvangen en meer. EVM- en RISC-V-contracten kunnen naar elkaar worden aangeroepen - vanuit een RISC-V-perspectief staat het aanroepen van het EVM-contract gelijk aan het uitvoeren van een systeemaanroep met speciale parameters; Het EVM-contract dat het bericht ontvangt, zal het interpreteren als een CALL.

Een meer radicale benadering vanuit een protocolperspectief is om een bestaand EVM-contract om te zetten naar een aanroep naar een EVM-tolkcontract geschreven in RISC-V om de bestaande EVM-code uit te voeren. Dat wil zeggen, als een EVM-contract code C heeft en de EVM-interpreter zich op adres X bevindt, dan wordt het contract vervangen door logica op het hoogste niveau die, wanneer het van buitenaf wordt aangeroepen met een aanroepargument D, X aanroept en doorgeeft (C, D), vervolgens wacht op de retourwaarde en doorstuurt. Als de EVM-tolk zelf het contract aanroept en vraagt om CALL of SLOAD/SSTORE uit te voeren, dan voert het contract deze bewerkingen uit.

Het compromis is de tweede optie, maar met expliciete ondersteuning voor het concept van een "virtuele machine-interpreter" via een protocol dat vereist dat de logica in RISC-V wordt geschreven. EVM zal de eerste instantie zijn, met ondersteuning voor andere talen in de toekomst (Move kan een kandidaat zijn).

Het belangrijkste voordeel van de tweede en derde optie is dat ze de specificatie van de uitvoeringslaag aanzienlijk vereenvoudigen. GEZIEN DE MOEILIJKHEID OM ZELFS INCREMENTELE VEREENVOUDIGINGEN ZOALS ZELFVERNIETIGING TE VERWIJDEREN, IS DEZE MANIER VAN DENKEN MISSCHIEN WEL DE ENIGE HAALBARE WEG OM TE VEREENVOUDIGEN. Tinygrad houdt zich aan de harde regel van "niet meer dan 10.000 regels code", en de optimale onderliggende blockchain zou in staat moeten zijn om gemakkelijk aan deze limiet te voldoen en deze verder te stroomlijnen. Het Beam Chain-initiatief belooft de consensuslaag van Ethereum drastisch te vereenvoudigen, en zo'n radicale verandering is misschien de enige manier om een vergelijkbare boost te bereiken op de uitvoeringslaag.