Plné znění Vitalikova dlouhodobého návrhu L1 výkonné vrstvy: nahrazení EVM RISC-V

Zdroj: Vitalik Buterin

Kompilace: KarenZ, Prognostické novinky

20. dubna představil Vitalik Buterin důležitý návrh na platformě Ethereum Magicians pro dlouhodobou prováděcí vrstvu L1 Etherea. Navrhl nahradit stávající EVM (Ethereum Virtual Machine) architekturou RISC-V jako virtuálním strojovým jazykem pro psaní chytrých kontraktů, jehož cílem je zásadně zlepšit provozní efektivitu prováděcí vrstvy Etherea, prolomit jedno ze současných hlavních úzkých hrdel škálování a výrazně zjednodušit jednoduchost prováděcí vrstvy.

Foresight News sestavily plný text návrhu, aby pomohly čtenářům pochopit tuto technickou vizi. Následuje kompilace původního návrhu:

Tento článek představuje radikální myšlenku o budoucnosti prováděcí vrstvy Ethereum, která není o nic méně ambiciózní než iniciativy Beam Chain konsensuální vrstvy. Cílem návrhu je dramaticky zlepšit efektivitu prováděcí vrstvy Etherea, vyřešit jednu z hlavních překážek škálování a výrazně zjednodušit prováděcí vrstvu – ve skutečnosti to může být jediný způsob, jak toho dosáhnout.

Základní myšlenka: Nahradit EVM RISC-V jako jazyk virtuálních strojů pro chytré kontrakty.

Důležité poznámky:

• Pojmy jako systém účtů, volání napříč smlouvami, úložiště atd. budou plně zachovány. Tyto abstraktní návrhy fungují dobře a vývojáři jsou zvyklí je používat. OPERAČNÍ KÓDY JAKO SLOAD, SSTORE, BALANCE, CALL ATD. JSOU PŘEVEDENY NA SYSTÉMOVÁ VOLÁNÍ RISC-V.

• V tomto režimu lze chytré smlouvy zapisovat v Rustu, ale očekávám, že většina vývojářů bude i nadále psát smlouvy v Solidity (nebo Vyper), která se přizpůsobí RISC-V jako novému backendu. Protože chytré smlouvy napsané v Rustu jsou ve skutečnosti méně čitelné, zatímco Solidity a Vyper jsou jasnější a snadněji čitelné. Prostředí vývoje může být téměř neovlivněno a vývojáři si změny nemusí ani všimnout.

• Stará smlouva EVM bude nadále běžet a je plně obousměrně kompatibilní s novou smlouvou RISC-V. Existuje několik způsobů, jak toho dosáhnout, které budou podrobněji popsány dále v tomto článku.

Nervos CKB VM vytvořil precedens a je v podstatě implementací RISC-V.

Proč?

V krátkodobém horizontu budou nadcházející EIP (např. přístupové seznamy na úrovni bloků, odložené provádění, distribuované úložiště historie a EIP-4444) řešit hlavní úzká místa škálování Ethereum L1. Další problémy budou ve střednědobém horizontu vyřešeny pomocí osob bez státní příslušnosti a ZK-EVM. V dlouhodobém horizontu budou hlavními limitujícími faktory pro škálování Ethereum L1:

1. Stabilita dostupnosti dat, vzorkování a historických protokolů pro ukládání dat

2. Udržet poptávku po konkurenci na trhu výroby bloků

3. Důkaz ZK-EVM

Budu argumentovat, že nahrazení ZK-EVM RISC-V může vyřešit klíčová úzká místa v (2) a (3).

Následující tabulka znázorňuje počet cyklů požadovaných pro každý krok prováděcí vrstvy Succinct ZK-EVM Proof EVM:

Popis diagramu: Čtyři hlavní časově náročné segmenty jsou deserialize_inputs, initialize_witness_db, state_root_computation a block_execution

initialize_witness_db a state_root_computation se vztahují ke stavovým stromům a deserialize_inputs zahrnují proces převodu blokových a svědkových dat na interní reprezentace – více než 50 % z nich je ve skutečnosti úměrných velikosti pamětních dat.

Tyto sekce mohou být výrazně optimalizovány nahrazením současného keccak 16-ary Merkle patricia tree binárním stromem, který používá snadno dokazatelnou hashovací funkci. Pokud použijeme Poseidon, můžeme na notebooku dokázat 2 miliony hashů za sekundu (oproti asi 15 000 hash/sec u keččaku). Kromě Poseidonu existuje mnoho dalších možností. Celkově je u těchto komponent velký prostor pro optimalizaci. Kromě toho můžeme odstranit accrue_logs_bloom odstraněním výkvětu.

Zbývající block_execution představuje asi polovinu současných dokazovacích cyklů. K dosažení 100násobného zvýšení celkové účinnosti důkazu je vyžadována účinnost důkazu EVM alespoň 50x. Jedním řešením je vytvořit efektivnější implementaci důkazu pro EVM a druhým je všimnout si, že současný ZK-EVM prover ve skutečnosti kompiluje EVM do RISC-V pro důkaz, což vývojářům chytrých kontraktů poskytuje přímý přístup k virtuálnímu stroji RISC-V.

Některé údaje ukazují, že v určitých situacích může dojít k více než 100násobnému zvýšení efektivity:

V praxi může být zbývající čas předkompilace většinou obsazen aktuální operací předkompilace. S RISC-V jako primárním virtuálním počítačem bude plán plynu odrážet skutečný čas ověření a ekonomický tlak povede vývojáře k omezení používání vysoce nákladné předkompilace. Ani pak nebudou zisky tak významné, ale máme dobrý důvod věřit, že budou podstatné.

(Stojí za zmínku, že doba potřebná pro "operace EVM" a "další operace" při běžném provádění EVM se také blíží 50/50, takže intuitivně předpokládáme, že odstranění EVM jako "mezivrstvy" přinese stejně významný zisk.)

Podrobnosti o implementaci

Existuje několik způsobů, jak tento návrh implementovat. Nejméně rušivým řešením je podporovat oba virtuální stroje a umožnit sepsání smlouvy v jednom z nich. Oba typy smluv mají přístup ke stejným funkcím: trvalé úložiště (SLOAD/SSTORE), schopnost držet zůstatky ETH, iniciovat/přijímat hovory a další. Kontrakty EVM a RISC-V lze volat vzájemně - z pohledu RISC-V je volání kontraktu EVM ekvivalentní provedení systémového volání se speciálními parametry; Kontrakt EVM, který zprávu přijme, ji bude interpretovat jako CALL.

Radikálnějším přístupem z hlediska protokolu je převést existující kontrakt EVM na kontrakt interpreta volání EVM napsaný v RISC-V pro spuštění stávajícího kódu EVM. To znamená, že pokud má kontrakt EVM kód C a interpret EVM je na adrese X, pak bude kontrakt nahrazen logikou nejvyšší úrovně, která při volání zvenčí s argumentem volání D volá X a předá (C, D), poté čeká na návratovou hodnotu a předá. Pokud samotný interpret EVM volá kontrakt a žádá o spuštění CALL nebo SLOAD/SSTORE, pak kontrakt tyto operace provede.

Kompromisem je druhá možnost, ale s explicitní podporou konceptu "interpretu virtuálních strojů" prostřednictvím protokolu, který vyžaduje, aby jeho logika byla napsána v RISC-V. EVM bude první instancí, s podporou dalších jazyků v budoucnu (Move může být kandidátem).

Hlavní výhodou druhé a třetí možnosti je, že výrazně zjednodušují specifikaci prováděcí vrstvy. VZHLEDEM K OBTÍŽNOSTI I ODSTRANĚNÍ POSTUPNÝCH ZJEDNODUŠENÍ, JAKO JE SEBEDESTRUKCE, MŮŽE BÝT TENTO ZPŮSOB UVAŽOVÁNÍ JEDINOU SCHŮDNOU CESTOU KE ZJEDNODUŠENÍ. Tinygrad se drží tvrdého pravidla "ne více než 10 000 řádků kódu" a optimální blockchain by měl být schopen tento limit snadno splnit a dále jej zefektivnit. Iniciativa Beam Chain slibuje dramatické zjednodušení konsensuální vrstvy Etherea a taková radikální změna může být jediným způsobem, jak dosáhnout podobného posílení na prováděcí vrstvě.