O relatório Devnet do PeerDAS da Sunnyside de 7/14 está aqui! Vamos mergulhar no estado atual do PeerDAS - quanto blob conseguimos lidar e qual é o gargalo?

Entre esses esforços, o papel da Sunnyside é executar devnets semanais em muitas configurações diferentes e fornecer aos desenvolvedores principais os insights resultantes: •Onde estão os limites atuais do PeerDAS •Exatamente quais componentes criam gargalos •Quão bem funcionam na prática otimizações como Supernodes e GetBlobV2

O nosso principal objetivo é testar de forma rápida e flexível de maneiras que complementem o que outras equipas, como @ethPandaOps, estão a fazer nos eventos fusaka-de, fornecendo feedback atempado que apoie a implementação contínua do PeerDAS.

Nesta semana, operámos 12 devnets e executámos 3 suites de testes, utilizando a imagem mais recente fusaka-devnet-2 do @ethPandaOps: 1. Throughput de Blobs (máx. blobs por bloco) 2. Largura de Banda da Rede (teste de carga sustentada) 3. Limitação de Largura de Banda (30 / 20 / 10 Mbps)

1 – Teste de Throughput de Blob Os resultados do teste mostraram que a maioria dos clientes CL poderia lidar com 84 blobs por bloco ou mais, e permaneceu estável com pelo menos 40 blobs. Alguns clientes registraram uma contagem máxima de blobs relativamente mais baixa em comparação com devnets anteriores - mas isso pode ser porque a contagem de validadores por nó neste devnet foi reduzida de 100 para 8, o que, por sua vez, diminuiu a taxa de participação da sub-rede de cada nó.

2 – Teste de Largura de Banda da Rede Ao contrário dos devnets anteriores, onde a rede frequentemente se tornava instável com altos números de blobs, desta vez todos os devnets funcionaram de forma estável por um período prolongado (~16 horas), mesmo com 60 ou 72 blobs por bloco. Embora isso não garanta estabilidade em nível de produção, mostra que pelo menos algumas combinações de CL-EL alcançaram um nível de robustez muito maior através da otimização 🚀

3 – Teste de Limitação de Largura de Banda Para verificar se os stakers reais em casa podem participar de forma suave uma vez que o PeerDAS esteja ativo, este teste aplicou limites de rede e examinou quais fatores se tornam gargalos em vários cenários restritos. Em múltiplos testes, descobrimos que o uso de largura de banda dos nós periodicamente aumenta - especialmente perto do início de um slot quando os blobs são divulgados - e que esses picos limitam o desempenho geral da rede. O tráfego de pico ocorreu uniformemente entre os nós, em vez de ser causado por um cliente CL ou EL específico, e uma vez que os picos começaram, a rede não conseguiu aumentar mais a taxa de transferência de blobs. Em outras palavras, o tráfego de pico é o maior gargalo em ambientes com largura de banda restrita, e precisamos encontrar maneiras de mitigá-lo.

Além disso, comunicámos com várias equipas de clientes e incentivámos melhorias para questões relacionadas com a sincronização e pares.

A devnet do Sunnyside ainda está em funcionamento 🏗️; a realizar interop-devnets com várias combinações de clientes, testes de largura de banda mais granulares, testes de spam que incluem transações normais e testes de preenchimento/sincronização, para identificar gargalos em ambientes que se assemelham mais às condições da mainnet.