Quanto mais eu olhava para a lógica do endereço de contrato do Dusk, mais um pequeno detalhe se destacava.

Em vez de pensar apenas em termos da chave do implantador + nonce, o estado de execução do Dusk também acompanha a altura atual do bloco e quantos contratos já foram criados naquele bloco.

Isso gera uma consequência interessante.

Se dois contratos forem implantados no mesmo bloco, os endereços resultantes podem depender da posição deles na sequência de execução daquele bloco.

Então, mesmo que ambas as transações tenham sido enviadas quase exatamente no mesmo momento, o endereço resultante pode ser diferente dependendo de qual implantação é processada primeiro.

Isso representa uma mudança sutil em relação às premissas de previsão de endereços que muitos desenvolvedores de EVM estão acostumados.

Isso não torna o design automaticamente problemático. Mas cria uma questão importante de ferramentas:

Se você está construindo uma factory, um script de implantação, um indexer, ou qualquer coisa que precise saber o endereço de um contrato antes da implantação, como você está lidando com essa dependência?

Eu não tinha realmente questionado essa suposição até olhar com mais atenção para o modelo de execução do Dusk.

Fico curioso para ouvir de desenvolvedores que estão construindo sobre @Dusk

Você já teve a ordenação de blocos afetando um endereço de contrato pré-calculado?

#dusk $DUSK @Dusk