Programação em blockchain: contratos que não têm volta

Programar em blockchain é, na prática, escrever contratos inteligentes: programas que ficam publicados em uma rede e executam sozinhos quando as condições que você definiu acontecem. Não há servidor para reiniciar, nem versão nova para subir na semana seguinte.

Essa diferença não é um detalhe: ela muda o que significa programar. Três restrições que não existem em nenhum outro tipo de software definem o trabalho, e é por elas que este guia começa.

As três restrições que mudam tudo

• O código é imutável depois de publicado. Um erro em uma aplicação comum vira correção na próxima versão. Em um contrato já na rede, o erro fica lá. Só é possível atualizar quem previu isso desde o início, publicando o contrato atrás de um intermediário que aponta para uma nova versão, o chamado padrão de proxy. Quem não previu precisa publicar um contrato novo e convencer todo mundo a migrar.
• Cada execução custa dinheiro. Toda operação que altera o estado da rede consome taxa, paga por quem executa. Isso inverte uma prioridade inteira do desenvolvimento: aqui, escrever código eficiente não é elegância, é redução de custo direto para o usuário. Um laço mal escrito não deixa o sistema lento, deixa a transação cara ou impossível.
• O código é público e o dado também. Qualquer pessoa lê o contrato publicado e o histórico completo de quem interagiu com ele. Não existe “ninguém vai ver essa parte”. Isso vale como transparência e como risco: quem procura falhas tem acesso ao mesmo código que você.

As três juntas explicam por que o desenvolvimento nessa área gasta muito mais tempo em teste e revisão que em escrita, proporção que assusta quem vem do desenvolvimento web. O funcionamento da rede por baixo disso está em o que é blockchain e como funciona.

O fluxo real de desenvolvimento

O caminho de um contrato, do editor até a rede principal:

1. Escrever. O contrato em si, geralmente usando bibliotecas já auditadas como base em vez de implementar do zero.
2. Testar localmente. Em uma rede simulada na própria máquina, com cobertura alta. Aqui os testes não são higiene, são a única proteção real antes do custo ficar irreversível.
3. Publicar em rede de teste. Uma rede pública que funciona igual à principal, mas com moeda sem valor. É onde a integração com carteira e interface é validada.
4. Revisar e auditar. Revisão por outra pessoa no mínimo; auditoria externa quando há valor relevante em jogo. É o item que mais é cortado do orçamento e o que mais causa prejuízo quando falta.
5. Publicar na rede principal. A operação que custa taxa real e não tem volta.
6. Verificar o código publicado. Enviar o código-fonte para um explorador de blocos, que confirma que ele corresponde ao que está rodando. Sem isso, ninguém consegue conferir o que assinou.

As ferramentas que se usa de verdade

• Remix. Ambiente de desenvolvimento que roda no navegador, sem instalar nada. É onde quase todo mundo escreve o primeiro contrato.
• Hardhat. Estrutura de projeto em JavaScript e TypeScript, com rede local, testes e scripts de publicação. É a opção mais comum em times que já vêm do desenvolvimento web.
• Foundry. Alternativa mais recente, com testes escritos na própria linguagem dos contratos e execução rápida. Ganhou espaço entre quem faz trabalho pesado de teste.
• OpenZeppelin. Biblioteca de contratos já auditados para padrões comuns, como tokens e controle de permissão. Usar o que já foi revisado por muita gente é a decisão de segurança mais barata disponível.
• Carteira. Uma extensão de navegador que guarda as chaves e assina as transações, tanto no desenvolvimento quanto pelo usuário final.
• Explorador de blocos. Onde se acompanha transações, se lê o estado do contrato e se publica o código-fonte para verificação.

Vale um aviso de manutenção: o Truffle, que por anos foi a ferramenta padrão da categoria e ainda aparece na maior parte dos tutoriais em português, teve o suporte encerrado. Tutorial que começa por ele está desatualizado, e isso é um bom teste para avaliar a idade de qualquer material sobre o assunto.

As linguagens, e o mal-entendido do JavaScript

• Solidity. A linguagem dominante para contratos no Ethereum e nas redes compatíveis com ele, que são a maioria. É onde estão a documentação, as bibliotecas e as ferramentas de análise.
• Vyper. Alternativa deliberadamente restrita, que remove recursos capazes de gerar erro sutil. Ecossistema menor, e escolha de quem prioriza auditabilidade.
• Rust. A linguagem de contratos em Solana, Polkadot e Near, além de ser usada para construir a própria rede. A verificação de memória feita na compilação vale mais aqui do que em qualquer outro contexto.
• Go e C++. Usadas para construir os programas que formam a rede, não os contratos que rodam nela. C++ é a base do Bitcoin Core; Go, de um dos principais clientes do Ethereum.

Onde entra o JavaScript. É comum ver JavaScript listado como linguagem de contratos inteligentes, e isso é impreciso. Nas redes relevantes, o JavaScript não roda dentro da blockchain: ele roda na aplicação que conversa com ela, usando bibliotecas que leem o estado do contrato e enviam transações a partir do navegador. É uma peça indispensável de qualquer aplicação descentralizada, mas está do lado de fora da rede. O panorama completo está em linguagens de programação: 15 principais e como escolher.

Os erros que custam dinheiro

Esta lista é curta porque poucos erros respondem pela maior parte dos prejuízos conhecidos:

• Reentrância. O contrato chama outro contrato antes de atualizar o próprio estado, e o chamado volta a entrar na função para repetir a operação. É a falha do ataque mais famoso da história do Ethereum, e continua aparecendo.
• Controle de permissão frouxo. Funções críticas sem verificação de quem pode chamá-las. Simples, comum e devastador.
• Confiar em dado externo sem validação. Contratos que leem preço ou informação de fora dependem de uma fonte, e manipular essa fonte é o caminho mais direto para explorar o contrato.
• Chave privada no repositório. Não é falha do contrato, é a causa mais banal de perda de fundos. Uma chave que chegou ao histórico do repositório deve ser considerada comprometida para sempre.
• Publicar sem plano de atualização. Descobrir que o contrato precisa mudar depois de publicado, sem ter previsto o mecanismo, é o erro que transforma um ajuste pequeno em migração de toda a base de usuários.

Onde publicar: as redes e o que muda entre elas

A escolha da rede é uma decisão de produto, e não apenas técnica. O que varia entre elas:

• Custo por transação. Diferença de ordens de grandeza entre a rede principal do Ethereum e as redes construídas sobre ela ou alternativas a ela. Isso decide se o seu caso de uso é viável.
• Ferramental e comunidade. Redes compatíveis com o Ethereum aproveitam todo o acervo existente. Sair dessa compatibilidade significa menos bibliotecas prontas e menos gente disponível.
• Onde estão os usuários. Um contrato só vale onde há quem interaja com ele. Publicar em uma rede sem público é o equivalente a lançar um site sem endereço.

Para a leitura de negócio dessa escolha, incluindo os casos em que blockchain não é a resposta, veja blockchain nos negócios: onde funciona e onde falhou.

Por onde começar

Um caminho realista para quem já programa: escrever o primeiro contrato no ambiente de navegador, sem instalar nada; publicá-lo em uma rede de teste e interagir com ele por uma carteira; montar um projeto local com testes automatizados; e só então construir uma interface que converse com o contrato. Quem não programa ainda precisa de uma base de lógica e de uma linguagem antes disso, e Solidity não é um bom primeiro contato com programação.

A fonte que importa é a documentação oficial da rede escolhida, que é atualizada junto com as mudanças e não envelhece como tutorial de terceiro. Cursos ajudam na estrutura, mas verifique a data e as ferramentas usadas antes de investir tempo: material dessa área desatualiza em cerca de dois anos.

E antes do código, vale a pergunta que antecede qualquer construção: o que exatamente vai ser feito e para quem. O corte dessa etapa está em como definir o escopo do primeiro produto digital.

Perguntas frequentes