Wird die Transaktionsreihenfolge bei der Verwendung von Rückrufen garantiert beibehalten?

Wenn ich einen Vertrag auf Transaktionsereignisse in web3.py oder web3.js beobachte,

In web3.js

var contract = web3.eth.contract(abi);

var cInstance = contract.at(address);

var transferEvent = cInstance .Transfer({}, {fromBlock: 0, toBlock: 'latest'});    

transferEvent.watch((error, event) => {});

In web3.py

contract = w3.eth.contract(abi=contract_interface['abi'], address='0x....')

tfilter = contract.on('Transfer',{'fromBlock':0,'toBlock':'latest'})

def transfer_callback(tnx):
    print(tnx)

tfilter.watch(transfer_callback)

Ist garantiert, dass der Rückruf gemäß der Reihenfolge der Transaktionen ausgelöst wird? auch für vergangene Transaktionen . Beispielsweise wird die erste Transaktion zuerst ausgelöst, und die zweite Transaktion wird als zweites ausgelöst und so weiter.

Bitte beachten Sie, dass ich 0 Block bis zum neuesten filtere. Der obige Code sollte also auch alle vergangenen Transaktionsereignisse abrufen.

Ich bin mir nicht sicher, ob ich das richtig verstehe, aber wenn Sie mehrere Transaktionen auslösen und auf ihre Ereignisse warten, gibt es keine Garantie, welche Transaktion zuerst in einem öffentlichen Netzwerk verarbeitet wird. Miner entscheiden über die Reihenfolge der Transaktionen. Aber wenn Sie sich nicht für diese Reihenfolge interessieren, würde ich davon ausgehen, dass das erste Ereignis, das vom Knoten kommt, aus dem ersten verarbeiteten TX stammt.

Antworten (1)

Fast die gesamte Filterlogik befindet sich derzeit auf dem Knoten. Die genaue Antwort hängt also davon ab, ob Sie gethoder parityoder etwas anderes verwenden. Ich habe bei meinen begrenzten Ereignisexperimenten in den verschiedenen Knoten nie etwas anderes als Ereignisse in der Reihenfolge gesehen.

Update für Geth : Meiner Erfahrung nach kehren sie immer in der richtigen Reihenfolge zurück. Ich konnte keine Dokumentation finden, um dies zu bestätigen, und hatte keine Chance, sie im Go-Code zu finden. Ich würde nicht davon ausgehen, dass es immer so ist. Sie könnten immer einfach eine Assertion hinzufügen, die auslöst oder warnt, wenn die Blocknummer in einem der Protokolle abnimmt.

Ich führe den Knoten mit geth --rpc aus