Esta es la primera versión de las notas de estudio personales del documento técnico de @megaeth_labs. Si estás interesado, puedes echarle un vistazo. Como frontera de facto de la innovación blockchain, Ethereum es muy digno de atención. Mi nivel personal es limitado. Si hay algún error u omisión, indíquelo y gracias.
1. Tres características y casos restringidos actuales:
alto rendimiento de transacciones, alto rendimiento
El mejor opBNB destaca por su tasa de gas extremadamente alta de 100MGas/s, pero sigue siendo muy baja en comparación con las capacidades de los servidores web2. 100MGas/s equivale a 650 swaps uniswap o 3700 transferencias ERC20 por segundo, mientras que los servidores modernos por segundo. segundo Se pueden ejecutar más de 1 millón de transacciones.
abundante capacidad informática, abundante potencia informática
Las aplicaciones complejas no se pueden cargar en la cadena y están limitadas principalmente por la potencia informática. Si se utiliza el contrato EVM para calcular los números de n-Fibonacci, se requieren 5.500 millones de gas, lo que requiere una velocidad de cálculo de 100 mg/s que requiere 55 segundos. de toda la cadena opbnb. Tradicionalmente, un programa escrito en lenguaje C sólo tarda 30 ms. La velocidad de la CPU de un solo núcleo aumentó 1833 veces
y, lo más singular, tiempos de respuesta de milisegundos incluso bajo cargas pesadas. Capacidades de respuesta de milisegundos bajo cargas pesadas.
A excepción de arb, otras cadenas de bloques convencionales de segundo nivel requieren más de 1 segundo de tiempo de generación de bloques para actualizar el estado de la cadena. Esto no es factible para aplicaciones que requieren altas tasas de actualización y ciclos de retroalimentación rápidos. Por ejemplo, los mundos y juegos en cadena hechos por uno mismo requieren un tiempo de respuesta de 100 ms, mientras que el comercio de alta frecuencia requiere un tiempo de respuesta de 10 ms para realizar o cancelar órdenes; de lo contrario, nada de esto se puede lograr.
2. Cómo superar los límites de rendimiento
Arquitectura Blockchain actual (N1)
Cada blockchain consta de dos componentes básicos, incluido el consenso y la ejecución.
El consenso determina el orden de las transacciones de los usuarios y la ejecución procesa estas transacciones en un orden establecido para actualizar el estado de la cadena de bloques. En la mayoría de las cadenas de bloques L1, cada nodo realiza la misma tarea sin especialización. Cada nodo participa en el protocolo distribuido, llega a un consenso y luego ejecuta transacciones localmente. Cada L1 debe decidir hasta qué punto puede aumentar los requisitos de hardware para que los usuarios comunes operen nodos sin comprometer las propiedades fundamentales de la cadena de bloques, como la seguridad y la resistencia a la censura.
Por tanto, los requisitos operativos de los nodos completos son muy importantes, relacionados con la seguridad y la resistencia a la censura.
El nuevo paradigma de la capa 2
La naturaleza de la cadena de bloques L2 es heterogénea e inherentemente diferente. Diferentes nodos L2 están especializados para realizar tareas específicas de manera más eficiente.
megaETH va un paso más allá y desacopla (desconecta) las tareas de ejecución de transacciones de los nodos completos. En concreto, megaETH tiene tres roles, secuenciadores (sequencers), probers (certificadores) y full nodes (nodos completos)
La primera clave es un potente clasificador centralizado.
Secuenciadores: responsables de ordenar y ejecutar transacciones, pero megaeth se diferencia en que solo hay un secuenciador activo en un momento dado, lo que elimina la sobrecarga de consenso durante la ejecución normal. La mayoría de los nodos completos reciben diferencias de estado de este ordenante a través de la red p2p y luego aplican las diferencias directamente para actualizar su estado local, pero no vuelven a ejecutar transacciones, verifican los bloques indirectamente a través de pruebas proporcionadas por el probador. Los usuarios avanzados (operadores de puentes y creadores de mercado) aún pueden ejecutar cada transacción para lograr la finalidad lo más rápido posible, pero esto requiere mayores requisitos de hardware para mantenerse al día con el secuenciador. Finalmente, los probadores utilizan el esquema de validación sin estado para verificar bloques de forma asincrónica y fuera de orden.
La especialización de los nodos es muy importante. Aunque la generación de bloques está más centralizada, la blockchain está más descentralizada. Por ejemplo, el secuenciador requiere un servidor de gama alta, mientras que el servidor requerido por el nodo completo es muy económico.
Además de los potentes servidores centralizados, existen implementaciones de ingeniería más complejas.
Si solo confía en servidores potentes, Reth solo puede alcanzar 1000TPS en el experimento, que es aproximadamente 100MGas/s. Esto se debe principalmente a la limitación de actualizar el MPT (estructura de datos utilizada por Ethereum) en cada bloque, que es más rápido que. el cálculo de la ejecución de la transacción en sí el costo es 10 veces mayor.
Por eso todavía nos enfrentamos a muchas situaciones complejas.
3. Diseño de megaETH
medir, luego construir, medir primero para encontrar los problemas reales, las limitaciones de desempeño, y luego diseñar el nuevo sistema para resolver todos los problemas al mismo tiempo.
Se esfuerza por diseñar sistemas para alcanzar los límites del hardware, no le gusta el diseño incremental y prefiere nuevos diseños cercanos a los límites teóricos.
Los siguientes son varios desafíos y soluciones encontrados durante el proceso de diseño.
Ejecución de transacciones Ejecución de transacciones
Comencemos con el secuenciador. Mucha gente dice que EVM es la razón del bajo rendimiento y los bajos tps de L2, pero esto está mal, según la prueba de megaeth, evm puede alcanzar 14.000 tps, lo que ya es muy alto.
Sin embargo, esto no es suficiente para la cadena de bloques en tiempo real. La implementación tradicional de EVM tiene tres problemas de ineficiencia, a saber.
Alta latencia de acceso al estado: el acceso y la lectura del estado de la cadena de bloques es lento porque está almacenado en el disco duro y requiere múltiples lecturas.
Solución: el nodo de orden está equipado con suficiente RAM para guardar todo el estado de la cadena de bloques. Actualmente, la RAM de Ethereum es de aproximadamente 100 GB. Este método acelera significativamente el acceso al estado al eliminar la latencia de lectura de SSD.
Falta de ejecución paralela: debido a que las transacciones se ejecutan secuencialmente para garantizar la coherencia del estado y el doble gasto, es difícil ejecutarlas en paralelo.
Solución: ya existen soluciones para este escenario, pero incluso si se solucionan, la aceleración real que se puede lograr en la producción real está inherentemente limitada por el paralelismo disponible en la carga de trabajo. Según las pruebas, el paralelismo medio real de Ethereum es recientemente inferior a 2, lo que indica un paralelismo limitado. De hecho, el núcleo es que las diferentes transacciones en Ethereum tienen muchas dependencias e incluso leen y escriben objetos en el mismo estado, lo que provoca conflictos de paralelismo. Este problema debe resolverse.
Gastos generales del intérprete: los gastos generales adicionales causados por la máquina virtual o el intérprete al ejecutar contratos inteligentes.
Solución: una proporción relativamente alta de códigos de operación ya son nativos de Rust, por lo que es difícil beneficiarse de la compilación. La aceleración máxima puede ser solo 2 veces.
Además de los problemas que enfrentan estas tres cadenas de bloques generales de alto rendimiento, todavía existen dos desafíos para lograr una cadena de bloques en tiempo real de 10 ms. El primero es la producción consistente de bloques de alta frecuencia, por ejemplo, se genera un bloque. cada 10 ms. La segunda es que el motor de ejecución paralela debe admitir la priorización de transacciones para que las transacciones críticas puedan procesarse sin demoras en la cola, incluso durante los períodos de máxima congestión.
Sincronización de estados
La sincronización de estado es el proceso de poner al día los nodos completos con el secuenciador, que es uno de los aspectos más desafiantes del diseño de blockchain de alto rendimiento.
Si las transferencias y las transacciones uniswap se transmiten 100.000 veces por segundo, requerirán un ancho de banda de 152,6 Mbps y 476,1 Mbps respectivamente, que es mucho más que el ancho de banda de 100 Mbps del nodo completo. Además, es probable que estos 100 Mbps solo se utilicen en un tercio. El ancho de banda real utilizado para la sincronización puede ser de sólo 25 Mbps, lo que supone una gran diferencia con respecto a los requisitos reales.
Actualizar estado raíz
El concepto es muy complicado. Bajo la estructura de datos de MPT, para actualizar la raíz del estado, es necesario leer y escribir muchos nodos hoja y nodos secundarios. Si solo se calcula la lectura, se calculan alrededor de 6 millones de no. Se necesitan tiempos de almacenamiento en caché. Las lecturas de la base de datos, incluso si asumimos que cada lectura de la base de datos puede ser manejada por una única E/S de disco, 6 millones de IOPS está mucho más allá de las capacidades de cualquier SSD de consumo actual, y este cálculo ni siquiera requiere escritura. operaciones en cuenta.
Una estrategia de optimización común para reducir la E/S del disco es agrupar varios nodos trie en un subárbol y almacenarlos en una página de disco de 4 KB. Pero sigue siendo 6 veces inferior a lo que pedimos.
Límite de gas de bloqueo
Para la seguridad y confiabilidad de blockchain, debemos establecer límites de gas razonables.
infraestructura
Finalmente, los usuarios no interactúan directamente con los nodos del secuenciador y la mayoría de las personas no ejecutan nodos completos en casa. En cambio, los usuarios envían transacciones a un nodo RPC de terceros y confían en una dApp o un explorador de blockchain, como la interfaz web de http://etherscan.io/, para confirmar los resultados de la transacción.
Por lo tanto, la experiencia real del usuario de una cadena de bloques depende en gran medida de su infraestructura de soporte, como los nodos RPC y los indexadores. No importa qué tan rápido se ejecute una cadena de bloques en tiempo real, si los nodos RPC no pueden manejar de manera eficiente la gran cantidad de solicitudes de lectura durante las horas pico, propagar las transacciones a los nodos clasificadores rápidamente o los indexadores no pueden actualizar las vistas de las aplicaciones lo suficientemente rápido para mantenerse al día, entonces no importa.
Escalar blockchain con un enfoque de principios
Comprometidos con un enfoque holístico y basado en principios para la investigación y el desarrollo. Al realizar un análisis de rendimiento en profundidad desde el principio, nos aseguramos de mantenernos enfocados en resolver problemas que brinden beneficios reales a nuestros usuarios. De hecho, la clave es la perspectiva general, profunda y del usuario.
4. Tipos de aplicaciones esperados
• juego
• Infraestructura física descentralizada (dePin) que requiere computación en tiempo real
• Motor mundial autónomo
• Red VPN descentralizada
• Pagos transfronterizos
• Aprovechar el comercio de alta frecuencia con una latencia extremadamente baja (¿Binance en cadena?)
De hecho, la parte de la aplicación debería tener mucho espacio para la imaginación. He escuchado muchos espacios relacionados y siento que el pensamiento de todos todavía no es lo suficientemente bueno.