Introducción

Con el rápido desarrollo de la tecnología blockchain, las blockchains monolíticas se enfrentan a serios desafíos de escalabilidad e interoperabilidad. Las plataformas líderes como Ethereum experimentan un aumento vertiginoso de las tarifas de transacción durante los períodos de alta demanda de los usuarios, lo que dificulta significativamente la adopción de aplicaciones descentralizadas. Para abordar estos problemas, los desarrolladores han estado buscando continuamente soluciones innovadoras, y la aparición de Avail ofrece una nueva dirección para resolver estos problemas. Tras la actualización de Cancún, los costes de transacción en el ecosistema de Ethereum han disminuido significativamente, y la tecnología modular se ha convertido en una narrativa clave en el desarrollo de blockchain. En la primera mitad del año, las cadenas de bloques modulares como Celestia y EigenDA lideraron la tendencia, y el 23 de julio, Avail dio un gran paso adelante en el campo modular al lanzar la red principal de Avail DA.

Como uno de los proyectos principales en blockchain modular, Avail, EigenDA y Celestia sirven a áreas similares. Sin embargo, cada uno tiene sus características únicas en términos de infraestructura, modelos de ejecución y diseños económicos de tokens.

Antecedentes del equipo

Avail se originó en Polygon y se convirtió en una entidad independiente y neutral en 2023. Antes de que la disponibilidad de datos (DA) se convirtiera en un punto focal en la industria, Anurag Arjun había colaborado con otros para desarrollar la cadena Plasma, con el objetivo de resolver los problemas de escalabilidad de Ethereum. Aunque esta cadena ayudó a Polygon a generar $19 mil millones en ingresos, finalmente no se convirtió en la solución de escalado ideal. A lo largo de este proceso, Anurag se dio cuenta de que todas las blockchains eventualmente enfrentarían el mismo desafío: la disponibilidad de datos. Aproximadamente el 80% de los costos de transacción de Rollup están relacionados con DA, lo que lo llevó a concebir la creación de una capa DA rentable que pudiera resolver problemas de escalabilidad para múltiples blockchains.

Esta idea no era única para Anurag; muchos proyectos de blockchain de Capa 1 (L1) también intentaron posicionarse como capas de DA. Ethereum, por ejemplo, está explorando soluciones de DA a través del enfoque de Rollup, mientras que otros proyectos de L1 están innovando en este espacio. Anurag cree que una blockchain L1 específicamente diseñada para DA ofrece ventajas distintas.

Durante su tiempo en Matic, Anurag conoció a Prabal Banerjee, actual cofundador de Avail, quien estaba cursando un doctorado en criptografía y seguridad. Prabal se unió más tarde al equipo como investigador y juntos se dedicaron a construir una capa DA escalable. Con el auge de la tecnología de Prueba de Conocimiento Cero (ZK), los dos integraron diseños de blockchain basados en pruebas de validez. Aprovechando la experiencia de Anurag en la construcción de un protocolo multimillonario en Polygon, avanzaron en el desarrollo de soluciones para abordar los desafíos de disponibilidad de datos.

De Monolítico a Modular

Fuente: Documentación oficial disponible

A medida que la competencia por los recursos computacionales subyacentes se intensifica, la arquitectura monolítica de Ethereum, que maneja la ejecución, la liquidación, el ordenamiento y la disponibilidad de datos (DA) en una sola cadena, ha revelado cada vez más sus limitaciones, especialmente en términos de escalabilidad. Esto ha llevado a la industria a reevaluar el modelo monolítico y explorar nuevas soluciones.

Rollups introdujo una arquitectura modular al mover la ejecución fuera de la cadena, lo que alivió la congestión en las redes de Capa 1 (L1), redujo los costos de transacción para los usuarios y mejoró el rendimiento de las transacciones. Aunque esta arquitectura mejoró significativamente la eficiencia en la cadena, el espacio limitado de bloque de Ethereum sigue siendo un cuello de botella y, a medida que la demanda crece, este problema puede volver a surgir. Actualmente, las aplicaciones descentralizadas (Dapps) dependen de L1 para la transmisión de datos y el acuerdo, mientras que Rollups utilizan L1 para gestionar estos procesos. Si bien Rollups han optimizado el uso del espacio de bloque, el espacio de bloque en sí sigue siendo un recurso escaso.

El análisis de las transacciones L1 de Ethereum Rollups revela que los costos de DA representan el 90% de los gastos de Rollup, lo que lo convierte en la mayor fuente de gasto. La mayor parte de este costo proviene del pago de tarifas L1 para publicar datos de transacción.

Similar to how Rollups offload execution off-chain, la arquitectura de Avail permite que la disponibilidad de datos se traslade a una capa dedicada. Avail proporciona a los desarrolladores una capa de DA flexible, fácil de usar y segura que aborda los desafíos de escalabilidad, gobernanza y descentralización.

Arquitectura modular de Avail

Avail tiene como objetivo acelerar la unificación de Web3 aprovechando su conjunto de tecnología modular, que integra la disponibilidad de datos, la agregación y la seguridad compartida. Los rollups que utilizan Avail para publicar datos de transacciones fuera de la cadena formarán sistemas como Validium (para Optimistic Rollups, esto se llama Optimium). Validiums y Sovereign Rollups pueden depender de Avail para obtener servicios de disponibilidad de datos y ordenación de baja confianza.

Aquí tienes una visión general de cómo Avail apoya Validiums y Sovereign Rollups:

1. Envío de transacciones: Al igual que la mayoría de los Rollups existentes, los datos de las transacciones se agrupan, y la raíz del estado se envía a Avail DA (Disponibilidad de Datos). Cada lote está asociado con un ID de aplicación único para representar el origen del Rollup.
2. Expansión de datos y codificación de borrado: Las transacciones enviadas a Avail DA son sometidas a codificación de borrado. El bloque de datos se divide en n fragmentos originales y se expande a 2n fragmentos. Cualquier conjunto de n fragmentos de la serie de 2n se puede utilizar para reconstruir los datos originales, garantizando redundancia y tolerancia a fallos.
3. Creación de compromisos: Avail DA aplica compromisos polinomiales KZG a los datos redundantes, asegurando su integridad a través de pruebas criptográficas. Estos compromisos garantizan que los datos almacenados son precisos e a prueba de manipulaciones.
4. Propagación de bloques: Los validadores reciben bloques que contienen compromisos KZG y los regeneran para verificar su precisión. La validez del bloque se decide entonces por consenso.
5. Red Ligera del Cliente: Los clientes ligeros utilizan Muestreo de Disponibilidad de Datos (DAS) para verificar la integridad de los datos de bloque. Esto se hace realizando la verificación de apertura del polinomio KZG en los compromisos de las cabeceras de bloque, eliminando la necesidad de reconstruir el compromiso completo de KZG o depender de pruebas de fraude.
6. Verificación de prueba: los clientes ligeros ejecutan la verificación de prueba utilizando pruebas a nivel de celda generadas a partir de la matriz de datos. Esto garantiza que los datos estén disponibles y sean correctos sin requerir que el cliente descargue o verifique el bloque completo.

Dado que Avail emplea pruebas de validez en lugar de pruebas de fraude, los clientes ligeros pueden verificar de inmediato la disponibilidad y corrección de los datos después de la finalización del estado. La red de clientes ligeros también garantiza una alta disponibilidad de datos a través del muestreo de disponibilidad de datos. A medida que se unen más clientes ligeros, la capacidad de muestreo mejora, lo que permite a la red admitir bloques más grandes. Estos clientes ligeros incluso pueden ejecutarse en computadoras portátiles o dispositivos móviles, mejorando la eficiencia de la red.

Fuente: Documentación oficial disponible

Características técnicas

Casos de uso del cliente ligero

Actualmente, muchas aplicaciones blockchain dependen de intermediarios para mantener nodos completos, con los usuarios interactuando indirectamente a través de estos intermediarios en lugar de conectarse directamente a la cadena de bloques. Debido a la falta de disponibilidad de datos garantizada, los clientes ligeros aún no se han convertido en la alternativa ideal a las arquitecturas tradicionales. Avail aborda este problema al permitir que las aplicaciones interactúen directamente con la red blockchain sin depender de intermediarios.

Aunque Avail admite la operación de nodos completos, la mayoría de las aplicaciones no necesitan ejecutar nodos completos, o solo requieren un número mínimo de nodos para funcionar sin problemas. Esto reduce significativamente los requisitos de recursos para participar en la red de blockchain y mejora la descentralización al permitir que más participantes interactúen directamente con la cadena a través de una infraestructura liviana.

Muestreo de Disponibilidad de Datos (DAS)

Similar a los clientes ligeros tradicionales, los clientes ligeros de Avail solo necesitan descargar datos de encabezado de bloque. Además, realizan muestreo aleatorio de porciones de los datos de bloque para verificar su disponibilidad a través del muestreo de disponibilidad de datos (DAS). Al combinar el código de borrado con compromisos polinomiales KZG, los clientes ligeros pueden garantizar casi el 100% de disponibilidad de datos sin depender de pruebas de fraude, y solo requieren un número pequeño y fijo de consultas.

Codificación de borrado y Disponibilidad de datos

El código de borrado funciona dividiendo los datos en fragmentos, restaurando el contenido original incluso si se pierden algunas partes de los datos. En las aplicaciones de blockchain, incluso si los actores malintencionados intentan ocultar partes de los datos, el sistema aún puede recuperarlo de otros fragmentos. Este mecanismo mejora significativamente la confiabilidad del muestreo de disponibilidad de datos y fortalece aún más la resistencia del sistema a la manipulación de datos.

Compromisos de KZG

Los compromisos KZG, desarrollados por Aniket Kate, Gregory M. Zaverucha e Ian Goldberg en 2010, son un método de compromiso polinómico eficiente que ha ganado una amplia adopción en los sistemas de prueba de conocimiento cero en los últimos años. En la arquitectura de Avail, los compromisos de KZG ofrecen las siguientes ventajas:

• Permiten un compromiso conciso a los valores registrados en el encabezado del bloque.
• Los clientes ligeros pueden verificar la disponibilidad de datos a través de estos compromisos.
• Las propiedades de enlace criptográfico de los compromisos KZG hacen que sea casi imposible generar compromisos falsos, reduciendo significativamente la necesidad de pruebas de fraude.

Capa Unificada de Avail

Avail está construyendo la “Capa Unificada”, una pila tecnológica integral que comienza con la capa de disponibilidad de datos (DA) fundamental, la capa unificada Nexus y una capa de seguridad adicional llamada Fusion. Con su capa escalable de disponibilidad de datos, Avail tiene como objetivo apoyar a todo el ecosistema Web3. Utilizando pruebas de validez basadas en compromisos polinomiales KZG, Avail garantiza la disponibilidad de datos en tiempo real y fiable, lo que permite que los rollups crezcan, se interconecten, mantengan la seguridad y se adapten.

Disponibilidad de DA

Fuente: Documentación oficial disponible

Avail DA es una arquitectura subyacente específicamente optimizada para la disponibilidad de datos. Utiliza los algoritmos de consenso GRANDPA y BABE, lo que la diferencia de otras capas de disponibilidad de datos. Este diseño proporciona a Avail DA una alta escalabilidad, garantizando datos confiables a bajo costo a través de Muestreo de Disponibilidad de Datos (DAS) y pruebas de validez.

En su núcleo, Avail DA prioriza y publica transacciones al tiempo que permite a los usuarios verificar la disponibilidad de datos de bloques sin descargar el bloque completo. Una de las características definitorias de Avail DA es su naturaleza agnóstica de datos. Soporta una variedad de entornos de ejecución, incluyendo EVM, WASM y nuevos entornos de ejecución personalizados, proporcionando una base versátil para una amplia gama de aplicaciones de blockchain.

Avail Nexus

Fuente: Documentación oficial disponible

Avail Nexus, el segundo pilar del ecosistema Avail, es un marco sin permisos diseñado para unificar el ecosistema Web3. Conecta blockchains internos y externos, utilizando Avail DA como base confiable y actuando como un centro de validación. Nexus integra un sistema Rollup coordinado por ZK, que consolida la agregación de pruebas, una capa de verificación, un mecanismo de selección de secuenciador y un sistema de subasta de ranuras. Nexus envía periódicamente pruebas agregadas a Ethereum y la capa Avail DA para su verificación, asegurando la confiabilidad de las operaciones entre cadenas.

Avail Fusion

Fuente: Documentación oficial de Avail

Avail Fusion, el tercer pilar, proporciona seguridad adicional para el ecosistema de Avail y el espacio más amplio de Web3. El concepto central detrás de Fusion es que un sistema unificado requiere seguridad unificada a nivel económico. La seguridad de Fusion mejora el consenso de Avail aprovechando activos nativos de ecosistemas establecidos como BTC y ETH, contribuyendo seguridad al consenso de Avail. Este marca el primer intento de usar tokens externos para lograr consenso en todas las blockchains.

Fusion admite dos tipos de apuestas de activos: criptomonedas establecidas y tokens Rollup emergentes. Actualmente, el prototipo de Fusion incluye dos módulos de apuestas: uno que opera en la cadena de bloques Avail y otro para la conversión de activos. Es importante tener en cuenta que el primer prototipo público de Avail Fusion todavía está en desarrollo.

Tipos de nodos en Avail

Aunque la arquitectura de Avail difiere de las blockchains monolíticas tradicionales, aún admite varios tipos de nodos, incluidos nodos completos, clientes ligeros, nodos de archivo y nodos validadores.

• 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. Si bien los nodos completos proporcionan redundancia y resiliencia adicionales al sistema, no son esenciales para la funcionalidad de la red.
• Nodo validador: Los nodos validadores son cruciales para generar bloques, determinar qué transacciones incluir y mantener el orden. Estos nodos ayudan a la red a alcanzar un consenso.
• Cliente Ligero: Los clientes ligeros permiten a los usuarios interactuar con la capa de disponibilidad de datos (DA) de Avail sin ejecutar un nodo completo ni depender de nodos pares remotos. Logran esto realizando un Muestreo de Disponibilidad de Datos (DAS) en cada bloque recién creado, asegurando la disponibilidad de los datos sin descargar el bloque completo.
• Nodo RPC: los nodos RPC proporcionan una API para la interacción remota, actuando como una puerta de enlace para que los desarrolladores y usuarios externos interactúen con la red Avail.

Los clientes ligeros monitorean bloques confirmados en la red de Avail y realizan DAS en unidades de datos pre-designadas dentro de cada nuevo bloque. Tras la verificación exitosa, el sistema calcula la certeza de un subconjunto de unidades de datos dentro del bloque, basado en el nivel de confianza requerido por el usuario.

Modelo Económico

Distribución de Tokens

Con el lanzamiento de la red principal de Avail DA, el equipo entregó tokens AVAIL a los usuarios elegibles, con un suministro total de 10 mil millones de tokens. La distribución es la siguiente:

• 6% para airdrops y asignación pública
• 30% para el desarrollo del ecosistema
• 23.88% para la comunidad e investigación
• 14.12% asignado a inversores
• 20% asignado a los colaboradores principales

Fuente: Documentación oficial disponible

Staking

El token AVAIL tiene múltiples propósitos, incluyendo la gobernanza del ecosistema y el staking líquido. Si bien el marco de gobernanza oficial no se ha detallado por completo, cualquier persona puede apostar AVAIL en la infraestructura de Avail para ganar recompensas de staking.

Para el staking, Avail adopta el mecanismo de consenso Nominated Proof-of-Stake (NPoS), heredado del ecosistema Substrate. El staking juega un papel crítico en este sistema, ya que los usuarios apuestan tokens AVAIL para mejorar la seguridad de la red y obtener recompensas. Cuantos más tokens se apuesten, más segura se vuelve la red, ya que el costo de atacar la red aumenta con la cantidad de tokens apostados.

Las aplicaciones de staking incluyen:

• Avail DA Staking: Los usuarios pueden apostar tokens AVAIL a validadores o pools de nominación para asegurar la red y respaldar diferentes aplicaciones, como juegos Web3 y plataformas DeFi. Los apostadores obtienen recompensas por sus contribuciones.
• Disponibilidad de Nexus Staking: Se requiere que los secuenciadores apuesten tokens AVAIL para participar en la presentación y ordenación de transacciones. Se recompensa a los secuenciadores de alto rendimiento mientras que se penaliza a los que tienen un rendimiento inferior.
• Staking de Avail Fusion: Además de los tokens AVAIL, los usuarios pueden hacer staking de otros criptoactivos importantes como BTC y ETH para mejorar la seguridad de la red, y los stakers obtienen recompensas.

Es importante tener en cuenta que los usuarios que deseen dejar de hacer staking de sus tokens deben someterse a un período de desvinculación de 28 días, durante el cual sus tokens AVAIL no se pueden usar ni transferir.

Desafíos

Riesgo de Competencia Rollup

El crecimiento de Avail podría verse desafiado por grandes rollups de propósito general que han establecido ecosistemas y soluciones de interoperabilidad internas. Con el tiempo, es posible que estos paquetes acumulativos ya no dependan de sistemas de interoperabilidad externos, lo que podría disminuir el valor de Avail Nexus. Sin embargo, el aumento de los paquetes acumulativos específicos de la aplicación y el alto grado de fragmentación al que se enfrentan los usuarios hacen que este escenario sea menos probable.

Competencia en Soluciones de DA

Con múltiples soluciones de disponibilidad de datos (DA), como Celestia y EigenDA, y el próximo EIP-4844 de Ethereum, que introduce "blobs" como opción de publicación de datos, la competencia en la capa DA se está intensificando. La sensibilidad de los Rollups a los costos de publicación de datos y la feroz competencia entre las soluciones DA pueden llevarlos a preferir los sistemas DA establecidos o confiar en la disponibilidad de datos nativos de Ethereum, especialmente una vez que se implementa el danksharding completo. Esto podría afectar potencialmente la adopción de la solución DA de Avail.

Riesgo de seguridad compartido

El modelo de seguridad compartida proporcionado por Avail Fusion se basa en apostar múltiples activos junto con el token AVAIL, lo que puede generar preocupaciones entre los usuarios acerca de la seguridad de estos diversos activos. Algunos desarrolladores pueden preferir obtener seguridad de un único activo bien establecido como ETH o BTC en lugar de depender de múltiples tokens. Además, los desarrolladores pueden inclinarse hacia soluciones DA con una seguridad económica más sólida si Avail Fusion no ofrece suficiente seguridad.

Competencia de los Ecosistemas de Servicios de Valor Agregado

Otros productos de reestaca o seguridad compartida pueden desarrollar ecosistemas de servicios de valor añadido adaptados a los rollups. Por ejemplo, EigenLayer podría ofrecer servicios descentralizados de secuenciación, disponibilidad de datos y finalidad rápida, lo que lo hace más competitivo. Estas características adicionales pueden atraer a los desarrolladores que buscan una solución más completa y segura.