Filter: Was ist „neu“ und „ausstehend“?

Ich möchte Konten auf eingehende Transaktionen überwachen (RPC/IPC-API) und eine Funktion aufrufen, wenn eines von mehreren überwachten Konten Ether erhält, das "bestätigt" wird, wie in "vor genügend vielen Blöcken, dass die Wahrscheinlichkeit doppelter Ausgaben besteht". sind vernachlässigbar".

Gibt es dazu eine Referenzimplementierung?

Ich schaue mir Filter an und die Wörter "ausstehend" und "neueste" tauchen immer wieder auf. Was meinen sie?

Antworten (2)

Neueste bedeutet der neueste Block, der sich bereits in Ihrer eigenen Kette befindet. Alle darin enthaltenen Transaktionen können als erfolgreich ausgeführt betrachtet werden. Sicherheitstechnisch kann es natürlich Reorgs geben, aber im Allgemeinen handelt es sich um ausgeführte Transaktionen.

Ausstehend ist dagegen die Sammlung von Transaktionen, die vom Netzwerk ausgeführt werden können (von denen Ihr eigener Node weiß), dies aber noch nicht getan haben. Ausstehend ist nützlich, um reaktive Benutzeroberflächen anzuzeigen, bei denen die Benutzeroberfläche sofort anzeigen kann, dass etwas eingeht, obwohl es keine Garantie dafür gibt, wann diese Transaktionen – falls überhaupt – erfolgreich ausgeführt werden.

Was genau meinst du mit "deine eigene Kette"? Auch "Sicherheitstechnisch kann es natürlich Reorgs geben" - genau, also wie messe/mildere ich das?
@spraff Ihr lokaler Knoten verwaltet seine eigene Kopie der Blockchain; "neueste" bedeutet, dass es sich im Kopfblock dieser Kette befindet. Sie können die Möglichkeit von Reorgs mindern, indem Sie zählen, wie viele Blöcke vom Kopf der Kette der betreffende TX entfernt ist, und ihn erst dann als vollständig akzeptiert betrachten, wenn er sich einige Blöcke unterhalb des Kopfs befindet (normalerweise als "Bestätigungen" angezeigt).
Ethereum ist ein dezentralisiertes System, daher können verschiedene Knoten das System in einem anderen Zustand sehen: zB wenn Sie aufholen/synchronisieren, sehen Sie nur einen älteren Zustand, bis Sie aufholen. Darüber hinaus werden Blockchains als „eventuell konsistent“ bezeichnet, was bedeutet, dass sich alle Knoten schließlich auf einen Zustand einigen, der aktuelle tatsächliche Zustand jedoch zwischen ihnen unterschiedlich sein kann. Ihre lokale Kette ist das, was Ihr eigener Knoten für den aktuellen Zustand hält. In Bezug auf Reorgs hängt es von den Mitteln ab, mit denen Sie arbeiten: Stellen Sie sicher, dass es mehr kostet, eine tiefgreifende Reorg (pow) durchzuführen, als Sie damit gewinnen können.
Wenn Sie z. B. Ether im Wert von ein paar Dollar (z. B. einen Kaffee) tauschen, kostet selbst eine kleine Reorg viel zu viel, um sich zu lohnen. Wenn Sie Millionen austauschen, sollten Sie einige Blöcke warten, um sicherzustellen, dass jemand nicht doppelt so viel Geld ausgibt, da es sich leicht lohnen kann, einen Cluster von GPUs bereitzustellen, um zu versuchen, diese Übertragung rückgängig zu machen.
Also, was ist das Kriterium, so etwas wie $reorg < k*$amount*2^confirmationsich annehme? Wenn ja, haben wir eine grobe Schätzung für den Koeffizienten?

Ideen zu einer „Referenzimplementierung“ finden Sie unter: Wie kann eine DApp eine Fork- oder Chain-Reorganisation mithilfe von web3.js oder zusätzlichen Bibliotheken erkennen?

Sicherlich wollen Sie auch wissen: Ab welcher Anzahl an Bestätigungen gilt Ethereum als sicher?


@Péters Antwort ist großartig und das einzige, was hinzugefügt werden muss, ist die web3.eth.defaultBlockDefinition:

"latest", der neueste Block (aktueller Kopf der Blockchain)

„pending“, der aktuell geschürfte Block (einschließlich schwebender Transaktionen)

pendingist gleich latestplus ausstehende Transaktionen (diejenigen, die nicht in einen Block geschürft wurden).

Dies ist eine schlechte Definition, die aktualisiert werden muss. Wie Peter bereits erwähnte, umfasst „ausstehend“ alle bekannten Transaktionen im Mem-Pool, nicht nur das, was in den aktuell abgebauten Block passen könnte, zumal die meisten Nodes keine Miner sind.
@GViz Das ist ein fairer Kommentar und ich denke, sie sind offen für eine PR zum Ändern: github.com/ChainSafe/web3.js/blob/1.x/docs/web3-eth.rst#L193