Smettiamola di cercare di essere protocolli di liquidità

Dopo una serie di exploit su larga scala dei bridge, viene dato molto ossigeno alla narrativa secondo cui la tecnologia cross-chain è intrinsecamente imperfetta: l'interoperabilità cross-chain significa rischio. Con una stima di $ 2 miliardi persi in 13 hack di bridge quest'anno, sta diventando sempre più difficile ignorare questo argomento.

At deBridge, pensiamo che non sia solo imperativo ma inevitabile che tutti i ponti cross-chain ripensino completamente il loro approccio all'aggregazione di liquidità.

I limiti della liquidità bloccata

Bloccando la liquidità per fornire un routing cross-chain (come fanno quasi tutti i bridge in questo momento), i bridge si sono posti in una competizione che sono destinati a perdere. Stiamo vedendo ponti che si scontrano con protocolli di liquidità consolidati e appositamente costruiti come AAVE, Compounde frax, progetti che senza dubbio monetizzeranno la liquidità in modo più efficace e sicuro. Gli esempi abbondano di bridge con centinaia di milioni di dollari in TVL, con un utilizzo estremamente basso della liquidità bloccata.

Con questo design, i progetti di bridge sono costretti a eseguire campagne di mining di liquidità insostenibili che non offrono soluzioni di efficienza del capitale a lungo termine. A meno che gli incentivi simbolici non vengano mantenuti a tempo indeterminato - un'ambizione infondata per qualsiasi progetto - i fornitori di liquidità rimuoveranno inevitabilmente il capitale per perseguire opportunità di rendimento più elevato.

Per aggregare la liquidità in modo sicuro, i bridge dovrebbero acquisire polizze assicurative per consentire ai fornitori di liquidità di coprire i rischi. Questa è un'altra spesa che rende ancora più difficile la monetizzazione della liquidità. Ecco perché la maggior parte dei bridge esistenti non è redditizia, poiché i costi e le ricompense pagate per il mining di liquidità spesso superano l'utile netto del protocollo.

Ci sono anche considerazioni di architettura in gioco, dato che un trasferimento di valore a catena incrociata è una richiesta che può essere risolta in diversi modi. Tutti i bridge esistenti regolano questi ordini dai propri pool di liquidità, dove la liquidità è continuamente bloccata quando è necessaria solo nel momento preciso in cui il trasferimento di valore deve essere eseguito.

Anche la dimensione dell'ordine può variare: se supera la dimensione del pool di liquidità del bridge, il mittente finirà con i token incartati o con una transazione sospesa/bloccata a tempo indeterminato. D'altra parte, se l'ordine è troppo piccolo per le dimensioni del pool di liquidità, l'utilizzo della liquidità è molto basso e inefficiente. Questo circolo vizioso evidenzia ulteriormente che questo approccio del protocollo di liquidità alla progettazione del ponte è inefficace e fondamentalmente sbagliato.

Risolvere il problema della sicurezza

Per quanto importante in una questione come questa, l'insostenibilità economica non è l'unica sfida principale qui. Anche supponendo che i bridge abbiano trovato un modo per utilizzare l'approccio della liquidità bloccata e rimanere efficienti in termini di capitale, ormai è evidente che la creazione di un protocollo di liquidità sicuro è un compito che consuma tutto. Infatti, trasformandosi consapevolmente o inconsapevolmente in protocolli di liquidità, i progetti bridge si stanno assumendo l'immenso compito di salvaguardare una superficie di attacco multiforme.

Per iniziare ad alto livello, uno dei problemi evidenti con un ponte in stile liquidità bloccato è che crea un effetto moltiplicatore del rischio, in cui le vulnerabilità di una catena supportata possono estendersi per compromettere il capitale detenuto in altri ecosistemi.

Qui c'è il problema della sicurezza per procura. Un bridge può avere la sua intera base di liquidità compromessa se esiste una potenziale vulnerabilità nella base di codice di una blockchain/L2 supportata. Abbiamo visto questa possibilità all'inizio di quest'anno con una vulnerabilità scoperta in Optimism, che avrebbe consentito agli aggressori di coniare una quantità arbitraria di risorse e scambiarle prevedibilmente con token in altri ecosistemi.

Anche in questo caso, eventuali problemi con il meccanismo del consenso di una catena possono anche portare a un contagio sistemico, mettendo a rischio qualsiasi liquidità bloccata in altre catene supportate. In questo caso, il bridge trasmette semplicemente l'exploit ad altre catene. Ciò potrebbe includere il 51% di attacchi o altri errori a livello di protocollo.

A parte questi tipi di rischi ereditati, assistiamo sempre più spesso a situazioni in cui gli errori degli stessi progetti bridge, in un modo o nell'altro, hanno causato una perdita di liquidità bloccata. Dagli aggiornamenti del protocollo falliti, alla progettazione di contratti intelligenti scadenti o all'infrastruttura compromessa dei validatori, ci sono molti scenari in cui i malintenzionati possono sfruttare le vulnerabilità nel bridge stesso.

Tutti questi rischi vengono rapidamente aggravati e, come abbiamo visto in troppe occasioni, alla fine nascono dai fornitori di liquidità quando perdono la riscattabilità dei loro asset impacchettati. Tale possibilità dovrebbe essere inaccettabile.

Pochi negano la vasta promessa dell'interoperabilità cross-chain per spingere l'adozione di Web3 a nuovi livelli. Ma con la vastità e la frequenza degli exploit del bridge, è diventato dolorosamente chiaro che il design fondamentale della tecnologia bridge deve essere reinventato dai primi principi. Il progetto del protocollo di liquidità trasformato in ponte non funziona.

C'è un modo in cui possiamo escogitare un approccio fondamentalmente nuovo e unico alla progettazione del bridge, che elimini completamente i rischi per i fornitori di liquidità, elimini i vettori di attacco e allo stesso tempo mantenga il massimo livello di efficienza del capitale?

Potrebbe esserci esattamente questo nel prossimo futuro. In deBridge, stiamo lavorando a un nuovo routing di liquidità cross-chain che risolve tutti questi problemi. Rimani sintonizzato.

Guest post di Alex Smirnov di deBridge Finance

Alex Smirnov è un matematico, ricercatore, sviluppatore e appassionato di blockchain. È CEO e co-fondatore di deBridge, un protocollo generico di messaggistica e interoperabilità cross-chain, dove si concentra sulla progettazione del protocollo, sulla gestione del prodotto, sulle partnership e sulle operazioni. Alex ha co-fondato Phenom, una società di ricerca e sviluppo blockchain, e ha anche guidato un team che ha vinto numerosi hackathon e sviluppato varie soluzioni blockchain e dApp.

→ Per saperne di più

Fonte: https://cryptoslate.com/reimagining-cross-chain-bridges-lets-stop-trying-to-be-liquidity-protocols/