📺 Vídeo de estudio recomendado hoy: https://www.youtube.com/watch?v=WtOQPxa6jOE

Ethereum ACDC #114: Preparando el Terreno para Deneb y el Nacimiento de Electra

La comunidad de desarrolladores de Ethereum se prepara para el lanzamiento de la actualización Deneb mientras define las bases del próximo gran paso: Electra. Este encuentro detalla desde ajustes técnicos en la API del motor hasta pruebas de estrés masivas para el nuevo sistema de depósitos.

Pregunta central: ¿Cómo están optimizando los desarrolladores la transición hacia Deneb y qué innovaciones estructurales definen el futuro de la capa de consenso con la llegada de Electra?

Puntos clave

• Confirmación oficial de “Electra” como el nombre de la actualización posterior a Deneb.
• Decisión final de no duplicar el hash del bloque Beacon en el payload de ejecución para mantener la pureza arquitectónica.
• Pruebas de estrés exitosas de la EIP-6110 que permite procesar depósitos directamente desde la capa de ejecución.
• Estado actual de Devnet 8 y ajustes de última hora en las especificaciones de nomenclatura para blobs.

⏱️ Tiempo de lectura: aprox. 7 minutos · Te ahorra unos 61 minutos frente a ver el vídeo.

¿Quieres tomar notas mientras ves el vídeo? Haz clic en la imagen de abajo y deja que AI Notebook extraiga los puntos clave por ti 👇

El camino hacia Deneb y el horizonte de Electra

Estabilización de Devnet 8 y nuevos nombres

Los desarrolladores confirmaron que Electra será el nombre oficial para la actualización posterior a Deneb, marcando el inicio formal de su planificación técnica en el repositorio de gestión de proyectos.

Durante la reunión, se discutió el progreso de Devnet 8, destacando que el conjunto de validadores ha crecido deliberadamente para probar el comportamiento de los blobs bajo una carga de transacciones constante. Las herramientas de testeo se están actualizando para facilitar la integración de clientes antes del lanzamiento de la especificación final el próximo lunes, lo que permitirá a los equipos de desarrollo trabajar sobre una base estable de datos.

Un punto crítico fue la búsqueda de consistencia en el nombramiento entre las Propuestas de Mejora de Ethereum (EIP) y las especificaciones del consenso, centrándose específicamente en términos como “versioned hash” frente a “versioned kzg” y las descripciones de los tipos personalizados de los blobs. Aunque estos cambios no afectan la lógica fundamental del consenso, son vitales para asegurar que las herramientas de depuración y monitoreo funcionen correctamente en todo el ecosistema. Los equipos acordaron abrir pull requests inmediatos para resolver estas discrepancias menores antes de congelar las especificaciones para las pruebas finales en redes de prueba públicas.

💡 Profundizando

Q: ¿Por qué es importante resolver los nombres de los campos ahora? A: Para evitar errores en las herramientas de monitoreo y asegurar que los clientes de ejecución y consenso hablen exactamente el mismo idioma técnico.
Q: ¿Qué pasará con la especificación el lunes? A: Se espera la publicación oficial de la nueva versión que servirá de base para las siguientes redes de prueba.
Q: ¿Quién decidió el nombre “Electra”? A: Fue un consenso del grupo tras barajar varias opciones de estrellas, siguiendo la tradición de nomenclatura de la capa de consenso.

Refinando la Arquitectura de Ejecución y Consenso

Simplicidad frente a redundancia en el Engine API

Uno de los debates más intensos de la llamada giró en torno a la inclusión de la raíz del bloque Beacon padre directamente en el payload de ejecución, una propuesta que buscaba facilitar la depuración.

La decisión final de los desarrolladores fue mantener la estructura actual sin cambios, priorizando una arquitectura limpia donde la capa de ejecución no contenga información redundante que ya reside en el bloque Beacon envolvente. Este enfoque refuerza la separación de responsabilidades entre capas y evita que la API del motor contamine las estructuras de datos fundamentales con requisitos estéticos que pueden resolverse mediante herramientas de software externas. Al final, se determinó que duplicar el dato solo añadiría complejidad innecesaria en la validación de los clientes, obligándolos a comprobar que ambos valores coinciden en cada bloque procesado.

Este tipo de decisiones arquitectónicas son las que mantienen a Ethereum eficiente a largo plazo, evitando la acumulación de “deuda técnica” por conveniencias temporales de desarrollo.

💡 Profundizando

Q: ¿Qué es el parent_beacon_block_root? A: Es un campo que permite a los contratos inteligentes en la capa de ejecución acceder a información del estado de la capa de consenso.
Q: ¿Por qué se rechazó la duplicación? A: Para evitar redundancia de datos y comprobaciones adicionales que no aportan seguridad real al sistema.

EIP-6110 y el Futuro de los Depósitos

Eliminando la dependencia del historial de Eth1

El equipo presentó los resultados de los prototipos de la EIP-6110, una propuesta diseñada para que la capa de consenso lea los depósitos directamente desde el payload de ejecución, eliminando el antiguo sistema de sondeo.

Las pruebas de estrés iniciales demostraron que la red puede manejar ráfagas de hasta 725 depósitos por slot, lo cual es significativamente superior a lo que se ve en la red principal actualmente. Durante estas pruebas, el tiempo de procesamiento de bloques aumentó de unos pocos milisegundos a más de un segundo, principalmente debido a la carga de verificación de firmas criptográficas de los nuevos validadores. Este hallazgo es crucial, ya que permite a los desarrolladores optimizar los algoritmos de verificación de firmas antes de que la propuesta se incluya formalmente en un fork.

A pesar del aumento en el tiempo de procesamiento, los desarrolladores concluyeron que el sistema es robusto frente a posibles ataques de denegación de servicio (DoS) mediante depósitos masivos. La transición hacia este modelo nativo simplificará drásticamente la lógica de los clientes, ya que no tendrán que monitorizar el contrato de depósito de la capa 1 de forma independiente, reduciendo los puntos de fallo potenciales.

Conclusiones clave

La reunión ACDC #114 ha servido para consolidar los cimientos de Deneb, cerrando debates técnicos sobre la estructura de los payloads y la nomenclatura de los blobs. La decisión de no duplicar datos en el Engine API subraya un compromiso continuo con la eficiencia del protocolo, prefiriendo la elegancia técnica sobre la comodidad de las herramientas de depuración.

Por otro lado, la presentación de los prototipos de la EIP-6110 para Electra marca un hito en la evolución de los depósitos de validadores. Al mover esta lógica directamente a los bloques de ejecución, Ethereum se encamina hacia una mayor autonomía de su capa de consenso y una reducción de la complejidad heredada de la era Proof of Work.

Preguntas y Respuestas

Q1: ¿Qué es Electra?
A1: Es el nombre oficial de la próxima gran actualización de la capa de consenso de Ethereum tras Deneb.

Q2: ¿Cuál es el estado de Devnet 8?
A2: Está activa y siendo utilizada para pruebas de spam de blobs y crecimiento del conjunto de validadores.

Q3: ¿Se modificará el Engine API para incluir la raíz del bloque Beacon?
A3: No, se decidió no añadir el campo para evitar la duplicación de datos y mantener la simplicidad del payload de ejecución.

Q4: ¿Qué mejora introduce la EIP-6110?
A4: Permite que los depósitos de los validadores se procesen de forma nativa en el payload de ejecución, eliminando la necesidad de que los nodos vigilen el contrato de depósitos en Eth1.

Q5: ¿Cómo afectaron los depósitos masivos al rendimiento en las pruebas?
A5: El tiempo de procesamiento subió a 1.3 segundos por bloque con 725 depósitos, principalmente por la verificación de firmas.

Q6: ¿Qué es la EIP-6914?
A6: Es una propuesta para reutilizar los índices de validadores que han salido completamente de la red, optimizando el estado de la cadena.

Q7: ¿Cuándo se congelará la especificación de Deneb?
A7: Se espera que tras los ajustes de nomenclatura del próximo lunes, la especificación esté lo suficientemente estable para las testnets finales.