Jag tror att den främsta anledningen till att de flesta blockkedjor inte har antagit asynkron körning är enkel: när användare ser att deras tx är bekräftad förväntar de sig att resultatet ska vara tillgängligt eftersom deras fortsatta åtgärder beror på det. Även om det med uppskjuten körning är möjligt att lokalt simulera resultatet för txs som arbetar med icke-omtvistade tillstånd (till exempel överföringar/godkännanden), är det också de typer av txs som inte lägger till mycket omkostnader för synkron körning. Den här aspekten gör asynkron körning till ett mycket mindre attraktivt alternativ med tanke på: 1. Ytterligare utvecklingskostnader 2. En icke-trivial tx-bearbetningsvillkor för slutklienten (kontrollera om en tx kan röra ett omtvistat tillstånd och välja att vänta på resultatet från kedjan eller simulera det lokalt)

Det är definitivt en intressant väg att gå, men historien visar att paradigm som tekniskt sett borde ge mer prestanda ofta misslyckas med att uppnå implementering på grund av en ytterligare komplexitet. Till exempel är asynkron exekvering i TON (även om det skiljer sig mycket från Monads men också är bättre på pappret btw) huvudpunkten för klagomål från utvecklare som jag hört, och det ger inte heller några rimliga prestandavinster.

@MaxResnick1 Jag förstår inte heller varför du har upprepat att det är strikt snabbare när det gäller slutfört tillstånd. Latensmässigt är det uppenbarligen det och det var inte poängen med mitt inlägg.