O que é um contrato inteligente? Código, estado e funções no Ethereum

Um contrato inteligente é um programa que funciona na blockchain do Ethereum. Ele reúne código e dados em um endereço específico da rede. O código define funções; os dados formam o chamado estado do contrato. Esses três elementos — código, estado e endereço — ajudam a entender o que é um smart contract de maneira concreta.

Para compreender a interação com esse programa, acrescente um quarto elemento: a chamada de uma função por meio de uma transação. Este guia explica essa relação, a diferença entre contas controladas por chaves privadas e contas controladas por código, além do limite para obter informações de fora da blockchain.

Código, estado e endereço: a estrutura básica

A introdução aos contratos inteligentes do Ethereum descreve um contrato como um conjunto de código e dados localizado em um endereço específico. Cada parte responde a uma pergunta diferente:

• Código: quais funções o programa define?
• Estado: quais dados fazem parte do contrato?
• Endereço: de qual contrato estamos falando?

Nesse contexto, estado é um termo técnico para os dados do contrato. Em um programa inventado para uma aula, por exemplo, uma variável chamada contador poderia fazer parte do estado. O nome identifica a variável do exercício, mas não informa seu valor inicial nem quais operações a afetam.

As funções pertencem ao código. Seus nomes ajudam a apresentar o programa, mas, isoladamente, não explicam seu comportamento. Para compreender um contrato específico, é preciso conhecer as funções e os dados envolvidos, em vez de deduzir tudo a partir dos nomes escolhidos.

Dessa estrutura decorre uma conclusão limitada: o endereço identifica o contrato em discussão, enquanto código e estado descrevem aspectos diferentes dele. Portanto, informar apenas um endereço deixa seu funcionamento sem explicação. Essa é uma dedução a partir da definição, não uma garantia sobre qualquer endereço apresentado ao leitor.

Quem controla uma EOA e uma conta de contrato?

A documentação de contas do Ethereum distingue a conta controlada externamente, conhecida pela sigla EOA, da conta de contrato. Uma EOA é controlada por quem possui suas chaves privadas. Já uma conta de contrato é controlada pelo código do contrato inteligente.

É importante manter claro o sujeito de cada afirmação. A descrição da EOA apresenta um modelo de controle por chaves privadas. A descrição da conta de contrato aponta o código como lógica de controle. Essas definições, por si só, não avaliam a segurança de uma conta ou de um programa específico.

Controle por código também não significa ausência de interação humana. A documentação descreve tanto o controle do contrato pelo programa quanto a interação de contas de usuários com suas funções. São perguntas diferentes: qual conta faz a solicitação e qual código rege o comportamento do contrato?

Ao ler uma explicação, experimente substituir a expressão genérica “a conta” por “a EOA remetente” ou “a conta de contrato”, conforme o caso. Esse cuidado ajuda a acompanhar os participantes sem presumir que todas as contas do Ethereum funcionam da mesma maneira.

O que significa chamar uma função do contrato

Contas de usuários podem interagir com contratos inteligentes enviando transações que chamam funções definidas nesses contratos. Para entender esse mecanismo, concentre-se na relação entre a conta do usuário, o contrato escolhido e a função chamada.

Três perguntas ajudam a organizar a leitura:

1. Qual conta de usuário está fazendo a solicitação?
2. A qual endereço de contrato a solicitação se dirige?
3. Qual função definida no contrato está sendo chamada?

Essas perguntas identificam a interação. Elas não estabelecem, por si só, execução bem-sucedida nem um valor resultante para os dados do contrato. A conclusão deve acompanhar o alcance da informação disponível: dizer que alguém enviou uma transação não basta para demonstrar um resultado específico.

A sequência das transações é outro assunto. Caso você encontre o termo nonce ao continuar os estudos, o guia sobre nonce de conta no Ethereum e sequência de transações oferece uma leitura complementar. Aqui, o foco permanece na relação entre a transação e a função definida pelo contrato.

Exemplo hipotético: um contrato com um contador

Imagine um contrato inventado exclusivamente para um exercício de leitura. Vamos estabelecer que ele contém uma variável de estado chamada contador e uma função chamada registrarVisita. Esses nomes pertencem ao exemplo hipotético e não representam um contrato real.

Organize as informações em três linhas:

• Contrato: o programa hipotético em um endereço Ethereum não especificado.
• Estado: uma variável chamada contador.
• Função: uma função definida com o nome registrarVisita.

Agora imagine que uma conta de usuário envie uma transação para chamar registrarVisita. Isso conecta a estrutura do programa ao mecanismo de interação: a solicitação se refere a uma função definida naquele contrato hipotético.

O exercício para nesse ponto, sem atribuir um resultado. Não estabelecemos um valor inicial para contador, uma regra de incremento ou qualquer outra alteração dessa variável. Os nomes “contador” e “registrarVisita” não substituem uma descrição da lógica da função.

A dedução, limitada às premissas do exemplo, é que conhecer uma variável e o nome de uma função não fornece informação suficiente para calcular um valor resultante. Seria necessário acrescentar regras ao exercício para explicar mais. Deixar o valor em aberto preserva a diferença entre aquilo que foi definido e aquilo que o leitor poderia imaginar.

Por que dados externos precisam de um oráculo

Contratos inteligentes, sozinhos, não conseguem buscar dados de fontes offchain. Neste contexto, offchain significa fora da blockchain. A palavra sozinhos é essencial: essa limitação não significa que aplicações baseadas em blockchain estejam impedidas de usar informações externas.

A documentação do Ethereum descreve oráculos como ferramentas que recebem dados offchain e os disponibilizam para contratos inteligentes. Esse é o papel de fornecimento de dados. Em uma explicação, convém distinguir o contrato do mecanismo que disponibiliza a informação externa.

Como extensão também hipotética do exercício, imagine que alguém proponha usar um registro de presença mantido fora do Ethereum como informação para o contador. Essa proposta introduz uma necessidade de dados externos. Apenas mencionar a função registrarVisita não explica como o registro chegará ao contrato.

A dedução tem duas premissas: a informação proposta está fora da blockchain e o contrato não consegue buscá-la sozinho. Logo, a explicação precisa indicar como ela será disponibilizada. O papel de um oráculo no fornecimento de dados, por si só, não estabelece a exatidão ou a confiabilidade dessas informações.

Checklist para avaliar uma explicação sobre contratos inteligentes

• Identifique o programa. Mantenha a explicação vinculada ao Ethereum e ao contrato em discussão.
• Separe código e estado. Reconheça funções como parte do código e variáveis como dados, sem inventar valores iniciais.
• Esclareça o controle da conta. Diferencie o modelo de chaves privadas da EOA do controle por código da conta de contrato.
• Descreva a interação. Identifique o contrato e a função envolvidos na transação apresentada.
• Ajuste a conclusão à evidência. O envio, isoladamente, não demonstra um resultado, e o nome de uma função não explica sua lógica.
• Localize as entradas externas. Se a explicação depende de dados offchain, procure como eles são disponibilizados ao contrato.

Use esse checklist para verificar se uma explicação deixa suas premissas visíveis. As fontes sustentam os conceitos apresentados aqui; sua citação não comprova a segurança ou a correção de um contrato específico.

Material educativo preparado com auxílio de IA. O exemplo hipotético é um exercício de compreensão, sem recomendação de enviar transações ou assinar solicitações em uma carteira.