Wat is de Cosmos SDK en hoe werkt het voor het bouwen van blockchains?

Wat is de Cosmos SDK?

De Cosmos SDK is open-source ontwikkelsoftware waarmee ontwikkelaars een eigen, applicatiespecifieke blockchain of digitaal grootboek kunnen bouwen. Het is dus geen blockchain, geen netwerk en ook geen token op zichzelf.

Een blockchain die met de Cosmos SDK wordt gebouwd, kan als zelfstandige Layer 1-blockchain functioneren. Dat betekent dat de keten niet als applicatie bovenop een andere blockchain draait, maar zelf de regels voor transacties, state en andere onderdelen van het protocol bepaalt. In combinatie met software zoals CometBFT kan zo'n blockchain ook een eigen validatornetwerk en consensusproces hebben.

Met de Cosmos SDK bepaalt een project zelf de regels van zijn keten. Denk aan wie bepaalde acties mag uitvoeren, hoe transacties werken, welke gegevens worden opgeslagen, hoe governance is ingericht en welke applicatielogica geldt.

Je kunt het zien als een bouwpakket voor een blockchain. In plaats van alle onderdelen vanaf nul te programmeren, kiest een ontwikkelaar bestaande onderdelen en voegt die samen met eigen code. Daardoor kan een keten bijvoorbeeld regels krijgen voor tokens, validatorbeheer, on-chain governance of specifieke permissies.

Een Cosmos SDK-applicatie is technisch gezien een deterministische state machine. Dat klinkt ingewikkeld, maar het idee is simpel: dezelfde geldige input moet bij iedere node altijd tot precies dezelfde nieuwe staat leiden. Als een gebruiker bijvoorbeeld tokens verstuurt, moeten alle nodes uiteindelijk hetzelfde saldo zien.

In de gebruikelijke opzet draait die applicatie als een Go-binary. Go is de programmeertaal waarin de ketenlogica wordt gebouwd. De applicatie draait samen met de software die nodes met elkaar laat communiceren en blokken laat maken.

De Cosmos SDK regelt vooral de applicatielaag: welke transacties geldig zijn en wat ze veranderen. CometBFT regelt doorgaans de consensus, peer-to-peer-netwerking en blokproductie. ABCI vormt de koppeling tussen die twee lagen. Via deze interface kan de consensussoftware de applicatie vragen om transacties en blokken te controleren en uit te voeren.

Korte samenvatting

• De Cosmos SDK is ontwikkelsoftware waarmee onder meer zelfstandige, applicatiespecifieke Layer 1-blockchains kunnen worden gebouwd.
• Een keten kan zelf regels instellen voor transacties, governance, permissies en opgeslagen gegevens.
• De SDK is modulair: ontwikkelaars combineren bestaande modules met eigen logica.
• CometBFT verzorgt meestal consensus, netwerkcommunicatie en blokproductie.
• De Cosmos SDK is geen afzonderlijke blockchain en heeft geen eigen token.

Hoe werkt de Cosmos SDK?

De Cosmos SDK werkt doordat CometBFT blokken laat verwerken en via ABCI de ketenapplicatie aanroept. De SDK bepaalt daarbij wat een transactie mag doen, terwijl CometBFT ervoor zorgt dat de nodes het eens worden over de blokken.

De centrale laag binnen een SDK-applicatie heet BaseApp. BaseApp vertaalt de oproepen van ABCI naar praktische taken: transacties uitvoeren, messages naar de juiste module sturen en de state bijwerken.

Een gebruiker verstuurt eerst een ondertekende transactie. In zo'n transactie staan één of meer messages. Een message is de concrete opdracht, zoals het versturen van tokens of het delegeren van tokens aan een validator.

De transactie bevat daarnaast onder meer een digitale handtekening, fees en een gaslimiet. De handtekening laat zien welke account de opdracht heeft goedgekeurd. Fees zijn de kosten voor verwerking. De gaslimiet geeft aan hoeveel rekenwerk de gebruiker maximaal wil betalen.

Voor de transactie wordt uitgevoerd, controleert de AnteHandler een aantal basisregels. Die kijkt bijvoorbeeld of de handtekening klopt, of de account-sequence juist is, of er genoeg fees zijn en of de gaslimiet niet wordt overschreden. De account-sequence is een oplopend nummer dat helpt voorkomen dat dezelfde transactie opnieuw wordt gebruikt.

Daarna stuurt BaseApp iedere message naar de juiste module. Een tokenoverdracht gaat bijvoorbeeld naar de module die saldi beheert. Die module controleert de eigen regels en past, als alles klopt, de state aan.

De state is alle actuele data van de keten, zoals accounts, saldi en instellingen. Deze gegevens staan als key-value-data opgeslagen in een multistore. Dat is een verzameling aparte opslagplaatsen, meestal één per module.

Een transactie wordt uitgevoerd met tijdelijke state-opslag. Wijzigingen die tijdens de uitvoering van een message worden gemaakt, worden alleen behouden als die uitvoering slaagt. Mislukt een message, dan worden die wijzigingen teruggedraaid. Sommige wijzigingen uit de eerdere AnteHandler-fase, zoals het innen van transactiekosten en het verhogen van de account-sequence, kunnen echter wel behouden blijven.

Bij de gebruikelijke CometBFT-flow verwerkt BaseApp een vastgesteld blok via FinalizeBlock. Daarbij wordt eerst eventuele logica vóór het blok uitgevoerd, daarna worden de transacties verwerkt en vervolgens de logica aan het einde van het blok. Daarna wordt de nieuwe state met Commit opgeslagen en ontstaat een nieuwe AppHash: een cryptografische vingerafdruk van de applicatiestate.

Voorbeeld: Stel dat je 10 tokens naar iemand verstuurt. Eerst controleert de keten je handtekening, sequence, fee en gaslimiet. Daarna controleert de tokenmodule of je minimaal 10 tokens hebt. Alleen als alle controles slagen, gaat er 10 van jouw saldo af en komt er 10 bij het saldo van de ontvanger.

Uit welke onderdelen bestaat de Cosmos SDK?

Een typische Cosmos SDK-applicatie bestaat uit BaseApp, modules en een laag waarin alles wordt samengesteld en geconfigureerd. Samen vormen deze onderdelen één state machine die nodeoperators draaien.

BaseApp is de schakel tussen CometBFT en de applicatie. Het verzorgt de ABCI-koppeling, routeert messages en queries, voert transacties uit en beheert de multistore.

Modules bevatten de echte businesslogica. Iedere module kan eigen state, messages, queryfuncties en regels hebben. Een keten kiest zelf welke modules zij opneemt. Daarna worden ze samengevoegd met eventuele eigen modules.

Dat samenvoegen gebeurt normaal in app.go. Daar maakt de ontwikkelaar BaseApp aan, stelt opslagplaatsen in, initialiseert onderdelen en bepaalt hoe de modules met elkaar samenwerken. De nodebinary start vervolgens zowel de consensusnode als de SDK-applicatie.

Modules gebruiken meestal een keeper voor toegang tot hun state. Een keeper kun je zien als een gecontroleerde toegangspoort tot opgeslagen gegevens. Niet elke module mag zomaar alles aanpassen. Een module krijgt alleen de rechten en interfaces die de applicatie bewust aan haar doorgeeft.

De ModuleManager houdt bij welke modules actief zijn en regelt onder meer de start bij genesis, upgrades en de volgorde van hooks op blokgrenzen. Genesis is het beginpunt van een blockchain: de eerste state waarmee het netwerk start.

Protocol Buffers spelen ook een belangrijke rol. Dit is een manier om gegevens en diensten duidelijk te beschrijven. Messages, queryservices, state-typen en genesis-typen worden hiermee gedefinieerd, waarna Go-code en gRPC-stubs worden gegenereerd voor de applicatie.

Welke modules biedt de Cosmos SDK?

De Cosmos SDK biedt veel modules die een keten kan kiezen en combineren. Geen enkele keten hoeft alle modules te gebruiken. Juist die keuze bepaalt wat de specifieke blockchain wel en niet kan.

Een paar veelgebruikte modules zijn:

• x/auth: regelt basisaccount- en transactietypen. Deze module helpt onder meer bij controles op handtekeningen en account-nonces.
• x/bank: beheert saldi van meerdere tokens, tokenoverdrachten en de totale tokenvoorraad.
• x/staking: regelt validators en delegaties binnen een proof-of-stake-opzet.
• x/gov: maakt on-chain voorstellen en stemmingen mogelijk.
• x/distribution: verdeelt stakingbeloningen.
• x/slashing: kan sancties toepassen wanneer validators zich niet aan de regels houden.
• x/mint: ondersteunt de uitgifte van tokens volgens de regels van de keten.
• x/evidence: verwerkt bewijs van validatorwangedrag.
• x/upgrade: helpt een keten om software-upgrades gecoördineerd uit te voeren.

Daarnaast zijn er modules voor specifieke taken. Zo kan x/authz gedelegeerde autorisaties voor messages regelen en kan x/feegrant toestaan dat een andere account de fees van een gebruiker betaalt. x/consensus maakt beheer van bepaalde CometBFT-consensusparameters op de keten mogelijk. x/circuit kan fungeren als circuit breaker om bepaalde messages tijdelijk te pauzeren.

IBC-functionaliteit wordt meestal toegevoegd via ibc-go. Dit is de gebruikelijke IBC-implementatie voor Cosmos SDK-ketens, maar wordt als afzonderlijk project onderhouden.

Een ontwikkelaar kan standaardmodules aanpassen, onderdelen vervangen of eigen modules bouwen. Een keten met alleen basisfuncties ziet er daardoor heel anders uit dan een keten met validatorbeheer, governance en uitgebreide permissieregels.

Hoe werken Cosmos SDK-applicaties?

Een Cosmos SDK-applicatie werkt doordat een ontwikkelaar modules bewust samenstelt, registreert en van de juiste rechten voorziet. Alleen een Go-package importeren is dus niet genoeg om een module op een keten te laten draaien.

In app.go wordt de applicatie opgebouwd. Daar worden store keys geregistreerd, keepers aangemaakt, modules toegevoegd aan de ModuleManager en services gekoppeld. Ook bepaalt de ontwikkelaar in welke volgorde hooks bij blokgrenzen worden uitgevoerd. Die volgorde kan belangrijk zijn, omdat de ene module afhankelijk kan zijn van acties van een andere module.

Een module bevat meestal vier praktische onderdelen:

• Een keeper: voor gecontroleerde toegang tot de eigen state.
• Een Msg-service: voor acties die de state veranderen, zoals een overdracht of delegatie.
• Een queryservice: voor read-only vragen, zoals het opvragen van een saldo.
• Een AppModule-implementatie: zodat de module goed samenwerkt met de ModuleManager.

Komt er een transactie binnen, dan routeert BaseApp iedere message op basis van het type naar de MsgServer van de juiste module. De module controleert vervolgens of de afzender bevoegd is en of de actie voldoet aan de businessregels. Daarna gebruikt de module de keeper om de state te wijzigen.

Queries volgen een andere route. Via de gRPCQueryRouter komen ze bij de queryservice van de juiste module terecht. Een query leest de opgeslagen, bevestigde state en verandert niets. Denk aan het verschil tussen je banksaldo bekijken en een betaling uitvoeren.

Modules kunnen ook logica hebben voor genesis, upgrades en blokgrenzen. Bij een upgrade kunnen state-migraties nodig zijn, zodat oude gegevens goed aansluiten op nieuwe code. Dat vraagt om zorgvuldige planning en tests van de ketenontwikkelaar.

Wat is Cosmos EVM?

Een Cosmos SDK-blockchain kan ook compatibel worden gemaakt met de Ethereum Virtual Machine (EVM). Daarvoor bestaat Cosmos EVM, waarmee EVM-functionaliteit als onderdeel van een Cosmos SDK-applicatie kan worden geïntegreerd. Hierdoor kan een project een eigen Layer 1-blockchain bouwen die tegelijkertijd Ethereum-smart contracts kan uitvoeren.

De kern hiervan is de x/vm-module. Deze voegt een EVM-uitvoeringsomgeving toe aan de blockchain, zodat ontwikkelaars Solidity-smart contracts kunnen gebruiken en met bekende Ethereum-tools zoals MetaMask, Hardhat en Foundry kunnen werken. De blockchain blijft ondertussen een zelfstandige Cosmos SDK-chain met eigen regels en configuratie.

Cosmos EVM kan daarnaast via precompiles toegang geven tot andere onderdelen van de Cosmos SDK. Een smart contract kan daardoor bijvoorbeeld communiceren met functionaliteit voor staking, governance of IBC. Welke precompiles beschikbaar zijn, wordt door de ontwikkelaars van de blockchain geconfigureerd.

Cosmos EVM is geen verplicht onderdeel van de Cosmos SDK. Een ontwikkelaar kan een Cosmos SDK-chain zonder EVM bouwen of bewust EVM-functionaliteit toevoegen wanneer compatibiliteit met Ethereum-applicaties en tooling gewenst is.

Waarvoor wordt de Cosmos SDK gebruikt?

De Cosmos SDK wordt gebruikt om applicatiespecifieke blockchains en digitale grootboeken te bouwen waarbij een project zelf de ketenregels wil bepalen. Zo kan een project een zelfstandige Layer 1-blockchain ontwerpen in plaats van alleen een applicatie of smart contract op een bestaande blockchain te bouwen. Dit is vooral nuttig wanneer de standaardregels van een bestaande algemene blockchain niet genoeg ruimte bieden.

Een project kan bijvoorbeeld op protocolniveau regels samenstellen voor tokenisatie, tokenoverdrachten, proof-of-stake-validatorbeheer, governance, autorisaties en fee-allowances. Ook compliance- of permissioninglogica kan onderdeel zijn van de ketenregels.

De SDK kan worden ingezet voor publieke netwerken, private permissioned netwerken en consortiumnetwerken. Bij een publiek netwerk kan in principe iedereen deelnemen volgens de open regels. In een permissioned netwerk kunnen juist vooraf bepaalde deelnemers of validators rechten krijgen.

Dat maakt de SDK bruikbaar voor situaties waarin een organisatie of groep niet alleen een dApp of smart contracts op een bestaande blockchain wil bouwen, maar een eigen Layer 1-omgeving met eigen state-overgangen en ketenregels nodig heeft.

Voorbeelden van mogelijke toepassingen zijn interbancaire netwerken, assettokenisatie en bedrijfsautomatisering. Of een eigen chain passend is, hangt wel af van de concrete eisen. Een eigen keten vraagt naast code ook om beheer, monitoring, upgrades, governance en een passend beveiligingsmodel.

Wat is de relatie tussen de Cosmos SDK, Cosmos Hub en IBC?

De Cosmos SDK is het bouwframework, IBC is het communicatieprotocol tussen blockchains en Cosmos Hub is één specifieke publieke proof-of-stake-blockchain. Deze drie horen dus bij elkaar, maar zijn niet hetzelfde.

Cosmos Hub draait de applicatie Gaia. Gaia is gebouwd als Cosmos SDK-applicatie en gebruikt ibc-go voor IBC. ATOM is de native stakingtoken van Cosmos Hub.

IBC staat voor Inter-Blockchain Communication. Het is een open protocol waarmee blockchains geverifieerde data naar elkaar kunnen sturen. Die data kan bestaan uit tokens, messages of applicatielogica.

Hoe weet een keten dan dat informatie van een andere keten klopt? IBC gebruikt onder meer clients, vaak light clients genoemd, om de state van de tegenpartij te verifiëren. Daarna kan IBC packets aantoonbaar versturen, bevestigen of laten verlopen. Een packet is hierbij een pakketje data dat van de ene keten naar de andere gaat.

De Cosmos SDK heeft een nauwe koppeling met IBC via ibc-go, maar IBC moet wel echt in de keten worden ingebouwd. Een ontwikkelaar moet onder meer IBC-keepers en opslag toevoegen, een IBC-router met routes instellen en relevante modules registreren.

Daarna is voor echte communicatie ook een geschikte tegenpartij nodig, plus een IBC-kanaal en relaying. Relayers zijn processen die IBC-berichten tussen ketens doorgeven. Zij regelen niet zelf welke data geldig is, want de ketens verifiëren die data volgens de IBC-regels.

Cosmos Hub kan via IBC met andere geschikte ketens communiceren, maar is geen verplichte centrale tussenlaag. Twee goed ingerichte IBC-ketens kunnen rechtstreeks met elkaar communiceren via hun eigen clients, connections en channels.

Ook IBC is niet exclusief voor Cosmos SDK-ketens. De SDK maakt de integratie vooral praktisch voor ketens die ermee zijn gebouwd.

Wat zijn de voordelen en beperkingen van de Cosmos SDK?

De grootste kracht van de Cosmos SDK is maatwerk. Ontwikkelaars kunnen alleen de modules gebruiken die nodig zijn, standaardgedrag aanpassen en eigen logica toevoegen. Daardoor kunnen de regels van een keten direct op protocolniveau worden ontworpen.

De scheiding tussen applicatielogica, ABCI en consensus is ook handig. Wie CometBFT gebruikt, hoeft de gebruikelijke consensus- en peer-to-peerlaag niet helemaal zelf te bouwen. De ontwikkelaar kan zich daardoor meer richten op wat de keten moet doen.

Andere voordelen zijn:

• Herbruikbare bouwblokken: modules bieden functies voor accounts, tokens, staking, governance, upgrades en autorisatie.
• Gecontroleerde toegang: keepers beperken welke state een module van andere modules kan lezen of aanpassen.
• Interoperabiliteit via IBC: correct geïntegreerde IBC-ketens kunnen geverifieerde data uitwisselen zonder een centrale brugpartij.
• Flexibele netwerkmodellen: de SDK kan worden gebruikt voor publieke, private en consortiumnetwerken.

Die vrijheid brengt ook verantwoordelijkheid mee. Een ontwikkelaar moet modules, keepers, permissies, parameters en hookvolgordes correct ontwerpen. Ook state-migraties bij upgrades en dependencybeheer vragen aandacht. De SDK is grotendeels gestabiliseerd, maar kan nog breaking changes bevatten. Een upgrade moet daarom goed worden gepland en getest.

Go-kennis is in de praktijk belangrijk, omdat SDK-applicaties Go-binaries zijn en Go nodig is om een node te bouwen en te draaien. Dat kan een drempel zijn voor teams die vooral met andere programmeertalen werken.

IBC maakt interoperabiliteit mogelijk, maar niet automatisch. Een keten moet IBC goed integreren en configureren. Daarnaast zijn een compatibele tegenpartij, een werkend kanaal en operationele relayers nodig.

Tot slot neemt de SDK niet alle operationele en beveiligingsverantwoordelijkheid weg. Een zelfstandige chain moet zelf een passend model draaien voor validators en stake, of voor permissioned validatorregels. De veiligheid hangt daarnaast af van eigen modulecode, configuratie, key management, upgrades, infrastructuur en de manier waarop het netwerk wordt beheerd.

Conclusie

De Cosmos SDK is een flexibel framework voor teams die een eigen blockchain met eigen regels willen bouwen. In plaats van alleen logica binnen een bestaande keten te plaatsen, kan een project zelf bepalen hoe transacties, state, governance, permissies en andere processen werken.

De modulaire opzet maakt het mogelijk om bestaande onderdelen voor bijvoorbeeld tokens, staking en governance te combineren met eigen code. Een project kan daarnaast bijvoorbeeld Cosmos EVM integreren wanneer het een eigen blockchain wil combineren met ondersteuning voor Ethereum-smart contracts en tooling. CometBFT verzorgt daarbij meestal de consensus en netwerklaag, terwijl BaseApp en de modules de applicatielogica uitvoeren.

IBC kan een Cosmos SDK-keten verbinden met andere correct geïntegreerde ketens, maar die koppeling vraagt wel om bewuste technische inrichting. Hetzelfde geldt voor de chain zelf: flexibiliteit betekent ook dat ontwikkelaars verantwoordelijk blijven voor ontwerp, upgrades, operatie en beveiliging.

Kort gezegd is de Cosmos SDK vooral interessant wanneer een project niet alleen een toepassing wil bouwen, maar de regels van de onderliggende blockchain zelf wil vormgeven.