Myślę, że głównym powodem, dla którego większość blockchainów nie przyjęła asynchronicznego wykonania, jest prosty: gdy użytkownicy widzą, że ich transakcja jest potwierdzona, oczekują, że wynik będzie dostępny, ponieważ ich dalsze działania na nim polegają. Podczas gdy w przypadku opóźnionego wykonania możliwe jest lokalne symulowanie wyniku dla transakcji działających w stanie niekontrowersyjnym (takim jak przelewy/zgody), są to również rodzaje transakcji, które nie dodają wiele obciążenia do wykonania synchronicznego. Ten aspekt sprawia, że asynchroniczne wykonanie jest znacznie mniej atrakcyjną alternatywą, biorąc pod uwagę: 1. Dodatkowe koszty rozwoju 2. Niekontrolowana warunkowość przetwarzania transakcji po stronie końcowego klienta (sprawdzanie, czy transakcja może dotknąć stanu kontrowersyjnego i wybieranie, czy czekać na wynik z łańcucha, czy lokalnie go symulować)

To zdecydowanie interesująca ścieżka, ale historia pokazuje, że paradygmaty, które technicznie powinny przynosić lepszą wydajność, często nie osiągają adopcji z powodu dodatkowej złożoności. Na przykład, asynchroniczne wykonanie w TON (choć jest bardzo różne od Monady, ale również lepsze na papierze, nawiasem mówiąc) jest głównym punktem skarg od deweloperów, które słyszałem, i nie przynosi też żadnych rozsądnych zysków wydajności.

@MaxResnick1 Również nie rozumiem, dlaczego powtarzasz, że jest to zdecydowanie szybsze pod względem stanu sfinalizowanego. Pod względem opóźnienia, oczywiście tak jest i to nie był sens mojej wiadomości.