En la cadena de bloques modular, la capa de ejecución y la capa de consenso ya son el mercado del océano rojo, y aún queda por descubrir el valor de la capa de disponibilidad de datos.
Título original: “Resumen semanal de IOSG | Desmantelamiento de la capa de disponibilidad de datos: Los ladrillos de Lego olvidados de un futuro modular #136”
Escrito por Jiawei, IOSG Ventures
tl; dr
Para la disponibilidad de datos de los clientes ligeros, hay pocas objeciones al uso de códigos de borrado para resolver este problema, la diferencia radica en cómo garantizar que los códigos de borrado estén codificados correctamente. Las promesas KZG se usan en Polygon Avail y Danksharding, mientras que las pruebas de fraude se usan en Celestia.
Para la disponibilidad de datos de Rollup, si DAC se entiende como una cadena de consorcio, entonces lo que hacen Polygon Avail y Celestia es hacer que la capa de disponibilidad de datos sea más descentralizada, lo que equivale a proporcionar una cadena pública “específica de DA” para mejorar el nivel de confianza. .
En los próximos 3 a 5 años, la arquitectura de la cadena de bloques inevitablemente evolucionará de monolítica a modular, y cada capa mostrará un estado de acoplamiento bajo. En el futuro, los proveedores de muchos componentes modulares como Rollup-as-a-Service (RaaS) y Data Availability-as-a-Service (DAaaS) pueden darse cuenta de la componibilidad de la arquitectura blockchain. La cadena de bloques modular es una de las narrativas importantes que sustentan el próximo ciclo.
En la cadena de bloques modular, la capa ejecutiva ha sido “cuatro partes del mundo”, y hay pocos rezagados; la capa de consenso está compitiendo en los Llanos Centrales, y están surgiendo Aptos y Sui. Aunque el patrón de competencia de la cadena pública ha aún no ha sido resuelta, su narrativa es vino viejo en botella nueva. , es difícil encontrar oportunidades de inversión razonables. Queda por descubrir el valor de la capa de disponibilidad de datos.
Cadena de bloques modular Cadena de bloques modular
Antes de hablar sobre la disponibilidad de datos, tomemos un momento para revisar brevemente las cadenas de bloques modulares.
Crédito de la imagen: IOSG Ventures, adaptado de Peter Watts
No existe una definición estricta de la estratificación de blockchains modulares.Algunos métodos de estratificación parten de Ethereum, mientras que otros tienden a generalizarse, según el contexto en el que se lleve a cabo la discusión.
Capa de ejecución: dos cosas suceden en la capa de ejecución. Para una sola transacción, la transacción se ejecuta y el estado cambia; para transacciones en el mismo lote, se calcula la raíz del estado del lote. Parte de la capa de ejecución actual de Ethereum está asignada a Rollup, conocida como StarkNet, zkSync, Arbitrum y Optimism.
Capa de liquidación: Puede entenderse como el proceso de verificación de la validez del estado raíz (zkRollup) o prueba de fraude (Optimistic Rollup) por parte del contrato de Rollup en la cadena principal.
Capa de consenso: Ya sea que se utilice PoW, PoS u otros algoritmos de consenso, en resumen, la capa de consenso es llegar a un consenso sobre algo en un sistema distribuido, es decir, llegar a un consenso sobre la validez de las transiciones de estado. En el contexto de la modularidad, los significados de la capa de liquidación y la capa de consenso son algo similares, por lo que algunos investigadores unifican la capa de liquidación y la capa de consenso.
Capa de estado histórico: propuesta por Polynya (solo para Ethereum). Porque después de la introducción de Proto-Danksharding, Ethereum solo mantiene la disponibilidad instantánea de datos durante un cierto período de tiempo y luego realiza operaciones de poda, dejando este trabajo a otros. Por ejemplo, Portal Network u otros terceros que almacenan estos datos pueden clasificarse en esta capa.
Capa de disponibilidad de datos: ¿Qué tiene de malo la disponibilidad de datos? ¿Cuáles son las soluciones correspondientes? Este es el tema en el que se centrará este artículo, y no lo resumiré aquí.
Crédito de la imagen: IOSG Ventures
En 2018 y 2019, la disponibilidad de datos se encontraba más en el contexto de los nodos de clientes ligeros y, en la perspectiva posterior del resumen, la disponibilidad de datos tiene otro significado. Este artículo explicará la disponibilidad de datos desde dos contextos diferentes de “nodo” y “resumen”.
DA en nodos
Crédito de la imagen: https://medium.com/metamask/metamask-labs-presents-mustekala-the-light-client-that-seeds-data-full-nodes-vs-light-clients-3bc785307ef5
Primero veamos los conceptos de nodos completos y clientes ligeros.
Dado que los nodos completos descargan y verifican cada transacción en cada bloque, no se requieren suposiciones honestas para garantizar que el estado se ejecute correctamente, con buenas garantías de seguridad. Sin embargo, ejecutar un nodo completo requiere requisitos de recursos de almacenamiento, poder de cómputo y ancho de banda. Excepto para los mineros, los usuarios o aplicaciones comunes no tienen ningún incentivo para ejecutar un nodo completo. Además, si un nodo solo necesita verificar cierta información en la cadena, obviamente no es necesario ejecutar un nodo completo.
Esto es lo que están haciendo los clientes ligeros. En el artículo de IOSG “Ecología de cadenas múltiples: nuestra fase actual y panorama futuro”, presentamos brevemente a los clientes ligeros. Los clientes ligeros son un término diferente de los nodos completos. A menudo, no interactúan directamente con la cadena, sino que dependen de los nodos completos vecinos como intermediarios para solicitar información de los nodos completos, como descargar encabezados de bloque o verificar saldos de cuentas.
El cliente ligero como nodo puede sincronizar rápidamente toda la cadena porque solo descarga y verifica el encabezado del bloque; mientras que en el modelo de puente entre cadenas, el cliente ligero actúa como un contrato inteligente: el cliente ligero de la cadena de destino solo necesita verificar Si los tokens de la cadena de origen están bloqueados sin verificar todas las transacciones de la cadena de origen.
¿Cuál es el problema?
Hay un problema implícito con esto: dado que los clientes ligeros solo descargan encabezados de bloque de nodos completos, en lugar de descargar y validar cada transacción por sí mismos, un nodo completo malicioso (productor de bloques) puede construir un bloque que contenga transacciones no válidas y enviarlo a clientes ligeros. para engañarlos.
Es fácil pensar en usar “prueba de fraude” para resolver este problema: es decir, solo se requiere un nodo completo honesto para monitorear la validez del bloque y, después de encontrar un bloque no válido, construir una prueba de fraude y enviarla al cliente ligero para recordarles. O, después de recibir el bloqueo, el cliente ligero pregunta activamente a toda la red si hay un certificado de fraude.Si no se recibe después de un período de tiempo, el bloqueo puede ser predeterminado para que sea válido. De esta forma, los clientes ligeros pueden lograr casi el mismo nivel de seguridad que los nodos completos (pero aun así confiar en suposiciones de honestidad).
Sin embargo, en la discusión anterior, en realidad asumimos que los productores de bloques siempre publicarán todos los datos de los bloques, que también es la premisa básica para generar pruebas de fraude. Sin embargo, los productores de bloques maliciosos pueden ocultar algunos de los datos al publicar bloques. En este punto, los nodos completos pueden descargar el bloque y verificar que no es válido, pero las características de los clientes ligeros les impiden hacerlo. Y debido a la falta de datos, los nodos completos tampoco pueden generar pruebas de fraude para advertir a los clientes ligeros.
Otra situación es que, posiblemente debido a razones de red, parte de los datos no se cargarán hasta más tarde, y ni siquiera podemos juzgar si la pérdida de datos en este momento se debe a condiciones objetivas o a la intención del productor del bloque; luego, la recompensa y el mecanismo de castigo por prueba de fraude tampoco puede tener efecto.
Este es el problema de la disponibilidad de datos en los nodos que vamos a discutir.
Fuente de la imagen: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
En la figura anterior se muestran dos situaciones: primero, un productor de bloques malicioso publica un bloque con datos faltantes, momento en el que un nodo completo honesto emite una advertencia, pero luego el productor publica los datos restantes; los otros dos, productores de bloques honestos, publican bloques completos, pero los nodos completos maliciosos emiten advertencias falsas en este momento. En ambos casos, el bloque de datos que ven todos los demás en la red después de T3 está completo, pero hay personas que hacen el mal en él.
De esta manera, el uso de pruebas de fraude para garantizar la disponibilidad de datos para clientes ligeros es vulnerable.
solución
En septiembre de 2018, Mustafa AI-Bassam (ahora CEO de Celestia) y Vitalik propusieron el uso de códigos de borrado multidimensionales para verificar la disponibilidad de datos en un artículo en coautoría: los clientes ligeros solo necesitan descargar una parte aleatoria de los datos y verificar, para garantizar que todos los bloques de datos estén disponibles y que todos los datos se reconstruyan si es necesario.
Hay pocas objeciones al uso de códigos de borrado para resolver el problema de disponibilidad de datos de clientes ligeros, y los códigos de borrado Reed-Solomon se usan en Polygon Avail, Celestia (y Danksharding de Ethereum).
La diferencia es cómo garantizar que el código de borrado esté codificado correctamente: las promesas KZG se usan en Polygon Avail y Danksharding, mientras que las pruebas de fraude se usan en Celestia. Ambos tienen sus propias ventajas y desventajas, KZG promete no ser resistente a la cuántica, mientras que las pruebas de fraude se basan en ciertos supuestos de honestidad y sincronización.
Además del compromiso de KZG, existen esquemas que usan STARK y FRI que se pueden usar para probar la exactitud de los códigos de borrado.
(Nota: los conceptos de códigos de borrado y compromisos de KZG se mencionan en el artículo de IOSG “Merging Soon: A Detail Explanation of the Latest Technology Route of Ethereum”. Debido a limitaciones de espacio, no se explicará en este artículo).
DA en resumen
La disponibilidad de datos en Rollup es: en zkRollup, es necesario permitir que cualquier persona reconstruya el estado de Layer2 por sí mismo para garantizar la resistencia a la censura; en Optimistic Rollup, es necesario asegurarse de que se publiquen todos los datos de Layer2, lo cual es un requisito previo para construyendo pruebas de fraude. ¿Entonces, dónde está el problema?
Fuente de la imagen: https://forum.celestia.org/t/ethereum-rollup-call-data-pricing-analysis/141
Veamos la estructura de costos de la Capa 2. Además del costo fijo, las variables relacionadas con el número de transacciones por lote son principalmente el costo del gas de la Capa 2 y el costo de disponibilidad de datos en la cadena. El impacto del primero es mínimo; el segundo requiere un pago constante de 16 gas por byte, lo que representa entre el 80 % y el 95 % del costo del Rollup.
La disponibilidad de datos (en cadena) es costosa, ¿qué hacer?
Una es reducir el costo de almacenar datos en la cadena: esto es lo que hace la capa de protocolo. En el artículo de IOSG “Merging is Coming: A Detail Explanation of Ethereum’s Latest Technology Route”, mencionamos que Ethereum está considerando introducir Proto-Danksharding y Danksharding para proporcionar a Rollup “bloques grandes”, es decir, mayor espacio de disponibilidad de datos, y adoptar Erasure Los códigos y KZG prometen resolver el problema de carga de nodos resultante. Pero desde la perspectiva de Rollup, no es realista esperar pasivamente a que Ethereum se adapte.
El segundo es poner los datos fuera de la cadena. La siguiente figura enumera las soluciones actuales de disponibilidad de datos fuera de la cadena. Las soluciones generalizadas incluyen Celestia y Polygon Avail; las soluciones seleccionables por el usuario en Rollup incluyen StarkEx, zkPorter y Arbitrum Nova.
Crédito de la imagen: IOSG Ventures
(Nota: Validium se refiere originalmente al esquema de expansión que combina zkRollup y disponibilidad de datos fuera de la cadena. Por conveniencia, Validium se usa en este artículo para referirse al esquema de disponibilidad de datos fuera de la cadena y participar juntos en la comparación)
A continuación, analizamos estas opciones en detalle.
DA proporcionado por Rollup
En la solución de Validium más simple, un operador de datos centralizado es responsable de garantizar la disponibilidad de los datos y los usuarios deben confiar en que el operador no hará nada malo. El beneficio de esto es el bajo costo, pero prácticamente ninguna garantía de seguridad.
Como resultado, StarkEx propuso además el esquema Validium mantenido por el Consejo de disponibilidad de datos (DAC) en 2020. Los miembros del DAC son personas u organizaciones bien conocidas dentro de la jurisdicción legal, y la suposición de confianza es que no se confabularán ni harán el mal.
Arbitrum propuso AnyTrust este año, y también utilizó un consejo de datos para garantizar la disponibilidad de los datos, y construyó Arbitrum Nova basado en AnyTrust.
zkPorter propone que los Guardianes (poseedores de tokens zkSync) mantengan la disponibilidad de datos. Deben prometer tokens zkSync. Si ocurre una falla en la disponibilidad de datos, los fondos prometidos serán confiscados.
Los tres brindan una opción llamada Volition: los usuarios pueden elegir libremente la disponibilidad de datos dentro o fuera de la cadena según sea necesario, y elegir entre seguridad y costo de acuerdo con escenarios de uso específicos.
Fuente de la imagen: https://blog.polygon.technology/from-rollup-to-validium-with-polygon-avail/
Escenarios generales de DA
El esquema anterior se propone con base en la idea de que, dado que la reputación de los operadores ordinarios no es lo suficientemente alta, se introduce un comité con más autoridad para mejorar la credibilidad.
¿Es un comité pequeño lo suficientemente seguro? La comunidad de Ethereum planteó el problema del ataque de ransomware de Validium hace ya dos años: si se robaban suficientes claves privadas de los miembros del comité para que la disponibilidad de datos fuera de la cadena no estuviera disponible, los usuarios podrían verse amenazados, solo si pagaban suficientes retiros de rescate de Layer2. Con base en la historia del robo del Puente Ronin y el Puente Harmony Horizon, no podemos ignorar la posibilidad.
Dado que el comité de disponibilidad de datos fuera de la cadena no es lo suficientemente seguro, ¿qué sucede si se introduce la cadena de bloques como un tema de confianza para garantizar la disponibilidad de datos fuera de la cadena?
Si el DAC antes mencionado se entiende como una cadena de consorcio, entonces lo que hacen Polygon Avail y Celestia es descentralizar más la capa de disponibilidad de datos, lo que equivale a proporcionar una cadena pública “específica de DA” con una serie de nodos de verificación, distritos Productores de bloques y mecanismos de consenso para aumentar el nivel de confianza.
Además de la mejora de la seguridad, si la capa de disponibilidad de datos en sí misma es una cadena, en realidad no puede limitarse a proporcionar disponibilidad de datos para un Rollup o una cadena, sino como una solución generalizada.
Fuente de la imagen: https://blog.celestia.org/celestiums/
Tomamos la aplicación de Celestia de Quantum Gravity Bridge en Ethereum Rollup como un ejemplo para explicar. El Contrato L2 en la cadena principal de Ethereum verifica la prueba de validez o la prueba de fraude como de costumbre, con la diferencia de que la disponibilidad de datos la proporciona Celestia. No hay contratos inteligentes en la cadena Celestia, no se realizan cálculos sobre los datos, solo se garantiza que los datos estén disponibles.
El Operador L2 publica los datos de la transacción en la cadena principal de Celestia, y el verificador de Celestia firma la Raíz Merkle de la Atestación DA y la envía al Contrato Puente DA en la cadena principal de Ethereum para su verificación y almacenamiento.
De esta manera, Merkle Root of DA Attestation se usa para probar la disponibilidad de todos los datos. El DA Bridge Contract en la cadena principal de Ethereum solo necesita verificar y almacenar este Merkle Root, y la sobrecarga se reduce considerablemente.
(Nota: Otros esquemas de disponibilidad de datos incluyen Adamantium y EigenLayr. Los usuarios en el esquema Adamantium pueden optar por alojar sus propios datos fuera de la cadena y firmar para confirmar que sus datos fuera de la cadena están disponibles después de cada transición de estado; de lo contrario, los fondos se transferirán automáticamente. enviado de vuelta La cadena principal se utiliza para garantizar la seguridad; o los usuarios pueden elegir libremente los proveedores de datos. EigenLayr es una solución académica, que propone Coded Merkle Tree y Oracle de disponibilidad de datos ACeD. No lo discutiremos aquí)
resumen
Fuente de la imagen: IOSG Ventures, adaptado de Celestia Blog
Después de discutir los esquemas anteriores uno por uno, haremos una comparación horizontal desde la perspectiva de la seguridad/descentralización y el costo del gas. Tenga en cuenta que este gráfico representa solo la comprensión personal del autor, como una vaga división aproximada en lugar de una comparación cuantitativa.
Pure Validium en la esquina inferior izquierda tiene la seguridad/descentralización y el costo de gas más bajos.
La parte central es el esquema DAC de StarkEx y Arbitrum Nova, el esquema del conjunto de verificadores Guardian de zkPorter y el esquema generalizado Celestia y Polygon Avail. El autor piensa que usar zkPorter para usar Guardians como conjunto de validadores es un poco más seguro/descentralizado que DAC; mientras que el esquema de cadena de bloques específico de DA es un poco más alto que un conjunto de validadores. Al mismo tiempo, el costo del gas también ha aumentado en consecuencia. Por supuesto, esto es solo una comparación aproximada.
El bloque de la esquina superior derecha es la solución para la disponibilidad de datos en la cadena, con el mayor costo de seguridad/descentralización y gas. Desde el interior del bloque, dado que la disponibilidad de datos de estos tres esquemas la proporciona la cadena principal de Ethereum, tienen el mismo grado de seguridad/descentralización. En comparación con el único Ethereum, el esquema de resumen puro obviamente cuesta menos gasolina, y después de la introducción de Proto-Danksharding y Danksharding, el costo de la disponibilidad de datos se reducirá aún más.
Nota: La mayor parte del contexto de “disponibilidad de datos” discutido en este artículo está bajo Ethereum. Cabe señalar que Celestia y Polygon Avail son soluciones generalizadas, no limitadas a Ethereum en sí.
Finalmente, resumimos las soluciones anteriores en la tabla.
Crédito de la imagen: IOSG Ventures
Pensamientos finales
Después de discutir los problemas de disponibilidad de datos anteriores, encontramos que todas las soluciones son esencialmente compensaciones bajo las restricciones mutuas del trilema, y la diferencia entre las soluciones radica en las compensaciones “de grano fino”.
Desde la perspectiva del usuario, es razonable que el protocolo brinde la opción de disponibilidad de datos dentro y fuera de la cadena. Porque en diferentes escenarios de aplicación o entre diferentes grupos de usuarios, los usuarios también son diferentes en sensibilidad a la seguridad y el costo.
El soporte de la capa de disponibilidad de datos para Ethereum y Rollup se analiza más arriba. En la comunicación entre cadenas, la cadena de retransmisión de Polkadot proporciona garantías de seguridad nativas de disponibilidad de datos para otras cadenas paralelas, mientras que Cosmos IBC se basa en el modelo de cliente ligero, por lo que garantiza que el cliente ligero pueda verificar la disponibilidad de datos de la cadena de origen y de destino. encadenar a importante.
Los beneficios de la modularidad radican en la capacidad de conexión y la flexibilidad, y pueden adaptarse a los protocolos según sea necesario: por ejemplo, para eliminar la carga de disponibilidad de datos de Ethereum mientras se garantiza la seguridad y los niveles de confianza, o para mejorar la comunicación ligera con el cliente en un ecosistema de múltiples cadenas. nivel del modelo, bajando el supuesto de confianza. Sin limitarse a Ethereum, la disponibilidad de datos también puede desempeñar un papel en la ecología de múltiples cadenas e incluso en más escenarios de aplicación en el futuro.
Creemos que en los próximos 3 a 5 años, la arquitectura de la cadena de bloques inevitablemente evolucionará de monolítica a modular, con cada capa mostrando un estado de acoplamiento bajo. En el futuro, los proveedores de muchos componentes modulares como Rollup-as-a-Service (RaaS) y Data Availability-as-a-Service (DAaaS) pueden darse cuenta de la componibilidad de la arquitectura blockchain. La cadena de bloques modular es una de las narrativas importantes que sustentan el próximo ciclo.
Entre ellos, el gigante de valoración de la capa ejecutiva (es decir, Rollup) ya tiene “cuatro puntos”, y hay pocos rezagados, la capa de consenso (es decir, cada Capa1) está compitiendo en los Llanos Centrales. Después de las cadenas públicas como Aptos y Sui comenzaron a despuntar, el patrón de competencia de la cadena pública aunque el polvo no se asienta, pero su narrativa es vino viejo en botellas nuevas, y es difícil encontrar oportunidades de inversión razonables.
Queda por descubrir el valor de la capa de disponibilidad de datos.
Referencias
A pesar de seguir de cerca el meme de la cadena de bloques modular desde los primeros tweets de @epolynya, acabo de entenderlo. @CelestiaOrg y lo que se puede construir con él.
No soy un experto y puede que me equivoque en algunos lugares, pero pensé en compartir mis notas en caso de que sean útiles… pic.twitter.com/Paz7UsTyBf
— Peter | Embalse (@ptrwtts) 1 de abril de 2022
1/ La idea de una “cadena de bloques modular” se está convirtiendo en una narrativa que define la categoría en torno a la escalabilidad y la infraestructura de la cadena de bloques. 🧵👇https://t.co/4qayl99MnR pic.twitter.com/igCLUoPHXy
— Alec (@0xAlec) 7 de julio de 2022
https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
https://vitalik.ca/general/2021/04/07/sharding.html
https://coinmarketcap.com/alexandria/article/what-is-data-availability
https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html
https://vitalik.ca/general/2021/04/07/sharding.html
https://www.parity.io/blog/que-es-un-cliente-ligero/
https://ethereum.org/en/developers/docs/scaling/validium/
https://forum.celestia.org/t/ethereum-rollup-call-data-pricing-analysis/141
https://ethresear.ch/t/adamantium-power-users/9600
https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view
https://blog.polygon.technology/introducing-avail-by-polygon-a-robust-general-purpose-scalable-data-availability-layer-98bc9814c048/
https://blog.polygon.technology/the-data-availability-problem/
https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/
https://blog.celestia.org/celestiums/