Wie handhaben Geth und Parity die Benachrichtigung von Clients über Ereignisse nach Reorgs?

Wenn Sie einen Ereignis-Listener mit Geth einrichten (ich nehme an, auch mit Parity), erhalten Sie Benachrichtigungen, wenn ein bestimmtes Ereignis in den Ereignisprotokollen angezeigt wird.

Manchmal findet eine Neuorganisation statt, und der Block, in dem dieses Ereignis stattfand, wird verwaist und verschwindet aus dem Hauptverlauf. Dieselbe Transaktion kann dazu führen, dass ein Ereignis in einem anderen Block ausgelöst wird.

Ist folgendes richtig?

  • Ein Ereignis wird immer ausgelöst, wenn ein Block, der dieses Ereignis generiert, in das gelangt, was der Knoten als Hauptkette betrachtet
  • Wenn es eine große Umstrukturierung gibt, werden mehrere Blocks tiefe Ereignisse fast gleichzeitig gesendet
  • Ein Ereignis wird auch dann noch einmal gesendet, wenn sein Inhalt (abgesehen von Block-Hash usw.) derselbe ist. Wenn Sie also beispielsweise auf einen Vertrag hören, der ein Ereignis auslöst, wenn es bezahlt wird, erhalten Sie dasselbe Ereignis möglicherweise zweimal, obwohl Sie Am Ende wird man nur einmal bezahlt

Gibt es Fallen für die unvorsichtigen oder interessanten implementierungsspezifischen Falten?

Antworten (1)

Ich glaube, Sie haben Recht, obwohl ich nicht glaube, dass ich es jemals getestet habe. Ereignisfilter in web3.js sind ein wenig seltsam – wenn Sie fromBlock auf früher als setzen 'latest', wird es bei historischen Ereignissen ausgelöst.

Wenn man sich die tatsächliche JSON-RPC-Spezifikation ansieht, scheint es, dass eth_getFilterChanges tatsächlich sagen wird, ob ein Ereignis über eine Neuorganisation entfernt wurde. Ich glaube zwar nicht, dass das aktuelle web3.js dies in großem Umfang ausnutzt, aber ein Client, der den RPC direkt verwendet (Schauder), könnte es besser wissen.

Daran hatte ich nicht gedacht, aber wenn Sie nach „Neueste“ filtern, frage ich mich, ob Sie immer noch ein Ereignis für einen Block erhalten, der sich nicht an der Spitze befindet, wenn die Neuorganisation stattfindet. Wörtlich genommen klingt es so, als würden Sie es nicht tun; Es sollte keinen Punkt geben, an dem Ihr Knoten den Block mit Ihrem Ereignis als spätesten betrachtet. Aber durch das Filtern nach „Neuesten“ erwarten die Leute im Allgemeinen, alles zu bekommen, was in der Hauptkette passiert, während sie filtern. Ich frage mich, welche dieser beiden Intuitionen Geth gewählt hat, um sie zu enttäuschen ...
Wie handhaben Geth und Parity die Benachrichtigung von Clients über Ereignisse nach Reorgs?
AntwortenHierDatenschutz-Bestimmungen1y, 0v