En las últimas semanas no he compartido muchas actualizaciones sobre @ethrex_client, nuestro cliente de ejecución @class_lambda @ethereum L1 y la pila ZK L2. Siga @ethrex_client para obtener más información sobre todo lo que estamos haciendo. En la L1 ya estamos ejecutando con éxito las redes de prueba de Ethereum y en la L2 estamos ejecutando redes de prueba para las aplicaciones de identidad y DeFi que estamos construyendo para y con los socios. Honestamente, creo que estamos cerca de tener la base de código y la pila más simples para mantener, actualizar y modificar en Ethereum. No hubiéramos podido llegar a este punto sin verificar 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 por venir, pero estoy particularmente emocionado por este, ya que unirá un caso de uso muy interesante de TradFi y DeFi. Tenemos como asesores y socios 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, hemos eliminado las funciones no utilizadas para simplificar la base de código y hemos añadido compatibilidad con el punto de conexión "engine_getBlobsV1". Registro de cambios: feat(l1): extremo de solicitud 'engine_getBlobsV1' (#3636) Tarea (L1): Eliminar el soporte de RedB (#4103) Refactor(L1): Eliminar usos innecesarios de la caja de blockchain (#4110) Corrección (L1): se eliminó el clon de estado innecesario (#4117) Fix(L1): Utilice la imagen de Docker adecuada para hacer girar localnets. (#4131) CHORE(L1): Añadir tiempo de bloque al panel de control de Grafana. (#4112) fix(l1): restar los tiempos de lectura de la base de datos de la ejecución del bloque. (#4051) Tarea (L1): Mejoras métricas. (#4118) TAREA (LEVM): Mejorar la organización del nuevo ejecutor de pruebas de LEVM (#3958) L2 En línea con nuestro enfoque minimalista, eliminamos una cantidad significativa de código de las bases de datos L2 no utilizadas. Continuamos simplificando la base de código y eliminando el código muerto. Además, el IC 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 L2 mediante la simulación de 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 soportar para que la red logre la autosostenibilidad. - Puntos de referencia 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 una infraestructura configurada para reproducir periódicamente las ejecuciones y pruebas de bloques de las redes públicas. Ahora estamos abordando los errores que surgieron durante estas ejecuciones. Algunos errores se derivan de errores lógicos en ethrex, mientras que otros están relacionados con el uso de la memoria. Las primeras están resueltas en su mayor parte, y estamos haciendo progresos significativos en las segundas. También hemos comenzado a buscar ZKVM @ziskvm y @0xLita para una posible integración a corto plazo. Ya apoyamos @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 se han fusionado. El primer error involucró un caso extremo 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 hasta la biblioteca oficial secp256k1 parcheada por SP1. Lo resolvimos migrando a la biblioteca k256 con parches de SP1. El segundo error se debió a una suposición incorrecta sobre la longitud de bits de un tipo usize en parte de la base de código. Para evitar problemas similares, realizamos una revisión exhaustiva del código base y enviamos varias solicitudes de incorporación de cambios para restringir el uso de usize a dos casos específicos: indexación y escenarios restringidos por una API o biblioteca. Además, estamos agregando compatibilidad para ejecutar los conjuntos de pruebas de EF, incluidas las pruebas de cadena de bloques y estado, con SP1 para mejorar nuestra cobertura de pruebas y garantizar la solidez en diferentes escenarios de ejecución. Con estos errores solucionados, 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 repeticiones de bloques recientes: errores de memoria insuficiente durante la ejecución de bloques en el SP1 zkVM y problemas de rendimiento en la ejecución y la prueba. Para solucionarlos, hemos configurado la caja de la herramienta para la creación de perfiles de memoria utilizando la caja Jemalloc. También estamos trabajando para apoyar la repetición de bloques históricos. Un MVP para esta característica está en un borrador de PR y funciona bien con clientes ethrex, reth y geth, pero encuentra problemas con clientes nethermind. Antes de lanzar la primera versión, nuestro objetivo es optimizar las solicitudes RPC para garantizar descargas precisas de datos de bloques, incluso cuando se utilizan proveedores de RPC gratuitos, para la mayoría de los bloques. Mejoras de DevEx: - Se corrigió nuestra compilación binaria para que ya no requiera CUDA como dependencia predeterminada de ciertos sistemas operativos y arquitecturas. Esta corrección se incluye en la versión más reciente. - Se ha enviado un PR para actualizar la versión de ethrex en rex, asegurando la compatibilidad con los últimos cambios en ethrex L2. - Hemos comenzado a desarrollar una nueva pestaña para el monitor ethrex L2 en entornos de desarrollo. Esta pestaña mostrará información relevante para el desarrollador, como una lista de cuentas enriquecidas y las direcciones de los contratos L1 y L2. Registro de cambios: - refactor(L2): se reemplazaron las constantes de diferencia de estado de usize. - Reature(L1,L2): Ethrex-Replay configurado para la creación de perfiles de memoria. - Refactor(L1): Se eliminó el uso innecesario de Usize en la caja de blockchain (relacionado con la corrección de errores). - Característica (L1, L2): Se agregaron nuevos comandos al testigo de ejecución. - Corrección (levm): se abordaron problemas relacionados con la arquitectura de 32 bits (relacionados con la corrección de errores). - Refactor(LEVM): Se actualizó la implementación de ecrecover para usar K256 en lugar de SECP256K1 (relacionado con la corrección de errores). - ci(L1,L2): separó las compilaciones de GPU y adoptó el objetivo x86-64-v2. Rendimiento Esta semana continuamos enfocándonos en el consumo de CPU y los puntos de referencia. En cuanto al consumo de CPU, identificamos 2 casos diferentes, uno en el que la construcción de bloques está presente y otro en el que no. Estamos priorizando los que no tienen construcción de bloques dado que siempre están presentes e impactan en otros esfuerzos (como la sincronización instantánea). Por lo que investigamos, está completamente relacionado con p2p. Continuaremos nuestros esfuerzos en este frente Con respecto a los puntos de referencia, después de nuestra mejora de la semana pasada del rendimiento de modexp, nos enfocamos en algunas mejoras detectadas, como codecopy y operaciones relacionadas, así como signextend, mulmod y addmod. Continuaremos enfocándonos tanto en el consumo de CPU como en el rendimiento de las pruebas que identificamos como próximos pasos para posibles mejoras, como transferencias eth y otros códigos de operación levm.