Ethereum 'Actualización de dos vías'... Glamsterdam en la red de pruebas pública y Hegotá en validación inicial

[Reportera de Blockmedia, Ham Ji-hyun] Ethereum continúa con los preparativos para la implementación de su próxima actualización, 'Glamsterdam', en la red de pruebas Sepolia. La actualización posterior, 'Hegotá', también se desarrolla de manera paralela, probando funciones clave antes de integrarlas.

Según la reunión de pruebas de desarrolladores 'ACDT #97', organizada por Ethereum Collective Korea (ECK) el 24 de octubre, el equipo de desarrollo coordinó el cronograma de la red de pruebas Glamsterdam y el método de prueba inicial para Hegotá en una reunión el 21 de octubre (hora local). La discusión se centró en cómo validar las funciones ya en desarrollo en lugar de agregar nuevas.

El flujo principal de actualizaciones de Ethereum ya se ha implementado en la mainnet con 'Fusaka', seguido por 'Glamsterdam', que actualmente está en validación, y luego 'Hegotá'. Glamsterdam tiene como objetivo su implementación en la mainnet en el cuarto trimestre de este año, mientras que Hegotá está programada para el segundo trimestre del próximo año, aunque no se han fijado fechas concretas.

Para que Glamsterdam se implemente en la mainnet, primero debe confirmarse la estabilidad de las nuevas funciones en la red de pruebas. Las redes de pruebas de Ethereum utilizadas en este proceso son 'Sepolia' y 'Hoodi'. El equipo de desarrollo planea aplicar Glamsterdam primero en estas dos redes de pruebas, donde en Sepolia se verificará principalmente si las aplicaciones y contratos inteligentes funcionan correctamente, y en Hoodi se confirmará que no haya problemas con las funciones de la red, como la operación de validadores y el staking.

Sepolia y Hoodi no son nombres de actualizaciones separadas, sino redes de pruebas de Ethereum que se utilizan para validar nuevas funciones antes de su implementación en la mainnet. Sepolia se utiliza principalmente para aplicaciones y contratos inteligentes, mientras que Hoodi se utiliza para probar la operación de validadores y el staking, así como las actualizaciones de la red. Por lo tanto, no se aplica Hoodi a Ethereum, sino que se aplica primero la actualización Glamsterdam en la red de pruebas Hoodi para confirmar su estabilidad.

Glamsterdam ha entrado en la fase de definir el alcance de las funciones clave y verificar su estabilidad en la red de pruebas para desarrolladores (devnet). Anteriormente, la Fundación Ethereum presentó el 17 de septiembre una red de pruebas preliminar llamada 'Platåberget', en la que también pueden participar desarrolladores y operadores de nodos, creando un entorno para verificar que las billeteras y varios servicios funcionen correctamente después de la actualización.

La próxima fecha clave es el 6 de octubre, cuando se aplicará Glamsterdam en la red de pruebas Sepolia. En consecuencia, cada equipo de desarrollo se comprometió a distribuir una nueva versión del software de funcionamiento de la red, el cliente, antes del 29 de este mes. La fecha provisional para aplicar Glamsterdam en la red de pruebas Hoodi se ha propuesto para el 27 de octubre, y se decidirá el progreso el 8 de octubre.

En resumen, Glamsterdam está en proceso de verificación tras el diseño funcional y la implementación inicial, y queda por confirmar la estabilidad en las redes de pruebas públicas existentes como Sepolia y Hoodi antes de su introducción en la mainnet. Aunque se ha fijado la fecha de aplicación en Sepolia, esto no significa que la fecha de lanzamiento de la mainnet esté confirmada.

El núcleo de Glamsterdam radica en cambiar la estructura interna de Ethereum para poder manejar más transacciones. ePBS, que gestiona la separación de roles entre los creadores de bloques y los validadores que proponen estos bloques como una regla de la red, y BAL, que proporciona una lista de qué datos lee y modifica cada transacción, son ejemplos representativos. En particular, BAL establece una base que permite procesar múltiples tareas simultáneamente al distinguir transacciones que no se afectan entre sí.

También se está llevando a cabo un programa de recompensas por errores, donde se recompensa a quienes encuentran y reportan vulnerabilidades. Sin embargo, a partir del 24 de octubre, las recompensas relacionadas con Glamsterdam están limitadas a especificaciones técnicas y propuestas de mejora de Ethereum (EIP). El código de implementación de Glamsterdam en el cliente aún no es objeto de recompensas, y el alcance de las recompensas se ampliará tras el anuncio de la versión candidata de lanzamiento.

Hegotá, validación separada de 'prevención de censura de transacciones' y 'comodidad de billetera'

Hegotá, que se está preparando para el período posterior a Glamsterdam, se encuentra en la etapa de definir funciones clave y avanzar en la implementación inicial y la configuración de la red de pruebas. Las funciones principales son 'FOCIL (lista de inclusión obligatoria basada en la elección de bifurcación)' y 'Transacción de marco (EIP-8141)', mientras que se necesita más discusión sobre otros componentes detallados.

FOCIL es un mecanismo que dificulta que los creadores de bloques excluyan intencionadamente transacciones normales de ciertos usuarios. Su objetivo es reducir el problema de que algunos operadores concentren el poder de selección de transacciones al presentar una lista de transacciones que varios validadores deben incluir en el bloque y hacer que se adhieran a ella.

La transacción de marco es una propuesta para reflejar la 'abstracción de cuentas', que define programáticamente el método de aprobación de transacciones y el manejo de tarifas de la billetera, en las reglas de transacción básicas de Ethereum, haciendo que el método de aprobación de transacciones y el pago de tarifas de la billetera sean más flexibles. Es fundamental que la red apoye directamente las funciones que anteriormente eran proporcionadas a través de una infraestructura separada por ERC-4337.

En ERC-4337, cuando un usuario envía una solicitud llamada 'UserOperation' en lugar de una transacción normal, un 'bundler' actúa como intermediario, recopilando estas solicitudes y presentándolas como transacciones de Ethereum. Posteriormente, un contrato inteligente común llamado 'EntryPoint' gestiona el proceso de verificación de las condiciones de aprobación de la billetera y la ejecución de la solicitud. Si el servicio paga la tarifa del usuario, también se utiliza un contrato separado llamado 'Paymaster'. Esto permite implementar funciones convenientes de billetera sin cambiar las reglas básicas de transacción de Ethereum, pero requiere infraestructura adicional para conectarlas.

Por otro lado, la transacción de marco consiste en varios pasos de procesamiento, como 'verificación de aprobación del usuario', 'verificación de consentimiento del pagador de tarifas' y 'ejecución real de la tarea'. Esto implica verificar si el usuario ha aprobado la transferencia y si el servicio ha aceptado asumir la tarifa, y luego ejecutar la transferencia real en un solo marco de transacción. A diferencia de la forma de procesar solicitudes de usuario en transacciones existentes, se cambia la forma de transacción de Ethereum para que soporte esta estructura.

Por ejemplo, cuando un usuario que solo posee stablecoins sin ETH realiza una transferencia, se puede diseñar para que el pagador asuma la tarifa en ETH en la red y cobre al usuario en stablecoins. También es posible agrupar 'aprobación de uso de tokens' y 'intercambio de tokens' en una sola transacción en un intercambio descentralizado, de modo que si el intercambio falla, la aprobación de uso también se revierta.

En esta reunión, el equipo de desarrollo decidió probar ambas funciones en devnets separadas y, una vez que su funcionamiento básico sea estable, combinarlas en una única devnet de Hegotá. Se considera que introducir funciones complejas de una sola vez puede dificultar la identificación de errores si ocurren.

Sin embargo, también se expresó la opinión de que las pruebas individuales no son suficientes. Es necesario verificar si FOCIL, que exige que las transacciones se incluyan en bloques, funciona sin problemas junto con el nuevo formato de transacción de marco. Tony Varshtetter, investigador de la fundación, destacó que dado que ambas funciones afectan estrechamente el espacio de espera de transacciones, conocido como 'mempool', es importante realizar una validación de integración temprana.

Matt Garnett, desarrollador de Geth, expresó su deseo de tener devnets de marco y FOCIL funcionando antes de Devcon. Se propuso avanzar hacia una devnet de integración en octubre si las pruebas iniciales son satisfactorias. Esto tiene como objetivo el funcionamiento de la red de pruebas para desarrolladores, pero no significa que Hegotá se introducirá en la mainnet en ese momento.

En relación con Glamsterdam, también se discutió cuánto tiempo deben conservar los nodos que participan en la operación de la red los datos auxiliares necesarios para el procesamiento de bloques y transacciones. Reducir el período de retención podría disminuir la capacidad de almacenamiento necesaria para los operadores.

Sin embargo, si un software elimina datos, pero el otro debe conservar los mismos datos, la carga total de almacenamiento no se reduce. Por lo tanto, se sugirió que se ajusten los criterios de retención de datos tanto para la 'capa de ejecución' que procesa las transacciones como para la 'capa de consenso' que se encarga de los bloques.

El equipo de desarrollo no fijó un período de retención en esta reunión y lo dejó para discusiones en línea y futuras reuniones de desarrolladores. También se confirmó que este asunto no es una condición que impida la aplicación de Glamsterdam en la red de pruebas Sepolia.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.