Czym jest Cosmos IBC? Wprowadzenie do Inter-Blockchain Communication

Czym jest Cosmos IBC?

Cosmos IBC to protokół, dzięki któremu oddzielne blockchainy mogą bezpiecznie wymieniać między sobą wiadomości. IBC oznacza Inter-Blockchain Communication i powstał w ekosystemie Cosmos. Dlatego często spotkasz nazwę Cosmos IBC, ale projekt nie jest przeznaczony wyłącznie dla blockchainów opartych na Cosmos SDK.

Mówiąc prościej, IBC to wspólny zestaw zasad dla blockchainów, które chcą się ze sobą komunikować. Protokół określa, jak wysyłana jest wiadomość, jak odbierający blockchain sprawdza jej autentyczność i w jakiej kolejności wiadomości są przetwarzane. IBC można więc traktować jako rodzaj standardu komunikacji dla blockchainów, podobnie jak EVM w Ethereum zapewnia standardowe środowisko do uruchamiania smart kontraktów.

IBC nie jest więc blockchainem, centralnym hubem ani wyłącznie mostem dla tokenów. Transfer tokenów to jedno z najczęstszych zastosowań, ale IBC może przekazywać także inne rodzaje wiadomości. Przykładem są instrukcje dotyczące zarządzania kontem na innym blockchainie.

Ważne jest to, że treść wiadomości IBC określa aplikacja, która ją wysyła i odbiera. IBC odpowiada przede wszystkim za transport i kontrolę wokół niego. Można to porównać do niezawodnego systemu dostaw, podczas gdy aplikacja decyduje, co znajduje się w paczce i co należy z nią zrobić.

Pierwotna konstrukcja nosi nazwę IBC v1. W tym modelu dwa blockchainy najpierw tworzą connection, a następnie channels, zanim aplikacje będą mogły wymieniać wiadomości. IBC v2 to najnowsza wersja projektu, która ma uprościć ten proces dzięki bezpośredniej komunikacji między clientami. Standardy dla v2 nadal mają status Draft.

Najważniejsze informacje

• IBC oznacza Inter-Blockchain Communication i umożliwia oddzielnym blockchainom wymianę wiadomości.
• Cosmos IBC nie jest blockchainem ani centralnym hubem, lecz protokołem interoperacyjności.
• IBC można wykorzystać do znacznie więcej niż tylko transfery tokenów.
• IBC v1 działa z użyciem connections i channels między dwoma blockchainami.
• IBC v2 to najnowsza iteracja, ale specyfikacje nadal mają status Draft.

Jak działa Cosmos IBC?

Cosmos IBC działa dzięki temu, że oba blockchainy sprawdzają się nawzajem za pomocą własnego on-chain light clienta. Light client to niewielki element na blockchainie, który może śledzić informacje z innego blockchaina i weryfikować kryptograficzne dowody.

Brzmi to technicznie, ale sama idea jest dość logiczna. Blockchain A nie musi ślepo wierzyć temu, co mówi blockchain B albo relayer. Blockchain A przechowuje informacje, dzięki którym może sprawdzić, czy wiadomość rzeczywiście znajduje się w stanie blockchaina B.

W IBC v1 dwa blockchainy najpierw ustanawiają connection. To kontrolowane połączenie, dzięki któremu oba blockchainy ustalają, z jaką siecią się komunikują.

Ustanowienie takiego connection przebiega w czterech krokach. ConnectionOpenInit rozpoczyna połączenie, ConnectionOpenTry pozwala drugiemu blockchainowi odpowiedzieć, ConnectionOpenAck potwierdza zgodność danych, a ConnectionOpenConfirm kończy proces. W ten sposób oba blockchainy krok po kroku sprawdzają, czy są połączone z właściwą stroną.

Na jednym connection może działać wiele channels. Channel to konkretne kanały komunikacji między dwiema aplikacjami na różnych blockchainach. Aplikacje przypisują się przy tym do unikalnego portu. Port można traktować jako stały punkt kontaktowy aplikacji, a channel jako uzgodnioną drogę do aplikacji po drugiej stronie.

Jak więc wiadomość przechodzi z A do B?

1. Aplikacja tworzy packet Aplikacja wysyłająca tworzy packet. To po prostu pakiet danych, na przykład instrukcja przesłania tokenów.

2. Blockchain źródłowy zapisuje commitment Blockchain, z którego packet jest wysyłany, zapisuje packet commitment w swoim stanie. To kryptograficzny dowód, że packet został tam zarejestrowany.

3. Relayer przenosi packet i dowód Relayer odczytuje packet oraz powiązany z nim dowód i przekazuje oba elementy do blockchaina odbierającego.

4. Blockchain odbierający wszystko sprawdza Light client weryfikuje kryptograficzny dowód. Jeśli dowód się zgadza, aplikacja odbierająca może przetworzyć packet.

5. Zwykle wraca acknowledgement Po przetworzeniu aplikacja odbierająca często zapisuje acknowledgement. To wiadomość potwierdzająca odbiór lub wynik. Relayer może następnie odesłać ten dowód do blockchaina, na którym packet został wysłany.

Packety mają też limit czasu. Jeśli packet nie dotrze na czas, blockchain źródłowy może rozpocząć obsługę timeoutu, ale tylko z dowodem ze stanu blockchaina docelowego. Sam brak odpowiedzi nie wystarcza więc, aby po prostu cofnąć transfer.

Przykład: Załóżmy, że przez IBC wysyłasz tokeny z blockchaina A do blockchaina B. Blockchain A zapisuje, że wiadomość została wysłana. Następnie relayer przekazuje wiadomość wraz z dowodem do blockchaina B. Gdy blockchain B sprawdzi, że dowód jest poprawny, transfer zostaje przetworzony i potwierdzenie może wrócić do blockchaina A.

IBC v2 ma uprościć tę konstrukcję. Zamiast wielu technicznych kroków potrzebnych do połączenia dwóch blockchainów, v2 pozwala wysyłać wiadomości bezpośrednio między obiema sieciami. To podejście nie jest jeszcze wszędzie standardem, ponieważ najważniejsze standardy dla IBC v2 nadal są w opracowaniu.

Jaką rolę pełnią relayers w Cosmos IBC?

Relayers są dostawcami wiadomości IBC między blockchainami. Monitorują blockchainy i przekazują wiadomości do drugiego blockchaina.

Blockchain A i blockchain B nie wysyłają bowiem wiadomości IBC bezpośrednio do siebie. Relayer widzi na przykład, że na blockchainie A pojawiła się nowa wiadomość, i przekazuje ją wraz z dowodem jej autentyczności do blockchaina B.

Relayer nie decyduje sam, czy wiadomość jest ważna. Sprawdza to sam blockchain B. Dzięki temu blockchain B nie musi po prostu ufać relayerowi.

Relayers nie tylko przekazują nowe wiadomości. Mogą też odesłać potwierdzenie do pierwotnego blockchaina. Jeśli wiadomość nie zostanie przetworzona na czas, mogą również przekazać informację o upływie limitu czasu.

W zasadzie każdy może działać jako relayer. IBC nie ma centralnej strony, która musi obowiązkowo przekazywać wszystkie wiadomości. Relayer może też zdecydować, że będzie obsługiwać tylko określone rodzaje wiadomości lub wybrane połączenia.

Musi jednak istnieć co najmniej jeden aktywny relayer, aby wiadomości były nadal przekazywane. Relayer zwykle nie może sfałszować poprawnej wiadomości, ale jeśli żaden relayer nie działa, wiadomość może utknąć.

IBC nie ma stałego systemu, w którym relayers zawsze otrzymują wynagrodzenie. Sposób ich rozliczania może więc różnić się w zależności od blockchaina lub aplikacji.

Które blockchainy mogą korzystać z Cosmos IBC?

W zasadzie każdy blockchain może korzystać z IBC, o ile obsługuje niezbędne elementy do wysyłania i weryfikowania wiadomości. Blockchainy nie muszą przy tym używać tej samej technologii ani tego samego mechanizmu konsensusu.

Aby móc sprawdzać inny blockchain, IBC wykorzystuje tak zwany light client. To, jaki light client jest potrzebny, zależy od blockchaina, z którym nawiązywane jest połączenie. Blockchainy Cosmos często korzystają na przykład z light clienta dla CometBFT, ale istnieją też inne typy dla innych zastosowań.

To, że blockchain obsługuje IBC, nie oznacza automatycznie, że może od razu komunikować się z każdym innym blockchainem IBC. Oba blockchainy muszą technicznie móc się wzajemnie weryfikować, a relayer musi przekazywać wiadomości między obiema sieciami. W przypadku IBC v1 najpierw trzeba też ustanowić połączenie między blockchainami.

Obsługa IBC nie oznacza również, że każda funkcja jest automatycznie dostępna. Dwa blockchainy mogą być na przykład połączone, ale transfery tokenów, transfery NFT lub inne funkcje IBC mogą jeszcze nie być na tym połączeniu włączone.

Wersja IBC w Go jest używana przez wiele blockchainów w ekosystemie IBC. Istnieją też rozwiązania między innymi dla Solidity/EVM oraz Solany, choć techniczne działanie i bezpieczeństwo mogą się różnić w zależności od integracji.

Do czego służy Cosmos IBC?

Cosmos IBC służy do przesyłania różnych rodzajów cross-chain wiadomości, nie tylko tokenów. Aplikacje po obu stronach same decydują, jak zbudować i przetworzyć dane w packetcie.

Najbardziej znanym zastosowaniem jest ICS-20, czyli standard transferów tokenów fungible. Fungible oznacza, że każda jednostka jest wzajemnie wymienna, jak jeden token, który można zamienić na inny token tego samego rodzaju.

W takim transferze trasa i pochodzenie tokena pozostają zapisane jako denomination trace. Dzięki temu oprogramowanie może sprawdzić, skąd pochodzi reprezentacja tokena IBC i jaką drogą dotarła.

IBC można też wykorzystać do Interchain Accounts za pomocą ICS-27. Dzięki temu blockchain kontrolujący może wysyłać instrukcje transakcji do konta na blockchainie hostującym. Blockchain hostujący sprawdza instrukcje i wykonuje tylko to, co jest dozwolone.

Istnieje również ICS-721 dla transferów NFT. Jeśli NFT opuszcza blockchain źródłowy, zostaje tam umieszczony w escrow. Na blockchainie odbierającym powstaje następnie odpowiadający mu voucher. Gdy NFT wraca, dzieje się odwrotnie.

Istnieje też standard dla zapytań cross-chain, ICS-31. Dzięki niemu blockchain może pobierać informacje z innego blockchaina, a relayer przekazuje odpowiedź wraz z dowodem. Ten standard nadal ma status Draft, więc nie jest automatycznie dostępny wszędzie.

Na koniec jest jeszcze Interchain Security. Dzięki niej blockchainy Cosmos mogą udostępniać sobie nawzajem bezpieczeństwo proof-of-stake. To osobna aplikacja IBC, a nie standardowy element każdego połączenia IBC.

Jakie są zalety Cosmos IBC?

Największą zaletą Cosmos IBC jest to, że blockchainy mogą się ze sobą komunikować bez rezygnowania z własnych zasad ani mechanizmu konsensusu. Każdy blockchain pozostaje więc niezależny, ale nadal może wymieniać wiadomości z innymi blockchainami.

Kolejną mocną stroną jest weryfikacja. Blockchain odbierający sprawdza packet commitments i acknowledgements za pomocą dowodów kryptograficznych przez swój light client. Relayer dostarcza dane, ale nie musi być stroną, której ufamy w kwestii ich poprawności.

IBC jest też modułowy. Ta sama warstwa bazowa może służyć do różnych zastosowań, takich jak:

• transfery tokenów fungible;
• transfery NFT;
• transakcje cross-chain za pośrednictwem Interchain Accounts;
• inne aplikacje, które chcą wysyłać wiadomości między blockchainami.

IBC nie ma obowiązkowego centralnego huba ani wyłącznego operatora relay. Umożliwia to permissionless relaying: różne podmioty mogą uruchamiać relayers i przetwarzać packety.

Channels dają też wybór sposobu przetwarzania wiadomości. Channel może działać w trybie uporządkowanym, w którym packety muszą docierać w określonej kolejności, albo nieuporządkowanym. Dzięki acknowledgements i timeoutom aplikacje mają też stały sposób obsługi odebranego, nieudanego lub wygasłego packetu.

Jedno connection może obsługiwać wiele channels. Dzięki temu różne aplikacje między tymi samymi dwoma blockchainami nie muszą za każdym razem tworzyć nowego, pełnego connection.

Jakie są wady Cosmos IBC?

Cosmos IBC ma też wady, zwłaszcza w obszarze dostępności, złożoności technicznej i bezpieczeństwa połączonych blockchainów. IBC umożliwia komunikację cross-chain, ale dodaje też dodatkowe kroki w porównaniu ze zwykłą lokalną transakcją.

Pierwszą zależnością są relayers. Bez co najmniej jednego poprawnego i aktywnego relayera packety, acknowledgements i aktualizacje clienta mogą się opóźniać albo całkowicie utknąć. Nie oznacza to automatycznie, że ktoś może ukraść tokeny, ale transfer może nie zostać zakończony.

Bezpieczeństwo connection IBC zależy też od light clientów i bezpieczeństwa konsensusu obu blockchainów. Jeśli złośliwa grupa walidatorów przekroczy próg zaufania threshold light clienta, connection może stać się niebezpieczne.

Light client może też stać się bezużyteczny. Na przykład wtedy, gdy śledzony blockchain przestaje działać, aktualizacje zbyt długo nie nadchodzą albo client zamraża się po wykryciu misbehavior. W podstawowej logice IBC i ICS-20 aktywa w dotkniętym channelu mogą wtedy pozostać zablokowane na stałe, jeśli nie ma mechanizmu odzyskiwania.

Przetwarzanie cross-chain zajmuje też więcej czasu i często wiąże się z wyższymi opłatami transakcyjnymi. Zwykły proces może obejmować wysłanie packetu, odebranie go na drugim blockchainie, odesłanie acknowledgement i czasem procedurę timeoutu. To kilka działań na dwóch różnych blockchainach.

Techniczna konfiguracja nie jest też prosta. Light clienty, connections, channels, moduły aplikacyjne i relayers muszą ze sobą dobrze współpracować. Błąd w konfiguracji, integracji lub utrzymaniu może powodować problemy.

Timeouty są również bardziej złożone, niż mogłoby się wydawać. Jeśli dochodzi do pełnej partycji sieci, blockchain źródłowy nie może na podstawie samego braku odpowiedzi stwierdzić, że packet nigdy nie został wykonany. Blockchain docelowy musi być osiągalny, aby dostarczyć potrzebny dowód.

W prywatnym środowisku testowym zaobserwowano też między innymi opóźnienia w potwierdzeniach, wąskie gardła RPC oraz problemy z współbieżnością u relayers. Takie wyniki zależą od użytego środowiska i implementacji, ale pokazują, że relaying w praktyce może napotykać ograniczenia techniczne.

Podsumowanie

Cosmos IBC to protokół, dzięki któremu niezależne blockchainy mogą kontrolowanie wymieniać wiadomości. Chodzi więc o znacznie więcej niż tylko przesyłanie tokenów: IBC może służyć także do transferów NFT, Interchain Accounts i innych zastosowań cross-chain.

Sednem jest to, że blockchainy mogą sprawdzać się nawzajem za pomocą light clientów i dowodów kryptograficznych. Relayers przenoszą wiadomości tam i z powrotem, ale nie decydują samodzielnie o ich ważności. Jednocześnie aktywne relayers, dobra konfiguracja i bezpieczeństwo obu blockchainów pozostają kluczowe.

Dla kryptowalut IBC sprawia, że aplikacje na różnych blockchainach mogą lepiej ze sobą współpracować. To nie jest magiczne rozwiązanie bez ryzyka, ale ważny element budowy bardziej połączonego świata blockchainów.