Myslím, že hlavní důvod, proč většina blockchainů nepřijala asynchronní provádění, je jednoduchý: když uživatelé vidí, že jejich tx je potvrzeno, očekávají, že výsledek bude k dispozici, protože na něm závisí jejich další akce. I když je u odloženého provádění možné lokálně simulovat výsledek pro TX pracující s nekonfliktním stavem (jako jsou přenosy/schválení), jedná se také o druhy TX, které nepřidávají velkou režii k synchronnímu provádění. Díky tomuto aspektu je asynchronní provádění mnohem méně atraktivní alternativou s ohledem na: 1. Dodatečné náklady na vývoj 2. Netriviální podmínka zpracování tx na koncovém klientovi (kontrola, jestli se tx může dotknout sporného stavu, a volba počkat na výsledek z řetězce nebo ho lokálně simulovat)

Je to rozhodně zajímavá cesta, ale historie ukazuje, že paradigmata, která by technicky měla přinášet vyšší výkon, často selhávají v přijetí kvůli další složitosti. Například asynchronní provádění v TONu (i když je velmi odlišné od Monadu, ale na papíře je také lepší) je hlavním bodem stížností od vývojářů, které jsem slyšel, a také nepřidává žádné rozumné zvýšení výkonu.

@MaxResnick1 Také nechápu, proč jste opakoval, že je to striktně rychlejší z hlediska konečného stavu. Z hlediska latence to tak zjevně je a nebylo to smyslem mého příspěvku.