! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
À medida que os usuários começam a integrar o Avail em seus designs de cadeia, a pergunta muitas vezes surge: "Quantas transações o Avail pode processar?" Neste post, vamos comparar a taxa de transferência do Ethereum e do Avail com base na arquitetura atual das duas cadeias.
Este é o primeiro de uma série sobre a escalabilidade da Avail que discutirá o desempenho atual da Avail e sua capacidade de escalar a curto e longo prazo.
Avail vs Ethereum
Os blocos do Ethereum podem conter até 1,875 MB de dados e ter um tempo de bloqueio de cerca de 13 segundos. No entanto, os blocos do Ethereum geralmente não são preenchidos. Quase todos os blocos não atingem o limite superior de dados porque atingem o limite de gás, porque tanto a execução como a liquidação consomem gás. Como resultado, a quantidade de dados armazenados em cada bloco é variável.
A necessidade de combinar execução, liquidação e disponibilidade de dados no mesmo bloco é uma questão central com uma única arquitetura blockchain. Os rollups L2 iniciaram o movimento para blockchains modulares, permitindo que as operações de execução sejam tratadas em uma única cadeia, e os blocos da cadeia são dedicados à execução. A Avail vai um passo além, adotando um design modular que também separa a disponibilidade de dados, permitindo que blocos de uma cadeia sejam dedicados à disponibilidade de dados.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Atualmente, o tempo de bloqueio do Avail é de 20 segundos, e cada bloco pode conter cerca de 2 MB de dados. Supondo um tamanho médio de transação de 250 bytes, cada bloco Avail pode conter cerca de 8.400 transações hoje (420 transações por segundo).
Além disso, o Avail sempre pode preencher blocos até o limite de armazenamento e aumentar o tamanho conforme necessário. Temos uma série de alavancas que podem ser rapidamente ajustadas para aumentar o número de transações por bloco para mais de 500.000 (25.000 transações por segundo) quando necessário.
Podemos aumentar o rendimento?
Para aumentar a taxa de transferência (especialmente as transações por segundo), os arquitetos da cadeia precisam aumentar o tamanho do bloco ou diminuir o tempo do bloco.
Para ser adicionado à cadeia, cada bloco deve gerar compromissos, construir provas, propagá-las e fazer com que todos os outros nós verifiquem essas provas. Essas etapas sempre levam tempo, o que define um limite superior natural no tempo necessário para que os blocos sejam gerados e confirmados.
Portanto, não podemos simplesmente reduzir o tempo de bloqueio para, digamos, um segundo. Isso simplesmente não tem tempo suficiente para gerar compromissos, gerar provas e propagar essas partes para todos os participantes da rede. Em um tempo teórico de bloco de um segundo, mesmo que cada participante da rede execute a máquina mais poderosa capaz de produzir compromissos e provas em um instante, o gargalo está na propagação de dados. Devido a limitações de velocidade da Internet, a rede é incapaz de notificar todos os nós completos de blocos rápido o suficiente. Portanto, temos que nos certificar de que o tempo de bloqueio é alto o suficiente para permitir que os dados sejam distribuídos para a rede após o consenso ser alcançado.
Por outro lado, também é possível aumentar a taxa de transferência aumentando o tamanho do bloco, ou seja, aumentando a quantidade de dados que podemos conter em cada bloco.
Arquitetura atual: Adicionar um bloco à cadeia
Primeiro, vamos ver as etapas necessárias para adicionar um bloco à cadeia. Há três etapas principais necessárias para adicionar cada bloco à cadeia. Isso inclui o tempo necessário para gerar um bloco, propagá-lo e validá-lo.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Geração de blocos
Esta etapa inclui o tempo necessário para coletar e classificar transações do Avail, criar compromissos e dimensionar (codificação de eliminação) a matriz de dados.
A geração de blocos mede o tempo que leva para gerar um bloco, pois isso sempre levará pelo menos algum tempo. Portanto, devemos levar em conta não apenas o tempo na melhor das hipóteses, mas também a situação média e o tempo na pior das hipóteses em máquinas diferentes.
A máquina mais fraca que pode participar da geração de novos blocos é aquela que atinge o limite de desempenho em média. Todas as máquinas mais lentas acabarão por ficar para trás porque não conseguem alcançar as máquinas mais rápidas.
2. Atraso de propagação
O atraso de propagação é uma medida do tempo que leva para propagar um bloco de um produtor para um validador e uma rede ponto a ponto.
Atualmente, o tamanho do bloco da Avail é de 2 MB. Dentro do limite de tempo de bloco atual de 20 segundos, esse tamanho de bloco pode ser propagado. Blocos maiores tornam a propagação mais complicada.
Por exemplo, se aumentarmos o Avail para suportar um bloco de 128 MB, o cálculo pode ser capaz de escalar (cerca de 7 segundos). No entanto, o gargalo se torna o tempo que leva para enviar e baixar esses blocos na rede.
Enviar um bloco de 128 MB para o mundo através de uma rede peer-to-peer em 5 segundos pode ser o limite do que é atualmente alcançável.
O limite de 128 MB não tem nada a ver com a disponibilidade de dados ou nosso cenário de compromisso, mas sim uma questão de limitações de largura de banda de comunicação.
Essa necessidade de levar em conta a latência de propagação nos dá o limite de tamanho de bloco teórico atual da Avail.
3. Validação de bloco
Uma vez propagados, os validadores participantes não confiam simplesmente nos blocos fornecidos pelo proponente do bloco — eles precisam verificar se o bloco produzido realmente contém os dados reivindicados pelo produtor.
Há uma certa tensão entre estes três passos. Podemos tornar todos os validadores máquinas poderosas e firmemente conectadas por uma excelente rede no mesmo data center – isso reduzirá o tempo de produção e validação, e nos permitirá propagar muito mais dados. No entanto, como também queremos ter uma rede descentralizada e diversificada com diferentes tipos de participantes, esta não é uma abordagem ideal.
Em vez disso, o aumento na taxa de transferência será alcançado pela compreensão das etapas necessárias para adicionar blocos à cadeia Avail e quais etapas podem ser otimizadas.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Atualmente, os validadores que usam o Avail pegam todo o bloco e copiam todos os compromissos gerados pelo proponente para validar o bloco. Isso significa que os produtores de blocos e todos os validadores precisam executar cada uma das etapas no gráfico acima.
Em um único blockchain, é a prática padrão para cada validador reconstruir todo o bloco. No entanto, em uma cadeia como a Avail, onde as transações não são executadas, essa reconstrução não é necessária. Portanto, uma maneira de otimizar o Avail é permitindo que os validadores alcancem suas próprias garantias de disponibilidade de dados por amostragem, em vez de reconstruir blocos. Isso consome menos recursos para os validadores do que exigir que eles repliquem todos os compromissos. Mais sobre isso em um artigo futuro.
Como funciona a amostragem de disponibilidade de dados exploratórios?
Na Avail, os clientes light usam três ferramentas principais para confirmar a disponibilidade de dados: amostras, compromissos e provas.
Atualmente, clientes leves executam operações de amostra que solicitam o valor de uma determinada célula e sua prova de validade associada da rede Avail. Quanto mais amostras colherem, mais confiantes estarão de que todos os dados estão disponíveis.
Os compromissos são gerados pelos proponentes de blocos e resumem uma linha inteira de dados em um bloco Avail. (Dica: esta é a etapa que otimizaremos mais adiante nesta série.) ）
Cada célula da rede gera uma prova. Os clientes Light usam atestados e prometem verificar se os valores das células fornecidas a eles estão corretos.
Usando essas ferramentas, o cliente leve executa três etapas.
Decisão: A confiança de disponibilidade necessária determina o número de amostras para a execução do cliente leve. Eles não precisam de muitas amostras (8-30 amostras) para alcançar mais de 99,95% de garantia de disponibilidade.
Download: O cliente light então solicita essas amostras e suas provas associadas e as baixa da rede (nó completo ou outro cliente light).
Validação: Eles olham para a promessa no cabeçalho do bloco (que é sempre acessível a clientes leves) e verificam a prova de cada célula contra a promessa.
Só com isso, os clientes light podem confirmar a disponibilidade de todos os dados em um bloco sem ter que baixar a maior parte do conteúdo do bloco. Outras medidas tomadas por clientes leves também contribuem para a segurança da Avail, mas não estão listadas aqui. Por exemplo, clientes light podem compartilhar amostras e provas que baixam com outros clientes light caso precisem. Mas esse é o procedimento para clientes leves confirmarem a disponibilidade dos dados!
Na segunda parte desta série, exploraremos maneiras de aumentar a taxa de transferência do Avail no curto prazo. Vamos explicar por que acreditamos que a Avail pode atender às necessidades de qualquer rede no próximo ano e como podemos melhorar a rede para enfrentar os desafios dos próximos anos.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Escalabilidade DA: estado atual do Avail
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
À medida que os usuários começam a integrar o Avail em seus designs de cadeia, a pergunta muitas vezes surge: "Quantas transações o Avail pode processar?" Neste post, vamos comparar a taxa de transferência do Ethereum e do Avail com base na arquitetura atual das duas cadeias.
Este é o primeiro de uma série sobre a escalabilidade da Avail que discutirá o desempenho atual da Avail e sua capacidade de escalar a curto e longo prazo.
Avail vs Ethereum
Os blocos do Ethereum podem conter até 1,875 MB de dados e ter um tempo de bloqueio de cerca de 13 segundos. No entanto, os blocos do Ethereum geralmente não são preenchidos. Quase todos os blocos não atingem o limite superior de dados porque atingem o limite de gás, porque tanto a execução como a liquidação consomem gás. Como resultado, a quantidade de dados armazenados em cada bloco é variável.
A necessidade de combinar execução, liquidação e disponibilidade de dados no mesmo bloco é uma questão central com uma única arquitetura blockchain. Os rollups L2 iniciaram o movimento para blockchains modulares, permitindo que as operações de execução sejam tratadas em uma única cadeia, e os blocos da cadeia são dedicados à execução. A Avail vai um passo além, adotando um design modular que também separa a disponibilidade de dados, permitindo que blocos de uma cadeia sejam dedicados à disponibilidade de dados.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Atualmente, o tempo de bloqueio do Avail é de 20 segundos, e cada bloco pode conter cerca de 2 MB de dados. Supondo um tamanho médio de transação de 250 bytes, cada bloco Avail pode conter cerca de 8.400 transações hoje (420 transações por segundo).
Além disso, o Avail sempre pode preencher blocos até o limite de armazenamento e aumentar o tamanho conforme necessário. Temos uma série de alavancas que podem ser rapidamente ajustadas para aumentar o número de transações por bloco para mais de 500.000 (25.000 transações por segundo) quando necessário.
Podemos aumentar o rendimento?
Para aumentar a taxa de transferência (especialmente as transações por segundo), os arquitetos da cadeia precisam aumentar o tamanho do bloco ou diminuir o tempo do bloco.
Para ser adicionado à cadeia, cada bloco deve gerar compromissos, construir provas, propagá-las e fazer com que todos os outros nós verifiquem essas provas. Essas etapas sempre levam tempo, o que define um limite superior natural no tempo necessário para que os blocos sejam gerados e confirmados.
Portanto, não podemos simplesmente reduzir o tempo de bloqueio para, digamos, um segundo. Isso simplesmente não tem tempo suficiente para gerar compromissos, gerar provas e propagar essas partes para todos os participantes da rede. Em um tempo teórico de bloco de um segundo, mesmo que cada participante da rede execute a máquina mais poderosa capaz de produzir compromissos e provas em um instante, o gargalo está na propagação de dados. Devido a limitações de velocidade da Internet, a rede é incapaz de notificar todos os nós completos de blocos rápido o suficiente. Portanto, temos que nos certificar de que o tempo de bloqueio é alto o suficiente para permitir que os dados sejam distribuídos para a rede após o consenso ser alcançado.
Por outro lado, também é possível aumentar a taxa de transferência aumentando o tamanho do bloco, ou seja, aumentando a quantidade de dados que podemos conter em cada bloco.
Arquitetura atual: Adicionar um bloco à cadeia
Primeiro, vamos ver as etapas necessárias para adicionar um bloco à cadeia. Há três etapas principais necessárias para adicionar cada bloco à cadeia. Isso inclui o tempo necessário para gerar um bloco, propagá-lo e validá-lo.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Geração de blocos
Esta etapa inclui o tempo necessário para coletar e classificar transações do Avail, criar compromissos e dimensionar (codificação de eliminação) a matriz de dados.
A geração de blocos mede o tempo que leva para gerar um bloco, pois isso sempre levará pelo menos algum tempo. Portanto, devemos levar em conta não apenas o tempo na melhor das hipóteses, mas também a situação média e o tempo na pior das hipóteses em máquinas diferentes.
A máquina mais fraca que pode participar da geração de novos blocos é aquela que atinge o limite de desempenho em média. Todas as máquinas mais lentas acabarão por ficar para trás porque não conseguem alcançar as máquinas mais rápidas.
2. Atraso de propagação
O atraso de propagação é uma medida do tempo que leva para propagar um bloco de um produtor para um validador e uma rede ponto a ponto.
Atualmente, o tamanho do bloco da Avail é de 2 MB. Dentro do limite de tempo de bloco atual de 20 segundos, esse tamanho de bloco pode ser propagado. Blocos maiores tornam a propagação mais complicada.
Por exemplo, se aumentarmos o Avail para suportar um bloco de 128 MB, o cálculo pode ser capaz de escalar (cerca de 7 segundos). No entanto, o gargalo se torna o tempo que leva para enviar e baixar esses blocos na rede.
Enviar um bloco de 128 MB para o mundo através de uma rede peer-to-peer em 5 segundos pode ser o limite do que é atualmente alcançável.
O limite de 128 MB não tem nada a ver com a disponibilidade de dados ou nosso cenário de compromisso, mas sim uma questão de limitações de largura de banda de comunicação.
Essa necessidade de levar em conta a latência de propagação nos dá o limite de tamanho de bloco teórico atual da Avail.
3. Validação de bloco
Uma vez propagados, os validadores participantes não confiam simplesmente nos blocos fornecidos pelo proponente do bloco — eles precisam verificar se o bloco produzido realmente contém os dados reivindicados pelo produtor.
Há uma certa tensão entre estes três passos. Podemos tornar todos os validadores máquinas poderosas e firmemente conectadas por uma excelente rede no mesmo data center – isso reduzirá o tempo de produção e validação, e nos permitirá propagar muito mais dados. No entanto, como também queremos ter uma rede descentralizada e diversificada com diferentes tipos de participantes, esta não é uma abordagem ideal.
Em vez disso, o aumento na taxa de transferência será alcançado pela compreensão das etapas necessárias para adicionar blocos à cadeia Avail e quais etapas podem ser otimizadas.
! [Escalabilidade DA: estado atual do Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Atualmente, os validadores que usam o Avail pegam todo o bloco e copiam todos os compromissos gerados pelo proponente para validar o bloco. Isso significa que os produtores de blocos e todos os validadores precisam executar cada uma das etapas no gráfico acima.
Em um único blockchain, é a prática padrão para cada validador reconstruir todo o bloco. No entanto, em uma cadeia como a Avail, onde as transações não são executadas, essa reconstrução não é necessária. Portanto, uma maneira de otimizar o Avail é permitindo que os validadores alcancem suas próprias garantias de disponibilidade de dados por amostragem, em vez de reconstruir blocos. Isso consome menos recursos para os validadores do que exigir que eles repliquem todos os compromissos. Mais sobre isso em um artigo futuro.
Como funciona a amostragem de disponibilidade de dados exploratórios?
Na Avail, os clientes light usam três ferramentas principais para confirmar a disponibilidade de dados: amostras, compromissos e provas.
Usando essas ferramentas, o cliente leve executa três etapas.
Só com isso, os clientes light podem confirmar a disponibilidade de todos os dados em um bloco sem ter que baixar a maior parte do conteúdo do bloco. Outras medidas tomadas por clientes leves também contribuem para a segurança da Avail, mas não estão listadas aqui. Por exemplo, clientes light podem compartilhar amostras e provas que baixam com outros clientes light caso precisem. Mas esse é o procedimento para clientes leves confirmarem a disponibilidade dos dados!
Na segunda parte desta série, exploraremos maneiras de aumentar a taxa de transferência do Avail no curto prazo. Vamos explicar por que acreditamos que a Avail pode atender às necessidades de qualquer rede no próximo ano e como podemos melhorar a rede para enfrentar os desafios dos próximos anos.