Chainlink lanserte CCIP 2.0 den 28. september, en versjon av sin protokoll på tvers av kjeder som lar tokenutstedere eller tredjeparter kjøre valgfrie Cross-Chain Verifiers, eller CCV-er, og kreve dem før en overføring kan fullføres. Endringen betyr at en påkrevd verifiseringsmekanisme som går offline kan fryse hver melding som er avhengig av attesteringen. En overføring kan stanse med kildekjedens tokens allerede låst eller brent, og ingen tilsvarende frigjøring eller utstedelse på destinasjonskjeden.
Hvor overføringen stopper
I CCIP 2.0 skiller overføringssekvensen verifisering fra utførelse. OnRamp samler verifiseringskravene for en melding. Tokenpoolen låser eller brenner deretter kildetokenene. Verifiseringstjenester utenfor kjeden publiserer attestasjoner knyttet til meldings-ID-en. OffRamp sjekker disse påkrevde attestasjonene før den frigjør eller utsteder på destinasjonskjeden. Chainlink oppgir at alle påkrevde CCV-er må returnere gyldige resultater før utførelsen fortsetter. Hvis en påkrevd verifiseringsmekanisme ikke attesterer, kan destinasjonsmeldingen forbli urørt.
Denne rekkefølgen er viktig fordi låsingen eller brenningen på kildesiden skjer før verifiseringen fullføres. En fastlåst overføring er ikke en ventende transaksjon i vanlig forstand; det er en tilstand der kil depotet har flyttet tokenene, men destinasjonskjeden ikke har noe bevis å handle på. Chainlink gir eksterne CCV-operatører ansvar for implementering, vedlikehold og oppetid, så påliteligheten til en påkrevd verifiseringsmekanisme avhenger av hvem som driver den. Standard Committee Verifier består av 16 uavhengige nodeoperatører, med eventuelle ekstra CCV-er ved siden av denne baselinen.
Utstedere og tredjeparter som avhengigheter
Hvis en utsteder kjører en påkrevd CCV for sin egen tokenpool, blir denne utstederens tjeneste en av partene som kan forsinke fullføringen. En tredjepartsoperatør vil skape en tilsvarende avhengighet. Chainlink har advart om at en ikke-responsiv verifiseringsmekanisme kan stanse hver melding som krever dens attestasjon – ikke bare én overføring. Selskapets lanseringsmateriale identifiserer ikke en navngitt produksjonsressurs eller bane som bruker en utstederstyrt påkrevd CCV, så mekanismen i seg selv er ikke bevis på at en bestemt eiers overføring har blitt blokkert.
Utførelse på destinasjonskjeden er tillatelsesfri når alle påkrevde bevis eksisterer og eventuelt påkrevd verifiseringskvorum er oppnådd. Standardutføreren sender vanligvis transaksjonen, men hvem som helst kan sende den gjennom den manuelle utførelsesbanen. Å betale gass på destinasjonskjeden eller bytte utfører fraskriver ikke en manglende påkrevd CCV-attestasjon; OffRamp sjekker fortsatt bevis før den frigjør eller utsteder tokens.
Feilhåndtering og nye forsøk
Når et destinasjonsforsøk mislykkes innenfor OffRamps beskyttede bane, kan det merkes FAILURE og prøves på nytt etter at det underliggende problemet er løst. Chainlinks standardutfører prøver mislykkede forsøk på nytt innen et konfigurert tidsvindu som for øyeblikket er satt til åtte timer. Den publiserte manuelle utførelsesruten spesifiserer ikke en generell automatisk kansellering, refusjon eller retur av kildetokens når en påkrevd verifiseringsmekanisme aldri attesterer. Eventuelle utstederspesifikke rettsmidler vil avhenge av den enkelte ressursens ordninger.
To hooks tilbyr tidligere inngripen. På EVM-kjeder kan en konfigurert Chainlink Automated Compliance Engine-hook avvise en utgående overføring før kil depotet låser eller brenner noe, noe som tilbakefører kildetransaksjonen. En separat konfigurert destinasjons-postflight-hook kan avvise frigjøring eller utstedelse etter at overføringen på kildesiden har startet, og etterlate tokens ulevert til policybetingelsen er oppfylt. Begge er konfigurasjonsvalg, ikke standardinnstillinger.
Hva utviklere og innehavere kan sjekke
Det praktiske spørsmålet for alle som flytter et token over CCIP 2.0, er hvilke verifiseringsmekanismer en gitt bane krever og hvem som driver dem. En påkrevd utstederstyrt CCV setter denne utstederen i veien for hver overføring for den poolen. En tredjeparts-CCV legger til en annen operatør med sin egen oppetidshistorikk. Standard Committee Verifier med 16 operatører er baselinen, men flere CCV-er endrer avhengighetssettet.
Chainlink har ikke navngitt en produksjonsressurs eller bane som er avhengig av en utstederstyrt påkrevd CCV. Inntil en dukker opp, er stoppscenarioet en dokumentert egenskap ved designet snarere enn en faktisk hendelse. Utviklere som vurderer oppgraderingen, vil vite hva som skjer når en påkrevd verifiseringsmekanisme er treg eller stille på deres spesifikke bane – og om utstederen bak den har publisert en løsning for tokens som allerede er låst på kildekjeden.
