Il Trilemma Dei Bridge: Asset Nativi, Liquidità Unificata e Finalizzazione Istantanea

Chi è nel mondo blockchain sa che il più noto trilemma riguarda: decentralizzazione, sicurezza, scalabilità. Decentralizzazione indica un network non centralizzato, con tanti nodi. Affinchè sia decentralizzato è necessario che l'hardware per validare transazioni sia alla portata di più persone possibili. Questo è anche connesso alla sicurezza: più un network è decentralizzato e migliore sarà la sua sicurezza. Infine la scalabilità indica la velocità di conferma delle transazioni e la loro economicità. Un network molto scalabile è economico e veloce e viceversa. Viene definito trilemma perchè al migliorare 1 o 2 di questi 3 parametri si peggiora l'altro o gli altri 2. In poche parole non esiste la blockchain perfetta, bisogna solo trovare il giusto compromesso. 

Per approfondire: Come Risolvere Il Trilemma: Scalabilità, Sicurezza, Decentralizzazione

Un altro noto trilemma in ambito blockchain è quello dei bridge che sono uno dei più grandi punti deboli del mondo blockchain perchè essendo multichain hanno tanti punti di attacco. Un bridge hackerato e derubato dei suoi asset nativi immessi come collaterale, porta al de-peg della versione bridgiata per mancanza di liquidità.

TRILEMMA DEI BRIDGE

Il trilemma dei bridge ha 3 parametri da considerare:

-Native Assets (cioè la necessità di trasportare asset nativi nella chain di destinazione)

-Unified Liquidity (unico pool di liquidità per tutte le chains quindi accesso condiviso)

-Instant Guaranteed Finality (appena la transazione è confermata, i fondi dovrebbero arrivare istantaneamente nella chain di destinazione)

Anche in questo caso, è possibile prediligere 1 o 2 di questi 3 parametri. Un asset sintetico finalizzato mediante meccanismo lock & mint e burn & redeem raggiunge l'Instant Guaranteed Finality poiché gli asset vengono coniati sulla catena di destinazione senza alcuna possibilità di reversione a causa della mancanza di liquidità. Tuttavia, gli utenti ricevono un asset sintetico e devono poi ri-scambiarlo con la risorsa di cui hanno effettivamente bisogno. Ad esempio deposito Bitcoin nativo, ottengo una versione sintetica che ne traccia il prezzo (wBTC). Ovviamente se il bridge viene hackerato con la perdita degli asset nativi ci sarebbero problemi di liquidità e perdita del peg.

Nei bridge tradizionali, viene usato qualcosa chiamato come liquidità frammentata in cui si hanno pool separati per i diversi token (ad esempio se devo trasferire USDT da Ethereum a Solana, devo avere 2 pool di USDT sulle due chains). In uno schema frammentato, ogni catena mantiene un pool di liquidità separato appunto, dove se uno dei due pool si esaurisce otterrei ritardi o il fallimento della transazione. Per risolvere questo problema, l'utilizzo della liquidità unificata consentirà a tutte le chains di depositare e prelevare da un unico pool di liquidità. Tutte le chains condividono un singolo pool: USDC pool servirà tutte le chains ad esempio.

La liquidità unificata presenta il problema che se più transazioni simultanee vengono ritirate dallo stesso pool di liquidità, è necessario fare attenzione che il pool non si esaurisca prima che tutte le transazioni possano essere completate. Il bridge ideale dovrebbe permettere di scambiare un token sulla chain di ETH con un altro token sulla chain di BNB (esempio), utilizzando asset nativi ed un unico pool di liquidità multi-chain. Il tutto con una sola transazione. 

Una volta risolto il trilemma, non abbiamo più bisogno del lock & mint di asset sintetici o di una liquidità frammentata. Invece, è possibile avere simultaneamente pool unificati di risorse native legate a tutte le catene, creando ordini di maggiore efficienza (senza che la transazione fallisca per mancanza di liquidità). I LP potranno partecipare a un pool di asset unilaterali senza impermanent loss e riscuotere commissioni da tutti i trasferimenti in entrata, indipendentemente dalla loro catena di origine e senza asset wrapped/sintentici. Stargate costruito su LayerZero pare abbia risolto questo problema tramite il wrapping di un algoritmo Delta (Δ) che avviene in una singola transazione dalla catena di origine per eseguire azioni come swap -> bridge -> swap.