Chainlink lançou o CCIP 2.0 em 28 de setembro, uma versão de seu protocolo de cruz-cadeia que permite que os emissores de token ou terceiros executem verificadores de cruz-cadeia opcionais, ou CCVs, e os exijam antes que uma transferência possa ser concluída. Isso significa que um verificador necessário que vai offline pode congelar todas as mensagens que dependem de sua atestação. Uma transferência pode ficar presa com os tokens da cadeia de origem já bloqueados ou queimados e sem correspondente liberação ou emissão na cadeia de destino.
Onde a transferência para
No CCIP 2.0, a sequência de transferência separa a verificação da execução. O OnRamp monta os requisitos de verificador para uma mensagem. A piscina de tokens então bloqueia ou queima os tokens da cadeia de origem. Serviços de verificação offchain publicam atestações ligadas ao ID da mensagem. O OffRamp verifica essas atestações necessárias antes de liberar ou emitir tokens na cadeia de destino. Chainlink afirma que todos os verificadores CCV necessários devem retornar resultados válidos antes que a execução continue. Se um verificador necessário não atestar, a mensagem de destino pode permanecer inalterada.
Essa ordem importa porque o bloqueio ou queima da cadeia de origem ocorre antes que a verificação seja concluída. Uma transferência presa não é um transação pendente no sentido usual; é um estado onde a piscina de origem moveu os tokens, mas a cadeia de destino não tem prova para agir. Chainlink atribui responsabilidade aos operadores de verificadores externos para implementação, manutenção e uptime, de forma que a confiabilidade de um verificador necessário depende de quem o executa. O default Committee Verifier consiste em 16 operadores de nó independentes, com qualquer verificador adicional sendo adicionado ao baseline.
Emissores e terceiros como dependências
Se um emissor executa um verificador necessário CCV para sua piscina de tokens, a serviço desse emissor se torna uma das partes capazes de atrasar a conclusão. Um operador terceirizado criaria uma dependência similar. Chainlink advertiu que um verificador inativo pode atrasar todas as mensagens que requerem sua atestação — não apenas uma transferência. O material de lançamento da empresa não identifica um ativo de produção nomeado ou uma faixa usando um verificador necessário CCV emissor, então o mecanismo em si não é evidência de que uma transferência específica de um titular foi bloqueada.
A execução de destino é permissiva uma vez que cada prova necessária exista e qualquer quórum de verificadores opcional seja atendido. O default executor normalmente submete a transação, mas qualquer pessoa pode submetê-la através do caminho de execução manual. Pagar gas de destino ou mudar o executor não dispensa uma atestação de verificador necessário CCV; o OffRamp ainda verifica provas antes de liberar ou emitir tokens.
Manejo de falhas e reinícios
Quando um tentativa de destino falhar dentro do caminho protegido do OffRamp, pode ser marcado como FAILURÊ e tentado novamente após o problema subjacente for resolvido. O executor padrão da Chainlink reúne falhas dentro de um janela configurada atualmente definida em oito horas. O caminho de execução manual publicado não especifica uma cancelação geral automática, reembolso ou devolução de tokens da cadeia de origem quando um verificador necessário CCV nunca atesta. Qualquer medida específica do emissor dependeria das arranjos desse ativo.
Dois ganchos oferecem intervenção mais cedo. Em cadeias EVM, um gancho configurado do Automatizado Compliance Engine Chainlink pode rejeitar uma transferência de saída antes que a piscina de origem bloquee ou queime qualquer coisa, o que reverterá a transação da fonte. Um gancho postflight configurado separadamente na cadeia de destino pode rejeitar a liberação ou a emissão após o transferência da fonte ter começado, deixando os tokens intransferíveis até que a condição da política seja atendida. Ambos são escolhas de configuração, não defaults.
O que construtores e detentores podem verificar
A questão prática para qualquer um que mova um token sobre o CCIP 2.0 é qual verificador uma determinada faixa requer e quem os opera. Um verificador necessário CCV emissor coloca aquele emissor no caminho de cada transferência para aquele pool. Um verificador CCV terceirizado adiciona outro operador com seu próprio registro de uptime. O default 16-verificador Committee Verifier é o baseline, mas verificadores adicionais alteram o conjunto de dependência.
Chainlink não nomeou um ativo de produção ou uma faixa que dependa de um verificador necessário CCV emissor. Até que isso aconteça, o cenário de atraso está documentado como uma propriedade do design, em vez de um incidente vivo. Construtores avaliando a atualização quererão saber o que acontece quando um verificador necessário é lento ou mudo em sua faixa específica — e se o emissor por trás disso publicou uma solução para tokens já bloqueados na cadeia de origem.
