Penso che il motivo principale per cui la maggior parte delle blockchain non ha adottato l'esecuzione asincrona sia semplice: quando gli utenti vedono che la loro transazione è confermata, si aspettano che il risultato sia disponibile poiché le loro azioni successive dipendono da esso. Sebbene con l'esecuzione differita sia possibile simulare localmente il risultato per le transazioni che lavorano con uno stato non controverso (come trasferimenti/approvazioni), queste sono anche le tipologie di transazioni che non aggiungono molto sovraccarico all'esecuzione sincrona. Questo aspetto rende l'esecuzione asincrona un'alternativa molto meno attraente considerando: 1. Costi di sviluppo aggiuntivi 2. Una non banale condizionalità nel trattamento delle transazioni sul client finale (verificare se una transazione può toccare uno stato controverso e scegliere di attendere il risultato dalla blockchain o simularlo localmente)

È sicuramente un percorso interessante da intraprendere, ma la storia mostra che i paradigmi che dovrebbero tecnicamente offrire prestazioni superiori spesso non riescono ad ottenere adozione a causa di una complessità aggiuntiva. Ad esempio, l'esecuzione asincrona in TON (anche se è molto diversa da quella di Monad, ma è anche migliore sulla carta, tra l'altro) è il principale punto di lamentele da parte degli sviluppatori che ho sentito, e non aggiunge nemmeno guadagni di prestazioni ragionevoli.

@MaxResnick1 Inoltre, non capisco perché hai ripetuto che è decisamente più veloce in termini di stato finalizzato. In termini di latenza, ovviamente lo è e non era il punto del mio post.