Es posible que hayas notado que casi todos los desarrolladores participan y retuitean KZG Ceremony, entonces, ¿qué es KZG Ceremony?
En términos simples, KZG Ceremony es la configuración de confianza del compromiso EIP-4844 KZG, y EIP-4844 es la versión preliminar de la fragmentación completa de Ethereum.

1. Sharding: una solución a largo plazo para el escalado de Ethereum
Mientras que los rollups escalan Ethereum desde la capa de ejecución, la fragmentación mejora la escalabilidad y capacidad de Ethereum desde la perspectiva de la disponibilidad de datos.
El siguiente gráfico de tendencias muestra que el tamaño promedio de bloque fluctúa alrededor de 90 kb a pesar de la rápida iteración de Ethereum estos años. Aunque los paquetes acumulativos alivian notablemente la congestión de la red, el rendimiento general todavía está restringido por la capacidad de almacenamiento de datos de la Capa 1.

Teniendo en cuenta la seguridad y la complejidad de la implementación, la fragmentación se divide en varias fases, que incluyen proto-danksharding y danksharding. Todo el proceso podría llevar varios años.
Dado el esquema de almacenamiento actual, sólo unos pocos hardwares de alto rendimiento pueden participar como nodos. Después de la implementación de la fragmentación, no se requiere que los nodos almacenen el contenido completo de los datos históricos, lo que aprovecha la seguridad de Ethereum al reducir el umbral para convertirse en un nodo (un menor costo de almacenamiento de datos y un mayor grado de descentralización).
2. EIP-4844: rendimiento notable a corto plazo, una versión preliminar de la fragmentación completa de Ethereum
EIP-4844 = Proto-Danksharding;
Dado que la implementación completa del sharding sigue siendo demasiado compleja y podría llevar años, el proto-danksharding es el mejor plan intermedio para reducir la congestión de Ethereum en el corto plazo.

2.1 Resumen de proto-danksharding
Proto-Danksharding introduce un nuevo tipo de transacción llamada transacción portadora de blobs. Al beneficiarse de esta actualización, los paquetes acumulativos pueden utilizar "blob" para transferir datos a L1 y almacenarlos provisionalmente a un costo relativamente menor. El tamaño de un blob es mucho mayor que los datos de llamada actuales.
Acerca de blob:
Cada transacción puede transportar como máximo 2 blobs
Cada bloque normalmente contiene 8 blobs, que tienen una capacidad de 1 MB.
Un bloque puede contener 16 blobs, lo que da como resultado un tamaño de bloque de 2 MB.
Un blob no se almacena permanentemente como registro histórico como los datos de llamada.
En el diseño de proto-danksharding, los nodos aún necesitan descargar el contenido completo de los datos y verificar la disponibilidad de los datos.
2.2 Transacción portadora de blobs en profundidad

Funcionalidad
La funcionalidad de un blob de datos es similar a calldata, que permite que el paquete acumulativo transfiera datos de transacciones y pruebas a L1.
Costo
La intención original del blob es admitir un TPS alto en los paquetes acumulativos. En comparación con calldata, que utiliza almacenamiento en cadena, esos blobs de datos solo se descargan y almacenan durante un período de tiempo. Por lo tanto, el gasto en gasolina para acumulaciones que garanticen la disponibilidad de datos será previsiblemente menor.
Capacidad
El tamaño de cada blob es de 125 kB.
2.3 El valor y el desafío de las transacciones portadoras de blobs
Valor
Es cierto que la aparición de blobs hace que los datos de las transacciones se conviertan en una especie de caché, lo que reduce aún más los requisitos de hardware de almacenamiento para los nodos y reduce la tarifa del gas al proporcionar a Ethereum almacenamiento de datos adicional.
Desafío: calculemos los requisitos de hardware
El caso es que el tamaño de bloque actual ronda los 90kB, pero el tamaño de un blob puede llegar a los 125kB.
Según el diseño de EIP-4844, el tamaño de cada ranura es normalmente de 1 MB, lo que significa que el tamaño total de los datos se puede calcular de la siguiente manera:
1 MB/bloque * 5 bloques/min * 43200 min/mes * 12 meses/año = 2,47 TB por año
Es obvio que el incremento anual de datos es mucho mayor que el total de datos de Ethereum, lo que infiere que este ingenuo plan de almacenamiento de datos no es eficiente.
¿Qué se puede optimizar?
A corto plazo, cada nodo aún necesita almacenar el contenido completo de los datos históricos, pero la capa de consenso se implementa con un esquema según el cual los datos del blob se eliminarán en un período de tiempo determinado (30 días o 1 año, por determinar).
Para obtener beneficios a largo plazo, es necesario implementar EIP-4444, lo que indica que ya no es necesario que los nodos almacenen datos completos. En cambio, se adopta un nuevo mecanismo que permite a los nodos almacenar solo partes de los datos durante un tiempo determinado, en referencia al llamado esquema de caducidad del historial.
2.4 Compromiso KZG
KZG Commitment es un esquema de compromiso polinómico adoptado por el proto-danksharding EIP-4844
La Ceremonia KZG es el proceso de creación de confianza para el Compromiso KZG, que atrae a más de 30.000 participantes.
2.4.1 ¿Qué es el compromiso de KZG?
KZG es una abreviatura de Aniket Kate, Gregory M. Zaverucha e Ian Goldberg, quienes publicaron el ensayo de compromiso polinomial “Constant-Size Commitments to Polynomials and Their Applications” en 2010. KZG Commitment se aplica ampliamente en el estilo plonk zk-snark. protocolo.

Refiriéndose al diagrama de la presentación de Dankrad, la raíz KZG es similar a la raíz de Merkle, excepto que la raíz KZG se compromete con un polinomio, donde cada posición se encuentra en este polinomio. Basado en el escenario de proto-danksharding, la raíz de KZG confirma un conjunto de datos, donde cada punto de datos se puede verificar como parte del conjunto completo.
Una vista rápida de cómo funciona internamente el compromiso de KZG
Prover: Responsable de calcular el compromiso. Por razones de seguridad, un probador no puede modificar el polinomio dado y el compromiso solo es válido para el polinomio actual;
Verificador: Responsable de verificar el compromiso enviado desde el probador.
2.4.2 Ceremonia KZG (configuración confiable)

El proceso de la Ceremonia KZG

Todos pueden unirse como participantes en la ceremonia KZG y contribuir con el secreto. El secreto recién agregado se mezclará con el resultado anterior para formar un nuevo resultado y, finalmente, generará un SRS para la configuración de confianza de compromiso de KZG. (Consulte el diagrama proporcionado por Vitalik para una mejor comprensión)
Configuración de confianza
KZG Ceremony es una configuración de confianza multiparticipante muy utilizada llamada poder de tau;
Esta configuración sigue el modelo de confianza 1 de N, lo que significa que no importa cuántos participantes contribuyan al proceso de generación de la configuración final, siempre que una persona mantenga su secreto, se puede garantizar la validez de la configuración.
Importancia de la ceremonia KZG
El valor de la configuración de confianza del compromiso KZG se puede interpretar de la siguiente manera: generar un parámetro que es necesario para cada ejecución del protocolo criptográfico.
Cuando el probador calcula el compromiso, el compromiso de KZG C = f(s)g1, donde f es la función de evaluación y s es el resultado final de la configuración de confianza de KZG. Por lo tanto, el secreto final generado por la actual ceremonia del KZG es crucial para la siguiente implementación de la fragmentación.
2.4.3 Ventajas del compromiso KZG
Costo
El compromiso KZG tiene una complejidad menor y se puede verificar de manera eficiente.
No se necesitan pruebas adicionales, lo que se traduce en un menor coste y remite el requisito de ancho de banda.
Costo aún menor aprovechando la precompilación de evaluación de puntos.
Seguridad
Si se produce el error, solo se infecta el blob correspondiente al compromiso actual y no hay más efectos en cadena.
Compatibilidad
El compromiso de KZG es más amigable con DAS, lo que evita la redundancia en el desarrollo.
2.5 El beneficio de EIP-4844
Enrollar
Como se muestra en la imagen a continuación, el resumen debe enviar el delta de estado y el hash versionado del compromiso de KZG a través de calldata (zk-rollup aún necesita cargar el zkp).
Después de la implementación de EIP-4844, los costosos datos de llamada solo transportan algunos datos pequeños, como delta de estado y compromisos, mientras que los datos grandes, como el lote de transacciones, se colocan en el blob.
reducir el costo;
Reduzca el uso del espacio de almacenamiento en bloque.

Mejora de la seguridad
Disponibilidad de datos: Blob se almacena en la cadena de balizas, que comparte la misma seguridad que Ethereum L1.
Datos históricos: los nodos solo almacenan blobs durante un cierto período de tiempo y el paquete acumulativo de capa 2 es responsable del almacenamiento permanente de datos, lo que indica que la seguridad de los datos históricos depende del paquete acumulativo.
Costo
La característica de bajo costo de la transacción de transporte de blobs puede optimizar el costo total entre x10 y x50.
Mientras tanto, EIP-4844 introduce una tarifa blob
El gas y el blob tendrán límites y precios de gas ajustables por separado;
La unidad de precio de un blob es el gas, la cantidad de gas flotará según el tráfico de la red, cuyo objetivo es mantener la cantidad que transporta cada bloque (8 en promedio).
Implementación de precompilación.
La ejecución de EVM solo puede ver el compromiso de un blob generado por el probador y no puede acceder a los datos del blob directamente. Por lo tanto, el resumen debe utilizar un esquema de precompilación para verificar la validez del compromiso.
Hay dos algoritmos de precompilación mencionados en EIP-4844
Precompilación de evaluación de puntos
Demuestre que se comprometen múltiples compromisos con el mismo conjunto de datos.
La precompilación de evaluación de puntos es adoptada principalmente por zk-rollup. El rollup debe proporcionar dos compromisos, el compromiso KZG y el compromiso zk-rollup.
En cuanto a la acumulación optimista, la mayoría de ellos han adoptado la prueba de fraude de múltiples rondas, y la ronda final a prueba de fraude tiene un tamaño de datos más pequeño, lo que significa que también pueden usar la precompilación de evaluación de puntos por un costo menor.
Precompilación de verificación de blobs
Demostrar que el hash versionado es válido para el blob correspondiente
El resumen optimista necesita acceso a los datos completos cuando se envía a prueba de fraude, por lo que es racional verificar la validez del hash versionado y luego la verificación a prueba de fraude.
3. Danksharding: un paso crucial hacia la fragmentación total
Escalada
Gracias al nuevo diseño de tipo de transacción de proto-danksharding, que introduce un blob de datos, cada bloque ahora tiene 1 MB de caché adicional. Este número aumentará de 16 a 32 veces después de la implementación del danksharding.
Disponibilidad de datos: almacenamiento y verificación de datos de alto rendimiento
En comparación con el proto-danksharding, donde se requiere que los nodos almacenen el contenido completo de los datos históricos, el danksharding permite que los nodos solo almacenen datos después del muestreo.
EL
Aprovechando la tecnología de codificación de borrado, la propuesta danksharding facilita (cada nodo solo necesita descargar partes de datos) que los nodos descubran la pérdida de datos.
Seguridad: Casi lo mismo
Dado que ya no se requieren nodos para almacenar el contenido completo de los datos históricos, la seguridad no está respaldada por un solo nodo, sino que depende de múltiples nodos que almacenan partes de los datos y pueden componerse y recuperar los datos completos.
Aunque un esquema de dependencia de un solo punto es más seguro que una dependencia de múltiples puntos, la cantidad de nodos en la red Ethereum es mucho más que suficiente, lo que está calificado para lograr el objetivo de garantizar la disponibilidad de datos.

Nuevo desafío: mayores exigencias para los constructores de bloques
Si bien los validadores solo descargan y almacenan partes de los datos completos, el creador de bloques aún necesita cargar el contenido completo de los datos, que es el blob que contiene todos los datos de las transacciones.
Según el diagrama de las diapositivas de Dankrad, podemos ver cómo PBS (separación proponente/constructor), que está diseñado originalmente para anti-MEV, ayuda a reducir el requisito de ancho de banda durante la construcción de bloques.
4. Otro esquema de fragmentación: fragmentación de estado dinámico de Shardeum
Shardeum es una cadena de bloques L1 compatible con EVM, que utiliza fragmentación de estado dinámico para mejorar la escalabilidad y la seguridad. Mientras tanto, la red shardeum puede garantizar un mayor nivel de descentralización.

Fragmentación de estado dinámico
Ventajas
Los beneficios más intuitivos de la fragmentación de estado dinámico son el escalado lineal. Cada nodo tiene un rango de direcciones diferente y existe una superposición significativa entre las direcciones cubiertas por los nodos. El algoritmo de fragmentación agrupa los nodos dinámicamente, lo que significa que los nodos recién agregados en la red Shardeum funcionan inmediatamente para aumentar el TPS.
Implementación
La complejidad de implementar la fragmentación de estado dinámico es más difícil que la fragmentación estática. El equipo técnico de Shardeum ha investigado profundamente las tecnologías de fragmentación. Los logros anteriores de I+D realizados por el equipo de Shardeum (anteriormente tecnología Shardus) también suponen contribuciones significativas, que pueden mostrar el escalamiento lineal de la fragmentación de estado dinámico en una etapa temprana de desarrollo.
Resumen
Producto
Haciendo referencia a la idea de divide y vencerás, la fragmentación de estado dinámico de Shardeum divide la carga de trabajo de cálculo y almacenamiento, lo que permite un mayor nivel de paralelización. Por lo tanto, la red puede acomodar más nodos, lo que mejora aún más el rendimiento y el nivel de descentralización.
Equipo
El equipo de Shardeum tiene una sólida experiencia en marketing y capacidad narrativa. También tienen un profundo conocimiento de los detalles tecnológicos, especialmente la fragmentación de estados dinámicos.
Tecnología
El equipo técnico es capaz de diseñar un esquema de fragmentación apropiado y un algoritmo de consenso eficiente (Prueba de participación + Prueba de quórum) basado en su comprensión del escenario, lo que pone la escala y el rendimiento como primera consideración y garantiza la seguridad y el nivel de descentralización. tan lejos como sea posible.
Progreso
Betanet se lanzó el 2 de febrero de 2023.
5. Las perspectivas
Sharding es una solución de escalamiento a largo plazo para Ethereum, tiene un valor enorme y una profunda importancia para toda la red. Es peor prestar mucha atención, ya que la implementación de la fragmentación es un proceso de iteración. Todas las propuestas actuales, incluidas proto-danksharding y danksharding, se pueden actualizar/modificar.
Si bien es importante comprender el método general de implementación de la fragmentación, también vale la pena prestar atención a las propuestas técnicas, como PBS, DAS, mercado de tarifas multidimensional, etc., que surgen durante el proceso. Podría haber muchos proyectos destacados que acompañen a esos planes.
Es importante saber que fragmentación es un término general que describe un conjunto de tecnologías de escalado y que existen diferentes esquemas de aplicación según escenarios específicos. Por ejemplo, el diseño de danksharding podría solo adaptarse a Ethereum y probablemente podría tener un efecto negativo si se aplica en otras L1, ya que la seguridad debe estar garantizada por una gran cantidad de nodos en la red.
Una combinación racional de fragmentación y otras soluciones de escalado puede lograr un efecto multiplicador. La actual propuesta de Danksharding no funcionará por sí sola. En cambio, los rollups y danksharding se complementan entre sí para mejorar la escalabilidad y capacidad de Ethereum.
Referencia
https://notes.ethereum.org/@dankrad/kzg_commitments_in_proofs
https://notes.ethereum.org/@dankrad/new_sharding
https://vitalik.ca/general/2022/03/14/trustedsetup.html
https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly
https://ethresear.ch/t/easy-proof-of-equivalence-between-multiple-polynomial-commitment-schemes-to-the-same-data/8188
https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html
https://eips.ethereum.org/EIPS/eip-4844
https://www.eip4844.com/
https://biquanlibai.notion.site/Data-Availability-caa896aae59d489b98f2448f17b01640
https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434
Acerca de las empresas de previsión
Foresight Ventures se dedica a respaldar la innovación disruptiva de blockchain durante las próximas décadas. Gestionamos múltiples fondos: un fondo de capital de riesgo, un fondo secundario de gestión activa, un FOF de múltiples estrategias y un fondo secundario de mercado privado, con activos gestionados que superan los 400 millones de dólares. Foresight Ventures se adhiere a la creencia de una “mentalidad única, independiente, agresiva y a largo plazo” y brinda un amplio apoyo a las empresas de cartera dentro de un ecosistema en crecimiento. Nuestro equipo está compuesto por veteranos de las principales empresas financieras y tecnológicas como Sequoia Capital, CICC, Google, Bitmain y muchas otras.
Sitio web: https://www.foresightventures.com/
Twitter: https://twitter.com/ForesightVen
Medio: https://foresightventures.medium.com
Subpila: https://foresightventures.substack.com
Discordia: https://discord.com/invite/maEG3hRdE3
Árbol de enlaces: https://linktr.ee/foresightventures

