Ich denke, der Hauptgrund, warum die meisten Blockchains keine asynchrone Ausführung übernommen haben, ist einfach: Wenn Benutzer sehen, dass ihre Transaktion bestätigt ist, erwarten sie, dass das Ergebnis verfügbar ist, da ihre weiteren Aktionen davon abhängen. Während es bei verzögerter Ausführung möglich ist, das Ergebnis für Transaktionen, die mit nicht umstrittenen Zuständen arbeiten (wie Überweisungen/Genehmigungen), lokal zu simulieren, sind dies auch die Arten von Transaktionen, die der synchronen Ausführung nicht viel zusätzlichen Aufwand hinzufügen. Dieser Aspekt macht die asynchrone Ausführung zu einer viel weniger attraktiven Alternative, wenn man Folgendes berücksichtigt: 1. Zusätzliche Entwicklungskosten 2. Eine nicht triviale Bedingung für die Verarbeitung von Transaktionen auf dem Endclient (Überprüfung, ob eine Transaktion einen umstrittenen Zustand berühren könnte und die Entscheidung, auf das Ergebnis von der Blockchain zu warten oder es lokal zu simulieren)

Es ist definitiv ein interessanter Weg, den man einschlagen kann, aber die Geschichte zeigt, dass Paradigmen, die technisch gesehen mehr Leistung bringen sollten, oft aufgrund einer zusätzlichen Komplexität nicht angenommen werden. Zum Beispiel ist die asynchrone Ausführung in TON (obwohl sie sehr unterschiedlich von Monad ist, aber auch auf dem Papier besser ist, btw) der Hauptpunkt der Beschwerden von Entwicklern, die ich gehört habe, und sie bringt auch keine nennenswerten Leistungsgewinne.

@MaxResnick1 Außerdem verstehe ich nicht, warum du wiederholt hast, dass es in Bezug auf den finalisierten Zustand strikt schneller ist. In Bezug auf die Latenz ist es offensichtlich so, und das war nicht der Punkt meines Beitrags.