Saltar al contenido
Financial Context Wiki

Cómo verificar una dirección de contrato CREATE2

CREATE2 predice una dirección a partir del implementador, el salt y el hash del código de inicialización, pero la verificación aún exige evidencia de fábrica, bytecode, despliegue, proxy y control específica de la cadena.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. Una dirección predicha, una cuenta vacía, un checksum o una etiqueta de fábrica no prueban despliegue, código, control, propiedad ni seguridad.

Respuesta directa

CREATE2 predice la dirección creada por un contrato implementador específico a partir de un 32-byte salt y del hash de su init_code exacto. La fórmula del protocolo es address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: calcula el hash de un 85-byte preimage y conserva los últimos 20 bytes. El implementador es la fábrica que ejecuta CREATE2, no necesariamente la cartera que llamó a la fábrica.

init_code es el bytecode de creación más los argumentos del constructor codificados con ABI; se ejecuta una vez y produce el bytecode de ejecución. La versión del compilador, la optimización, las bibliotecas enlazadas, los metadatos, los argumentos del constructor o el punto de entrada de la fábrica pueden cambiar el hash. El código de ejecución es una salida, no la entrada de CREATE2. Una misma dirección solo es comparable con el mismo implementador, salt, código de inicialización, reglas EVM y estado de la cadena.

Una dirección contrafactual puede recibir fondos antes de que exista código, pero aún no tiene lógica de control verificada. La predicción no demuestra despliegue, propiedad, autorización, finalidad ni seguridad. Verifica el bytecode y calldata de la fábrica, el recibo y los eventos, eth_getCode, nonce, almacenamiento, saldo, implementación del proxy, inicializador y propietario en la cadena y bloque previstos.

Cómo funciona

Fija la cadena o dominio, las reglas de fork, RPC y bloque, la dirección de la fábrica y el hash de runtime, el salt bruto, los bytes exactos de init, la codificación del constructor, el compilador y las bibliotecas enlazadas. Recalcula keccak256(init_code) y el 85-byte preimage; normaliza el relleno ABI, el endianess, el checksum y la extracción de los últimos 20 bytes.

Después decodifica la llamada y el valor enviados a la fábrica. Confirma que la fábrica, el punto de entrada, el dominio del salt, el constructor, el propietario y el inicializador previstos están vinculados. Para un proxy mínimo, hashea el bytecode de creación del clon que contiene la dirección de implementación, no el runtime de la implementación. Para un proxy, verifica por separado la implementación, el administrador, los slots de almacenamiento y la política de actualización.

EIP-684 hace que la creación revierta cuando el nonce de destino no es cero o el código no está vacío. Un constructor fallido tampoco deja un despliegue válido. Las suposiciones sobre SELFDESTRUCT y el redespliegue posterior dependen de las reglas del fork; nunca confíes en la antigua afirmación de que el código puede reemplazarse siempre a voluntad.

La evidencia del despliegue tiene capas: inclusión y estado de la transacción, eventos emitidos, código y nonce, almacenamiento y saldos, y finalmente un estado seguro o finalizado. Una respuesta RPC exitosa o un checksum predicho no sustituye la verificación del recibo y del estado. Copias de la misma dirección en distintas cadenas pueden tener código, propietarios, almacenamiento y activos diferentes.

Usa este flujo:

  1. Fija cadena, fork, RPC y bloque; dirección de fábrica o implementador y hash de runtime; bytes del salt; código init, argumentos del constructor, compilador y bibliotecas enlazadas.
  2. Calcula el hash del código init y el preimagen CREATE2 exacto, comprobando anchos, relleno, 0xff, los últimos 20 bytes y el checksum.
  3. Decodifica calldata y valor de la fábrica; compara dirección predicha, propietario, inicializador, destino del proxy y permisos previstos.
  4. Verifica recibo, estado, eventos, eth_getCode, nonce, saldo y almacenamiento en la cadena correcta; registra estados no desplegado y de colisión.
  5. Inspecciona fábrica, proxy, implementación, administrador, inicializador, actualización y supuestos de Singleton Factory, incluidos los destinos ERC-1167.
  6. Prueba fallo del constructor, colisión por nonce/código, redespliegue sensible al fork, fábricas anidadas y supuestos de dominio de cadena o replay.
  7. Antes de financiar o firmar, reconcilia importes humanos y brutos; después del despliegue monitoriza hash de código, propietario, implementación, roles, eventos y finalidad.

Ejemplos

  • Vector EIP-1014: implementador 0x0000000000000000000000000000000000000000, salt cero, init 0x00 produce 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Vinculación del constructor: con implementador y salt fijos, cambiar un argumento del constructor codificado con ABI cambia keccak256(init_code) y, por tanto, la dirección predicha; hashear el runtime verificaría el objeto equivocado.
  • Colisión: si el nonce de destino es mayor que 0 o su código no está vacío, CREATE2 debe revertir conforme a EIP-684. Una dirección financiada con código vacío y nonce cero solo es contrafactual y sigue sin estar verificada.
  • Proxy mínimo: la dirección de un clon ERC-1167 hashea el bytecode de creación del clon que contiene la dirección de implementación. Hashear el runtime de la implementación produce una predicción distinta.

Riesgos

  • Se usa una fábrica o implementador equivocado.
  • El ancho, relleno, endianess o dominio del salt es incorrecto.
  • Se confunde el código init con el bytecode de ejecución.
  • Se omiten o reordenan los argumentos del constructor.
  • Difieren el punto de entrada, valor o calldata de la fábrica.
  • El proxy o destino delegatecall no es la implementación prevista.
  • Difieren la cadena, el fork o el dominio EVM.
  • El nonce existente causa una colisión.
  • El código existente causa una colisión.
  • Se usan suposiciones obsoletas sobre redespliegue tras SELFDESTRUCT.
  • CREATE2 anidado cambia el implementador efectivo.
  • Se mezclan las fórmulas CREATE y CREATE2.
  • No se verifica el destino de implementación ERC-1167.
  • No se verifican la dirección o supuestos de despliegue de Singleton Factory.
  • Una actualización o administrador de implementación cambia el comportamiento.
  • Difieren el compilador, metadatos, biblioteca o artefacto fuente.
  • Se confunden recibo, mempool, fallo y estados finalizados.
  • Un checksum o envenenamiento de la interfaz oculta una dirección equivocada.
  • Los fondos prefijados no tienen prueba de propiedad de la dirección contrafactual.
  • Son erróneos los supuestos sobre EIP-7702, replay, gas, denegación de servicio o monitorización obsoleta.

Errores comunes

  • «Una dirección vacía es segura o propia». Puede no tener código ni controlador verificado.
  • «El salt por sí solo determina la dirección». El implementador y el hash del código init también son vinculantes.
  • «CREATE2 hashea el bytecode de ejecución». Hashea el código de creación, incluidos los argumentos del constructor.
  • «La misma dirección en dos cadenas implica el mismo código y control». Hay que comprobar por separado el estado y despliegue de cada cadena.
  • «Una predicción correcta prueba despliegue y seguridad». Solo el recibo, el código, el estado, los permisos y la finalidad establecen qué existe.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...