Un borrador para Ethereum propone blobs de tamaño variable y una nueva verificación de PeerDAS

Una propuesta sin número definitivo ni adopción

Francesco Risitano abrió el 1 de noviembre a las 03:51 UTC una solicitud de modificación en el repositorio Ethereum EIPs. Su texto, «Post-Quantum PeerDAS and Variable-Size Blobs», describe otra forma de verificar los datos asociados a los blobs. En el control de la redacción, la solicitud número 12604 está abierta, marcada como borrador y sin fusionar. Ese número identifica la solicitud de GitHub; no es el número definitivo de un estándar de Ethereum.

El archivo lleva una fecha interna de creación del 26 de octubre, distinta de su presentación pública del 1 de noviembre. Expone una arquitectura para debatir, con varias dependencias técnicas y elementos todavía por definir. El procedimiento EIP distingue precisamente un documento de diseño de su implementación. Ni la presentación ni la etiqueta de borrador significan que los clientes de Ethereum hayan adoptado las reglas propuestas o que se haya decidido su activación en la red principal.

Cambiar las pruebas conservando el muestreo

El proyecto sustituiría los compromisos KZG de los blobs por compromisos de Merkle basados en Keccak-256. Cada fragmento muestreado se autenticaría mediante una ruta de hashes conectada con la raíz de su blob. Una prueba STARK LeanDA verificaría la relación de codificación Reed–Solomon y la derivación correcta de los compromisos. Sin embargo, el texto conserva los mecanismos de custodia de columnas, muestreo y umbrales de reconstrucción de PeerDAS; no propone eliminarlos.

El objetivo declarado es dejar atrás las hipótesis de seguridad sobre curvas elípticas y la ceremonia de configuración de confianza asociadas a KZG. No obstante, el autor precisa que la resistencia poscuántica depende de la seguridad de toda la construcción, incluidos el hash, la prueba y su agregación. También distingue dos funciones: demostrar que la codificación y el compromiso son correctos no prueba, por sí solo, que los datos sigan disponibles en la red.

Tamaños ajustables y costes pendientes de evaluación

Los blobs podrían medir entre 2.048 y 524.288 bytes, con tamaños permitidos que sean potencias de dos. Cada blob conservaría 128 celdas; variaría la longitud de cada una. El proyecto busca evitar que un emisor con pocos datos tenga que pagar capacidad no utilizada o esperar hasta reunir un lote mayor. Esa motivación no es una medición de una reducción de comisiones ya observada: las nuevas reglas no están desplegadas.

La contabilidad propuesta suma la longitud del blob y un cargo fijo correspondiente a los nodos internos de su árbol de Merkle. Iría acompañada de cambios en las transacciones, los intercambios de red y las interfaces entre clientes. El documento prevé una transición que requeriría modificar el consenso, realizar pruebas y medir el rendimiento. También señala que las rutas de autenticación aumentan el ancho de banda y la exposición a la denegación de servicio frente a las pruebas KZG. Esos compromisos siguen pendientes de evaluación antes de cualquier decisión de integración.