Implantação determinística (CREATE2)

O que é implantação determinística (CREATE2)?

Implantação determinística (CREATE2) é um método da Ethereum Virtual Machine que permite aos desenvolvedores calcular o endereço de um contrato inteligente antes de implantá-lo.

O método usa o opcode

da EVM, identificado pelo valor de opcode .

Um contrato implantado com CREATE2 recebe um endereço derivado do contrato que faz a implantação, de um salt escolhido pelo desenvolvedor e do hash do código de inicialização do contrato.

Isso difere da implantação convencional de contratos, em que o endereço resultante normalmente se baseia no endereço do implantador e em seu nonce.

Como CREATE2 não usa o nonce de implantação variável do implantador, os desenvolvedores podem prever o mesmo endereço mesmo que a factory tenha criado outros contratos nesse intervalo.

Essa propriedade viabiliza contas inteligentes contrafactuais, componentes previsíveis de protocolos, infraestrutura de aplicativos cross-chain, canais de estado e contratos que recebem criptomoedas antes da implantação.

A especificação final EIP-1014 CREATE2 define o opcode, a fórmula do endereço, o tratamento de gas, o comportamento em caso de colisão e a motivação original para a implantação contrafactual.

CREATE2 não torna um contrato seguro, permanente, descentralizado nem automaticamente idêntico em todas as blockchains.

Apenas fornece um método determinístico para derivar o endereço de implantação a partir de parâmetros especificados.

Por que CREATE2 é chamado de determinístico?

Um processo é determinístico quando as mesmas entradas sempre produzem a mesma saída.

No CREATE2, a saída relevante é o endereço do contrato inteligente.

As entradas relevantes são o endereço do implantador CREATE2, o salt de 32 bytes e o hash do código de inicialização.

Qualquer pessoa que conheça essas entradas pode calcular o endereço futuro sem enviar uma transação à blockchain.

O endereço não depende do momento da implantação, do número do bloco atual nem da quantidade de contratos criados anteriormente pela factory.

A alteração de qualquer entrada da fórmula do endereço produz um endereço previsto diferente.

Assim, é possível planejar, referenciar ou financiar o contrato, ou incluí-lo em mensagens assinadas, antes que seu código exista on-chain.

A fórmula do endereço CREATE2

O endereço CREATE2 é calculado com a seguinte fórmula.

O valor

é um prefixo de um byte usado para diferenciar endereços CREATE2 dos endereços criados pelo método CREATE convencional.

é o endereço de 20 bytes do contrato que executa diretamente o opcode CREATE2.

é um valor de 32 bytes fornecido à operação CREATE2.

é o código de inicialização executado durante a criação do contrato.

O código de inicialização é transformado em hash antes de ser incluído na entrada final de 85 bytes do hash CREATE2.

Os últimos 20 bytes do hash Keccak-256 resultante formam o endereço do contrato.

É possível calcular a fórmula localmente sem pagar uma taxa de rede, pois a previsão do resultado não exige alterações no estado da blockchain.

O que é o implantador CREATE2?

O implantador CREATE2 é o contrato inteligente que chama diretamente o opcode CREATE2.

Ele costuma ser chamado de factory, contrato implantador, proxy de implantação determinística ou factory singleton.

A conta de propriedade externa (EOA) que envia uma transação à factory não é automaticamente o endereço usado na fórmula CREATE2.

O endereço relevante do implantador normalmente é o da factory, pois ela executa o opcode.

O uso de uma factory diferente resulta em outro endereço previsto para o contrato, mesmo que o salt e o código de inicialização sejam idênticos.

Por isso, os desenvolvedores devem verificar o endereço exato da factory, em vez de calcular o resultado usando a carteira que envia a transação.

Uma factory pode permitir que qualquer pessoa implante qualquer código de inicialização ou restringir as implantações a contas e modelos de contrato aprovados.

As permissões e a implementação da factory podem determinar se o contrato previsto pode realmente ser implantado.

O que é um salt CREATE2?

Um salt CREATE2 é um valor arbitrário de 32 bytes incluído no cálculo determinístico do endereço.

O salt permite que uma factory implante vários contratos a partir do mesmo código de inicialização, atribuindo um endereço diferente a cada contrato.

O salt pode ser derivado de um identificador de usuário, endereço de carteira, número de conta, identificador de token, versão de aplicativo, valor aleatório ou combinação de vários campos.

O salt não precisa ser secreto.

Qualquer pessoa que conheça a factory, o salt e o código de inicialização pode calcular o mesmo endereço.

Os desenvolvedores devem definir um método claro de codificação do salt, pois diferenças na codificação podem gerar endereços inesperados.

Por exemplo, o número

, uma string de texto contendo e um valor de 32 bytes terminado em podem ser interpretados de formas diferentes pelo software.

Um projeto pode aplicar hash a dados estruturados para criar um salt fixo de 32 bytes e evitar ambiguidades de codificação.

O que é código de inicialização?

O código de inicialização, geralmente abreviado como init code, é um código temporário da EVM executado durante a criação de um contrato inteligente.

Sua função é executar a lógica do construtor e retornar o bytecode de execução que permanecerá no novo endereço.

Em geral, o próprio código de inicialização não é armazenado como código permanente do contrato.

A fórmula CREATE2 inclui o hash desse código de inicialização.

Em Solidity, o código de inicialização completo geralmente inclui o bytecode de criação do contrato e os argumentos do construtor codificados em ABI.

A documentação atual do Solidity sobre criação de contratos com salt confirma que o endereço depende do bytecode de criação e dos argumentos do construtor.

A alteração de um argumento do construtor muda o hash do código de inicialização e, portanto, muda o endereço previsto.

Para calcular um endereço CREATE2, os desenvolvedores devem usar exatamente o resultado do compilador e a codificação dos argumentos do construtor que serão usados na implantação.

Código de inicialização e bytecode de execução

O código de inicialização e o bytecode de execução estão relacionados, mas são diferentes.

O código de inicialização é executado uma vez durante a implantação.

O bytecode de execução é armazenado no endereço do contrato após a conclusão da implantação.

A fórmula do endereço CREATE2 inclui diretamente o hash do código de inicialização, não o hash final do código de execução.

Essa distinção traz uma importante consideração de segurança.

Um construtor pode ler o estado externo da blockchain e usar essas informações para decidir qual código de execução ou valores iniciais de armazenamento serão criados.

Portanto, o mesmo código de inicialização pode produzir comportamentos diferentes quando executado sob condições externas distintas.

Para garantir um compromisso mais forte sobre o comportamento, o desenvolvedor deve evitar construtores dependentes do ambiente ou verificar o código de execução e o armazenamento resultantes após a implantação.

Argumentos do construtor e CREATE2

Em implantações com Solidity, os argumentos do construtor fazem parte do código de inicialização.

Um contrato criado com o endereço de proprietário

normalmente terá um endereço CREATE2 diferente do mesmo contrato criado com o endereço de proprietário .

A mesma regra se aplica a nomes de tokens, valores de oferta, endereços de implementação, listas de validadores, configurações de taxas e outras entradas do construtor.

Os desenvolvedores devem codificar os argumentos do construtor na mesma ordem e formato esperados pela ABI do contrato.

Um preditor de endereços que omita os argumentos do construtor calculará o resultado incorreto.

Funções de inicialização chamadas após a implantação não afetam a fórmula CREATE2, a menos que a chamada de inicialização faça parte do construtor ou do processo da factory.

Separar a implantação da inicialização pode criar risco de apropriação se outra conta puder chamar primeiro uma função de inicialização desprotegida.

CREATE e CREATE2

CREATE e CREATE2 são operações da EVM usadas para criar contratos inteligentes.

O CREATE convencional deriva o novo endereço principalmente da conta que cria o contrato e de seu nonce de implantação.

O nonce aumenta à medida que o implantador cria outros contratos.

Assim, para prever um endereço CREATE, o desenvolvedor precisa conhecer a sequência correta de implantações.

O CREATE2 substitui a fórmula de endereço baseada no nonce por uma fórmula baseada no endereço da factory, no salt e no hash do código de inicialização.

O CREATE2 não altera a execução fundamental do código do construtor nem o armazenamento do bytecode de execução retornado.

Ele altera a forma como o endereço de destino é derivado e acrescenta um custo de hash para o código de inicialização.

As duas operações falham quando o endereço de destino viola as regras da EVM para colisões na criação de contratos.

Quando CREATE2 foi introduzido?

CREATE2 foi especificado na EIP-1014, em 2018.

Foi incluído na atualização de rede Constantinople do Ethereum.

A especificação da atualização Constantinople inclui a EIP-1014 entre as mudanças de protocolo implementadas.

Desde então, CREATE2 tornou-se parte consolidada da EVM e é compatível com Solidity e ferramentas de desenvolvimento amplamente usadas.

Redes compatíveis com EVM podem oferecer suporte a CREATE2 após ativarem o comportamento de protocolo correspondente.

Os desenvolvedores devem confirmar a compatibilidade da rede, em vez de presumir que todas as blockchains que usam ambientes semelhantes à EVM implementam regras idênticas.

CREATE2 em Solidity

Solidity oferece uma sintaxe de alto nível para implantar contratos por meio de CREATE2.

Uma factory pode usar a sintaxe

.

O compilador Solidity prepara o bytecode de criação, codifica os argumentos do construtor e gera a operação CREATE2.

Um construtor payable também pode receber a moeda nativa da blockchain durante a implantação usando a opção

.

A factory deve confirmar que a implantação retornou o endereço esperado, diferente de zero.

Os desenvolvedores também podem chamar CREATE2 por meio de assembly inline quando precisarem de controle direto sobre a memória e o tamanho do código de inicialização, o salt e o valor enviado.

O uso de assembly inline aumenta o risco de implementação e deve ser testado cuidadosamente.

Exemplo simplificado de CREATE2 em Solidity

Neste exemplo, o endereço previsto do contrato Child depende do endereço da factory, do salt, do bytecode de criação de Child e do argumento

codificado.

Alterar o chamador externo sem alterar essas entradas não necessariamente muda o endereço.

Alterar

muda o endereço porque o argumento do construtor faz parte do código de inicialização.

Como prever um endereço CREATE2

Um desenvolvedor pode calcular um endereço CREATE2 em um contrato inteligente, script de implantação, carteira ou aplicativo local.

O cálculo deve usar o endereço exato da factory que executará CREATE2.

Também deve usar o salt em sua representação final de 32 bytes.

O hash do código de inicialização deve incluir o bytecode de criação exato e os argumentos do construtor codificados.

O resultado deve ser comparado com o endereço retornado pela factory após a implantação.

As ferramentas de implantação devem interromper o processo se o endereço previsto e o endereço real forem diferentes.

Previsões incorretas geralmente resultam do uso do bytecode de execução em vez do bytecode de criação, da omissão dos argumentos do construtor, da escolha da factory errada ou da codificação incorreta do salt.

O que é implantação contrafactual?

Implantação contrafactual é tratar como significativo um endereço futuro de contrato inteligente antes que o código seja implantado nele.

As partes podem calcular o endereço e concordar previamente com o código de inicialização esperado para o contrato.

Elas podem enviar ativos ao endereço, incluí-lo em outro contrato ou criar autorizações assinadas relacionadas a ele.

O contrato só é implantado quando sua execução se torna necessária.

Isso pode evitar uma transação de implantação imediata e reduzir os custos iniciais de integração.

A EIP-1014 destacou originalmente interações contrafactuais em sistemas de canais de estado, nos quais um contrato talvez só seja necessário se os participantes entrarem em uma disputa.

A implantação contrafactual também é importante para carteiras de contratos inteligentes e abstração de contas.

Contas de contratos inteligentes contrafactuais

É possível prever o endereço CREATE2 de uma conta de contrato inteligente antes da implantação do contrato da conta.

O usuário pode compartilhar esse endereço e receber criptomoedas ou tokens nele.

Na primeira operação da conta, a carteira pode ser implantada e realizar uma ação como parte do mesmo processo mais amplo.

Isso pode eliminar a necessidade de o usuário concluir uma transação separada de criação da carteira antes de receber ativos.

A especificação de abstração de contas ERC-4337 permite criar uma conta de contrato inteligente emissora a partir de dados de inicialização da factory, quando a conta ainda não existe.

As factories de contas costumam usar CREATE2 para permitir que o endereço da conta emissora seja calculado antes da implantação.

Nem todo design de abstração de contas precisa usar CREATE2, pois modelos mais recentes de autorização e contas podem usar outros mecanismos.

Enviar criptomoedas a um endereço ainda não implantado

Um endereço CREATE2 ainda não implantado pode receber a criptomoeda nativa da blockchain, pois um endereço não precisa ter código de execução para manter saldo.

Tokens fungíveis e não fungíveis também podem ser transferidos para um endereço previsto quando seus contratos permitem transferências comuns entre endereços.

Os ativos permanecem associados ao endereço mesmo que ainda não exista código de contrato nele.

Eles poderão ser usados depois que o contrato pretendido for implantado com sucesso.

Esse comportamento pode simplificar a integração de carteiras e o design de aplicativos contrafactuais.

Também cria um risco sério, pois os ativos podem ficar inacessíveis se a factory, o salt ou o código de inicialização pretendidos estiverem incorretos.

Antes de enviar valores relevantes a um endereço contrafactual, os usuários devem confirmar que a implantação realmente poderá ocorrer.

Um endereço CREATE2 vazio pode manter fundos?

Sim. Um endereço sem código pode ter saldo de criptomoeda nativa e saldos de tokens.

Um saldo positivo, por si só, não impede a implantação CREATE2 no endereço.

A regra da EVM sobre colisões considera se o destino tem nonce diferente de zero ou código não vazio.

Esse design é necessário para contas contrafactuais que recebem fundos antes da implantação.

Após a implantação, o código do contrato e as regras de autorização determinam como esses ativos podem ser usados.

Regras de colisão do CREATE2

Uma implantação CREATE2 falha quando o endereço de destino já tem código não vazio ou nonce diferente de zero.

Isso impede que uma factory sobrescreva um contrato existente no mesmo endereço.

A regra se aplica mesmo quando o novo código de inicialização calcularia corretamente aquele endereço.

A implantação também falha se o código de inicialização reverter, ficar sem gas, retornar código inválido ou violar outra regra de criação de contratos.

As factories devem tratar um resultado zero do opcode CREATE2 e, quando possível, retornar um erro informativo.

Uma colisão não significa que a função hash Keccak tenha sido quebrada criptograficamente.

Normalmente, significa que o destino determinístico já está ocupado segundo as regras de contas da EVM.

Duas implantações diferentes podem gerar o mesmo endereço CREATE2?

Duas tentativas de implantação calculam o mesmo endereço quando usam o mesmo endereço de factory, salt e hash do código de inicialização.

Em teoria, códigos de inicialização diferentes poderiam ter o mesmo hash, mas encontrar uma colisão prática em Keccak-256 é considerado computacionalmente inviável segundo as atuais premissas de segurança.

Como apenas os 20 bytes finais são usados no endereço, colisões aleatórias são teoricamente possíveis, como ocorre com outros endereços Ethereum.

Produzir uma colisão escolhida continua sendo impraticável com os recursos computacionais atuais.

Ainda assim, os desenvolvedores não devem considerar um endereço visualmente semelhante como prova de que as entradas da implantação estão corretas.

Reutilização de salt

Uma factory pode reutilizar o mesmo salt quando o código de inicialização é diferente, pois o hash do código de inicialização resultará em outro endereço.

A mesma factory não pode implantar com sucesso duas vezes o mesmo código de inicialização com o mesmo salt enquanto o destino original continuar ocupado.

Um projeto pode proibir a reutilização de salts no nível do aplicativo para facilitar o acompanhamento da intenção de implantação.

Uma factory pública pode permitir que qualquer pessoa envie um salt já usado, pois a fórmula completa também inclui o hash do código de inicialização.

A exclusividade do salt, por si só, não é uma propriedade de segurança completa.

É preciso avaliar a combinação completa de factory, salt e código de inicialização.

Front-running de uma implantação CREATE2

Uma transação CREATE2 pendente pode ficar visível antes de ser incluída em um bloco.

Outro usuário pode copiar a chamada da factory e tentar implantar o contrato primeiro.

Quando uma factory sem permissão usa o mesmo salt e um código de inicialização idêntico, a implantação copiada deve criar o mesmo compromisso de código no mesmo endereço previsto.

A transação original poderá então falhar porque o destino já estará ocupado.

Isso ainda pode causar problemas de timing, gasto de gas sem resultado ou interrupção dos fluxos do aplicativo.

O risco aumenta quando o comportamento do construtor lê informações ambientais variáveis, como dados do bloco, origem da transação, estado de contratos externos ou parâmetros da factory que dependem do chamador.

A proposta atual de factory determinística recomenda o uso de factories conhecidas para contratos totalmente determinísticos, em vez de implantações cujos resultados dependem do ambiente de execução.

Risco de front-running do construtor

Um endereço CREATE2 inclui o código de inicialização, mas não congela todo o estado externo que o construtor pode consultar.

Um invasor que controle o momento da implantação pode fazer com que o construtor observe outro preço, valor de bloco, registro ou estado de contrato externo.

O código de execução resultante ou o armazenamento inicial pode diferir do que o usuário original esperava.

Sempre que possível, o construtor deve receber as configurações essenciais por meio de argumentos comprometidos, em vez de consultar estado externo mutável.

Após a criação, os scripts de implantação devem verificar o bytecode de execução, a propriedade, o armazenamento e os eventos emitidos.

Risco de função de inicialização desprotegida

Contratos proxy e clones mínimos costumam usar funções de inicialização em vez de construtores.

A função de inicialização define a propriedade, as permissões, os detalhes de implementação ou outro estado essencial após a implantação.

Prever um endereço CREATE2 não protege automaticamente essa função de inicialização.

Se a implantação e a inicialização ocorrerem em transações separadas, um invasor poderá chamar a função de inicialização primeiro.

A factory deve inicializar o contrato atomicamente durante a transação de implantação ou aplicar controles rígidos de autorização.

Um endereço determinístico não compensa um design de inicialização desprotegido.

Factories CREATE2

Uma factory CREATE2 é um contrato inteligente reutilizável que recebe um salt e um código de inicialização e executa o opcode CREATE2.

O uso de uma factory permite que contas de propriedade externa e outros contratos inteligentes acessem a implantação determinística por meio de uma interface consistente.

Uma factory mínima pode aceitar qualquer código sem exigir permissão.

Uma factory especializada pode implantar apenas implementações de contas ou módulos de aplicativos aprovados.

Os desenvolvedores devem examinar o bytecode de execução da factory, o histórico de implantação, as permissões, o tratamento de falhas e o comportamento de transferência de valores.

Uma factory maliciosa pode alterar entradas, restringir implantações, reter fundos ou executar código inesperado.

Factories singleton

Uma factory singleton é uma factory determinística projetada para existir no mesmo endereço em várias redes EVM.

Um endereço compartilhado para a factory ajuda os desenvolvedores a derivar o mesmo endereço de contrato dependente em cada rede compatível.

A ERC-2470 propôs uma factory singleton CREATE2 sem permissão para implantações determinísticas.

A proposta usou um método de implantação sem chave para que a factory pudesse ser criada em um endereço conhecido em redes compatíveis.

Em julho de 2026, a ERC-2470 está marcada como Stagnant no repositório de EIPs, embora o conceito mais amplo de factory determinística continue amplamente relevante.

O status de uma proposta em um repositório e o status de implantação real de um contrato são questões distintas.

Implantação determinística em várias redes

CREATE2 pode ajudar a implantar um contrato no mesmo endereço em várias redes EVM.

Para obter o mesmo resultado, é necessário usar o mesmo endereço de factory CREATE2, salt e hash do código de inicialização em cada rede.

Usar a mesma carteira de implantação do aplicativo não basta quando a carteira chama endereços diferentes de factory.

Os metadados do compilador, a vinculação de bibliotecas, os argumentos do construtor e as alterações no código-fonte do contrato podem mudar o hash do código de inicialização.

O ID da chain não está incluído diretamente na fórmula CREATE2 básica.

No entanto, um construtor ou ferramenta de implantação pode incluir dados específicos da rede que alterem o código de inicialização ou o estado implantado.

Os desenvolvedores devem verificar separadamente o código implantado em cada rede, mesmo quando os endereços coincidem.

Por que a implantação no mesmo endereço em várias redes é útil?

Endereços de contrato idênticos reduzem a quantidade de endereços que carteiras, interfaces, bibliotecas de software e outros contratos precisam armazenar.

Um desenvolvedor pode usar uma única constante de endereço em várias redes compatíveis.

Assim, é menos provável que os usuários copiem o endereço do contrato de uma rede errada.

As contas de contratos inteligentes também podem apresentar um endereço consistente em várias blockchains.

Isso melhora a usabilidade, mas pode gerar falsa confiança se uma rede tiver código ou configuração diferentes no mesmo endereço.

O endereço deve sempre ser avaliado junto com o identificador da chain e o bytecode verificado.

Propostas atuais para factories determinísticas

A infraestrutura de factories determinísticas continua evoluindo com a criação de mais redes EVM e rollups.

Em julho de 2026, a EIP-7997 está em análise e propõe exigir formalmente uma factory determinística amplamente usada em um endereço especificado em todas as chains EVM.

A proposta ainda não é definitiva e não deve ser considerada uma garantia universal para todas as redes.

A ERC-7955 continua sendo uma proposta em Draft para inicializar sem permissões uma factory CREATE2 universal por meio dos recursos EIP-7702.

Essas propostas abordam o fato de que CREATE2, por si só, não resolve o problema de instalar a factory original no mesmo endereço em todos os lugares.

Antes de depender de uma factory universal, os desenvolvedores devem verificar o status atual da proposta e o estado real da rede.

CREATE2 e abstração de contas

A abstração de contas permite que contas de contratos inteligentes usem regras programáveis de validação e execução.

Uma carteira pode oferecer múltiplos signatários, passkeys, tutores de recuperação, limites de gastos, operações em lote e patrocínio de taxas.

CREATE2 permite que a factory da carteira calcule o endereço da conta antes de implantar o contrato da carteira.

O usuário pode receber fundos no endereço e implantar a conta quando a primeira operação for processada.

A ERC-4337 pode incluir dados da factory para criar uma conta quando o emissor ainda não existe.

O endereço contrafactual da conta precisa corresponder ao endereço produzido pela chamada da factory.

Se a factory implantar o código em outro lugar, a operação da conta falhará no fluxo de validação padrão.

CREATE2 e assinaturas antes da implantação

Uma conta de contrato contrafactual pode precisar assinar uma mensagem de autenticação antes de ser implantada.

A verificação convencional de assinatura de contrato não pode chamar a conta porque ainda não existe código de execução no endereço.

A ERC-6492 define um formato de encapsulamento para verificar assinaturas feitas em nome de contas de contrato ainda não implantadas.

O processo de verificação pode simular ou executar a implantação necessária pela factory antes de conferir a lógica de assinatura do contrato.

O padrão recomenda contratos CREATE2 porque seus endereços são previsíveis.

Uma assinatura de uma conta contrafactual deve ser verificada pelo padrão aplicável a assinaturas de contratos, e não tratada como uma assinatura comum de uma conta de propriedade externa.

CREATE2 e contas vinculadas a tokens

Uma conta vinculada a token é uma conta de contrato inteligente associada a um token não fungível.

A conta pode manter criptomoedas, tokens, NFTs e outros ativos on-chain.

A ERC-6551 usa CREATE2 para permitir que endereços de contas vinculadas a tokens existam de forma contrafactual antes da implantação.

Isso permite transferir ativos para a conta de um token antes que alguém pague para implantar o contrato da conta.

De acordo com as regras do padrão, o endereço da conta depende do registro, da implementação, do salt, do identificador da blockchain, do contrato do token e do identificador do token.

Em geral, a propriedade do NFT controlador determina quem pode executar ações pela conta vinculada ao token.

CREATE2 e canais de estado

Os canais de estado permitem que os participantes realizem interações repetidas off-chain, usando um contrato blockchain para impor o resultado final ou resolver disputas.

Os participantes podem concordar antecipadamente com o código e o endereço de um contrato de disputa.

CREATE2 permite calcular esse endereço sem implantar o contrato imediatamente.

Os participantes podem fazer referência ao contrato contrafactual durante todo o processo off-chain.

O contrato só precisa ser implantado quando sua execução se tornar necessária.

Esse foi um dos casos de uso originais descritos na EIP-1014.

CREATE2 e contratos proxy mínimos

Um proxy mínimo é um contrato pequeno que delega chamadas a um contrato de implementação.

Uma factory pode combinar proxies mínimos com CREATE2 para criar endereços previsíveis para contas ou aplicativos.

O endereço da implementação pode fazer parte do código de inicialização do proxy.

Portanto, a alteração do endereço da implementação pode mudar o endereço previsto do proxy.

Algumas factories gravam parâmetros de inicialização no armazenamento do proxy implantado durante a mesma transação.

Os desenvolvedores devem verificar se o compromisso determinístico abrange a implementação, os dados de inicialização ou apenas um proxy genérico.

CREATE2 e contratos atualizáveis

CREATE2 não é, por si só, um sistema de atualização.

Um contrato implantado com CREATE2 pode ser atualizável se usar um proxy ou outra arquitetura explícita de atualização.

Nesse design, o proxy permanece no endereço determinístico, enquanto a referência à implementação pode mudar.

O administrador do proxy, as regras de governança, o prazo de espera e a verificação da implementação determinam a segurança das atualizações.

Um endereço determinístico de proxy não garante comportamento imutável.

Os usuários devem verificar as permissões de atualização, em vez de presumir que um endereço previsível significa código permanente.

CREATE2, SELFDESTRUCT e nova implantação

Designs antigos de CREATE2 às vezes usavam

para remover um contrato e depois implantar um comportamento diferente no mesmo endereço.

Esses designs eram frequentemente chamados de contratos metamórficos.

As regras atuais da Ethereum definidas na EIP-6780 para SELFDESTRUCT geralmente impedem que um contrato de longa duração exclua seu código e armazenamento.

Quando SELFDESTRUCT é chamado por um contrato que não foi criado na mesma transação, ele transfere o saldo, mas não exclui o código, o armazenamento nem a conta.

Por isso, padrões convencionais de atualização que dependiam de destruir um contrato implantado e recriá-lo no mesmo endereço CREATE2 deixaram de funcionar.

A EIP-6780 recomenda explicitamente o uso de designs de atualização consolidados baseados em proxy, em vez da reimplantação CREATE2 para atualizar contratos.

SELFDESTRUCT continua obsoleto, e novos sistemas não devem depender de que seu comportamento permaneça inalterado indefinidamente.

Risco dos contratos metamórficos

Um contrato metamórfico foi projetado para alterar o código executado em um endereço estável por meio de destruição e nova implantação.

Antes das restrições atuais de SELFDESTRUCT, esse padrão podia tornar especialmente perigoso confiar em um endereço.

Um usuário poderia verificar uma versão do código e, mais tarde, interagir com um código diferente no mesmo endereço.

As regras atuais do Ethereum interromperam o padrão geral de reimplantação de contratos de longa duração, mas redes antigas ou outros ambientes EVM podem ter comportamentos diferentes para SELFDESTRUCT.

As ferramentas de segurança devem avaliar as regras da blockchain específica e do período de blocos analisado.

Uma transação histórica deve ser interpretada de acordo com as regras de protocolo vigentes quando ocorreu.

Custos de gas do CREATE2

CREATE2 usa uma estrutura de gas semelhante à do CREATE convencional e acrescenta um custo pelo hash do código de inicialização.

A EIP-1014 define esse custo adicional de hash de acordo com o número de palavras de 32 bytes no código de inicialização.

Assim, códigos de inicialização maiores exigem mais gas para derivar o endereço, além do gas necessário para memória e execução do construtor.

A implantação também paga pelo armazenamento do bytecode de execução resultante e pelas operações do construtor.

As tabelas de gas da rede podem mudar com atualizações de protocolo, portanto, estimativas fixas não devem ser consideradas permanentes.

Uma conta contrafactual pré-financiada ainda pode precisar de criptomoeda nativa suficiente ou de um patrocinador de taxas para pagar sua implantação futura.

Limites de tamanho do código de inicialização

O Ethereum aplica limites de protocolo e medição de gas ao código de inicialização de contratos.

A EIP-3860 introduziu medição adicional de init code e um limite máximo de tamanho para o código de inicialização.

As regras se aplicam tanto a implantações CREATE quanto CREATE2.

Factories grandes não devem presumir que códigos de construtor de tamanho arbitrário poderão ser enviados com sucesso.

As ferramentas de desenvolvimento devem testar o código de inicialização compilado final de acordo com os limites atuais da rede.

Endereços de contrato personalizados

Os desenvolvedores podem testar vários valores de salt até que o endereço CREATE2 previsto contenha um prefixo ou padrão desejado.

Esse processo é conhecido como mineração de um endereço de contrato personalizado.

Um prefixo curto e reconhecível pode facilitar a identificação visual de um endereço.

Isso não melhora a segurança nem a autoridade do contrato inteligente.

Os usuários devem verificar o endereço completo, pois golpistas podem gerar endereços com prefixos e sufixos semelhantes.

Um endereço personalizado nunca deve substituir a verificação do bytecode e dos registros confiáveis de implantação.

CREATE2 e envenenamento de endereços

O envenenamento de endereços tenta fazer um endereço enganoso aparecer no histórico de transações ou na interface da carteira do usuário.

Um invasor pode gerar um endereço com caracteres parecidos com os de um endereço confiável.

CREATE2 pode ajudar a procurar endereços de contratos com padrões visuais escolhidos, variando o salt.

O ataque não exige quebrar CREATE2 nem Keccak-256.

Ele se aproveita de usuários que verificam apenas o começo ou o fim de um endereço.

Antes de enviar criptomoedas, os usuários devem verificar o endereço completo ou usar um sistema confiável de contatos.

Confusão de endereços entre blockchains

O mesmo endereço hexadecimal pode existir em várias redes EVM.

Dependendo da rede, ele pode conter o mesmo código, código diferente ou nenhum código.

Um plano de implantação determinística pode criar endereços idênticos, mas o identificador da blockchain continua sendo essencial.

O envio de ativos ao endereço correto, mas na rede errada, pode torná-los inacessíveis pelo aplicativo pretendido.

Carteiras e interfaces devem exibir claramente o endereço do contrato e a rede selecionada.

Os desenvolvedores devem verificar os hashes de código e as configurações em cada chain compatível.

Riscos de confiança na factory

Um cálculo determinístico de endereço pressupõe que a factory selecionada se comporte conforme esperado.

Uma factory pode alterar o salt, modificar o código de inicialização, aplicar controles de acesso, cobrar taxas ou transferir o valor enviado de forma inesperada.

Uma factory atualizável pode mudar depois da análise inicial feita pelo desenvolvedor.

Uma factory controlada por uma única chave privada pode ficar indisponível ou se tornar maliciosa se a chave for perdida ou comprometida.

Factories sem permissão reduzem alguns riscos de controle, mas podem criar preocupações com front-running e spam.

Antes de depender de endereços previstos, os desenvolvedores devem verificar o código de execução da factory e seu mecanismo de implantação.

Riscos de compilador e metadados

Versões diferentes do compilador Solidity podem gerar bytecode de criação diferente a partir do mesmo código-fonte.

As configurações do compilador, como execuções de otimização, configuração de metadados, bibliotecas vinculadas e versão-alvo da EVM, também podem alterar o bytecode.

Uma pequena diferença no bytecode produz outro hash do código de inicialização e, consequentemente, outro endereço CREATE2.

Os desenvolvedores devem fixar a versão do compilador e a configuração de compilação usadas na implantação determinística.

Procedimentos de compilação reproduzível ajudam usuários independentes a confirmar que o código-fonte publicado gera o bytecode implantado.

Copiar apenas o código Solidity, sem as configurações de compilação, pode não ser suficiente para reproduzir o endereço previsto.

Vinculação de bibliotecas

Um contrato Solidity pode conter marcadores que precisam ser substituídos pelos endereços de bibliotecas implantadas antes da criação.

O bytecode de criação vinculado passa a fazer parte do código de inicialização CREATE2.

A alteração do endereço de uma biblioteca muda o endereço previsto do contrato.

Assim, uma implantação cross-chain pode não gerar endereços idênticos se as bibliotecas vinculadas estiverem em endereços diferentes.

Projetos que buscam endereços idênticos em várias redes talvez precisem implantar as bibliotecas de forma determinística antes dos contratos dependentes.

Lista de verificação para CREATE2

Verifique a blockchain e o endereço da factory antes de calcular o destino previsto.

Confirme a codificação exata de 32 bytes do salt.

Use o bytecode de criação, não o bytecode de execução.

Inclua no código de inicialização os argumentos do construtor codificados em ABI.

Fixe a versão do compilador, as configurações de otimização, as bibliotecas vinculadas e a configuração de metadados.

Verifique se o endereço previsto já tem código ou nonce diferente de zero.

Simule a chamada da factory e analise quaisquer dependências do construtor em relação ao estado externo.

Após a implantação, compare o endereço real, o bytecode de execução, a configuração de armazenamento, o proprietário, a implementação e os eventos emitidos com o resultado esperado.

Vantagens do CREATE2

CREATE2 permite conhecer o endereço de um contrato antes da implantação.

Viabiliza carteiras e contratos contrafactuais que podem receber ativos antes da criação do código.

Elimina a dependência do nonce de implantação variável da factory.

Pode criar endereços de aplicativos consistentes em redes EVM compatíveis quando todas as entradas necessárias coincidem.

Oferece suporte a designs eficientes de canais de estado e contratos de disputa.

Pode simplificar o gerenciamento de endereços em carteiras, bibliotecas de software, contratos inteligentes e interfaces multichain.

Também viabiliza sistemas de implantação reproduzíveis nos quais os usuários verificam de forma independente o destino esperado.

Limitações do CREATE2

CREATE2 não garante que o contrato será realmente implantado.

Não garante que a factory seja confiável ou esteja disponível em todas as redes.

Não garante que endereços idênticos contenham o mesmo código de execução ou estado em diferentes blockchains.

Não protege um proxy não inicializado, um construtor inseguro, um administrador comprometido ou um contrato inteligente vulnerável.

Não permite sobrescrever um contrato existente quando o destino já tem código ou nonce diferente de zero.

As regras atuais de SELFDESTRUCT impedem padrões gerais de atualização que destroem e reimplantam contratos de longa duração.

Também cria riscos operacionais quando os usuários enviam fundos a um endereço previsto sem verificar completamente as entradas da implantação.

Perguntas frequentes

O que é CREATE2, em termos simples?

CREATE2 é uma instrução da EVM que permite aos desenvolvedores calcular o endereço de um contrato inteligente antes de implantá-lo.

O que significa implantação determinística?

Implantação determinística significa que as mesmas entradas definidas para a implantação produzem o mesmo endereço calculado para o contrato.

Qual EIP introduziu CREATE2?

CREATE2 foi introduzido pela EIP-1014.

Qual é o opcode CREATE2?

O opcode CREATE2 é

.

Quais entradas determinam um endereço CREATE2?

O endereço depende do endereço da factory CREATE2, de um salt de 32 bytes e do hash do código de inicialização.

CREATE2 usa nonce?

CREATE2 não usa o nonce variável de criação de contratos da factory em sua fórmula de endereço.

O remetente da transação está incluído na fórmula CREATE2?

A fórmula inclui o contrato que executa diretamente CREATE2, normalmente a factory, e não a carteira externa que a chama.

O que é um salt CREATE2?

Salt é um valor de 32 bytes usado para diferenciar implantações determinísticas e gerar endereços distintos.

O salt CREATE2 precisa ser secreto?

Não. Normalmente, não é necessário manter o salt em segredo.

O que é init code?

Init code é um código temporário de criação que executa o construtor e retorna o bytecode de execução armazenado no novo endereço.

CREATE2 aplica hash ao bytecode de execução?

A fórmula do endereço aplica hash ao código de inicialização, em vez de aplicar hash diretamente apenas ao bytecode final de execução.

Os argumentos do construtor alteram o endereço CREATE2?

Sim. Os argumentos do construtor Solidity são incluídos no código de inicialização e normalmente alteram o endereço previsto.

É possível prever um endereço CREATE2 off-chain?

Sim. O endereço pode ser calculado localmente, sem enviar uma transação à blockchain.

Um endereço CREATE2 ainda não implantado pode receber criptomoedas?

Sim. Um endereço previsto pode receber criptomoeda nativa e tokens compatíveis antes da implantação do contrato.

É seguro enviar fundos a um endereço ainda não implantado?

Há riscos, a menos que a factory, o salt, o código de inicialização, a possibilidade de implantação e as regras futuras de autorização tenham sido verificados.

CREATE2 pode implantar por cima de um contrato existente?

Não. A implantação falha quando o endereço de destino já tem código não vazio ou nonce diferente de zero.

CREATE2 pode implantar o mesmo contrato duas vezes?

A mesma factory, o mesmo salt e o mesmo código de inicialização não podem ser usados para implantar o contrato duas vezes com sucesso enquanto o destino original continuar ocupado.

É possível reutilizar o mesmo salt?

Sim. O mesmo salt pode produzir endereços diferentes quando a factory ou o hash do código de inicialização forem diferentes.

Alguém pode fazer front-running de uma implantação CREATE2?

Alguém pode copiar uma chamada pública da factory e implantar primeiro, o que pode atrapalhar o timing e ser perigoso quando o comportamento do construtor depende de dados externos variáveis.

CREATE2 garante código idêntico em várias blockchains?

Não. Endereços idênticos exigem entradas correspondentes, mas o ambiente do construtor, a inicialização, a configuração e o estado da rede ainda podem causar diferenças importantes.

Como CREATE2 pode gerar o mesmo endereço em várias redes?

É preciso usar a mesma factory, o mesmo salt e o mesmo hash do código de inicialização em cada rede compatível.

O ID da chain faz parte da fórmula CREATE2?

A fórmula básica não inclui diretamente o ID da chain, embora o código de implantação ou os argumentos do construtor possam incluir informações específicas da rede.

O que é uma factory CREATE2?

Uma factory CREATE2 é um contrato inteligente que executa implantações determinísticas para usuários ou outros contratos.

O que é uma factory singleton?

Uma factory singleton é um implantador CREATE2 projetado para existir em um endereço conhecido e idêntico em várias redes.

O que é implantação contrafactual?

Implantação contrafactual significa usar ou referenciar um endereço previsível de contrato antes que o contrato seja implantado.

Como CREATE2 ajuda carteiras de contratos inteligentes?

Permite calcular e financiar o endereço da carteira antes da criação do contrato dela.

Qual é a relação entre CREATE2 e ERC-4337?

As factories de contas ERC-4337 costumam usar CREATE2 para derivar e implantar endereços previsíveis de contas de contratos inteligentes.

Um contrato ainda não implantado pode assinar mensagens?

A ERC-6492 oferece um método para verificar, antes da implantação, assinaturas associadas a determinadas contas de contrato contrafactuais.

CREATE2 é um mecanismo de atualização?

Não. A possibilidade de atualização exige um design separado de proxy ou governança.

SELFDESTRUCT pode liberar um contrato para reimplantação com CREATE2?

As regras atuais do Ethereum geralmente preservam o código e o armazenamento de contratos já estabelecidos, portanto padrões de atualização baseados em destruir e reimplantar contratos de longa duração deixaram de funcionar.

O que é um contrato metamórfico?

Um contrato metamórfico é um design antigo que buscava alterar o código em um endereço por meio de destruição e reimplantação determinística.

CREATE2 custa mais gas do que CREATE?

CREATE2 acrescenta um custo de hash do código de inicialização aos custos comuns de criação, memória, execução do construtor e armazenamento do código.

CREATE2 pode gerar um endereço personalizado?

Sim. Os desenvolvedores podem testar vários salts até que o endereço previsto contenha um padrão visual desejado.

Um endereço CREATE2 personalizado melhora a segurança?

Não. Um prefixo ou sufixo reconhecível não comprova a segurança, a propriedade nem a autenticidade do código.

Por que meu endereço CREATE2 previsto foi diferente do endereço implantado?

As causas comuns incluem factory errada, codificação incorreta do salt, resultado do compilador, biblioteca vinculada, argumentos do construtor ou confusão entre bytecode de criação e de execução.

Como verificar uma implantação CREATE2?

Recalcule o endereço usando as entradas exatas e compare o código de execução implantado, o armazenamento, o proprietário, a implementação e os eventos com os valores esperados.

Conclusão

A implantação determinística por meio de CREATE2 permite calcular o endereço de um contrato inteligente compatível com Ethereum antes que ele exista on-chain.

O endereço é derivado de um prefixo fixo, do endereço da factory CREATE2, de um salt de 32 bytes e do hash do código de inicialização.

Os argumentos do construtor, o resultado do compilador, as bibliotecas vinculadas e as configurações de compilação podem alterar o código de inicialização e, portanto, o endereço.

CREATE2 viabiliza contas inteligentes contrafactuais, canais de estado, contas vinculadas a tokens, componentes previsíveis de aplicativos e implantações multichain no mesmo endereço.

Um endereço previsto pode receber criptomoedas antes da implantação, mas os ativos podem ficar inacessíveis se o contrato pretendido não puder ser criado.

Para ter o mesmo endereço em várias redes, é preciso usar a mesma factory, o mesmo salt e o mesmo hash do código de inicialização. Isso não garante automaticamente código, estado ou segurança idênticos.

Os desenvolvedores também devem proteger as funções de inicialização, evitar construtores dependentes do ambiente, verificar o comportamento da factory e considerar os riscos de front-running.

As regras atuais de SELFDESTRUCT do Ethereum impedem sistemas gerais de atualização baseados em destruir um contrato de longa duração e recriá-lo no mesmo endereço.

Portanto, CREATE2 deve ser considerado uma ferramenta de derivação de endereços e implantação, não uma solução automática de segurança ou atualização.

Quando suas entradas, sua factory, seu bytecode e seu processo de inicialização são verificados cuidadosamente, CREATE2 oferece uma base poderosa para aplicativos de criptomoedas previsíveis e fáceis de usar.