Sind nicht alle Verträge, die einen Wert akzeptieren und nach der HF eingesetzt werden, tödlich anfällig für Replay-Angriffe?

Nehmen wir an, ich stelle einen Vertrag mit einer einfachen Funktion bereit, die einen gewissen Wert akzeptiert, und stelle dies auf der gegabelten Kette bereit. Der Vertrag endet an einer unvorhersehbaren Adresse U. Dann beginnen die Leute damit, einige Transaktionen mit ETH-Wert an den Vertrag zu senden und gleichzeitig die Funktion aufzurufen. Alles gut.

Aber alle diese eingehenden Transaktionen sind auf der ETC-Kette abspielbar und werden wahrscheinlich tatsächlich abgespielt (vorausgesetzt, es gibt ETC-Guthaben auf der Absenderadresse, was jederzeit in der Zukunft passieren kann, z. B. durch einen Dritten, der versehentlich Gelder dorthin sendet). . Das Problem dabei ist, dass es in der ETC-Kette keinen Vertrag an Adresse U gibt (selbst wenn ich denselben Vertrag auf dieser Kette einsetze, wird er an einer anderen Adresse landen), also wird Adresse U als extern kontrolliertes Konto behandelt, also der Wert übertragen und es wird keine Funktion aufgerufen (es scheint, dass das Datenfeld in der Transaktion bei Transaktionen auf extern kontrollierte Konten ignoriert wird). Der ETC-Wert ging also ins Leere und ist nicht erstattungsfähig.

Stimmt das oder mache ich etwas falsch? Es scheint, dass dies sehr oft passieren könnte.

Ich sage nicht, dass dies zu offensichtlichen Wertverlusten führen kann, aber es könnte ein potenzieller Angriffsvektor sein oder einfach nur Chaos verursachen.

Antworten (1)

Die Antwort ist nein. Die Vertragsadresse wird deterministisch erstellt, also zB. wenn die Vertragsbereitstellungstransaktion auf der anderen Kette wiederholt wird, wird der Vertrag dieselbe Adresse U auf beiden Ketten haben.

Nicht wirklich, weil die Nonce nicht (immer) gleich sein wird. Also, deterministisch, ja, aber nicht für beide Ketten identisch.
Die @bortzmeyer-Adresse ist dieselbe, wenn die tx wiedergegeben wird (wie bei Replay-Angriffen). Es wird auch dasselbe sein, wenn wir sicherstellen, dass die Bereitstellungsadresse und ihre Nonce identisch sind.