Ik denk dat de belangrijkste reden waarom de meeste blockchains geen asynchrone uitvoering hebben aangenomen eenvoudig is: wanneer gebruikers zien dat hun transactie is bevestigd, verwachten ze dat het resultaat beschikbaar is, omdat hun verdere acties daarvan afhankelijk zijn. Hoewel het met uitgestelde uitvoering mogelijk is om lokaal het resultaat te simuleren voor transacties die werken met niet-betwistbare status (zoals overboekingen/goedkeuringen), zijn dit ook de soorten transacties die niet veel overhead toevoegen aan synchrone uitvoering. Dit aspect maakt asynchrone uitvoering een veel minder aantrekkelijke optie, gezien: 1. Extra ontwikkelingskosten 2. Een niet-triviale verwerkingsvoorwaarde voor transacties aan de eindklant (controleren of een transactie een betwistbare status kan raken en kiezen om te wachten op het resultaat van de keten of het lokaal te simuleren)

Het is zeker een interessante weg om in te slaan, maar de geschiedenis toont aan dat paradigma's die technisch gezien meer prestaties zouden moeten opleveren vaak falen in adoptie vanwege een extra complexiteit. Bijvoorbeeld, asynchrone uitvoering in TON (hoewel het heel anders is dan die van Monad, maar ook beter op papier trouwens) is het belangrijkste punt van klachten van ontwikkelaars die ik heb gehoord, en het voegt ook geen redelijke prestatieverbeteringen toe.

@MaxResnick1 Ook begrijp ik niet waarom je hebt herhaald dat het strikt sneller is in termen van de gefinaliseerde staat. Wat latency betreft, is het dat duidelijk en dat was niet het punt van mijn bericht.