I controlli obbligatori degli emittenti possono lasciare in stallo i trasferimenti CCIP 2.0 di Chainlink

Chainlink CCIP 2.0 consente a un emittente di token di richiedere un verificatore aggiuntivo prima che i token passino da una blockchain a un'altra. La funzionalità è stata annunciata il 28 settembre. Aggiunge verificatori cross-chain (Cross-Chain Verifiers, CCV) opzionali accanto al Comitato di verifica predefinito di CCIP. Un emittente o una terza parte può gestire un verificatore e rendere la sua approvazione una condizione per la consegna. Il pool sorgente può bloccare o bruciare i token prima che il verificatore obbligatorio fornisca la propria attestazione. La blockchain di destinazione non può sbloccare o coniare i token senza l'attestazione richiesta. Il materiale di lancio di Chainlink non indica un asset e una tratta di produzione che utilizzino un verificatore obbligatorio gestito dall'emittente. La funzionalità, quindi, non dimostra che un emittente abbia bloccato il trasferimento di un titolare. L'OnRamp di CCIP raccoglie i requisiti di verifica per un trasferimento. L'OnRamp registra il messaggio per i servizi di verifica off-chain dopo che il pool sorgente ha bloccato o bruciato i token. Questi servizi monitorano l'evento sulla rete sorgente e applicano le proprie regole di finalità e verifica. Pubblicano attestazioni associate all'ID del messaggio. L'OffRamp di CCIP controlla le attestazioni obbligatorie prima che il pool di destinazione sblocchi o conii i token. I controlli si basano sulle impostazioni della tratta e del pool di token. Anche uno smart contract ricevente può imporre requisiti di verifica. Le preferenze del mittente possono aggiungersi all'insieme dei verificatori sul lato sorgente. Un trasferimento di soli token non prevede una chiamata di ritorno al contratto ricevente con preferenze di verifica da controllare. Chainlink afferma che tutti i CCV obbligatori devono fornire risultati validi prima che l'esecuzione possa procedere. Il suo modello di fiducia avverte che un verificatore che non risponde può bloccare ogni messaggio che richiede la sua attestazione. Un emittente che gestisce un verificatore e lo rende obbligatorio per il proprio pool di token può ritardare il completamento. Un operatore terzo può creare una dipendenza simile sotto il proprio controllo. Chainlink afferma che il Comitato di verifica predefinito comprende 16 operatori di nodi indipendenti. I CCV aggiuntivi operano insieme a questa configurazione di base. Chainlink attribuisce agli operatori esterni dei CCV la responsabilità dell'implementazione, della manutenzione e della continuità del servizio. L'esecuzione sulla blockchain di destinazione è consentita senza autorizzazione una volta disponibili tutte le prove obbligatorie e raggiunto l'eventuale quorum dei verificatori opzionali. Normalmente è l'esecutore predefinito di Chainlink a inviare la transazione. Chiunque può inviarla tramite la procedura di esecuzione manuale. Cambiare esecutore o pagare il gas sulla blockchain di destinazione non compensa un'attestazione obbligatoria mancante. L'OffRamp continua a controllare le prove prima di sbloccare o coniare i token. Un messaggio sulla rete di destinazione può rimanere UNTOUCHED se l'attestazione obbligatoria non è stata raccolta. UNTOUCHED significa che non è stata registrata alcuna esecuzione. Un tentativo inviato sulla rete di destinazione che fallisce all'interno del percorso protetto dell'OffRamp può essere contrassegnato come FAILURE. Chainlink afferma che un tentativo fallito può essere ripetuto dopo aver risolto il problema sottostante. Il suo esecutore predefinito riprova i tentativi falliti entro una finestra configurata, attualmente fissata a 8 ore. Tale limite si applica al servizio automatizzato. La guida all'esecuzione manuale spiega come verificare lo stato dei controlli e dell'esecuzione. Include casi in cui l'indicizzatore non ha raccolto il risultato di un verificatore esterno. La procedura di esecuzione manuale pubblicata da Chainlink non specifica una modalità generale di annullamento automatico, rimborso o restituzione dei token sulla blockchain sorgente nel caso in cui un verificatore obbligatorio non fornisca mai l'attestazione. Qualsiasi rimedio specifico dell'emittente dipende dagli accordi relativi all'asset. Sulle blockchain EVM, un hook configurato del motore di conformità automatizzata di Chainlink (Chainlink Automated Compliance Engine, ACE) può respingere un trasferimento in uscita prima che il pool sorgente blocchi o bruci i token. Questo errore preliminare annulla la transazione sulla rete sorgente. Un hook separato, configurato per i controlli successivi sulla rete di destinazione, può respingere lo sblocco o il conio dopo che il trasferimento sul lato sorgente è iniziato. I token rimangono quindi non consegnati finché la condizione prevista dalla policy non è risolta e l'esecuzione non viene ripetuta. La guida all'integrazione ACE di Chainlink descrive queste configurazioni come distinte e opzionali. L'elenco di Chainlink per la rete principale riporta le reti e i token supportati. La presenza nell'elenco non indica se una tratta di produzione richieda un verificatore gestito dall'emittente o abbia attivato un controllo ACE sulla rete di destinazione. Un annuncio di un partner o una precedente migrazione di un asset non dimostrano quali siano tali impostazioni. Il rilascio offre anche trasferimenti più rapidi rispetto alla finalità completa della blockchain sorgente. La finalità completa della rete sorgente resta l'impostazione predefinita. La guida FTF di Chainlink afferma che l'opzione più rapida può esporre un trasferimento a una doppia esecuzione sulla rete di destinazione dopo una riorganizzazione abbastanza profonda. Altri CCV obbligatori possono applicare proprie regole sulle riorganizzazioni. L'opzione di trasferimento più rapido non elimina la necessità delle attestazioni obbligatorie.