Vývojáři vyvracejí Vitalika: předpoklady jsou nesprávné a RISC-V není nejlepší volbou

Tento článek je z: Vývojář Etherea levochka.eth

kompilace|Odaily Planet Daily (@OdailyChina); @azuma_eth Poznámka redakce

:

Včera spoluzakladatel Etherea Vitalik vydal radikální článek o upgradu prováděcí vrstvy Etherea (viz "Vitalikův radikální nový článek: Škálování prováděcí vrstvy "nerozbije se, nestojí", EVM musí být v budoucnu iterováno), přičemž zmiňuje, že doufá, že jej nahradí RISC-V EVM jako jazyk virtuálních strojů pro chytré kontrakty.

Jakmile tento článek vyšel, okamžitě vyvolal rozruch v komunitě vývojářů Etherea a mnoho technických papalášů vyjádřilo na plán různé názory. Krátce po zveřejnění článku napsal vývojář Etherea úrovně 1 levochka.eth dlouhý článek pod původní článek, který vyvrací Vitalikovo tvrzení, že Vitalik učinil nesprávné předpoklady o důkazním systému a jeho výkonu a že RISC-V nemusí být nejlepší volbou, protože nedokáže vyvážit "škálovatelnost" a "udržovatelnost".

Následuje původní článek na levochka.eth, který sestavil deník Odaily.

Prosím, nedělejte to.

Tento plán nedává smysl, protože vytváříte nesprávné předpoklady o dokazování systému a jeho výkonu.

Hypotéza validace

Jak tomu rozumím, hlavními argumenty pro toto schéma jsou "škálovatelnost" a "udržovatelnost".

Nejprve chci mluvit o udržovatelnosti.

Ve skutečnosti všechny RISC-V zk-VMs vyžadují "předkompilace" pro zpracování výpočetně náročných operací. Předkompilovaný seznam SP 1 lze nalézt v dokumentaci Succinctu a zjistíte, že pokrývá téměř všechny důležité "výpočetní" operační kódy v EVM.

Výsledkem je, že všechny modifikace kryptografických primitiv základní vrstvy vyžadují napsání a auditování nových "obvodů" pro tyto předkompilace, což je závažné omezení.

Pokud je totiž výkon dostatečně dobrý, může být relativně snadné provést obslužnost "non-EVM" části klienta. Nejsem si jistý, jestli je to dost dobré, ale jsem si v této části méně jistý z následujících důvodů:

• "výpočty stavových stromů" mohou být skutečně velmi urychleny přátelským předkompilováním jako je Poseidon.

• Není však jasné, zda lze "deserializaci" zvládnout elegantním a udržovatelným způsobem.
  

• Kromě toho existují některé složité detaily (jako je měření plynu a různé kontroly), které mohou spadat pod "dobu hodnocení bloku", ale ve skutečnosti by měly být klasifikovány jako "non-EVM" díly, které mají tendenci být citlivější na tlak údržby.

Za druhé, část o škálovatelnosti.

Musím zopakovat, že je nemožné, aby RISC-V zvládl načítání EVM bez použití předkompilace, rozhodně ne.

Takže tvrzení v původním textu, že "konečnému času důkazu bude dominovat aktuální operace předkompilace", je technicky správné, ale je příliš optimistické - předpokládá, že v budoucnu nebude žádná předkompilace, když ve skutečnosti (v tomto budoucím scénáři) bude předkompilace stále existovat a je přesně stejná jako výpočetně náročné operační kódy v EVM (jako jsou podpisy, hashe a možná velké analogy).

Je těžké posoudit Fibonacciho příklad, aniž bychom se dostali do nejjemnějších detailů, ale výhody přicházejí alespoň částečně:

• rozdíl mezi interpretací a režijní zátěží provedení;

• Cyklické odvíjení (snižuje "řídicí tok" RISC-V, není jisté, zda lze implementovat Solidity, ale i jediný operační kód může stále generovat velký počet přístupů k řídicímu toku/paměti kvůli režii interpretace);

• používat menší datové typy;

Zde bych rád poukázal na to, že aby bylo možné realizovat přínosy bodů 1 a 2, musí být eliminována "režie výkladu". To je v souladu s filozofií RISC-V, ale nejedná se o RISC-V, o kterém právě diskutujeme, ale spíše o podobné "(?)RISC-V" - vyžaduje určité další schopnosti, jako je podpora konceptů smluv.

Zde přichází problém

, takže zde jsou nějaké problémy.

• Chcete-li zlepšit udržovatelnost, potřebujete RISC-V (s předkompilací), který zkompiluje EVM - to je v podstatě vše.

• Ke zlepšení škálovatelnosti je zapotřebí něco úplně jiného – nová architektura, která by mohla být podobná RISC-V, která rozumí konceptu "smluv", je kompatibilní s omezeními běhu Etherea a dokáže přímo spouštět kód kontraktu (bez "režie výkladu").

Nyní předpokládám, že máte na mysli druhý případ (protože zbytek článku to zřejmě naznačuje). Musím vás upozornit na fakt, že veškerý kód mimo toto prostředí bude stále napsán v současném jazyce RISC-V zkVM, což má významný dopad na údržbu.

Jako alternativu

můžeme zkompilovat bytecode z vysokoúrovňového OPDu EVM. Kompilátor je zodpovědný za zajištění toho, aby tvůrce zůstal neměnný, například aby nedocházelo k "přetečení zásobníku". Rád bych to viděl zobrazené v normálním EVM. Správně zkompilované SNARKy mohou být doplněny o smluvní instrukce k nasazení.

Můžeme také zkonstruovat "formální důkaz", který dokazuje, že některé invarianty jsou zachovány. Pokud vím, tento přístup (nikoli "virtualizace") byl použit v některých kontextech prohlížečů. Generováním SNARKů tohoto formálního důkazu můžete dosáhnout podobných výsledků. 

Nejjednodušší možností je samozřejmě zatnout zuby a udělat ......

Sestavení minimálního "zřetězeného" MMU

, což můžete v článku implicitně vyjádřit, ale upozorňuji, že pokud chcete eliminovat virtualizační režii, musíte přímo spustit zkompilovaný kód — což znamená, že musíte nějak zabránit tomu, aby se kontrakt (nyní spustitelný) zapisoval do paměti jádra (nikoli implementace EVM).

Proto potřebujeme nějakou "jednotku pro správu paměti" (MMU). Stránkovací mechanismus tradičních počítačů nemusí být nutný, protože "fyzický" paměťový prostor je téměř nekonečný. Tato MMU by měla být co nejštíhlejší (protože je na stejné úrovni abstrakce jako samotná architektura), ale některé vlastnosti jako atomicita transakcí lze přesunout do této vrstvy.

V tomto okamžiku se prokazatelný EVM stává jádrem programu běžícího na této architektuře.

RISC-V nemusí být nejlepší volbou

Zajímavé je, že za všech těchto podmínek nemusí být nejlepší "architektura instrukční sady" (ISA) pro tento úkol RISC-V, ale něco podobného EOF-EVM z následujících důvodů:

• "Malé" operační kódy ve skutečnosti vedou k velkému přístupu k paměti, což je pro stávající metody ověření obtížné efektivně zvládnout.

• Abychom snížili režii větvení, ukázali jsme, jak dokázat kód "statických skoků" (EOF) s výkonem na úrovni předkompilace v našem nedávném článku Morgana.

Můj návrh je vytvořit novou architekturu přátelskou k důkazům s minimální MMU, která umožňuje, aby kontrakt běžel jako samostatný spustitelný soubor. Nemyslím si, že by to mělo být RISC-V, ale spíše nová ISA optimalizovaná pro omezení protokolu SNARK a dokonce i ISA, která částečně dědí podmnožinu operačních kódů EVM, by mohla být lepší - jak víme, předkompilace tu zůstane, ať se nám to líbí nebo ne, takže RISC-V zde nepřináší žádné zjednodušení.