Introdução
Com o rápido desenvolvimento da tecnologia blockchain, as blockchains individuais enfrentam desafios sérios de escalabilidade e interoperabilidade. Plataformas mainstream como Ethereum experimentaram grandes subidas nos custos de transação e lavagem de dinheiro durante o aumento da base de usuários, o que prejudicou seriamente a disseminação da descentralização. Para lidar com esses problemas, os desenvolvedores estão constantemente procurando soluções inovadoras, e o surgimento da Avail oferece uma nova direção para resolver esses problemas. Com a atualização de Cancun, os custos de transação do ecossistema Ethereum diminuíram significativamente, enquanto a tecnologia modular se tornou uma narrativa importante para o desenvolvimento da blockchain. No primeiro semestre, blockchains modulares como Celestia e EigenDA lideraram a tendência, e a Avail deu um passo crucial ao lançar a Avail DA Rede principal em 23 de julho no campo da modularidade.
Como projetos principais do blockchain modular, Avail, EigenDA e Celestia, embora semelhantes no campo de serviços, apresentam características distintas na infraestrutura, modelo de execução e design econômico do token.
Background da Equipe
Avail originated from Polygon and became an independent entity in 2023. Before the data availability (DA) issue became a focus of the industry, Anurag Arjun worked with others to develop the Plasma chain in an attempt to solve Ethereum’s scalability issues. Although the chain helped Polygon achieve a revenue of 19 billion US dollars, it failed to become an ideal scaling solution. In this process, Anurag gradually realized that all blockchain will eventually face the same obstacle - the issue of data availability. In Rollup transaction costs, about 80% are related to DA, so he envisioned that building a cost-effective DA layer might solve the scaling problem of multiple blockchains.
Esta ideia não é exclusiva de Anurag, a maioria dos projetos da Blockchain L1 também estão tentando se tornar uma camada DA, o Blockchain Ethereum está explorando soluções DA através da rota Rollup e outros projetos L1 estão inovando nessa área. Anurag acredita que a Blockchain L1 projetada especificamente para DA possui vantagens únicas.
Anurag conheceu o atual co-fundador da Avail, Prabal Banerjee, durante o período da Matic, quando ele estava buscando seu doutorado em criptografia e segurança, e posteriormente se juntou à equipe como pesquisador. Os dois trabalharam juntos para construir uma camada DA escalável. Com o surgimento da tecnologia de prova de conhecimento zero (ZK), eles combinaram o design de blockchain de prova de validade e, com a experiência de Anurag em construir um protocolo de bilhões na Polygon, avançaram ainda mais a solução para o problema de disponibilidade de dados.
Da cadeia única à modularização
![]()
Fonte: Documentação oficial da Avail
Com a competição cada vez mais acirrada pelos recursos computacionais de base, os problemas de execução, liquidação, ordenação e disponibilidade de dados do ETH Ethereum começaram a ser expostos gradualmente em uma única cadeia, levando a uma limitação de escalabilidade. A indústria está começando a revisar a arquitetura de cadeia única e buscar novas soluções.
Rollups, ao mover a execução para fora da cadeia, introduziram uma arquitetura modular que aliviou efetivamente o congestionamento da rede L1, reduzindo os custos de transação dos usuários, ao mesmo tempo em que aumentaram a capacidade de processamento de transações. Embora essa arquitetura tenha trazido melhorias significativas na eficiência na cadeia, o espaço limitado do bloco Ethereum ainda é um gargalo e pode surgir novamente à medida que a demanda aumenta. Atualmente, os Dapps dependem da L1 para transferência de dados e liquidação, enquanto os Rollups usam a L1 para processar esses processos. Embora os Rollups otimizem o uso do espaço do bloco, o espaço do bloco ainda está muito apertado.
Ao analisar as transações L1 do Rollups da Ethereum, descobriu-se que os custos de DA representam 90% dos custos, o que é a maior fonte de despesas do Rollups, e a maior parte da receita é utilizada para pagar as taxas de publicação de transações L1.
Semelhante aos rollups, o Avail pode mover a execução para fora da cadeia, e sua arquitetura permite a disponibilidade de dados em uma camada dedicada. O Avail oferece aos desenvolvedores uma camada de disponibilidade de dados flexível, fácil de usar e segura, resolvendo os desafios de escalabilidade, governança e Descentralização.
Estrutura modular construída por Avail
Avail visa utilizar a sua pilha de tecnologia modular, que combina a disponibilidade, agregação e partilha de dados, para acelerar a uniformidade da Web3. A utilização de Rollup da Avail para publicar dados de transações fora da cadeia irá resultar em Validium (para Optimistic Rollup, é chamado Optimium). Os Validiums e Sovereign Rollups podem depender dos serviços de disponibilidade de dados com baixa confiança e ordenação fornecidos pela Avail.
Aqui está um breve processo de suporte para Validiums e Sovereign Rollups da Avail:
- Submissão de transação: Como na maioria dos rollup existentes, os dados de chamada de transação são processados em lote, a raiz de estado é submetida à Avail DA e identificada por um ID de aplicação único que representa a origem do rollup.
- Expansão de dados e codificação de apagamento: As transações enviadas para Avail DA são processadas através da codificação de apagamento, onde o bloco é dividido em n blocos originais e expandido para 2n, onde é possível selecionar qualquer n blocos dentre os 2n para reconstruir os dados.
- Promessa de Criação: Avail DA irá obter dados redundantes e aplicar o polinómio KZG a cada Bloco. Estas promessas servem como prova de encriptação da integridade dos dados, garantindo assim que os dados armazenados são precisos e não podem ser adulterados.
- A propagação do Bloco: os validadores recebem o Bloco com compromissos KZG e recriam esses compromissos para verificar sua precisão e chegar a um consenso sobre o Bloco.
- Rede de cliente ligeiro: O cliente ligeiro utiliza a verificação DAS para a integridade dos dados do bloco. Isso é alcançado através da verificação de abertura do polinômio KZG para cada unidade de amostragem no cabeçalho do bloco, eliminando a necessidade de reconstrução completa do compromisso KZG ou dependência de prova de fraude.
- 证明验证：cliente ligeiro通过从数据矩阵生成的单元级证明执行证明验证。
Devido ao Avail utilizar prova de validade em vez de prova de fraude, o cliente ligeiro pode verificar a disponibilidade e correção dos dados após a confirmação final do estado. Além disso, a rede de cliente ligeiro garante alta disponibilidade dos dados através da amostragem de disponibilidade de dados. Com a adesão de mais clientes ligeiros, a capacidade de amostragem aumenta, o que pode suportar blocos de maior escala. Os usuários até podem executar esses clientes ligeiros em laptops ou telemóveis para aumentar ainda mais a eficiência da rede.
![]()
Fonte: Documentação oficial da Avail
Características técnicas
Aplicação de cliente ligeiro
Atualmente, muitos cenários de aplicação dependem de intermediários para manter nós completos, onde os usuários interagem indiretamente com a cadeia de blocos por meio desses intermediários, em vez de se conectarem diretamente. Devido à falta de garantia de disponibilidade de dados, os clientes leves ainda não são uma solução ideal para arquiteturas tradicionais. A Avail resolve esse problema, permitindo que mais aplicativos interajam diretamente com a rede de cadeia de blocos sem depender de intermediários. Embora a Avail suporte operações em nós completos, a maioria dos aplicativos não precisa executar nós completos ou requer apenas alguns nós para funcionar sem problemas.
Amostragem de Disponibilidade de Dados (DAS)
Semelhante ao cliente ligeiro tradicional, o cliente ligeiro do Avail só precisa de baixar os dados do bloco. Além disso, eles verificam a sua correção através da amostragem de parte dos dados do bloco, garantindo assim a sua disponibilidade. Com a combinação de codificação e compromisso polinomial KZG, o cliente ligeiro pode garantir quase 100% de disponibilidade dos dados sem depender de prova de fraude, e apenas realizando algumas consultas fixas.
codificação de apagamento与数据可用性
A codificação de apagamento permite que os dados sejam fragmentados, de forma que, mesmo que parte dos dados seja perdida, ainda seja possível recuperar o conteúdo original a partir de outras fragmentações. Nas aplicações de blockchain, isso significa que, mesmo que um ator mal-intencionado tente ocultar parte dos dados, o sistema ainda poderá recuperar os dados a partir de outras fragmentações. Esse mecanismo aumenta significativamente a confiabilidade da disponibilidade dos dados e reforça ainda mais a capacidade de prevenir a adulteração dos dados.
Compromisso KZG
A tecnologia de compromisso polinomial KZG, prometida pela KZG, foi proposta por Aniket Kate, Gregory M. Zaverucha e Ian Goldberg em 2010. É um método eficiente de compromisso polinomial que tem sido amplamente utilizado em estruturas de prova de conhecimento zero nos últimos anos. Na arquitetura do Avail, o compromisso KZG tem as seguintes vantagens:
- Comprometa-se com os valores de forma concisa e registre-os no cabeçalho de bloco;
- Permitir que o cliente ligeiro verifique a disponibilidade dos dados;
- A sua encriptação torna praticamente impossível gerar compromissos errados, reduzindo a necessidade de prova de fraude.
A camada unificada do Avail
Avail has been building a unified layer for Avail, which is a unified technology stack starting from the basic data availability (DA) layer, the Nexus unified layer, and the additional security layer Fusion. Avail will support the entire Web3 ecosystem through a scalable data availability layer, utilizing prova de validade with KZG polynomial commitment to ensure instant and reliable data availability, enabling aggregation to rise, connect, remain secure, and adapt.
Avail DA
![]()
Fonte: Documentação oficial da Avail
Avail DA é uma infraestrutura de base projetada para otimização da disponibilidade de dados, utilizando os algoritmos de consenso GRANDPA e BABE, diferenciando-se de outras camadas de DA. Este design confere ao Avail DA uma alta escalabilidade, garantindo uma proteção de dados confiável a baixo custo por meio de amostragem de disponibilidade de dados (DAS) e prova de validade.
O Avail DA tem como núcleo a classificação e publicação prioritárias de transações, permitindo simultaneamente aos utilizadores verificar a disponibilidade de dados do Bloco, sem necessidade de descarregar o Bloco inteiro. A neutralidade dos dados do Avail DA é uma das suas funcionalidades definidoras. Suporta vários ambientes de execução, incluindo EVM, WASM e runtimes personalizados, fornecendo uma base multifuncional para várias aplicações de cadeias de Bloco.
Avail Nexus
![]()
Fonte: Documentação oficial da Avail
Avail Nexus, como o segundo pilar, é uma estrutura sem permissão projetada para unificar o ecossistema web3. Ele conecta blockchains internos e externos, baseado em Avail DA como fundamento de confiança e atua como centro de validação. O Nexus contém Rollup coordenado por ZK, integrando agregação de provas, camada de validação, mecanismo de seleção de ordenador e leilão de slots. O Nexus envia regularmente as provas agregadas para a verificação na camada Ethereum e Avail DA, garantindo a confiabilidade da operação de cadeia cruzada.
Avail Fusion
![]()
Fonte: Documentação oficial da Avail
O terceiro pilar Avail Fusion fornece segurança adicional para o ecossistema Avail e todo o web3. Sua ideia central é que, em termos de economia macro, um sistema unificado requer segurança unificada. A Fusion Security contribui para a segurança do Avail Consenso ao utilizar ativos locais em ecossistemas maduros como BTC e ETH. Este mecanismo é a primeira tentativa de alcançar consenso entre diferentes blocos de cadeia usando tokens externos.
Avail Fusion suporta dois tipos de stake de ativos: criptomoedas estabelecidas e tokens Rollup emergentes. Atualmente, o protótipo da Fusion inclui dois módulos de stake: um executado na cadeia de blocos Avail e outro para conversão de ativos. É importante notar que o primeiro protótipo público do Avail Fusion ainda está em desenvolvimento.
Tipo Nó do Avail
Embora a arquitetura do Avail seja diferente da blockchain tradicional, ela suporta vários tipos de nó, incluindo nó completo, cliente ligeiro, nó de arquivo e nó de verificação.
- Nó completo: Um nó completo é responsável por baixar e verificar a corretude do bloco, mas não participa do processo de consenso. Sua existência fornece redundância e elasticidade adicionais ao sistema, mas não é um componente necessário.
- Verificação do nó: O nó de verificação ajuda a rede a alcançar o consenso, gerando blocos, decidindo se as transações estão incluídas e mantendo a ordem das transações.
- cliente ligeiro: O cliente ligeiro permite aos utilizadores interagir com a camada de disponibilidade de dados (DA) da Avail sem necessidade de executar um nó completo e sem necessidade de confiar em nós pares remotos. Isso é alcançado executando amostragem de disponibilidade de dados (DAS) em cada novo bloco criado.
- RPC Nó：RPC Nó fornece uma API de interação remota como uma porta de entrada para desenvolvedores e usuários externos na rede Avail.
O cliente ligeiro irá ouvir os Blocos confirmados na rede Avail e executar amostras de disponibilidade de dados (DAS) para os dados pré-configurados de novos Blocos. Após a verificação bem-sucedida, o sistema calculará a certeza de um certo número de unidades de dados no Bloco, de acordo com o nível de confiança necessário para o usuário.
Modelo Econômico
Alocação de Tokens
Com o lançamento da Rede principal do AvailDA, a equipe fez um Airdrop do token AVAIL para usuários elegíveis, com um fornecimento total de 10 bilhões de tokens. Desses, 6% são destinados ao Airdrop e distribuição pública, 30% para o desenvolvimento do ecossistema, 23,88% para a comunidade e pesquisa, 14,12% para investidores e 20% para os principais contribuintes.
![]()
Fonte: Documentação oficial da Avail
stake
O uso do Token AVAIL abrange a governança e a stake de Liquidez no ecossistema. Embora o plano de governança oficial ainda não tenha sido divulgado em detalhes, qualquer pessoa pode fazer stake do AVAIL em toda a infraestrutura da Avail para obter recompensas de stake.
Em termos de stake, Avail adota o mecanismo de consenso de Prova de Stake Nomeada (NPoS) herdado do ecossistema Substrato. O stake desempenha um papel crucial no NPoS. Ao apostar AVAIL Token, os usuários ajudam a aumentar a segurança da rede e recebem recompensas correspondentes. Quanto mais Token em stake, maior a segurança da rede, uma vez que o custo para atacar a rede também aumenta.
Os cenários de aplicação do stake são os seguintes:
- Avail DA stake: Os usuários podem apostar tokens AVAIL para validadores ou pools de nomeação para garantir a segurança da rede e suportar diferentes casos de uso, como jogos Web3 e a plataforma Finanças Descentralizadas. As recompensas estão disponíveis para os apostadores.
- Avail Nexus stake：排序器需stake AVAIL Token以参与交易提交和排序，表现优秀的排序器可获得奖励，表现不佳者则会受到惩罚。
- Avail Fusion stake: Além do Token AVAIL, você também pode fazer stake em outros ativos de encriptação mainstream como BTC e ETH para reforçar ainda mais a segurança da rede, e os stakers podem obter retornos correspondentes.
É importante notar que, se o utilizador pretender cancelar a stake, terá de concluir o processo de desbloqueio de 28 dias, durante o qual o AVAIL Token não pode ser utilizado ou transferido.
Desafios enfrentados
Risco de competição Rollup
O desenvolvimento da Avail pode ser afetado pelos grandes rollups universais que possuem ecossistemas maduros e soluções internas de interoperabilidade, o que pode enfraquecer o valor do Avail Nexus, pois não dependeria mais de sistemas externos de interoperabilidade. No entanto, o número de rollups específicos de aplicativos atuais está aumentando rapidamente, bem como o problema altamente fragmentado enfrentado pelos usuários, tornando essa situação improvável.
Competição de soluções DA
Com o lançamento de várias soluções de DA no mercado, como Celestia e EigenDA, o Ethereum também introduziu blobs como opção de publicação de dados através do EIP-4844. A competição acirrada entre as camadas de DA e a sensibilidade do rollup aos custos de publicação de dados podem levar a uma diminuição, levando o rollup a tender a escolher soluções de DA verificadas ou depender do Ethereum para publicação de dados após a implementação completa do danksharding.
Risco de Segurança Compartilhado
O modo de segurança compartilhada fornecido pelo Avail Fusion depende de vários tokens e do staking do token AVAIL, o que pode levar a preocupações dos usuários em relação à segurança de vários ativos. Alguns desenvolvedores podem preferir obter segurança de um único ativo, como ETH ou BTC, em vez de depender de vários tokens. Além disso, se o Avail Fusion não fornecer segurança suficiente, os desenvolvedores podem recorrer a soluções de DA com maior segurança econômica.
Competição no ecossistema de serviços de valor agregado
Outros produtos de segurança que envolvem staking ou compartilhamento podem ter ecossistemas de serviços especializados para rollup. Por exemplo, o EigenLayer pode oferecer funcionalidades como ordenação descentralizada, disponibilidade de dados e finalidade rápida, o que aumentará sua competitividade.
