Por Canuto  

MegaETH, presentado por MegaLabs, plantea construir la primera blockchain en tiempo real compatible con EVM para llevar latencias de milisegundos y rendimiento comparable a servidores Web2. El proyecto combina nodos especializados, secuenciadores potentes y técnicas de ingeniería holísticas para superar los cuellos de botella actuales en ejecución, sincronización de estado y límites de gas.
***

  • MegaETH propone nodos especializados (sequencer, prover, replica, full) para escalar rendimiento y mantener validación sin confianza.
  • Según MegaETH, revm llegó a ~14.000 TPS en sincronización histórica, pero los límites reales vienen de I/O y estructura del trie de estado.
  • Problemas clave: latencia de acceso al estado, paralelismo limitado (< 2), sincronización de estado de alta banda y límite de gas de bloque conservador.

MegaETH, presentado por MegaLabs, propone una blockchain compatible con EVM diseñada para ofrecer rendimiento en tiempo real y latencias de milisegundos incluso bajo cargas elevadas. El proyecto argumenta que la brecha entre las blockchains y servidores Web2 puede cerrarse con un enfoque de ingeniería que vaya más allá de optimizaciones aisladas. Según MegaETH, su objetivo es empujar el rendimiento hasta los límites del hardware y permitir dApps de gran demanda como mundos autónomos o trading de alta frecuencia on-chain.

Para lectores nuevos, el término “blockchain en tiempo real” describe un ledger capaz de procesar y publicar actualizaciones tan pronto como llegan, con alta capacidad de transacciones y capacidad de cómputo suficiente para mantener la experiencia bajo picos de demanda. MegaETH plantea que eso requiere reimaginar tanto la arquitectura de nodos como los mecanismos de ejecución y sincronización de estado.

Por qué otra blockchain y el desafío del rendimiento

MegaLabs observa que la proliferación de nuevas cadenas no resuelve por sí sola los problemas de escalabilidad. La organización cita datos de que existen más de 120 proyectos documentados en el ecosistema Layer-2, pero sostiene que cada cadena impone límites a las dApps que alberga.

Como ejemplo, MegaETH destaca que opBNB alcanza un gas objetivo de 100 MGas/s, lo cual equivale, según sus cálculos, a solo 650 intercambios de Uniswap o 3.700 transferencias ERC-20 por segundo. En contraposición, benchmarks de servidores de bases de datos como TPC-C ya superan 1.000.000 de transacciones por segundo.

El equipo además ilustra la limitación en cómputo con un contrato que calcula el enésimo número de Fibonacci: esa implementación consume aproximadamente 5,5 mil millones de gas para n=10^8. A 100 MGas/s, opBNB tardaría 55 segundos en realizar ese cálculo. Un programa equivalente en C lo completaría en 30 milisegundos, es decir, 1.833 veces más rápido con un solo núcleo.

Por último, MegaETH subraya que muchas aplicaciones sofisticadas exigen tasas de actualización altas (ticks menores a 100 milisegundos) o cancelaciones de órdenes en menos de 10 milisegundos, requisitos inviables en cadenas con tiempos de bloque largos.

Especialización de nodos: roles y hardware

MegaETH eleva la heterogeneidad de nodos típica de L2 y define cuatro roles principales: secuenciadores, probadores (provers), nodos réplica y nodos completos. Cada rol tiene requisitos de hardware distintos y funciones especializadas.

El secuenciador actúa como productor principal de bloques y ejecuta transacciones. MegaETH propone que solo exista un secuenciador activo a la vez para eliminar la sobrecarga de consenso durante la operación normal. Ese secuenciador está pensado para ejecutarse en servidores de muy alta gama.

Los nodos réplica aplican diffs de estado enviados por el secuenciador sin re-ejecutar transacciones; en su lugar, validan bloques de forma indirecta mediante pruebas ofrecidas por los probadores. Los nodos completos siguen re-ejecutando para obtener validación completa y finalización rápida.

MegaETH detalla requisitos de hardware proyectados: sequencer con CPU 100 núcleos y Memoria 1-4 TB; prover (OP) con CPU 1 núcleo y Memoria 0,5 GB; replica node con CPU 4-8 núcleos y Memoria 16 GB; full node con CPU 16 núcleos y Memoria 64 GB. MegaLabs acompaña ejemplos de instancias y costos: VM ejemplo AWS r6a.48xlarge para el sequencer (USD $10 por hora), t4g.nano para prover (USD $0,004 por hora), Im4gn.xlarge para replica (USD $0,4 por hora) e Im4gn.4xlarge para full node (USD $1,6 por hora).

Desafíos técnicos: ejecución, paralelismo y compilación

En ejecución de transacciones, MegaETH demuestra que la EVM no es el único cuello de botella. En experimentos con Reth y revm, una máquina con 512 GB de RAM alcanzó aproximadamente 14.000 TPS durante una sincronización histórica. Esa cifra indica que accesos al estado y actualizaciones de trie explican gran parte del costo.

MegaLabs identifica tres ineficiencias fundamentales en implementaciones tradicionales de EVM: alta latencia de acceso al estado, falta de ejecución paralela y sobrecarga del intérprete. Al mantener el estado en RAM abundante se reduce la latencia por lectura desde SSD, pero persisten los otros retos.

La capacidad de paralelismo disponible en bloques recientes de Ethereum resulta ser menor a 2 en promedio; incluso con lotes artificiales el paralelismo medio sube solo a 2,75. Estas largas cadenas de dependencias limitan el beneficio práctico de algoritmos como Block-STM.

Respecto a compilación AOT/JIT, MegaETH señala que la ganancia máxima en producción está acotada porque cerca del 50% del tiempo en revm se gasta en opcodes de host y system (keccak256, sload, sstore) ya implementados en Rust. Por ello, las mejoras por compilación pueden quedar en torno a 2x para cargas reales.

Sincronización de estado, root updates y límites de gas

MegaETH explica que sincronizar estado a alta tasa es uno de los retos más difíciles y a menudo subestimados. El equipo calcula que una transferencia ERC-20 genera un diff de estado de cerca de 200 bytes. A 100.000 transferencias por segundo, eso implica 152,6 Mbps de ancho de banda sólo para diffs.

Un intercambio de Uniswap produce diffs aún mayores: 624 bytes por intercambio, lo que para 100.000 intercambios por segundo suma 476,1 Mbps. MegaETH advierte que conexiones nominales de 100 Mbps no garantizan sincronización efectiva por overhead de redes P2P y uso compartido de recursos.

Con suponer un ancho de banda sostenible promedio de 75 Mbps y reservar dos tercios para otras necesidades, MegaETH concluye que quedan 25 Mbps para state sync. En ese escenario, 100.000 intercambios de Uniswap exigirían una compresión de estado de 19x.

La actualización de la raíz de estado en estructuras tipo MPT añade I/O intensivo. Para un MPT binario con 16.000 millones de claves la actualización de una clave exige ~68 lecturas y 34 escrituras en el peor caso. Aunque cachear niveles altos reduce el trabajo, MegaETH muestra que la contabilidad de I/O escala hasta millones de IOPS para altas tasas de transacción.

Como ejemplo de optimización, NOMT agrupa subárboles en páginas de 4 KB y reduce lecturas no cacheadas. Aun así, MegaETH cita benchmarks de Thrum que indican que un NOMT con 134 millones de claves gestiona hasta 50.000 actualizaciones de hojas por segundo, lo que sigue siendo 6 veces inferior a la capacidad que MegaETH persigue, y además ese estado es 128 veces más pequeño que el caso límite ilustrado.

Finalmente, el límite de gas de bloque actúa como freno artificial que asegura que cualquier bloque se pueda procesar en el tiempo de bloque. MegaETH argumenta que no basta con acelerar componentes aislados; también hace falta reconsiderar modelos de precios multidimensionales para reflejar costes de compilación, acceso a estados calientes y prioridades de transacción antes de aumentar agresivamente el límite de gas.

Filosofía de diseño e implicaciones para la industria

MegaETH defiende una filosofía de “medir, luego construir” y un enfoque holístico que persiga diseños de tablero limpio orientados a acercarse a los límites del hardware. El equipo critica optimizaciones parciales que brillan en microbenchmarks pero no afectan el rendimiento de extremo a extremo para usuarios finales.

La propuesta de node specialization permite fijar requisitos de hardware distintos por rol, manteniendo accesibles los nodos réplica y permitiendo secuenciadores centralizados pero verificables. MegaETH apunta que esa especialización puede mantener validación sin confianza mientras mejora el rendimiento que experimentan los desarrolladores.

En su comunicado, MegaLabs reconoce que muchas soluciones específicas exceden el alcance de la publicación y anuncia que publicará detalles técnicos en futuras entregas. Aun así, la investigación ya muestra datos concretos sobre límites de I/O, paralelismo y costes de sincronización.

Si las ideas de MegaETH prosperan, la industria podría ver aplicaciones on-chain con latencias y capacidad de cómputo cercanas a Web2. Eso abriría nuevas posibilidades para mundos autónomos, simulaciones en tiempo real y trading de muy baja latencia, siempre que la infraestructura de soporte (nodos RPC, indexadores) evolucione en paralelo.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados