Prólogo

Con el rápido desarrollo de la tecnología blockchain, la cadena de bloques individual se enfrenta a graves desafíos de escalabilidad e interoperabilidad. Las plataformas principales como Ethereum experimentan un gran aumento en el blanqueo de capitales cuando hay un aumento en el número de usuarios, lo que afecta gravemente la descentralización de las aplicaciones. Para hacer frente a estos problemas, los desarrolladores continúan buscando soluciones innovadoras y el surgimiento de Avail proporciona una nueva dirección para resolver este problema. Después de la actualización de Cancún, el costo de transacción en el ecosistema de Ethereum ha disminuido significativamente, mientras que la tecnología modular se ha convertido en una narrativa importante para el desarrollo de blockchain. En la primera mitad del año, Celestia y EigenDA lideraron la tendencia de la cadena de bloques modular, y Avail también dio un paso importante en el campo de la modularidad al lanzar Avail DA Mainnet el 23 de julio.

Como proyectos centrales de blockchain modular, Avail, EigenDA y Celestia son similares en términos de servicios, pero tienen características distintivas en cuanto a infraestructura, modelo de ejecución y diseño económico de Token.

Antecedentes del equipo

Avail se originó en Polygon y se convirtió en una entidad neutral por derecho propio en 2023. Antes de que el tema de la disponibilidad de datos (DA) se convirtiera en el foco de la industria, Anurag Arjun co-desarrolló Plasma Chain con la intención de resolver el problema de escalabilidad de Ethereum. Si bien la cadena ayudó a Polygon a lograr $ 19 mil millones en ingresos, no se convirtió en una solución de escalado ideal. En el camino, Anurag se dio cuenta de que todas las cadenas de Bloquear eventualmente enfrentarían el mismo obstáculo: problemas de disponibilidad de datos. Alrededor del 80% del Rollup Costo de la transacción está relacionado con DA, por lo que prevé que la creación de una capa de DA rentable podría resolver el problema de escalar múltiples cadenas de Bloquear.

Esta idea no es exclusiva de Anurag, la mayoría de los proyectos de cadena de bloques L1 también están tratando de convertirse en una capa DA. Ethereum está explorando soluciones DA a través de la ruta de Rollup, y otros proyectos L1 también están innovando en este campo. Anurag cree que una cadena de bloques L1 diseñada específicamente para DA tiene ventajas únicas.

Durante su tiempo en Matic, Anurag conoció al actual cofundador de Avail, Prabal Banerjee, quien en ese momento estaba estudiando para obtener un doctorado en criptografía y seguridad, y luego se unió al equipo como investigador. Ambos se unieron para construir una capa DA escalable. Con el surgimiento de la tecnología de prueba de conocimiento cero (ZK), combinaron el diseño de blockchain de prueba de validez con la experiencia de Anurag en la creación de protocolos a escala de miles de millones en Polygon, lo que impulsó aún más la solución al problema de la disponibilidad de datos.

De cadena única a modularización

Fuente: Documentación oficial de Avail

A medida que la competencia por los recursos de cálculo subyacentes se intensifica, los problemas de ejecución, liquidación, ordenación y disponibilidad de datos en la cadena única de Ethereum comienzan a ser evidentes, lo que limita la escalabilidad. La industria está empezando a reconsiderar la arquitectura de cadena única y buscar nuevas soluciones.

Los rollups, al mover la ejecución a off-chain, introducen una arquitectura modular que alivia efectivamente la congestión de la red L1, libera el Costo de la transacción de los usuarios, y aumenta la capacidad de procesamiento de transacciones. A pesar de que esta arquitectura ha mejorado significativamente la eficiencia on-chain, el limitado espacio Bloquear de Ethereum sigue siendo un cuello de botella que podría volver a surgir con el aumento de la demanda. Actualmente, las Dapps dependen de L1 para la transmisión de datos y Asentamiento, mientras que los rollups utilizan L1 para manejar estos procesos. Aunque los rollups optimizan el uso del espacio Bloquear, este sigue siendo muy limitado.

Al analizar las transacciones L1 de Ethereum Rollups, se descubrió que el costo de DA representa el 90% de los costos, que también es la mayor fuente de gastos de Rollups, y la mayoría de los ingresos se utilizan para pagar los costos de publicación de datos de transacciones L1.

Similar a los rollups, Avail traslada la ejecución fuera de la cadena (off-chain) y su arquitectura permite la disponibilidad de datos en una capa dedicada. Avail proporciona una capa de disponibilidad de datos flexible, fácil de usar y segura para los desarrolladores, abordando los desafíos de escalabilidad, gobernanza y descentralización.

Estructura modular construida por Avail

Avail tiene como objetivo acelerar la unificación de Web3 mediante su pila de tecnología modular que combina la disponibilidad de datos, la agregación y la seguridad compartida. Los Rollup de Validium (llamados Optimium para Optimistic Rollup) que publican datos de transacciones fuera de la cadena utilizando Avail, pueden depender de los servicios de disponibilidad de datos y ordenación de baja confianza proporcionados por Avail. Los Validiums y Sovereign Rollups pueden depender de los servicios de disponibilidad de datos y ordenación de baja confianza proporcionados por Avail.

A continuación se muestra un breve resumen del proceso compatible con Validiums y Sovereign Rollups de Avail:

1. Envío de transacciones: Al igual que la mayoría de los rollup existentes, los datos de llamadas de transacciones se procesan en lotes, la raíz del estado se envía a Avail DA y se utiliza un ID de aplicación único para representar el origen del rollup.
2. Expansión de datos y codificación de borrado: Las transacciones presentadas a Avail DA son procesadas mediante codificación de borrado, donde el bloque se divide en n bloques originales y se expande a 2n bloques, de los cuales se pueden seleccionar cualquier n bloques para reconstruir los datos.
3. Promesa de creación: Avail DA obtendrá datos redundantes y hará una promesa de polinomio KZG para cada Bloquear aplicado. Estas promesas actúan como pruebas de encriptación de integridad de datos para asegurar que los datos almacenados sean precisos e inalterables.
4. La propagación de Bloquear: Los validadores reciben Bloquear con compromisos KZG y vuelven a generar estos compromisos para verificar su precisión y alcanzar un Consenso sobre el Bloquear.
5. La red de cliente ligero: el cliente ligero utiliza la verificación DAS para la integridad de los datos del Encabezado de bloque. Esto se logra mediante la verificación de la apertura del polinomio KZG para cada unidad de muestreo en el Encabezado de bloque, lo que elimina la necesidad de reconstruir compromisos completos de KZG o depender de prueba de fraude.
6. Verificación de prueba: cliente ligero realiza la verificación de prueba ejecutando la verificación de prueba a nivel de celda generada a partir de la matriz de datos.

Debido a que Avail utiliza pruebas de validez en lugar de pruebas de fraude, cliente ligero puede verificar la disponibilidad y la corrección de los datos una vez que se determina su estado final. Además, la red cliente ligero garantiza la alta disponibilidad de los datos mediante el muestreo de la disponibilidad de los datos. A medida que se unen más clientes ligeros, la capacidad de muestreo aumenta y se puede admitir un mayor bloqueo. Incluso los usuarios pueden ejecutar estos clientes ligeros en computadoras portátiles o teléfonos móviles para mejorar aún más la eficiencia de la red.

Fuente: Documentación oficial de Avail

Características técnicas

Aplicaciones de cliente ligero

En la actualidad, muchos escenarios de aplicaciones dependen de intermediarios para mantener nodos completos, y los usuarios interactúan indirectamente con la cadena de bloques a través de estos intermediarios en lugar de acceder directamente. Debido a la falta de garantía de disponibilidad de datos, el cliente ligero aún no es una solución ideal para la arquitectura tradicional. Avail resuelve este problema, permitiendo que más aplicaciones interactúen directamente con la red de cadenas de bloques sin depender de intermediarios. Aunque Avail admite operaciones de nodo completo, la mayoría de las aplicaciones no requieren ejecutar un nodo completo o solo necesitan unos pocos nodos para funcionar sin problemas.

Muestreo de disponibilidad de datos (DAS)

Similar to traditional cliente ligero, Avail's cliente ligero only needs to download Bloquear header data. In addition, they verify its correctness by sampling part of the Bloquear data through random extraction for data availability. Combining erasure coding and KZG polynomial commitment, cliente ligero can ensure the availability of data almost 100% without relying on prueba de fraude, and only needs to perform a small amount of fixed queries.

codificación por borrado与数据可用性

La codificación por borrado permite recuperar el contenido original de otros fragmentos incluso si se pierden algunos datos. En las aplicaciones de bloques, esto significa que el sistema puede recuperar datos de otros fragmentos incluso si un actor malicioso intenta ocultar parte de los datos. Este mecanismo mejora significativamente la fiabilidad de la disponibilidad de los datos y refuerza aún más la capacidad de prevenir la manipulación de datos.

Promesa de KZG

La tecnología KZG fue propuesta por Aniket Kate, Gregory M. Zaverucha e Ian Goldberg en 2010. Es una forma eficiente de comprometerse con polinomios, que se ha utilizado ampliamente en estructuras de prueba de conocimiento cero en los últimos años. En la arquitectura de Avail, el compromiso KZG tiene las siguientes ventajas:

1. Comprometerse con los valores de una manera concisa y registrarlos en el Encabezado de bloque;
2. Permitir la verificación de la disponibilidad de datos del cliente ligero;
3. Su característica de encriptación vinculada hace que sea casi imposible generar promesas falsas, lo que reduce la necesidad de pruebas de fraude.

La capa unificada de Avail

Avail ha estado construyendo una capa unificada para Avail, que es una pila tecnológica unificada que comienza desde la capa de disponibilidad de datos (DA), la capa unificada Nexus y la capa de seguridad adicional Fusion. Avail se extenderá a través de toda la ecología Web3 con la capa de disponibilidad de datos soporte escalable, utilizando prueba de validez con compromiso polinomial KZG para garantizar disponibilidad de datos instantánea y confiable, permitiendo la escalabilidad, conexión, seguridad y adaptabilidad de la agregación.

Disponible DA

Fuente: Documentación oficial de Avail

Avail DA es una infraestructura subyacente diseñada específicamente para optimizar la disponibilidad de datos, que utiliza los algoritmos de Consenso GRANDPA y BABE, a diferencia de otras capas DA. Este diseño dota a Avail DA de una alta escalabilidad, garantizando una protección de datos fiable a bajo costo a través del muestreo de disponibilidad de datos (DAS) y la prueba de validez.

El núcleo de Avail DA es la priorización y publicación de transacciones, al mismo tiempo que permite a los usuarios verificar la disponibilidad de datos de Bloquear sin necesidad de descargar todo el Bloquear. La independencia de datos de Avail DA es una de sus funciones definitorias. Admite varios entornos de ejecución, incluyendo EVM, WASM y runtimes personalizados, proporcionando una base multifuncional para diversas aplicaciones de cadenas de Bloquear.

Avail Nexus

Fuente: Documentación oficial de Avail

Avail Nexus, como el segundo pilar, es un marco sin licencia diseñado para unificar el ecosistema web3. Conecta blockchains internos y externos, aprovechando Avail DA como base de confianza y actuando como centro de validación. Nexus incluye Rollup coordinado por ZK, que integra la agregación de pruebas, la capa de verificación, el mecanismo de selección de ordenadores y el mecanismo de subasta de ranuras. Nexus envía periódicamente pruebas agregadas para su validación en las capas de Ethereum y Avail DA, garantizando la fiabilidad de las operaciones de interacción cross-chain.

Avail Fusion

Fuente: Documentación oficial de Avail

El tercer pilar, Avail Fusion, proporciona seguridad adicional para el ecosistema Avail y todo el web3. Su idea principal es que, a nivel macroeconómico, un sistema unificado requiere seguridad unificada. La seguridad de Fusion, al aprovechar los activos locales de sistemas maduros como BTC, ETH, contribuye a la seguridad de Consenso de Avail. Este mecanismo intenta por primera vez lograr un Consenso a través de Tokens externos en diferentes cadenas Bloquear-on-chain.

Avail Fusion admite dos tipos de activos para stake: Criptomonedas consolidadas y Tokens Rollup emergentes. Actualmente, el prototipo de Fusion incluye dos módulos de stake: uno que se ejecuta en la cadena de bloques de Avail y otro que es un módulo de conversión de activos para stake. Es importante tener en cuenta que el primer prototipo público de Avail Fusion aún está en desarrollo.

Tipo de Nodo de Avail

Aunque la arquitectura de Avail es diferente de la cadena de bloques monolítica tradicional, también admite varios tipos de Nodos, incluidos el Nodo completo, cliente ligero, Nodo de archivo y Nodo de validación.

• Nodo completo: Los nodos completos son responsables de descargar y verificar la corrección de los bloques, pero no participan en el proceso de consenso. Su existencia proporciona redundancia y flexibilidad adicionales al sistema, pero no son componentes necesarios.
• 验证 Nodo：验证 Nodo通过生成 Bloquear、决定交易是否包含并维护交易顺序，帮助网络达成 Consenso。
• cliente ligero：El cliente ligero permite a los usuarios interactuar con la capa de disponibilidad de datos (DA) de Avail sin la necesidad de ejecutar un nodo completo, y sin la necesidad de confiar en un nodo par remoto. Logran esto realizando muestreos de disponibilidad de datos (DAS) en cada bloque recién creado.
• RPC Nodo: RPC Nodo proporciona una API de interacción remota como puerta de enlace entre los desarrolladores y los usuarios externos de la red Avail.

El cliente ligero escucha los bloques confirmados en la red Avail y realiza el muestreo de disponibilidad de datos (DAS) en las unidades de datos prefabricadas de nuevos bloques. Después de la verificación exitosa, el sistema calcula la determinación de una cierta cantidad de unidades de datos en el bloque según el nivel de confianza requerido por el usuario.

Modelo económico

Asignación de Token

Con el lanzamiento de AvailDA Mainnet, el equipo realizó un Airdrop de AVAIL Token a usuarios elegibles, con un suministro total de 10 mil millones. De este total, el 6% se destinó a Airdrop y distribución pública, el 30% para el desarrollo del ecosistema, el 23.88% para la comunidad y la investigación, el 14.12% se asignó a los inversores, y el 20% se asignó a los contribuyentes principales.

Fuente: Documentación oficial de Avail

stake

El uso de AVAIL Token abarca la gobernanza e la liquidez dentro del ecosistema de Avail. Aunque el plan de gobernanza aún no ha sido detallado por el equipo oficial, cualquier persona puede hacer stake de AVAIL en toda la infraestructura de Avail para obtener recompensas de stake.

En cuanto a la participación, Avail utiliza el mecanismo de consenso de Prueba de participación nominada (NPoS) heredado del ecosistema Substrate. La participación juega un papel clave en NPoS. Al participar con el token AVAIL, los usuarios ayudan a mejorar la seguridad de la red y reciben recompensas correspondientes. Cuanto más token se participe, mayor será la seguridad de la red, ya que el costo de atacar la red también aumentará.

Las aplicaciones de stake son las siguientes:

• Avail DA stake: Los usuarios pueden hacer stake de los tokens AVAIL con validadores o en un pool de nominaciones para garantizar la seguridad de la red y respaldar diferentes casos de uso, como juegos Web3 y plataformas de Finanzas descentralizadas. Los participantes en el stake pueden recibir recompensas.
• Participar en la presentación y clasificación de transacciones de Nexus requiere apostar AVAIL Token. Los clasificadores que tengan un buen desempeño recibirán recompensas, mientras que aquellos que tengan un desempeño deficiente serán penalizados.
• Avail Fusion stake: Además del token AVAIL, también se puede realizar stake en otros activos de encriptación principales como BTC y ETH para aumentar aún más la seguridad de la red. Los stakeholders pueden recibir beneficios correspondientes.

Es importante tener en cuenta que si un usuario desea retirar su stake, debe completar el proceso de desvinculación de 28 días, durante este período, el token AVAIL no se puede utilizar ni transferir.

Desafíos a enfrentar

Riesgo de competencia de Rollup

El desarrollo de Avail puede verse afectado por rollups generales a gran escala que tienen ecosistemas maduros y soluciones de interoperabilidad interna, lo que podría debilitar el valor de Avail Nexus al no depender más de sistemas de interoperabilidad externos. Sin embargo, el aumento significativo de rollups específicos de aplicaciones y el alto grado de fragmentación al que se enfrentan los usuarios hacen que esta situación sea poco probable.

La competencia de la solución DA

Con el lanzamiento de varias soluciones de DA en el mercado, como Celestia y EigenDA, Ethereum también ha introducido blobs como opción de publicación de datos a través de EIP-4844. La intensa competencia entre las capas de DA y la sensibilidad de rollup hacia los costos de publicación de datos pueden llevar a soltar, lo que hace que rollup tienda a elegir soluciones de DA verificadas o depender de Ethereum para la publicación de datos una vez que se implemente completamente danksharding en Ethereum.

Compartir riesgos de seguridad

El modo de seguridad compartida proporcionado por Avail Fusion depende de múltiples tokens y del stake de AVAIL Token, lo que puede plantear preocupaciones de seguridad de varios activos por parte de los usuarios. Algunos desarrolladores pueden preferir obtener seguridad de un solo activo, como ETH o BTC, en lugar de depender de varios tokens. Además, si Avail Fusion no proporciona suficiente seguridad, los desarrolladores podrían recurrir a soluciones de DA con una seguridad económica más sólida.

Competencia en el ecosistema de servicios de valor añadido

Otras opciones de stake o productos de seguridad compartida pueden tener servicios de valor añadido especializados para rollup. Por ejemplo, EigenLayer puede ofrecer servicios de ordenación descentralizada, disponibilidad de datos y finalidad rápida, lo que mejorará su competitividad.