Was ist das Cosmos SDK und wie funktioniert es beim Aufbau von Blockchains?

Was ist das Cosmos SDK?

Das Cosmos-SDK ist Open-Source-Entwicklungssoftware, mit der Entwickler eine eigene, anwendungsspezifische Blockchain oder ein digitales Hauptbuch aufbauen können. Es ist also weder selbst eine Blockchain noch ein Netzwerk und auch kein Token.

Eine Blockchain, die mit dem Cosmos SDK gebaut wird, kann als eigenständige Layer-1-Blockchain funktionieren. Das bedeutet, dass die Kette nicht als Anwendung auf einer anderen Blockchain läuft, sondern selbst die Regeln für Transaktionen, State und andere Teile des Protokolls festlegt. In Kombination mit Software wie CometBFT kann so eine Blockchain auch ein eigenes Validatornetzwerk und einen eigenen Konsensprozess haben.

Mit dem Cosmos SDK legt ein Projekt die Regeln seiner Kette selbst fest. Dazu gehören etwa, wer bestimmte Aktionen ausführen darf, wie Transaktionen funktionieren, welche Daten gespeichert werden, wie Governance aufgebaut ist und welche Anwendungslogik gilt.

Du kannst es dir wie einen Baukasten für eine Blockchain vorstellen. Statt alle Komponenten von Grund auf neu zu programmieren, wählt ein Entwickler bestehende Bausteine aus und kombiniert sie mit eigenem Code. Dadurch kann eine Kette zum Beispiel Regeln für Token, Validator-Verwaltung, On-Chain-Governance oder spezielle Berechtigungen erhalten.

Eine Cosmos-SDK-Anwendung ist technisch gesehen eine deterministische State Machine. Das klingt kompliziert, aber die Idee ist einfach: Derselbe gültige Input muss bei jedem Node immer exakt zum selben neuen Zustand führen. Wenn ein Nutzer zum Beispiel Token sendet, müssen alle Nodes am Ende denselben Kontostand sehen.

In der üblichen Architektur läuft diese Anwendung als Go-Binary. Go ist die Programmiersprache, in der die Kettenlogik gebaut wird. Die Anwendung läuft zusammen mit der Software, die Nodes miteinander kommunizieren lässt und Blöcke erzeugt.

Das Cosmos SDK regelt vor allem die Anwendungsebene: welche Transaktionen gültig sind und was sie verändern. CometBFT übernimmt in der Regel den Konsens, die Peer-to-Peer-Vernetzung und die Blockproduktion. ABCI bildet die Verbindung zwischen diesen beiden Ebenen. Über diese Schnittstelle kann die Konsenssoftware die Anwendung auffordern, Transaktionen und Blöcke zu prüfen und auszuführen.

Wichtigste Erkenntnisse

• Das Cosmos SDK ist Entwicklungssoftware, mit der unter anderem eigenständige, anwendungsspezifische Layer-1-Blockchains gebaut werden können.
• Eine Kette kann selbst Regeln für Transaktionen, Governance, Berechtigungen und gespeicherte Daten festlegen.
• Das SDK ist modular: Entwickler kombinieren bestehende Module mit eigener Logik.
• CometBFT übernimmt meist Konsens, Netzwerkkommunikation und Blockproduktion.
• Das Cosmos SDK ist keine eigene Blockchain und hat keinen eigenen Token.

Wie funktioniert das Cosmos SDK?

Das Cosmos SDK funktioniert, indem CometBFT Blöcke verarbeiten lässt und über ABCI die Kettenanwendung aufruft. Das SDK legt dabei fest, was eine Transaktion tun darf, während CometBFT dafür sorgt, dass sich die Nodes über die Blöcke einig werden.

Die zentrale Ebene innerhalb einer SDK-Anwendung heißt BaseApp. BaseApp übersetzt die Aufrufe von ABCI in praktische Aufgaben: Transaktionen ausführen, Messages an das richtige Modul weiterleiten und den State aktualisieren.

Ein Nutzer sendet zuerst eine signierte Transaktion. In so einer Transaktion stehen eine oder mehrere Messages. Eine Message ist der konkrete Auftrag, etwa das Senden von Token oder das Delegieren von Token an einen Validator.

Die Transaktion enthält außerdem unter anderem eine digitale Signatur, Fees und ein Gaslimit. Die Signatur zeigt, welches Konto den Auftrag genehmigt hat. Fees sind die Kosten für die Verarbeitung. Das Gaslimit gibt an, wie viel Rechenaufwand der Nutzer maximal bezahlen will.

Bevor die Transaktion ausgeführt wird, prüft der AnteHandler einige grundlegende Regeln. Er schaut zum Beispiel, ob die Signatur stimmt, ob die Account-Sequence korrekt ist, ob genug Fees vorhanden sind und ob das Gaslimit nicht überschritten wird. Die Account-Sequence ist eine fortlaufende Nummer, die hilft zu verhindern, dass dieselbe Transaktion erneut verwendet wird.

Danach sendet BaseApp jede Message an das passende Modul. Eine Tokenübertragung geht zum Beispiel an das Modul, das Salden verwaltet. Dieses Modul prüft seine eigenen Regeln und passt, wenn alles stimmt, den State an.

Der State sind alle aktuellen Daten der Kette, etwa Konten, Salden und Einstellungen. Diese Daten werden als Key-Value-Daten in einem Multistore gespeichert. Das ist eine Sammlung getrennter Speicherbereiche, meist einer pro Modul.

Eine Transaktion wird mit temporärem State-Speicher ausgeführt. Änderungen, die während der Ausführung einer Message vorgenommen werden, bleiben nur erhalten, wenn diese Ausführung erfolgreich ist. Schlägt eine Message fehl, werden diese Änderungen zurückgesetzt. Einige Änderungen aus der früheren AnteHandler-Phase, etwa das Einziehen von Transaktionsgebühren und das Erhöhen der Account-Sequence, können jedoch erhalten bleiben.

Im üblichen CometBFT-Flow verarbeitet BaseApp einen festgelegten Block über FinalizeBlock. Dabei wird zuerst eventuelle Logik vor dem Block ausgeführt, danach werden die Transaktionen verarbeitet und anschließend die Logik am Ende des Blocks. Danach wird der neue State mit Commit gespeichert und es entsteht ein neuer AppHash: ein kryptografischer Fingerabdruck des Anwendungs-States.

Beispiel: Stell dir vor, du sendest 10 Token an jemanden. Zuerst prüft die Kette deine Signatur, Sequence, Fee und das Gaslimit. Danach prüft das Token-Modul, ob du mindestens 10 Token hast. Nur wenn alle Prüfungen erfolgreich sind, gehen 10 von deinem Kontostand ab und 10 kommen beim Kontostand des Empfängers hinzu.

Aus welchen Bestandteilen besteht das Cosmos SDK?

Eine typische Cosmos-SDK-Anwendung besteht aus BaseApp, Modulen und einer Ebene, in der alles zusammengesetzt und konfiguriert wird. Zusammen bilden diese Bestandteile eine einzige State Machine, die Node-Operatoren betreiben.

BaseApp ist die Schnittstelle zwischen CometBFT und der Anwendung. Es übernimmt die ABCI-Anbindung, leitet Messages und Queries weiter, führt Transaktionen aus und verwaltet den Multistore.

Module enthalten die eigentliche Businesslogik. Jedes Modul kann eigenen State, eigene Messages, Query-Funktionen und Regeln haben. Eine Kette wählt selbst aus, welche Module sie aufnimmt. Danach werden sie mit eventuellen eigenen Modulen zusammengeführt.

Dieses Zusammenführen passiert normalerweise in app.go. Dort erstellt der Entwickler BaseApp, richtet Speicherbereiche ein, initialisiert Komponenten und legt fest, wie die Module miteinander zusammenarbeiten. Die Node-Binary startet anschließend sowohl den Konsens-Node als auch die SDK-Anwendung.

Module verwenden meist einen Keeper für den Zugriff auf ihren State. Einen Keeper kannst du dir als kontrollierten Zugangspunkt zu gespeicherten Daten vorstellen. Nicht jedes Modul darf einfach alles ändern. Ein Modul erhält nur die Rechte und Schnittstellen, die die Anwendung ihm bewusst übergibt.

Der ModuleManager hält fest, welche Module aktiv sind, und regelt unter anderem den Start bei Genesis, Upgrades und die Reihenfolge der Hooks an Blockgrenzen. Genesis ist der Startpunkt einer Blockchain: der erste State, mit dem das Netzwerk beginnt.

Auch Protocol Buffers spielen eine wichtige Rolle. Das ist eine Methode, um Daten und Dienste klar zu beschreiben. Messages, Query-Services, State-Typen und Genesis-Typen werden damit definiert, danach werden Go-Code und gRPC-Stubs für die Anwendung generiert.

Welche Module bietet das Cosmos SDK?

Das Cosmos SDK bietet viele Module, aus denen eine Kette auswählen und kombinieren kann. Keine Kette muss alle Module verwenden. Genau diese Auswahl bestimmt, was die jeweilige Blockchain kann und was nicht.

Einige häufig genutzte Module sind:

• x/auth: regelt grundlegende Konto- und Transaktionstypen. Dieses Modul hilft unter anderem bei Prüfungen von Signaturen und Account-Nonces.
• x/bank: verwaltet Salden mehrerer Token, Tokenübertragungen und den gesamten Tokenbestand.
• x/staking: regelt Validatoren und Delegationen innerhalb eines Proof-of-Stake-Setups.
• x/gov: ermöglicht On-Chain-Vorschläge und Abstimmungen.
• x/distribution: verteilt Staking-Belohnungen.
• x/slashing: kann Sanktionen anwenden, wenn Validatoren sich nicht an die Regeln halten.
• x/mint: unterstützt die Ausgabe von Token nach den Regeln der Kette.
• x/evidence: verarbeitet Beweise für Fehlverhalten von Validatoren.
• x/upgrade: hilft einer Kette, Software-Upgrades koordiniert durchzuführen.

Darüber hinaus gibt es Module für spezielle Aufgaben. So kann x/authz delegierte Autorisierungen für Messages regeln und x/feegrant erlauben, dass ein anderes Konto die Fees eines Nutzers bezahlt. x/consensus ermöglicht die Verwaltung bestimmter CometBFT-Konsensparameter auf der Kette. x/circuit kann als Circuit Breaker dienen, um bestimmte Messages vorübergehend zu pausieren.

IBC-Funktionalität wird meist über ibc-go hinzugefügt. Das ist die übliche IBC-Implementierung für Cosmos-SDK-Ketten, wird aber als separates Projekt gepflegt.

Ein Entwickler kann Standardmodule anpassen, Komponenten ersetzen oder eigene Module bauen. Eine Kette mit nur Basisfunktionen sieht dadurch ganz anders aus als eine Kette mit Validator-Verwaltung, Governance und umfangreichen Berechtigungsregeln.

Wie funktionieren Cosmos-SDK-Anwendungen?

Eine Cosmos-SDK-Anwendung funktioniert, indem ein Entwickler Module bewusst zusammenstellt, registriert und mit den richtigen Rechten ausstattet. Nur ein Go-Paket zu importieren reicht also nicht aus, damit ein Modul auf einer Kette läuft.

In app.go wird die Anwendung aufgebaut. Dort werden Store-Keys registriert, Keeper erstellt, Module dem ModuleManager hinzugefügt und Services verbunden. Außerdem legt der Entwickler fest, in welcher Reihenfolge Hooks an Blockgrenzen ausgeführt werden. Diese Reihenfolge kann wichtig sein, weil ein Modul von Aktionen eines anderen Moduls abhängen kann.

Ein Modul besteht meist aus vier praktischen Teilen:

• Ein Keeper: für den kontrollierten Zugriff auf den eigenen State.
• Ein Msg-Service: für Aktionen, die den State verändern, etwa eine Übertragung oder Delegation.
• Ein Query-Service: für reine Leseanfragen, etwa das Abrufen eines Kontostands.
• Eine AppModule-Implementierung: damit das Modul gut mit dem ModuleManager zusammenarbeitet.

Kommt eine Transaktion an, leitet BaseApp jede Message anhand des Typs an den MsgServer des richtigen Moduls weiter. Das Modul prüft dann, ob der Absender berechtigt ist und ob die Aktion den Businessregeln entspricht. Danach nutzt das Modul den Keeper, um den State zu ändern.

Queries laufen über einen anderen Weg. Über den gRPCQueryRouter gelangen sie zum Query-Service des richtigen Moduls. Eine Query liest den gespeicherten, bestätigten State und verändert nichts. Denk an den Unterschied zwischen dem Blick auf dein Bankguthaben und einer Zahlung.

Module können auch Logik für Genesis, Upgrades und Blockgrenzen haben. Bei einem Upgrade können State-Migrationen nötig sein, damit alte Daten sauber zu neuem Code passen. Das erfordert sorgfältige Planung und Tests durch den Kettenentwickler.

Was ist Cosmos EVM?

Eine Cosmos-SDK-Blockchain kann auch mit der Ethereum Virtual Machine (EVM) kompatibel gemacht werden. Dafür gibt es Cosmos EVM, mit dem EVM-Funktionalität als Teil einer Cosmos-SDK-Anwendung integriert werden kann. Dadurch kann ein Projekt eine eigene Layer-1-Blockchain bauen, die gleichzeitig Ethereum-Smart-Contracts ausführen kann.

Der Kern davon ist das x/vm-Modul. Es fügt der Blockchain eine EVM-Ausführungsumgebung hinzu, sodass Entwickler Solidity-Smart-Contracts verwenden und mit bekannten Ethereum-Tools wie MetaMask, Hardhat und Foundry arbeiten können. Die Blockchain bleibt dabei eine eigenständige Cosmos-SDK-Chain mit eigenen Regeln und eigener Konfiguration.

Cosmos EVM kann außerdem über Precompiles Zugriff auf andere Teile des Cosmos SDK geben. Ein Smart Contract kann dadurch zum Beispiel mit Funktionen für Staking, Governance oder IBC kommunizieren. Welche Precompiles verfügbar sind, wird von den Entwicklern der Blockchain konfiguriert.

Cosmos EVM ist kein verpflichtender Bestandteil des Cosmos SDK. Ein Entwickler kann eine Cosmos-SDK-Chain ohne EVM bauen oder bewusst EVM-Funktionalität hinzufügen, wenn Kompatibilität mit Ethereum-Anwendungen und Tools gewünscht ist.

Wofür wird das Cosmos SDK verwendet?

Das Cosmos SDK wird verwendet, um anwendungsspezifische Blockchains und digitale Hauptbücher zu bauen, bei denen ein Projekt die Kettenregeln selbst festlegen will. So kann ein Projekt eine eigenständige Layer-1-Blockchain entwerfen, statt nur eine Anwendung oder Smart Contracts auf einer bestehenden Blockchain zu bauen. Das ist vor allem dann nützlich, wenn die Standardregeln einer bestehenden allgemeinen Blockchain nicht genug Spielraum bieten.

Ein Projekt kann zum Beispiel auf Protokollebene Regeln für Tokenisierung, Tokenübertragungen, Proof-of-Stake-Validator-Verwaltung, Governance, Autorisierungen und Fee-Allowances zusammenstellen. Auch Compliance- oder Permissioning-Logik kann Teil der Kettenregeln sein.

Das SDK kann für öffentliche Netzwerke, private permissioned Netzwerke und Konsortiumsnetzwerke eingesetzt werden. Bei einem öffentlichen Netzwerk kann grundsätzlich jeder nach den offenen Regeln teilnehmen. In einem permissioned Netzwerk können dagegen vorher bestimmte Teilnehmer oder Validatoren Rechte erhalten.

Das macht das SDK nützlich für Situationen, in denen eine Organisation oder Gruppe nicht nur eine dApp oder Smart Contracts auf einer bestehenden Blockchain bauen will, sondern eine eigene Layer-1-Umgebung mit eigenen State-Übergängen und Kettenregeln braucht.

Beispiele für mögliche Anwendungen sind Interbanken-Netzwerke, Asset-Tokenisierung und Unternehmensautomatisierung. Ob eine eigene Chain sinnvoll ist, hängt allerdings von den konkreten Anforderungen ab. Eine eigene Kette braucht neben Code auch Verwaltung, Monitoring, Upgrades, Governance und ein passendes Sicherheitsmodell.

Was ist die Beziehung zwischen dem Cosmos SDK, Cosmos Hub und IBC?

Das Cosmos SDK ist das Bau-Framework, IBC ist das Kommunikationsprotokoll zwischen Blockchains und Cosmos Hub ist eine bestimmte öffentliche Proof-of-Stake-Blockchain. Diese drei gehören also zusammen, sind aber nicht dasselbe.

Cosmos Hub betreibt die Anwendung Gaia. Gaia ist als Cosmos-SDK-Anwendung gebaut und nutzt ibc-go für IBC. ATOM ist der native Staking-Token von Cosmos Hub.

IBC steht für Inter-Blockchain Communication. Es ist ein offenes Protokoll, mit dem Blockchains verifizierte Daten aneinander senden können. Diese Daten können aus Token, Messages oder Anwendungslogik bestehen.

Woher weiß eine Kette dann, dass Informationen von einer anderen Kette stimmen? IBC nutzt unter anderem Clients, oft Light Clients genannt, um den State der Gegenpartei zu verifizieren. Danach kann IBC nachweislich Packets senden, bestätigen oder auslaufen lassen. Ein Packet ist dabei ein Datenpaket, das von einer Kette zur anderen geht.

Das Cosmos SDK ist eng mit IBC über ibc-go verbunden, aber IBC muss tatsächlich in die Kette eingebaut werden. Ein Entwickler muss unter anderem IBC-Keeper und Speicher hinzufügen, einen IBC-Router mit Routen einrichten und relevante Module registrieren.

Danach braucht es für echte Kommunikation auch eine passende Gegenpartei, plus einen IBC-Kanal und Relaying. Relayers sind Prozesse, die IBC-Nachrichten zwischen Ketten weitergeben. Sie entscheiden nicht selbst, welche Daten gültig sind, denn die Ketten verifizieren diese Daten nach den IBC-Regeln.

Cosmos Hub kann über IBC mit anderen geeigneten Ketten kommunizieren, ist aber keine verpflichtende zentrale Zwischenschicht. Zwei sauber eingerichtete IBC-Ketten können direkt über ihre eigenen Clients, Connections und Channels miteinander kommunizieren.

Auch IBC ist nicht exklusiv für Cosmos-SDK-Ketten. Das SDK macht die Integration vor allem für Ketten praktisch, die damit gebaut wurden.

Was sind die Vorteile und Grenzen des Cosmos SDK?

Die größte Stärke des Cosmos SDK ist die Anpassbarkeit. Entwickler können nur die Module verwenden, die sie brauchen, Standardverhalten anpassen und eigene Logik hinzufügen. Dadurch lassen sich die Regeln einer Kette direkt auf Protokollebene gestalten.

Die Trennung zwischen Anwendungslogik, ABCI und Konsens ist ebenfalls praktisch. Wer CometBFT nutzt, muss die übliche Konsens- und Peer-to-Peer-Ebene nicht komplett selbst bauen. Der Entwickler kann sich dadurch stärker darauf konzentrieren, was die Kette tun soll.

Weitere Vorteile sind:

• Wiederverwendbare Bausteine: Module bieten Funktionen für Konten, Token, Staking, Governance, Upgrades und Autorisierung.
• Kontrollierter Zugriff: Keeper begrenzen, welchen State ein Modul von anderen Modulen lesen oder ändern kann.
• Interoperabilität über IBC: korrekt integrierte IBC-Ketten können verifizierte Daten austauschen, ohne eine zentrale Brückenpartei.
• Flexible Netzwerkmodelle: Das SDK kann für öffentliche, private und Konsortiumsnetzwerke verwendet werden.

Diese Freiheit bringt auch Verantwortung mit sich. Ein Entwickler muss Module, Keeper, Berechtigungen, Parameter und Hook-Reihenfolgen korrekt entwerfen. Auch State-Migrationen bei Upgrades und das Abhängigkeitsmanagement brauchen Aufmerksamkeit. Das SDK ist weitgehend stabilisiert, kann aber noch Breaking Changes enthalten. Ein Upgrade sollte deshalb gut geplant und getestet werden.

Go-Kenntnisse sind in der Praxis wichtig, weil SDK-Anwendungen Go-Binaries sind und Go benötigt wird, um einen Node zu bauen und zu betreiben. Das kann für Teams, die vor allem mit anderen Programmiersprachen arbeiten, eine Hürde sein.

IBC ermöglicht Interoperabilität, aber nicht automatisch. Eine Kette muss IBC sauber integrieren und konfigurieren. Außerdem braucht es eine kompatible Gegenpartei, einen funktionierenden Kanal und operative Relayers.

Schließlich nimmt das SDK nicht die gesamte operative und sicherheitsbezogene Verantwortung ab. Eine eigenständige Chain muss selbst ein passendes Modell für Validatoren und Stake oder für permissioned Validator-Regeln betreiben. Die Sicherheit hängt außerdem vom eigenen Modulcode, der Konfiguration, dem Key Management, Upgrades, der Infrastruktur und der Art ab, wie das Netzwerk betrieben wird.

Fazit

Das Cosmos SDK ist ein flexibles Framework für Teams, die eine eigene Blockchain mit eigenen Regeln bauen wollen. Statt nur Logik innerhalb einer bestehenden Kette zu platzieren, kann ein Projekt selbst bestimmen, wie Transaktionen, State, Governance, Berechtigungen und andere Prozesse funktionieren.

Die modulare Struktur macht es möglich, bestehende Bausteine etwa für Token, Staking und Governance mit eigenem Code zu kombinieren. Ein Projekt kann außerdem zum Beispiel Cosmos EVM integrieren, wenn es eine eigene Blockchain mit Unterstützung für Ethereum-Smart-Contracts und Tools verbinden will. CometBFT übernimmt dabei meist Konsens und Netzwerkschicht, während BaseApp und die Module die Anwendungslogik ausführen.

IBC kann eine Cosmos-SDK-Kette mit anderen korrekt integrierten Ketten verbinden, aber diese Anbindung erfordert eine bewusste technische Einrichtung. Dasselbe gilt für die Chain selbst: Flexibilität bedeutet auch, dass Entwickler für Design, Upgrades, Betrieb und Sicherheit verantwortlich bleiben.

Kurz gesagt ist das Cosmos SDK vor allem dann interessant, wenn ein Projekt nicht nur eine Anwendung bauen will, sondern die Regeln der zugrunde liegenden Blockchain selbst gestalten möchte.