Chainlink ha rilasciato la versione 2.0 del suo Cross-Chain Interoperability Protocol (CCIP), introducendo Cross-Chain Verifiers, nuove funzioni per i token pool e impostazioni di finalità configurabili, secondo le note di rilascio del progetto. Una panoramica sulla sicurezza complementare spiega l'architettura più ampia in cui queste funzionalità si inseriscono. Il CCIP, che trasmette messaggi e token tra blockchain che non possono leggere nativamente lo stato dell'altra, estende il lavoro di un progetto noto soprattutto per la sua infrastruttura di oracle nella finanza decentralizzata.

Nel complesso, le modifiche consentono agli emittenti di token di richiedere controlli aggiuntivi prima che un trasferimento cross-chain venga approvato e permettono a diversi asset di operare con diverse impostazioni di sicurezza e finalità. La verifica personalizzata sposta maggiore responsabilità sull'emittente, i percorsi più rapidi possono basarsi su presupposti diversi sulla finalità, e gli utenti devono valutare il percorso specifico del token piuttosto che solo il marchio del bridge.

Cosa è cambiato

Si pensi a un trasferimento tramite bridge come a un cancello tra due blockchain. Prima che il cancello si apra, qualcuno deve confermare che l'asset è stato bloccato o distrutto dall'altra parte. CCIP 2.0 consente all'emittente del token di decidere quali controlli aggiuntivi dovrebbero approvare tale attestazione. Uno stablecoin, un fondo tokenizzato e un token crypto-nativo potrebbero quindi seguire ciascuno regole diverse prima che venga rilasciata una versione cross-chain.

I trasferimenti cross-chain si basano su una decisione che deve essere fidata

Un trasferimento cross-chain di solito implica più del semplice spostamento di un token da un indirizzo a un altro. Un asset può essere bloccato in una rete, o rimosso dalla circolazione lì, prima che una versione corrispondente diventi disponibile su un'altra chain. La parte difficile è confermare che il primo si sia davvero verificato e che la chain di destinazione debba agire di conseguenza.

Un fallimento in quel processo decisionale può creare problemi seri: un trasferimento valido di un utente può essere ritardato, oppure un messaggio non valido potrebbe portare al rilascio di token quando non dovrebbero essere rilasciati.

Il CCIP già fornisce un sistema per trasmettere e verificare messaggi cross-chain. La versione 2.0 aggiunge un modo per i token pool di richiedere un'ulteriore verifica prima di completare un trasferimento. Ciò offre agli emittenti maggiore flessibilità, ma rende anche più importante la configurazione attorno a un percorso di token.

Gli emittenti possono aggiungere le proprie regole di verifica

CCIP 2.0 introduce i Cross-Chain Verifiers, o CCV — componenti di verifica aggiuntivi che possono essere utilizzati insieme al processo di sicurezza esistente del CCIP. In particolare, un progetto non ha bisogno dell'approvazione di Chainlink prima di sviluppare o utilizzare un verificatore aggiuntivo. Questa apertura dà agli emittenti più spazio per modellare un percorso secondo le proprie esigenze, attribuendo loro al contempo maggiore responsabilità nel valutare il verificatore scelto.

Un token pool può specificare quali CCV devono approvare un trasferimento. Un emittente può volere una prova aggiuntiva che un asset sia stato bloccato sulla chain di origine. Un altro potrebbe richiedere una condizione legata alla conformità o una conferma indipendente da un sistema separato. Tale verificatore può pubblicare prove in diversi modi, dai dati firmati e alle API fino alle prove crittografiche.

Il punto importante per gli utenti è che il CCIP non decide quali prove un percorso specifico di token debba fidare. La differenza è pratica: una versione cross-chain di un token potrebbe non seguire più esattamente lo stesso processo di approvazione di un altro asset che usa il CCIP, e il modello di sicurezza del percorso può dipendere dalle scelte dell'emittente.

L'esecuzione più rapida è opzionale

L'aggiornamento include anche impostazioni di finalità configurabili, tra cui una funzione opzionale chiamata Faster Than Finality. Le blockchain non raggiungono tutte la finalità allo stesso modo. Alcune transazioni possono apparire confermate prima che la rete abbia raggiunto il punto in cui riorganizzarle diventa altamente improbabile. Attendere di più può migliorare la certezza, ma può anche rendere un trasferimento cross-chain più lento.

CCIP 2.0 dà alle parti partecipanti di un percorso la possibilità di utilizzare un punto di conferma anticipato. Le note di rilascio chiariscono che questa impostazione deve essere supportata attraverso i relativi componenti mittente, pool, verificatore, esecutore e ricevente. Un percorso più rapido può quindi comportare presupposti operativi diversi rispetto a uno che attende che la transazione sulla chain di origine raggiunga la sua consueta soglia di finalità. Se questi componenti sono configurati in modo incoerente, le note di rilascio avvertono che un messaggio e i suoi contenuti in token potrebbero bloccarsi.

Più controlli aiutano solo quando non condividono la stessa debolezza

Aggiungere verificatori non rende automaticamente più sicuro un percorso di bridge. Gli exploit dei bridge si sono ripetutamente collocati tra le categorie di incidenti più costose nel mondo, e le analisi post-mortem dei principali fallimenti si sono spesso concentrate su come i trasferimenti erano verificati piuttosto che sulle chain stesse. La qualità della configurazione dipende da cosa verifica ciascun controllo e se i sistemi alla base di quei controlli sono realmente indipendenti. Ad esempio, due verificatori possono apparire separati mentre si affidano alla stessa fonte di dati, operatore o servizio off-chain. Se quella dipendenza condivisa fallisce, entrambi i controlli possono giungere alla stessa conclusione errata.

Ciò che conta è se ciascun controllo può fallire per un motivo diverso. Ecco perché il rilascio dà agli emittenti flessibilità piuttosto che una garanzia di sicurezza universale. Un percorso progettato con cura può aggiungere controlli indipendenti utili, mentre uno progettato male può aggiungere complessità senza ridurre il rischio fondamentale.

CCIP 2.0 fornisce il quadro per questi controlli. L'emittente deve comunque decidere quali sono le regole, come funziona il proprio codice e chi può in seguito modificarle.

Perché i controlli a livello di emittente contano oltre il DeFi

Le stesse scelte di design hanno più peso quando un token rappresenta qualcosa al di là di una normale posizione DeFi. Un emittente di stablecoin può necessitare di condizioni diverse rispetto a un protocollo che trasferisce un token di governance crypto-nativo. Un fondo tokenizzato potrebbe richiedere restrizioni di trasferimento, controlli di identità o approvazione dell'emittente in determinate circostanze. Le istituzioni possono inoltre preferire sistemi che rendano le regole attorno a un asset cross-chain più facili da definire e verificare.

Come notato in una precedente analisi di Coindoo sui test delle banche centrali che coinvolgono Chainlink, l'infrastruttura cross-chain viene esplorata sia per i flussi di lavoro finanziari tokenizzati sia per i trasferimenti crypto-nativi.

CCIP 2.0 non dimostra che una particolare istituzione abbia già adottato un verificatore personalizzato. Dà a un emittente l'opzione tecnica di porre condizioni aggiuntive attorno al proprio percorso cross-chain. Ciò potrebbe rendere il protocollo più utile per asset che non possono fare affidamento su un unico set di regole identico. Significa anche che gli utenti possono affrontare restrizioni e rischi diversi a seconda del token che detengono.

Cosa dovrebbero controllare gli utenti prima di usare un percorso cross-chain

L'aggiornamento rende più difficile giudicare un trasferimento solo chiedendosi se utilizzi un fornitore di bridge noto. Prima di spostare un token tra chain, gli utenti potrebbero voler controllare:

• Chi controlla il token pool: l'emittente, un team di protocollo o un sistema di governance separato.
• Se il percorso utilizza verificatori aggiuntivi, e su quali prove si basano quei verificatori.
• Se la finalità rapida è abata, poiché un'attesa più breve può comportare presupposti operativi diversi.
• Chi può modificare la configurazione, compresi i requisiti dei verificatori, i diritti di pausa e l'autorità di aggiornamento.
• Se il token di destinazione porta gli stessi diritti di rimborso e trasferimento della versione detenuta sulla chain di origine.

Queste domande non significano che ogni percorso personalizzato sia insicuro. Aiutano a spiegare perché la parola "bridged" può descrivere sistemi molto diversi.

Un fornitore di bridge è solo una parte della configurazione di sicurezza

CCIP 2.0 riflette un cambiamento più ampio nel design cross-chain. L'infrastruttura di bridge sta diventando meno incentrata sull'applicare un unico processo fisso a ogni token e più orientata a dare agli emittenti strumenti per definire come i loro asset viaggiano tra le reti. Ciò può essere utile dove diversi asset comportano requisiti legali, tecnici o operativi differenti. Il compromesso è che gli utenti necessitano di informazioni più chiare sulle regole allegate al percorso che stanno utilizzando.

Il significato dell'aggiornamento diventerà visibile in come i percorsi vengono effettivamente configurati — quali emittenti aggiungono verificatori personalizzati e quanti abilitano la finalità rapida — poiché queste scelte sono fatte per token piuttosto che da Chainlink per il protocollo nel suo complesso.

Per gli utenti, il cambiamento pratico è semplice: il fornitore di bridge è solo una parte del quadro di sicurezza, e le regole di approvazione che governano il percorso specifico del token meritano la stessa attenzione.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria o di investimento. I trasferimenti cross-chain comportano rischi legati a smart contract, operatività e liquidità.

Pubblicato originariamente da Coindoo.