Las últimas semanas no he compartido muchas actualizaciones sobre @ethrex_client, nuestro cliente de ejecución L1 @class_lambda @ethereum y la pila ZK L2. Por favor, sigue a @ethrex_client para aprender más sobre todo lo que estamos haciendo. En el L1 ya estamos ejecutando con éxito las testnets de Ethereum y en el L2 estamos ejecutando testnets para las aplicaciones de identidad y DeFi que estamos construyendo para y con socios. Honestamente creo que estamos cerca de tener la base de código y la pila más simples de mantener, actualizar y modificar en Ethereum. No habríamos podido llegar a este punto sin revisar el código de @NethermindEth y @go_ethereum. Con mis socios @rj_aligned, @fran_aligned de @alignedlayer y @SantiDiPaolo, @AguuMg de @PolFinance_ estamos a punto de lanzar uno de los primeros documentos técnicos sobre un RWA L2 que será impulsado por Ethrex y @alignedlayer. Tenemos muchos más en camino, pero estoy particularmente emocionado por este ya que conectará un caso de uso muy interesante entre TradFi y DeFi. Contamos como asesores y socios con algunos de los equipos más fuertes de la industria. Estoy ansioso por compartir más sobre este proyecto. Actualizaciones L1 Hemos estado trabajando en muchos frentes. Hemos mejorado la observabilidad con Grafana, eliminado características no utilizadas para simplificar la base de código y añadido soporte para el endpoint `engine_getBlobsV1`. Changelog: feat(l1): endpoint de solicitud `engine_getBlobsV1` (#3636) chore(l1): eliminar soporte para redb (#4103) refactor(l1): eliminar usizes innecesarios del crate de blockchain (#4110) fix(l1): eliminar clon de estado innecesario (#4117) fix(l1): usar la imagen de docker adecuada para iniciar localnets. (#4131) chore(l1): añadir tiempo de bloque al panel de Grafana. (#4112) fix(l1): restar tiempos de lectura de DB de la ejecución de bloques. (#4051) chore(l1): mejoras en métricas. (#4118) chore(levm): mejorar la organización del nuevo corredor de pruebas levm (#3958) L2 En línea con nuestro enfoque minimalista, hemos eliminado una cantidad significativa de código de bases de datos L2 no utilizadas. Continuamos simplificando la base de código y eliminando código muerto. Además, la CI se estabilizó después de corregir un error relacionado con los precios del gas. Estamos evaluando el L2 en dos frentes: - Costo de mantenimiento de la red L2: Estamos ajustando los parámetros de L2 simulando varios escenarios con diferentes cargas de trabajo de transacciones y configuraciones de red. El objetivo es determinar el costo aproximado de la comisión de mantenimiento por transacción que los usuarios deben asumir para que la red logre la autosostenibilidad. - Benchmarks de generación de prueba de ejecución de bloques aislados: Usando la herramienta ethrex-replay, estamos probando bloques de Hoodi, Sepolia y Mainnet para identificar posibles errores en la base de código y medir el rendimiento de nuestro probador. En el lado de ethrex-replay, la herramienta es lo suficientemente estable y tenemos infraestructura configurada para reproducir periódicamente las ejecuciones de bloques y pruebas de redes públicas. Ahora estamos abordando errores que surgieron durante estas ejecuciones. Algunos errores provienen de errores lógicos en ethrex, mientras que otros están relacionados con el uso de memoria. Los primeros están mayormente resueltos y estamos avanzando significativamente en los últimos. También hemos comenzado a mirar @ziskvm y @0xLita ZKVMs para una posible integración a corto plazo. Ya apoyamos a @RiscZero y @SuccinctLabs. Esta semana, fusionamos un PR que estabiliza ethrex-replay, lo que nos permite identificar y resolver dos errores en ethrex. Estas correcciones también han sido fusionadas. El primer error involucró un caso límite en nuestra precompilación ecrecover, donde una entrada específica causó que la ejecución fallara debido a un desajuste de gas. Después de una investigación exhaustiva, rastreamos el problema a la biblioteca secp256k1 oficial parcheada por SP1. Lo resolvimos migrando a la biblioteca k256 parcheada por SP1. El segundo error provino de una suposición incorrecta sobre la longitud de bits de un tipo usize en parte de la base de código. Para prevenir problemas similares, realizamos una revisión exhaustiva de la base de código y presentamos múltiples PRs para restringir el uso de usize a dos casos específicos: indexación y escenarios restringidos por una API o biblioteca. Además, estamos añadiendo soporte para ejecutar las suites de pruebas de EF, incluyendo pruebas de blockchain y estado, con SP1 para mejorar nuestra cobertura de pruebas y asegurar robustez en diferentes escenarios de ejecución. Con estos errores abordados, los problemas ya no ocurren. Estamos reproduciendo con éxito nuevos bloques de Hoodi y Sepolia, y las ejecuciones de bloques de Mainnet mejoraron significativamente, con la tasa de éxito de ejecución de SP1 aumentando de 1/10 a 6/10. Este progreso despeja el camino para abordar nuestros desafíos restantes con las reproducciones de bloques recientes: errores de falta de memoria durante la ejecución de bloques en el zkVM de SP1 y problemas de rendimiento en la ejecución y prueba. Para abordar estos, hemos configurado el crate de la herramienta para el perfilado de memoria utilizando el crate Jemalloc. También estamos trabajando en soportar la reproducción de bloques históricos. Un MVP para esta característica está en un PR en borrador y funciona bien con los clientes ethrex, reth y geth, pero encuentra problemas con los clientes de nethermind. Antes de lanzar la primera versión, nuestro objetivo es optimizar las solicitudes RPC para asegurar descargas precisas de datos de bloques, incluso al usar proveedores de RPC gratuitos, para la mayoría de los bloques. Mejoras en DevEx: - Hemos corregido nuestras compilaciones binarias para que ya no requieran CUDA como dependencia predeterminada en ciertos sistemas operativos y arquitecturas. Esta corrección está incluida en la última versión. - Se ha presentado un PR para actualizar la versión de ethrex en rex, asegurando compatibilidad con los últimos cambios en ethrex L2. - Hemos comenzado a desarrollar una nueva pestaña para el monitor de ethrex L2 en entornos de desarrollo. Esta pestaña mostrará información relevante para los desarrolladores, como una lista de cuentas ricas y las direcciones de los contratos L1 y L2. Changelog: - refactor(l2): reemplazados los constantes de diferencia de estado usize. - feature(l1,l2): configurado ethrex-replay para el perfilado de memoria. - refactor(l1): eliminado el uso innecesario de usize en el crate de blockchain (relacionado con la corrección de errores). - feature(l1,l2): añadidos nuevos comandos al testigo de ejecución. - fix(levm): abordados problemas relacionados con la arquitectura de 32 bits (relacionado con la corrección de errores). - refactor(levm): actualización de la implementación de ecrecover para usar k256 en lugar de secp256k1 (relacionado con la corrección de errores). - ci(l1,l2): separadas las compilaciones de GPU y adoptado el objetivo x86-64-v2. Rendimiento Esta semana continuamos nuestro enfoque en el consumo de CPU y benchmarks. En cuanto al consumo de CPU, identificamos 2 casos diferentes, uno donde la construcción de bloques está presente y otro donde no. Estamos priorizando los que no tienen construcción de bloques dado que están presentes siempre y afectan otros esfuerzos (como la sincronización instantánea). Hasta donde hemos investigado, está completamente relacionado con p2p. Continuaremos nuestros esfuerzos en este frente. Con respecto a los benchmarks, después de nuestra mejora de la semana pasada en el rendimiento de modexp, nos enfocamos en algunas mejoras detectadas, como codecopy y operaciones relacionadas, así como signextend, mulmod y addmod. Continuaremos nuestro enfoque tanto en el consumo de CPU como en el rendimiento de las pruebas que identificamos como próximos pasos para posibles mejoras, como transferencias de eth y otros opcodes de levm.