DVN-y LayerZero weryfikują wiadomości międzyłańcuchowe; Executory automatyzują ich dostarczenie w łańcuchu docelowym. Wszystkie wymagane DVN-y muszą poświadczyć wiadomość, podczas gdy opcjonalne DVN-y muszą spełnić osobny próg. Executor nie może zastąpić brakującego wymaganego poświadczenia, dlatego awarie weryfikacji i dostarczenia wymagają innych działań naprawczych.
Ten ostatni punkt często ginie za listą logo dostawców. Bezpieczeństwo aktywa zależy od tego, których dostawców kontrakt rzeczywiście wymaga na danej ścieżce i w chwili transferu.
Co potwierdza DVN
Decentralized Verifier Network sprawdza wiadomość z łańcucha źródłowego i przesyła poświadczenie powiązane z jej danymi. Biblioteka wiadomości odbierająca wiadomość ocenia wymagane poświadczenia, zanim wiadomość będzie kwalifikować się do dostarczenia. Każdy DVN może korzystać z własnej metody weryfikacji. Warstwa bezpieczeństwa DVN.
Słowo „sieć” w nazwie nie powinno zastępować analizy operatora. Nadal trzeba poznać jego infrastrukturę, klucze i tryby awarii. Dwóch dostawców może mieć różne nazwy, a mimo to zależeć od tego samego źródła danych lub środowiska operacyjnego.
Aplikacja wybiera kombinację. Jeden wymagany dostawca wiąże się z innym założeniem zaufania niż kilku niezależnych dostawców wymaganych łącznie. Wybór zmienia to, co musiałby przejąć atakujący i co mogłaby przerwać awaria.
Awaria i przejęcie wpływają na ten wybór w różny sposób. Niedostępny weryfikator może zatrzymać prawidłową wiadomość. Przejęty weryfikator może poświadczyć fałszywą. Zasady należy ocenić pod kątem obu sytuacji.
Weryfikatorzy decydują o akceptacji. Executory dostarczają.
Ten przykład oddziela politykę bezpieczeństwa od transakcji w łańcuchu docelowym.
Przykładowa polityka DVN
Wymagany A + wymagany B + co najmniej jedno opcjonalne poświadczenie
Jego poświadczenie jest obowiązkowe.
Dodatkowe opcjonalne poświadczenia nie mogą go zastąpić.
Każdy z nich może spełnić przedstawiony opcjonalny próg.
Przykładowa polityka; nie jest zalecaną konfiguracją produkcyjną ani stwierdzeniem o niezależności operatorów.
Wymagany znaczy wymagany
Wymagany DVN musi poświadczyć wiadomość. Dodanie opcjonalnych DVN-ów nie daje aplikacji automatycznie możliwości pominięcia brakującego wymaganego DVN-u. Opcjonalne poświadczenia spełniają własny skonfigurowany próg.
Na przykład polityka może wymagać A i B oraz jednego dostawcy z opcjonalnego zestawu zawierającego C i D. Jeśli B jest niedostępny, poświadczenia C i D łącznie nadal nie spełniają polityki. Jeśli D jest niedostępny, C może spełnić część opcjonalną, ale A i B wciąż są konieczne. To hipotetyczna konfiguracja ilustrująca zasadę. Model weryfikacji LayerZero.
To rozróżnienie wiąże się z kosztem operacyjnym. Większa liczba niezależnych wymaganych świadków może wzmocnić regułę akceptacji, a jednocześnie zwiększyć liczbę zależności koniecznych do skutecznego dostarczenia. Zespół musi uwzględnić dostępność każdego obowiązkowego komponentu.
Właściwe pytanie brzmi: co aktywo musi chronić? Fałszywa emisja powszechnie używanego tokena zabezpieczającego może wpłynąć na inne aplikacje pożyczkowe lub handlowe. Takie ekspozycje następcze mogą uzasadniać surowsze wymagania niż w przypadku wiadomości aplikacji o niskiej wartości.
Różnorodność musi przetrwać rzeczywistą awarię
Różne nazwy dostawców to początek. Mocniejsze sprawdzenie ustala, czy dostawcy współdzielą źródła danych, systemy chmurowe, infrastrukturę podpisywania lub potoki wdrożeniowe. Wspólna awaria może zniweczyć sens korzystania z kilku świadków.
Wytyczne produkcyjne LayerZero omawiają różnorodność operatorów i infrastruktury obok metod weryfikacji. Ostrzegają też przed traktowaniem przykładowych ustawień jako produkcyjnej polityki bezpieczeństwa. Konfiguracja produkcyjna DVN.
Rozważ dostawców, którzy wszyscy odczytują te same błędne dane z łańcucha źródłowego. Ich podpisy mogą być niezależne, choć bazują na błędnej obserwacji. Mocniejszy projekt ogranicza taką współdzieloną zależność zamiast po prostu dodawać kolejny podpis.
Użytkownikowi może być trudno samodzielnie ustalić te informacje. Dlatego cenne są jawne ujawnienia ze strony emitenta. Projekt, który podaje wymaganych dostawców, wyjaśnia politykę i publikuje bieżącą konfigurację, daje więcej podstaw do oceny niż ogólne stwierdzenie „zabezpieczone przez LayerZero”.
Executory obsługują transakcję w łańcuchu docelowym
Po weryfikacji ktoś musi przesłać i sfinansować transakcję w łańcuchu docelowym. Executor automatyzuje tę pracę zgodnie z opcjami wykonania wiadomości. Zweryfikowane wiadomości można też wykonać za pomocą bezpozwoleniowych wywołań endpointu. Dokumentacja Executorów.
Awaria dostarczenia może więc opóźnić prawidłową wiadomość, nie dając usłudze dostarczającej uprawnień do wymyślenia prawidłowej wiadomości. Kontrole weryfikacyjne pozostają osobną bramką. To rozróżnienie przydaje się podczas analizy zablokowanego transferu.
Nie oznacza to, że dostarczenie jest nieistotne. Aplikacja może polegać na prawidłowej obsłudze gas, dołączonej wartości lub późniejszych wywołań. Zweryfikowana wiadomość nadal wymaga wystarczających zasobów i zgodnej logiki po stronie sieci docelowej, by zrealizować zamierzone działanie.
Procedura odzyskiwania powinna instruować operatorów, jak rozpoznać etap, na którym wystąpił błąd, i wykonać prawidłową oczekującą wiadomość. Powinna też odróżniać błąd wykonania od niespełnionej polityki weryfikacji. Opłacenie większej ilości gas w sieci docelowej nie zastąpi wymaganego poświadczenia, które nie dotarło.
Potwierdzenia to kompromis między szybkością a ryzykiem
Weryfikacja wymaga reguły określającej, kiedy zdarzenie z łańcucha źródłowego jest wystarczająco potwierdzone, by mu zaufać. Oczekiwanie na dodatkowe potwierdzenia może spowolnić działanie, ograniczając jednocześnie ryzyko reorganizacji łańcucha.
Działanie w sieci docelowej oparte na zdarzeniu źródłowym, które później znika, powoduje problem księgowy. Przy transferze tokena sieć docelowa mogła zaksięgować wartość, mimo że odpowiadający jej debet źródłowy przestał istnieć w kanonicznej historii. Założenia dotyczące finalności należą więc do opisu bezpieczeństwa aktywa.
Właściwe ustawienie zależy od sieci i ścieżki. Liczba potwierdzeń skopiowana z przykładu deweloperskiego nie stanowi dowodu bezpiecznej polityki produkcyjnej. Wybór powinien uwzględniać wytyczne produkcyjne i własny model finalności danego łańcucha. Wytyczne produkcyjne LayerZero.
W przypadku produktu finansowego pytanie brzmi: jakie opóźnienie użytkownicy mogą zaakceptować w stosunku do potencjalnej straty? Interfejs powinien odpowiednio określać oczekiwania. Nazywanie wolniejszego transferu „zepsutym” może skłaniać zespół do osłabienia ustawienia, które ma uzasadniony cel.
Nad polityką jest jeszcze administracja
Właściciel lub delegowany podmiot uprawniony może wpływać na kontrahentów aplikacji i jej konfigurację. Nawet starannie dobrana polityka weryfikacji zależy od bezpieczeństwa i ładu konta, które może ją zmienić. Dokumentacja techniczna OApp.
Ustal, kto sprawuje te uprawnienia i w jaki sposób widoczne stają się zmiany. Polityka multisig pomaga tylko w takim stopniu, w jakim jej sygnatariusze i procedury operacyjne zapewniają niezależną kontrolę. Opóźnienie pomaga tylko wtedy, gdy ktoś monitoruje oczekującą zmianę i może zareagować.
Limity transferów i awaryjne pauzy mogą ograniczyć skutki pewnych incydentów. Dają też operatorom uprawnienia, które użytkownicy powinni rozumieć. Pauza może chronić podaż, uniemożliwiając jednocześnie posiadaczowi wykonanie planowanego transferu lub wyjścia.
W przypadku aktywów RWA te uprawnienia wchodzą w interakcję ze zobowiązaniami emitenta i ograniczeniami dotyczącymi inwestorów. Weryfikacja międzyłańcuchowa sprawdza wiadomość; nie rozstrzyga prawnych praw związanych z tokenem. Wprowadzenie do RWA omawia to odrębne roszczenie.
Sprawdź używaną ścieżkę
Zapisz kontrakty źródłowy i docelowy, ich relację jako peerów oraz obowiązujące wymagania wobec weryfikatorów. Sprawdź politykę potwierdzeń, dostawcę dostarczenia i wszelkie limity transferów. Następnie ustal, kto może zmienić te ustawienia.
Pozostawienie ustawień domyślnych również jest wyborem konfiguracji. Niektóre ścieżki zawierają zastępczy wpis Dead DVN i nie mogą weryfikować wiadomości, dopóki aplikacja nie wybierze działających dostawców. Aktualna dokumentacja zaleca jawne ustawienia produkcyjne i wymagany weryfikator niezależny od LayerZero Labs. Sprawdź obowiązującą konfigurację zamiast zakładać, że domyślne ustawienia są gotowe do obsługi Twojego aktywa. Wytyczne dotyczące konfiguracji domyślnej.
Zrób to dla rzeczywistego kierunku transferu. Bezpiecznie wyglądająca konfiguracja jednej ścieżki nie dowodzi, że każda inna ma taką samą politykę. Deklaracja obsługi całej sieci nie dowodzi również, że każdy dostawca jest dostępny dla Twojego aktywa.
Jeśli interesuje Cię księgowanie tokenów związane z tymi kontrolami, przeczytaj wyjaśnienie podaży OFT. Jeśli porównujesz dostawców szerszej infrastruktury, artykuł LayerZero a Chainlink CCIP stosuje to samo podejście zależne od konkretnej ścieżki.