Wiadomości międzyłańcuchowe: porównaj weryfikację, dostawę i wykonanie
Aplikacja wielołańcuchowa może prezentować jedno działanie, opierając się na kilku różnych systemach. Wiadomość musi zostać rozpoznana w łańcuchu źródłowym, zweryfikowana w ramach ustalonego modelu bezpieczeństwa, dostarczona i zaakceptowana przez logikę miejsca docelowego. Nazywanie całego procesu „przeniesieniem pomostowym” może ukryć się tam, gdzie zmieniają się jego założenia.
Praktyczne porównanie nie dotyczy tego, który system ma najkrótszy reklamowany czas transferu. To, jakie dowody akceptuje miejsce docelowe, kto może zmienić tę zasadę i co się dzieje, gdy dany etap jest opóźniony lub kwestionowany.
Oddziel etapy jednej instrukcji
Rozważmy hipotetyczną instrukcję uznania depozytu w łańcuchu A i zwolnienia salda aplikacji w łańcuchu B. Uwzględniona transakcja źródłowa sama w sobie nie dowodzi, że akcja docelowa została zakończona.
Śledź cztery stany: zdarzenie źródłowe i jego ostateczność, wynik weryfikacji, dostarczenie wiadomości i wykonanie docelowe. Element dostawy może przesyłać informacje bez decydowania, czy są one ważne. I odwrotnie, zweryfikowana wiadomość może nadal nie zostać wykonana, jeśli kontrakt docelowy odrzuci jej dane wejściowe lub zabraknie wymaganych zasobów.
Ten przykład opisuje model badawczy, a nie architekturę każdego protokołu czy aktualnie oferowaną funkcję OrangeX.
Zapytaj, co udowodni weryfikator
Dokumentacja mostu Ethereum opisuje mosty przenoszące tokeny, wiadomości i dane oraz odróżnia projekty zweryfikowane zewnętrznie od podejść opierających się na połączonych łańcuchach. Przeczytaj konkretną implementację, zamiast traktować którąkolwiek etykietę jako pełną gwarancję bezpieczeństwa.
W przypadku zestawu weryfikatorów zewnętrznych zbadaj członkostwo, zasady progowe, niezależność i kluczowy kompromis. W przypadku podejścia opartego na dowodach należy określić, co zostało udowodnione, jakie założenia konsensusowe pozostały i w jaki sposób można zaktualizować oprogramowanie weryfikatora. Dowody kryptograficzne nie eliminują wszystkich ryzyk kontraktowych, operacyjnych lub związanych z zarządzaniem.
Traktuj opóźnienie i ostateczność osobno
Aplikacja może wyświetlać tymczasowy postęp, zanim zostaną spełnione odpowiednie warunki finalności lub wyzwania. Zapytaj, czy reklamowany czas dotyczy obserwacji, dostawy, płynności użytkownika lub ostatecznego rozliczenia. Te kamienie milowe mogą się różnić.
Nie porównuj dwóch wartości opóźnienia, jeśli zdarzenie początkowe, zdarzenie końcowe i warunki bezpieczeństwa nie są zgodne. Szybsze potwierdzenie nie jest automatycznie silniejszym ostatecznością. Wstrzymana trasa może być również celową reakcją na niepewność, a nie dowodem na zniknięcie transakcji źródłowej.
Sprawdź ponowne próby i organ docelowy
Nieudana akcja w miejscu docelowym rodzi drugi zestaw pytań: czy można ją ponowić, kto może ją ponowić, jakie obowiązują opłaty i co zapobiega dwukrotnemu wykonaniu tej samej instrukcji? Zamiast zakładać, że drugie przesłanie jest bezpieczne, przeczytaj udokumentowane identyfikatory protokołu i zabezpieczenia przed powtórzeniem.
Sprawdź klucze aktualizacji, przerwy awaryjne, konfigurację trasy i uprawnienia na poziomie aplikacji. Bezpieczna warstwa przesyłania wiadomości nie może wydawać dźwięku niebezpiecznej aplikacji docelowej. Podobnie renomowany interfejs nie dowodzi, że wszystkie obsługiwane trasy korzystają z jednego modelu zaufania.
Prowadź rejestr badań dotyczący konkretnej trasy
Zapisz dokładne łańcuchy, umowy, reprezentację aktywów, model bezpieczeństwa, założenia dotyczące ostateczności i procedurę odzyskiwania dla ocenianej trasy. Korzystaj z aktualnej oficjalnej dokumentacji i odróżniaj wdrożone kontrole od przyszłych planów.
Wpłata giełdowa jest odrębnym przepływem pracy od dowolnego komunikatu aplikacji między łańcuchami. Przed wysłaniem środków do OrangeX.com postępuj zgodnie z instrukcjami dotyczącymi sieci i adresu wyświetlanymi w interfejsie depozytu. Nie zakładaj, że pomyślna operacja mostu sprawia, że nieobsługiwana sieć docelowa jest akceptowalna.
