Autor: 100y.eth Fuente: mirror Traducción: Shanooba, Golden Finance

El 23 de julio de 2024, después de una larga espera, finalmente se lanzó Avail Mainnet. Como su nombre indica, Avail es un proyecto de capa de disponibilidad de datos (DA). Mucha gente puede pensar que "Avail" es otro proyecto de DA como Celestia o EigenDA, pero no es así.

Desde el roadmap de Avail se puede ver que Avail no es solo un proyecto de DA, sino una capa unificada de integración vertical. Aunque la comunidad ya tiene muchos artículos que presentan Avail, este artículo se centrará en las ventajas de Avail en comparación con otros proyectos de DA. Si está interesado en conocer los conceptos básicos de Avail, consulte los siguientes artículos:

• Avail： La infraestructura de encriptación de Blockworks unificada
• Redacted Research 的$AVAIL 与 Web3 的统一

1. Interoperabilidad de mínima confianza y capa de liquidación fija

En comparación con otras capas de DA, la ventaja más significativa de Avail es su capa de liquidación fija, llamada Avail Nexus, que admite la interoperabilidad de minimización de confianza entre la agregación.

1.1 ¿Por qué se necesita un modelo de cadena de bloques con un sistema de prueba unificado?

Para lograr la puente segura, es crucial comprender la cadena normativa y la efectividad de la ejecución en la red contraparte. La agregación soberana que comparte la misma capa DA publica datos de transacciones en la misma capa DA, por lo que es fácil comprender la cadena normativa de la red contraparte. Sin embargo, solo compartir la capa DA no facilita la verificación de la efectividad de la ejecución en la red contraparte.

Por lo tanto, se ha discutido un método para lograr la transmisión de mensajes de interacción cross-chain con confianza mínima entre los Rollups soberanos, y lo más destacado es la transmisión de mensajes IBC entre los Rollups basados en Cosmos SDK. En IBC, se logra la confianza mínima a través de la verificación de los encabezados de los bloques y las pruebas de Merkle de la red opuesta mediante la validación de clientes ligeros en el puente.

Sin embargo, ¿cómo se puede lograr la consolidación de la soberanía sin usar Cosmos SDK? Todavía necesitan verificar la validez de la ejecución de la red de contraparte a través de cliente ligero. Las diferencias en la Máquina virtual, los esquemas de prueba (prueba de fraude y prueba de validez) o el sistema de prueba zk pueden hacer que la construcción de un sistema de verificación de puente de confianza mínima sea extremadamente desafiante.

Además, si el puente entre la consolidación de la soberanía se realiza de manera punto a punto en lugar de a través de un modelo de radiación central, el sistema de puente se volverá fragmentado. Cada nuevo canal requerirá un nuevo sistema, y es posible que surjan varios tipos de tokens envueltos, lo que provocará problemas de intercambiabilidad incluso entre tokens del mismo tipo.

Por lo tanto, para garantizar la seguridad y la experiencia de usuario sin problemas en la consolidación de puente entre capas DA compartidas, es necesario utilizar un sistema unificado para verificar la ejecución y adoptar un modelo de puente radial de eje compartido para un único nivel de liquidación.

1.2 Usando Nexus

Esto es realmente lo que hace Avail Nexus. Avail Nexus es una capa de liquidación zk construida sobre Avail, como una capa de liquidación fija del ecosistema Avail. Avail Nexus maneja 1) subastas de secuenciadores y 2) agregación de pruebas, permitiendo que la liquidación en el ecosistema Avail logre una transmisión de mensajes cross-chain de interacción de minimización de confianza rápida y eficiente.

Avail Nexus recopilará y verificará pruebas de varios tipos de rollup provenientes de múltiples rollup, y las combinará en una prueba concisa. No solo los rollup de validez, sino también los rollup optimistas pueden participar en Avail Nexus. Los rollup optimistas pueden enviar sus recibos y raíces de estado a Nexus, y si no se proporciona ninguna prueba de fraude durante el período de desafío, se incluirán en el estado de Nexus.

La prueba de validación final se presentará a Avail DA y la red Ethereum. Debido a la falta de capa de ejecución en Avail DA, se agregará un módulo para prueba de validación en el futuro. La información de estado de los Rollups en Avail Nexus se verifica en la red Ethereum, con el mismo supuesto de seguridad que opera como capa de liquidación que los validiums que utilizan Ethereum como capa de liquidación.

2. Utilizar el esquema de compromiso KZG para verificación rápida

Avail DA utiliza el esquema de compromiso KZG para la prueba de validez, lo que permite a los clientes ligeros verificar rápidamente la disponibilidad de los datos de manera concisa. Además, gracias a la propiedad homomórfica del compromiso KZG, se puede verificar la corrección del código de borrado sin necesidad de prueba de fraude, lo que elimina la latencia causada por el desafío del período.

2.1 ELI5: Compromiso KZG

En criptografía, un compromiso es un método para comprometerse con un conjunto de datos en un momento dado y revelarlo más tarde para demostrar la autenticidad de los datos originales. Los compromisos suelen utilizarse para comprimir u ocultar datos. Dos propiedades clave de un compromiso son el enlace y el ocultamiento.

• Vinculación: una vez que se envían los datos, no se pueden cambiar, lo que garantiza la integridad.
• Oculto: no se puede inferir datos originales de las promesas.

Un esquema de compromiso común en la cadena de Bloquear es el árbol de Merkle, que comprime la información en un valor único que no revela los datos originales y permite verificar fácilmente si ciertos datos están incluidos en el árbol de Merkle.

El esquema de compromiso polinomial KZG compromete polinomios. Los datos pueden convertirse en un polinomio que tiene un valor de compromiso individual de tamaño fijo. La ventaja del compromiso KZG es que los validadores pueden demostrar fácilmente la inclusión de datos específicos utilizando pruebas KZG muy pequeñas (O(1)). En comparación con los árboles de Merkle, esta es una ventaja significativa, ya que el tamaño de la prueba de los árboles de Merkle sube logarítmicamente con el tamaño de los datos (O(logN)).

2.2 Compromiso de KZG en Avail

Profundicemos en el método de almacenamiento de datos y el proceso de verificación de la disponibilidad de datos en Avail DA. Cuando los usuarios (rollup) envían datos de transacciones a Avail, los datos se organizan en una matriz bidimensional. Luego, se utiliza un código de corrección de errores para generar datos redundantes, lo que efectivamente duplica los datos originales.

Debido a que el volumen de datos se ha duplicado, los productores maliciosos de bloques deben ocultar más de la mitad de los datos para poder ocultarlos, por lo que es muy probable que este comportamiento sea detectado durante el proceso de muestreo de disponibilidad de datos. Los datos en cada fila se convierten en polinomios, y el compromiso polinómico KZG de estos datos está incluido en el encabezado del bloque. A continuación se muestran las funciones implementadas por el compromiso KZG:

1. cliente ligero puede verificar la disponibilidad de datos de manera rápida y sencilla: si cliente ligero desea verificar si datos específicos están incluidos en un bloque, gracias al compromiso KZG, el Nodo completo puede proporcionar pruebas KZG muy pequeñas (O(1)).
2. Se puede verificar la corrección de la codificación por borrado sin prueba de fraude: En Celestia, la prueba de fraude se utiliza para verificar la corrección de la codificación por borrado, lo que puede provocar latencia debido al período de desafío. Dado que la promesa de KZG es homomórfica, se puede verificar rápidamente la corrección de la codificación por borrado al comprobar si la promesa de los datos de codificación por borrado coincide con la promesa de codificación por borrado.

3. Implementando seguridad y actividad con BABE y GRANDPA

La mayoría de las redes de Cadena de bloques suelen enfocarse en la seguridad o la actividad de su Mecanismo de consenso. Avail DA, construido sobre el Polkadot SDK, utiliza BABE y GRANDPA como su Mecanismo de consenso, ofreciendo un equilibrio similar de actividad y seguridad a la de Ethereum.

3.1 Asignación ciega de extensión de blockchain (BABE)

BABE es el motor de producción Bloquear de Avail, responsable de garantizar la actividad. Cada ranura (20 segundos) selecciona un autor principal para producir Bloquear a través de VRF. Puede haber varios autores en una ranura o incluso ninguno. Si se seleccionan varios autores, comienza una competencia y el Bloquear con mayor difusión se convierte en parte de la cadena canónica. Si no se selecciona un autor principal, se producirá Bloquear a través de un autor secundario seleccionado mediante un método de rotación.

3.2 Basado en GHOST, derivando el prefijo de ancestro recursivo protocolo (GRANDPA)

GRANDPA actúa como una herramienta de determinación final similar a Casper FFG de Ethereum, pero a diferencia de él, determina la cadena de especificaciones finales en lugar de un solo bloque, acelerando así el proceso de determinación final. En un entorno sincrónico, más de dos tercios de los nodos deben ser honestos para determinar la finalidad, mientras que en una configuración asincrónica puede manejar hasta un quinto de los nodos bizantinos.

4. Sistema ecológico con una encriptación económica segura

（Avail Fusion | Fuente: Avail）

Avail Fusion permite que los tokens de otros ecosistemas contribuyan a la seguridad criptográfica del sistema Avail. Protocolos como EigenLayer, Babylon, Symbiotic y Karak son seguidos debido a la gran seguridad que ofrecen BTC y ETH. Con la implementación de Avail Fusion, se espera que el nivel de seguridad del ecosistema Avail mejore significativamente. Una crítica común a Optimium y Validium es que su seguridad se debilita debido a su dependencia de capas DA externas. Avail DA con Avail Fusion puede mitigar estas críticas.

Lo interesante es que el Token de rollup en Avail también se puede utilizar en Avail Fusion. Uno de los mayores defectos de la tokenómica de rollup Token es la falta de utilidad fuera de la gobernanza. Avail Fusion puede resolver este problema al mejorar su productividad y acelerar el ciclo de incentivos del ecosistema a través de la encriptación económica utilizando rollup Token.

Sin embargo, una cuestión que vale la pena seguir es la distribución de las recompensas. Si los tokens de otros ecosistemas se utilizan para el consenso y se obtienen recompensas de bloque, las recompensas relativas de los participantes de AVAIL podrían disminuir. Por lo tanto, al introducir Avail Fusion, es necesario realizar un diseño complejo de la proporción de stake y recompensas de tokens de ecosistemas externos.

5. Varios programas de utilidad Token

La tokenómica es el campo más prometedor de la encriptación y también un problema de larga data. Aunque los Token pueden actuar como un lubricante para garantizar el funcionamiento fluido del protocolo, un diseño deficiente o la falta de utilidad puede hacer que se conviertan en un perjuicio.

(Fuente: Avail)

Afortunadamente, Avail proporciona múltiples usos para el token AVAIL a través del concepto de capa unificada, a diferencia de muchos otros protocolos, integra internamente varias capas y funcionalidades:

• Gobierno
• Tarifa DA
• Proporcionar seguridad DA
• Participar en el grupo secuencial de Nexus stake
• Participar en la piscina de agregación de pruebas en Nexus de stake
• Tarifa de transición

Teniendo en cuenta la funcionalidad y la utilidad del Token en cada capa, Avail puede considerarse como una combinación de la capa DA, la capa de ordenación Descentralización y la capa de agregación ZKP. Esto resalta el enorme potencial de crecimiento del ecosistema Avail.

6. Últimas reflexiones

Aunque el ecosistema modular dentro de Ethereum ha avanzado considerablemente, el ecosistema modular fuera de Ethereum aún no es maduro en cuanto a interoperabilidad y seguridad. Avail ofrece soluciones efectivas a estos problemas a través de Avail DA, Avail Nexus y Avail Fusion, convirtiéndose en un ecosistema modular ideal.

Al igual que la batalla en curso entre la infraestructura y las aplicaciones, aunque Avail ha construido una infraestructura perfecta, el verdadero desafío sigue siendo crear un ecosistema dinámico. Sin embargo, no hay de qué preocuparse. Según la página del ecosistema de Avail, Avail ya se ha integrado en varios SDK de agregación, incluyendo Arbitrum Orbit y Polygon CDK. También hay muchos plataformas RaaS como Conduit y AltLayer que admiten Avail DA, con un total de 32 redes de agregación que se unirán a Avail DA.

En los últimos años, el ecosistema modular se ha vuelto más diverso y amplio. Muchos proyectos modulares (como rollup y DA layer) están entrando en el mercado y para sobrevivir en este entorno competitivo, los proyectos deben tener ventajas únicas. Avail se destaca en el mercado gracias a su concepto de capa unificada, que proporciona funciones como ejecución de DA, ordenamiento, agregación de ZKP y stake. Por lo tanto, el próximo viaje de Avail es definitivamente emocionante.