Czym jest Cosmos SDK i jak działa przy budowie blockchainów?

Czym jest Cosmos SDK?

SDK Cosmos to oprogramowanie open source do tworzenia, dzięki któremu deweloperzy mogą zbudować własny, wyspecjalizowany pod konkretną aplikację blockchain lub cyfrowy rejestr. Nie jest więc sam w sobie blockchainem, siecią ani tokenem.

Blockchain zbudowany z użyciem Cosmos SDK może działać jako samodzielny blockchain Layer 1. Oznacza to, że łańcuch nie działa jako aplikacja na innej blockchainie, lecz sam określa zasady transakcji, stanu i innych elementów protokołu. W połączeniu z oprogramowaniem takim jak CometBFT taki blockchain może też mieć własną sieć walidatorów i własny proces konsensusu.

Dzięki Cosmos SDK projekt sam ustala zasady swojego łańcucha. Chodzi na przykład o to, kto może wykonywać określone działania, jak działają transakcje, jakie dane są przechowywane, jak wygląda governance i jaka logika aplikacyjna obowiązuje.

Można to traktować jak zestaw konstrukcyjny do budowy blockchaina. Zamiast programować wszystkie elementy od zera, deweloper wybiera gotowe komponenty i łączy je z własnym kodem. Dzięki temu łańcuch może na przykład otrzymać zasady dotyczące tokenów, zarządzania walidatorami, on-chain governance lub konkretnych uprawnień.

Aplikacja Cosmos SDK jest technicznie deterministyczną maszyną stanów. Brzmi to skomplikowanie, ale idea jest prosta: ten sam poprawny input musi na każdym węźle zawsze prowadzić dokładnie do tego samego nowego stanu. Jeśli użytkownik na przykład wysyła tokeny, wszystkie nodes muszą ostatecznie widzieć to samo saldo.

W typowej konfiguracji taka aplikacja działa jako binarka Go. Go to język programowania, w którym buduje się logikę łańcucha. Aplikacja działa razem z oprogramowaniem, które pozwala węzłom komunikować się ze sobą i tworzyć bloki.

Cosmos SDK odpowiada przede wszystkim za warstwę aplikacyjną: które transakcje są ważne i co zmieniają. CometBFT zwykle odpowiada za konsensus, peer-to-peer networking i produkcję bloków. ABCI stanowi połączenie między tymi dwiema warstwami. Za pomocą tego interfejsu oprogramowanie konsensusu może prosić aplikację o sprawdzanie i wykonywanie transakcji oraz bloków.

Najważniejsze informacje

• Cosmos SDK to oprogramowanie do tworzenia, za pomocą którego można budować między innymi samodzielne, wyspecjalizowane pod konkretną aplikację blockchainy Layer 1.
• Łańcuch może sam ustalać zasady dotyczące transakcji, governance, uprawnień i przechowywanych danych.
• SDK jest modułowe: deweloperzy łączą gotowe moduły z własną logiką.
• CometBFT zwykle odpowiada za konsensus, komunikację sieciową i produkcję bloków.
• Cosmos SDK nie jest osobnym blockchainem i nie ma własnego tokena.

Jak działa Cosmos SDK?

Cosmos SDK działa dzięki temu, że CometBFT przetwarza bloki i przez ABCI wywołuje aplikację łańcucha. SDK określa przy tym, co transakcja może zrobić, a CometBFT dba o to, by węzły uzgodniły bloki.

Centralna warstwa w aplikacji SDK nazywa się BaseApp. BaseApp tłumaczy wywołania z ABCI na praktyczne zadania: wykonuje transakcje, kieruje messages do odpowiedniego modułu i aktualizuje stan.

Użytkownik najpierw wysyła podpisaną transakcję. Taka transakcja zawiera jedną lub więcej messages. Message to konkretne polecenie, takie jak wysłanie tokenów albo delegowanie tokenów do walidatora.

Transakcja zawiera też między innymi podpis cyfrowy, opłaty i limit gas. Podpis pokazuje, które konto zatwierdziło polecenie. Opłaty to koszt przetworzenia. Limit gas wskazuje, za ile maksymalnie obliczeń użytkownik chce zapłacić.

Zanim transakcja zostanie wykonana, AnteHandler sprawdza kilka podstawowych zasad. Weryfikuje na przykład, czy podpis jest poprawny, czy sequence konta się zgadza, czy opłaty są wystarczające i czy nie został przekroczony limit gas. Sequence konta to rosnący numer, który pomaga zapobiegać ponownemu użyciu tej samej transakcji.

Następnie BaseApp kieruje każdą message do właściwego modułu. Na przykład transfer tokenów trafia do modułu, który zarządza saldami. Ten moduł sprawdza własne zasady i, jeśli wszystko się zgadza, aktualizuje stan.

Stan to wszystkie bieżące dane łańcucha, takie jak konta, salda i ustawienia. Dane te są przechowywane jako dane key-value w multistore. To zbiór oddzielnych miejsc przechowywania, zwykle po jednym na moduł.

Transakcja jest wykonywana z tymczasowym przechowywaniem stanu. Zmiany wprowadzone podczas wykonywania message są zachowywane tylko wtedy, gdy wykonanie się powiedzie. Jeśli message się nie powiedzie, zmiany są cofane. Niektóre zmiany z wcześniejszej fazy AnteHandler, takie jak pobranie opłat transakcyjnych i zwiększenie sequence konta, mogą jednak zostać zachowane.

W typowym przepływie CometBFT BaseApp przetwarza ustalony blok przez FinalizeBlock. Najpierw wykonywana jest ewentualna logika przed blokiem, potem przetwarzane są transakcje, a następnie logika na końcu bloku. Potem nowy stan jest zapisywany przez Commit i powstaje nowy AppHash: kryptograficzny odcisk palca stanu aplikacji.

Przykład: Załóżmy, że wysyłasz komuś 10 tokenów. Najpierw łańcuch sprawdza Twój podpis, sequence, opłatę i limit gas. Następnie moduł tokenów sprawdza, czy masz co najmniej 10 tokenów. Tylko jeśli wszystkie kontrole zakończą się powodzeniem, z Twojego salda znika 10 tokenów, a 10 trafia na saldo odbiorcy.

Z jakich elementów składa się Cosmos SDK?

Typowa aplikacja Cosmos SDK składa się z BaseApp, modułów oraz warstwy, w której wszystko jest składane i konfigurowane. Razem elementy te tworzą jedną maszynę stanów, którą uruchamiają operatorzy węzłów.

BaseApp jest łącznikiem między CometBFT a aplikacją. Odpowiada za połączenie ABCI, kieruje messages i queries, wykonuje transakcje i zarządza multistore.

Moduły zawierają właściwą logikę biznesową. Każdy moduł może mieć własny stan, messages, funkcje query i zasady. Łańcuch sam wybiera, które moduły chce uwzględnić. Następnie są one łączone z ewentualnymi własnymi modułami.

To łączenie odbywa się zwykle w app.go. Tam deweloper tworzy BaseApp, ustawia miejsca przechowywania, inicjalizuje komponenty i określa, jak moduły współpracują ze sobą. Binarka węzła uruchamia następnie zarówno węzeł konsensusu, jak i aplikację SDK.

Moduły zwykle korzystają z keepera do dostępu do swojego stanu. Keeper można traktować jak kontrolowaną bramę do przechowywanych danych. Nie każdy moduł może dowolnie wszystko zmieniać. Moduł otrzymuje tylko te uprawnienia i interfejsy, które aplikacja świadomie mu przekazuje.

ModuleManager śledzi, które moduły są aktywne, i odpowiada między innymi za start przy genesis, aktualizacje oraz kolejność hooków na granicach bloków. Genesis to punkt początkowy blockchaina: pierwszy stan, od którego zaczyna sieć.

Protocol Buffers również odgrywają ważną rolę. To sposób na jasne opisywanie danych i usług. Za ich pomocą definiuje się messages, usługi query, typy stanu i typy genesis, a następnie generuje kod Go oraz stuby gRPC dla aplikacji.

Jakie moduły oferuje Cosmos SDK?

Cosmos SDK oferuje wiele modułów, które łańcuch może wybierać i łączyć. Żaden blockchain nie musi korzystać ze wszystkich modułów. To właśnie ten wybór decyduje o tym, co dana blockchain potrafi, a czego nie.

Kilka często używanych modułów to:

• x/auth: odpowiada za podstawowe typy kont i transakcji. Moduł ten pomaga między innymi przy sprawdzaniu podpisów i nonce konta.
• x/bank: zarządza saldami wielu tokenów, transferami tokenów i całkowitą podażą tokenów.
• x/staking: odpowiada za walidatorów i delegacje w modelu proof-of-stake.
• x/gov: umożliwia on-chain propozycje i głosowania.
• x/distribution: rozdziela nagrody za staking.
• x/slashing: może nakładać sankcje, gdy walidatorzy nie przestrzegają zasad.
• x/mint: wspiera emisję tokenów zgodnie z zasadami łańcucha.
• x/evidence: przetwarza dowody niewłaściwego zachowania walidatorów.
• x/upgrade: pomaga łańcuchowi przeprowadzać aktualizacje oprogramowania w skoordynowany sposób.

Istnieją też moduły do bardziej konkretnych zadań. Na przykład x/authz może obsługiwać delegowane autoryzacje dla messages, a x/feegrant może pozwolić, by inne konto opłacało fees użytkownika. x/consensus umożliwia zarządzanie niektórymi parametrami konsensusu CometBFT na poziomie łańcucha. x/circuit może działać jak circuit breaker, tymczasowo wstrzymując określone messages.

Funkcjonalność IBC jest zwykle dodawana przez ibc-go. To standardowa implementacja IBC dla blockchainów Cosmos SDK, utrzymywana jednak jako osobny projekt.

Deweloper może dostosować standardowe moduły, zastąpić ich elementy albo zbudować własne moduły. Łańcuch z samymi podstawowymi funkcjami wygląda więc zupełnie inaczej niż łańcuch z zarządzaniem walidatorami, governance i rozbudowanymi zasadami uprawnień.

Jak działają aplikacje Cosmos SDK?

Aplikacja Cosmos SDK działa dlatego, że deweloper świadomie zestawia moduły, rejestruje je i nadaje im odpowiednie uprawnienia. Samo zaimportowanie pakietu Go nie wystarczy więc, aby moduł działał na blockchainie.

W app.go budowana jest aplikacja. Tam rejestrowane są store keys, tworzone keepers, dodawane moduły do ModuleManager i łączone usługi. Deweloper określa też kolejność wykonywania hooków na granicach bloków. Ta kolejność może być ważna, ponieważ jeden moduł może zależeć od działań innego modułu.

Moduł zwykle zawiera cztery praktyczne elementy:

• Keeper: do kontrolowanego dostępu do własnego stanu.
• Msg-service: do działań zmieniających stan, takich jak transfer lub delegacja.
• Queryservice: do pytań tylko do odczytu, takich jak sprawdzenie salda.
• Implementację AppModule: aby moduł dobrze współpracował z ModuleManager.

Gdy pojawia się transakcja, BaseApp kieruje każdą message na podstawie jej typu do MsgServer właściwego modułu. Moduł sprawdza następnie, czy nadawca ma uprawnienia i czy działanie spełnia zasady biznesowe. Potem używa keepera do zmiany stanu.

Queries przebiegają inną drogą. Przez gRPCQueryRouter trafiają do queryservice właściwego modułu. Query odczytuje zapisany, potwierdzony stan i niczego nie zmienia. To jak różnica między sprawdzeniem salda bankowego a wykonaniem płatności.

Moduły mogą też zawierać logikę dla genesis, aktualizacji i granic bloków. Przy aktualizacji mogą być potrzebne migracje stanu, aby stare dane dobrze pasowały do nowego kodu. Wymaga to starannego planowania i testów ze strony dewelopera łańcucha.

Czym jest Cosmos EVM?

Blockchain Cosmos SDK można też uczynić kompatybilnym z Ethereum Virtual Machine (EVM). Służy do tego Cosmos EVM, dzięki któremu funkcjonalność EVM można zintegrować jako część aplikacji Cosmos SDK. W ten sposób projekt może zbudować własny blockchain Layer 1, który jednocześnie potrafi uruchamiać smart contracts Ethereum.

Rdzeniem tego rozwiązania jest moduł x/vm. Dodaje on do blockchaina środowisko wykonywania EVM, dzięki czemu deweloperzy mogą korzystać ze smart contracts Solidity i pracować ze znanymi narzędziami Ethereum, takimi jak MetaMask, Hardhat i Foundry. Blockchain pozostaje przy tym samodzielnym łańcuchem Cosmos SDK z własnymi zasadami i konfiguracją.

Cosmos EVM może też przez precompiles zapewniać dostęp do innych elementów Cosmos SDK. Smart contract może więc na przykład komunikować się z funkcjami staking, governance lub IBC. To, które precompiles są dostępne, konfigurują deweloperzy blockchaina.

Cosmos EVM nie jest obowiązkową częścią Cosmos SDK. Deweloper może zbudować łańcuch Cosmos SDK bez EVM albo świadomie dodać funkcjonalność EVM, jeśli potrzebna jest kompatybilność z aplikacjami i narzędziami Ethereum.

Do czego używa się Cosmos SDK?

Cosmos SDK służy do budowy wyspecjalizowanych pod konkretną aplikację blockchainów i cyfrowych rejestrów, gdy projekt chce sam określać zasady łańcucha. Dzięki temu można zaprojektować samodzielny blockchain Layer 1 zamiast budować tylko aplikację lub smart contract na istniejącej blockchainie. Jest to szczególnie przydatne wtedy, gdy standardowe zasady istniejącej ogólnego przeznaczenia blockchaina nie dają wystarczająco dużo swobody.

Projekt może na przykład na poziomie protokołu ustalić zasady dotyczące tokenizacji, transferów tokenów, zarządzania walidatorami w modelu proof-of-stake, governance, autoryzacji i fee allowances. Logika zgodności lub uprawnień może również stać się częścią zasad łańcucha.

SDK można wykorzystać w sieciach publicznych, prywatnych sieciach permissioned oraz sieciach konsorcjalnych. W sieci publicznej zasadniczo każdy może uczestniczyć zgodnie z otwartymi zasadami. W sieci permissioned z góry określeni uczestnicy lub validators mogą otrzymać uprawnienia.

To sprawia, że SDK jest przydatne w sytuacjach, gdy organizacja lub grupa chce zbudować nie tylko dApp albo smart contracts na istniejącej blockchainie, lecz potrzebuje własnego środowiska Layer 1 z własnymi przejściami stanu i zasadami łańcucha.

Przykładowe zastosowania to sieci międzybankowe, tokenizacja aktywów i automatyzacja procesów biznesowych. To, czy własny chain ma sens, zależy jednak od konkretnych wymagań. Własny łańcuch wymaga nie tylko kodu, ale też zarządzania, monitoringu, aktualizacji, governance i odpowiedniego modelu bezpieczeństwa.

Jaki jest związek między Cosmos SDK, Cosmos Hub i IBC?

Cosmos SDK to framework do budowy, IBC to protokół komunikacji między blockchainami, a Cosmos Hub to jeden konkretny publiczny blockchain proof-of-stake. Te trzy elementy są więc ze sobą powiązane, ale nie są tym samym.

Cosmos Hub uruchamia aplikację Gaia. Gaia została zbudowana jako aplikacja Cosmos SDK i korzysta z ibc-go dla IBC. ATOM jest natywnym tokenem stakingowym Cosmos Hub.

IBC oznacza Inter-Blockchain Communication. To otwarty protokół, który pozwala blockchainom przesyłać sobie zweryfikowane dane. Mogą to być tokeny, messages lub logika aplikacyjna.

Skąd łańcuch wie, że informacje z innego łańcucha są poprawne? IBC wykorzystuje między innymi clients, często nazywane light clients, aby weryfikować stan drugiej strony. Następnie IBC może w sposób możliwy do udowodnienia wysyłać, potwierdzać lub wygaszać packets. Packet to tutaj pakiet danych, który przechodzi z jednego łańcucha do drugiego.

Cosmos SDK ma ścisłe powiązanie z IBC przez ibc-go, ale IBC trzeba rzeczywiście wbudować w łańcuch. Deweloper musi między innymi dodać IBC keepers i storage, skonfigurować IBC router z trasami oraz zarejestrować odpowiednie moduły.

Dopiero potem do prawdziwej komunikacji potrzebna jest też odpowiednia druga strona, a także kanał IBC i relaying. Relayers to procesy, które przekazują wiadomości IBC między łańcuchami. Nie decydują one samodzielnie, jakie dane są ważne, ponieważ łańcuchy weryfikują te dane zgodnie z zasadami IBC.

Cosmos Hub może komunikować się przez IBC z innymi odpowiednimi łańcuchami, ale nie jest obowiązkową centralną warstwą pośrednią. Dwa dobrze skonfigurowane łańcuchy IBC mogą komunikować się bezpośrednio przez własne clients, connections i channels.

IBC nie jest też wyłącznie dla blockchainów Cosmos SDK. SDK sprawia przede wszystkim, że integracja jest praktyczna dla łańcuchów zbudowanych z jego użyciem.

Jakie są zalety i ograniczenia Cosmos SDK?

Największą siłą Cosmos SDK jest możliwość dostosowania. Deweloperzy mogą używać tylko tych modułów, które są potrzebne, zmieniać standardowe zachowanie i dodawać własną logikę. Dzięki temu zasady łańcucha można projektować bezpośrednio na poziomie protokołu.

Przydatny jest też podział między logiką aplikacyjną, ABCI i konsensusem. Osoba korzystająca z CometBFT nie musi budować całej zwykłej warstwy konsensusu i peer-to-peer od podstaw. Deweloper może dzięki temu bardziej skupić się na tym, co łańcuch ma robić.

Inne zalety to:

• Ponownie używalne bloki konstrukcyjne: moduły oferują funkcje dla kont, tokenów, staking, governance, aktualizacji i autoryzacji.
• Kontrolowany dostęp: keepers ograniczają, jaki stan moduł może odczytywać lub zmieniać w innych modułach.
• Interoperacyjność przez IBC: poprawnie zintegrowane łańcuchy IBC mogą wymieniać zweryfikowane dane bez centralnej strony pośredniczącej.
• Elastyczne modele sieci: SDK można wykorzystać w sieciach publicznych, prywatnych i konsorcjalnych.

Ta swoboda wiąże się jednak z odpowiedzialnością. Deweloper musi poprawnie zaprojektować moduły, keepers, uprawnienia, parametry i kolejność hooków. Również migracje stanu przy aktualizacjach i zarządzanie zależnościami wymagają uwagi. SDK jest w dużej mierze ustabilizowane, ale nadal może zawierać breaking changes. Aktualizację trzeba więc dobrze zaplanować i przetestować.

W praktyce ważna jest znajomość Go, ponieważ aplikacje SDK są binarkami Go, a Go jest potrzebne do budowy i uruchamiania węzła. Może to być bariera dla zespołów, które pracują głównie w innych językach programowania.

IBC umożliwia interoperacyjność, ale nie robi tego automatycznie. Łańcuch musi dobrze zintegrować i skonfigurować IBC. Potrzebna jest też kompatybilna druga strona, działający kanał i operacyjne relayers.

Na koniec SDK nie usuwa całej odpowiedzialności operacyjnej i bezpieczeństwa. Samodzielny chain musi sam utrzymywać odpowiedni model dla walidatorów i stake albo dla permissioned rules dotyczących walidatorów. Bezpieczeństwo zależy też od własnego kodu modułów, konfiguracji, key management, aktualizacji, infrastruktury i sposobu zarządzania siecią.

Podsumowanie

Cosmos SDK to elastyczny framework dla zespołów, które chcą zbudować własny blockchain z własnymi zasadami. Zamiast umieszczać tylko logikę w istniejącym łańcuchu, projekt może sam zdecydować, jak działają transakcje, stan, governance, uprawnienia i inne procesy.

Modułowa konstrukcja pozwala łączyć gotowe elementy, na przykład dla tokenów, staking i governance, z własnym kodem. Projekt może też na przykład zintegrować Cosmos EVM, jeśli chce połączyć własny blockchain ze wsparciem dla smart contracts Ethereum i narzędzi. CometBFT zwykle odpowiada przy tym za konsensus i warstwę sieciową, a BaseApp i moduły wykonują logikę aplikacyjną.

IBC może połączyć łańcuch Cosmos SDK z innymi poprawnie zintegrowanymi łańcuchami, ale takie połączenie wymaga świadomej konfiguracji technicznej. To samo dotyczy samego chaina: elastyczność oznacza też, że deweloperzy pozostają odpowiedzialni za projekt, aktualizacje, działanie i bezpieczeństwo.

Krótko mówiąc, Cosmos SDK jest szczególnie interesujące wtedy, gdy projekt chce nie tylko zbudować aplikację, ale także samodzielnie kształtować zasady stojącej za nią blockchaina.