Titolo originale: "Aggregazione, regolamento, esecuzione"

Scritto da Bridget Harris

Compilato da: Chris, Techub News

Le varie parti dello stack modulare non sono uguali in termini di focus e innovazione e, sebbene ci siano stati molti progetti precedenti che hanno innovato la disponibilità dei dati (DA) e i livelli di sequenziamento, fino a poco tempo fa i livelli di esecuzione e regolamento non facevano parte dello stack modulare. lo stack modulare viene preso sul serio.

La concorrenza nello spazio dello smistamento condiviso è feroce, con molti progetti come Espresso, Astria, Radius, Rome e Madara in lizza per quote di mercato, così come fornitori RaaS come Caldera e Conduit che sviluppano lo smistamento condiviso per Rollup, che si basa su loro. Questi fornitori RaaS sono in grado di offrire tariffe più favorevoli per Rollup perché i loro modelli di business sottostanti non dipendono interamente dalla sequenziazione delle entrate. Ci sono anche molti Rollup che scelgono di eseguire il proprio sequenziatore per le commissioni che genera.

Il mercato degli smistatori è unico rispetto allo spazio di disponibilità dei dati (DA). Lo spazio di disponibilità dei dati (DA) è essenzialmente un oligopolio costituito da Celestia, Avail ed EigenDA. Ciò rende difficile per i nuovi entranti più piccoli al di fuori dei Tre Grandi riuscire a rivoluzionare con successo il settore. I progetti possono sfruttare la scelta "esistente" (Ethereum) o scegliere uno dei livelli DA maturi in base al tipo di stack tecnologico e alla coerenza. Anche se l'utilizzo di un livello DA comporta notevoli risparmi sui costi, l'esternalizzazione della parte sequenziatore non è una scelta ovvia (dal punto di vista dei costi, non della sicurezza), principalmente a causa del costo opportunità derivante dalla rinuncia ai ricavi del sequenziatore. Molti credono anche che DA diventerà una merce, ma ciò che vediamo nelle criptovalute è che la combinazione di fossati di liquidità estremamente forti e tecnologia sottostante unica (difficile da copiare) rende estremamente difficile mercificare uno strato dello stack. Indipendentemente da questi argomenti, sono stati lanciati molti prodotti DA e sequenziatori. In breve, per alcuni stack modulari, "ogni servizio ha diversi concorrenti".

Penso che i livelli di esecuzione e liquidazione (e aggregazione) siano relativamente sottoesplorati, ma stanno iniziando a iterare in nuovi modi per allinearsi meglio con il resto dello stack modulare.

Relazione tra livelli di esecuzione e regolamento

Lo strato di esecuzione e lo strato di regolamento sono strettamente collegati, essendo il livello di regolamento che funge da luogo in cui vengono definiti lo stato e i risultati finali dell'esecuzione. Lo strato di regolamento può anche fornire miglioramenti ai risultati dello strato di esecuzione, migliorando così la funzionalità e la sicurezza dello strato di esecuzione. In pratica, ciò significa che il livello di liquidazione può svolgere diversi ruoli, come risolvere controversie relative a frodi nel livello di esecuzione, verificare le prove e connettersi ad altri ambienti del livello di esecuzione.

Vale la pena notare che alcuni team hanno scelto di supportare direttamente lo sviluppo di ambienti di esecuzione personalizzati nell’ambiente nativo dei propri protocolli, come Repyh Labs, che sta costruendo una L1 chiamata Delta. Si tratta essenzialmente di un reverse engineering dello stack modulare, ma fornisce comunque flessibilità e presenta il vantaggio della compatibilità tecnica perché i team non hanno bisogno di dedicare tempo all'integrazione manuale di ciascuna parte dello stack modulare. Gli svantaggi, ovviamente, sono l’isolamento dal punto di vista della mobilità, l’impossibilità di scegliere lo strato modulare che meglio si adatta al proprio progetto ed il fatto che sia troppo costoso.

Altri team scelgono di creare L1 per funzionalità o applicazioni core specifiche. Un esempio è Hyperliquid, che ha creato un L1 dedicato per la sua applicazione nativa di punta, la sua piattaforma di trading di contratti perpetui. Sebbene gli utenti si affidino ad Arbitrum per le operazioni cross-chain, la loro architettura principale non si basa su Cosmos SDK o altri framework, quindi può essere personalizzata e ottimizzata in modo iterativo per i casi d'uso principali.

Progresso esecutivo

Nell'ultimo ciclo, l'unica caratteristica che alt-L1 per uso generale aveva su Ethereum era un throughput più elevato. Ciò significa che se un progetto vuole migliorare significativamente le prestazioni, dovrà essenzialmente scegliere di costruire il proprio Layer1 da zero, soprattutto perché Ethereum stesso non dispone ancora di questa tecnologia. Storicamente, ciò significava semplicemente incorporare meccanismi di efficienza direttamente nei protocolli comuni. Nel ciclo attuale, questi miglioramenti delle prestazioni sono ottenuti attraverso la progettazione modulare e sono implementati sulla principale piattaforma di contratto intelligente Ethereum. Ciò consente sia ai progetti esistenti che a quelli nuovi di trarre vantaggio dalla nuova infrastruttura del livello di esecuzione senza sacrificare la liquidità, la sicurezza e il fossato della comunità di Ethereum.

Attualmente stiamo inoltre assistendo a un aumento nella combinazione e nell'abbinamento di diverse macchine virtuali (VM) come parte di una rete condivisa, offrendo agli sviluppatori flessibilità e maggiore personalizzazione a livello di esecuzione. Ad esempio, il livello N consente agli sviluppatori di eseguire nodi Rollup generici (ad esempio SolanaVM, MoveVM, ecc. come ambienti di esecuzione) e nodi Rollup specifici dell'applicazione (ad esempio Persistent DEX, Order Book DEX) sulla sua macchina a stati condivisa. Stanno anche lavorando per ottenere la piena componibilità e la liquidità condivisa tra queste diverse architetture VM, un problema di ingegneria on-chain che è stato storicamente difficile da realizzare su larga scala. Ogni applicazione sul livello N può consegnare messaggi in modo asincrono senza ritardi nel consenso, che spesso è un problema di "overhead di comunicazione" con le criptovalute. Ogni xVM può anche utilizzare uno schema di database diverso, che si tratti di RocksDB, LevelDB o di un database sincrono/asincrono personalizzato creato da zero. L'interoperabilità funziona in parte attraverso un "sistema snapshot" (un algoritmo simile all'algoritmo Chandy-Lamport) in cui la catena può passare a nuovi blocchi in modo asincrono senza richiedere una pausa del sistema. Dal punto di vista della sicurezza, è possibile presentare prove di frode se la transizione dello stato non è corretta. Con questo design, mirano a ridurre al minimo i tempi di esecuzione massimizzando al contempo il throughput complessivo della rete.

Strato n

Per favorire il progresso nella personalizzazione, Movement Labs sfrutta il linguaggio Move per VM/esecuzione, originariamente progettato da Facebook e utilizzato in reti come Aptos e Sui. Move presenta vantaggi strutturali rispetto ad altri framework, principalmente in termini di sicurezza e flessibilità degli sviluppatori. Storicamente, i due problemi principali legati alla creazione di applicazioni on-chain utilizzando le tecnologie esistenti sono stati la sicurezza e la flessibilità dello sviluppo. È importante sottolineare che gli sviluppatori possono anche semplicemente scrivere Solidity e distribuirlo su Movement. Per consentire ciò, Movement ha creato un runtime EVM completamente compatibile con bytecode che può essere utilizzato anche con lo stack Move. Il loro Rollup M2 sfrutta la parallelizzazione BlockSTM, che consente un throughput più elevato pur essendo in grado di accedere al fossato di liquidità di Ethereum (storicamente, BlockSTM veniva utilizzato solo in alt L1 come Aptos, che apparentemente mancava di compatibilità EVM).

MegaETH sta anche guidando i progressi nell'area del livello di esecuzione, in particolare attraverso il suo motore di parallelizzazione e il database in memoria, dove il sequenziatore può archiviare l'intero stato in memoria. In termini di architettura, hanno sfruttato:

• La compilazione del codice nativo rende le prestazioni L2 ancora migliori (se il contratto è più intensivo dal punto di vista computazionale, il programma può ottenere un'enorme accelerazione, se non è molto intenso dal punto di vista computazionale, puoi comunque ottenere circa 2 volte più accelerazione).

• Produzione di blocchi relativamente centralizzata, ma verifica e conferma dei blocchi decentralizzate.

• Sincronizzazione efficiente dello stato, in cui i nodi completi non devono rieseguire le transazioni, ma devono conoscere il delta dello stato in modo che possa essere applicato al database locale.

• Struttura di aggiornamento dell'albero Merkle, mentre il loro approccio è una nuova struttura dati trie che è efficiente in termini di memoria e disco. L'elaborazione in memoria consente loro di comprimere lo stato della catena in memoria, quindi quando le transazioni vengono eseguite, non devono andare sul disco, ma solo in memoria.

Un altro progetto recentemente esplorato e ripetuto come parte dello stack modulare è l'aggregazione delle prove: definita come un prover che crea un'unica prova concisa di più prove concise. Innanzitutto, diamo un’occhiata al livello di aggregazione nel suo complesso, alla sua storia e alle tendenze attuali nello spazio crittografico.

Il valore del livello di aggregazione

Storicamente, gli aggregatori hanno avuto una quota di mercato inferiore rispetto alle piattaforme nei mercati non legati alle criptovalute:

Anche se non sono sicuro che ciò si applichi a tutti i casi di criptovalute, è comunque vero per gli scambi decentralizzati, i ponti a catena incrociata e i protocolli di prestito.

Ad esempio, la capitalizzazione di mercato combinata di 1inch e 0x (due principali aggregatori DEX) è di circa 1 miliardo di dollari, una frazione della capitalizzazione di mercato di circa 7,6 miliardi di dollari di Uniswap. Lo stesso vale per i ponti a catena incrociata: gli aggregatori di ponti a catena incrociata come Li.Fi e Socket/Bungee hanno una quota di mercato inferiore rispetto a piattaforme come Across. Sebbene Socket supporti 15 diversi bridge cross-chain, il loro volume totale di transazioni cross-chain è in realtà simile a Across (Socket - 2,2 miliardi di dollari, Across - 1,7 miliardi di dollari), con Across che rappresenta solo una frazione del recente volume di transazioni di Socket/Bungee. .

Nel campo dei prestiti, Yearn Finance è il primo protocollo decentralizzato di aggregazione dei ricavi dei prestiti e il suo valore di mercato è attualmente di circa 250 milioni di dollari. In confronto, piattaforme come Aave (~$1,4 miliardi) e Compound (~$560 milioni) hanno valutazioni più elevate.

La situazione è simile nei mercati finanziari tradizionali. Ad esempio, ICE (Intercontinental Exchange) US e CME Group hanno capitalizzazioni di mercato di circa 75 miliardi di dollari ciascuna, mentre gli “aggregatori” come Charles Schwab e Robinhood hanno capitalizzazioni di mercato di circa 132 miliardi di dollari e circa 15 miliardi di dollari, rispettivamente. A Schwab, che attraversa numerose sedi tra cui ICE e CME, la percentuale del volume degli scambi instradato attraverso di esse è sproporzionata rispetto alla sua quota di capitalizzazione di mercato. Robinhood ha circa 119 milioni di contratti di opzione al mese, rispetto ai circa 35 milioni di ICE – e i contratti di opzione non sono nemmeno una parte fondamentale del modello di business di Robinhood. Tuttavia, ICE è valutato circa 5 volte di più di Robinhood sui mercati pubblici. Pertanto, poiché le interfacce di aggregazione a livello di applicazione, Schwab e Robinhood instradano il flusso degli ordini dei clienti verso varie sedi e, sebbene i loro volumi di scambio siano elevati, le valutazioni non sono così elevate come ICE e CME.

Come consumatori, assegniamo meno valore agli aggregatori.

Questo potrebbe non essere vero nelle criptovalute se il livello di aggregazione è incorporato nel prodotto/piattaforma/catena. Se l'aggregatore è strettamente integrato direttamente nella catena, ovviamente si tratta di un'architettura diversa e mi interesserebbe vedere come si sviluppa. Un esempio è AggLayer di Polygon, che consente agli sviluppatori di connettere facilmente le loro L1 e L2 in una rete che aggrega prove e abilita uno strato di liquidità unificato tra le catene utilizzando CDK.

AgLayer

Il modello funziona in modo simile al livello di interoperabilità Nexus di Avail, che include l'aggregazione di prove e meccanismi di aste di ordinazione, rendendo la sua offerta DA più solida. Come AggLayer di Polygon, ogni catena o rollup integrato con Avail interagirà all'interno dell'ecosistema esistente di Avail. Inoltre, i pool Avail hanno ordinato i dati delle transazioni da varie piattaforme blockchain e rollup, tra cui Ethereum, tutti i rollup Ethereum, Cosmos Chain, Avail Rollup, Celestia Rollup e diverse strutture ibride come Validiums, Optimiums e le catene Polkadot Parallel, ecc. Gli sviluppatori di qualsiasi ecosistema possono creare senza autorizzazione sul livello DA di Avail utilizzando Avail Nexus, che può essere utilizzato per l'aggregazione di prove e la messaggistica tra gli ecosistemi.

Utilizza Nexus

Nebra si concentra sull'aggregazione e sulla liquidazione delle prove, che possono essere aggregate tra diversi sistemi di prove. Ad esempio, aggrega la prova di sistema xyz con la prova di sistema abc in modo da avere agg_xyzabc (invece di aggregare all'interno del sistema di prova in modo da avere agg_xyz e agg_abc ). L'architettura utilizza UniPlonK, che standardizza il lavoro dei verificatori tra famiglie di circuiti, rendendo le prove di verifica su diversi circuiti PlonK più efficienti e fattibili. Essenzialmente, utilizza le stesse prove a conoscenza zero (SNARK ricorsivi) per estendere la parte di verifica (di solito il collo di bottiglia in questi sistemi). La liquidazione dell'ultimo miglio è resa più semplice per i clienti perché Nebra gestisce tutta l'aggregazione e la liquidazione dei lotti e i team devono solo modificare le chiamate del contratto API.

Astria sta lavorando su alcuni progetti interessanti su come funziona il loro selezionatore condiviso con l'aggregazione delle prove. Lasciano la parte di esecuzione a Rollup stesso, che esegue il software del livello di esecuzione su un dato spazio dei nomi di un selezionatore condiviso, che è essenzialmente solo l'"API di esecuzione", che è un modo per Rollup di accettare i dati del livello di ordinamento. Potrebbero anche aggiungere facilmente il supporto per le prove di validità qui per garantire che i blocchi non violino le regole della macchina a stati EVM.

Qui, prodotti come Astria agiscono come il processo#1→#2(transazioni fuori ordine → blocchi ordinati), il livello di esecuzione/nodi Rollup sono#2→#3e protocolli come Nebra agiscono come ultimo miglio#3→#4(blocco di esecuzione → prova concisa). Nebra potrebbe anche essere un quinto passo teorico in cui le prove vengono aggregate e poi verificate. Anche Sovereign Labs sta lavorando su un concetto simile all’ultimo passaggio, in cui i ponti a catena incrociata basati sull’aggregazione di prove sono al centro della loro architettura.

Nel complesso, alcuni livelli applicativi stanno iniziando a possedere l'infrastruttura sottostante, in parte perché se non controllano lo stack sottostante, conservare solo le applicazioni del livello superiore può creare problemi di incentivi e costi elevati di adozione da parte degli utenti. D’altro canto, poiché la concorrenza e i progressi tecnologici continuano a ridurre i costi delle infrastrutture, diventa più conveniente integrare applicazioni/catene di applicazioni con componenti modulari. Credo che questa dinamica sarà più forte, almeno per ora.

Con tutte queste innovazioni (livello di esecuzione, livello di regolamento, livello di aggregazione) diventano possibili una maggiore efficienza, un’integrazione più semplice, una maggiore interoperabilità e costi inferiori. Tutto ciò alla fine porta a app migliori per gli utenti e a una migliore esperienza di sviluppo per gli sviluppatori. Questa è una combinazione vincente che può portare a una maggiore innovazione e a un’innovazione più rapida.