Ir para o conteúdo
Financial Context Wiki

Como verificar um endereço de contrato CREATE2

CREATE2 prevê um endereço a partir do deployer, do salt e do hash do código de inicialização, mas a verificação ainda exige evidências específicas da cadeia sobre fábrica, bytecode, implantação, proxy e controle.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento ou de segurança. Um endereço previsto, uma conta vazia, um checksum ou um rótulo de fábrica não provam implantação, código, controle, propriedade ou segurança.

Resposta direta

CREATE2 prevê o endereço criado por um contrato deployer específico a partir de um 32-byte salt e do hash do seu init_code exato. A fórmula do protocolo é address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: calcula o hash de um 85-byte preimage e mantém os últimos 20 bytes. O deployer é a fábrica que executa CREATE2, não necessariamente a carteira que chamou a fábrica.

init_code é o bytecode de criação mais os argumentos do construtor codificados em ABI; ele é executado uma vez e produz o bytecode de execução. A versão do compilador, a otimização, as bibliotecas vinculadas, os metadados, os argumentos do construtor ou o ponto de entrada da fábrica podem alterar o hash. O código de execução é uma saída, não a entrada do CREATE2. O mesmo endereço só é comparável com o mesmo deployer, salt, código de inicialização, regras da EVM e estado da cadeia.

Um endereço contrafactual pode receber fundos antes de existir código, mas ainda não tem lógica de controle verificada. A previsão não prova implantação, propriedade, autorização, finalidade ou segurança. Verifique o bytecode e o calldata da fábrica, o recibo e os eventos, eth_getCode, nonce, armazenamento, saldo, implementação do proxy, inicializador e proprietário na cadeia e no bloco pretendidos.

Como funciona

Fixe a cadeia ou o domínio, as regras do fork, RPC e bloco, o endereço da fábrica e o hash do runtime, o salt bruto, os bytes exatos do init, a codificação do construtor, o compilador e as bibliotecas vinculadas. Recalcule keccak256(init_code) e o 85-byte preimage; normalize o preenchimento ABI, o endianess, o checksum e a extração dos últimos 20 bytes.

Depois decodifique a chamada e o valor enviados à fábrica. Confirme que a fábrica, o ponto de entrada, o domínio do salt, o construtor, o proprietário e o inicializador pretendidos estão vinculados. Para um proxy mínimo, faça o hash do bytecode de criação do clone que contém o endereço da implementação, não do runtime da implementação. Para um proxy, verifique separadamente a implementação, o administrador, os slots de armazenamento e a política de atualização.

O EIP-684 faz a criação reverter quando o nonce de destino não é zero ou o código não está vazio. Um construtor que falha também não deixa uma implantação válida. As suposições sobre SELFDESTRUCT e uma nova implantação dependem das regras do fork; nunca confie na antiga afirmação de que o código pode ser sempre substituído à vontade.

A evidência da implantação tem camadas: inclusão e status da transação, eventos emitidos, código e nonce, armazenamento e saldos, e depois um estado seguro ou finalizado. Uma resposta RPC bem-sucedida ou um checksum previsto não substitui a verificação do recibo e do estado. Cópias do mesmo endereço em cadeias diferentes podem ter código, proprietários, armazenamento e ativos diferentes.

Use este fluxo:

  1. Fixe cadeia, fork, RPC e bloco; endereço da fábrica ou deployer e hash do runtime; bytes do salt; código init, argumentos do construtor, compilador e bibliotecas vinculadas.
  2. Calcule o hash do código init e o preimagem CREATE2 exato, conferindo larguras, preenchimento, 0xff, os últimos 20 bytes e o checksum.
  3. Decodifique o calldata e o valor da fábrica; compare o endereço previsto, proprietário, inicializador, destino do proxy e permissões pretendidas.
  4. Verifique recibo, status, eventos, eth_getCode, nonce, saldo e armazenamento na cadeia correta; registre estados não implantado e de colisão.
  5. Inspecione fábrica, proxy, implementação, administrador, inicializador, atualização e premissas da Singleton Factory, incluindo destinos ERC-1167.
  6. Teste falha do construtor, colisão por nonce/código, nova implantação sensível ao fork, fábricas aninhadas e premissas de domínio de cadeia ou replay.
  7. Antes de financiar ou assinar, reconcilie valores humanos e brutos; depois da implantação, monitore hash do código, proprietário, implementação, funções, eventos e finalidade.

Exemplos

  • Vetor EIP-1014: deployer 0x0000000000000000000000000000000000000000, salt zero, init 0x00 produz 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Vínculo do construtor: com deployer e salt fixos, alterar um argumento do construtor codificado em ABI altera keccak256(init_code) e, portanto, o endereço previsto; fazer hash do runtime verificaria o objeto errado.
  • Colisão: se o nonce de destino for maior que 0 ou o código não estiver vazio, CREATE2 deve reverter conforme o EIP-684. Um endereço financiado com código vazio e nonce zero é apenas contrafactual e continua sem verificação.
  • Proxy mínimo: o endereço de um clone ERC-1167 faz hash do bytecode de criação do clone que contém o endereço da implementação. Fazer hash do runtime da implementação gera uma previsão diferente.

Riscos

  • É usada a fábrica ou o deployer errado.
  • A largura, o preenchimento, o endianess ou o domínio do salt estão errados.
  • O código init é confundido com o bytecode de execução.
  • Os argumentos do construtor são omitidos ou reordenados.
  • O ponto de entrada, o valor ou o calldata da fábrica diferem.
  • O proxy ou destino delegatecall não é a implementação pretendida.
  • A cadeia, o fork ou o domínio EVM diferem.
  • O nonce existente causa uma colisão.
  • O código existente causa uma colisão.
  • São usadas premissas obsoletas sobre nova implantação após SELFDESTRUCT.
  • CREATE2 aninhado muda o deployer efetivo.
  • As fórmulas CREATE e CREATE2 são misturadas.
  • O destino da implementação ERC-1167 não é verificado.
  • O endereço ou as premissas da Singleton Factory não são verificados.
  • Uma atualização ou um administrador da implementação muda o comportamento.
  • O compilador, os metadados, a biblioteca ou o artefato-fonte diferem.
  • Recibo, mempool, falha e estados finalizados são confundidos.
  • Um checksum ou envenenamento da interface esconde o endereço errado.
  • Fundos pré-carregados não têm prova de propriedade da conta contrafactual.
  • Premissas sobre EIP-7702, replay, gás, negação de serviço ou monitoramento obsoleto estão erradas.

Equívocos comuns

  • “Uma conta vazia é segura ou tem proprietário.” Ela pode não ter código nem controlador verificado.
  • “O salt sozinho determina o endereço.” O deployer e o hash do código init também são vinculantes.
  • “CREATE2 faz hash do bytecode de execução.” Ele faz hash do código de criação, incluindo os argumentos do construtor.
  • “O mesmo endereço em duas cadeias significa o mesmo código e controle.” O estado e as implantações de cada cadeia precisam ser verificados separadamente.
  • “Uma previsão bem-sucedida prova implantação e segurança.” Apenas recibo, código, estado, permissões e finalidade estabelecem o que existe.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...