So lösen Sie ein asynchrones Solidity-Problem

Die Blockchain selbst ist effektiv Single-Threaded: Transaktionen werden einzeln ausgeführt, und der Status der vorherigen Transaktion wurde geändert, wenn sie dann von der nächsten Transaktion referenziert wird. Wenn Sie beispielsweise einer Reihe von Datensätzen eine aufsteigende ID zuweisen möchten, können Sie sicher sein, dass letztendlich jede ID nur einem Datensatz zugewiesen wird.

Das Problem ist, dass Sie beim Senden einer Transaktion nicht nur nicht im Voraus wissen, in welcher Reihenfolge sie im Verhältnis zu anderen Transaktionen ablaufen wird, sondern Sie wissen es auch nicht unmittelbar danach, da der Block, der sie gerade verarbeitet hat, möglicherweise verwaist ist und ersetzt wird durch einen Block, der Transaktionen in einer anderen Reihenfolge akzeptierte. In unserem ID-Beispiel können Sie also einen Datensatz erstellen, indem Sie eine Transaktion von Ihrem Javascript-Code senden, sehen, wie sie eine ID erhält, dann später zurückkommen und feststellen, dass die ID, von der Sie dachten, dass sie Ihrem Datensatz zugewiesen wurde, jetzt zu einem anderen Datensatz gehört.

Das Ergebnis ist, dass Dinge, die eine strenge Ordnung erfordern, innerhalb der Blockchain verwaltet werden müssen, die letztendlich immer mit sich selbst konsistent ist, und dass Sie nicht von einer sofortigen Konsistenz in Bezug auf externe Systeme ausgehen können.

Es gibt keine Parallelität auf der Blockchain. Die Transaktionen werden von dem Knoten, der den Block erstellt, gemäß der Reihenfolge geordnet, in der dieser Knoten die Transaktionen erhalten hat.

In einem Fall, der wie eine Race-Condition erscheinen mag, z. B. bei einem Token-Austausch, bei dem viele Aufträge innerhalb der Blockzeit und gemäß Zustandswerten wie dem im vorherigen Block gesehenen Preis platziert werden können, werden viele Transaktionen möglicherweise einfach aufgrund dieses Preises ungültig wird nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ in den TX-Pool eingestellt.