Je genauer ich mir die Adresslogik von Dusk ansah, desto mehr fiel mir ein kleines Detail auf.
Anstatt nur im Hinblick auf den Schlüssel eines Deployers + Nonce zu denken, verfolgt der Ausführungszustand von Dusk außerdem die aktuelle Blockhöhe und wie viele Verträge in diesem Block bereits erstellt wurden.
Das hat eine interessante Konsequenz.
Wenn zwei Verträge im selben Block bereitgestellt werden, können sich ihre resultierenden Adressen je nach ihrer Position in der Ausführungssequenz dieses Blocks unterscheiden.
Das bedeutet: Selbst wenn beide Transaktionen nahezu zur gleichen Zeit ausgesendet wurden, kann sich die resultierende Adresse unterscheiden, je nachdem, welche Bereitstellung zuerst verarbeitet wird.
Das ist eine subtile Abweichung von den Annahmen zur Adressvorhersage, an die sich viele EVM-Entwickler gewöhnt haben.
Es macht das Design nicht automatisch problematisch. Aber es wirft eine wichtige Frage für die Tooling-Praxis auf:
Wenn du einen Factory-Contract, ein Deployment-Skript, einen Indexer oder etwas Ähnliches baust, das eine Vertragsadresse vor der Bereitstellung kennen muss – wie gehst du mit dieser Abhängigkeit um?
Ich hatte diese Annahme eigentlich nie wirklich hinterfragt, bis ich mir das Ausführungsmodell von Dusk genauer angesehen habe.
Spannend, was Entwickler sagen, die auf @Dusk aufbauen.
Hat dich Block-Reihenfolge jemals bei einer vorher berechneten Vertragsadresse beeinflusst?
#dusk $DUSK @Dusk
Anstatt nur im Hinblick auf den Schlüssel eines Deployers + Nonce zu denken, verfolgt der Ausführungszustand von Dusk außerdem die aktuelle Blockhöhe und wie viele Verträge in diesem Block bereits erstellt wurden.
Das hat eine interessante Konsequenz.
Wenn zwei Verträge im selben Block bereitgestellt werden, können sich ihre resultierenden Adressen je nach ihrer Position in der Ausführungssequenz dieses Blocks unterscheiden.
Das bedeutet: Selbst wenn beide Transaktionen nahezu zur gleichen Zeit ausgesendet wurden, kann sich die resultierende Adresse unterscheiden, je nachdem, welche Bereitstellung zuerst verarbeitet wird.
Das ist eine subtile Abweichung von den Annahmen zur Adressvorhersage, an die sich viele EVM-Entwickler gewöhnt haben.
Es macht das Design nicht automatisch problematisch. Aber es wirft eine wichtige Frage für die Tooling-Praxis auf:
Wenn du einen Factory-Contract, ein Deployment-Skript, einen Indexer oder etwas Ähnliches baust, das eine Vertragsadresse vor der Bereitstellung kennen muss – wie gehst du mit dieser Abhängigkeit um?
Ich hatte diese Annahme eigentlich nie wirklich hinterfragt, bis ich mir das Ausführungsmodell von Dusk genauer angesehen habe.
Spannend, was Entwickler sagen, die auf @Dusk aufbauen.
Hat dich Block-Reihenfolge jemals bei einer vorher berechneten Vertragsadresse beeinflusst?
#dusk $DUSK @Dusk