Utvecklarna motbevisar Vitalik: antagandena är felaktiga och RISC-V är inte det bästa valet

Den här artikeln är från: Ethereum-utvecklaren levochka.eth

compilation|Odaily Planet Daily (@OdailyChina); @azuma_eth Redaktörens

anmärkning:

Igår släppte Ethereums medgrundare Vitalik en radikal artikel om uppgraderingen av Ethereums exekveringslager (se "Vitaliks radikala nya artikel: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), och nämnde att han hoppas kunna ersätta den med RISC-V EVM som ett virtuellt maskinspråk för smarta kontrakt.

Så fort den här artikeln kom ut orsakade den omedelbart ett rabalder i Ethereums utvecklargemenskap, och många tekniska höjdare uttryckte olika åsikter om planen. Kort efter att artikeln publicerades skrev Tier-1 Ethereum-utvecklaren levochka.eth en lång artikel under den ursprungliga artikeln där han motbevisade Vitaliks argument att Vitalik hade gjort felaktiga antaganden om bevissystemet och dess prestanda, och att RISC-V kanske inte var det bästa valet eftersom det inte kunde balansera "skalbarhet" och "underhållsbarhet".

Följande är den ursprungliga artikeln på levochka.eth, sammanställd av dagstidningen Odaily.

Gör inte detta.

Den här planen är inte meningsfull eftersom du gör felaktiga antaganden om att bevisa systemet och dess prestanda.

Valideringshypotes

Som jag förstår det är de viktigaste argumenten för detta schema "skalbarhet" och "underhållsbarhet".

Först vill jag prata om underhållsbarhet.

Faktum är att alla RISC-V zk-VM:er kräver "förkompileringar" för att hantera beräkningsintensiva åtgärder. Den förkompilerade listan över SP 1 finns i Succincts dokumentation, och du kommer att upptäcka att den täcker nästan alla viktiga "beräkningsmässiga" opkoder i EVM.

Som ett resultat av detta kräver alla ändringar av baslagrets kryptografiska primitiver att nya "kretsar" skrivs och granskas för dessa förkompileringar, vilket är en allvarlig begränsning.

Faktum är att om prestandan är tillräckligt bra kan det vara relativt enkelt att utföra användbarheten hos den "icke-EVM" delen av klienten. Jag är inte säker på om det är tillräckligt bra, men jag är mindre säker på den här delen av följande skäl:

• "tillståndsträdsberäkning" kan verkligen påskyndas kraftigt med vänlig förkompilering som Poseidon.

• Det är dock inte klart om "deserialisering" kan hanteras på ett elegant och underhållbart sätt.
  

• Dessutom finns det några knepiga detaljer (t.ex. gasmätning och olika kontroller) som kan falla under "blockutvärderingstiden" men som faktiskt bör klassificeras som "icke-EVM"-delar, som tenderar att vara mer sårbara för underhållstryck.

För det andra, delen om skalbarhet.

Jag måste upprepa att det är omöjligt för RISC-V att hantera EVM-belastningar utan att använda förkompilering, absolut inte.

Så påståendet i den ursprungliga texten att "den slutliga bevistiden kommer att domineras av den aktuella förkompileringsoperationen" är tekniskt korrekt, men det är överdrivet optimistiskt - det förutsätter att det inte kommer att finnas någon förkompilering i framtiden, när det i själva verket (i detta framtida scenario) fortfarande kommer att finnas förkompilering, och är exakt detsamma som de beräkningsintensiva opkoderna i EVM (såsom signaturer, hash och möjligen stora analoger).

Det är svårt att bedöma Fibonacci-exemplet utan att gå in på de mest subtila detaljerna, men fördelarna kommer åtminstone delvis:

• skillnaden mellan tolkning och utförande overhead;

• Cyklisk avlindning (minskar "kontrollflödet" för RISC-V, det är osäkert om Solidity kan implementeras, men även en enda opkod kan fortfarande generera ett stort antal kontrollflöden/minnesåtkomster på grund av tolkningsoverhead);

• använda mindre datatyper;

Här skulle jag vilja påpeka att för att förverkliga fördelarna med punkterna 1 och 2 måste "tolkningsoverheaden" elimineras. Detta är i linje med filosofin bakom RISC-V, men det är inte det RISC-V som vi för närvarande diskuterar, utan snarare ett liknande "(?)RISC-V" - det kräver vissa ytterligare funktioner, t.ex. stöd för kontraktskoncept.

Här kommer problemet

, så det finns några problem här.

• För att förbättra underhållet behöver du en RISC-V (med förkompilering) som kompilerar EVM - det är i stort sett allt.

• För att förbättra skalbarheten behövs något helt annat – en ny arkitektur som kan likna RISC-V och som förstår begreppet "kontrakt", är kompatibel med Ethereums körtidsbegränsningar och kan exekvera kontraktskod direkt (utan "tolkningsoverhead").

Jag antar nu att du hänvisar till det andra fallet (eftersom resten av artikeln verkar antyda det). Jag måste uppmärksamma dig på det faktum att all kod utanför den här miljön fortfarande kommer att skrivas i det aktuella RISC-V zkVM-språket, vilket har en betydande inverkan på underhållet.

Som ett alternativ

kan vi kompilera bytekoden från EVM-opkoden på hög nivå. Kompilatorn ansvarar för att se till att byggaren förblir invariant, till exempel att inte uppleva ett "stackspill". Jag skulle vilja se detta visas i en normal EVM. Korrekt kompilerade SNARK:er kan tillhandahållas med instruktioner för kontraktsdistribution.

Vi kan också konstruera ett "formellt bevis" som bevisar att vissa invarianter är bevarade. Såvitt jag kan se har detta tillvägagångssätt (inte "virtualisering") använts i vissa webbläsarsammanhang. Genom att generera SNARK:er av detta formella bevis kan du uppnå liknande resultat. 

Det enklaste alternativet är naturligtvis att bita ihop och göra ......

Att bygga en minimal "kedjad" MMU,

som du kanske implicit uttrycker i artikeln, men låt mig varna för att om du vill eliminera virtualiseringsoverhead måste du köra den kompilerade koden direkt - vilket innebär att du på något sätt måste förhindra kontraktet (nu körbart) från att skriva till kärnans (inte en EVM-implementering) minne.

Därför behöver vi någon form av "minneshanteringsenhet" (MMU). Växlingsmekanismen för traditionella datorer kanske inte är nödvändig eftersom det "fysiska" minnesutrymmet är nästan oändligt. Denna MMU bör vara så mager som möjligt (eftersom den är på samma abstraktionsnivå som själva arkitekturen), men vissa funktioner, till exempel atomicitet för transaktioner, kan flyttas till detta lager.

Vid denna tidpunkt blir den bevisbara EVM:en kärnprogrammet som körs på denna arkitektur.

RISC-V kanske inte är det bästa alternativet

Intressant nog är den bästa "instruktionsuppsättningsarkitekturen" (ISA) för den här uppgiften kanske inte RISC-V, utan något som liknar EOF-EVM av följande skäl:

• "Små" opkoder resulterar faktiskt i mycket minnesåtkomst, vilket är svårt för befintliga attesteringsmetoder att hantera effektivt.

• För att minska förgreningskostnaderna visade vi hur man bevisar EOF-kod (Static Jumps) med prestanda på förkompileringsnivå i vår senaste artikel, Morgana.

Mitt förslag är att bygga en ny bevisvänlig arkitektur med ett minimalt MMU som gör att kontraktet kan köras som en separat körbar fil. Jag tror inte att det är tänkt att vara RISC-V, utan snarare en ny ISA optimerad för SNARK-protokollbegränsningar, och till och med en ISA som delvis ärver en delmängd av EVM-opkoder kan vara bättre - som vi vet är förkompilering här för att stanna, vare sig vi gillar det eller inte, så RISC-V ger ingen förenkling här.