O Que É um Contrato Inteligente, e O Que Pode Dar Errado?

Contrato inteligente é um dos termos mais enganosos do universo cripto, porque toma emprestada uma palavra jurídica para algo que não é, estritamente falando, um contrato. É um programa armazenado em uma blockchain que roda automaticamente quando certas condições são atendidas, sem um banco, corretora, ou tribunal no meio do processo. Essa automação é o atrativo, e também é a origem da maior parte do risco. Este guia explica o que um contrato inteligente realmente faz, onde a ideia é usada na prática, e as principais categorias de coisas que dão errado quando o código não se comporta da forma que seus autores pretendiam.

O que um contrato inteligente realmente é

Tirando o nome de lado, um contrato inteligente é um software implantado em uma blockchain, mais comumente a Ethereum ou uma rede programável semelhante. Uma vez implantado, seu código fica fixo em um endereço e tipicamente não pode ser alterado, a menos que os desenvolvedores tenham incorporado um mecanismo de atualização específico com antecedência. Qualquer pessoa pode enviar uma transação para ele, e a rede de validadores executa o código exatamente como escrito, atualizando o estado compartilhado da blockchain como resultado. Não há linha de atendimento ao cliente e, na maioria dos casos, nenhuma forma de reverter um resultado depois que ele foi confirmado.

Isso difere de um acordo tradicional de uma forma fundamental. Um contrato em papel descreve intenção em linguagem natural, e um tribunal ou árbitro interpreta essa intenção se surgir uma disputa. Um contrato inteligente não tem intérprete. Ele faz exatamente o que seu código diz, mesmo quando isso diverge fortemente do que as partes presumiam que aconteceria. A frase “o código é lei” (“the code is law”), popular nos primeiros dias da Ethereum, capta isso literalmente: o resultado é o que o programa computa, não o que alguém acredita ser justo. Na prática, essa ideia tem limites reais, que as seções posteriores deste guia abordam.

Onde contratos inteligentes realmente são usados

O conceito soa abstrato até ser vinculado a exemplos concretos. Três casos de uso respondem pela maior parte da atividade em blockchains programáveis hoje.

• Swaps em exchanges descentralizadas. Protocolos construídos sobre designs de formador de mercado automatizado permitem que usuários troquem um token por outro diretamente contra uma reserva agrupada, com a taxa de câmbio definida por uma fórmula em vez de um livro de ofertas. O contrato inteligente detém os fundos e executa a troca em uma única transação.
• Empréstimos e captação. Protocolos de empréstimo DeFi usam contratos inteligentes para aceitar garantias, emitir empréstimos, rastrear juros, e, se o valor da garantia cair demais, acionar liquidação automatizada, tudo sem um oficial de crédito revisando o pedido.
• Emissão de tokens. A maioria dos tokens além do ativo nativo de uma blockchain, incluindo a maioria dos ativos construídos sobre a Ethereum, são eles mesmos contratos inteligentes que definem oferta, regras de transferência, e registros de propriedade.

Em cada caso, o atrativo é o mesmo: as transações se liquidam automaticamente, de acordo com regras públicas que qualquer pessoa pode inspecionar com antecedência, sem exigir que os participantes confiem em uma instituição específica.

Os limites práticos de “o código é lei”

Tratar o código como palavra final soa elegante na teoria, mas encontra atrito assim que o código diverge do que as pessoas pretendiam. Um exemplo amplamente citado é o colapso em 2016 de um projeto chamado The DAO, no qual um atacante explorou uma falha na lógica do contrato para sacar uma grande parte dos fundos agrupados usando funções que, tecnicamente, operavam exatamente como escritas. A resposta da comunidade Ethereum, uma divisão contenciosa da rede que produziu a Ethereum e a Ethereum Classic, continua sendo uma ilustração viva de que “o código é lei” é uma filosofia de design, não uma lei da física. Quando o resultado é suficientemente perturbador, os participantes ainda podem optar por intervir no nível da rede subjacente.

Fora desses casos extremos, a tensão mais comum é mais silenciosa. Um contrato pode executar perfeitamente e ainda assim produzir um resultado que ninguém queria, porque o código não previu uma sequência específica de transações, uma condição de mercado específica, ou uma combinação específica de entradas. Geralmente não existe um processo de recurso embutido para isso.

O que pode dar errado: as principais categorias

Relatos de falhas de contratos inteligentes tendem a se encaixar em um punhado de categorias recorrentes, e distinguir entre elas importa, porque exigem tipos diferentes de escrutínio antes de confiar em um protocolo.

• Bugs e exploits. Erros no próprio código, como controles de acesso falhos, overflows de inteiro, ou lógica que permite que uma função seja chamada em uma ordem não pretendida (um padrão por trás de muitos exploits de reentrância), podem permitir que um atacante drene fundos ou cunhe tokens sem autorização. Esses são erros de programação, e uma vez que um contrato está ativo e é imutável, muitas vezes são difíceis ou impossíveis de corrigir.
• Manipulação de oráculo. Contratos inteligentes não conseguem ver fora de sua própria blockchain. Quando um contrato precisa de dados externos, como o preço de um ativo, ele depende de um serviço “oráculo” para fornecer essa informação. Se um atacante consegue distorcer o preço que um oráculo reporta, mesmo que brevemente, ele pode enganar um contrato de empréstimo ou negociação para agir com base em informação falsa, uma técnica por trás de vários prejuízos DeFi de grande repercussão.
• Risco de chave administrativa e atualização. Muitos contratos incluem uma porta dos fundos por design: uma chave de administrador ou uma carteira multisig que pode pausar o contrato, alterar parâmetros, ou atualizar o código. Essa flexibilidade ajuda equipes a corrigir bugs rapidamente, mas também significa que o sistema não é totalmente autônomo. Se essa chave é comprometida, ou se a equipe que a detém age de má-fé, os usuários enfrentam perdas que não têm relação alguma com uma falha na lógica central.
• Falhas de design econômico. Nem toda falha é um erro de programação. Um contrato pode ser implementado exatamente como pretendido e ainda assim falhar porque suas premissas econômicas estavam erradas, por exemplo uma estrutura de incentivos que funciona em condições normais mas quebra durante volatilidade extrema ou uma crise de liquidez. Essa categoria é mais difícil de auditar, porque o código não é “bugado” em sentido técnico; o modelo subjacente de como os participantes se comportariam simplesmente estava incompleto.

Auditorias, bug bounties, e seus limites

Dados esses riscos, a maioria dos projetos sérios encomenda uma auditoria de segurança de terceiros antes do lançamento, e muitos mantêm programas contínuos de bug bounty que pagam pesquisadores independentes para reportar vulnerabilidades. Ambas as práticas reduzem o risco de forma significativa. Uma auditoria realizada por uma empresa experiente tipicamente detecta padrões comuns de bugs, e um bug bounty bem financiado dá a pesquisadores white-hat um incentivo financeiro para encontrar falhas antes dos atacantes.

Nenhuma das duas é uma garantia. Uma auditoria é uma revisão do código como ele existia em um momento específico, conduzida sob restrições de tempo e orçamento, e não pode provar a ausência de toda falha possível, apenas a ausência das falhas que os revisores pensaram em procurar. Contratos que passaram por múltiplas auditorias já foram explorados, às vezes através de uma vulnerabilidade fora do escopo auditado, às vezes através de um ataque econômico em vez de um bug de código. Tratar um selo de auditoria como um certificado de segurança, em vez de uma entre várias informações, é um erro comum e custoso.

Para quem usa um protocolo construído sobre contratos inteligentes, uma linha de base razoável inclui verificar se o contrato foi auditado, por quem, há quanto tempo, se existe uma chave administrativa e quem a controla, e como o protocolo lidou com estresse no passado. Nada disso elimina o risco, mas substitui a confiança cega por um julgamento informado, que é o padrão mais realista que contratos inteligentes já puderam oferecer. Leitores que queiram construir esse hábito em todo um portfólio podem achar útil um framework de risco mais amplo, como o descrito na metodologia da roo2ya, como ponto de partida, junto com práticas gerais de pesquisa como o DYOR.

Este artigo tem fins apenas informativos e não constitui aconselhamento financeiro.