Cuanto más miraba la lógica de la dirección del contrato de Dusk, más destacaba un pequeño detalle.

En lugar de pensar solo en términos de la clave del desplegador + el nonce, el estado de ejecución de Dusk también lleva el registro de la altura actual del bloque y de cuántos contratos ya se han creado en ese bloque.

Eso trae una consecuencia interesante.

Si se despliegan dos contratos en el mismo bloque, las direcciones resultantes pueden depender de su posición en la secuencia de ejecución de ese bloque.

Así que, aunque ambas transacciones se hayan transmitido en un intervalo casi idéntico de tiempo, la dirección resultante podría ser distinta según cuál despliegue se procese primero.

Ese es un cambio sutil respecto a las suposiciones de predicción de direcciones a las que muchos desarrolladores de EVM están acostumbrados.

No hace que el diseño sea problemático de forma automática. Pero sí plantea una pregunta importante de herramientas:

Si estás construyendo una factory, un script de despliegue, un indexer o cualquier cosa que necesite conocer una dirección de contrato antes del despliegue, ¿cómo estás manejando esa dependencia?

No había cuestionado esa suposición hasta que miré con detenimiento el modelo de ejecución de Dusk.

Me gustaría oír de parte de desarrolladores que construyen sobre <a>@Dusk </a>

¿Alguna vez el orden de los bloques ha afectado una dirección de contrato precomputada?

#dusk $DUSK @Dusk