Ir para o conteúdo

Contrato inteligente

Entenda o que é um contrato inteligente, como os nós o executam, onde entram dados externos e autoridade de atualização e o que verificar antes de interagir.

Atualizado

Somente para fins educacionais; não constitui recomendação de investimento. Transações com contratos inteligentes podem causar perdas irreversíveis.

Resposta direta

Um contrato inteligente é um programa implantado em uma blockchain ou rede de execução distribuída semelhante. Ele contém código e, em muitas plataformas, estado persistente. Uma transação ou outro contrato pode chamar suas funções; os nós executam as mesmas regras e aceitam a mudança de estado resultante pelo processo de validação e consenso da rede.

“Inteligente” não significa que o programa compreenda a intenção, e “contrato” não o transforma automaticamente em um acordo juridicamente exigível. O termo descreve código capaz de impor condições específicas dentro dos recursos e dados disponíveis no ambiente de execução.

Contratos inteligentes podem:

  • manter ou transferir ativos digitais sob condições programadas;
  • registrar e atualizar o estado de uma aplicação; e
  • combinar-se com outros contratos para criar bolsas, sistemas de empréstimo, jogos, ferramentas de governança e outras aplicações on-chain.

Sua previsibilidade limita-se ao código implementado e às entradas. Um contrato pode executar exatamente como foi escrito e ainda gerar resultado indesejado por defeito, projeto malicioso, privilégios comprometidos ou dados externos incorretos.

Como funciona

Uma interação típica segue estas etapas:

  1. Desenvolvedores escrevem e testam o código-fonte, compilam quando a plataforma exige e implantam o programa resultante em uma transação.
  2. A implantação atribui ao programa um identificador ou endereço on-chain e pode inicializar seu estado e funções administrativas.
  3. Um usuário, aplicação ou outro contrato envia uma chamada com seletor de função, parâmetros e, às vezes, ativos.
  4. Cada nó validador executa a chamada conforme as mesmas regras de máquina virtual e protocolo. Se uma condição necessária falhar, a chamada pode ser revertida, mas a taxa da transação ainda pode ser cobrada.
  5. Se a chamada tiver sucesso e for incluída pela rede, as mudanças de estado e os eventos emitidos passam a integrar o registro da blockchain.

A execução só é determinística para informações disponíveis no contexto acordado. Um contrato não busca sozinho na internet o clima, um preço de mercado ou um pagamento bancário. Aplicações que precisam de fatos off-chain usam oráculo, mensagem assinada, ponte ou operador privilegiado, acrescentando pressupostos de confiança e falha além do código.

O código implantado nem sempre é o sistema inteiro. Alguns contratos são imutáveis, enquanto padrões de proxy e governança podem encaminhar chamadas a uma nova lógica ou mudar parâmetros. Portanto, além da interface visível, é preciso examinar chaves de atualização, poderes administrativos, controles de pausa, desenho do oráculo e contratos conectados.

Antes de assinar uma interação, verifique:

  • a rede e o endereço completo do contrato em uma fonte independente e confiável;
  • a função decodificada, os parâmetros, as quantidades de ativos e o destinatário;
  • as permissões de tokens ou de operador criadas pela chamada;
  • se o contrato é verificado, atualizável, está pausado ou é controlado por contas privilegiadas; e
  • se, quando viável, um pequeno teste cobre o caminho pretendido de entrada e saída.

Exemplo

Considere um contrato de custódia para um serviço digital. O comprador deposita 1,000 USDC, e o contrato registra comprador, vendedor, valor e condição de liquidação. Se o comprador aprovar a entrega, o contrato libera os fundos ao vendedor. Se a condição não for cumprida em 24 horas, o caminho programado de reembolso fica disponível.

O contrato não sabe se o serviço foi satisfatório, a menos que o desenho lhe forneça esse fato. Se a aprovação vier da chave do comprador, uma chave comprometida pode autorizar a liberação. Se um oráculo ou administrador decidir o resultado, essa parte integra o modelo de confiança. Uma falha no controle de acesso ou no tratamento do token também pode frustrar a regra de custódia. A execução automática reduz parte do trabalho manual, mas não elimina a avaliação de cada dependência.

Riscos e controles

  • Defeitos de código: reentrância, contabilidade incorreta, chamadas externas inseguras ou casos extremos podem perder ou bloquear ativos. Prefira projetos pequenos e bem testados e analise o código implantado, não apenas um selo de auditoria.
  • Risco de privilégios e atualização: um administrador pode pausar o sistema, substituir a lógica, mudar taxas ou mover ativos. Confira quem controla cada função, se há timelock ou múltiplas assinaturas e o que pode mudar.
  • Risco de oráculo e integração: código correto pode agir sobre dados desatualizados, manipulados ou com escala errada, e falhas em tokens, pontes ou outros contratos podem se propagar pela composição.
  • Risco de transação e autorização: uma interface maliciosa pode mostrar endereço, função, destinatário ou permissão ilimitada errados. Decodifique a solicitação e limite as permissões ao escopo necessário.
  • Risco do desenho econômico: transações válidas ainda podem provocar liquidação, manipulação de preços, falha de incentivos ou corrida sobre liquidez limitada. Código correto não equivale a solvência econômica.
  • Risco operacional: congestionamento, reorganizações da cadeia, indisponibilidade do sequenciador ou da interface podem atrasar uma ação mesmo com o contrato implantado.
  • Irreversibilidade: transações em cadeias públicas geralmente não têm estorno. Se os fundos forem enviados por uma função errada ou a um contrato hostil, recuperá-los pode ser impossível.

Uma auditoria é evidência sobre uma versão e um escopo definidos, não uma garantia. Verifique se o bytecode implantado ou o código-fonte verificado corresponde à versão analisada e se atualizações, dependências ou configurações posteriores ficaram fora do escopo.

Equívocos comuns

  • “O código executa automaticamente sem transação.” A maioria das funções que altera estado precisa de uma transação ou outra chamada on-chain; ações baseadas em tempo podem exigir um executor externo.
  • “O código não pode mudar.” Um contrato imutável não reescreve seu bytecode implantado, mas proxies, governança e migrações podem mudar a lógica alcançada pelos usuários.
  • “Código público é código seguro.” A visibilidade ajuda a revisão, mas não prova correção, administração honesta nem economia sólida.
  • “Uma auditoria garante segurança.” Revisões têm limites de tempo e escopo, podem deixar passar defeitos ou excluir riscos operacionais e econômicos.
  • “Uma transação bem-sucedida significa que a ação pretendida ocorreu.” Sucesso só indica que o código chamado não foi revertido; ainda é preciso verificar destino, eventos decodificados, movimentos de ativos e permissões resultantes.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...