Beim Durchsuchen von Traces, die durch Parität generiert wurden, bin ich auf einen interessanten Fall gestoßen:
Vertrag 0xfec94608dea1f3609e4a93e56e01477d8a86de46wurde zweimal erstellt.
Beim ersten Mal in der Transaktion: 0xc0d8d11c5da64e025ac0bb0cc286ede65c2a0b7afeeb455f04d6479cc98edb7a. Die Transaktion ist fehlgeschlagen, Out of gasaber der Vertrag wurde erfolgreich erstellt.
Beim zweiten Mal wurde derselbe Vertrag mit demselben Code in Transaktion erstellt: 0x9c3ef34611bd24e254b2b6f339e2f196a57042e8261c069af944248d982c67b4.
Soweit ich weiß, hat der Vertrag dieselbe Adresse erhalten, weil er im Rahmen eines anderen Vertrags erstellt wurde. Die Vertragsadresse wird aus der Erstellervertragsadresse und ihrer Nonce generiert. Da die vorherige Erstellervertragstransaktion endete, Out of gaswurde die Nonce nicht erhöht und somit die gleiche Vertragsadresse.
Was wirklich passierte? Wurde der Vertrag wirklich in der ersten Transaktion erstellt? Sollte es nicht rückgängig gemacht werden? Zeigt Etherscanes richtig an? Was würde passieren, wenn bei der zweiten Transaktion der Vertrag mit einem anderen Code generiert wird?
BEARBEITEN: Ich habe das Problem den Parity GitHub-Problemen gemeldet
Ich denke, Sie haben Recht mit der Nonce und Etherscan gibt fälschlicherweise an, dass B zweimal erstellt wurde, nur die zweite ist gültig.
In der ersten Transaktion (Block 4930939) erstellt Vertrag A einen neuen Vertrag B. Aber die Transaktion „run out of gas and revert“ wird aufgerufen, wodurch die Erstellung von B und die Erhöhung der Nonce von A rückgängig gemacht werden.
Bei der zweiten Transaktion (Block 4932566) erstellt Vertrag A erneut B, die Transaktion wird abgeschlossen. Und aus diesem Blockvertrag B besteht.
Roman Frolow
Kuba
Namebazaar contract creator. Quelle hier verfügbar: github.com/district0x/name-bazaar/tree/master/resources/public/…