Despliegue determinista (CREATE2)

¿Qué es el despliegue determinista (CREATE2)?

El despliegue determinista (CREATE2) es un método de la Ethereum Virtual Machine que permite a los desarrolladores calcular la dirección de un contrato inteligente antes de desplegarlo.

Este método utiliza el opcode de la EVM

, identificado por el valor de opcode .

Un contrato desplegado con CREATE2 recibe una dirección derivada del contrato que lo despliega, un salt elegido por el desarrollador y un hash del código de inicialización del contrato.Esto difiere del despliegue normal de contratos, en el que la dirección resultante suele basarse en la dirección del desplegador y su nonce.Como CREATE2 no utiliza el nonce de despliegue, que cambia con el tiempo, los desarrolladores pueden predecir la misma dirección aunque la factory haya creado otros contratos entretanto.Esta propiedad permite crear cuentas inteligentes contrafactuales, componentes de protocolo previsibles, infraestructura de aplicaciones cross-chain, canales de estado y contratos que reciben criptomonedas antes de desplegarse.

La especificación definitiva EIP-1014 CREATE2 define el opcode, la fórmula de la dirección, el tratamiento del gas, el comportamiento ante colisiones y la motivación original del despliegue contrafactual.

CREATE2 no hace que un contrato sea seguro, permanente, descentralizado o idéntico automáticamente en todas las blockchains.Solo proporciona un método determinista para derivar la dirección de despliegue a partir de determinadas entradas.

¿Por qué se denomina determinista a CREATE2?

Un proceso es determinista cuando las mismas entradas siempre producen el mismo resultado.En CREATE2, el resultado relevante es la dirección del contrato inteligente.Las entradas pertinentes son la dirección del desplegador CREATE2, el salt de 32 bytes y el hash del código de inicialización.Cualquier persona que conozca estas entradas puede calcular la dirección futura sin enviar una transacción a la blockchain.La dirección no depende del momento del despliegue, del número del bloque actual ni del número de contratos que la factory haya creado anteriormente.Cambiar cualquier entrada de la fórmula de la dirección produce una dirección prevista distinta.Por tanto, se puede planificar, referenciar o financiar el contrato, o incluirlo en mensajes firmados, antes de que exista código on-chain en esa dirección.

Fórmula de la dirección CREATE2

La dirección CREATE2 se calcula con la fórmula siguiente.

El valor

es un prefijo de un byte que permite distinguir las direcciones CREATE2 de las creadas mediante la fórmula CREATE normal.

es la dirección de 20 bytes del contrato que ejecuta directamente el opcode CREATE2.

es un valor de 32 bytes proporcionado a la operación CREATE2.

es el código de inicialización ejecutado durante la creación del contrato.

El código de inicialización se convierte en un hash antes de incluirse en la entrada final de 85 bytes del hash CREATE2.Los últimos 20 bytes del hash Keccak-256 final se convierten en la dirección del contrato.La fórmula se puede calcular localmente sin pagar una comisión de red, ya que predecir el resultado no requiere modificar el estado de la blockchain.

¿Qué es el desplegador CREATE2?

El desplegador CREATE2 es el contrato inteligente que llama directamente al opcode CREATE2.A menudo se denomina factory, contrato desplegador, proxy de despliegue determinista o singleton factory.La cuenta de propiedad externa que envía una transacción a la factory no es automáticamente la dirección que se utiliza en la fórmula CREATE2.La dirección pertinente del desplegador suele ser la de la factory, porque es esta la que ejecuta el opcode.Utilizar una factory distinta genera una dirección de contrato prevista diferente, aunque el salt y el código de inicialización sean idénticos.Por eso los desarrolladores deben verificar la dirección exacta de la factory, en lugar de calcular el resultado a partir de la wallet que envía la transacción.Una factory puede permitir que cualquiera despliegue código de inicialización arbitrario o restringir los despliegues a cuentas y plantillas de contrato aprobadas.Los permisos y la implementación de la factory pueden determinar si el contrato previsto puede realmente desplegarse.

¿Qué es un salt CREATE2?

Un salt CREATE2 es un valor arbitrario de 32 bytes que se incluye en el cálculo determinista de la dirección.El salt permite a una factory desplegar varios contratos con el mismo código de inicialización y asignarles direcciones distintas.El salt puede derivarse de un identificador de usuario, una dirección de wallet, un número de cuenta, un identificador de token, una versión de aplicación, un valor aleatorio o una combinación de varios campos.El salt no tiene que ser secreto.Cualquiera que conozca la factory, el salt y el código de inicialización puede calcular la misma dirección.Los desarrolladores deben definir un método claro para codificar el salt, ya que una codificación incoherente puede generar direcciones inesperadas.

Por ejemplo, el número

, una cadena de texto que contiene y un valor de 32 bytes que termina en pueden interpretarse de forma diferente por el software.

Un proyecto puede aplicar un hash a datos estructurados para crear un salt fijo de 32 bytes y evitar ambigüedades de codificación.

¿Qué es el código de inicialización?

El código de inicialización, normalmente abreviado como init code, es un código EVM temporal que se ejecuta al crear un contrato inteligente.Su función es ejecutar la lógica del constructor y devolver el bytecode de ejecución que permanecerá en la nueva dirección.Normalmente, el código de inicialización no se almacena como código permanente del contrato.La fórmula CREATE2 incorpora el hash de este código de inicialización.En Solidity, el código de inicialización completo suele incluir el bytecode de creación del contrato y los argumentos del constructor codificados según ABI.

La documentación actual de Solidity sobre la creación de contratos con salt confirma que la dirección depende del bytecode de creación y de los argumentos del constructor.

Si se cambia un argumento del constructor, cambia el hash del código de inicialización y, por tanto, la dirección prevista.Para calcular una dirección CREATE2, los desarrolladores deben utilizar exactamente el resultado del compilador y la codificación del constructor previstos para el despliegue.

Código de inicialización y bytecode de ejecución

El código de inicialización y el bytecode de ejecución están relacionados, pero son diferentes.El código de inicialización se ejecuta una vez durante el despliegue.El bytecode de ejecución es el código que se almacena en la dirección del contrato cuando finaliza el despliegue.La fórmula de la dirección CREATE2 incorpora directamente el hash del código de inicialización, no el hash final del código de ejecución.Esta distinción plantea una consideración de seguridad importante.Un constructor puede leer el estado externo de la blockchain y utilizar esa información para decidir qué bytecode de ejecución o valores iniciales de almacenamiento crear.Por tanto, el mismo código de inicialización puede producir comportamientos de despliegue distintos al ejecutarse bajo condiciones externas diferentes.Si un desarrollador quiere comprometerse firmemente con un comportamiento determinado, debe evitar constructores dependientes del entorno o verificar el código de ejecución y el almacenamiento resultantes después del despliegue.

Argumentos del constructor y CREATE2

En los despliegues con Solidity, los argumentos del constructor forman parte del código de inicialización.

Un contrato construido con la dirección de propietario

normalmente tendrá una dirección CREATE2 distinta de la del mismo contrato construido con la dirección de propietario .

La misma regla se aplica a los nombres de tokens, los valores de oferta, las direcciones de implementación, las listas de validadores, los ajustes de comisiones y otros argumentos del constructor.Los desarrolladores deben codificar los argumentos en el mismo orden y formato que espera la ABI del contrato.Un predictor de direcciones que omita los argumentos del constructor calculará un resultado incorrecto.Las funciones de inicialización llamadas después del despliegue no afectan a la fórmula CREATE2, salvo que la llamada de inicialización esté incluida en el constructor o en el proceso de la factory.Separar el despliegue de la inicialización puede crear un riesgo de apropiación si otra cuenta puede llamar primero a una función de inicialización sin protección.

CREATE y CREATE2

CREATE y CREATE2 son operaciones de la EVM utilizadas para crear contratos inteligentes.CREATE normal deriva la nueva dirección principalmente de la cuenta que crea el contrato y de su nonce de despliegue.El nonce aumenta a medida que el desplegador crea contratos.Por tanto, para predecir una dirección CREATE, el desarrollador debe conocer la secuencia de despliegue correcta.CREATE2 sustituye la fórmula basada en el nonce por otra basada en la dirección de la factory, el salt y el hash del código de inicialización.CREATE2 no modifica la ejecución fundamental del código del constructor ni el almacenamiento del bytecode de ejecución devuelto.Cambia el modo de derivar la dirección de destino y añade un coste de hash para el código de inicialización.Ambas operaciones fallan cuando la dirección de destino incumple las reglas de colisión de creación de contratos de la EVM.

¿Cuándo se introdujo CREATE2?

CREATE2 se especificó en EIP-1014 en 2018.Se incluyó en la actualización de red Constantinople de Ethereum.

La especificación de la actualización Constantinople incluye EIP-1014 entre los cambios del protocolo incorporados en dicha actualización.

Desde entonces, CREATE2 se ha consolidado como parte de la EVM y es compatible con Solidity y con las herramientas de desarrollo más utilizadas.Las redes compatibles con la EVM pueden admitir CREATE2 tras activar el comportamiento de protocolo correspondiente.Los desarrolladores deben verificar la compatibilidad de cada red, en lugar de suponer que todas las blockchains que utilizan un entorno similar a la EVM aplican reglas idénticas.

CREATE2 en Solidity

Solidity proporciona una sintaxis de alto nivel para desplegar contratos mediante CREATE2.

Una factory puede utilizar la sintaxis

.

El compilador de Solidity prepara el bytecode de creación, codifica los argumentos del constructor y genera la operación CREATE2.

Un constructor payable también puede recibir la moneda nativa de la blockchain durante el despliegue mediante la opción

.

La factory debe comprobar que el despliegue ha devuelto la dirección no nula esperada.Los desarrolladores también pueden llamar a CREATE2 mediante assembly en línea cuando necesiten controlar directamente la memoria del código de inicialización, su longitud, el salt y el valor transferido.El assembly en línea aumenta el riesgo de implementación y debe probarse cuidadosamente.

Ejemplo simplificado de CREATE2 en Solidity

En este ejemplo, la dirección prevista del contrato hijo depende de la dirección de la factory, el salt, el bytecode de creación de Child y el argumento

codificado.

Cambiar la cuenta externa que llama a la función sin modificar estas entradas no cambia necesariamente la dirección.

Cambiar

sí cambia la dirección, porque el argumento del constructor forma parte del código de inicialización.

Cómo predecir una dirección CREATE2

Un desarrollador puede calcular una dirección CREATE2 en un contrato inteligente, un script de despliegue, una wallet o una aplicación local.El cálculo debe utilizar la dirección exacta de la factory que ejecutará CREATE2.También debe utilizar el salt en su representación final de 32 bytes.El hash del código de inicialización debe incluir el bytecode de creación exacto y los argumentos del constructor codificados.El resultado debe compararse con la dirección que devuelve la factory después del despliegue.Las herramientas de despliegue deben rechazar el proceso si la dirección prevista y la dirección real no coinciden.Un cálculo incorrecto suele deberse a que se utiliza bytecode de ejecución en lugar de bytecode de creación, se omiten los argumentos del constructor, se selecciona la factory equivocada o se codifica mal el salt.

¿Qué es el despliegue contrafactual?

El despliegue contrafactual consiste en tratar como significativa una futura dirección de contrato inteligente antes de desplegar código en ella.Las partes pueden calcular la dirección y acordar de antemano el código de inicialización previsto para el contrato.Pueden enviar activos a esa dirección, incluirla en otro contrato o crear autorizaciones firmadas relacionadas con ella.El contrato solo se despliega cuando su ejecución resulta necesaria.Esto puede evitar una transacción de despliegue inmediata y reducir los costes iniciales de incorporación.EIP-1014 destacó originalmente las interacciones contrafactuales en sistemas de canales de estado, donde un contrato podía ser necesario solo si los participantes entraban en una disputa.El despliegue contrafactual también es importante actualmente para las wallets de contratos inteligentes y la abstracción de cuentas.

Cuentas de contratos inteligentes contrafactuales

Una cuenta de contrato inteligente puede tener una dirección CREATE2 previsible antes de que se despliegue el contrato de la cuenta.El usuario puede compartir esa dirección y recibir criptomonedas o tokens en ella.La primera operación de la cuenta puede desplegar la wallet y realizar una acción dentro del mismo proceso general.Esto puede evitar que el usuario tenga que completar una transacción aparte para crear la wallet antes de recibir activos.

La especificación de abstracción de cuentas ERC-4337 permite crear una cuenta de contrato inteligente emisora a partir de los datos de inicialización de una factory cuando la cuenta aún no existe.

Las factories de cuentas suelen utilizar CREATE2 para que la dirección emisora pueda calcularse antes del despliegue.No todos los diseños de abstracción de cuentas deben utilizar CREATE2, ya que los modelos de autorización y cuenta más recientes pueden recurrir a otros mecanismos.

Enviar criptomonedas a una dirección aún no desplegada

Una dirección CREATE2 aún no desplegada puede recibir la criptomoneda nativa de la blockchain, porque una dirección no necesita tener código de ejecución para mantener un saldo.También se pueden transferir tokens fungibles y no fungibles a una dirección prevista cuando sus contratos permiten transferencias normales a direcciones.Los activos siguen asociados a la dirección aunque todavía no exista código de contrato en ella.Podrán utilizarse una vez que el contrato previsto se despliegue correctamente.Este comportamiento puede simplificar la incorporación a wallets y el diseño de aplicaciones contrafactuales.También crea un riesgo importante, ya que los activos pueden quedar inaccesibles si la factory, el salt o el código de inicialización previstos son incorrectos.Antes de enviar un valor significativo a una dirección contrafactual, los usuarios deben verificar que el despliegue puede realizarse.

¿Puede una dirección CREATE2 vacía mantener fondos?

Sí. Una dirección sin código puede tener un saldo de criptomoneda nativa y saldos de tokens.Un saldo positivo por sí solo no impide el despliegue CREATE2 en esa dirección.La regla de colisión de la EVM se centra en si la dirección de destino tiene un nonce distinto de cero o código no vacío.Este diseño es necesario para que las cuentas contrafactuales reciban fondos antes del despliegue.Después del despliegue, el código del contrato y las reglas de autorización determinan cómo pueden utilizarse esos activos.

Reglas de colisión de CREATE2

El despliegue CREATE2 falla si la dirección de destino ya tiene código no vacío o un nonce distinto de cero.Así se impide que una factory sobrescriba un contrato existente en la misma dirección.La regla se aplica aunque el nuevo código de inicialización calculase correctamente esa dirección.El despliegue también falla si el código de inicialización revierte, se queda sin gas, devuelve código no válido o incumple otra regla de creación de contratos.Las factories deben gestionar un resultado cero del opcode CREATE2 y, cuando sea posible, devolver un error útil.Una colisión no significa que la función hash Keccak se haya vulnerado criptográficamente.Normalmente significa que, conforme a las reglas de cuentas de la EVM, el destino determinista ya está ocupado.

¿Pueden dos despliegues distintos generar la misma dirección CREATE2?

Dos intentos de despliegue calculan la misma dirección si utilizan la misma dirección de factory, el mismo salt y el mismo hash del código de inicialización.En teoría, códigos de inicialización distintos podrían tener el mismo hash, pero se considera computacionalmente inviable encontrar una colisión práctica de Keccak-256 conforme a los supuestos de seguridad actuales.Como solo se utilizan los últimos 20 bytes de la dirección, las colisiones aleatorias son teóricamente posibles, igual que con otras direcciones de Ethereum.Con las capacidades de computación actuales, sigue siendo inviable crear una colisión elegida.Aun así, los desarrolladores no deben considerar que una dirección visualmente parecida demuestra que las entradas de despliegue subyacentes sean correctas.

Reutilización del salt

Una factory puede reutilizar el mismo salt si el código de inicialización es distinto, porque el hash del código de inicialización producirá una dirección diferente.La misma factory no puede desplegar correctamente dos veces el mismo código de inicialización con el mismo salt mientras el destino original siga ocupado.Un proyecto puede prohibir la reutilización del salt a nivel de aplicación para facilitar el seguimiento de la intención del despliegue.Una factory pública puede permitir que cualquiera envíe un salt utilizado anteriormente, ya que la fórmula completa también incluye el hash del código de inicialización.La unicidad del salt no constituye por sí sola una propiedad de seguridad completa.Es necesario examinar la combinación completa de factory, salt y código de inicialización.

Front-running de un despliegue CREATE2

Una transacción CREATE2 pendiente puede ser visible antes de incluirse en un bloque.Otro usuario puede copiar la llamada a la factory e intentar desplegar primero el contrato.Si una factory sin permisos utiliza el mismo salt y un código de inicialización idéntico, el despliegue copiado debería crear el mismo compromiso de código en la misma dirección prevista.La transacción original podría entonces fallar porque el destino ya estaría ocupado.Aun así, esto puede causar problemas de sincronización, gasto de gas y alteraciones en el flujo de trabajo de la aplicación.El riesgo es mayor cuando el comportamiento del constructor depende de datos del entorno que cambian, como datos del bloque, el origen de la transacción, el estado de contratos externos o parámetros de la factory que dependen del llamante.

La propuesta actual sobre factories deterministas recomienda utilizar factories conocidas para contratos plenamente deterministas, en lugar de despliegues cuyos resultados dependan del entorno de ejecución.

Riesgo de front-running del constructor

Una dirección CREATE2 compromete el código de inicialización, pero no fija todo el estado externo que el constructor pueda consultar.Un atacante que controle el momento del despliegue puede hacer que el constructor observe un precio, valor de bloque, entrada de registro o estado de contrato externo distinto.El bytecode de ejecución o el almacenamiento inicial resultantes podrían diferir de lo esperado por el usuario original.Siempre que sea posible, el constructor debe recibir la configuración crítica mediante argumentos comprometidos, en vez de consultar un estado externo mutable.Después de la creación, los scripts de despliegue deben verificar el bytecode de ejecución, la propiedad, el almacenamiento y los eventos emitidos.

Riesgo de una función de inicialización sin protección

Los contratos proxy y los clones mínimos suelen utilizar funciones de inicialización en lugar de constructores.La función de inicialización establece la propiedad, los permisos, los detalles de implementación u otro estado esencial después del despliegue.Una dirección CREATE2 puede predecirse, pero eso no protege automáticamente la función de inicialización.Si el despliegue y la inicialización se realizan en transacciones distintas, un atacante puede llamar primero a la función de inicialización.La factory debe inicializar el contrato de forma atómica durante la transacción de despliegue o aplicar una autorización estricta.Una dirección determinista no compensa un diseño de inicialización sin protección.

Factories CREATE2

Una factory CREATE2 es un contrato inteligente reutilizable que recibe un salt y un código de inicialización y ejecuta el opcode CREATE2.Una factory permite que las cuentas de propiedad externa y otros contratos inteligentes utilicen el despliegue determinista mediante una interfaz uniforme.Una factory mínima puede aceptar código arbitrario sin requerir permisos.Una factory especializada puede desplegar únicamente implementaciones de cuentas o módulos de aplicación aprobados.Los desarrolladores deben examinar el bytecode de ejecución, el historial de despliegue, los permisos, la gestión de fallos y el comportamiento de transferencia de valor de la factory.Una factory maliciosa puede modificar entradas, restringir el despliegue, retener fondos o ejecutar código inesperado.

Singleton factories

Una singleton factory es una factory determinista que pretende existir en la misma dirección en varias redes EVM.Una dirección de factory compartida ayuda a los desarrolladores a derivar la misma dirección de contrato hijo en cada red compatible.

ERC-2470 propuso una singleton factory CREATE2 sin permisos para despliegues deterministas.

La propuesta utilizó un método de despliegue sin clave para que la factory pudiera crearse en una dirección conocida en redes compatibles.A julio de 2026, ERC-2470 figura como Stagnant en el repositorio de EIP, aunque el concepto más amplio de factory determinista sigue siendo relevante.El estado de una propuesta en un repositorio y el estado real de despliegue de un contrato son cuestiones distintas.

Despliegue determinista en varias cadenas

CREATE2 puede ayudar a desplegar un contrato en la misma dirección en varias redes EVM.Para obtener el mismo resultado, es necesario utilizar la misma dirección de factory CREATE2, el mismo salt y el mismo hash del código de inicialización en cada red.Usar la misma wallet de despliegue de la aplicación no basta si esa wallet llama a direcciones de factory distintas.Los metadatos del compilador, el enlazado de bibliotecas, los argumentos del constructor y los cambios en el código fuente del contrato pueden modificar el hash del código de inicialización.El ID de cadena no se incluye directamente en la fórmula básica CREATE2.Sin embargo, un constructor o una herramienta de despliegue pueden incluir datos específicos de la cadena que modifiquen el código de inicialización o el estado del contrato desplegado.Los desarrolladores deben verificar por separado el código desplegado en cada red, aunque las direcciones coincidan.

Ventajas de desplegar la misma dirección en varias cadenas

Las direcciones de contrato idénticas reducen el número de direcciones que deben almacenar las wallets, interfaces, bibliotecas de software y otros contratos.Un desarrollador puede utilizar la misma dirección constante en varias redes compatibles.Es menos probable que los usuarios copien la dirección del contrato de una red equivocada.Las cuentas de contratos inteligentes también pueden presentar una dirección uniforme en varias cadenas.Esto mejora la usabilidad, pero puede generar una falsa sensación de seguridad si una red contiene código o configuración distintos en la misma dirección.La dirección siempre debe evaluarse junto con el identificador de cadena y el bytecode verificado.

Propuestas actuales sobre factories deterministas

La infraestructura de factories deterministas sigue evolucionando a medida que se crean más redes EVM y rollups.

A julio de 2026, EIP-7997 está en fase de revisión y propone exigir formalmente una factory determinista muy utilizada en una dirección especificada en las cadenas EVM.

La propuesta no es definitiva y no debe considerarse una garantía universal para todas las redes.

ERC-7955 sigue siendo un borrador de propuesta para iniciar sin permisos una factory CREATE2 universal mediante las capacidades de EIP-7702.

Estas propuestas abordan el hecho de que CREATE2, por sí solo, no resuelve el problema de situar la factory original en la misma dirección en todas partes.Antes de confiar en una factory universal, los desarrolladores deben comprobar el estado actual de la propuesta y el estado real de la red.

CREATE2 y la abstracción de cuentas

La abstracción de cuentas permite que las cuentas de contratos inteligentes utilicen reglas de validación y ejecución programables.Una wallet puede admitir varios firmantes, claves de acceso (passkeys), guardianes de recuperación, límites de gasto, operaciones agrupadas y patrocinio de comisiones.CREATE2 permite que la factory de la wallet calcule la dirección de la cuenta antes de desplegar el contrato de la wallet.El usuario puede recibir fondos en esa dirección y desplegar la cuenta cuando se procese la primera operación.ERC-4337 puede incluir datos de factory para crear una cuenta cuando el remitente aún no exista.La dirección contrafactual de la cuenta debe coincidir con la dirección que produce la llamada a la factory.Si la factory despliega código en otra dirección, la operación de la cuenta falla conforme al flujo de validación del estándar.

CREATE2 y las firmas previas al despliegue

Una cuenta de contrato contrafactual puede necesitar firmar un mensaje de autenticación antes de desplegarse.La verificación habitual de firmas de contratos no puede llamar a la cuenta porque aún no existe código de ejecución en esa dirección.

ERC-6492 define un formato envolvente para verificar firmas realizadas en nombre de cuentas de contratos previas al despliegue.

El proceso de verificación puede simular o realizar el despliegue necesario mediante la factory antes de comprobar la lógica de firma del contrato.El estándar recomienda los contratos CREATE2 porque sus direcciones son previsibles.Las firmas de cuentas contrafactuales deben verificarse mediante el estándar de firma de contratos aplicable, no tratarse como firmas ordinarias de cuentas de propiedad externa.

CREATE2 y las cuentas vinculadas a tokens

Una cuenta vinculada a un token es una cuenta de contrato inteligente asociada a un token no fungible.La cuenta puede mantener criptomonedas, tokens, NFT y otros activos on-chain.

ERC-6551 utiliza CREATE2 para que las direcciones de las cuentas vinculadas a tokens puedan existir de forma contrafactual antes del despliegue.

Esto permite transferir activos a la cuenta de un token antes de pagar para desplegar el contrato de la cuenta.Conforme a las reglas del estándar, la dirección de la cuenta depende del registro, la implementación, el salt, el identificador de blockchain, el contrato del token y el identificador del token.La titularidad del NFT que la controla determina quién puede normalmente ejecutar acciones a través de la cuenta vinculada al token.

CREATE2 y los canales de estado

Los canales de estado permiten a los participantes interactuar repetidamente off-chain y utilizar un contrato blockchain para hacer cumplir el resultado final o resolver una disputa.Los participantes pueden acordar de antemano el código y la dirección de un contrato de resolución de disputas.CREATE2 les permite calcular esa dirección sin desplegar el contrato inmediatamente.Pueden hacer referencia al contrato contrafactual durante todo el proceso off-chain.El contrato solo debe desplegarse cuando sea necesario hacer cumplir el acuerdo.Este fue uno de los casos de uso originales descritos en EIP-1014.

CREATE2 y los contratos proxy mínimos

Un proxy mínimo es un contrato pequeño que delega las llamadas en un contrato de implementación.Una factory puede combinar proxies mínimos con CREATE2 para crear direcciones previsibles de cuentas o aplicaciones.La dirección de implementación puede formar parte del código de inicialización del proxy.Por tanto, cambiar la dirección de implementación puede cambiar la dirección prevista del proxy.Algunas factories incluyen parámetros de inicialización en el almacenamiento del proxy desplegado durante la misma transacción.Los desarrolladores deben verificar si el compromiso determinista abarca la implementación, los datos de inicialización o solo una estructura genérica de proxy.

CREATE2 y los contratos actualizables

CREATE2 no es por sí mismo un sistema de actualización.Un contrato desplegado con CREATE2 puede ser actualizable si utiliza un proxy u otra arquitectura de actualización explícita.En ese diseño, el proxy permanece en la dirección determinista, mientras que su referencia de implementación puede cambiar.La seguridad de las actualizaciones depende del administrador del proxy, las reglas de gobernanza, los plazos y la verificación de la implementación.Una dirección proxy determinista no garantiza un comportamiento inmutable.Los usuarios deben revisar los permisos de actualización, en lugar de suponer que una dirección previsible implica que el código sea permanente.

CREATE2, SELFDESTRUCT y el redespliegue

Algunos diseños antiguos de CREATE2 utilizaban

para eliminar un contrato y, posteriormente, desplegar otro comportamiento en la misma dirección.

Estos diseños solían llamarse contratos metamórficos.

Las actuales reglas de SELFDESTRUCT de EIP-6780 de Ethereum generalmente impiden que un contrato de larga duración elimine su código y almacenamiento.

Cuando SELFDESTRUCT lo llama un contrato que no se ha creado en la misma transacción, transfiere el saldo, pero no elimina el código, el almacenamiento ni la cuenta.Por ello, los patrones de actualización habituales que dependían de destruir un contrato desplegado y volver a crearlo en la misma dirección CREATE2 ya no funcionan.EIP-6780 recomienda expresamente utilizar diseños de actualización consolidados basados en proxies en lugar del redespliegue con CREATE2 para conseguir actualizaciones.SELFDESTRUCT sigue obsoleto y los nuevos sistemas no deben depender de que su comportamiento permanezca inalterado indefinidamente.

Riesgo de los contratos metamórficos

Un contrato metamórfico pretende cambiar el código que opera en una dirección estable mediante la destrucción y el redespliegue.Antes de las restricciones actuales de SELFDESTRUCT, este patrón podía hacer especialmente peligroso confiar en una dirección.Un usuario podía verificar una versión del código y, posteriormente, interactuar con otra distinta en la misma dirección.Las reglas actuales de Ethereum han puesto fin al patrón general de redespliegue de contratos de larga duración, pero otras redes antiguas o entornos EVM pueden aplicar un comportamiento distinto de SELFDESTRUCT.Las herramientas de seguridad deben evaluar las reglas de la blockchain y del periodo de bloques específicos que se analizan.Las transacciones históricas deben interpretarse conforme a las reglas del protocolo vigentes en el momento en que se produjeron.

Costes de gas de CREATE2

CREATE2 utiliza una estructura de gas similar a la de CREATE normal y añade un coste por calcular el hash del código de inicialización.EIP-1014 define este coste adicional de hash en función del número de bloques de 32 bytes del código de inicialización.Por tanto, un código de inicialización más grande requiere más gas para derivar la dirección y también para la memoria y la ejecución del constructor.El despliegue también paga por almacenar el bytecode de ejecución resultante y ejecutar las operaciones del constructor.Las tarifas de gas de la red pueden cambiar con las actualizaciones del protocolo, por lo que las estimaciones fijas no deben considerarse permanentes.Una cuenta contrafactual con fondos predepositados puede seguir necesitando suficiente criptomoneda nativa o un patrocinador de comisiones para pagar su despliegue posterior.

Límites de tamaño del código de inicialización

Ethereum aplica límites y mediciones de gas al código de inicialización de los contratos.

EIP-3860 introdujo una medición adicional del init code y un tamaño máximo para el código de inicialización.

Estas reglas se aplican tanto a los despliegues CREATE como a los CREATE2.Las factories grandes no deben dar por hecho que es posible enviar correctamente una lógica de constructor de tamaño ilimitado.Las herramientas de desarrollo deben comprobar que el código de inicialización final compilado respeta los límites actuales de la red.

Direcciones de contrato personalizadas

Los desarrolladores pueden probar distintos valores de salt hasta que la dirección CREATE2 prevista contenga un prefijo o patrón deseado.Este proceso se conoce como búsqueda de una dirección de contrato personalizada.Un prefijo corto y reconocible puede facilitar la identificación visual de una dirección.No mejora la seguridad ni la autoridad del contrato inteligente.Los usuarios deben verificar la dirección completa, ya que los estafadores pueden generar direcciones con prefijos y sufijos similares.Una dirección personalizada nunca debe sustituir la verificación del bytecode ni los registros de despliegue de confianza.

CREATE2 y el envenenamiento de direcciones

Los ataques de envenenamiento de direcciones intentan hacer que una dirección engañosa aparezca en el historial de transacciones o en la interfaz de la wallet de un usuario.Un atacante puede generar una dirección con caracteres parecidos a los de una dirección de confianza.CREATE2 puede facilitar la búsqueda de direcciones de contrato con patrones visuales elegidos mediante la variación del salt.El ataque no requiere vulnerar CREATE2 ni Keccak-256.Se basa en que los usuarios solo comprueben el principio o el final de una dirección.Antes de enviar criptomonedas, los usuarios deben verificar la dirección completa o utilizar una libreta de direcciones de confianza.

Confusión de direcciones entre cadenas

Una misma dirección hexadecimal puede existir en varias redes EVM.Según la red, puede contener el mismo código, un código distinto o ningún código.Un plan de despliegue determinista puede crear direcciones idénticas, pero el identificador de blockchain sigue siendo esencial.Enviar activos a la dirección correcta en la red equivocada puede hacer que resulten inaccesibles desde la aplicación prevista.Las wallets y las interfaces deben mostrar claramente tanto la dirección del contrato como la red seleccionada.Los desarrolladores deben verificar los hashes del código y la configuración en cada cadena admitida.

Riesgos de confianza en la factory

El cálculo de una dirección determinista presupone que la factory seleccionada se comporta como se espera.Una factory puede modificar el salt o el código de inicialización, aplicar controles de acceso, cobrar comisiones o transferir inesperadamente el valor del despliegue.Una factory actualizable puede cambiar después de la revisión inicial del desarrollador.Una factory controlada por una sola clave privada puede dejar de estar disponible o volverse maliciosa si la clave se pierde o queda comprometida.Las factories sin permisos reducen algunos riesgos de control, pero pueden generar problemas de front-running y spam.Antes de confiar en direcciones previstas, los desarrolladores deben verificar el código de ejecución de la factory y su mecanismo de despliegue.

Riesgos del compilador y los metadatos

Distintas versiones del compilador de Solidity pueden generar bytecode de creación diferente a partir del mismo código fuente.Los ajustes del compilador, como las iteraciones de optimización, la configuración de metadatos, las bibliotecas enlazadas y la versión de EVM de destino, también pueden modificar el bytecode.Una pequeña diferencia en el bytecode genera un hash de código de inicialización y una dirección CREATE2 diferentes.Los desarrolladores deben fijar la versión del compilador y la configuración de compilación utilizadas para el despliegue determinista.Los procedimientos de compilación reproducible ayudan a los usuarios independientes a confirmar que el código fuente publicado genera el bytecode desplegado.Copiar solo el código fuente de Solidity, sin los ajustes de compilación, puede no bastar para reproducir la dirección prevista.

Enlace de bibliotecas

Un contrato Solidity puede contener marcadores de posición que deban sustituirse por direcciones de bibliotecas desplegadas antes de la creación.El bytecode de creación enlazado forma parte del código de inicialización CREATE2.Cambiar la dirección de una biblioteca modifica la dirección prevista del contrato.Por tanto, un despliegue cross-chain puede no producir direcciones idénticas si las bibliotecas enlazadas están ubicadas en direcciones diferentes.Los proyectos que busquen direcciones idénticas en varias cadenas pueden tener que desplegar determinísticamente las bibliotecas antes de desplegar los contratos que dependen de ellas.

Lista de verificación de CREATE2

Verifica la blockchain y la dirección de la factory antes de calcular el destino previsto.Confirma la codificación exacta del salt de 32 bytes.Utiliza bytecode de creación, no bytecode de ejecución.Incluye los argumentos del constructor codificados según ABI en el código de inicialización.Fija la versión del compilador, los ajustes de optimización, las bibliotecas enlazadas y la configuración de metadatos.Comprueba si la dirección prevista ya tiene código o un nonce distinto de cero.Simula la llamada a la factory y revisa cualquier dependencia del constructor respecto a estados externos.Después del despliegue, compara la dirección real, el bytecode de ejecución, la configuración de almacenamiento, el propietario, la implementación y los eventos emitidos con el resultado previsto.

Ventajas de CREATE2

CREATE2 permite conocer la dirección de un contrato antes del despliegue.Permite crear wallets y contratos contrafactuales que pueden recibir activos antes de que se genere el código.Elimina la dependencia del nonce de despliegue cambiante de la factory.Puede crear direcciones de aplicación coherentes en redes EVM compatibles cuando coinciden todas las entradas necesarias.Permite diseñar de forma eficiente canales de estado y contratos de resolución de disputas.Puede simplificar la gestión de direcciones en wallets, bibliotecas de software, contratos inteligentes e interfaces multicadena.También permite crear sistemas de despliegue reproducibles en los que los usuarios verifican de forma independiente el destino esperado.

Limitaciones de CREATE2

CREATE2 no garantiza que el contrato llegue a desplegarse.No garantiza que la factory sea fiable ni que esté disponible en todas las redes.No garantiza que direcciones idénticas contengan el mismo código de ejecución o estado en distintas cadenas.No protege un proxy sin inicializar, un constructor inseguro, un administrador comprometido ni un contrato inteligente vulnerable.No permite sobrescribir un contrato existente cuando la dirección de destino tiene código o un nonce distinto de cero.Las reglas actuales de SELFDESTRUCT impiden los patrones generales de actualización basados en destruir y volver a desplegar un contrato de larga duración.También genera riesgos operativos si los usuarios envían fondos a una dirección prevista sin verificar completamente las entradas del despliegue.

Preguntas frecuentes

¿Qué es CREATE2 en términos sencillos?

CREATE2 es una instrucción de la EVM que permite a los desarrolladores calcular la dirección de un contrato inteligente antes de desplegarlo.

¿Qué significa despliegue determinista?

Significa que las mismas entradas de despliegue definidas producen la misma dirección calculada para el contrato.

¿Qué EIP introdujo CREATE2?

CREATE2 se introdujo mediante EIP-1014.

¿Cuál es el opcode CREATE2?

El opcode CREATE2 es

.

¿Qué entradas determinan una dirección CREATE2?

La dirección depende de la dirección de la factory CREATE2, un salt de 32 bytes y el hash del código de inicialización.

¿CREATE2 utiliza un nonce?

CREATE2 no utiliza en su fórmula de dirección el nonce cambiante de creación de contratos de la factory.

¿Se incluye el remitente de la transacción en la fórmula CREATE2?

Se incluye el contrato que ejecuta directamente CREATE2, que normalmente es la factory y no la wallet externa que la llama.

¿Qué es un salt CREATE2?

Es un valor de 32 bytes que permite distinguir despliegues deterministas y generar direcciones diferentes.

¿El salt CREATE2 debe ser secreto?

No. Normalmente no es necesario mantenerlo en secreto.

¿Qué es el init code?

Es el código temporal de creación que ejecuta el constructor y devuelve el bytecode de ejecución que se almacena en la nueva dirección.

¿CREATE2 aplica un hash al bytecode de ejecución?

La fórmula de la dirección aplica un hash al código de inicialización; no aplica directamente un hash solo al bytecode de ejecución final.

¿Los argumentos del constructor cambian la dirección CREATE2?

Sí. Los argumentos del constructor de Solidity se incluyen en el código de inicialización y normalmente cambian la dirección prevista.

¿Se puede predecir off-chain una dirección CREATE2?

Sí. La dirección se puede calcular localmente sin enviar una transacción a la blockchain.

¿Puede una dirección CREATE2 aún no desplegada recibir criptomonedas?

Sí. Una dirección prevista puede recibir criptomonedas nativas y tokens compatibles antes del despliegue del contrato.

¿Es seguro enviar fondos a una dirección aún no desplegada?

Es arriesgado si no se han verificado la factory, el salt, el código de inicialización, la viabilidad del despliegue y las futuras reglas de autorización.

¿Puede CREATE2 desplegar sobre un contrato existente?

No. El despliegue falla si la dirección de destino ya tiene código no vacío o un nonce distinto de cero.

¿Puede CREATE2 desplegar dos veces el mismo contrato?

La misma factory, el mismo salt y el mismo código de inicialización no pueden desplegarse correctamente dos veces mientras el destino original siga ocupado.

¿Se puede reutilizar el mismo salt?

Sí. El mismo salt puede generar direcciones distintas si cambia la factory o el hash del código de inicialización.

¿Alguien puede hacer front-running de un despliegue CREATE2?

Alguien puede copiar una llamada pública a una factory y desplegar primero, lo que puede alterar los tiempos y resultar peligroso si el comportamiento del constructor depende de datos externos cambiantes.

¿CREATE2 garantiza el mismo código en varias cadenas?

No. Para obtener direcciones idénticas deben coincidir las entradas, pero el entorno del constructor, la inicialización, la configuración y el estado de la red aún pueden producir diferencias importantes.

¿Cómo puede CREATE2 crear la misma dirección en varias redes?

Debe utilizarse la misma dirección de factory, el mismo salt y el mismo hash del código de inicialización en todas las redes compatibles.

¿El ID de cadena forma parte de la fórmula CREATE2?

La fórmula básica no incluye directamente el ID de cadena, aunque el código de despliegue o los argumentos del constructor pueden incluir información específica de la cadena.

¿Qué es una factory CREATE2?

Es un contrato inteligente que ejecuta despliegues deterministas para usuarios u otros contratos.

¿Qué es una singleton factory?

Es un desplegador CREATE2 que pretende existir en una dirección conocida e idéntica en varias redes.

¿Qué es el despliegue contrafactual?

Consiste en utilizar o referenciar una dirección de contrato previsible antes de que se haya desplegado el contrato.

¿Cómo ayuda CREATE2 a las wallets de contratos inteligentes?

Permite calcular y financiar una dirección de wallet antes de crear el contrato de la wallet.

¿Qué relación tiene CREATE2 con ERC-4337?

Las factories de cuentas ERC-4337 suelen utilizar CREATE2 para derivar y desplegar direcciones previsibles de cuentas de contratos inteligentes.

¿Puede un contrato aún no desplegado firmar mensajes?

ERC-6492 proporciona un método para verificar firmas asociadas a determinadas cuentas de contratos contrafactuales antes del despliegue.

¿CREATE2 es un mecanismo de actualización?

No. La capacidad de actualización requiere un diseño independiente basado en proxy o gobernanza.

¿Puede SELFDESTRUCT vaciar un contrato para volver a desplegarlo con CREATE2?

Las reglas actuales de Ethereum suelen conservar el código y el almacenamiento de los contratos establecidos, por lo que los patrones de actualización de larga duración basados en destruir y volver a desplegar ya no funcionan.

¿Qué es un contrato metamórfico?

Es un diseño antiguo que pretende cambiar el código de una dirección mediante la destrucción y el redespliegue determinista.

¿CREATE2 cuesta más gas que CREATE?

CREATE2 añade el coste de calcular el hash del código de inicialización, además de los costes habituales de creación, memoria, constructor y almacenamiento del código.

¿CREATE2 puede generar una dirección personalizada?

Sí. Los desarrolladores pueden probar muchos valores de salt hasta que la dirección prevista contenga un patrón visual deseado.

¿Una dirección CREATE2 personalizada mejora la seguridad?

No. Un prefijo o sufijo reconocible no demuestra que el código sea seguro, que la propiedad sea legítima ni que la dirección sea auténtica.

¿Por qué no coincidía mi dirección CREATE2 prevista con la del despliegue?

Entre las causas habituales están una factory equivocada, una codificación incorrecta del salt, un resultado distinto del compilador, una biblioteca enlazada incorrecta, los argumentos del constructor o confundir el bytecode de creación con el de ejecución.

¿Cómo puedo verificar un despliegue CREATE2?

Vuelve a calcular la dirección con las entradas exactas y compara el código de ejecución desplegado, el almacenamiento, el propietario, la implementación y los eventos con los valores esperados.

Conclusión

El despliegue determinista mediante CREATE2 permite calcular la dirección de un contrato inteligente compatible con Ethereum antes de que exista on-chain.La dirección se deriva de un prefijo fijo, la dirección de la factory CREATE2, un salt de 32 bytes y el hash del código de inicialización.Los argumentos del constructor, el resultado del compilador, las bibliotecas enlazadas y los ajustes de compilación pueden modificar el código de inicialización y, por tanto, la dirección.CREATE2 permite crear cuentas inteligentes contrafactuales, canales de estado, cuentas vinculadas a tokens, componentes de aplicaciones previsibles y despliegues multicadena en la misma dirección.Una dirección prevista puede recibir criptomonedas antes del despliegue, pero los activos pueden quedar inaccesibles si no es posible crear el contrato previsto.Para obtener la misma dirección en distintas redes deben coincidir la factory, el salt y el hash del código de inicialización; esto no garantiza automáticamente que el código, el estado o la seguridad sean idénticos.Los desarrolladores también deben proteger las funciones de inicialización, evitar constructores dependientes del entorno, verificar el comportamiento de la factory y tener en cuenta los riesgos de front-running.Las reglas actuales de SELFDESTRUCT de Ethereum impiden los sistemas generales de actualización basados en destruir un contrato de larga duración y volver a crearlo en la misma dirección.Por tanto, CREATE2 debe considerarse una herramienta para derivar direcciones y desplegar contratos, no una solución automática de seguridad o actualización.Si se verifican cuidadosamente sus entradas, la factory, el bytecode y el proceso de inicialización, CREATE2 ofrece una base sólida para crear aplicaciones de criptomonedas previsibles y fáciles de usar.