Una breve storia della catena incrociata: spiegazione di nove diverse soluzioni a catena incrociata

Le soluzioni cross-chain sono state l'argomento più discusso nell'ultimo anno. Con l'aumento delle infrastrutture della catena pubblica, c'è stato un enorme interesse per il modo in cui le diverse catene parlano e comunicano. Sono state proposte e implementate soluzioni, ma nessuna risolve i problemi fondamentali senza drastici compromessi. Ora esaminiamo i diversi approcci cross-chain e divulghiamo perché e come daranno forma al futuro dell'infrastruttura cross-chain.

Innanzitutto, discutiamo di cos'è la tecnologia cross-chain e perché è necessaria. Motivo dell'utilizzo: le catene sono eterogenee e richiedono agli sviluppatori molto tempo per tenere traccia delle differenze e delle sfide durante lo spostamento delle risorse. I bridge sono meno sicuri e non possono essere attendibili al 100% perché di solito sono di proprietà dei team di progetto blockchain e altamente centralizzati (disordinati senza coordinamento da parte di ciascun team). L'obiettivo della blockchain di livello 1 è standardizzare, ma la segmentazione delle catene di livello 1 sta portando alla necessità di un livello di infrastruttura a catena incrociata che sia anche al di sotto dei livelli 1.

La storia dei meccanismi a catena incrociata deve essere illustrata e confrontata per comprendere le soluzioni a catena incrociata e confrontare le loro differenze e attributi.

Trasferimento manuale

 
La prima soluzione cross-chain è un trasferimento manuale di asset. Il processo inizia chiedendo all'utente di trasferire le risorse a un portafoglio specifico sulla catena A e un'entità centralizzata monitora il portafoglio per i trasferimenti e li registra in Excel. Quindi, dopo un periodo di tempo limitato (di solito a fini di monitoraggio), l'entità accredita le attività sulla catena B dopo la verifica. Il vantaggio di questo approccio è la facilità di implementazione, ma è soggetto a errori umani e ha una garanzia di sicurezza molto bassa. Non c'è nemmeno decentramento in questo approccio.

Trasferimento semiautomatico

L'iterazione successiva migliora facendo in modo che l'utente trasferisca le risorse a un portafoglio specifico e/o a un contratto intelligente sulla catena A. Quindi, un programma centralizzato monitora l'indirizzo per i trasferimenti. Tale programma invia automaticamente le risorse alla catena B dopo la verifica. Il vantaggio è ancora la facilità di implementazione senza troppa complessità o codifica e i record possono essere conservati in catena anziché localmente. Lo svantaggio è che il programma centralizzato può essere difettoso o non funzionare correttamente. Anche il conto di credito centrale potrebbe esaurire i fondi. Anche la garanzia di sicurezza è bassa e non c'è decentramento.

Scambio centralizzato

Quando le semplici soluzioni cross-chain non sono scalabili, gli scambi centralizzati prosperano in base alle esigenze cross-chain. Funzionano facendo in modo che gli utenti trasferiscano le risorse nella loro borsa centralizzata e quindi, utilizzando lo scambio "interno" della borsa, trasformano le "attività X" sulla catena A in "attività Y" sulla catena B attraverso la contabilità dei record. Il vantaggio è evidente: è la soluzione più semplice da utilizzare: non è necessaria alcuna codifica e c'è un'elevata affidabilità negli scambi di livello 1. Ma il problema espone lo svantaggio opposto: il controllo centralizzato della disponibilità di depositi/prelievi. Lo scambio centralizzato offre un'elevata sicurezza con lo svantaggio del minimo decentramento.

Ponte centralizzato

Il prossimo progresso migliora grazie a un'infrastruttura separata per il trasferimento di risorse attraverso le catene: un ponte. Un bridge centralizzato funziona facendo in modo che l'utente trasferisca le risorse, quindi utilizzando la funzione di trasferimento del bridge, avvii il trasferimento delle risorse X sulla catena A nelle risorse Y sulla catena B. Un relayer centralizzato (o un insieme di) è responsabile del processo:

Blocca le risorse X sulla catena A
verificare
Conta attività Y sulla catena B
Il vantaggio di questo ponte è il processo completamente automatico senza alcuna interruzione manuale. E lo svantaggio è ancora il controllo centralizzato di quando è disponibile il deposito/prelievo. Inoltre, il bridge potrebbe essere danneggiato o violato, rendendolo di tanto in tanto non funzionante. Quindi la sicurezza è media e non c'è ancora decentramento.

Ponte decentralizzato con MPC

L'iterazione successiva è il decentramento del modello di verifica invece di un bridge centralizzato. Un bridge MPC (Multi-Party Computation) inizia con il trasferimento di risorse da parte degli utenti. Utilizzando la funzione di trasferimento del bridge, avvia il trasferimento delle risorse X sulla catena A nelle risorse Y sulla catena B. Di solito esiste un insieme decentralizzato di relayer responsabile del processo:

Blocca le risorse X sulla catena A utilizzando MPC
Verificare utilizzando MPC
Conta i beni Y sulla catena B usando MPC
Il vantaggio di MPC è il processo completamente automatico senza alcuna interruzione manuale e non è necessario centralizzare i nodi di inoltro. Lo svantaggio è l'alto costo computazionale e di comunicazione di MPC. Inoltre, i nodi possono essere compromessi o collusi. La sicurezza è media, mentre anche la decentralizzazione è media.

Ponte Atomic Swap con HTLC

Un'altra classe di bridge sorge a seconda della tecnologia atomic swap (Lightning Network). Funziona in questo modo: l'utente trasferisce gli asset in un atomic swap bridge e quindi, utilizzando la funzione di trasferimento del bridge, avvia il trasferimento degli asset X sulla catena A negli asset Y sulla catena B:

Crea un nuovo contratto a tempo HTLC – Hash Lock
Depositare le attività X in contratto sulla catena A
Genera chiave di blocco hash + crittografa un segreto per il ritiro finale entro il tempo T sulla catena B
Presenta un segreto crittografato per contrattare sulla catena B per ritirare i beni Y
OPPURE il tempo T è trascorso e recuperare le risorse X dal contratto sulla catena A con il segreto crittografato
Il vantaggio significativo è che non esiste un nodo/processo centralizzato che controlla il trasferimento del bridge. E lo svantaggio è relativamente comune: un costo elevato per la distribuzione di HTLC e l'esecuzione di chiamate HTLC. A causa della mancanza di fiducia, mantenere un'elevata sicurezza e l'audit trail è impegnativo. La sicurezza di questo approccio è elevata e anche il decentramento è elevato, visti gli inconvenienti di cui sopra.

Interoperabilità cross-chain con Light Client + Oracle

Dopo l'approccio del bridge ad alto costo, sono nate più implementazioni per ridurre questo costo. La tecnologia Light Client è diventata l'ultima norma per semplificare le verifiche cross-chain. Il processo è il seguente:

In primo luogo, l'utente trasferisce le risorse X in un contratto di protocollo di interoperabilità cross-chain sulla catena A
Un messaggio di trasferimento è impostato su contratto e viene raccolto da nodi relayer decentralizzati
I nodi inviano prove attraverso il contratto del protocollo sulla catena B
Gli aggiornamenti dell'intestazione del blocco (client leggero) sono gestiti dalla rete Oracle per garantire la consegna e la validità
L'utente ritira gli asset Y dal contratto del protocollo sulla catena B al momento della convalida
Il vantaggio di questo approccio è che non sono necessari token o catene intermedie dal trasferimento al completamento. La conferma immediata è possibile dopo l'aggiornamento delle intestazioni dei blocchi. Gli svantaggi sono 1) rischi di collusione da Oracles, 2) dovuti alla mancanza di fiducia, al mantenimento di un'elevata sicurezza e l'audit trail è impegnativo. La sicurezza di questo approccio è media, mentre il decentramento è elevato.

Interoperabilità a catena incrociata con catena a relè

Sulla base delle lezioni dell'approccio Oracle, è presente anche una pura soluzione a catena di inoltro. Il processo è leggermente diverso:

L'utente trasferisce le risorse X in un contratto di protocollo di interoperabilità cross-chain sulla catena A
Un messaggio di trasferimento è impostato su contratto e viene raccolto da nodi relayer decentralizzati
I nodi inviano prove al contratto della catena di inoltro
I validatori della catena di inoltro sottostanti gestiscono gli aggiornamenti dei blocchi per garantire la consegna e la validità
Dopo la convalida, i nodi relayer inoltrano il messaggio di trasferimento al contratto del protocollo sulla catena B
L'utente ritira i beni Y dal contratto del protocollo sulla catena B
Il vantaggio di questo approccio rispetto alla semplice soluzione Oracle sono le tariffe più economiche delle catene di inoltro che consumano la maggior parte dei costi. La conferma immediata è possibile dopo l'aggiornamento dei blocchi, il che è fondamentale per risolvere tempi di ritardo più lunghi. Il problema è che il protocollo stesso potrebbe non supportare un ecosistema all-chain. La sicurezza è alta (all'interno dell'ecosistema) e anche il decentramento è alto.

Strato infrastrutturale a catena incrociata con Light Client + Catena di inoltro

La soluzione di nuova generazione si concentra sul livello di infrastruttura cross-chain risolvendo tutti i problemi fondamentali di cui sopra. Combina la tecnologia del client leggero con una catena a relè per incorporare tutte le catene:

L'utente trasferisce le risorse X in un contratto di interoperabilità di un livello di infrastruttura cross-chain sulla catena A
Un messaggio di trasferimento è impostato su contratto e viene raccolto da nodi relayer decentralizzati
I nodi inviano prove al contratto di interoperabilità della catena di inoltro
Gli aggiornamenti dell'intestazione del blocco (client leggero) sono gestiti da nodi di manutenzione decentralizzati per garantire la consegna e la validità
Dopo la convalida, i nodi relayer inoltrano il messaggio di trasferimento al contratto di interoperabilità sulla catena B
L'utente ritira gli asset Y dal contratto di interoperabilità sulla catena B
Questa soluzione garantisce l'interoperabilità con tariffe molto convenienti grazie all'implementazione di una catena di relè. Fornisce inoltre una conferma immediata dopo l'aggiornamento delle intestazioni dei blocchi. La sfida più grande è l'elevata complessità dell'ottimizzazione dei client leggeri sulla catena di inoltro. Conducendo una quantità sufficiente di ricerca e ingegneria, queste ottimizzazioni dovrebbero supportare i vantaggi che gli altri non possono risolvere. La sicurezza è molto alta e il decentramento è alto.

Informazioni sul protocollo MAP

Tra le soluzioni a catena incrociata, dobbiamo ancora vederne una che risolva tutti i problemi di cui sopra. Fino all'attuazione del protocollo MAP. Dopo 3 anni di ricerca e sviluppo complessi, MAP Protocol ha finalmente raggiunto il livello Omnichain con tecnologia client + catena di relè leggera senza compromessi. MAP ha implementato i principi Omnichain con le seguenti proprietà:

Pronto per gli sviluppatori
Copertura per tutta la catena
Costo minimo
Finalità di sicurezza
Conferma immediata

Il protocollo MAP è il livello dell'infrastruttura per supportare la costruzione di bridge, DEX, protocolli di interoperabilità e altro ancora. Supporta la verifica da parte dei client leggeri sulla catena di inoltro MAP direttamente, per ridurre i costi. E fornisce incentivi integrati in ogni componente per gli sviluppatori di dapp da guadagnare o presentare agli utenti finali. MAP supporta catene EVM e non EVM: il livello di protocollo è isomorfo con tutte le catene.

Per il futuro, MAP è l'infrastruttura dietro tutte le catene che costituiranno il nuovo livello di base. Gli sviluppatori non sono più limitati dalla loro catena di scelta e possono concentrarsi sul prodotto dapp stesso. Il futuro è Omnichain e più modularizzazione e incentivazione sono la strada da percorrere.