Chainlink heeft op 28 september CCIP 2.0 uitgebracht, een versie van zijn cross-chainprotocol waarmee tokenuitgevers of derden optionele Cross-Chain Verifiers, of CCV's, kunnen draaien en deze kunnen vereisen voordat een overdracht kan worden voltooid. Deze wijziging betekent dat een vereiste verifier die offline gaat, elk bericht kan bevriezen dat afhankelijk is van zijn attestatie. Een overdracht kan vastlopen terwijl tokens op de bronketen al zijn vergrendeld of verbrand en er geen overeenkomstige vrijgave of aanmaak op de bestemmingsketen plaatsvindt.
Waar de overdracht stopt
In CCIP 2.0 scheidt de overdrachtsreeks verificatie van uitvoering. De OnRamp stelt de verifiervereisten voor een bericht samen. De tokenpool vergrendelt of verbrandt vervolgens de brontokens. Offchain-verifierdiensten publiceren attestaties die aan de bericht-ID zijn gekoppeld. De OffRamp controleert die vereiste attestaties voordat deze op de bestemmingsketen vrijgeeft of aanmaakt. Chainlink stelt dat alle vereiste CCV's geldige resultaten moeten retourneren voordat de uitvoering doorgaat. Als een vereiste verifier niet attesteert, kan het bestemmingsbericht onaangeroerd blijven.
Die volgorde is belangrijk omdat de vergrendeling of verbranding aan de bronzijde plaatsvindt voordat de verificatie is voltooid. Een vastgelopen overdracht is geen hangende transactie in de gebruikelijke zin; het is een toestand waarin de bronpool de tokens heeft verplaatst, maar de bestemmingsketen geen bewijs heeft om op te handelen. Chainlink geeft externe CCV-exploitanten de verantwoordelijkheid voor implementatie, onderhoud en uptime, dus de betrouwbaarheid van een vereiste verifier berust bij degene die deze draait. De standaard Committee Verifier bestaat uit 16 onafhankelijke node-exploitanten, met eventuele extra CCV's naast die basislijn.
Uitgevers en derden als afhankelijkheden
Als een uitgever een vereiste CCV voor zijn eigen tokenpool draait, wordt de dienst van die uitgever een van de partijen die de voltooiing kan vertragen. Een externe exploitant zou een vergelijkbare afhankelijkheid creëren. Chainlink heeft gewaarschuwd dat een niet-reagerende verifier elk bericht kan blokkeren dat zijn attestatie vereist — niet slechts één overdracht. Het lanceermateriaal van het bedrijf noemt geen specifiek productieasset of lane die een door de uitgever gedraaide vereiste CCV gebruikt, dus het mechanisme op zich is geen bewijs dat de overdracht van een specifieke houder is geblokkeerd.
Uitvoering op de bestemmingsketen is permissionless zodra elk vereist bewijs bestaat en een eventueel quorum voor optionele verifiers is bereikt. De standaard executor dient de transactie normaal gesproken in, maar iedereen kan deze via het handmatige uitvoeringspad indienen. Het betalen van gas op de bestemmingsketen of het wijzigen van de executor heft een ontbrekende vereiste CCV-attestatie niet op; de OffRamp controleert nog steeds bewijzen voordat tokens worden vrijgegeven of aangemaakt.
Afhandeling van fouten en nieuwe pogingen
Wanneer een poging op de bestemming binnen het beschermde pad van de OffRamp mislukt, kan deze als FAILURE worden gemarkeerd en opnieuw worden geprobeerd nadat het onderliggende probleem is opgelost. De standaard executor van Chainlink probeert mislukkingen opnieuw binnen een geconfigureerd venster dat momenteel op acht uur is ingesteld. De gepubliceerde handmatige uitvoeringsroute specificeert geen algemene automatische annulering, terugbetaling of retournering van tokens op de bronketen wanneer een vereiste verifier nooit attesteert. Elke uitgeversspecifieke remedie zou afhangen van de regelingen voor dat asset.
Twee hooks bieden eerdere interventie. Op EVM-ketens kan een geconfigureerde Chainlink Automated Compliance Engine-hook een uitgaande overdracht afwijzen voordat de bronpool iets vergrendelt of verbrandt, waardoor de brontransactie wordt teruggedraaid. Een afzonderlijk geconfigureerde postflight-hook op de bestemming kan de vrijgave of aanmaak afwijzen nadat de overdracht aan de bronzijde is begonnen, waardoor tokens niet worden geleverd totdat aan de beleidsvoorwaarde is voldaan. Beide zijn configuratiekeuzes, geen standaardinstellingen.
Wat bouwers en houders kunnen controleren
De praktische vraag voor iedereen die een token via CCIP 2.0 verplaatst, is welke verifiers een bepaalde lane vereist en wie deze beheert. Een vereiste door de uitgever gedraaide CCV plaatst die uitgever in het pad van elke overdracht voor die pool. Een externe CCV voegt nog een exploitant met een eigen uptime-record toe. De standaard Committee Verifier met 16 exploitanten is de basislijn, maar extra CCV's veranderen de afhankelijkheidsreeks.
Chainlink heeft geen productieasset of lane genoemd die afhankelijk is van een door de uitgever gedraaide vereiste CCV. Totdat er een verschijnt, is het vastloopszenario een gedocumenteerde eigenschap van het ontwerp en geen live-incident. Bouwers die de upgrade evalueren, willen weten wat er gebeurt wanneer een vereiste verifier traag of stil is op hun specifieke lane — en of de uitgever erachter een remedie heeft gepubliceerd voor tokens die al op de bronketen zijn vergrendeld.
