Kyle Samani, partner di Multicoin Capital, elabora 7 ragioni per cui le blockchain modulari sono sopravvalutate.
Scritto da: Kyle Samani, partner, Multicoin Capital
Compilato da: Rufy, Foresight News
Negli ultimi due anni, il dibattito sulla scalabilità della blockchain si è concentrato sul tema centrale del "dibattito tra modularità e integrazione".
Tieni presente che le discussioni sulla criptovaluta spesso confondono sistemi "singoli" e "integrati". Il dibattito tecnico sui sistemi integrati rispetto ai sistemi modulari dura da 40 anni. Questa conversazione nello spazio delle criptovalute dovrebbe essere inquadrata attraverso la stessa lente della storia, e questo è ben lungi dall’essere un nuovo dibattito.
Quando si considera la modularità rispetto all’integrazione, la decisione progettuale più importante che una blockchain può prendere è la misura in cui la complessità dello stack viene esposta agli sviluppatori di applicazioni. I clienti della blockchain sono sviluppatori di applicazioni, quindi le decisioni finali sulla progettazione dovrebbero tenere conto della loro prospettiva.
Oggi, la modularità è ampiamente considerata il modo principale in cui le blockchain crescono. In questo articolo sfiderò questo presupposto partendo dai principi primi, svelerò i miti culturali e i costi nascosti dei sistemi modulari e condividerò le conclusioni che ho tratto riflettendo su questo dibattito negli ultimi sei anni.
I sistemi modulari aumentano la complessità dello sviluppo
Il costo nascosto di gran lunga più grande dei sistemi modulari è la complessità aggiuntiva del processo di sviluppo.
I sistemi modulari aumentano notevolmente la complessità che gli sviluppatori di applicazioni devono gestire, sia nel contesto delle proprie applicazioni (complessità tecnica) sia nel contesto delle interazioni con altre applicazioni (complessità sociale).
Nel contesto delle criptovalute, le blockchain modulari consentono teoricamente una maggiore specializzazione, ma al costo di creare nuova complessità. Questa complessità (sia di natura tecnica che sociale) viene trasferita agli sviluppatori di applicazioni, rendendo in definitiva più difficile la creazione di applicazioni.
Ad esempio, considera lo stack OP. A partire da ora, sembra essere il framework modulare più popolare. OP Stack costringe gli sviluppatori a scegliere tra l'adozione della Legge delle Catene (che comporta molta complessità sociale) o il fork e la gestione separata delle stesse. Entrambe le opzioni creano una notevole complessità a valle per i costruttori. Se scegli di effettuare il fork, riceverai supporto tecnico da altri partecipanti all'ecosistema (CEX, fiat on-ramp, ecc.) che devono sostenere costi per conformarsi ai nuovi standard tecnologici? Se scegli di seguire la Legge delle Catene, quali regole e vincoli ti verranno imposti oggi e domani?
Fonte: modello OSI
I moderni sistemi operativi (OS) sono sistemi grandi e complessi contenenti centinaia di sottosistemi. I moderni sistemi operativi gestiscono i livelli 2-6 nel diagramma sopra. Questo è un classico esempio di integrazione di componenti modulari per gestire la complessità dello stack esposta agli sviluppatori di applicazioni. Gli sviluppatori di applicazioni non vogliono occuparsi di nulla al di sotto del livello 7, motivo per cui esistono i sistemi operativi: il sistema operativo gestisce la complessità dei livelli sottostanti in modo che gli sviluppatori di applicazioni possano concentrarsi sul livello 7. Pertanto, la modularità non dovrebbe essere un obiettivo in sé, ma un mezzo per raggiungere un fine.
Tutti i principali sistemi software del mondo oggi (backend cloud, sistemi operativi, motori di database, motori di gioco, ecc.) sono altamente integrati e composti da molti sottosistemi modulari. I sistemi software tendono ad essere altamente integrati per massimizzare le prestazioni e ridurre la complessità dello sviluppo. Lo stesso vale per la blockchain.
Ethereum, tra l’altro, sta riducendo la complessità emersa durante l’era del fork Bitcoin del 2011-2014. I sostenitori della modularità spesso enfatizzano il modello Open Systems Interconnection (OSI), sostenendo che la disponibilità dei dati (DA) e l'esecuzione dovrebbero essere separate; tuttavia, questo argomento è ampiamente frainteso; Una corretta comprensione della questione in questione porta alla conclusione opposta: all’argomentazione secondo cui l’OSI è un sistema integrato piuttosto che un sistema modulare.
Le catene modulari non possono eseguire il codice più velocemente
In base alla progettazione, una definizione comune di "catena modulare" è la separazione tra disponibilità dei dati (DA) ed esecuzione: un insieme di nodi è responsabile del DA, mentre un altro insieme (o insiemi) di nodi è responsabile dell'esecuzione. Le raccolte di nodi non devono avere alcuna sovrapposizione, ma possono farlo.
In pratica, separare DA ed esecuzione non migliora di per sé le prestazioni di nessuno dei due, piuttosto alcuni hardware da qualche parte nel mondo devono eseguire DA e alcuni hardware da qualche parte devono implementare l'esecuzione; La separazione di queste funzioni non migliora le prestazioni di nessuna di esse. Sebbene la separazione possa ridurre i costi computazionali, essa può essere ridotta solo centralizzando l’esecuzione.
Per ribadire: indipendentemente dall'architettura modulare o integrata, parte dell'hardware da qualche parte deve svolgere il lavoro e separare DA ed esecuzione su hardware separato non accelera o aumenta di per sé la capacità complessiva del sistema.
Alcuni sostengono che la modularità consente a più EVM di funzionare in parallelo in modo rollup, consentendo all'esecuzione di scalare orizzontalmente. Sebbene ciò sia teoricamente corretto, questa visione in realtà enfatizza i limiti dell'EVM come processore a thread singolo piuttosto che la premessa di base di separare DA ed esecuzione nel contesto del ridimensionamento del throughput complessivo del sistema.
La modularità da sola non migliora la produttività.
La modularità aumenta i costi di transazione per gli utenti
Per definizione, ciascuna L1 e L2 è un registro patrimoniale indipendente con il proprio stato. Questi pezzi di stato separati possono comunicare, anche se con latenze di transazione più lunghe e maggiore complessità per sviluppatori e utenti (tramite ponti a catena incrociata come LayerZero e Wormhole).
Più registri patrimoniali ci sono, più frammentato diventa lo stato globale di tutti i conti. Questo è terribile sia per le catene che per gli utenti di più catene. La frammentazione dello Stato può comportare una serie di conseguenze:
Ridotta liquidità, con conseguente maggiore slittamento delle negoziazioni;
Maggiore consumo totale di gas (le transazioni cross-chain richiedono almeno due transazioni su almeno due registri di asset);
Aumento del doppio conteggio nei registri degli asset (riducendo così il throughput complessivo del sistema): quando il prezzo di ETH-USDC si sposta su Binance o Coinbase, si presenteranno opportunità di arbitraggio su ogni pool ETH-USDC in tutti i registri degli asset (puoi facilmente È facile immaginare un mondo in cui ogni volta che il prezzo ETH-USDC cambia su Binance o Coinbase, ci sono più di 10 transazioni sui vari registri delle risorse. Mantenere i prezzi coerenti in uno stato frammentato è estremamente ridotto in termini di utilizzo efficiente dello spazio sui blocchi.
È importante rendersi conto che la creazione di più registri delle risorse aumenta significativamente i costi in tutte queste dimensioni, in particolare quelle associate alla DeFi.
L’input principale della DeFi è lo stato della catena (ovvero chi possiede quali asset). Quando i team lanciano catene di applicazioni/rollup, creano naturalmente una frammentazione dello stato, che è molto dannosa per la DeFi, sia per gli sviluppatori che gestiscono la complessità dell'applicazione (bridge, portafogli, ritardi, MEV cross-chain, ecc.), sia per gli utenti ( Slippage, ritardi di regolamento).
La condizione ideale per la DeFi è che gli asset siano emessi su un unico registro degli asset e scambiati all’interno di un unico apparato statale. Maggiore è il registro delle risorse, maggiore sarà la complessità che gli sviluppatori di applicazioni dovranno gestire e maggiori saranno i costi che gli utenti dovranno sostenere.
L'app cumulativo non creerà nuove opportunità di monetizzazione per gli sviluppatori
I sostenitori di AppChain/Rollup ritengono che gli incentivi porteranno gli sviluppatori di applicazioni a sviluppare Rollup anziché basarsi su L1 o L2, in modo che le applicazioni possano acquisire da sole valore MEV. Tuttavia, questa idea è errata perché l'esecuzione di un rollup dell'applicazione non è l'unico modo per acquisire nuovamente MEV nei token del livello applicazione e nella maggior parte dei casi non è il modo migliore. I token del livello applicativo possono catturare nuovamente il MEV nei propri token semplicemente codificando la logica nei contratti intelligenti sulla catena comune. Consideriamo alcuni esempi:
Liquidazione: se Compound o Aave DAO desiderano acquisire una parte del MEV che fluisce al bot di liquidazione, possono semplicemente aggiornare i rispettivi contratti in modo che una parte delle commissioni attualmente fluenti al liquidatore venga pagata al proprio DAO, senza la necessità per una nuova catena/Rollup .
Oracle: i token Oracle possono acquisire MEV fornendo servizi di back running. Oltre agli aggiornamenti dei prezzi, gli oracoli possono anche raggruppare qualsiasi transazione on-chain arbitraria che è garantita essere eseguita immediatamente dopo un aggiornamento dei prezzi. Pertanto, gli oracoli possono acquisire MEV fornendo servizi di back running a ricercatori, costruttori di blocchi, ecc.
Conio NFT: il conio NFT è pieno di bot scalping. Ciò può essere facilmente mitigato semplicemente codificando la riallocazione dei profitti in calo. Ad esempio, se qualcuno tenta di rivendere il proprio NFT entro due settimane dalla coniazione dell'NFT, il 100% del ricavato tornerà all'emittente o alla DAO. Questa percentuale può cambiare nel tempo.
Non esiste una risposta universale all’acquisizione di MEV nei token del livello di applicazione. Tuttavia, con un po’ di riflessione, gli sviluppatori di applicazioni possono facilmente catturare il MEV nei propri token sulla catena universale. Il lancio di una catena completamente nuova è semplicemente inutile e comporterebbe ulteriore complessità tecnica e sociale per gli sviluppatori, oltre a maggiori preoccupazioni in termini di portafoglio e liquidità per gli utenti.
Il rollup dell'applicazione non può risolvere i problemi di congestione tra applicazioni
Molti credono che la catena di applicazioni/rollup garantisca che le applicazioni non siano influenzate dai picchi di gas causati da altre attività sulla catena, come il popolare conio NFT. Questa visione è in parte vera, ma in gran parte sbagliata.
Si tratta di un problema storico e la causa principale è la natura a thread singolo dell'EVM, non perché non vi sia separazione tra DA ed esecuzione. Tutti i L2 pagano una commissione a L1 e le commissioni L1 possono essere aumentate in qualsiasi momento. Durante la mania dei memecoin all'inizio di quest'anno, le commissioni di transazione su Arbitrum e Optimism hanno superato brevemente i 10 dollari. Anche le commissioni di Optimism sono recentemente salite alle stelle in seguito al lancio di Worldcoin.
Le uniche soluzioni per affrontare i picchi tariffari sono: 1) massimizzare L1 DA, 2) perfezionare il mercato delle commissioni il più possibile:
Se L1 ha risorse limitate, i picchi di utilizzo nei singoli L2 verranno trasferiti a L1, il che imporrà costi più elevati su tutti gli altri L2. Pertanto, la catena di applicazione/rollup non è immune ai picchi di gas.
La coesistenza di numerosi EVM L2 è solo un modo rozzo per provare il mercato delle tariffe di localizzazione. È meglio che collocare il mercato delle commissioni in un singolo EVM L1, ma non risolve il problema principale. Quando ci si rende conto che la soluzione è un mercato tariffario localizzato, l’endpoint logico è un mercato tariffario per stato (piuttosto che un mercato tariffario per L2).
Altre catene sono già arrivate a questa conclusione. Solana e Aptos localizzano naturalmente i mercati tariffari. Ciò ha richiesto un ampio lavoro di ingegneria nel corso di molti anni per i rispettivi ambienti di esecuzione. La maggior parte dei sostenitori del sistema modulare sottovaluta gravemente l’importanza e la difficoltà di progettare mercati tariffari locali.
Lanciando più catene, gli sviluppatori non ottengono reali guadagni in termini di prestazioni. Quando ci sono applicazioni che determinano un aumento del volume delle transazioni, i costi di tutte le catene L2 ne risentono.
La flessibilità è sopravvalutata
I sostenitori delle catene modulari sostengono che l’architettura modulare è più flessibile. Questa affermazione è ovviamente vera, ma ha davvero importanza?
Per sei anni ho cercato di trovare sviluppatori di applicazioni per i quali un L1 generico non potesse fornire una flessibilità significativa. Ma finora, al di fuori di tre casi d’uso molto specifici, nessuno è stato in grado di spiegare perché la flessibilità è importante e come aiuta direttamente la scalabilità. Tre casi d'uso specifici in cui ritengo che la flessibilità sia importante sono:
Applicazioni che sfruttano lo stato "caldo". Lo stato caldo è lo stato necessario per coordinare una serie di operazioni in tempo reale, ma sarà sottoposto alla catena solo temporaneamente e non esisterà per sempre. Alcuni esempi di stati termici:
Ordini limite in DEX come dYdX e Sei (molti ordini limite finiscono per essere annullati).
Il flusso degli ordini è coordinato e identificato in tempo reale in dFlow (dFlow è un protocollo che facilita un mercato decentralizzato del flusso degli ordini tra market maker e portafogli).
Oracoli come Pyth, che è un oracolo a bassa latenza. Pyth viene eseguito come catena SVM autonoma. Pyth genera così tanti dati che il team principale di Pyth ha deciso che era meglio inviare aggiornamenti sui prezzi ad alta frequenza a una catena autonoma e quindi utilizzare Wormhole per collegare i prezzi ad altre catene secondo necessità.
Modificare la catena del consenso. Gli esempi migliori sono Osmosis (dove tutte le transazioni vengono crittografate prima di essere inviate ai validatori) e Thorchain (dove alle transazioni all'interno di un blocco viene assegnata la priorità in base alle commissioni pagate).
È necessaria un'infrastruttura che sfrutti in qualche modo il Threshold Signature Scheme (TSS). Alcuni esempi di questo sono Sommelier, Thorchain, Osmosis, Wormhole e Web3Auth.
Ad eccezione di Pyth e Wormhole, tutti gli esempi sopra elencati vengono creati utilizzando Cosmos SDK ed eseguiti come catene autonome. Ciò la dice lunga sull’idoneità e la scalabilità di Cosmos SDK per tutti e tre i casi d’uso: stati caldi, modifiche del consenso e sistemi Threshold Signature Scheme (TSS).
Tuttavia, la maggior parte dei progetti nei tre casi d’uso precedenti non sono applicazioni, ma infrastrutture.
Pyth e dFlow non sono applicazioni, sono infrastrutture. Sommelier, Wormhole, Sei e Web3Auth non sono applicazioni, sono infrastrutture. Tra questi, esiste solo un tipo specifico di applicazione rivolta all'utente: DEX (dYdX, Osmosis, Thorchain).
Per sei anni ho chiesto ai sostenitori di Cosmos e Polkadot quali casi d’uso derivano dalla flessibilità che offrono. Penso che ci siano dati sufficienti per fare alcune deduzioni:
Prima di tutto, gli esempi di infrastrutture non dovrebbero esistere come Rollup perché producono troppi dati di basso valore (come gli stati caldi, e il punto centrale degli stati caldi è che i dati non vengono restituiti a L1), o perché eseguono qualcosa di intenzionalmente incoerente con le risorse nella funzionalità relativa all'aggiornamento dello stato (ad esempio, tutti i casi d'uso TSS).
In secondo luogo, l'unica applicazione che ho visto che potrebbe trarre vantaggio dalla modifica del design del sistema principale è un DEX. Perché DEX è inondato di MEV e le catene universali non possono eguagliare la latenza di CEX. Il consenso è la base per la qualità dell’esecuzione delle transazioni e per il MEV, quindi i cambiamenti basati sul consenso porteranno naturalmente molte opportunità di innovazione a DEX. Tuttavia, come accennato in precedenza in questo articolo, l’input principale per un DEX spot è l’asset scambiato. I DEX competono per gli asset e quindi per gli emittenti di asset. In questo quadro, è improbabile che le catene DEX indipendenti abbiano successo perché la questione principale che gli emittenti di asset considerano quando emettono asset non è il MEV correlato a DEX, ma la funzionalità generale del contratto intelligente e l’incorporazione di questa funzionalità nelle rispettive applicazioni degli sviluppatori.
Tuttavia, i DEX derivati non hanno bisogno di competere per gli emittenti di asset. Si basano principalmente su garanzie come USDC e feed di prezzi oracle e essenzialmente devono bloccare le risorse degli utenti per garantire le posizioni sui derivati. Quindi, nel senso delle catene DEX indipendenti, è molto probabile che funzionino per DEX incentrati sui derivati come dYdX e Sei.
Consideriamo le comuni applicazioni L1 integrate esistenti oggi, tra cui: giochi, sistemi DeSoc (come Farcaster e Lens), protocolli DePIN (come Helium, Hivemapper, Render Network, DIMO e Daylight), audio, scambi NFT e altro ancora. . Nessuno di questi beneficia particolarmente della flessibilità apportata dalla modifica del consenso, i rispettivi registri degli asset hanno una serie di requisiti abbastanza semplici, ovvi e comuni: commissioni basse, bassa latenza, accesso al DEX spot, accesso alle stablecoin e accesso al fiat. canali, come CEX.
Credo che ora disponiamo di dati sufficienti per affermare, in una certa misura, che la stragrande maggioranza delle applicazioni rivolte agli utenti presenta gli stessi requisiti generali elencati nel paragrafo precedente. Sebbene alcune applicazioni possano ottimizzare altre variabili a margine con funzionalità personalizzate nello stack, i compromessi che derivano da queste personalizzazioni di solito non valgono la pena (più bridge, meno supporto per il portafoglio, meno supporto per il programma di indicizzazione/indagine, riduzione della valuta legale canali, ecc.).
L’implementazione di nuovi registri delle risorse è un modo per ottenere flessibilità, ma raramente aggiunge valore e quasi sempre introduce complessità tecnica e sociale con scarsi vantaggi finali per gli sviluppatori di applicazioni.
La DA estesa non richiede una nuova ipoteca
Sentirai anche i sostenitori della modularità parlare di reimpegno nel contesto del ridimensionamento. Questo è l’argomento più speculativo avanzato dai sostenitori della catena modulare, ma vale la pena discuterne.
Afferma approssimativamente che a causa del re-staking (ad esempio, attraverso sistemi come EigenLayer), l'intero ecosistema crittografico può re-staking ETH un numero infinito di volte, abilitando un numero illimitato di livelli DA (ad esempio, EigenDA) e livelli di esecuzione. Pertanto, pur garantendo l’apprezzamento del valore ETH, la scalabilità è risolta sotto tutti gli aspetti.
Nonostante l’enorme incertezza tra la situazione attuale e il futuro teorico, diamo per scontato che tutte le ipotesi di stratificazione funzionino come pubblicizzato.
La DA di Ethereum è attualmente di circa 83 KB/s. Con l'introduzione di EIP-4844 entro la fine dell'anno, tale velocità potrà raddoppiare fino a circa 166 KB/s. EigenDA può aggiungere ulteriori 10 MB/s, ma richiede una serie diversa di presupposti di sicurezza (non tutti gli ETH verranno nuovamente garantiti da EigenDA).
In confronto, Solana offre attualmente una DA di circa 125 MB/s (32.000 frammenti per blocco, 1.280 byte per frammento, 2,5 blocchi al secondo). Solana è molto più efficiente di Ethereum ed EigenDA. Inoltre, la DA di Solana si espande nel tempo secondo la Legge di Nelson.
Esistono molti modi per estendere il DA attraverso il remortgaging e la modularizzazione, ma questi meccanismi semplicemente non sono necessari oggi e introducono significative complessità tecniche e sociali.
Costruito per gli sviluppatori di applicazioni
Dopo anni di riflessione, sono giunto alla conclusione che la modularità non dovrebbe essere un obiettivo in sé.
La blockchain deve servire i propri clienti (ovvero gli sviluppatori di applicazioni), pertanto dovrebbe astrarre la complessità a livello di infrastruttura in modo che gli sviluppatori possano concentrarsi sulla creazione di applicazioni di livello mondiale.
La modularità è eccezionale. Ma la chiave per costruire una tecnologia vincente è capire quali parti dello stack devono essere integrate e quali lasciare ad altri. Allo stato attuale, l'integrazione di DA e catene di esecuzione fornisce intrinsecamente un'esperienza più semplice per l'utente finale e lo sviluppatore e, in definitiva, fornirà una base migliore per le migliori applicazioni della categoria.
Collegamento originale
Questo articolo è stato ristampato da Foresight News con autorizzazione
Questo articolo Partner multicoin di Venture Capital Institution: perché la blockchain modulare è sopravvalutata è apparso per la prima volta su Zombit.