Mehrere Transaktionen von derselben Adresse mit denselben Details

Ich betreibe einen lokalen Ethereum-Knoten, der eine wahrnehmbare Zeit in Anspruch nimmt, um Blöcke abzubauen.

Ich versuche, eine kugelsichere Methode zum dynamischen Aufrufen von Transaktionsmethoden für einen Smart Contract von Ethereum zu entwickeln. Unser Produkt ermöglicht Benutzern die Integration mit Ethereum Smart Contracts, und es gibt keine Einschränkungen für die Benutzer unseres Produkts, wenn es um den Konsum von Smart Contracts geht. Meistens funktioniert meine Logik, akzeptiere, wenn ich zwei (2) oder mehr Transaktionen ziemlich gleichzeitig mit denselben Details veröffentliche. Da keine von beiden geschürft wurden, erhalten sie am Ende dieselbe Nonce von Geth (dh Geth 1.8.2-stable-b8b9f7f4 und web3.js 1.0.0-beta.28 unter nodejs 4.2.6), und es resultiert eine „Bekannte Transaktion“. .

Ich habe mehrere Strategien ausprobiert, um dieses Problem zu vermeiden, aber keine davon funktioniert konsequent:

  1. Setzen Sie "nonce" in der signTransaction-Methode auf null. Für zwei (2) geschlossene Transaktionen, beide ungemined, führt dies zu einem „Bekannte Transaktion“-Fehler.
  2. Setzen Sie "nonce" auf getTransactionCount() oder getTransactionCount("pending"), aber für zwei (2) geschlossene Transaktionen, die beide nicht abgebaut sind, wird der Fehler "Replacement Transaction Underpriced" angezeigt.
  3. Konstruieren Sie eine Logik, die sich an die „Nonce“ aus den vorherigen Transaktionen erinnert und sie mit dem Ergebnis getTransactionCount(„pending“) verschmilzt – führt immer noch zum Fehler „Replacement Transaction Underpriced“.

Ich weiß, dass dies wahrscheinlich ein Nischenfall ist, aber hat jemand eine Idee, wie man dieses Problem am besten angeht?

Könnten alle meine Probleme mit dem folgenden offenen Go-Eth-Bug #2880 zusammenhängen ?

Antworten (1)

Es gab einen netten Beitrag, in dem mehrere Alternativen beschrieben wurden, wie dieses Problem angegangen werden kann -> „ Concurrency Patterns for Account Nonce “ .

Geth Issue 2880 verweist auf eine ältere Version. Wir verwenden den Parameter „ausstehend“ für unser DAPP mit Geth 1.7.2 und es funktioniert einwandfrei, wenn sich die Transaktion im Pool für ausstehende Transaktionen befindet.