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. Tx 3: Charlie envía 100 MON a Alice, costando 1 MON en tarifas. Ahora estamos en el bloque 1001. El líder está decidiendo si incluir la siguiente transacción: Tx 4: Alice envía 40 MON a Bob, costando 1 MON en tarifas. Cuando lo miramos, sabemos que sería seguro incluir tx 4 porque el saldo de Alice es 100 - 21 - 71 + 100 = 108. Pero debido a la ejecución asíncrona, en el momento del consenso, no sabemos el resultado de toda la ejecución, solo sabemos que el saldo en el peor de los casos de Alice es 100 - 21 - 71 = 8. El antiguo algoritmo se basaba en este saldo en curso pesimista para utilizar el estado retrasado en las decisiones de consenso. Funciona bastante bien, aparte del hecho de que a veces puede ser demasiado conservador (como se ve en el ejemplo anterior donde tx 4 no puede ser incluido de inmediato hasta que la raíz de merkle retrasada se actualice para incluir el bloque con tx 3 en él).

Creo que el equipo de Category Labs puede haber encontrado una manera de hacer que la ejecución asíncrona funcione con EIP-7702.

Acabamos de lanzar un boletín semanal con actualizaciones sobre todo lo que está sucediendo alrededor de Monad Gracias a @denk_tweets y al equipo de @beehiiv que han hecho que sea muy fácil escalar esto Regístrate aquí: