¡Hola,
La escalabilidad de las transacciones ha sido el tema de conversación. Hemos estado explorando cómo Monad ayuda a aumentar el TPS en las últimas semanas.
La nota a continuación es un desglose de cómo funciona Monad escrito por @desh_saurabhConsidere registrarse enDecentralised.cosi disfrutas leyendo explicaciones basadas en datos sobre todo lo relacionado con Web3. ¡Nos vemos al otro lado!
TPS es una métrica en la que nos obsesionamos. Queremos que nuestras cadenas admitan un TPS más alto, ya que podrían admitir más usuarios y aplicaciones. El gráfico a continuación muestra los números de TPS para Ethereum y L2s. Ninguna cadena ha superado nunca la marca de 100 TPS. Tenga en cuenta que TPS es un término general para medir la escala. TPS es inexacto porque no todas las transacciones son iguales, ya que difieren en complejidad. Pero usamos TPS como medida de escala por simplicidad.
¿Qué hacemos si queremos aumentar el TPS?
Monad, un nuevo L1 compatible con EVM que recientemente recaudó $225 millones, está construyendo el EVM desde cero en lugar de usarlo tal cual. Escogió este tercer enfoque para aumentar la escalabilidad.
Discutimos algunos cambios significativos que Monad aporta a la mesa.
La Máquina Virtual Ethereum (EVM) ejecuta transacciones de forma serial. Hasta que se ejecuta una transacción, la siguiente transacción tiene que esperar. Piénsalo de esta manera. Digamos que hay una plataforma en un almacén de ensamblaje de motocicletas. Varios camiones depositan piezas de motocicletas (de manera que cada camión tiene todas las piezas necesarias para crear 50 motocicletas). El almacén de ensamblaje realiza cuatro funciones diferentes con equipos dedicados: descarga, clasificación, ensamblaje y carga.
Con la configuración actual de EVM, solo hay una plataforma, y el mismo lugar se utiliza para la carga y descarga. Por lo tanto, cuando el camión está estacionado, los componentes de la motocicleta se descargan, se clasifican, se ensamblan y se cargan en el mismo camión. Mientras el equipo de clasificación está trabajando, todos los demás equipos solo están esperando. Entonces, si piensas en sus trabajos como diferentes espacios, cada equipo trabaja solo una vez cada cuatro espacios. Esto conduce a ineficiencias significativas, destacando la necesidad de un enfoque más eficiente.
Ahora, imagina que hay cuatro plataformas con diferentes áreas de carga y descarga. Incluso si el equipo de descarga puede trabajar con solo un camión a la vez, no necesitan esperar los siguientes tres espacios. Pueden pasar directamente al siguiente camión.
Lo mismo ocurre con los equipos de clasificación, ensamblaje y carga. Una vez que se descarga la carga del camión, este se mueve al área de carga y espera a que el equipo de carga cargue las motocicletas ensambladas. Por lo tanto, el almacén con solo una plataforma y área de carga/descarga ejecuta todo de forma secuencial, mientras que el que tiene 4 plataformas y áreas de carga/descarga diferentes está paralelizando.
Considera Monad como una infraestructura equivalente al almacén con múltiples plataformas de camiones, pero no tan simple. La complejidad aumenta cuando los camiones dependen entre sí. Por ejemplo, ¿qué pasa si un camión no tiene todas las piezas para hacer 50 motocicletas? Las transacciones no siempre son independientes. Entonces, cuando Monad las ejecuta en paralelo, tiene que lidiar con transacciones que dependen entre sí.
¿Cómo? Realiza algo llamado ejecución paralela optimista. El protocolo solo puede ejecutar transacciones independientes en paralelo. Por ejemplo, considere 4 transacciones con el saldo de Joel como 1 ETH -
Todas estas transacciones se ejecutan de forma paralela con resultados pendientes que se confirman uno por uno. Las transacciones se vuelven a ejecutar si los resultados pendientes entran en conflicto con las entradas originales de cualquier transacción. Las transacciones 2 y 4 no tienen resultados pendientes que entren en conflicto con las entradas de otras transacciones, ya que son independientes entre sí. Pero 1 y 3 no son independientes.
Tenga en cuenta que dado que las 4 transacciones comienzan desde el mismo estado, la que nos concierne aquí es el saldo de Joel de 1 ETH. El resultado de Joel enviando 0.2 ETH es de 0.8 ETH. Después de que Joel envía 0.1 ETH a Sid, su saldo es de 0.9 ETH. Los resultados se comprometen uno por uno, asegurando que las salidas no entren en conflicto con ninguna de las entradas. Después de que el resultado pendiente de 1 se compromete, el nuevo saldo de Joel es de 0.8 ETH.
Esta salida entra en conflicto con la entrada de 3. Por lo tanto, ahora se vuelve a ejecutar 3 con una entrada de 0.8 ETH. Después de que se ejecute 3, el saldo de Joel es de 0.7 ETH.
En este punto, una pregunta obvia es ¿cómo sabemos que no tendremos que reejecutar la mayoría de las transacciones? La respuesta radica en el hecho de que la reejecución no es el cuello de botella. El cuello de botella es el acceso a la memoria de Ethereum. Resulta que la forma en que Ethereum almacena su estado en la base de datos dificulta (consume tiempo y, por lo tanto, es costoso) acceder al estado. Aquí es donde entra en juego otra mejora de Monad: MonadDb. Monad ha construido su base de datos de una manera que reduce los costos asociados con las operaciones de lectura.
Cuando una transacción debe ser reejecutada, todos los insumos ya están en la memoria caché, lo que es significativamente más fácil de acceder en comparación con el estado general.
Solana tiene 50k TPS en su red de prueba pero actualmente hace ~1k en la red principal. Monad afirma haber logrado 10k TPS reales en su red de prueba interna. Aunque esto no siempre es indicativo del rendimiento en el mundo real, estamos ansiosos por ver cómo funciona Monad en la naturaleza.
Este artículo originalmente titulado “Understanding Monad” es reproducido de [chaincatcher]. Todos los derechos de autor pertenecen al autor original [Decentralised.Co]. Si tiene alguna objeción a la reimpresión, por favor contacte a la Equipo de aprendizaje de Gate, el equipo lo resolverá lo antes posible.
Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.
Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
Compartir
Contenido
¡Hola,
La escalabilidad de las transacciones ha sido el tema de conversación. Hemos estado explorando cómo Monad ayuda a aumentar el TPS en las últimas semanas.
La nota a continuación es un desglose de cómo funciona Monad escrito por @desh_saurabhConsidere registrarse enDecentralised.cosi disfrutas leyendo explicaciones basadas en datos sobre todo lo relacionado con Web3. ¡Nos vemos al otro lado!
TPS es una métrica en la que nos obsesionamos. Queremos que nuestras cadenas admitan un TPS más alto, ya que podrían admitir más usuarios y aplicaciones. El gráfico a continuación muestra los números de TPS para Ethereum y L2s. Ninguna cadena ha superado nunca la marca de 100 TPS. Tenga en cuenta que TPS es un término general para medir la escala. TPS es inexacto porque no todas las transacciones son iguales, ya que difieren en complejidad. Pero usamos TPS como medida de escala por simplicidad.
¿Qué hacemos si queremos aumentar el TPS?
Monad, un nuevo L1 compatible con EVM que recientemente recaudó $225 millones, está construyendo el EVM desde cero en lugar de usarlo tal cual. Escogió este tercer enfoque para aumentar la escalabilidad.
Discutimos algunos cambios significativos que Monad aporta a la mesa.
La Máquina Virtual Ethereum (EVM) ejecuta transacciones de forma serial. Hasta que se ejecuta una transacción, la siguiente transacción tiene que esperar. Piénsalo de esta manera. Digamos que hay una plataforma en un almacén de ensamblaje de motocicletas. Varios camiones depositan piezas de motocicletas (de manera que cada camión tiene todas las piezas necesarias para crear 50 motocicletas). El almacén de ensamblaje realiza cuatro funciones diferentes con equipos dedicados: descarga, clasificación, ensamblaje y carga.
Con la configuración actual de EVM, solo hay una plataforma, y el mismo lugar se utiliza para la carga y descarga. Por lo tanto, cuando el camión está estacionado, los componentes de la motocicleta se descargan, se clasifican, se ensamblan y se cargan en el mismo camión. Mientras el equipo de clasificación está trabajando, todos los demás equipos solo están esperando. Entonces, si piensas en sus trabajos como diferentes espacios, cada equipo trabaja solo una vez cada cuatro espacios. Esto conduce a ineficiencias significativas, destacando la necesidad de un enfoque más eficiente.
Ahora, imagina que hay cuatro plataformas con diferentes áreas de carga y descarga. Incluso si el equipo de descarga puede trabajar con solo un camión a la vez, no necesitan esperar los siguientes tres espacios. Pueden pasar directamente al siguiente camión.
Lo mismo ocurre con los equipos de clasificación, ensamblaje y carga. Una vez que se descarga la carga del camión, este se mueve al área de carga y espera a que el equipo de carga cargue las motocicletas ensambladas. Por lo tanto, el almacén con solo una plataforma y área de carga/descarga ejecuta todo de forma secuencial, mientras que el que tiene 4 plataformas y áreas de carga/descarga diferentes está paralelizando.
Considera Monad como una infraestructura equivalente al almacén con múltiples plataformas de camiones, pero no tan simple. La complejidad aumenta cuando los camiones dependen entre sí. Por ejemplo, ¿qué pasa si un camión no tiene todas las piezas para hacer 50 motocicletas? Las transacciones no siempre son independientes. Entonces, cuando Monad las ejecuta en paralelo, tiene que lidiar con transacciones que dependen entre sí.
¿Cómo? Realiza algo llamado ejecución paralela optimista. El protocolo solo puede ejecutar transacciones independientes en paralelo. Por ejemplo, considere 4 transacciones con el saldo de Joel como 1 ETH -
Todas estas transacciones se ejecutan de forma paralela con resultados pendientes que se confirman uno por uno. Las transacciones se vuelven a ejecutar si los resultados pendientes entran en conflicto con las entradas originales de cualquier transacción. Las transacciones 2 y 4 no tienen resultados pendientes que entren en conflicto con las entradas de otras transacciones, ya que son independientes entre sí. Pero 1 y 3 no son independientes.
Tenga en cuenta que dado que las 4 transacciones comienzan desde el mismo estado, la que nos concierne aquí es el saldo de Joel de 1 ETH. El resultado de Joel enviando 0.2 ETH es de 0.8 ETH. Después de que Joel envía 0.1 ETH a Sid, su saldo es de 0.9 ETH. Los resultados se comprometen uno por uno, asegurando que las salidas no entren en conflicto con ninguna de las entradas. Después de que el resultado pendiente de 1 se compromete, el nuevo saldo de Joel es de 0.8 ETH.
Esta salida entra en conflicto con la entrada de 3. Por lo tanto, ahora se vuelve a ejecutar 3 con una entrada de 0.8 ETH. Después de que se ejecute 3, el saldo de Joel es de 0.7 ETH.
En este punto, una pregunta obvia es ¿cómo sabemos que no tendremos que reejecutar la mayoría de las transacciones? La respuesta radica en el hecho de que la reejecución no es el cuello de botella. El cuello de botella es el acceso a la memoria de Ethereum. Resulta que la forma en que Ethereum almacena su estado en la base de datos dificulta (consume tiempo y, por lo tanto, es costoso) acceder al estado. Aquí es donde entra en juego otra mejora de Monad: MonadDb. Monad ha construido su base de datos de una manera que reduce los costos asociados con las operaciones de lectura.
Cuando una transacción debe ser reejecutada, todos los insumos ya están en la memoria caché, lo que es significativamente más fácil de acceder en comparación con el estado general.
Solana tiene 50k TPS en su red de prueba pero actualmente hace ~1k en la red principal. Monad afirma haber logrado 10k TPS reales en su red de prueba interna. Aunque esto no siempre es indicativo del rendimiento en el mundo real, estamos ansiosos por ver cómo funciona Monad en la naturaleza.
Este artículo originalmente titulado “Understanding Monad” es reproducido de [chaincatcher]. Todos los derechos de autor pertenecen al autor original [Decentralised.Co]. Si tiene alguna objeción a la reimpresión, por favor contacte a la Equipo de aprendizaje de Gate, el equipo lo resolverá lo antes posible.
Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.
Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.