Ir al contenido principal

Última actualización de la página: 24 de julio de 2024

Danksharding

Gracias a Danksharding (es decir, a la fragmentación), Ethereum se convierte en una cadena de bloques realmente escalable, aunque para llegar aquí, hay varias actualizaciones de protocolo necesarias. ProtoDanksharding es un paso intermedio en el camino. Ambas tienen como objetivo hacer que las transacciones a la capa 2 sean tan baratas como sea posible para los usuarios y deben escalar Ethereum a >100.000 transacciones por segundo.

¿Qué es ProtoDanksharding?

ProtoDanksharding, también conocido como EIP-4844(opens in a new tab), es una manera para que los rollups añadan datos más baratos a los bloques. El nombre proviene de los investigadores que propusieron la idea: Protolambda y Dankrad Feist. Historicamente los rollups se habían visto limitados en la medida en que pueden abaratar las transacciones de los usuarios por el hecho de que publican sus transacciones en CALLDATA.

Esto es caro porque es procesado por todos los nodos de Ethereum y reside en la cadena para siempre, aunque los rollups solo necesiten los datos durante un breve periodo de tiempo. ProtoDanksharding introduce los blobs de datos que se pueden enviar y adjuntar a los bloques. Los datos de estos blobs no son accesibles para la EVM y se eliminan automáticamente después un periodo de tiempo fijo (establecido en 4096 épocas en el momento de redactar este documento, es decir, unos 18 días). Esto significa que los rollups pueden enviar datos de forma más barata y trasladar el ahorro a los usuarios finales en la forma de transacciones más baratas.

¿Cómo se verifican los datos de una masa?

Los rollups publican las transacciones que ejecutan en blobs de datos. También publican un "compromiso" con los datos. Para ello, ajustan una función polinómica a los datos. Esta función puede evaluarse en varios puntos. Por ejemplo, si definimos una función extremadamente simple f(x) = 2x-1, podemos evaluarla por x = 1, x = 2, x = 3 dando los resultados 1, 3, 5. Un probador aplica la misma función a los datos y la evalúa en los mismos puntos. Si cambian los datos originales, la función no será idéntica y, por lo tanto, tampoco lo serán los valores evaluados en cada punto. En realidad, el compromiso y la prueba son más complicados, porque están involucrados en funciones criptográficas.

¿Qué es KZG?

KZG son las siglas de Kate-Zaverucha-Goldberg, los nombres de los tres autores originales(opens in a new tab) de un esquema que reduce un blob de datos a un pequeño "compromiso" criptográfico(opens in a new tab). El blob de datos enviado por un rollup tiene que verificarse para garantizar que el rollup no se esté comportando indebidamente. Esto incluye un probador que reejecute las transacciones en el blob para verificar la fiabilidad del compromiso. Es igual que la forma en que los clientes de ejecución comprueban la validez de las transacciones de Ethereum en la capa 1 usando pruebas de Merkle. KZG es una prueba alternativa que ajusta una ecuación polinómica a los datos. El compromiso evalúa el polinomio en algunos puntos de datos secretos. Un probador encajaría el mismo polinomio en los datos y lo evaluaría en los mismos valores, asegurándose de que el resultado sea el mismo. Es una forma de comprobar que los datos son compatibles con las técnicas de conocimiento cero usadas por algunos rollups y eventualmente otras partes del protocolo de Ethereum.

¿Qué fue la ceremonia KZG?

La ceremonia KZG fue una forma para que la gente de toda la comunidad de Ethereum generara de manera colectiva una cadena secreta aleatoria de números que se puedieran utilizar para verificar algunos datos. Es muy importante que esta cadena de números no sea conocida y no pueda ser recreada por nadie. Para asegurarse eso, cada persona que participó en la ceremonia recibió una cadena del participante anterior. Luego, creó algunos valores aleatorios nuevos (p. ej. permitiendo que su navegador midiera los movimientos del mouse) y los mezcló con el valor anterior. Después envió el valor al siguiente participante y lo destruyó de su máquina local. Mientras una persona en la ceremonia haya actuado con honestidad, el valor final será desconocido para un atacante.

La ceremonia KZG EIP-4844 estuvo abierta al público y decenas de miles de personas participaron para añadir su propia entropía (aleatoriedad). En total, hubo más de 140.000 contribuciones, lo que la convierte en la ceremonia más grande del mundo de su tipo. Para frustrar la ceremonia, el 100 % de los participantes tendría que actuar de mala fe. Desde la perspectiva de los participantes, si saben que se han comportado mal, no necesitan confiar en nadie más, porque saben que aseguraron la ceremonia (cumplieron individualmente con el requisito de 1-de-N participantes honestos).

Ni Danksharding ni Proto-Danksharding siguen el modelo tradicional de "sharding" que tiene como objetivo dividir la cadena de bloques en varias partes. Las cadenas de fragmentación ya no forman parte de la hoja de ruta. En su lugar, Danksharding utiliza el muestreo distribuido de datos en varias masas para escalar Ethereum. Su implementación es mucho más sencilla. A este modelo a veces se le denomina «fragmentación de datos».

¿Qué es Danksharding?

Danksharding es la máxima expresión de la escalabilidad de las acumulaciones, que comenzó con ProtoDanksharding. Danksharding aportará una gran cantidad de espacio en Ethereum para que las acumulaciones depositen sus datos comprimidos de transacciones. Esto significa que Ethereum será compatible con cientos de acumulaciones individuales con facilidad y hará realidad la posibilidad de realizar millones de transacciones por segundo.

La forma en que esto funciona es expandiendo los blobs adjuntos a los bloques de seis (6) en Proto-Danksharding a 64 en Danksharding completo. El resto de los cambios necesarios son todas actualizaciones en la forma en que operan los clientes de consenso para permitirles gestionar las grandes masas. La hoja de ruta ya incluye varias de estas modificaciones con otros objetivos independientes del Danksharding. Por ejemplo, Danksharding requiere que se haya implementado la separación entre el generador de propuestas y el constructor de bloques. Esta es una actualización que separa las tareas de construir bloques y proponer bloques entre diferentes validadores. De manera similar, el Danksharding requiere el muestreo de disponibilidad de datos, aunque también es necesario para el desarrollo de clientes muy ligeros que no almacenen mucha información histórica («clientes sin estado»).

Progreso actual

La implementación completa del Danksharding está aún fuera de escena. Mientras tanto, la ceremonia KZG ha concluido con más de 140.000 contribuciones, y el EIP(opens in a new tab) para Proto-Danksharding ha madurado. Esta propuesta ha sido completamente implementada en todas las redes de prueba, y se activó en la Red principal con la actualización de red Cancun-Deneb ("Dencun") en marzo de 2024.

Más información

¿Le ha resultado útil este artículo?