Criação de contrato no Ethereum: init code e endereço resultante

Uma transação de criação de contrato no Ethereum não tem um endereço de destino comum. Ela contém código compilado do contrato, e um contrato implantado com sucesso passa a ter seu próprio endereço. Essas afirmações descrevem partes diferentes da criação: o que a transação especifica e o que a implantação produz.

A diferença fica mais clara quando separamos três elementos: o campo de destino da transação, o código envolvido na inicialização e o campo contractAddress do recibo. Este artigo explica a relação entre eles por meio de um registro hipotético, sem depender de um procedimento de implantação. Para conhecer a estrutura geral do programa, consulte a introdução a código, estado e funções de contratos inteligentes.

Por que a transação de criação não tem um destino comum

No objeto de transação descrito pela documentação JSON-RPC do Ethereum, to normalmente identifica o destinatário. Em uma transação de criação de contrato, esse campo tem o valor null. Nesse contexto, null indica que o campo não contém um endereço de destinatário comum; null não é um endereço.

A documentação de implantação do Ethereum descreve a criação por meio de uma transação que contém código compilado do contrato, sem especificar um destinatário. Isso dá um contexto concreto à ausência de destino: a transação trata da criação, em vez de uma solicitação dirigida a um destinatário existente.

É útil separar o conceito de sua representação. Uma descrição da transação pode dizer que nenhum destinatário foi especificado, enquanto o objeto retornado pela JSON-RPC representa o destino como to: null. Leia esse campo conforme sua função documentada. Não é necessário substituí-lo mentalmente pelo endereço que aparece após a criação bem-sucedida.

Init code e código implantado representam etapas diferentes

Nesta explicação conceitual, init code designa o código envolvido na etapa de criação. Código implantado designa o código final do contrato armazenado após a criação. Essa escolha de termos é uma dedução explicativa a partir do processo documentado, e não uma especificação completa do conteúdo usado na criação.

As premissas estão na documentação de contratos do Solidity: um construtor é executado uma vez quando o contrato é criado, pode executar código de inicialização, e o código final do contrato é armazenado depois da execução do construtor. O Solidity também exclui explicitamente do código implantado o código do construtor e as funções internas chamadas apenas por ele.

Esses detalhes sustentam uma distinção útil entre o código usado durante a criação e aquele que permanece implantado. Eles não justificam tratar apenas o construtor como todo o init code, nem presumir que o conteúdo compilado da transação seja simplesmente uma cópia inalterada do código final implantado.

Imagine duas pastas em um exercício de aula: uma para o código da etapa de criação e outra para o código final implantado. Os nomes ajudam a organizar a explicação. Eles não mostram instruções individuais, a estrutura completa do conteúdo da transação ou a comparação, byte a byte, de um resultado específico do compilador. Neste nível, o ponto principal é a função diferente de cada etapa.

Onde aparece o endereço do contrato criado

Depois de implantado, um contrato tem um endereço Ethereum. No recibo de transação documentado, contractAddress informa o endereço criado quando a transação é de criação de contrato; nos demais casos, esse campo é null. Portanto, o campo de destino e o campo que informa o endereço criado precisam ser interpretados separadamente.

O hash de uma transação a identifica. Essa identificação, por si só, não comprova que a criação foi bem-sucedida nem fornece o endereço do contrato resultante. O recibo contém o campo referente ao resultado da criação discutido aqui.

O status da execução também importa. Para recibos que usam status, a documentação define 1 como sucesso e 0 como falha. Ela descreve separadamente recibos históricos anteriores ao Byzantium que usam root; a explicação de status apresentada aqui se aplica aos recibos que contêm esse campo.

Uma transação pendente não tem recibo disponível. Por isso, não se deve presumir que o registro concluído do exemplo abaixo já exista enquanto a transação estiver pendente. A ausência de recibo, isoladamente, não constitui um diagnóstico completo da situação da transação. Essas definições de campos vêm da documentação JSON-RPC do Ethereum.

Como interpretar um registro hipotético de criação

Considere um exemplo inventado para uma aula, com uma transação de criação e seu recibo correspondente. Estabelecemos como premissa que a criação foi concluída com sucesso. Usaremos os rótulos Transação T e Endereço C como marcadores: nenhum deles representa um hash ou endereço real, e nenhum cálculo de endereço está implícito.

• Identificador da transação: Transação T.
• Destino da transação: to: null.
• Dados de entrada da transação: código compilado da etapa de criação, estabelecido como premissa do exercício.
• Status do recibo correspondente: 1, indicando sucesso.
• contractAddress do recibo correspondente: Endereço C.

A dedução sustentada pelo exemplo é que o destino null é compatível com a presença do endereço criado no recibo. As premissas são a criação bem-sucedida estipulada e os significados documentados de to, status e contractAddress. O destino descreve o campo de destinatário da transação; o Endereço C descreve o resultado da criação no recibo correspondente.

Essa dedução se limita às condições apresentadas. Ela não comprova que uma transação qualquer enviada à rede tenha sido concluída com sucesso, nem especifica o valor de todos os campos do recibo após uma falha na criação. O exemplo também não fornece código real que permita analisar o comportamento do contrato hipotético.

Checklist para ler um registro de criação

Use estas perguntas ao estudar um registro de transação fornecido. Elas organizam as evidências necessárias para essa interpretação específica:

1. Qual campo você está lendo? Diferencie o campo to da transação do campo contractAddress do recibo.
2. O que o destino mostra? No objeto de transação de criação documentado, o valor esperado é null, em vez de um endereço de destinatário comum.
3. De qual etapa do código se trata? Mantenha a inicialização e o código final implantado separados, especialmente ao ler sobre o construtor.
4. Há um recibo disponível? Transações pendentes não têm recibo disponível.
5. Qual resultado as informações sustentam? Quando houver status, interprete seu valor de sucesso ou falha em conjunto com o campo do endereço criado.
6. Quais premissas permanecem? Deixe explícitos os rótulos hipotéticos, o sucesso estipulado e os detalhes ausentes.

O foco desta leitura é a relação entre a transação de criação, sua etapa de inicialização e o endereço resultante. Identificar esses elementos ajuda a acompanhar a explicação, mas não comprova a segurança ou a correção de um contrato específico.

Material educativo preparado com auxílio de IA. O registro inventado é um exercício de interpretação.