O que é o Cosmos SDK e como funciona para construir blockchains?

O que é o Cosmos SDK?

O SDK da Cosmos é software de desenvolvimento open-source que permite aos programadores construir uma blockchain própria, específica para aplicações, ou um livro-razão digital. Portanto, não é uma blockchain, nem uma rede, nem um token por si só.

Uma blockchain construída com o Cosmos SDK pode funcionar como uma blockchain Layer 1 autónoma. Isso significa que a cadeia não funciona como uma aplicação por cima de outra blockchain, mas define por si própria as regras para transacções, state e outros componentes do protocolo. Em combinação com software como o CometBFT, uma blockchain deste tipo também pode ter a sua própria rede de validadores e processo de consenso.

Com o Cosmos SDK, um projecto define por si próprio as regras da sua cadeia. Pense em quem pode executar determinadas acções, como funcionam as transacções, que dados são armazenados, como a governance está organizada e que lógica de aplicação se aplica.

Pode vê-lo como um kit de construção para uma blockchain. Em vez de programar todos os componentes a partir do zero, um programador escolhe componentes existentes e combina-os com código próprio. Assim, uma cadeia pode, por exemplo, receber regras para tokens, gestão de validadores, governance on-chain ou permissões específicas.

Uma aplicação Cosmos SDK é, tecnicamente, uma máquina de estados determinística. Isto soa complicado, mas a ideia é simples: a mesma entrada válida deve conduzir sempre ao mesmo novo estado em cada node. Se um utilizador, por exemplo, enviar tokens, todos os nodes devem acabar por ver o mesmo saldo.

Na configuração habitual, essa aplicação funciona como um binário Go. Go é a linguagem de programação em que a lógica da cadeia é construída. A aplicação funciona em conjunto com o software que permite aos nodes comunicar entre si e produzir blocos.

O Cosmos SDK trata sobretudo da camada de aplicação: que transacções são válidas e o que alteram. O CometBFT trata, em regra, do consenso, da rede peer-to-peer e da produção de blocos. O ABCI faz a ligação entre estas duas camadas. Através desta interface, o software de consenso pode pedir à aplicação que verifique e execute transacções e blocos.

Pontos principais

• O Cosmos SDK é software de desenvolvimento com o qual, entre outras coisas, podem ser construídas blockchains Layer 1 autónomas e específicas para aplicações.
• Uma cadeia pode definir por si própria regras para transacções, governance, permissões e dados armazenados.
• O SDK é modular: os programadores combinam módulos existentes com lógica própria.
• O CometBFT normalmente assegura o consenso, a comunicação em rede e a produção de blocos.
• O Cosmos SDK não é uma blockchain separada e não tem token próprio.

Como funciona o Cosmos SDK?

O Cosmos SDK funciona porque o CometBFT processa blocos e chama a aplicação da cadeia através do ABCI. O SDK determina o que uma transacção pode fazer, enquanto o CometBFT garante que os nodes chegam a acordo sobre os blocos.

A camada central dentro de uma aplicação SDK chama-se BaseApp. A BaseApp traduz as chamadas do ABCI em tarefas práticas: executar transacções, enviar messages para o módulo certo e actualizar o state.

Um utilizador envia primeiro uma transacção assinada. Numa transacção deste tipo estão uma ou mais messages. Uma message é a instrução concreta, como enviar tokens ou delegar tokens a um validador.

A transacção inclui ainda, entre outros elementos, uma assinatura digital, fees e um limite de gas. A assinatura mostra que conta aprovou a instrução. As fees são os custos de processamento. O limite de gas indica quanto trabalho computacional o utilizador quer pagar, no máximo.

Antes de a transacção ser executada, o AnteHandler verifica várias regras básicas. Por exemplo, verifica se a assinatura está correcta, se a sequência da conta está certa, se há fees suficientes e se o limite de gas não é excedido. A sequência da conta é um número crescente que ajuda a evitar que a mesma transacção seja reutilizada.

Depois, a BaseApp envia cada message para o módulo certo. Uma transferência de tokens, por exemplo, vai para o módulo que gere saldos. Esse módulo verifica as suas próprias regras e, se tudo estiver correcto, actualiza o state.

O state é todos os dados actuais da cadeia, como contas, saldos e definições. Estes dados são armazenados como dados key-value num multistore. Trata-se de uma colecção de espaços de armazenamento separados, normalmente um por módulo.

Uma transacção é executada com armazenamento temporário de state. As alterações feitas durante a execução de uma message só são mantidas se essa execução for bem-sucedida. Se uma message falhar, essas alterações são revertidas. No entanto, algumas alterações da fase anterior do AnteHandler, como a cobrança de taxas de transacção e o aumento da sequência da conta, podem ser mantidas.

No fluxo habitual do CometBFT, a BaseApp processa um bloco definido através de FinalizeBlock. Nessa fase, primeiro é executada qualquer lógica antes do bloco, depois as transacções são processadas e, por fim, a lógica no final do bloco. Em seguida, o novo state é guardado com Commit e surge um novo AppHash: uma impressão digital criptográfica do state da aplicação.

Exemplo: Imagine que envia 10 tokens a alguém. Primeiro, a cadeia verifica a sua assinatura, sequence, fee e limite de gas. Depois, o módulo de tokens verifica se tem pelo menos 10 tokens. Só se todas as verificações forem bem-sucedidas é que 10 saem do seu saldo e 10 entram no saldo do destinatário.

De que componentes é composto o Cosmos SDK?

Uma aplicação típica do Cosmos SDK é composta por BaseApp, módulos e uma camada onde tudo é combinado e configurado. Em conjunto, estes componentes formam uma única máquina de estados que os operadores de nodes executam.

A BaseApp é a ligação entre o CometBFT e a aplicação. Trata da ligação ABCI, encaminha messages e queries, executa transacções e gere o multistore.

Os módulos contêm a verdadeira lógica de negócio. Cada módulo pode ter o seu próprio state, messages, funções de query e regras. Uma cadeia escolhe por si própria que módulos inclui. Depois, estes são combinados com eventuais módulos próprios.

Essa combinação é normalmente feita em app.go. Aí, o programador cria a BaseApp, define os espaços de armazenamento, inicializa componentes e determina como os módulos trabalham entre si. O binário do node inicia então tanto o node de consenso como a aplicação SDK.

Os módulos usam normalmente um keeper para aceder ao seu state. Um keeper pode ser visto como uma porta de acesso controlada aos dados armazenados. Nem todos os módulos podem alterar tudo livremente. Um módulo recebe apenas os direitos e interfaces que a aplicação lhe transmite de forma deliberada.

O ModuleManager acompanha quais os módulos activos e trata, entre outras coisas, do arranque no genesis, das actualizações e da ordem dos hooks nas fronteiras dos blocos. Genesis é o ponto de partida de uma blockchain: o primeiro state com que a rede começa.

Os Protocol Buffers também desempenham um papel importante. Trata-se de uma forma de descrever dados e serviços de maneira clara. Messages, serviços de query, tipos de state e tipos de genesis são definidos com isto, após o que são gerados código Go e stubs gRPC para a aplicação.

Que módulos oferece o Cosmos SDK?

O Cosmos SDK oferece muitos módulos que uma cadeia pode escolher e combinar. Nenhuma cadeia precisa de usar todos os módulos. É precisamente essa escolha que determina o que a blockchain específica pode e não pode fazer.

Alguns módulos muito usados são:

• x/auth: trata dos tipos básicos de conta e transacção. Este módulo ajuda, entre outras coisas, nas verificações de assinaturas e nonces de conta.
• x/bank: gere saldos de vários tokens, transferências de tokens e a oferta total de tokens.
• x/staking: trata de validadores e delegações numa configuração proof-of-stake.
• x/gov: permite propostas e votações on-chain.
• x/distribution: distribui recompensas de staking.
• x/slashing: pode aplicar sanções quando os validadores não cumprem as regras.
• x/mint: suporta a emissão de tokens de acordo com as regras da cadeia.
• x/evidence: processa provas de má conduta de validadores.
• x/upgrade: ajuda uma cadeia a executar actualizações de software de forma coordenada.

Além disso, existem módulos para tarefas específicas. Por exemplo, x/authz pode tratar de autorizações delegadas para messages e x/feegrant pode permitir que outra conta pague as fees de um utilizador. x/consensus permite a gestão de determinados parâmetros de consenso do CometBFT na cadeia. x/circuit pode funcionar como um circuit breaker para pausar temporariamente determinadas messages.

A funcionalidade IBC é normalmente adicionada através de ibc-go. Esta é a implementação IBC habitual para cadeias Cosmos SDK, mas é mantida como um projecto separado.

Um programador pode adaptar módulos padrão, substituir componentes ou construir módulos próprios. Uma cadeia com apenas funções básicas tem, por isso, um aspecto muito diferente de uma cadeia com gestão de validadores, governance e regras de permissões extensas.

Como funcionam as aplicações Cosmos SDK?

Uma aplicação Cosmos SDK funciona porque um programador compõe, regista e dota de direitos adequados os módulos de forma deliberada. Portanto, importar apenas um pacote Go não é suficiente para fazer um módulo funcionar numa cadeia.

Em app.go, a aplicação é construída. Aí são registadas store keys, criados keepers, adicionados módulos ao ModuleManager e associadas services. O programador também determina a ordem pela qual os hooks são executados nas fronteiras dos blocos. Essa ordem pode ser importante, porque um módulo pode depender de acções de outro módulo.

Um módulo contém normalmente quatro componentes práticos:

• Um keeper: para acesso controlado ao seu próprio state.
• Um serviço Msg: para acções que alteram o state, como uma transferência ou delegação.
• Um serviço de query: para perguntas apenas de leitura, como consultar um saldo.
• Uma implementação AppModule: para que o módulo trabalhe correctamente com o ModuleManager.

Quando chega uma transacção, a BaseApp encaminha cada message com base no tipo para o MsgServer do módulo certo. O módulo verifica então se o remetente está autorizado e se a acção cumpre as regras de negócio. Depois, o módulo usa o keeper para alterar o state.

As queries seguem um caminho diferente. Através do gRPCQueryRouter, chegam ao serviço de query do módulo certo. Uma query lê o state armazenado e confirmado e não altera nada. Pense na diferença entre ver o saldo da sua conta bancária e efectuar um pagamento.

Os módulos também podem ter lógica para genesis, actualizações e fronteiras de blocos. Numa actualização, podem ser necessárias migrações de state, para que os dados antigos se ajustem correctamente ao novo código. Isso exige planeamento cuidadoso e testes por parte do programador da cadeia.

O que é o Cosmos EVM?

Uma blockchain Cosmos SDK também pode ser tornada compatível com a Ethereum Virtual Machine (EVM). Para isso existe o Cosmos EVM, que permite integrar a funcionalidade EVM como parte de uma aplicação Cosmos SDK. Assim, um projecto pode construir uma blockchain Layer 1 própria que, ao mesmo tempo, consegue executar smart contracts Ethereum.

O núcleo disto é o módulo x/vm. Este adiciona um ambiente de execução EVM à blockchain, para que os programadores possam usar smart contracts Solidity e trabalhar com ferramentas Ethereum conhecidas, como MetaMask, Hardhat e Foundry. Entretanto, a blockchain continua a ser uma cadeia Cosmos SDK autónoma, com regras e configuração próprias.

O Cosmos EVM também pode, através de precompiles, dar acesso a outros componentes do Cosmos SDK. Um smart contract pode, por exemplo, comunicar com funcionalidades de staking, governance ou IBC. Quais os precompiles disponíveis é configurado pelos programadores da blockchain.

O Cosmos EVM não é um componente obrigatório do Cosmos SDK. Um programador pode construir uma cadeia Cosmos SDK sem EVM ou adicionar deliberadamente funcionalidade EVM quando a compatibilidade com aplicações e ferramentas Ethereum é desejada.

Para que é usado o Cosmos SDK?

O Cosmos SDK é usado para construir blockchains e livros-razão digitais específicos para aplicações, quando um projecto quer definir por si próprio as regras da cadeia. Assim, um projecto pode conceber uma blockchain Layer 1 autónoma em vez de construir apenas uma aplicação ou smart contract numa blockchain existente. Isto é especialmente útil quando as regras padrão de uma blockchain geral existente não oferecem espaço suficiente.

Um projecto pode, por exemplo, definir ao nível do protocolo regras para tokenização, transferências de tokens, gestão de validadores em proof-of-stake, governance, autorizações e fee-allowances. Também a lógica de conformidade ou de permissões pode fazer parte das regras da cadeia.

O SDK pode ser utilizado para redes públicas, redes privadas permissioned e redes de consórcio. Numa rede pública, em princípio qualquer pessoa pode participar de acordo com as regras abertas. Numa rede permissioned, pelo contrário, podem receber direitos apenas participantes ou validadores previamente definidos.

Isso torna o SDK útil para situações em que uma organização ou grupo não quer apenas construir uma dApp ou smart contracts numa blockchain existente, mas precisa de um ambiente Layer 1 próprio, com as suas próprias transições de state e regras da cadeia.

Exemplos de possíveis aplicações são redes interbancárias, tokenização de activos e automatização empresarial. Se uma cadeia própria é adequada depende, no entanto, dos requisitos concretos. Uma cadeia própria exige, além de código, gestão, monitorização, actualizações, governance e um modelo de segurança adequado.

Qual é a relação entre o Cosmos SDK, o Cosmos Hub e o IBC?

O Cosmos SDK é o framework de construção, o IBC é o protocolo de comunicação entre blockchains e o Cosmos Hub é uma blockchain pública proof-of-stake específica. Estes três elementos estão relacionados, mas não são a mesma coisa.

O Cosmos Hub executa a aplicação Gaia. A Gaia foi construída como uma aplicação Cosmos SDK e usa ibc-go para IBC. ATOM é o token nativo de staking do Cosmos Hub.

IBC significa Inter-Blockchain Communication. É um protocolo aberto que permite às blockchains enviar dados verificados umas às outras. Esses dados podem consistir em tokens, messages ou lógica de aplicação.

Então como sabe uma cadeia que a informação de outra cadeia está correcta? O IBC usa, entre outros elementos, clients, muitas vezes chamados light clients, para verificar o state da contraparte. Depois disso, o IBC pode enviar, confirmar ou deixar expirar packets de forma comprovável. Um packet é, neste contexto, um pacote de dados que passa de uma cadeia para outra.

O Cosmos SDK tem uma ligação estreita com o IBC através de ibc-go, mas o IBC tem de ser realmente incorporado na cadeia. Um programador tem de, entre outras coisas, adicionar IBC keepers e armazenamento, configurar um IBC router com rotas e registar módulos relevantes.

Depois disso, para haver comunicação real, também é necessária uma contraparte adequada, além de um canal IBC e relaying. Relayers são processos que transmitem mensagens IBC entre cadeias. Estes não decidem por si próprios que dados são válidos, porque as cadeias verificam esses dados de acordo com as regras do IBC.

O Cosmos Hub pode comunicar via IBC com outras cadeias adequadas, mas não é uma camada intermédia central obrigatória. Duas cadeias IBC bem configuradas podem comunicar directamente entre si através dos seus próprios clients, connections e channels.

O IBC também não é exclusivo das cadeias Cosmos SDK. O SDK torna a integração sobretudo prática para as cadeias construídas com ele.

Quais são as vantagens e limitações do Cosmos SDK?

A maior força do Cosmos SDK é a personalização. Os programadores podem usar apenas os módulos necessários, adaptar o comportamento padrão e adicionar lógica própria. Assim, as regras de uma cadeia podem ser concebidas directamente ao nível do protocolo.

A separação entre lógica de aplicação, ABCI e consenso também é útil. Quem usa o CometBFT não precisa de construir de raiz toda a camada habitual de consenso e peer-to-peer. Isso permite ao programador concentrar-se mais no que a cadeia deve fazer.

Outras vantagens são:

• Blocos de construção reutilizáveis: os módulos oferecem funções para contas, tokens, staking, governance, actualizações e autorização.
• Acesso controlado: os keepers limitam que state um módulo pode ler ou alterar de outros módulos.
• Interoperabilidade via IBC: cadeias IBC correctamente integradas podem trocar dados verificados sem uma parte intermediária central.
• Modelos de rede flexíveis: o SDK pode ser usado para redes públicas, privadas e de consórcio.

Essa liberdade também traz responsabilidade. Um programador tem de conceber correctamente módulos, keepers, permissões, parâmetros e a ordem dos hooks. As migrações de state em actualizações e a gestão de dependências também exigem atenção. O SDK está em grande parte estabilizado, mas ainda pode conter breaking changes. Por isso, uma actualização deve ser bem planeada e testada.

Na prática, o conhecimento de Go é importante, porque as aplicações SDK são binários Go e o Go é necessário para construir e executar um node. Isso pode ser uma barreira para equipas que trabalham sobretudo com outras linguagens de programação.

O IBC torna a interoperabilidade possível, mas não automaticamente. Uma cadeia tem de integrar e configurar bem o IBC. Além disso, são necessários uma contraparte compatível, um canal funcional e relayers operacionais.

Por fim, o SDK não elimina toda a responsabilidade operacional e de segurança. Uma cadeia autónoma tem de executar por si própria um modelo adequado para validadores e stake, ou para regras de validadores permissioned. A segurança depende também do código dos módulos próprios, da configuração, da gestão de chaves, das actualizações, da infraestrutura e da forma como a rede é gerida.

Conclusão

O Cosmos SDK é um framework flexível para equipas que querem construir a sua própria blockchain com regras próprias. Em vez de colocar apenas lógica dentro de uma cadeia existente, um projecto pode definir por si próprio como funcionam as transacções, o state, a governance, as permissões e outros processos.

A estrutura modular permite combinar componentes existentes para, por exemplo, tokens, staking e governance com código próprio. Um projecto pode ainda, por exemplo, integrar o Cosmos EVM quando quer combinar a sua própria blockchain com suporte para smart contracts e ferramentas Ethereum. O CometBFT trata, em regra, do consenso e da camada de rede, enquanto a BaseApp e os módulos executam a lógica de aplicação.

O IBC pode ligar uma cadeia Cosmos SDK a outras cadeias correctamente integradas, mas essa ligação exige uma configuração técnica deliberada. O mesmo se aplica à própria chain: flexibilidade também significa que os programadores continuam responsáveis pelo design, pelas actualizações, pela operação e pela segurança.

Em suma, o Cosmos SDK é sobretudo interessante quando um projecto não quer apenas construir uma aplicação, mas moldar as regras da própria blockchain subjacente.