Glamsterdam se actualiza, la respuesta de L1 para la escalabilidad de Ethereum

Original  Odaily Star Daily jk

La próxima actualización de Glamsterdam de Ethereum es, según los desarrolladores principales, la reestructuración del protocolo con el mayor cambio desde The Merge. Este nombre proviene de la combinación de dos partes: la parte de actualización de la capa de ejecución mantiene el nombre "Amsterdam", en honor a la ciudad donde se celebró el Devconnect anterior; la parte de actualización de la capa de consenso se llama "Gloas", en honor a una estrella. Tras la actualización de Fusaka, Glamsterdam avanza en la escalabilidad de L1 reorganizando la forma en que la red procesa transacciones y gestiona su base de datos en crecimiento, actualizando fundamentalmente la forma en que Ethereum crea y verifica bloques.

Esta actualización se centra en tres objetivos clave:

• Aceleración del procesamiento (paralelización): Reorganizar la forma en que la red registra las dependencias de datos, permitiendo procesar de manera segura una gran cantidad de transacciones simultáneamente, en lugar de hacerlo de forma secuencial y lenta.
• Escalabilidad: Dividir el trabajo pesado de creación y verificación de bloques, permitiendo que la red tenga más tiempo para propagar grandes cantidades de datos sin desacelerarse.
• Sostenibilidad: Ajustar las tarifas de la red para reflejar con precisión el costo a largo plazo del hardware necesario para almacenar nuevos datos, despejando el camino para futuros aumentos en el límite de Gas, mientras se evita la degradación del rendimiento del hardware.

Las dos propuestas principales de la actualización se encuentran en la capa de consenso y en la capa de ejecución:

Hay dos grandes propuestas principales. Fuente: Ethereum

Propuesta Principal Uno: ePBS, convertir "intermediarios externos" en "reglas integradas"

Comencemos con la propuesta principal de la capa de consenso, que separa a los proponentes de los constructores, conocida como ePBS (EIP-7732).

Cada vez que Ethereum crea un bloque, en realidad se divide en dos pasos: una persona se encarga de "seleccionar qué bloque" (el proponente), y otra persona se encarga de "ensamblar las transacciones dentro del bloque" (el constructor). Actualmente, esta división de trabajo no está estipulada por el protocolo de Ethereum, sino que depende de un grupo de "empresas intermediarias" fuera de la cadena (llamadas relés) para facilitarlo. Esta relación fuera de la cadena también crea un camino durante la verificación del bloque, obligando a los validadores a apresurarse a completar la difusión y ejecución de transacciones en una ventana de 2 segundos, limitando la cantidad de datos que la red puede procesar. Es como si en un restaurante, el proceso de tomar pedidos y cocinar dependiera de un intermediario externo; si este intermediario falla, la cocina y el servicio pueden perder la sincronización.

Lo que hace ePBS es escribir estas reglas de división de "tomar pedidos - cocinar" en el manual de operaciones del restaurante, sin depender de un intermediario externo. De esta manera, el mecanismo de entrega de bloques confiables y de pago se construye directamente en el protocolo, eliminando la necesidad de depender de middleware de terceros. Sin embargo, si ambas partes desean utilizar algunas funciones complejas que aún no están especificadas en el protocolo, pueden optar por seguir utilizando un intermediario externo. Además, para evitar que el proceso de "entrega de platos" sea caótico, ePBS establece un "grupo de verificación de platos" que revisa "quién tomó el pedido" y "si los platos están listos a tiempo", ampliando la ventana de tiempo de entrega de 2 segundos a aproximadamente 9 segundos, permitiendo al restaurante manejar más pedidos a la vez, lo que significa que Ethereum puede soportar más datos orientados a Layer2.

Propuesta Principal Dos: BALs, preparar una "lista de compras" antes de salir

Ahora hablemos de la propuesta principal de la capa de ejecución, la lista de acceso a nivel de bloque, conocida como BALs (EIP-7928).

Actualmente, la forma en que Ethereum procesa transacciones es un poco como si una persona estuviera comprando en un supermercado con los ojos vendados: debe tocar un artículo, confirmar qué es, antes de decidir qué hacer a continuación, por lo que solo puede procesar una transacción a la vez. Como no se sabe de antemano qué datos se utilizarán en una transacción, como qué cuentas estarán involucradas, el sistema debe procesar las transacciones estrictamente en orden, de lo contrario, dos transacciones pueden intentar modificar los mismos datos (como el saldo de una misma dirección) al mismo tiempo, causando conflictos.

BALs permite que esta persona, antes de salir, obtenga una lista de compras que detalla "a qué estantes ir y qué artículos recoger". Con esta lista, el sistema puede prever qué transacciones no entrarán en conflicto, permitiendo agrupar transacciones no relacionadas y procesarlas simultáneamente en lugar de una por una. Esta lista también tiene un beneficio adicional: cuando nuevos nodos se unen a la red, pueden copiar directamente el resultado final registrado en esta lista, evitando tener que recalcular todas las transacciones históricas complejas, lo que acelera significativamente la sincronización de nuevos nodos. Para facilitar la circulación de esta lista en la red, Glamsterdam también ha empaquetado una actualización de protocolo de transmisión complementaria, permitiendo que los nodos compartan efectivamente estas listas de acceso, y esta actualización de protocolo de transmisión se ha convertido en un requisito obligatorio para todos los clientes de la capa de ejecución.

Propuesta Complementaria: Recalcular las operaciones que "ocupan espacio"

Además de estas dos propuestas principales, Glamsterdam también ha empaquetado dos propuestas complementarias de revalorización, que pueden entenderse como ajustes en la "tarifa de almacenamiento" y la "tarifa de consulta" de la red.

• La primera propuesta es para operaciones como crear cuentas y desplegar contratos que "ocupan espacio de forma permanente" en la red; las tarifas anteriores no eran proporcionales al espacio que realmente ocupaban, ahora se cobrará "por cada unidad de espacio ocupada", con el objetivo de controlar la velocidad de crecimiento de datos de toda la red a un nivel seguro y predecible de 120 GiB por año, asegurando que el uso de hardware común pueda seguir funcionando en esta red. Además, esta tarifa de almacenamiento se contabilizará por separado, sin mezclarse con las tarifas de cálculo de las transacciones, permitiendo a los desarrolladores pagar un poco más de tarifa de almacenamiento para desplegar aplicaciones más grandes y complejas, sin ser bloqueados por el límite total de Gas.
• La segunda propuesta es para operaciones de consulta y lectura de datos existentes en la red, cuyas tarifas anteriores eran demasiado bajas y no reflejaban el costo real de consulta tras el aumento de volumen de datos; esta vez se aumentará el estándar de tarifas para estas operaciones, acercando los precios a la carga real del hardware moderno, y también previniendo que alguien abuse de tarifas demasiado bajas para inundar la red con solicitudes de consulta.

Fecha de lanzamiento de la mainnet: aún no se ha fijado

En cuanto al cronograma, Glamsterdam se encuentra actualmente en una fase bastante delicada. A nivel oficial, la última reunión ejecutiva de todos los desarrolladores principales (ACDE) que se puede verificar fue la número 241, el 16 de julio, y la agenda principal incluía un informe sobre el progreso más reciente de la fase Devnet de Glamsterdam, así como la votación para seleccionar propuestas principales para la próxima actualización, Hegota. Un cronograma ampliamente citado en la industria muestra que la fase Devnet ha pasado por ocho iteraciones de 0 a 7, desde el 28 de marzo de 2026 hasta el 8 de julio, y luego se programó el fork de la red de pruebas Sepolia para el 3 de agosto de 2026, y el fork de la red de pruebas Hoodi para el 17 de agosto de 2026, con una fecha objetivo de activación de la mainnet para el 16 de septiembre de 2026.

El cronograma original era para la primera mitad de 2026, fuente: Ethereum

Sin embargo, según los últimos movimientos, es probable que este cronograma se haya retrasado. El equipo de EthPandaOps ha lanzado recientemente una nueva red de pruebas llamada Plataberget, que es la primera red de pruebas pública a corto plazo diseñada específicamente para Glamsterdam; el despliegue oficial de Sepolia y Hoodi se espera que se retrase hasta septiembre, y el objetivo de lanzamiento de la mainnet también se ha movido a la cuarta trimestre de 2026. Esta es la segunda vez que Glamsterdam ha experimentado un deslizamiento de fechas, tras el retraso inicial de la primera mitad de 2026. Los desarrolladores principales han enfatizado en múltiples ocasiones que la corrección de la actualización es prioritaria sobre cumplir con cualquier fecha específica, por lo que antes de que la reunión formal de ACD fije una altura de bloque específica, podríamos no ver esta actualización hasta el cuarto trimestre o incluso hasta finales de año.

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.