Multicoin Capital Partner Kyle Samani rozvádí 7 důvodů, proč jsou modulární blockchainy nadhodnocené.

  • Napsal: Kyle Samani, Partner, Multicoin Capital

  • Sestavil: Luffy, Foresight News

V posledních dvou letech se debata o škálovatelnosti blockchainu zaměřila na ústřední téma „debaty mezi modularitou a integrací“.

Všimněte si, že diskuse o kryptoměnách často spojují „jednotné“ a „integrované“ systémy. Technická debata o integrovaných systémech versus modulární systémy trvá 40 let. Tato konverzace v kryptoměnovém prostoru by měla být zarámována stejnou optikou jako historie, a to zdaleka není nová debata.

Při zvažování modularity versus integrace je nejdůležitějším návrhovým rozhodnutím, které může blockchain učinit, rozsah, v jakém je složitost zásobníku vystavena vývojářům aplikací. Zákazníci blockchainu jsou vývojáři aplikací, takže konečná rozhodnutí o designu by měla brát v úvahu jejich perspektivu.

Dnes je modularita z velké části oslavována jako primární způsob škálování blockchainů. V tomto článku zpochybním tento předpoklad z prvních principů, odhalím kulturní mýty a skryté náklady modulárních systémů a podělím se o závěry, které jsem vyvodil z přemýšlení o této debatě za posledních šest let.

Modulární systémy zvyšují složitost vývoje

Zdaleka největší skrytou cenou modulárních systémů je přidaná složitost procesu vývoje.

Modulární systémy značně zvyšují složitost, kterou musí vývojáři aplikací spravovat, a to jak v kontextu vlastních aplikací (technická složitost), tak v kontextu interakcí s jinými aplikacemi (sociální složitost).

V kontextu kryptoměn modulární blockchainy teoreticky umožňují větší specializaci, ale za cenu vytvoření nové složitosti. Tato složitost (jak technické, tak sociální povahy) se přenáší na vývojáře aplikací, což v konečném důsledku ztěžuje vytváření aplikací.

Vezměme si například OP Stack. V současnosti se zdá, že jde o nejoblíbenější modulární framework. OP Stack nutí vývojáře, aby si vybrali mezi přijetím Zákona řetězců (který přináší spoustu sociální složitosti), nebo rozvětvením a jejich samostatnou správou. Obě možnosti vytvářejí značnou složitost pro stavitele. Pokud se rozhodnete forkovat, obdržíte technickou podporu od ostatních účastníků ekosystému (CEX, fiat on-ramp atd.), kteří musí vynaložit náklady, aby vyhověli novým technologickým standardům? Pokud se rozhodnete dodržovat Zákon řetězů, jaká pravidla a omezení vám budou dnes a zítra uložena?

Zdroj: OSI model

Moderní operační systémy (OS) jsou velké, komplexní systémy obsahující stovky subsystémů. Moderní operační systémy zvládají vrstvy 2-6 ve výše uvedeném diagramu. Toto je klasický příklad integrace modulárních komponent pro správu složitosti zásobníku vystavené vývojářům aplikací. Vývojáři aplikací se nechtějí zabývat ničím pod vrstvou 7, a proto existují operační systémy: operační systém spravuje složitost vrstev pod ní, takže vývojáři aplikací se mohou soustředit na vrstvu 7. Modularita by proto neměla být sama o sobě cílem, ale prostředkem k dosažení cíle.

Každý hlavní softwarový systém v dnešním světě – cloudové backendy, operační systémy, databázové stroje, herní stroje atd. – je vysoce integrovaný a skládá se z mnoha modulárních subsystémů. Softwarové systémy mají tendenci být vysoce integrované, aby se maximalizoval výkon a snížila složitost vývoje. Totéž platí pro blockchain.

Ethereum mimochodem snižuje složitost, která se objevila během éry bitcoinových forků v letech 2011-2014. Zastánci modularity často zdůrazňují model propojení otevřených systémů (OSI) s tím, že dostupnost dat (DA) a provádění by měly být odděleny, tento argument je však široce nepochopený. Správné pochopení dané problematiky vede k opačnému závěru: argument, že OSI je spíše integrovaný systém než modulární systém.

Modulární řetězce nemohou provádět kód rychleji

Podle návrhu je běžnou definicí „modulárního řetězce“ oddělení dostupnosti dat (DA) a provádění: jedna sada uzlů je zodpovědná za DA, zatímco jiná sada (nebo sady) uzlů jsou zodpovědné za provádění. Kolekce uzlů se nemusí překrývat, ale mohou.

V praxi oddělení DA a spouštění ze své podstaty nezlepšuje výkon ani jednoho z nich, spíše nějaký hardware někde na světě musí provádět DA a nějaký hardware někde musí implementovat spouštění. Oddělení těchto funkcí nezlepší výkon žádné z nich. Zatímco oddělení může snížit výpočetní náklady, lze jej snížit pouze centralizací provádění.

Pro zopakování: bez ohledu na modulární nebo integrovanou architekturu musí někde pracovat nějaký hardware a oddělení DA a provádění na samostatný hardware ze své podstaty nezrychlí ani nezvýší celkovou kapacitu systému.

Někteří tvrdí, že modularita umožňuje paralelnímu běhu více EVM způsobem rollup, což umožňuje provádění horizontálně škálovat. I když je to teoreticky správné, tento pohled ve skutečnosti zdůrazňuje omezení EVM jako jednovláknového procesoru spíše než základní premisu oddělení DA a provádění v kontextu škálování celkové propustnosti systému.

Samotná modularita nezlepšuje propustnost.

Modularita zvyšuje transakční náklady pro uživatele

Podle definice je každá L1 a L2 nezávislou účetní knihou aktiv s vlastním stavem. Tyto samostatné části stavu mohou komunikovat, i když s delšími transakčními latencemi a větší složitostí pro vývojáře a uživatele (prostřednictvím cross-chain mostů, jako jsou LayerZero a Wormhole).

Čím více účetních knih aktiv existuje, tím je globální stav všech účtů fragmentovanější. To je hrozné jak pro řetězce, tak pro uživatele napříč více řetězci. Fragmentace státu může přinést řadu důsledků:

  • Snížená likvidita, což má za následek vyšší skluz obchodování;

  • Více celkové spotřeby plynu (transakce napříč řetězci vyžadují alespoň dvě transakce na alespoň dvou účetních knihách aktiv);

  • Zvýšené dvojité započítávání napříč účetními knihami aktiv (čímž se snižuje celková propustnost systému): Když se cena ETH-USDC pohne na Binance nebo Coinbase, objeví se arbitrážní příležitosti na každém fondu ETH-USDC napříč všemi účetními knihami aktiv (můžete si snadno představit svět, kde pokaždé, když se cena ETH-USDC na Binance nebo Coinbase změní, existuje více než 10 transakcí v různých účetních knihách aktiv.

Je důležité si uvědomit, že vytváření více účetních knih aktiv výrazně zvyšuje náklady ve všech těchto dimenzích, zejména těch, které jsou spojené s DeFi.

Primárním vstupem do DeFi je stav on-chain (tj. kdo vlastní jaká aktiva). Když týmy spouštějí aplikační řetězce/rollupy, přirozeně vytvářejí fragmentaci stavu, což je pro DeFi velmi škodlivé, a to jak pro vývojáře spravující složitost aplikace (mosty, peněženky, zpoždění, cross-chain MEV atd.), tak pro uživatele ( Skluz, zpoždění vypořádání).

Nejideálnější podmínkou pro DeFi je, že aktiva jsou vydávána na jedné knize aktiv a obchodována v rámci jednoho státního automatu. Čím větší je účetní kniha aktiv, tím složitější musí vývojáři aplikací spravovat a tím vyšší náklady musí uživatelé nést.

App Rollup nevytvoří nové možnosti zpeněžení pro vývojáře

Zastánci AppChain/Rollup věří, že pobídky povedou vývojáře aplikací k vývoji Rollupů spíše než k budování na L1 nebo L2, aby aplikace mohly samy zachytit hodnotu MEV. Tato myšlenka je však chybná, protože spuštění kumulativní aplikace není jediným způsobem, jak zachytit MEV zpět do tokenů aplikační vrstvy, a ve většině případů to není nejlepší způsob. Tokeny aplikační vrstvy mohou získat MEV zpět do svých vlastních tokenů jednoduše kódováním logiky v inteligentních smlouvách ve společném řetězci. Podívejme se na několik příkladů:

  • Likvidace: Pokud Compound nebo Aave DAO chtějí získat část MEV plynoucí likvidačnímu botovi, mohou jednoduše aktualizovat své příslušné smlouvy tak, aby část poplatků aktuálně plynoucích likvidátorovi byla zaplacena jejich vlastnímu DAO, aniž by to bylo nutné. pro nový řetěz/rollup .

  • Oracle: Tokeny Oracle mohou zachycovat MEV poskytováním služeb zpětného běhu. Kromě aktualizací cen mohou oracles také sbalit jakékoli libovolné transakce v řetězci, u kterých je zaručeno, že proběhnou okamžitě po aktualizaci ceny. Proto mohou věštci zachytit MEV poskytováním zpětných služeb pro vyhledávače, tvůrce bloků atd.

  • NFT ražba: NFT ražba je plná skalpovacích botů. To lze snadno zmírnit jednoduchým kódováním přerozdělení klesajících zisků. Pokud se například někdo pokusí prodat svůj NFT do dvou týdnů od ražení NFT, 100 % výnosů se vrátí emitentovi nebo DAO. Toto procento se může v průběhu času měnit.

Neexistuje žádná univerzální odpověď na zachycování MEV do tokenů aplikační vrstvy. S trochou přemýšlení však mohou vývojáři aplikací snadno zachytit MEV zpět do svých vlastních tokenů na univerzálním řetězci. Spuštění zbrusu nového řetězce je jednoduše zbytečné a přinese vývojářům další technickou a sociální složitost a uživatelům také více starostí o peněženku a likviditu.

Kumulativní aplikace nemůže vyřešit problémy s přetížením napříč aplikacemi

Mnozí se domnívají, že Application Chain/Rollup zajišťuje, že aplikace nebudou ovlivněny prudkými nárůsty plynu způsobenými jinými aktivitami v řetězci, jako je populární ražba NFT. Tento názor je částečně pravdivý, ale většinou mylný.

Toto je historický problém a hlavní příčinou je jednovláknová povaha EVM, nikoli proto, že neexistuje oddělení DA a provádění. Všechny L2 platí poplatek L1 a poplatky L1 lze kdykoli zvýšit. Během memecoinového šílenství na začátku tohoto roku transakční poplatky na Arbitrum a Optimismus krátce přesáhly 10 USD. Poplatky za optimismus také nedávno po spuštění Worldcoinu prudce vzrostly.

Jedinými řešeními, jak se vypořádat s nárůsty poplatků, jsou: 1) maximalizovat L1 DA, 2) co nejvíce zpřesnit trh poplatků:

Pokud je L1 omezený zdroj, budou špičky využití v jednotlivých L2 předány L1, což bude znamenat vyšší náklady na všechny ostatní L2. Aplikační řetězec/rollup proto není imunní vůči plynovým špičkám.

Koexistence mnoha EVM L2 je jen hrubý způsob, jak vyzkoušet trh s lokalizačními poplatky. Je to lepší než umístit trh s poplatky do jediného EVM L1, ale neřeší to hlavní problém. Když si uvědomíte, že řešením je lokalizovaný trh s poplatky, logickým koncovým bodem je trh s poplatky podle státu (spíše než trh s poplatky za L2).

K tomuto závěru již došly i další řetězce. Solana a Aptos přirozeně lokalizují trhy s poplatky. To vyžadovalo rozsáhlé inženýrské práce po mnoho let pro příslušná prováděcí prostředí. Většina zastánců modulárních systémů silně podceňuje důležitost a obtížnost inženýrských trhů s místními poplatky.

Spuštěním více řetězců vývojáři nezískají skutečné zvýšení výkonu. Pokud existují aplikace, které zvyšují objem transakcí, jsou ovlivněny náklady všech řetězců L2.

Flexibilita se přeceňuje

Zastánci modulárních řetězců tvrdí, že modulární architektura je flexibilnější. Toto tvrzení je zjevně pravdivé, ale je to opravdu důležité?

Šest let jsem se snažil najít vývojáře aplikací, kterým by generická L1 nemohla poskytnout smysluplnou flexibilitu. Ale zatím, kromě tří velmi specifických případů použití, nikdo nebyl schopen formulovat, proč je flexibilita důležitá a jak přímo pomáhá škálování. Tři konkrétní případy použití, u kterých považuji flexibilitu za důležitou, jsou:

Aplikace, které využívají „horký“ stav. Hot stav je stav nezbytný pro koordinaci určité sady operací v reálném čase, ale do řetězce bude předložen pouze dočasně a nebude existovat navždy. Několik příkladů tepelných stavů:

  • Limitní příkazy v DEXech, jako jsou dYdX a Sei (mnoho limitních příkazů je nakonec zrušeno).

  • Tok objednávek je koordinován a identifikován v reálném čase v dFlow, protokolu, který usnadňuje decentralizovaný trh toku objednávek mezi tvůrci trhu a peněženkami.

  • Věštci mají rádi Pyth, což je orákulum s nízkou latencí. Pyth běží jako samostatný řetězec SVM. Pyth generuje tolik dat, že hlavní tým Pyth rozhodl, že bude nejlepší poslat vysokofrekvenční aktualizace cen do samostatného řetězce a poté použít Wormhole k přemostění cen do jiných řetězců podle potřeby.

Upravte řetězec konsensu. Nejlepšími příklady jsou Osmosis (kde jsou všechny transakce před odesláním validátorům zašifrovány) a Thorchain (kde jsou transakce v rámci bloku upřednostňovány na základě zaplacených poplatků).

Vyžaduje se infrastruktura, která nějakým způsobem využívá Threshold Signature Scheme (TSS). Některé příklady jsou Sommelier, Thorchain, Osmosis, Wormhole a Web3Auth.

S výjimkou Pyth a Wormhole jsou všechny výše uvedené příklady vytvořeny pomocí Cosmos SDK a běží jako samostatné řetězce. To vypovídá o použitelnosti a škálovatelnosti Cosmos SDK pro všechny tři případy použití: horké stavy, konsensuální modifikace a systémy Threshold Signature Scheme (TSS).

Většina projektů ve výše uvedených třech případech použití však nejsou aplikace, ale infrastruktura.

Pyth a dFlow nejsou aplikace, jsou to infrastruktura. Sommelier, Wormhole, Sei a Web3Auth nejsou aplikace, ale infrastruktura. Mezi nimi je pouze jeden konkrétní typ uživatelské aplikace: DEX (dYdX, Osmosis, Thorchain).

Šest let jsem se ptal příznivců Cosmos a Polkadot na případy použití, které vyplývají z flexibility, kterou nabízejí. Myslím, že existuje dostatek dat, abychom mohli udělat nějaké závěry:

Za prvé, příklady infrastruktury by neměly existovat jako kumulativní, protože buď produkují příliš mnoho dat s nízkou hodnotou (jako jsou horké stavy, a celý smysl horkých stavů spočívá v tom, že data nejsou potvrzena zpět do L1), nebo protože fungují něco, co je záměrně v rozporu s funkcemi souvisejícími s aktualizací stavu (například všechny případy použití TSS).

Za druhé, jediná aplikace, kterou jsem viděl a která by mohla těžit ze změny návrhu jádra systému, je DEX. Protože DEX je zaplaven MEV a univerzální řetězce se latenci CEX nevyrovnají. Konsensus je základem pro kvalitu provedení transakcí a MEV, takže změny založené na konsensu přirozeně přinesou DEX mnoho inovačních příležitostí. Jak však bylo zmíněno dříve v tomto článku, hlavním vstupem do spotového DEX je obchodované aktivum. DEX soutěží o aktiva, a tedy o emitenty aktiv. V tomto rámci je nepravděpodobné, že by nezávislé řetězce DEX uspěly, protože emitenti primárního vydání aktiv při vydávání aktiv nezvažují MEV související s DEX, ale obecnou funkcionalitu inteligentních smluv a začlenění této funkce do příslušných aplikací vývojářů.

Deriváty DEX však nemusejí soutěžit o emitenty aktiv. Spoléhají se hlavně na kolaterál, jako je USDC a cenové zdroje oracle, a v podstatě musí uzamknout uživatelská aktiva, aby zajistily pozice derivátů. Takže ve smyslu nezávislých řetězců DEX budou s největší pravděpodobností fungovat pro DEX zaměřené na deriváty, jako jsou dYdX a Sei.

Podívejme se na běžné integrované aplikace L1, které dnes existují, včetně: her, systémů DeSoc (jako Farcaster a Lens), protokolů DePIN (jako je Helium, Hivemapper, Render Network, DIMO a Daylight), zvuku, výměn NFT a dalších . Žádný z nich nijak zvlášť netěží z flexibility, kterou přináší úprava konsensu, a jejich příslušné účetní knihy aktiv mají poměrně jednoduchý, zřejmý a společný soubor požadavků: nízké poplatky, nízká latence, přístup k spotovým DEXům, přístup ke stablecoinům a přístup k fiat kanály, jako je CEX.

Domnívám se, že nyní máme dostatek dat, abychom do určité míry mohli říci, že velká většina aplikací pro uživatele má stejné obecné požadavky vyjmenované v předchozím odstavci. Zatímco některé aplikace mohou optimalizovat další proměnné na okraji pomocí vlastních funkcí v zásobníku, kompromisy, které s těmito přizpůsobeními přicházejí, se obvykle nevyplatí (více mostů, menší podpora peněženky, menší podpora indexování / poptávkového programu, snížení legální měny kanály atd.).

Zavedení nových účetních knih aktiv je jedním ze způsobů, jak dosáhnout flexibility, ale málokdy přidává hodnotu a téměř vždy přináší technickou a sociální složitost s malým konečným přínosem pro vývojáře aplikací.

Prodloužená DA nevyžaduje re-hypotéku

Uslyšíte také zastánce modulárních systémů mluvit o rehypotekaci v kontextu škálování. Toto je nejspekulativnější argument zastánců modulárních řetězců, ale stojí za to diskutovat.

Zhruba uvádí, že v důsledku opětovného sázky (např. prostřednictvím systémů jako EigenLayer) může celý kryptoekosystém znovu sázet ETH nekonečně mnohokrát, čímž se zmocňuje neomezený počet DA vrstev (např. EigenDA) a realizačních vrstev. Při zajištění zhodnocení hodnoty ETH je tedy řešena škálovatelnost ze všech aspektů.

Navzdory obrovské nejistotě mezi současnou situací a teoretickou budoucností považujeme za samozřejmé, že všechny stratifikační předpoklady fungují tak, jak jsou inzerovány.

Aktuální DA Etherea je kolem 83 KB/s. Se zavedením EIP-4844 koncem tohoto roku se tato rychlost může zhruba zdvojnásobit na přibližně 166 KB/s. EigenDA může přidat dalších 10 MB/s, ale vyžaduje jinou sadu bezpečnostních předpokladů (ne všechna ETH budou znovu zajištěna na EigenDA).

Pro srovnání, Solana v současnosti nabízí DA asi 125 MB/s (32 000 skartování na blok, 1 280 bajtů na skartování, 2,5 bloku za sekundu). Solana je mnohem efektivnější než Ethereum a EigenDA. Solanovo DA se navíc postupem času rozšiřuje podle Nelsonova zákona.

Existuje mnoho způsobů, jak rozšířit DA prostřednictvím remortgagingu a modularizace, ale tyto mechanismy dnes prostě nejsou nutné a představují značné technické a sociální složitosti.

Vytvořeno pro vývojáře aplikací

Po letech přemýšlení jsem dospěl k závěru, že modularita by neměla být cílem sama o sobě.

Blockchain musí sloužit svým zákazníkům (tj. vývojářům aplikací), proto by měl blockchain abstrahovat složitost na úrovni infrastruktury, aby se vývojáři mohli soustředit na vytváření aplikací světové třídy.

Modularita je skvělá. Ale klíčem k budování vítězné technologie je zjistit, které části zásobníku je třeba integrovat a které části nechat na ostatních. V současné době integrace DA a realizačních řetězců ze své podstaty poskytuje jednodušší prostředí pro koncového uživatele a vývojáře a nakonec poskytne lepší základ pro nejlepší aplikace ve své třídě.

Původní odkaz

Tento článek je přetištěn z Foresight News se svolením

Tento článek Venture Capital Institution Multicoin Partner: Why Modular Blockchain Is Overvalued se poprvé objevil na Zombitu.