Cred că principalul motiv pentru care majoritatea blockchain-urilor nu au adoptat execuția asincronă este simplu: atunci când utilizatorii văd că tx-ul lor este confirmat, se așteaptă ca rezultatul să fie disponibil, deoarece acțiunile lor ulterioare depind de acesta. În timp ce cu execuția amânată este posibil să simulați local rezultatul pentru txs care lucrează cu stări non-contencioase (cum ar fi transferuri/aprobări), acestea sunt, de asemenea, tipurile de txs care nu adaugă prea multă supraîncărcare la execuția sincronă. Acest aspect face ca execuția asincronă să fie o alternativă mult mai puțin atractivă, având în vedere: 1. Costuri suplimentare de dezvoltare 2. O condiționalitate de procesare tx non-trivială pe clientul final (verificarea dacă un tx poate atinge o stare controversată și alegerea de a aștepta rezultatul din lanț sau de a-l simula local)

Este cu siguranță o cale interesantă de urmat, dar istoria arată că paradigmele care ar trebui să producă mai multe performanțe adesea nu reușesc să fie adoptate din cauza unei complexități suplimentare. De exemplu, execuția asincronă în TON (deși este foarte diferită de cea a lui Monad, dar este și mai bună pe hârtie) este principalul punct de plângere din partea dezvoltatorilor pe care le-am auzit și nu adaugă nici câștiguri rezonabile de performanță.

@MaxResnick1 De asemenea, nu înțeleg de ce ați repetat că este strict mai rapid în ceea ce privește starea finală. Din punct de vedere al latenței, evident că este și nu a fost scopul postării mele.