WAS, WENN EINE BLOCKCHAIN-TRANSAKTION NICHT FALSCH, SONDERN NUR ZU FRÜH IST?
Ich betrachte eine kleine Änderung in Rusk v1.7.0, die mich kurz innehalten lässt. Sie betrifft Moonlight-Transaktionen, die mit einer zukünftigen Nonce ankommen. Anstatt sie sofort abzulehnen, kann Rusk sie vorübergehend in eine Warteschlange stellen, während die Nonce-Lücke sich schließt.
Das bringt mich zum Nachdenken über den Unterschied zwischen ungültig und zu früh. Wenn der Knoten noch auf eine frühere Transaktion wartet, kann die nächste einfach weiter vorn in der Sequenz liegen. Rusk verwendet dafür eine begrenzte Retry-Warteschlange. Außerdem gibt es ein Deferred-Event aus, während die Transaktion wartet.
Der einfachste Vergleich für mich ist eine Banküberweisung. Überweisung Nummer zwei erreicht das System, bevor Überweisung Nummer eins dort ankommt. Ich gehe nicht automatisch davon aus, dass Nummer zwei schlecht ist. Zuerst will ich wissen, ob das System nur auf Nummer eins wartet.
Das macht auch diese @Dusk detail für mich interessant. Die HTTP-API kann 202 Accepted zurückgeben, wenn eine Transaktion weitergeleitet wurde. Aber das bedeutet nicht, dass sie bereits im Mempool ist oder finalisiert wurde. Dusk’ Dokumentation sagt sogar, dass die lokale mempoolTxs-Ansicht zukünftige-Nonce-Transaktionen ausschließt, die in der Prequeue warten.
Jetzt bin ich bei dem „deferred“-Teil hängen geblieben. Wenn ein Wallet oder eine Börse dieses Event sieht, was sollte es dann tatsächlich mit der Transaktion machen? Soll es warten, bis die Transaktion weiterkommt, oder gibt es ein anderes Signal, auf das es sich verlassen sollte?
Ich neige dazu, sie im Blick zu behalten. Aber ich möchte trotzdem wissen, wie echte Integrationen diese Wartezeit handhaben.#dusk
$METAB $STAR $DUSK
Ich betrachte eine kleine Änderung in Rusk v1.7.0, die mich kurz innehalten lässt. Sie betrifft Moonlight-Transaktionen, die mit einer zukünftigen Nonce ankommen. Anstatt sie sofort abzulehnen, kann Rusk sie vorübergehend in eine Warteschlange stellen, während die Nonce-Lücke sich schließt.
Das bringt mich zum Nachdenken über den Unterschied zwischen ungültig und zu früh. Wenn der Knoten noch auf eine frühere Transaktion wartet, kann die nächste einfach weiter vorn in der Sequenz liegen. Rusk verwendet dafür eine begrenzte Retry-Warteschlange. Außerdem gibt es ein Deferred-Event aus, während die Transaktion wartet.
Der einfachste Vergleich für mich ist eine Banküberweisung. Überweisung Nummer zwei erreicht das System, bevor Überweisung Nummer eins dort ankommt. Ich gehe nicht automatisch davon aus, dass Nummer zwei schlecht ist. Zuerst will ich wissen, ob das System nur auf Nummer eins wartet.
Das macht auch diese @Dusk detail für mich interessant. Die HTTP-API kann 202 Accepted zurückgeben, wenn eine Transaktion weitergeleitet wurde. Aber das bedeutet nicht, dass sie bereits im Mempool ist oder finalisiert wurde. Dusk’ Dokumentation sagt sogar, dass die lokale mempoolTxs-Ansicht zukünftige-Nonce-Transaktionen ausschließt, die in der Prequeue warten.
Jetzt bin ich bei dem „deferred“-Teil hängen geblieben. Wenn ein Wallet oder eine Börse dieses Event sieht, was sollte es dann tatsächlich mit der Transaktion machen? Soll es warten, bis die Transaktion weiterkommt, oder gibt es ein anderes Signal, auf das es sich verlassen sollte?
Ich neige dazu, sie im Blick zu behalten. Aber ich möchte trotzdem wissen, wie echte Integrationen diese Wartezeit handhaben.#dusk
$METAB $STAR $DUSK