Původní autor: PSE Trading Analyst @cryptohawk

TL;DR
Virtuální stroj je softwarově emulovaný počítačový systém, který poskytuje spouštěcí prostředí pro programy. Dokáže simulovat různá hardwarová zařízení a umožňuje běh programů v kontrolovaném a kompatibilním prostředí.
Virtuální stroj Ethereum (EVM) je virtuální stroj založený na zásobníku, který se používá k provádění chytrých smluv Ethereum zkEVM provedl určité optimalizace efektivity generování EVM, které jsou odolné vůči zk;
zkVM opouští ekvivalenci/kompatibilitu EVM a zvyšuje prioritu přívětivosti zk;
Privacy zkVM překrývá nativní funkce ochrany osobních údajů na zkVM;
SVM, FuelVM a MoveVM mají společnou snahu o maximální výkon prostřednictvím paralelního provádění, ale mají své vlastní charakteristiky v konstrukčních detailech;
ESC VM a BitVM provedly určité inovativní experimenty s výpočetní vrstvou na řetězcích ETH a BTC, ale skutečná poptávka po implementaci je v současném prostředí nízká.
Obrovský uživatelský ekosystém EVM určuje, že jakákoli blockchainová síť, která ji opustí, jí bude v krátkodobém horizontu těžko konkurovat. Proto ekosystém mimo EVM zavádí ekologické uživatele EVM prostřednictvím překladatelů/kompilátorů/překladačů bajtových kódů a dokonce vrstev kompatibility VM, aby využívali ne. -EVM Použití funkcí virtuálního stroje k vytvoření nového ekologického příběhu může být nezbytnou cestou k úspěchu.
1.1 Co je VM?
Virtuální stroj (VM) je stavebním blokem virtualizovaných výpočetních zdrojů, který provádí téměř stejné funkce jako počítač, včetně spouštění aplikací a operačních systémů. Koncept virtuálních strojů není nový a tato technologie je široce používána v mnoha technologických ekosystémech.
V kontextu blockchainu je virtuální stroj (VM) kus softwaru, který spouští programy, často označovaný jako běhové prostředí, které provádí blockchainové smart kontrakty. Virtuální stroje obvykle poskytují prostředí virtuálního počítače simulací různých hardwarových zařízení. Hardwarová zařízení, která mohou různé virtuální stroje simulovat, se liší, ale obvykle zahrnují CPU, paměť, pevný disk, síťové rozhraní atd. Při odeslání transakce v řetězci je virtuální stroj zodpovědný za zpracování transakce a aktualizaci stavu blockchainu (aktuálního globálního stavu celé sítě) ovlivněného provedením transakce. Konkrétní pravidla pro změnu stavu sítě definuje virtuální počítač. Při zpracování transakce virtuální počítač převede kód inteligentní smlouvy do formátu, který může provést hardware uzlu/validátoru.
Nejdůležitějším jádrem mezi VM je LLVM (low-level-virtual-machine), které lze považovat za nejdůležitější jádro kompilátoru. Obrázek ukazuje původní operační schéma EVM Smart kontrakt je převeden přes mezikód LLVM IR a převeden na Bytecode. Tyto bajtové kódy budou uloženy na blockchainu, když je zavolána smart smlouva, bajtové kódy budou převedeny na odpovídající operační kódy, které pak budou provedeny EVM a hardwarem uzlu.

1.2 Běžný VM
1.2.1 EVM – Blockchain VM má celkem jeden kámen, EVM má výhradně osm bucketů a zbytek je rozdělen do dvou bucketů.
Reprezentativní projekty: Optimismus, Arbitrum
Jako blockchainový ekosystém s nejaktivnějšími vývojářskými uživateli v oboru je virtuální stroj Ethereum (EVM) virtuální stroj založený na zásobníku, který poskytuje prostředí virtuálního počítače simulací hardwarových zařízení, jako je CPU, paměť, úložiště a zásobníky. provádět instrukce smart kontraktu a ukládat stav a data smart kontraktu. Instrukční sada EVM obsahuje různé operační kódy Opcode, jako jsou aritmetické operace, logické operace, operace ukládání, operace skoků atd.

Paměť a úložiště simulované EVM jsou zařízení používaná k ukládání stavu a dat smart kontraktů. EVM zachází s pamětí a úložištěm jako se dvěma různými oblastmi a může přistupovat ke stavu a datům inteligentních kontraktů čtením a zápisem paměti a úložiště.
Simulovaný zásobník EVM se používá k ukládání operandů a výsledků instrukcí. Většina instrukcí v instrukční sadě EVM je založena na zásobníku, čte operandy ze zásobníku a vkládá výsledek zpět do zásobníku.

Proces návrhu EVM je evidentně zdola nahoru Nejprve je dokončeno simulované hardwarové prostředí (zásobník, paměť) a poté je navržena vlastní sada instrukční sady pro sestavení (Opcode) a bytecode (Bytecode) podle odpovídajícího prostředí. . Komunita Ethereum navrhla dva zkompilované jazyky na vysoké úrovni – Solidity a Vyper – pro efektivitu provádění EVM. Je samozřejmé, že je třeba zdůraznit, že Vyper je EVM jazyk na vysoké úrovni navržený Vitalikem, aby vylepšil některé nedostatky existující v Solidity, ale nezískal vysoké přijetí v komunitě, takže se postupně vytratil etapa dějin.
1.2.2 zkEVM – chci to všechno: kompatibilní s prostředím EVM + podporuje transformaci globálního státního kořene pro generování zk-proof
Reprezentativní projekty: Taiko, Scroll, Polygon zkEVM
Protože EVM nebylo postaveno s ohledem na výpočet zk-proof, má vlastnosti, které jsou nepříznivé pro kontrolní obvody, zejména pokud jde o speciální operační kódy, architekturu založenou na zásobníku, režii úložiště a náklady na kontrolu. zkEVM je virtuální stroj, který provádí chytré kontrakty způsobem, který je kompatibilní s výpočty zk-proof, takže proces provádění EVM lze ověřit efektivněji a levněji prostřednictvím zk-proof/validity-proof. Ve srovnání s OP Rollup potřebuje prováděcí vrstva pouze kopírovat EVM a sestavení EVM tak, aby bylo přátelské k ZK, je pro ZK Rollup další výzvou.
ZK-rollups nejsou snadno kompatibilní s Ethereum Virtual Machine (EVM). Dokazování obecných výpočtů EVM v okruhu je obtížnější a náročnější na zdroje než dokazování jednoduchých výpočtů (jako je dříve popsaný přenos tokenů).
Pokrok v technologii nulových znalostí (otevře se na nové kartě) však znovu podnítil zájem o zabalení výpočtů EVM do důkazů s nulovými znalostmi. Cílem těchto snah je vytvořit implementaci EVM s nulovými znalostmi (zkEVM), která dokáže efektivně ověřit správnost provádění programu. .
Stejně jako EVM i zkEVM přechází mezi stavy po provedení výpočtů na určitých vstupech. Rozdíl je v tom, že zkEVM také vytváří důkazy s nulovými znalostmi pro ověření správnosti každého kroku při provádění programu. Důkazy platnosti ověřují správnost operací týkajících se stavu virtuálního stroje (paměť, zásobník, úložiště) a samotného výpočtu (tj. volala operace správné operační kódy a provedla je správně?).

Myšlenka je to krásná, ale realita je velmi hubená V současné době je pro Rollup obtížné dosáhnout jak přívětivosti ZK, tak kompatibility (nebo dokonce ekvivalence), to znamená, že musí buď co nejúplněji kopírovat prováděcí vrstvu Ethereum L1. včetně hash, stavového stromu a transakčního stromu, předkompilace atd., takže klient pro provádění Ethereum L1 může být použit tak, jak je, ke zpracování bloků Rollup nebo k odstranění kompatibility EVM a opětovnému vytvoření stávajícího operačního kódu pro ověřování/ověření v rámci okruhu; , umožňující inteligentní realizaci smluv .
1.2.3 zkVM – Nemůžete si dát svůj dort a také ho sníst: virtuální stroj bez evm zaměřený na efektivitu zk
Reprezentativní projekty: Starknet, Zksync, RISC ZERO
zkVM opouští kompatibilitu EVM, bere jako své hlavní cíle kontrolu dat a aktualizaci stavu a nachází společného jmenovatele mezi kryptografií a jazyky na vysoké úrovni, aby poskytl společný rámec pro různé aplikace.
Od doby, kdy Starkware začal dříve v celém oboru ZK, nashromáždil dostatek technologií a má určitý technologický náskok. Jedná se o reprezentativní technickou architekturu zaměřenou na ZK a Cairo VM a Cairo language jsou postaveny na ZK. Nevýhodou je, že náklady na učení v Káhiře jsou poměrně vysoké.
Rámec ZKsync je kompatibilní s charakteristikami EVM a ZK, integruje Solidity s vlastním jazykem obvodů Zinc a sjednocuje oba na úrovni IR v kompilátoru. Výhodou je, že jádro kompilátoru LLVM je kompatibilní s více jazyky.
RISC Zero využívá architekturu RISC-V k vytvoření simulátoru, který umožňuje programátorům psát programy pro zkVM v běžných jazycích, jako je Rust, C/C++ a Go To znamená, že aplikační logika se nemusí omezovat na co lze vyjádřit v Solidity, což umožňuje zápis a řetězení irelevantního kódu.
1.2.4 Privacy zkVM – zk friendly + nativní podpora ochrany soukromí se pokouší zažehnout novou ekologickou jiskru
Reprezentativní projekty: Aleo, Ola, Polygon Miden
Blockchain slouží jako systém veřejné knihy a všechny transakce jsou prováděny v řetězci, což znamená, že změny stavu obsahující informace o majetku související s adresami nebo účty jsou otevřené a transparentní. Proto se některé blockchainové týmy kromě práce na škálovacích řešeních domnívají, že další klíčovou funkcí, kterou je třeba implementovat, je soukromí.
Privacy zkVM Kromě funkcí zk-friendly podpory pro rozšíření, díky funkcím ochrany soukromí nativně podporovaným vlastním programovacím jazykem, mohou vývojáři aplikací na vyšší vrstvě vyvíjet dapps související s ochranou soukromí, které přinesou nové aplikační scénáře a velké příběhy. Například zcela vyřešit problém MEV a chránit vlastnictví uživatelských dat. Složitost návrhu Privacy zkVM samozřejmě vyžaduje větší technický tým, aby jej implementoval, a jeho dosažení může trvat několik let.
1.2.5 SVM – Po opadnutí přílivu stále existují žhavé uhlíky: prováděcí prostředí, kde výkonnostní design dosáhl extrému
Reprezentativní projekty: Eclipse Mainnet, Nitro, MakerDAO Chain (možná)
SVM, virtuální stroj Solana, se zaměřuje na vysoce výkonné exekuční prostředí a chytré smlouvy jsou psány hlavně v jazyce Rust. Ve srovnání s jednovláknovými prováděcími prostředími EVM a EOS WASM SVM tím, že vyžaduje, aby transakce Solana popisovaly všechny stavy, které bude transakce při provádění číst nebo zapisovat, implementuje souběžné provádění nepřekrývajících se transakcí a transakcí, které pouze čtou stejný stav.

Navíc, aby bylo možné rychle ověřit/vysílat velké transakční bloky, proces ověřování transakcí v síti Solana široce využívá optimalizace potrubí běžné v návrhu CPU. Aby byla uspokojena situace, kdy je vstupní datový tok zpracováván v sérii kroků a každý krok má na starosti jiný hardware. Typickou analogií je pračka a sušička, která pere/suší/skládá více dávek prádla za sebou. Čištění musí být provedeno před sušením a skládání musí být provedeno před sušením, ale každou z těchto tří operací provádí samostatná jednotka.

Kromě toho je SVM založen na registru a má mnohem menší instrukční sadu než EVM, takže provedení SVM se snadněji prokazuje v ZK. Pro optimistické souhrny usnadňuje návrh založený na registrech nastavení kontrolních bodů.
1.2.6 Fuel VM——buff stack: Paralelní virtuální stroj v rámci UTXO
Reprezentativní projekt: Palivo
Fuel VM je vylepšení založené na technickém rámci EVM, Solana, WASM a BTC Cosmos Ve srovnání s EVM má následující vlastnosti:

Nejunikátnější je, že Fuel nejen nastavuje přístupové seznamy podobné SVM, ale má také schopnost provádět transakce paralelně s nepřekrývajícími se transakcemi. Dále přejímá model UTXO, který se dále dělí na token UTXO a smluvní UTXO zlepšení efektivity přístupu a výpočetní propustnosti.

Kromě toho Fuel VM poskytuje výkonné a bezproblémové vývojářské prostředí prostřednictvím vlastního jazyka Sway specifického pro doménu a podpůrného řetězce nástrojů Forc, jehož vývojové prostředí si zachovává výhody inteligentních smluvních jazyků, jako je Solidity, a zároveň přijímá paradigma představené v ekosystém nástroje Rust.
V budoucnu bude Fuel VM implementovat také upgrady jazyka Sway, včetně optimalizace kompilátoru z hlediska velikosti bajtkódu, Sway bude podporovat více backendů (backend EVM je již ve vývoji), abstrakce bude ekonomičtější a bude k dispozici více aplikací. Přechod ze Solidity/Vyper na Sway, vylepšení analýzy opětovného vstupu na úrovni kompilátoru a další.
1.2.7 ESC VM – nástupce Ordinal/Smartweave: výpočetní vrstva nad Ethereem
Reprezentativní projekt: Ethscriptions Protocol
ESC VM, neboli Ethscriptions Virtual Machine, je řešení chytré smlouvy navržené protokolem Ethscriptions. Samotný Ethscriptions Protocol je protokol podobný BTC Ordinal v řetězci Ethereum, který se zaměřuje na zkoumání nízkonákladových alternativ odlišných od smart kontraktů a L2.
Ethscriptions umožňují uživatelům obejít ukládání a provádění inteligentních kontraktů za extrémně nízké náklady tím, že na data volání v Tx pro výpočet použijí předem dohodnutá pravidla protokolu. Zjednodušeně řečeno, pokud existuje úspěšná transakce Ethereum, jeho calldata odpovídají platným datovým specifikacím a jedinečná adresa "to" není 0, lze mít za to, že Ethscription byl legálně vytvořen, "od" adresa je tvůrce a "to" Adresa patří vlastníkovi.
Na začátku návrhu každý Ethscription preferuje formu NFT, jako je obrázkové NFT Obsah obrázku je přímo zapsán do dat volání ve formátu Base 64:

Nedávno populární eths je založeno na specifikaci protokolu brc-20 a bylo vytvořeno pomocí Ethscription:

Inteligentní smlouva zavedená ESC VM se nazývá hloupá smlouva, která je publikována jako logická smlouva, ale neinteraguje v řetězci ve formě EVM. Kromě toho ESC VM také přidává speciální formátový počítačový příkaz Ethscriptions vytvořené pomocí tohoto formátu budou rozpoznány ESC VM a budou interagovat s hloupými smlouvami, jako je Deploy - deploy dumb contract, Call - invoke dumb contract.
Toto řešení má určitá omezení Za prvé, funkce hloupé smlouvy není splatná. To znamená, že pokud chcete poslat ETH prostřednictvím hloupé smlouvy, musíte projít „překlenovací smlouvou“ a „překlenovací smlouvou“. samo o sobě zahrnuje zneužití kontrolních práv a rizika krádeže majetku, za druhé, existují překážky vstupu do ekosystému, které nedovolují svévolné vytváření hloupých kontraktů, a jejich kódy je třeba definovat prostřednictvím návrhu řízení Ethscriptions Protocol.
Abych to shrnul, ESC VM je výpočetní vrstva postavená na Ethereum L1 jako vrstva pro ukládání dat. Je implementována umístěním smluvní logiky, smluvních volání, smluvních volání a dalšího datového obsahu do dat volání Ethereum ESC VM The global stavový konsensus je konsensus klienta ESC VM, který je podobný implementační logice SmartWeave společnosti Arweave, kromě toho, že vrstva úložiště dat SmartWeave je Arweave.
1.2.8 Bit VM – Zajímavý výzkumný experiment: prováděcí kanál peer-to-peer na BTC
Reprezentativní projekt: ZeroSync
Zakladatel ZeroSync Robin Linus vydal 9. října bílou knihu „BitVM: Compute Anything On Bitcoin“. Abych byl přesný, nejedná se o VM, ale o pokus o vytvoření Turingova kompletního výpočetního prostoru, jehož smlouvy jsou uloženy v Bitcoin On-chain , ale logika smlouvy je prováděna mimo řetězec. Pokud se domníváte, že druhá strana porušila smlouvu, můžete zahájit výzvu v řetězci. Pokud druhá strana nemůže správně reagovat, můžete odebrat všechny prostředky ve smlouvě.
Výhodou je, že bitcoinu lze poskytnout Turingovu úplnost bez jakýchkoli úprav bitcoinového protokolu, žádné nové operační kódy, žádné soft forky a lze jej použít kdykoli.
Jeho nedostatky jsou také zřejmé. Za prvé, podporuje pouze transakce mezi dvěma stranami (jedna strana certifikuje a jedna strana ověřuje). úložiště informací mimo řetězec je obrovské.
Následuje stručný úvod do technické logiky:
(1) Klikněte pro zadání závazku
Bodový vstupní závazek umožňuje zkoušečce nastavit vstupní hodnotu 0 nebo 1 pro logické hradlo. V tomto závazku existují dvě hodnoty hash H(A 0) a H(A 1). , jako je A 0 , vstupní hodnota je nastavena na 0, a pokud je odhalena A 1, je vstupní hodnota nastavena na 1 .
(2) Závazek logické brány
Jakmile budete mít vstupní hodnotu, můžete zkombinovat libovolné logické hradlo v bitcoinovém skriptu kombinací bitcoinových AND, NOT a dalších operačních kódů.
(3) Závazek binárního okruhu
Turingovy úplnosti lze dosáhnout složením stovek milionů logických hradel do binárního obvodu. Aby bylo možné tento binární obvod odevzdat do bitcoinové sítě, musí být všechna logická hradla umístěna do listového uzlu na adrese Taproot.

(4) Odkaz výzva-odpověď
Nestačí zapojit obvod do řetězce Obě strany potřebují účinný způsob, jak ověřit, že výsledky výpočtu smlouvy jsou správné. V ideálním světě smlouva běží mimo řetěz a obě strany jsou šťastné, když spolupracují a nemají spory o výsledku. Pokud však dojde ke sporu mezi dvěma stranami transakce, musí zadat odkaz výzva-odpověď, aby ověřili výsledky výpočtu a vynutili distribuci zůstatku kanálu prostřednictvím bitcoinových skriptů.

BitVM proto zdaleka není nějakým druhem bitcoinového Rollupu nebo L2, bez kompletního prostředí pro provádění virtuálních strojů, globálního stavu, jazyka na vysoké úrovni pro publikování složitých inteligentních smluv ani neumožňuje libovolnému počtu uživatelů snadno interagovat s těmito smlouvami. . Pro ilustraci použijeme velmi oblíbený příklad: BitVM je jako postavit obří počítač, který je větší než místnost v době, kdy každý může používat mobilní terminál.
1.2.9 MoveVM—— Produkt genetické dědičnosti Facebook Web2
Reprezentativní projekty: Aptos, Sui
Move je programovací jazyk pro psaní bezpečných chytrých smluv. Původně byl vyvinut společností Facebook, aby poskytoval podporu pro blockchain Diem, projekty zastoupené společnostmi Aptos a Sui nadále používaly jazyk Move. Největší vlastností Move blockchainu je, že úložiště dat používá globální úložiště, které se skládá ze stromu zakořeněného na adrese účtu. Každá adresa může ukládat zdrojová data a kód modulu.

Move má dva různé typy programů: moduly a skripty. Moduly jsou knihovny, které definují strukturální typy a funkce, které na těchto typech fungují. Typ struktury definuje režim globálního úložiště Move a funkce modulu definuje pravidla pro aktualizaci úložiště. Samotné moduly jsou také uloženy v globálním úložišti. Skript je vstupním bodem spustitelného souboru, podobně jako hlavní funkce v tradičních jazycích, a je dočasným fragmentem kódu, který není publikován v globálním úložišti.

Stručně řečeno, modul Přesunout je podobný modulu dynamické knihovny načtenému při spuštění spustitelného souboru systému a skript je podobný hlavnímu programu. Uživatelé mohou psát své vlastní skripty pro přístup ke globálnímu úložišti, včetně volání modulů, zatímco moduly publikování nebo spouštění skriptů fungují prostřednictvím virtuálního počítače Move.
1.3 Trendy ekologického vývoje
Nyní, když je síťový efekt EVM tak silný, se migrace uživatelů EVM na ekologii řetězců mimo EVM stala největším růstovým bodem pro vznikající blockchainové projekty, což v budoucnu přinese větší složitelnost Dapp a větší konektivitu růst.
1.3.1 Kompatibilita rozhraní peněženky
Začlenění uživatelů EVM do řetězců mimo EVM bylo historicky hlavní překážkou, ale nedávno spuštěný Metamask Snap tuto bariéru prolomí. Uživatelé EVM mohou pokračovat v používání MetaMask bez přepínání peněženek. Díky open source příspěvkům Drift k vybudování vynikající implementace MetaMask Snap je UX ekvivalentní interakci s jakýmkoli EVM řetězcem. Uživatelé mainnetu Eclipse budou moci komunikovat s nativními aplikacemi v MetaMask nebo používat nativní peněženky Solana, jako je Salmon.

1.3.2 Kompatibilita backendu VM
1.3.2.1 Překladatel/překladač
Reprezentativní projekt: Wrap
Warp je překladač Solidity-Cairo, který vyvinul Nethermind, známý tým infrastruktury Ethereum. Warp umí přeložit kód Solidity do Káhiry, ale přeložený káhirský program je často potřeba upravit a přidat k němu káhirské funkce (jako je volání vestavěných funkcí, optimalizace paměti atd.), aby se maximalizovala efektivita provádění.
1.3.2.2 Vrstva kompatibility překladače bajtového kódu/VM
Reprezentativní projekty: Kakarot, Neon EVM
Kakarot je interpret bytecode EVM napsaný v Káhiře a implementovaný ve formě inteligentních kontraktů nasazených na Starknet. Simuluje zásobník, paměť, provádění a další aspekty EVM ve formě chytrých kontraktů Cairo. Ve srovnání s překladem kódu, Kakarot implementuje krok za krokem implementaci Opcode a Pre-compile za EVM a vytváří komponenty, jako je Account Registry a Blockhash Registry pro provádění dalšího zpracování mapování adresy účtu, získávání informací o blocích atd. kakarot mít vyšší nativní kompatibilitu.

Neon EVM je EVM, který běží jako chytrá smlouva a lze jej nasadit na jakýkoli řetězec SVM. Samotný mainnet Eclipse používá SVM jako prováděcí prostředí, ale přináší plnou kompatibilitu EVM (včetně podpory bytecode EVM a Ethereum JSON-RPC) prostřednictvím Neon EVM a propustnost je vyšší než u jednovláknového EVM. Kromě toho má každá instance Neon EVM svůj vlastní trh s místními poplatky, to znamená, že existuje horní limit pro výpočetní jednotky související s interakcí s jedním smluvním účtem ve výšce bloku (1/4 blokových výpočetních jednotek), takže pouze uživatelé potřebujete komunikovat s konkrétními horkými smlouvami Nebo musíte zaplatit prioritní poplatek, když je blok plný. V tomto smyslu mohou aplikace nasazující své vlastní smlouvy získat výhody aproximace aplikačních řetězců, čímž se sníží škody na uživatelské zkušenosti, bezpečnosti nebo likviditě celé sítě způsobené přetížením konkrétní smlouvy tx interakce.

Reference:
1. "Kakarot: Exploring Starknet's EVM Compatibility Road", Cynic Starknet Astro
2. „BitVM podnítí vášnivou diskusi, může bitcoinová síť dosáhnout Turingovy úplnosti?“, od Haotian
3.https://ethereum.org/en/developers/docs/evm/
4. "Technická architektura Starkware a ekologický přehled", od Maxliona
5.https://twitter.com/muneeb/status/1712461799327416491
6. "Project Research丨 Zpráva o výzkumu modulární vysokorychlostní vrstvy Execution Layer Fuel", od Web3 CN
7.https://www.fuel.network/
8.https://docs.ethscriptions.com/overview/introducing-ethscriptions
9. „Analýza první kritické zranitelnosti Aptos Move VM“ od Numen Cyber Labs
10. https://ethereum.org/en/developers/docs/evm/
11.„Co je SVM – virtuální stroj Solana“,od Squads
12. „Představujeme Eclipse Mainnet: The Ethereum SVM L2“ od Eclipse
13.https://john-hol.gitbook.io/bitvm/
14.https://bitvm.org/bitvm.pdf
15.„Různé typy ZK-EVM“,od Vitalika Buterina
16. „Cipholio Research Report: Diskuse o plánech a budoucnosti ZkVM“, YOLO SHEN, Cipholio Ventures
