Vitalik: Fusaka está desarrollando la funcionalidad central PeerDAS, diseñada para lograr una cadena de bloques en tiempo real sin necesidad de descargar datos completos.

【Vitalik: Fusaka está desarrollando la función central PeerDAS, diseñada para lograr una cadena de bloques en tiempo real sin necesidad de descargar datos completos】 El fundador de Ethereum, Vitalik Buterin, publicó en la plataforma X que, para Fusaka, la seguridad es lo más importante. Su función central PeerDAS está intentando hacer algo sin precedentes: crear una cadena de bloques en tiempo real que no requiera que ningún nodo individual descargue todos los datos. La forma de trabajar de PeerDAS es que cada nodo solo solicita una pequeña cantidad de "bloques de datos" (chunk), para verificar de manera probabilística que más del 50% de los bloques de datos son utilizables. Si más del 50% de los bloques de datos son utilizables, entonces, teóricamente, el nodo puede descargar estos bloques de datos y usar la codificación de borrado (erasure coding) para recuperar el resto de los datos. En la primera versión, los datos completos del bloque aún necesitan existir en un solo lugar, hay dos situaciones: (i) difusión inicial (initial broadcasting)：cuando los datos se publican por primera vez； (ii) reconstrucción de datos (reconstruction): cuando el publicador ha lanzado bloques de datos entre el 50% y el 100%. Pero estos roles son todos de confianza cero: solo necesitamos un participante honesto para ejecutar estas tareas, incluso si hay 100 participantes deshonestos, el protocolo los eludirá. Además, diferentes nodos pueden ejecutar esta tarea para diferentes bloques. En el futuro, la mensajería a nivel de celda y la construcción de bloques distribuidos permitirán que estas dos funciones también se puedan distribuir. Estas son todas tecnologías nuevas, y es prudente que los desarrolladores principales mantengan un enfoque extremadamente cauteloso durante las pruebas, incluso si han trabajado en ello durante muchos años. Esta es también la razón por la cual la cantidad inicial de blobs aumentará de manera conservadora y luego se volverá más agresiva con el tiempo. Pero esta es la clave para la expansión de L2 (y, en última instancia, también es la clave para la expansión de L1, una vez que el límite de gas de L1 sea lo suficientemente alto como para que tengamos que poner los datos de ejecución de L1 en blobs).