Chainlink udostępnił CCIP 2.0 28 września — wersję swojego protokołu międzyłańcuchowego, która pozwala emitentom tokenów lub stronom trzecim uruchamiać opcjonalnych weryfikatorów międzyłańcuchowych (Cross-Chain Verifiers, CCV) i wymagać ich przed zakończeniem transferu. Zmiana oznacza, że wymagany weryfikator, który przejdzie w tryb offline, może zamrozić każdą wiadomość zależną od jego poświadczenia. Transfer może utknąć, gdy tokeny w łańcuchu źródłowym są już zablokowane lub spalone, a w łańcuchu docelowym nie następuje odpowiadające im uwolnienie ani emisja.
Gdzie zatrzymuje się transfer
W CCIP 2.0 sekwencja transferu oddziela weryfikację od wykonania. OnRamp zestawia wymagania dotyczące weryfikatorów dla wiadomości. Następnie pula tokenów blokuje lub spala tokeny źródłowe. Usługi weryfikatorów pozałańcuchowych publikują poświadczenia powiązane z identyfikatorem wiadomości. OffRamp sprawdza te wymagane poświadczenia, zanim uwolni lub wyemituje tokeny w łańcuchu docelowym. Chainlink podaje, że wszystkie wymagane CCV muszą zwrócić prawidłowe wyniki, zanim wykonanie będzie kontynuowane. Jeśli wymagany weryfikator nie poświadczy, wiadomość docelowa może pozostać nietknięta.
Ta kolejność ma znaczenie, ponieważ blokada lub spalenie po stronie źródłowej następuje przed zakończeniem weryfikacji. Zablokowany transfer nie jest transakcją oczekującą w zwykłym sensie; to stan, w którym pula źródłowa przeniosła tokeny, ale łańcuch docelowy nie ma dowodu, na podstawie którego mógłby działać. Chainlink przypisuje zewnętrznym operatorom CCV odpowiedzialność za wdrożenie, utrzymanie i dostępność, więc niezawodność wymaganego weryfikatora zależy od tego, kto go uruchamia. Domyślny Committee Verifier składa się z 16 niezależnych operatorów węzłów, a wszelkie dodatkowe CCV działają obok tego punktu odniesienia.
Emitenci i strony trzecie jako zależności
Jeśli emitent uruchamia wymagany CCV dla własnej puli tokenów, usługa tego emitenta staje się jednym z podmiotów mogących opóźnić zakończenie. Podobną zależność stworzyłby operator zewnętrzny. Chainlink ostrzegał, że niereagujący weryfikator może wstrzymać każdą wiadomość wymagającą jego poświadczenia — nie tylko jeden transfer. Materiały premierowe firmy nie wskazują żadnego nazwanego produkcyjnego zasobu ani ścieżki wykorzystującej wymagany CCV prowadzony przez emitenta, więc sam mechanizm nie jest dowodem na to, że transfer konkretnego posiadacza został zablokowany.
Wykonanie w łańcuchu docelowym jest bezzezwoleniowe, gdy istnieją wszystkie wymagane dowody i zostanie osiągnięte kworum opcjonalnego weryfikatora. Domyślny executor zwykle wysyła transakcję, ale każdy może ją wysłać przez ścieżkę ręcznego wykonania. Opłacenie gazu w łańcuchu docelowym lub zmiana executora nie uchyla brakującego wymaganego poświadczenia CCV; OffRamp nadal sprawdza dowody przed uwolnieniem lub emisją tokenów.
Obsługa awarii i ponowne próby
Gdy próba docelowa rzeczywiście nie powiedzie się w chronionej ścieżce OffRamp, można ją oznaczyć jako FAILURE i ponowić po naprawieniu podstawowego problemu. Domyślny executor Chainlink ponawia nieudane próby w skonfigurowanym oknie, obecnie ustawionym na osiem godzin. Opublikowana ścieżka ręcznego wykonania nie określa ogólnego automatycznego anulowania, zwrotu ani przywrócenia tokenów łańcucha źródłowego, gdy wymagany weryfikator nigdy nie poświadczy. Jakiekolwiek rozwiązanie specyficzne dla emitenta zależałoby od ustaleń dotyczących tego zasobu.
Dwa hooki oferują wcześniejszą interwencję. W łańcuchach EVM skonfigurowany hook Chainlink Automated Compliance Engine może odrzucić wychodzący transfer, zanim pula źródłowa cokolwiek zablokuje lub spali, co wycofuje transakcję źródłową. Osobno skonfigurowany hook postflight w łańcuchu docelowym może odrzucić uwolnienie lub emisję po rozpoczęciu transferu po stronie źródłowej, pozostawiając tokeny niedostarczone do momentu spełnienia warunku polityki. Oba są wyborami konfiguracyjnymi, a nie ustawieniami domyślnymi.
Co mogą sprawdzić twórcy i posiadacze
Praktyczne pytanie dla każdego, kto przenosi token przez CCIP 2.0, brzmi: jakich weryfikatorów wymaga dana ścieżka i kto nimi zarządza. Wymagany CCV prowadzony przez emitenta stawia tego emitenta na drodze każdego transferu dla tej puli. Zewnętrzny CCV dodaje kolejnego operatora z własną historią dostępności. Domyślny 16-operatorowy Committee Verifier jest punktem odniesienia, ale dodatkowe CCV zmieniają zestaw zależności.
Chainlink nie wskazał produkcyjnego zasobu ani ścieżki, która opiera się na wymaganym CCV prowadzonym przez emitenta. Dopóki taki się nie pojawi, scenariusz zablokowania jest udokumentowaną właściwością projektu, a nie rzeczywistym incydentem. Twórcy oceniający aktualizację będą chcieli wiedzieć, co się stanie, gdy wymagany weryfikator będzie powolny lub milczący na ich konkretnej ścieżce — i czy stojący za nim emitent opublikował rozwiązanie dla tokenów już zablokowanych w łańcuchu źródłowym.
