Krótka historia cross-chain: wyjaśnienie dziewięciu różnych rozwiązań cross-chain

Rozwiązania międzyłańcuchowe były najchętniej omawianym tematem w zeszłym roku. Wraz z rozwojem infrastruktury łańcuchów publicznych wzrosło ogromne zainteresowanie sposobem, w jaki różne sieci rozmawiają i komunikują się. Zaproponowano i wdrożono rozwiązania, ale żadne z nich nie rozwiązuje podstawowych problemów bez drastycznych kompromisów. Teraz analizujemy różne podejścia międzyłańcuchowe i ujawniamy, dlaczego i w jaki sposób będą one kształtować przyszłość infrastruktury międzyłańcuchowej.

Najpierw omówmy, czym jest technologia międzyłańcuchowa i dlaczego jest potrzebna. Powód użycia: łańcuchy są heterogeniczne i wymagają od programistów znacznej ilości czasu na śledzenie różnic i wyzwań związanych z przenoszeniem zasobów. Mosty są mniej bezpieczne i nie można im ufać w 100%, ponieważ zazwyczaj są własnością zespołów projektowych blockchain i są wysoce scentralizowane (brak koordynacji ze strony każdego zespołu powoduje bałagan). Celem łańcucha bloków warstwy 1 jest standaryzacja, ale segmentacja łańcuchów warstwy 1 prowadzi do potrzeby warstwy infrastruktury międzyłańcuchowej, która znajduje się nawet pod warstwami 1.

Należy przedstawić i porównać historię mechanizmów międzyłańcuchowych, aby zrozumieć rozwiązania międzyłańcuchowe oraz porównać ich różnice i cechy.

Transfer ręczny

 
Pierwszym rozwiązaniem międzyłańcuchowym jest ręczny transfer aktywów. Proces rozpoczyna się od przeniesienia przez użytkownika zasobów do określonego portfela w łańcuchu A, a scentralizowana jednostka monitoruje portfel pod kątem transferów i rejestruje je w programie Excel. Następnie po określonym czasie (zwykle w celach monitorowania) jednostka po weryfikacji zapisuje aktywa do łańcucha B. Zaletą tego podejścia jest łatwość wdrożenia, ale jest ono podatne na błędy ludzkie i ma bardzo niską gwarancję bezpieczeństwa. W tym podejściu również nie ma decentralizacji.

Półautomatyczny transfer

Następna iteracja poprawia się, ponieważ użytkownik przesyła zasoby do określonego portfela i/lub inteligentnej umowy w łańcuchu A. Następnie scentralizowany program monitoruje adres do przelewów. Taki program po weryfikacji automatycznie wysyła aktywa do łańcucha B. Zaletą jest nadal łatwość wdrożenia bez nadmiernej złożoności i kodowania, a zapisy można przechowywać w łańcuchu zamiast lokalnie. Wadą jest to, że scentralizowany program może zawierać błędy lub działać nieprawidłowo. Na centralnym rachunku kredytowym może zabraknąć środków. Gwarancja bezpieczeństwa jest również niska i nie ma decentralizacji.

Scentralizowana wymiana

Kiedy proste rozwiązania międzyłańcuchowe nie są skalowalne, scentralizowane giełdy rozwijają się w oparciu o potrzeby międzyłańcuchowe. Działają w ten sposób, że użytkownicy przenoszą aktywa na ich scentralizowaną giełdę, a następnie, korzystając z „wewnętrznej” wymiany giełdy, zamieniają „aktywa X” w łańcuchu A w „aktywa Y” w łańcuchu B poprzez księgowość rekordową. Zaleta jest oczywista – jest to rozwiązanie najłatwiejsze w użyciu – nie wymaga kodowania, a centrale poziomu 1 zapewniają wysoką niezawodność. Jednak problem ujawnia przeciwną wadę – scentralizowaną kontrolę nad dostępnością wpłat/wypłat. Scentralizowana wymiana zapewnia wysokie bezpieczeństwo, a wadą jest najmniejsza decentralizacja.

Scentralizowany most

Następny postęp polega na stworzeniu oddzielnej infrastruktury do przesyłania aktywów między łańcuchami – mostu. Scentralizowany most działa w ten sposób, że użytkownik przesyła zasoby, a następnie za pomocą funkcji przesyłania mostu inicjuje przesyłanie zasobów X w łańcuchu A do aktywów Y w łańcuchu B. Za proces odpowiada scentralizowany (lub zestaw) przekaźników:

Zablokuj zasoby X w łańcuchu A
zweryfikować
Wybij aktywa Y w łańcuchu B
Zaletą tego mostu jest w pełni automatyczny proces bez konieczności ręcznego przerywania. Wadą jest nadal scentralizowana kontrola dostępności wpłat/wypłat. Ponadto most może zostać wyłączony lub zhakowany, przez co od czasu do czasu przestaje działać. Zatem bezpieczeństwo jest średnie i nadal nie ma decentralizacji.

Zdecentralizowany most z MPC

Następną iteracją jest decentralizacja modelu weryfikacji zamiast scentralizowanego mostu. Most MPC (Multi-Party Computation) rozpoczyna się od przeniesienia przez użytkowników zasobów do niego. Korzystając z funkcji transferu mostu, inicjuje przenoszenie aktywów X w łańcuchu A do aktywów Y w łańcuchu B. Za proces odpowiedzialny jest zazwyczaj zdecentralizowany zestaw przekaźników:

Zablokuj zasoby X w łańcuchu A za pomocą MPC
Sprawdź za pomocą MPC
Wybij aktywa Y w łańcuchu B za pomocą MPC
Zaletą MPC jest w pełni automatyczny proces bez konieczności ręcznego przerywania, a węzły przekaźnikowe nie muszą być scentralizowane. Wadą jest wysoki koszt obliczeniowy i komunikacyjny MPC. Ponadto węzły mogą zostać naruszone lub zmowane. Bezpieczeństwo jest średnie, a decentralizacja również jest średnia.

Most Atomic Swap Bridge z HTLC

Inna klasa mostów powstaje w oparciu o technologię Atom Swap (Lightning Network). Działa to w następujący sposób: użytkownik przenosi zasoby do atomowego mostu wymiany, a następnie korzystając z funkcji przesyłania mostu, inicjuje przesyłanie aktywów X w łańcuchu A do aktywów Y w łańcuchu B:

Utwórz nowy kontrakt czasowy HTLC – Hash Lock
Zdeponuj aktywa X w kontrakcie w łańcuchu A
Wygeneruj klucz skrótu + zaszyfruj sekret do ostatecznej wypłaty w czasie T w łańcuchu B
Przedstaw zaszyfrowany sekret kontraktu w łańcuchu B w celu wycofania aktywów Y
LUB czas T minął i odzyskaj aktywa X z kontraktu w łańcuchu A z zaszyfrowanym sekretem
Istotną zaletą jest brak scentralizowanego węzła/procesu sterującego transferem mostowym. Wada jest stosunkowo powszechna – wysoki koszt wdrożenia HTLC i prowadzenia wywołań HTLC. Ze względu na brak zaufania utrzymanie wysokiego poziomu bezpieczeństwa i ścieżki audytu jest wyzwaniem. Bezpieczeństwo tego podejścia jest wysokie, a decentralizacja również jest wysoka, biorąc pod uwagę powyższe wady.

Współpraca między łańcuchami z Light Client + Oracle

W miarę zbliżania się drogich mostów pojawia się więcej wdrożeń mających na celu zmniejszenie tych kosztów. Technologia klienta lekkiego stała się najnowszą normą upraszczającą weryfikacje międzyłańcuchowe. Proces jest następujący:

Najpierw użytkownik przenosi zasoby X do umowy protokołu interoperacyjności międzyłańcuchowej w łańcuchu A
Komunikat transferu jest ustalany na podstawie kontraktu i jest odbierany przez zdecentralizowane węzły przekazujące
Węzły wysyłają dowody do kontraktu protokołu w łańcuchu B
Aktualizacje nagłówków bloków (klient lekki) są obsługiwane przez sieć Oracle w celu zapewnienia dostarczenia i ważności
Użytkownik wycofuje aktywa Y z umowy protokołu w łańcuchu B po zatwierdzeniu
Zaletą tego podejścia jest to, że od momentu przeniesienia do zakończenia nie jest potrzebny żaden token pośredni ani łańcuch. Natychmiastowe potwierdzenie jest możliwe po aktualizacji nagłówków bloków. Wady to 1) ryzyko zmowy ze strony Oracle, 2) brak zaufania, utrzymywanie wysokiego poziomu bezpieczeństwa i trudna ścieżka audytu. Bezpieczeństwo tego podejścia jest średnie, podczas gdy decentralizacja jest wysoka.

Współpraca między łańcuchami z łańcuchem przekaźnikowym

Wyciągając wnioski z podejścia Oracle, dostępne jest również rozwiązanie oparte wyłącznie na łańcuchu przekaźników. Proces jest nieco inny:

Użytkownik przenosi zasoby X do umowy protokołu interoperacyjności międzyłańcuchowej w łańcuchu A
Komunikat transferu jest ustalany na podstawie kontraktu i jest odbierany przez zdecentralizowane węzły przekazujące
Węzły wysyłają dowody do kontraktu łańcucha przekaźników
Podstawowe walidatory łańcucha przekaźników obsługują aktualizacje blokowe, aby zapewnić dostawę i ważność
Po zatwierdzeniu węzły przekazujące przekazują komunikat przesyłania do kontraktu protokołu w łańcuchu B
Użytkownik wycofuje aktywa Y z umowy protokołu w łańcuchu B
Przewagą tego podejścia nad prostym rozwiązaniem Oracle są niższe opłaty od łańcuchów przekaźnikowych, które pochłaniają większość kosztów. Natychmiastowe potwierdzenie jest możliwe po aktualizacji bloków, co ma kluczowe znaczenie w rozwiązaniu problemu dłuższych czasów opóźnień. Problem polega na tym, że sam protokół może nie obsługiwać ekosystemu obejmującego wszystkie łańcuchy. Bezpieczeństwo jest wysokie (w obrębie ekosystemu), a decentralizacja również jest wysoka.

Warstwa infrastruktury międzyłańcuchowej z klientem Light + łańcuchem przekaźnikowym

Rozwiązanie nowej generacji koncentruje się na warstwie infrastruktury międzyłańcuchowej, rozwiązując wszystkie powyższe podstawowe problemy. Łączy technologię klienta lekkiego z łańcuchem przekaźnikowym, aby uwzględnić wszystkie łańcuchy:

Użytkownik przenosi aktywa X do umowy o interoperacyjność warstwy infrastruktury międzyłańcuchowej w łańcuchu A
Komunikat transferu jest ustalany na podstawie kontraktu i jest odbierany przez zdecentralizowane węzły przekazujące
Węzły przesyłają dowody umowy dotyczącej interoperacyjności łańcucha przekaźników
Aktualizacje nagłówków bloków (klient lekki) są obsługiwane przez zdecentralizowane węzły opiekunów, aby zapewnić dostawę i ważność
Po zatwierdzeniu węzły przekazujące przekazują komunikat do kontraktu interoperacyjności w łańcuchu B
Użytkownik wycofuje aktywa Y z umowy interoperacyjnej w łańcuchu B
Rozwiązanie to zapewnia interoperacyjność przy bardzo niskich opłatach dzięki zastosowaniu łańcucha przekaźników. Daje także natychmiastowe potwierdzenie po aktualizacji nagłówków bloków. Największym wyzwaniem jest duża złożoność optymalizacji lekkich klientów w łańcuchu przekaźników. Dzięki przeprowadzeniu wystarczającej liczby badań i inżynierii optymalizacje te powinny zapewnić korzyści, których inne rozwiązania nie są w stanie rozwiązać. Bezpieczeństwo jest bardzo wysokie, a decentralizacja wysoka.

O protokole MAP

Spośród rozwiązań międzyłańcuchowych nie widzieliśmy jeszcze takiego, który rozwiązałby wszystkie powyższe problemy. Do czasu wdrożenia protokołu MAP. Po 3 latach kompleksowych badań i rozwoju, protokół MAP w końcu osiągnął warstwę Omnichain z technologią lekkiego klienta + łańcucha przekaźników, bez kompromisów. MAP wdrożył zasady Omnichain o następujących właściwościach:

Deweloper gotowy
Pokrycie całego łańcucha
Minimalny koszt
Ostateczność bezpieczeństwa
natychmiastowe potwierdzenie

Protokół MAP to warstwa infrastruktury obsługująca budowanie mostów, DEX, protokoły interoperacyjności i nie tylko. Obsługuje weryfikację przez klientów lekkich bezpośrednio w łańcuchu przekaźników MAP – w celu zmniejszenia kosztów. Zapewnia także zachęty wbudowane w każdy komponent, dzięki którym programiści dapp mogą zarabiać lub prezentować je użytkownikom końcowym. MAP obsługuje łańcuchy EVM i inne niż EVM – warstwa protokołu jest izomorficzna ze wszystkimi łańcuchami.

W przyszłości MAP to infrastruktura wszystkich sieci, która będzie nową warstwą bazową. Programiści nie są już ograniczeni łańcuchem wyboru i mogą skupić się na samym produkcie dapp. Przyszłość to Omnichain, a najlepszym rozwiązaniem jest większa modularyzacja i motywacja.