Beim Aufladen einer Börse oder bei Zahlungen über das System ist eine der gefährlichsten Fehlannahmen, die Knotenrückmeldung „202 Accepted“ als Nachweis dafür zu betrachten, dass das Geld angekommen ist.
Ich habe den Transaktionslebenszyklus der @Dusk neu geordnet. Nachdem die Transaktion beim Knoten eingereicht wurde, bedeutet „202“ nur, dass der Knoten diese Daten akzeptiert hat und bereit ist, sie weiterzuleiten; es bedeutet nicht, dass sie bereits im echten Mempool ist, und erst recht nicht, dass sie gepackt, ausgeführt wurde oder die finale Bestätigung erreicht hat.
Eine einzelne Dusk L1-Transaktion durchläuft mindestens mehrere Phasen: Einreichen, Vorvalidierung, Eintritt in den lokalen Mempool, Netzwerkweiterleitung, Blockauswahl, Vertrag-Ausführung und die abschließende Finalisierung des Blocks. Selbst wenn die Transaktion bereits in einem akzeptierten Block ist, muss man prüfen, ob im Executed-Event der Error leer ist; wenn im Vertrag ein Fehler auftritt, können Nonce oder Phoenix Notes trotzdem verbraucht werden, und Gas muss ebenfalls bezahlt werden. Nur wenn der Blockstatus „Finalized“ ist, kann man die Transaktion als unwiderrufliches Ergebnis betrachten.
Das ist wie ein Liefersystem, das „vom Kurier übernommen“ anzeigt. Es beweist nur, dass der Kurier das Paket entgegengenommen hat, aber nicht, dass das Paket beim Empfänger angekommen ist.
Wenn die Börse also sieht, dass die Transaktionshash(es) vorhanden sind, und diese Transaktion zu früh verbucht, kann sie ersetzte Transaktionen, Transaktionen mit Ausführungsfehler oder Transaktionen, die noch nicht finalisiert wurden, fälschlich als echte Einzahlung betrachten. Am wichtigsten ist danach, worauf man als Nächstes achten sollte: wie die Wallet den Transaktionsstatus anzeigt, welche Art von finaler Bestätigung die Börse verwendet und welcher Anteil an Fällen vorliegt, in denen die Ausführung fehlschlägt, aber Gas bereits bezahlt wurde.
Eine Transaktion erhalten heißt nicht, dass sie ausgeführt wurde; ausgeführt heißt nicht, dass die finale Abrechnung erfolgt ist. Was ein Finanzsystem wirklich bestätigen muss, ist der letzte Schritt.#dusk $DUSK
Ich habe den Transaktionslebenszyklus der @Dusk neu geordnet. Nachdem die Transaktion beim Knoten eingereicht wurde, bedeutet „202“ nur, dass der Knoten diese Daten akzeptiert hat und bereit ist, sie weiterzuleiten; es bedeutet nicht, dass sie bereits im echten Mempool ist, und erst recht nicht, dass sie gepackt, ausgeführt wurde oder die finale Bestätigung erreicht hat.
Eine einzelne Dusk L1-Transaktion durchläuft mindestens mehrere Phasen: Einreichen, Vorvalidierung, Eintritt in den lokalen Mempool, Netzwerkweiterleitung, Blockauswahl, Vertrag-Ausführung und die abschließende Finalisierung des Blocks. Selbst wenn die Transaktion bereits in einem akzeptierten Block ist, muss man prüfen, ob im Executed-Event der Error leer ist; wenn im Vertrag ein Fehler auftritt, können Nonce oder Phoenix Notes trotzdem verbraucht werden, und Gas muss ebenfalls bezahlt werden. Nur wenn der Blockstatus „Finalized“ ist, kann man die Transaktion als unwiderrufliches Ergebnis betrachten.
Das ist wie ein Liefersystem, das „vom Kurier übernommen“ anzeigt. Es beweist nur, dass der Kurier das Paket entgegengenommen hat, aber nicht, dass das Paket beim Empfänger angekommen ist.
Wenn die Börse also sieht, dass die Transaktionshash(es) vorhanden sind, und diese Transaktion zu früh verbucht, kann sie ersetzte Transaktionen, Transaktionen mit Ausführungsfehler oder Transaktionen, die noch nicht finalisiert wurden, fälschlich als echte Einzahlung betrachten. Am wichtigsten ist danach, worauf man als Nächstes achten sollte: wie die Wallet den Transaktionsstatus anzeigt, welche Art von finaler Bestätigung die Börse verwendet und welcher Anteil an Fällen vorliegt, in denen die Ausführung fehlschlägt, aber Gas bereits bezahlt wurde.
Eine Transaktion erhalten heißt nicht, dass sie ausgeführt wurde; ausgeführt heißt nicht, dass die finale Abrechnung erfolgt ist. Was ein Finanzsystem wirklich bestätigen muss, ist der letzte Schritt.#dusk $DUSK