La expansión siempre ha sido uno de los temas que Ethereum no puede evitar. Si Ethereum quiere convertirse en una verdadera "computadora mundial", necesita tener escalabilidad, seguridad y descentralización al mismo tiempo, pero teniendo estas tres condiciones al mismo tiempo. Conocido en la industria como el "Triángulo Imposible de Blockchain", es un gran problema que no se ha resuelto en toda la industria.

Sin embargo, a finales de 2021, el investigador y desarrollador de Ethereum, Dankrad Feist, propuso Danksharding, una nueva solución de fragmentación para Ethereum, que parece haber aportado una solución revolucionaria al "triángulo imposible de blockchain" y puede incluso reescribir todas las reglas del juego de la industria. .

Este informe de investigación intentará explicar claramente en lengua vernácula qué es la nueva solución de fragmentación de Ethereum, Danksharding, y sus entresijos. La razón por la que se escribió este informe de investigación es porque hay muy pocos artículos chinos sobre Danksharding y la mayoría de ellos requieren un alto umbral de conocimiento. Por lo tanto, Spinach intentará desglosar los complejos principios detrás de Danksharding para usted y utilizará una lengua vernácula simple para hacerlo. Los principiantes de Web3 también pueden comprender la nueva solución de fragmentación de Ethereum, Danksharding, y su solución de requisito previo EIP-4844.

Autor: espinacas espinacas

Recuento de palabras: este informe de investigación supera las 10.000 palabras y el tiempo estimado de lectura es de 21 minutos.

Tabla de contenido

  • ¿Por qué Ethereum necesita expandirse?

    • Fondo de expansión de Ethereum

    • ¿Qué es el triángulo imposible de blockchain?

    • ¿Cuáles son las soluciones de escalamiento actuales para Ethereum?

  • La solución de fragmentación inicial de Ethereum, Sharding1.0

    • ¿Cómo funciona el mecanismo de consenso POS de Ethereum?

    • ¿Cómo es la solución de fragmentación inicial Sharding1.0?

    • ¿Cuáles son las desventajas de la solución de fragmentación inicial Sharding1.0?

  • ¿Qué es Danksharding, la nueva solución de fragmentación de Ethereum?

    • Prototipo EIP-4844: Proto-Danksharding: nuevo tipo de transacción Blob

    • Danksharding: solución de expansión completa

      • Muestreo de disponibilidad de datos

      • Codificación de borrado

      • Compromiso polinómico KZG (Compromiso KZG)

      • Separación proponente/constructor

      • Lista de resistencia a la censura (crList)

      • Separación de dos espacios entre proponente y constructor

  • Resumir

  • Referencias

¿Por qué Ethereum necesita expandirse?

Después de que el fundador de Ethereum, Vitalik Buterin, publicara el documento técnico de Ethereum "Contratos inteligentes de próxima generación y plataforma de aplicaciones descentralizadas" en 2014, la cadena de bloques marcó el comienzo de una nueva era. El nacimiento de los contratos inteligentes permite a las personas crear aplicaciones descentralizadas (DApps) en Ethereum y también trae una serie de innovaciones al ecosistema blockchain como NFT, DeFi, GameFi, etc.

Fondo de expansión de Ethereum

A medida que crece el ecosistema de la cadena Ethereum, más y más personas comienzan a usar Ethereum y los problemas de rendimiento de Ethereum comienzan a quedar expuestos. Cuando muchas personas interactúan en Ethereum al mismo tiempo, se produce "congestión" en la cadena de bloques, al igual que el tiempo del semáforo en una carretera es fijo, y la cantidad de vehículos dentro de un cierto número no causará atascos, sino de repente durante el pico. horas Cuando el semáforo se pone verde, muchos automóviles circulan por esta vía. La cantidad de vehículos que salen de la vía cuando el semáforo se pone verde es mucho menor que la cantidad de vehículos nuevos que ingresan a la vía esperando el semáforo. congestión El tiempo que tardan todos los vehículos en pasar por esta carretera se alargará para siempre, y lo mismo ocurre en la cadena de bloques. El tiempo de confirmación de las solicitudes interactivas de todos se alargará.

Pero en la cadena de bloques, no solo se estira el tiempo, sino también las altas tarifas del gas (las tarifas del gas pueden entenderse como tarifas duras pagadas a los mineros, que son responsables de empaquetar y procesar todas las transacciones en la cadena de bloques), porque los mineros darán prioridad a las transacciones con las ofertas más altas, lo que llevará a que todos aumenten la tarifa del gas para luchar por una confirmación de solicitud de interacción más rápida, lo que desencadenará una "Guerra del Gas". Uno de los eventos más famosos fue un proyecto NFT en 2017: CryptoKitties. La popularidad de CryptoKitties elevó la tarifa del gas a cientos de dólares por interacción. Una interacción en Ethereum cuesta decenas o incluso cientos de dólares en tarifas de gas.

La razón principal de las costosas tarifas del gas es que el rendimiento de Ethereum ya no puede satisfacer las necesidades de interacción de los usuarios existentes. En términos de cálculo de rendimiento, Ethereum es diferente de Bitcoin. Bitcoin solo usa un libro de contabilidad simple para procesar la información de transferencia, por lo que TPS es fijo y puede manejar 7 transacciones por segundo, pero es diferente en Ethereum.

Debido a la existencia de contratos inteligentes en Ethereum, el contenido de cada transacción es diferente, por lo que cuántas transacciones (TPS) puede procesar cada bloque depende del volumen de datos de las transacciones contenidas en un bloque y del volumen de datos de cada transacción. El tamaño se determina en función de la demanda en tiempo real. Podemos conocer el mecanismo de rendimiento de Ethereum: (La siguiente información es útil para comprender Danksharding, asegúrese de leerla ~)

  • Ethereum estipula el límite superior de la cantidad de datos de un bloque según la tarifa de gas. Un bloque puede transportar hasta 30 millones de GAS de datos.

  • Ethereum no quiere que la cantidad de datos en cada bloque sea demasiado grande, por lo que cada bloque tiene un objetivo de gas (gas objetivo) de 15 millones de gas.

  • Ethereum tiene un conjunto de estándares de consumo de datos de Gas. Los diferentes tipos de datos consumen Gas diferente. Sin embargo, según la estimación de Spinach, cada bloque tiene un tamaño de aproximadamente 5 kb ~ 160 kb, y el tamaño de bloque promedio es de aproximadamente 60 ~ 70 kb.

  • Una vez que el consumo de gas de un bloque supere el objetivo de gas, que es de 15 millones de gas, la tarifa básica del siguiente bloque será un 12,5% más cara. Si es inferior a la tarifa básica, la tarifa básica se reducirá. Este mecanismo es un mecanismo de ajuste dinámico automatizado que puede seguir aumentando los costos para aliviar la congestión cuando las transacciones alcanzan su punto máximo, al tiempo que reduce los costos para atraer más transacciones cuando las transacciones son lentas.

Luego, al comprender el mecanismo anterior, podemos saber que el TPS de Ethereum está flotando. **Podemos calcular el TPS aproximado viendo la cantidad de transacciones en cada bloque a través del navegador blockchain. Como se puede ver en la figura a continuación, en promedio, un bloque tiene alrededor de 160 transacciones basándose solo en alcanzar el objetivo de gas, con el El más alto puede alcanzar más de 300 transacciones. Según el tiempo de generación de bloques de 12 segundos por bloque, el TPS es de aproximadamente 13 a 30 transacciones, pero según el TPS conocido actualmente de Ethereum, puede alcanzar un máximo de 45 transacciones por segundo.

Origen: Mainnet | Beacon Chain Explorer (fase 0) para Ethereum 2.0 – BeaconScan

Si tomamos como ejemplo el rendimiento del mundialmente famoso sistema comercial VISA, que puede procesar decenas de miles de transacciones por segundo, el rendimiento de Ethereum, que quiere convertirse en una "computadora mundial", y puede procesar hasta 45 transacciones por segundo, es realmente demasiado débil. Por lo tanto, Ethereum necesita urgentemente una expansión para resolver los problemas de rendimiento, lo cual está relacionado con el futuro de Ethereum. Sin embargo, la expansión no es una tarea fácil porque existe un "triángulo imposible" en la industria blockchain.

¿Qué es el triángulo imposible de blockchain?

"Blockchain Impossible Triangle" se refiere al hecho de que una blockchain pública no puede satisfacer tres características al mismo tiempo: descentralización, seguridad y escalabilidad.

  • Descentralización: se refiere al grado de descentralización de los nodos. Cuantos más nodos hay, más dispersos y descentralizados están.

  • Seguridad: se refiere a la seguridad de toda la red blockchain. Cuanto mayor sea el costo del ataque, más seguro será.

  • Escalabilidad: se refiere al rendimiento del procesamiento de transacciones de la cadena de bloques. Cuantas más transacciones se puedan procesar por segundo, más escalable será.

Si observamos la importancia de estos tres puntos, encontraremos que la descentralización y la seguridad tienen el mayor peso. La descentralización es la piedra angular de Ethereum. Es la descentralización la que le da a Ethereum neutralidad, resistencia a la censura, apertura, propiedad de datos y una seguridad casi inquebrantable. . Naturalmente, no es necesario explicar la importancia de la seguridad, pero la visión de Ethereum es lograr escalabilidad bajo la premisa de descentralización y seguridad. La dificultad de implementación se puede imaginar, por eso también se le llama el "Triángulo Imposible de Blockchain".

Fuente de la imagen: Visión Ethereum | ethereum.org

¿Cuáles son las soluciones de escalamiento actuales para Ethereum?

Sabemos que en el "Triángulo Imposible de Blockchain", el requisito previo para que Ethereum logre la expansión debe ser garantizar la descentralización y la seguridad, para garantizar la descentralización y la seguridad, no debe exceder el límite para lograr la expansión. Debido a que los nodos son un papel indispensable en el mantenimiento de toda la red Ethereum, los nodos de alta demanda evitarán que más personas se conviertan en nodos y se centralicen cada vez más. Por supuesto, cuanto más bajo sea el umbral de los nodos, mejor lo permitirán. más personas para participar. Enter hace que Ethereum sea más descentralizado y seguro.

Por lo tanto, actualmente existen dos soluciones de expansión para Ethereum: Layer2 y Sharding. Layer2 es una solución fuera de la cadena para la expansión de la cadena de bloques subyacente (Layer1). El principio es colocar solicitudes en la cadena de bloques en ejecución fuera de la cadena. Hay varias soluciones Layer2. Este informe de investigación solo se centra en una solución Layer2, que es Rollup: el principio de Rollup es empaquetar cientos de transacciones fuera de la cadena como panqueques en una sola transacción y enviarlas a Ethereum para lograr la expansión. , todos pueden compartir el costo de cargar Ethereum a un precio muy bajo y, al mismo tiempo, pueden heredar la seguridad de Ethereum.

Actualmente, el rollup se divide en dos tipos: Optimism Rollup (rollup optimista) y ZK Rollup (rollup a prueba de conocimiento cero). La diferencia entre estos dos rollups es simplemente asumir que todas las transacciones son honestas y confiables. y enviado a Ethereum, habrá un período de tiempo después del envío (período de desafío: actualmente una semana). Cualquiera puede cuestionar e iniciar un desafío para verificar la autenticidad de la transacción, pero si el usuario desea transferir el ETH al OP). Rollup Si cambia a Ethereum, debe esperar hasta el final del período de desafío antes de poder obtener la confirmación final.

ZK Rollup demuestra que todas las transacciones son válidas generando una prueba de conocimiento cero y carga los cambios de estado finales después de que se ejecuten todas las transacciones en Ethereum. ZK Rollup es más prometedor que Optimism Rollup. ZK Rollup no necesita cargar todos los detalles de la transacción comprimidos como Optimism Rollup. Solo necesita cargar una prueba de conocimiento cero y los datos de cambio de estado final, lo que significa que es escalable. más datos que OP Rollup y no necesita esperar un período de desafío de una semana como OP Rollup. Sin embargo, la mayor desventaja de ZK Rollup es que es extremadamente difícil de desarrollar, por lo que en el corto plazo, Optimism Rollup lo hará. Ocupan una gran cantidad de mercado L2.

Además de Layer2, existe otra solución de expansión que es Sharding, el protagonista de este artículo. Sabemos que Layer2 coloca las transacciones en Ethereum en la cadena para su procesamiento. Pero no importa cómo procese los datos Layer2, el rendimiento de Ethereum en sí permanece sin cambios, por lo que el efecto de expansión que Layer2 puede lograr en realidad no es tan significativo.

La fragmentación es para lograr la expansión en el nivel de Capa 1 de Ethereum, pero sabemos que el requisito previo para la expansión en Ethereum es garantizar la descentralización y seguridad de Ethereum, por lo que no podemos aumentar demasiado la carga sobre los nodos.

El esquema de implementación específico de fragmentación siempre ha sido un tema de discusión constante en la comunidad de Ethereum. El último esquema es Danksharding, el tema de este artículo también menciona que Danksharding es el último esquema de fragmentación. También permítanme presentarles brevemente cómo se ve la antigua solución de fragmentación y por qué no se adopta.

La solución de fragmentación inicial de Ethereum, Sharding1.0

Antes de hablar sobre la solución de fragmentación 1.0, primero debemos presentar cómo funciona el mecanismo de consenso POS actual de Ethereum, porque este es el conocimiento previo necesario para comprender la solución de fragmentación 1.0 y Danksharding. breve resumen (solo sepa aproximadamente qué hacer).

¿Cómo funciona el mecanismo de consenso POS de Ethereum? [7]

El mecanismo de consenso es un sistema que permite que todos los nodos que mantienen la red en la cadena de bloques lleguen a un consenso, y su importancia es evidente. Ethereum completó "The Merge" en la fase de actualización de Ethereum 2.0 el 15 de septiembre de 2022, es decir, la red principal de Ethereum de prueba de carga de trabajo de POW y la cadena de balizas del mecanismo de prueba de equidad de POS se fusionaron, y el mecanismo de prueba de equidad de POS se fusionó oficialmente. reemplazó el mecanismo de prueba de carga de trabajo de prisioneros de guerra y se convirtió en el mecanismo de consenso de Ethereum.

Sabemos que en el mecanismo de prueba de carga de trabajo POW, los mineros compiten por el derecho a producir bloques mediante el apilamiento de potencia informática. En el mecanismo de prueba de equidad POS, los mineros compiten por el derecho a producir bloques prometiendo 32 ETH para convertirse en el nodo de verificación. Derechos de bloque de Ethereum (el método de apuesta no se presentará aquí).

Además de los cambios en el mecanismo de consenso, el tiempo de bloque de Ethereum también ha cambiado del tiempo de bloque flotante anterior a un tiempo fijo, que se divide en dos unidades: ranura (Slot) y período (Epoch): la ranura es de 12 segundos y la época es de 6,4 minutos. Una época contiene 32 ranuras. En pocas palabras, un bloque se produce en 12 segundos y 32 bloques se producen en 6,4 minutos como un ciclo (Epoch).

Cuando un minero promete 32 ETH para convertirse en un nodo de verificación, la cadena de balizas utilizará un algoritmo aleatorio para seleccionar el nodo de verificación como el nodo productor de bloques para empaquetar el bloque. Cada bloque seleccionará aleatoriamente un nodo productor de bloques. Al mismo tiempo, en cada ciclo de Época, la cadena de baliza asignará de manera uniforme y aleatoria todos los nodos de verificación a cada bloque a un grupo de "Comités" compuesto por al menos 128 nodos de verificación.

Es decir, a cada bloque se le asignará 1/32 del número de nodos de verificación de todos los nodos. Los "Comités" compuestos por estos nodos de verificación deben verificar y votar los bloques empaquetados por los nodos productores de bloques de cada bloque. Cuando el nodo productor del bloque empaqueta el bloque, más de dos tercios de los nodos de verificación votan para producir el bloque con éxito.

¿Cómo es la solución de fragmentación inicial Sharding1.0? [7]

En el concepto de diseño de la solución de fragmentación inicial Sharding1.0, Ethereum se diseñó desde una cadena principal hasta un máximo de 64 cadenas de fragmentación, y la expansión se logró agregando múltiples cadenas nuevas. En esta solución, cada cadena de fragmentos es responsable de procesar los datos de Ethereum y entregarlos a la cadena de balizas. La cadena de balizas es responsable de la coordinación de todo Ethereum. Los nodos productores de bloques y los comités de cada cadena de fragmentos están controlados por la baliza. cadena. Las cadenas se asignan aleatoriamente.

La cadena de baliza y la cadena de fragmentos están vinculadas mediante enlaces cruzados. El bloque de la cadena de baliza dará un valor hash al bloque de fragmentos del mismo bloque, y luego el bloque de fragmentos llevará este valor hash al siguiente. bloque de baliza, se pueden lograr enlaces cruzados. Si se omite el valor, se pasará al siguiente bloque de baliza.

¿Cuáles son las desventajas de la solución de fragmentación inicial Sharding1.0?

En pocas palabras, la solución de fragmentación 1.0 es dividir Ethereum en muchas cadenas de fragmentos para procesar datos juntos y luego entregar los datos a la cadena de balizas para lograr la expansión. Sin embargo, esta solución tiene muchas desventajas:

**Dificultades de desarrollo:** Es técnicamente muy difícil dividir Ethereum en 64 cadenas de fragmentos mientras se garantiza el funcionamiento normal, y cuanto más complejo sea el sistema, es más probable que se produzcan algunas lagunas impredecibles. problemas si surgen problemas y necesitan ser reparados.

**Problema de sincronización de datos:** Cada ciclo de Época de la cadena de balizas volverá a interrumpir los "comités" responsables de la verificación, por lo que cada redistribución de los nodos de verificación es una sincronización de datos de una red a gran escala, porque si es Cuando Al nodo se le asigna una nueva cadena de fragmentos, necesita sincronizar los datos de esta cadena de fragmentos. Debido a los diferentes anchos de banda de rendimiento de los nodos, es difícil garantizar que la sincronización se complete dentro del tiempo especificado. Sin embargo, si a los nodos se les permite sincronizar directamente los datos de todas las cadenas de fragmentos, aumentará en gran medida la carga sobre los nodos, lo que hará que Ethereum esté cada vez más centralizado. [2]

**Problema de crecimiento del volumen de datos:** Aunque la velocidad de procesamiento de Ethereum ha mejorado mucho, el procesamiento simultáneo de datos por múltiples cadenas de fragmentos también ha provocado un gran aumento en la cantidad de datos almacenados. La tasa de expansión del volumen de datos de Ethereum será. más rápido que antes, los requisitos de rendimiento de almacenamiento para los nodos seguirán aumentando, lo que conducirá a una mayor centralización.

**No se puede resolver el problema MEV:** El valor máximo extraíble (MEV) es la cantidad que se puede extraer de la producción del bloque por encima de la recompensa del bloque estándar y excluyendo transacciones en el bloque y cambiando el orden de las transacciones en el bloque. Costo máximo de combustible. Después de que se inicia una transacción en Ethereum, la transacción se colocará en el mempool (un grupo que almacena las transacciones que se ejecutarán) esperando a que los mineros la empaqueten. Luego, los mineros podrán ver todas las transacciones en el mempool y los derechos de los mineros. son muy limitados, los mineros dominan la inclusión, exclusión y ordenación de transacciones. Si alguien obtiene ganancias sobornando a los mineros para que ajusten el orden de las transacciones en el grupo de transacciones pagando más tarifas de gas, este es un MEV de valor máximo extraíble. [6]

Por ejemplo:

  • Existe un método de MEV llamado "ataque sándwich" o "ataque de clip". Este método de extracción de MEV consiste en monitorear transacciones DEX a gran escala en la cadena. Por ejemplo, alguien quiere comprar altcoins por valor de 1 millón de dólares en Uniswap. Y este método Una transacción aumentará mucho el precio de la altcoin. Cuando la transacción se coloca en el mempool, el robot de monitoreo puede detectar la transacción. En este momento, el robot sobornará al minero que empaquetó el bloque para que transfiera un. La operación de compra de esta altcoin salta frente a esta persona y luego realiza una operación de venta después de la operación de compra de esta persona. Es como un sándwich que intercala a esta persona que realiza transacciones DEX a gran escala. La persona que "atacó" obtuvo la altcoin debido a las ganancias de la transacción de gran cantidad de esta persona, y la persona que realizó la transacción de gran cantidad causó pérdidas. [6]

La existencia de MEV siempre ha traído algunos impactos negativos a Ethereum, como las pérdidas y la peor experiencia del usuario causadas por "ataques sándwich", la congestión de la red causada por la competencia entre los líderes, las altas tarifas del gas e incluso el problema de centralización de los nodos. con más valor MEV puede continuar ocupando más acciones en la red a través de los ingresos, porque más ingresos = más ETH = más intereses de participación, más el alto costo generado por MEV (la congestión de la red y el alto GAS causado por el front-running harán que los usuarios de Ethereum Continuar perdiendo Incluso si el valor de MEV excede significativamente la recompensa del bloque, provocará la inestabilidad y la seguridad del consenso de todo Ethereum, que la solución de fragmentación 1.0 no puede resolver.

Cuando el investigador y desarrollador de Ethereum, Dankrad Feist, propuso Danksharding, una nueva solución de fragmentación para Ethereum a finales de 2021, la comunidad de Ethereum consideró unánimemente que Danksharding era la mejor solución para lograr la expansión de la fragmentación e incluso podría traer una nueva era a Ethereum. revolución.

Danksharding utiliza un nuevo conjunto de ideas de fragmentación para resolver el problema de expansión de Ethereum, es decir, una solución de fragmentación que gira en torno al Rollup de Capa 2. Esta nueva solución de fragmentación puede garantizar la descentralización sin aumentar significativamente la carga de los nodos. seguridad, y también soluciona el impacto negativo causado por MEV.

Podemos ver en la figura siguiente que los objetivos de "The Surge" y "The Scourge" en las próximas etapas de actualización de Ethereum son: lograr más de 100.000 TPS en Rollup y evitar la centralización provocada por MEV y otros protocolos.

Imagen/Fuente: vitalik.eth Traducción: ethereum.cn

Entonces, ¿cómo resuelve Danksharding el problema de expansión de Ethereum? Comencemos con la solución pre-profesional EIP-4844 de Danksharding: Proto-Danksharding.

Prototipo EIP-4844: Proto-Danksharding: nuevo tipo de transacción Blob

EIP-4844 introduce un nuevo tipo de transacción en Ethereum: Blob Transcation. Este nuevo tipo de transacción Blob puede proporcionar una base de datos complementaria adicional para Ethereum:

  • Un blob tiene un tamaño aproximado de 128 KB.

  • Una transacción puede transportar hasta dos blobs: 256 KB

  • Cada bloque tiene 8 Target Blobs - 1 MB, y puede transportar hasta 16 Blobs - 2 MB (el concepto de Target se menciona en el trasfondo de la expansión)

  • Los datos del blob se almacenan temporalmente y se borrarán después de un período de tiempo (la recomendación actual de la comunidad es 30 días)

En la actualidad, el tamaño promedio de cada bloque en Ethereum es de solo unos 85 KB. El espacio de almacenamiento adicional que Blob aporta a Ethereum es enorme. Debe saber que el tamaño total de datos de todos los libros de contabilidad de Ethereum solo ha sido de aproximadamente 1 TB desde el nacimiento de Ethereum. Los blobs pueden aportar entre 2,5 TB y 5 TB de datos adicionales a Ethereum cada año, lo que representa varias veces la cantidad de datos en todo el libro mayor de Ethereum.

Se puede decir que la transacción Blob introducida por EIP-4844 está hecha a medida para que los datos acumulativos se carguen en Ethereum en forma de Blob. El espacio de datos adicional puede permitir que Rollup obtenga un TPS más alto y costos más bajos, y al mismo tiempo. Con el tiempo, el espacio de bloque originalmente ocupado por Rollup se liberará a más usuarios.

Dado que los datos de Blob se almacenan temporalmente, el aumento repentino en la cantidad de datos no supondrá una carga cada vez mayor para el rendimiento de almacenamiento del nodo. Si solo se almacenan temporalmente los datos de Blob durante un mes, el volumen de datos sincronizados será necesario. para descargar 1 MB ~ 2 MB más de datos, lo que no parece ser una carga para los requisitos de ancho de banda del nodo. Desde la perspectiva del volumen de almacenamiento de datos, los nodos solo necesitan descargar y guardar una cantidad fija de datos de aproximadamente 200 ~ 400 GB (el volumen de datos de un mes), lo que solo aumenta el costo al tiempo que garantiza la descentralización y la seguridad. La carga, el aumento de TPS y la reducción de costos se calculan decenas o incluso cientos de veces. Esta es simplemente una excelente solución para resolver el problema de escalabilidad de Ethereum.

¿Qué pasa si los datos se borran y el usuario quiere acceder a datos anteriores?

En primer lugar, el propósito del protocolo de consenso de Ethereum no es garantizar el almacenamiento permanente de todos los datos históricos. En cambio, el propósito es proporcionar un tablero de anuncios en tiempo real altamente seguro con espacio de almacenamiento a largo plazo para otros protocolos descentralizados. La existencia del tablón de anuncios es para garantizar que los datos publicados en el tablón de anuncios permanezcan el tiempo suficiente. Cualquier usuario o protocolo que desee estos datos tenga tiempo suficiente para capturarlos y guardarlos, por lo que guardarlos es responsabilidad de los datos de Blob. entregado a otras funciones, como partes del proyecto de Capa 2, protocolos de almacenamiento descentralizado, etc. [3]

Danksharding: solución de expansión completa

EIP-4844 ha logrado el primer paso en la expansión de Ethereum en torno a Rollup, pero para Ethereum, el efecto de expansión logrado por EIP-4844 está lejos de ser suficiente. La solución completa de Danksharding amplía aún más la cantidad de datos que Blob puede transportar de 1 a 2 MB por bloque a 16 MB a 32 MB, y propone un nuevo mecanismo de separación entre productores y empaquetadores de bloques (PBS) para resolver los problemas causados ​​por MEV.

Entonces necesitamos saber qué dificultades habrá para seguir ampliando la capacidad basada en EIP-4844:

**La carga del nodo es demasiado grande:** Sabemos que el Blob en EIP-4844 tiene un tamaño de solo 1 ~ 2 MB, lo cual es completamente aceptable para aumentar la carga en el nodo, pero si el volumen de datos del Blob se expande 16 veces a 16 ~ 32 MB, ya sea sincronización o almacenamiento de datos, la carga sobre los nodos será demasiado grande y el grado de descentralización de Ethereum se reducirá.

**Problemas de disponibilidad de datos:** Si el nodo no descarga todos los datos del Blob, enfrentará problemas de disponibilidad de datos porque los datos no están abiertos en la cadena y no son accesibles en cualquier momento. Por ejemplo, el nodo Ethereum tiene dudas sobre un. determinada transacción en Optimism Rollup Challenge, pero Optimism Rollup no entrega estos datos. Si no puede obtener los datos originales, no puede demostrar que esta transacción es problemática. Por lo tanto, para resolver el problema de disponibilidad de datos, debe asegurarse de que. Los datos están abiertos y accesibles en cualquier momento.

Entonces, ¿cómo soluciona Danksharding estos problemas?

Muestreo de disponibilidad de datos

Danksharding propuso una solución (muestreo de disponibilidad de datos) para reducir la carga de los nodos y al mismo tiempo garantizar la disponibilidad de los datos.

La idea del muestreo de disponibilidad de datos (DAS) es cortar los datos del Blob en fragmentos de datos y dejar que los nodos cambien de descargar los datos del Blob a verificar aleatoriamente los fragmentos de datos del Blob, de modo que los fragmentos de datos del Blob estén dispersos. cada nodo de Ethereum, pero los datos completos del Blob se almacenan en todo el libro mayor de Ethereum, siempre que los nodos sean lo suficientemente grandes y estén descentralizados.

Por ejemplo: por ejemplo, los datos de Blob se cortan en 10 fragmentos y hay 100 nodos en toda la red. Cada nodo verificará y descargará aleatoriamente un fragmento de datos y enviará el número de fragmento verificado aleatoriamente al bloque. block es Si todos los fragmentos numerados se pueden reunir, Ethereum establecerá de forma predeterminada que los datos de este Blob están disponibles y los datos originales se pueden restaurar juntando los fragmentos. Sin embargo, también habrá una probabilidad muy baja de que 100 nodos no dibujen un fragmento con un número determinado. En este caso, faltarán datos, lo que reduce la seguridad hasta cierto punto, pero es aceptable en términos de probabilidad.

Danksharding utiliza dos tecnologías para implementar el muestreo de disponibilidad de datos (DAS): codificación de borrado y compromiso polinomial KZG (compromiso KZG)

Codificación de borrado

Erasure Coding es una tecnología de codificación tolerante a fallas. El uso de codificación de borrado para cortar datos puede permitir que todos los nodos de Ethereum restauren los datos originales cuando solo tienen más del 50% de los fragmentos de datos, lo que reduce en gran medida el principio de implementación específico de los datos. La probabilidad de fallar es más complicada. Aquí hay una fórmula matemática para dar un ejemplo y explicar aproximadamente el principio: [2]

  • Primero construya una función f(x) = ax + b, y tome cualesquiera 4 valores de x

  • Supongamos que m = f(0) = b, n = f(1) = a + b, podemos obtener a = n – b, b = m

  • Supongamos que p = f(2), q = f(3), podemos obtener p = 2a + b = 2n – m, q = 3a + b = 3n – 2m

  • Luego, los cuatro fragmentos m, n, p, q están dispersos entre los nodos de toda la red.

  • Según la fórmula matemática, sólo necesitamos encontrar dos de los fragmentos para descubrir cuáles son los otros dos fragmentos.

  • Si encuentra n y m, puede calcular directamente q=3n-2m y p=2n-m

  • Si encuentra q y p, puede combinar (2p=4n-2m)-(q=3n-2m) para obtener 2p-q=n y luego puede calcular directamente m

En pocas palabras, la codificación de borrado utiliza principios matemáticos para dividir los datos del Blob en muchos fragmentos de datos. Los nodos de Ethereum no necesitan recopilar todos los fragmentos de datos, solo necesitan recopilar más del 50% de los fragmentos para restaurar los datos originales del Blob. De esta manera, se reduce en gran medida la probabilidad de una recopilación de fragmentos insuficiente y se puede ignorar su probabilidad.

Compromiso polinómico KZG (Compromiso KZG)

El Compromiso Polinómico KZG (Compromiso KZG) es una tecnología criptográfica que se utiliza para resolver el problema de integridad de los datos de la codificación de borrado. Dado que el nodo solo verifica aleatoriamente los fragmentos de datos cortados por el código de borrado, el nodo no sabe si los fragmentos de datos realmente provienen de los datos originales del Blob, por lo que el rol responsable de la codificación debe generar un compromiso polinómico KZG para probar esto. borrado. Los fragmentos de datos del código son de hecho parte de los datos originales. La función de KZG es algo similar al árbol de Merkle pero la forma es diferente. Todas las pruebas de KZG están en el mismo polinomio.

Danksharding implementa el muestreo de disponibilidad de datos (DAS) mediante codificación de borrado y compromiso polinómico KZG, lo que reduce en gran medida la carga sobre los nodos cuando la cantidad de datos adicionales transportados por Blobs se expande a 16 MB ~ 32 MB. Actualmente, la comunidad Ethereum también ha propuesto un método llamado. El esquema 2D KZG corta aún más fragmentos de datos para reducir el ancho de banda y los requisitos computacionales, pero el algoritmo final utilizado aún está siendo objeto de acalorados debates en la comunidad, incluido el diseño de DAS, que también se optimiza y mejora constantemente.

Para Ethereum, el muestreo de disponibilidad de datos (DAS) resuelve el problema de ampliar el tamaño de los datos de Blob de 16 MB a 32 MB al tiempo que reduce la carga sobre los nodos, pero parece haber un problema: ¿quién codificará los datos originales?

Si desea codificar los datos originales de Blob, la premisa es que el nodo de codificación debe tener datos originales completos. Para lograr esto, habrá requisitos más altos para el nodo. Bueno, Spinach mencionó antes que Danksharding propuso un nuevo mecanismo ** Separación de productores y empaquetadores de bloques (PBS) ** para resolver los problemas causados ​​por MEV. De hecho, esta solución no solo resuelve el problema de MEV, sino que también resuelve el problema de codificación. asuntos.

Separación proponente/constructor

En primer lugar, sabemos que el muestreo de disponibilidad de datos (DAS) reduce la carga de los nodos para verificar Blobs y logra una verificación descentralizada y de baja configuración. Sin embargo, para crear este bloque, es necesario tener datos de Blob completos y codificarlos, lo que mejora. Hay muchos requisitos para los nodos completos de Ethereum. La separación entre proponente y paquete (PBS) propone dividir los nodos en dos roles: constructor y proponente. Los nodos con alto rendimiento pueden convertirse en constructores, y los nodos con bajo rendimiento se convierten en proponentes.

Actualmente, existen dos tipos de nodos en Ethereum: nodos completos y nodos ligeros. Los nodos completos necesitan sincronizar todos los datos en Ethereum, como las listas de transacciones y los cuerpos de los bloques. Los nodos completos desempeñan las dos funciones de empaquetado y verificación de bloques. Dado que el nodo completo puede ver toda la información del bloque, el nodo completo puede reordenar, agregar o eliminar las transacciones en el bloque para obtener el valor MEV. Los nodos ligeros no necesitan sincronizar todos los datos, solo necesitan sincronizar el encabezado del bloque para verificar el bloque. [1]

Después de implementar la separación entre proponente y empaquetador (PBS):

  • Los nodos con una configuración de alto rendimiento pueden convertirse en constructores. Los constructores solo necesitan ser responsables de descargar datos de Blob, codificar y crear bloques, y luego transmitirlos a otros nodos para realizar comprobaciones puntuales, porque la cantidad de datos sincronizados y los requisitos de ancho de banda son. alto, estará relativamente centralizado.

  • Los nodos con una configuración de rendimiento más baja pueden convertirse en proponentes. Los proponentes solo necesitan verificar la validez de los datos y crear y transmitir encabezados de bloque. Sin embargo, para los proponentes, el volumen de datos de sincronización y los requisitos de ancho de banda son menores, por lo que estarán descentralizados.

PBS realiza la división del trabajo entre los nodos al separar las funciones de empaquetado y verificación. Los nodos con configuración de alto rendimiento son responsables de descargar todos los datos para su codificación y distribución, y los nodos con configuración de bajo rendimiento son responsables de las verificaciones y verificaciones puntuales. ¿El problema del MEV está resuelto?

Lista de resistencia a la censura (crList)

Dado que PBS separa el trabajo de empaquetado y verificación, el empaquetador (Constructor) en realidad tiene una mayor capacidad para revisar transacciones. El empaquetador puede ignorar deliberadamente ciertas transacciones y ordenar e insertar las transacciones que desea insertar a voluntad. Vaya a obtener MEV. -La lista resistente (crList) resuelve estos problemas.

Mecanismo de lista resistente a la censura (crList): [1]

  • Antes de que el Constructor empaquete la transacción en bloque, el Proponente primero publicará una lista resistente a la censura (crList). Esta crList contiene todas las transacciones en el mempool.

  • El empaquetador (Constructor) solo puede elegir empaquetar y ordenar las transacciones en crList, lo que significa que el empaquetador no puede insertar su propia transacción privada para obtener MEV, ni puede rechazar deliberadamente una transacción (a menos que el límite de Gas esté lleno).

  • Después del empaquetado, el Constructor transmite la versión final del Hash de la lista de transacciones al Proponente. El Proponente selecciona una de las listas de transacciones para generar un Encabezado de bloque y la transmite.

  • Cuando el nodo sincroniza datos, obtendrá el encabezado del bloque del proponente (Proposer) y luego obtendrá el cuerpo del bloque del empaquetador (Builder) para garantizar que el cuerpo del bloque sea la versión final seleccionada.

El impacto negativo de MEV como el "ataque sándwich" se resuelve mediante la lista anticensura (crList). Los nodos ya no pueden obtener MEV similares insertando transacciones privadas.

El plan de implementación específico de Ethereum para PBS aún está en discusión. El posible plan de implementación inicial actual es PBS de doble ranura.

Separación de dos espacios entre proponente y constructor

PBS de doble ranura utiliza un modelo de oferta para determinar los bloques:[2]

  1. Después de obtener crList, el constructor crea el encabezado del bloque de la lista de transacciones y puja.

  2. El proponente selecciona el encabezado del bloque y el constructor que tiene éxito en la oferta final, y el proponente recibe la tarifa de la oferta ganadora incondicionalmente (independientemente de si se genera un bloque válido o no).

  3. El Comité de Verificación (Comités) confirma el encabezado del bloque ganador

  4. El Constructor da a conocer el bloque ganador Body

  5. El Comité de Verificación (Comités) confirma el Cuerpo del bloque ganador y realiza una votación de verificación (si se aprueba, se producirá el bloque. Si el empaquetador deliberadamente no entrega el Cuerpo del bloque, se considerará que el bloque no existe).

Aunque el constructor todavía puede obtener MEV ajustando la secuencia de la transacción, el mecanismo de oferta del PBS de doble ranura provoca una "involución" entre estos empaquetadores. Cuando todos tengan que ofertar para competir por bloques, las ganancias obtenidas por los empaquetadores centralizados a través de MEV se exprimirán continuamente y las ganancias finales se distribuirán a los proponentes descentralizados (Proponentes). Esto resuelve el problema. Resuelve el problema de los empaquetadores centralizados. centralizándose cada vez más con la adquisición de MEV.

Sin embargo, el PBS de doble ranura tiene un defecto de diseño: vemos que el nombre de este diseño tiene "Dos ranuras", lo que significa que hay dos ranuras, lo que significa que en este esquema, el tiempo efectivo de generación de bloques es Ha sido ampliado a 24 segundos (un espacio = 12 segundos), y la comunidad Ethereum ha estado discutiendo activamente cómo resolver este problema.

Resumir

Danksharding proporciona una solución transformadora para que Ethereum resuelva el "triángulo imposible de blockchain" de lograr escalabilidad y al mismo tiempo garantizar la descentralización y seguridad de Ethereum:

  • A través de la solución frontal EIP-4844: Proto-Danksharding, se introduce un nuevo tipo de transacción Blob. El volumen de datos adicional de 1 MB a 2 MB que transporta Blob puede ayudar a Ethereum a lograr un TPS más alto y costos más bajos en Rollup.

  • El muestreo de disponibilidad de datos (DAS) se implementa mediante codificación de borrado y compromiso polinómico KZG, de modo que los nodos solo necesitan verificar aleatoriamente algunos fragmentos de datos para verificar la disponibilidad de los datos y reducir la carga sobre los nodos.

  • Al implementar el muestreo de disponibilidad de datos (DAS), el volumen de datos adicional del Blob se expande a 16 MB ~ 32 MB, llevando el efecto de expansión a un nivel superior.

  • A través de la separación entre proponente y empaquetador (PBS), el trabajo de verificación y empaquetado de bloques se separa en dos roles de nodo, logrando la descentralización de los nodos de empaquetado y la descentralización de los nodos de verificación.

  • El impacto negativo causado por MEV se reduce en gran medida mediante la lista anticensura (crList) y el PBS de doble ranura. El empaquetador no puede insertar transacciones privadas ni censurar una determinada transacción.

Al menos, la solución front-end EIP-4844 de Danksharding se implementará oficialmente en la actualización de Cancún después de la actualización de Ethereum Shanghai. El beneficio más directo después de la implementación de la solución EIP-4844 es el Rollup y Rollup en la capa 2. ecología. Un TPS más alto y un costo más bajo son muy adecuados para aplicaciones de alta frecuencia en la cadena. También podríamos imaginar que pueden nacer algunas "aplicaciones asesinas". La generación de bloques centralizada + verificación descentralizada + resistencia a la censura lograda por Danksharding traerá una nueva ronda de narrativa de cadena pública a Ethereum. Además de la Capa 2, la cadena de bloques modular y Ethereum después de Danksharding chocarán para crear ¿Qué tipo de reacción química?

Spinach cree que la implementación de Danksharding reescribirá todas las reglas del juego y Ethereum llevará a la industria blockchain a una nueva era.

Referencias

[1] Disponibilidad de datos, expansión del almacenamiento de blockchain

[2] Comprender el nuevo plan de actualización de Ethereum en un artículo Danksharding

[3] Preguntas frecuentes sobre Proto-Danksharding – HackMD

[4] ¿Qué es exactamente "Danksharding" en la divulgación científica de V Dios?

[5] Recomendado por V God 丨 Para tener una comprensión profunda de la hoja de ruta de fragmentación de Ethereum, este informe es suficiente

[6] Artículo de Buidler DAO: ¿Cómo rescatar NFT de los piratas informáticos después de que les roban la billetera?

[7] ¿La historia se repite? Una explicación detallada de Ethereum 2.0 y los hard forks