Chainlink ha rilasciato CCIP 2.0 il 28 settembre, una versione del suo protocollo cross-chain che consente agli emittenti di token o a terze parti di eseguire Cross-Chain Verifier opzionali, o CCV, e richiederli prima che un trasferimento possa essere completato. La modifica significa che un verificatore richiesto che va offline può bloccare ogni messaggio che dipende dalla sua attestazione. Un trasferimento può bloccarsi con i token sulla catena di origine già bloccati o bruciati e nessun rilascio o conio corrispondente sulla catena di destinazione.
Dove si ferma il trasferimento
In CCIP 2.0, la sequenza di trasferimento separa la verifica dall'esecuzione. L'OnRamp assembla i requisiti del verificatore per un messaggio. Il pool di token quindi blocca o brucia i token di origine. I servizi di verifica offchain pubblicano attestazioni legate all'ID del messaggio. L'OffRamp controlla le attestazioni richieste prima di rilasciare o coniare sulla catena di destinazione. Chainlink afferma che tutti i CCV richiesti devono restituire risultati validi prima che l'esecuzione proceda. Se un verificatore richiesto non attesta, il messaggio di destinazione può rimanere intatto.
Questo ordine è importante perché il blocco o la bruciatura sul lato origine avviene prima che la verifica sia completata. Un trasferimento bloccato non è una transazione in sospeso nel senso usuale; è uno stato in cui il pool di origine ha spostato i token ma la catena di destinazione non ha prove su cui agire. Chainlink assegna agli operatori CCV esterni la responsabilità dell'implementazione, della manutenzione e del tempo di attività, quindi l'affidabilità di un verificatore richiesto dipende da chi lo gestisce. Il Committee Verifier predefinito comprende 16 operatori di nodo indipendenti, con eventuali CCV aggiuntivi che si affiancano a quella base.
Emittenti e terze parti come dipendenze
Se un emittente gestisce un CCV richiesto per il proprio pool di token, il servizio di quell'emittente diventa una delle parti in grado di ritardare il completamento. Un operatore terzo creerebbe una dipendenza simile. Chainlink ha avvertito che un verificatore non reattivo può bloccare ogni messaggio che richiede la sua attestazione — non solo un trasferimento. Il materiale di lancio dell'azienda non identifica un asset o una corsia di produzione nominata che utilizzi un CCV richiesto gestito dall'emittente, quindi il meccanismo di per sé non è prova che il trasferimento di uno specifico detentore sia stato bloccato.
L'esecuzione sulla catena di destinazione è senza permessi una volta che esistono tutte le prove richieste e viene raggiunto qualsiasi quorum di verificatori opzionali. L'esecutore predefinito normalmente invia la transazione, ma chiunque può inviarla attraverso il percorso di esecuzione manuale. Pagare il gas della catena di destinazione o cambiare l'esecutore non esonera da un'attestazione CCV richiesta mancante; l'OffRamp controlla comunque le prove prima di rilasciare o coniare token.
Gestione dei guasti e tentativi
Quando un tentativo di destinazione fallisce all'interno del percorso protetto dell'OffRamp, può essere contrassegnato come FAILURE e ritentato dopo che il problema di fondo è risolto. L'esecutore predefinito di Chainlink ritenta i fallimenti entro una finestra configurata attualmente impostata a otto ore. Il percorso di esecuzione manuale pubblicato non specifica una cancellazione automatica generale, un rimborso o una restituzione dei token sulla catena di origine quando un verificatore richiesto non attesta mai. Qualsiasi rimedio specifico per l'emittente dipenderebbe dagli accordi di quell'asset.
Due hook offrono un intervento anticipato. Sulle catene EVM, un hook configurato di Chainlink Automated Compliance Engine può rifiutare un trasferimento in uscita prima che il pool di origine blocchi o bruci qualsiasi cosa, il che annulla la transazione di origine. Un hook postflight di destinazione configurato separatamente può rifiutare il rilascio o il conio dopo che il trasferimento sul lato origine è iniziato, lasciando i token non consegnati fino a quando la condizione della policy non è soddisfatta. Entrambi sono scelte di configurazione, non impostazioni predefinite.
Cosa possono verificare gli sviluppatori e i detentori
La domanda pratica per chiunque sposti un token su CCIP 2.0 è quali verificatori richiede una determinata corsia e chi li gestisce. Un CCV richiesto gestito dall'emittente mette quell'emittente nel percorso di ogni trasferimento per quel pool. Un CCV di terze parti aggiunge un altro operatore con il proprio record di tempo di attività. Il Committee Verifier predefinito con 16 operatori è la base, ma CCV aggiuntivi cambiano l'insieme delle dipendenze.
Chainlink non ha nominato un asset o una corsia di produzione che si affidi a un CCV richiesto gestito dall'emittente. Finché non ne appare uno, lo scenario di stallo è una proprietà documentata del design piuttosto che un incidente reale. Gli sviluppatori che valutano l'aggiornamento vorranno sapere cosa succede quando un verificatore richiesto è lento o silenzioso sulla loro specifica corsia — e se l'emittente dietro di esso ha pubblicato un rimedio per i token già bloccati sulla catena di origine.
