De ontwikkelaars weerleggen Vitalik: de aannames zijn onjuist en RISC-V is niet de beste keuze

Dit artikel komt uit: Ethereum-ontwikkelaar levochka.eth

compilatie|Odaily Planet Daily (@OdailyChina); @azuma_eth Noot van de redactie

:

Gisteren heeft Ethereum-medeoprichter Vitalik een radicaal artikel uitgebracht over de upgrade van de uitvoeringslaag van Ethereum (zie "Vitalik's radicale nieuwe artikel: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM moet in de toekomst worden herhaald), waarin hij vermeldt dat hij hoopt het te vervangen door RISC-V EVM als virtuele machinetaal voor slimme contracten.

Zodra dit artikel uitkwam, veroorzaakte het meteen opschudding in de Ethereum-ontwikkelaarsgemeenschap, en veel technische hoogwaardigheidsbekleders uitten verschillende meningen over het plan. Kort nadat het artikel was gepubliceerd, schreef Tier-1 Ethereum-ontwikkelaar levochka.eth een lang artikel onder het oorspronkelijke artikel waarin hij het argument van Vitalik weerlegde dat Vitalik de verkeerde aannames had gedaan over het bewijssysteem en de prestaties ervan, en dat RISC-V misschien niet de beste keuze was omdat het geen evenwicht kon vinden tussen "schaalbaarheid" en "onderhoudbaarheid".

Het volgende is het originele artikel op levochka.eth, samengesteld door het dagblad Odaily.

Doe dit alsjeblieft niet.

Dit plan slaat nergens op, omdat je de verkeerde aannames doet over het bewijzen van het systeem en de prestaties ervan.

Validatiehypothese

Zoals ik het begrijp, zijn de belangrijkste argumenten voor dit schema "schaalbaarheid" en "onderhoudbaarheid".

Eerst wil ik het hebben over onderhoudbaarheid.

In feite vereisen alle RISC-V zk-VM's "precompilaties" om rekenintensieve bewerkingen uit te voeren. De vooraf samengestelde lijst van SP 1 is te vinden in de documentatie van Succinct, en je zult zien dat het bijna alle belangrijke "computationele" opcodes in de EVM omvat.

Als gevolg hiervan vereisen alle aanpassingen aan de cryptografische primitieven van de basislaag dat er nieuwe "circuits" worden geschreven en gecontroleerd voor deze precompilaties, wat een ernstige beperking is.

Inderdaad, als de prestaties goed genoeg zijn, kan het relatief eenvoudig zijn om de bruikbaarheid van het "niet-EVM"-deel van de klant uit te voeren. Ik weet niet zeker of het goed genoeg is, maar ik heb minder vertrouwen in dit deel om de volgende redenen:

• "state tree computation" kan inderdaad enorm worden versneld met vriendelijke pre-compilatie zoals Poseidon.

• Het is echter niet duidelijk of "deserialisatie" op een elegante en onderhoudbare manier kan worden aangepakt.
  

• Daarnaast zijn er enkele lastige details (zoals gasmeting en verschillende controles) die onder de "blokevaluatietijd" kunnen vallen, maar eigenlijk moeten worden geclassificeerd als "niet-EVM"-onderdelen, die doorgaans kwetsbaarder zijn voor onderhoudsdruk.

Ten tweede het deel over schaalbaarheid.

Ik moet herhalen dat het voor RISC-V onmogelijk is om EVM-belastingen aan te kunnen zonder precompilatie te gebruiken, absoluut niet.

Dus de bewering in de oorspronkelijke tekst dat "de uiteindelijke bewijstijd zal worden gedomineerd door de huidige precompilatie" is technisch correct, maar het is overdreven optimistisch - het gaat ervan uit dat er in de toekomst geen precompilatie zal zijn, terwijl precompilatie in feite (in dit toekomstige scenario) nog steeds zal bestaan, en is precies hetzelfde als de rekenintensieve opcodes in de EVM (zoals handtekeningen, hashes en mogelijk grote analogen).

Het is moeilijk om het Fibonacci-voorbeeld te beoordelen zonder in de meest subtiele details te treden, maar de voordelen komen in ieder geval gedeeltelijk:

• het verschil tussen interpretatie en uitvoering overhead;

• Cyclische afwikkeling (het verminderen van de "control flow" van RISC-V, het is onzeker of Solidity kan worden geïmplementeerd, maar zelfs een enkele opcode kan nog steeds een groot aantal control flow/geheugentoegangen genereren vanwege interpretatie-overhead);

• kleinere gegevenstypen gebruiken;

Hier wil ik erop wijzen dat om de voordelen van punt 1 en punt 2 te realiseren, de "interpretatie-overhead" moet worden geëlimineerd. Dit is in lijn met de filosofie van RISC-V, maar dit is niet de RISC-V waar we het momenteel over hebben, maar eerder een vergelijkbare "(?)RISC-V" - het vereist bepaalde extra mogelijkheden, zoals ondersteuning voor contractconcepten.

Hier komt het probleem

, dus er zijn hier enkele problemen.

• Om de onderhoudbaarheid te verbeteren, heb je een RISC-V (met precompilatie) nodig die de EVM compileert - dat is het zo'n beetje.

• Om de schaalbaarheid te verbeteren, is iets heel anders nodig: een nieuwe architectuur die vergelijkbaar kan zijn met RISC-V die het concept van "contracten" begrijpt, compatibel is met Ethereum-runtimebeperkingen en contractcode rechtstreeks kan uitvoeren (zonder de "interpretatie-overhead").

Ik ga er nu van uit dat je verwijst naar het tweede geval (aangezien de rest van het artikel dat lijkt te impliceren). Ik moet uw aandacht vestigen op het feit dat alle code buiten deze omgeving nog steeds in de huidige RISC-V zkVM-taal zal worden geschreven, wat een aanzienlijke impact heeft op het onderhoud.

Als alternatief

kunnen we de bytecode compileren uit de high-level EVM opcode. De compiler is verantwoordelijk om ervoor te zorgen dat de builder invariant blijft, bijvoorbeeld door geen "stack overflow" te ervaren. Ik zou dit graag zien in een normale EVM. Goed samengestelde SNARK's kunnen worden voorzien van instructies voor contractimplementatie.

We kunnen ook een "formeel bewijs" construeren dat bewijst dat sommige invarianten behouden blijven. Voor zover ik weet, is deze benadering (niet "virtualisatie") in sommige browsercontexten gebruikt. Door SNARK's van dit formele bewijs te genereren, kunt u vergelijkbare resultaten bereiken. 

De gemakkelijkste optie is natuurlijk om de knoop door te bijten en ......

Het bouwen van een minimale "geketende" MMU,

die je impliciet in het artikel mag aangeven, maar laat me waarschuwen dat als je virtualisatie-overhead wilt elimineren, je de gecompileerde code rechtstreeks moet uitvoeren - wat betekent dat je op de een of andere manier moet voorkomen dat het contract (nu uitvoerbaar) naar het geheugen van de kernel schrijft (geen EVM-implementatie).

Daarom hebben we een soort "memory management unit" (MMU) nodig. Het paging-mechanisme van traditionele computers is misschien niet nodig omdat de "fysieke" geheugenruimte bijna oneindig is. Deze MMU moet zo slank mogelijk zijn (omdat het zich op hetzelfde abstractieniveau bevindt als de architectuur zelf), maar sommige functies, zoals de atomiciteit van transacties, kunnen naar deze laag worden verplaatst.

Op dit punt wordt de bewijsbare EVM het kernelprogramma dat op deze architectuur draait.

RISC-V is misschien niet de beste optie

Interessant is dat in al deze omstandigheden de beste "instructiesetarchitectuur" (ISA) voor deze taak misschien niet RISC-V is, maar iets vergelijkbaars met EOF-EVM om de volgende redenen:

• "Kleine" opcodes resulteren in feite in veel geheugentoegang, wat moeilijk is voor bestaande attestmethoden om efficiënt te verwerken.

• Om de overhead van vertakkingen te verminderen, hebben we in ons recente artikel, Morgana, laten zien hoe "statische sprongen" (EOF)-code kunnen worden bewezen met prestaties op precompilatieniveau.

Mijn suggestie is om een nieuwe proof-vriendelijke architectuur te bouwen met een minimale MMU die het mogelijk maakt om het contract als een afzonderlijk uitvoerbaar bestand uit te voeren. Ik denk niet dat het RISC-V moet zijn, maar eerder een nieuwe ISA die is geoptimaliseerd voor SNARK-protocolbeperkingen, en zelfs een ISA die gedeeltelijk een subset van EVM-opcodes erft, is misschien beter - zoals we weten, is precompilatie een blijvertje, of we het nu leuk vinden of niet, dus RISC-V brengt hier geen vereenvoudiging.