Este es un resumen sobre la ejecución asíncrona: cómo lo hicimos funcionar en Monad, por qué EIP-7702 lo rompió y cómo solucionarlo. Para dar contexto, la ejecución asíncrona ha estado en Monad desde que los clientes de consenso y ejecución se conectaron entre sí. La ejecución asíncrona permite que la ejecución se retrase respecto al consenso por un número fijo de bloques desde una perspectiva de interacción. La mayoría de las blockchains tienen consenso entrelazado. Es decir, la ejecución ocurre antes del consenso, lo que significa que se debe ajustar la ejecución a un presupuesto de tiempo que es una pequeña fracción del tiempo de bloque (el resto está ocupado por la mensajería alrededor del mundo, también conocida como consenso). Esto limita inherentemente el gas por segundo del sistema. Las L2 evitan esto al no tener consenso en absoluto. Pero queremos el comportamiento de un L1 distribuido y descentralizado que mantenga un alto rendimiento. La ejecución asíncrona nos permite evadir este problema al mover la ejecución fuera de la ruta caliente del consenso. En su lugar, el consenso y la ejecución ocurren en carriles paralelos. El consenso en el bloque 2 ocurre mientras la ejecución del bloque 1 se está ejecutando en paralelo. Sin embargo, todavía necesita haber un acuerdo entre el consenso y la ejecución. Específicamente, ese acuerdo es: la ejecución solo puede retrasarse respecto al consenso hasta k bloques, porque las propuestas de bloque contienen una raíz de merkle retrasada. Además, el consenso está construyendo bloques con una vista retrasada del estado (retrasada por k bloques). Esto significa que hay un peligro de que el consenso incluya una transacción de un remitente que, para cuando ejecutemos, resulta que tiene un saldo vacío. Sería malo si el protocolo permitiera que esto sucediera, porque abriría un vector de Denegación de Servicio (DOS). Por lo tanto, para abordar este problema y habilitar de manera segura la ejecución asíncrona, el cliente de consenso de Monad calcula el máximo débito de MON de cada transacción como MON_gastado = oferta_gas * límite_gas + valor. El cliente de consenso mantiene una lista en curso de los saldos de cuenta disponibles para cada remitente después de deducir MON_gastado por cada transacción que enviaron. Basándose en ese saldo en curso, el cliente de consenso solo incluye transacciones si puede estar seguro de que la transacción puede ser pagada. Este es un enfoque pesimista para la construcción de bloques, ya que no toma en cuenta la posibilidad de que alguna cuenta gane saldo por una transferencia entrante. Déjame explicar lo que quiero decir con un ejemplo. Supongamos que la cuenta de Alice tiene 100 MON. Luego, las siguientes 3 transacciones se incluyen en el bloque 1000: Tx 1: Alice envía 20 MON a Bob, costando 1 MON en tarifas. Tx 2: Alice gasta 70 MON comprando un memecoin, costando 1 MON en tarifas....