Wenn Sie eine App entwickeln, die Transaktionen an Dusk L1 übermittelt, wirkt eine erfolgreiche Antwort vom Node wie der naheliegende Moment, um dem Nutzer mitzuteilen, dass die Aktion funktioniert hat.

Ich habe das zunächst genauso gelesen, bis ich den Transaktionslebenszyklus von Dusk genauer verfolgt habe. Ein `202 Accepted` vom Propagation-Endpoint bedeutet nur, dass der Node die Transaktion zur Weiterleitung akzeptiert hat. Das heißt nicht, dass die Transaktion einen Block erreicht, erfolgreich ausgeführt wurde oder final ist.

Dadurch wird aus einer vermeintlich einfachen „Transaktion senden“-Integration eher eine Sache der Zustandsverfolgung. Sobald eine Transaktion ausgeführt wurde, macht Dusk ein `err`-Feld verfügbar, wobei `null` bedeutet, dass die Ausführung erfolgreich war. Selbst dann kann aber ein akzeptierter Block noch rückgängig gemacht werden. Die Finalität tritt ein, wenn der Block den Status `finalized` erreicht.

Ich denke, das ordnet die Aufgabe des Builders in einer nützlichen Weise neu.

Sie verdrahten nicht einfach nur einen Button mit einem Endpoint und warten auf einen HTTP-Erfolg. Sie entscheiden, welchen Netzwerkzustand Ihre Anwendung tatsächlich als „abgeschlossen“ für die Person zählt, die sie benutzt.

„Submitted“ ist ein Zustand.

„Executed successfully“ ist ein anderer.

„Final“ ist der, der den Kreis schließt.

@Dusk $DUSK #dusk