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

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

Nosso principal objetivo é testar de forma rápida e flexível de maneiras que complementem o que outras equipes como @ethPandaOps estão fazendo na fusaka-devents, fornecendo feedback oportuno que apoie a implementação contínua do PeerDAS.

Nesta semana, operamos 12 devnets e executamos 3 suítes de testes, usando a imagem fusaka-devnet-2 mais recente do @ethPandaOps: 1. Taxa de transferência de blob (máximo de blobs por bloco) 2. Largura de banda da rede (teste de carga sustentada) 3. Restrição de largura de banda (limites de 30/20/10 Mbps)

1 – Teste de taxa de transferência 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 menor em comparação com devnets anteriores - mas isso pode ser porque a contagem de validadores por nó nesta devnet foi reduzida de 100 para 8, o que, por sua vez, reduziu a taxa de participação da sub-rede de cada nó.

2 – Teste de largura de banda de rede Ao contrário dos devnets anteriores, onde a rede geralmente se tornava instável em altas contagens de blobs, desta vez todos os devnets funcionavam de forma estável por um longo período (~ 16 horas), mesmo com 60 ou 72 blobs por bloco. Embora isso não garanta estabilidade no nível de produção, mostra que pelo menos algumas combinações CL-EL alcançaram um nível muito mais alto de robustez por meio da otimização 🚀

3 – Teste de restrição de largura de banda Para verificar se os stakers reais podem participar sem problemas quando o PeerDAS estiver ativo, este teste aplicou limites de rede e examinou quais fatores se tornam gargalos em vários cenários restritos. Em vários testes, descobrimos que o uso da largura de banda do nó aumenta periodicamente - especialmente perto do início de um slot quando os blobs são fofocados - e que esses picos limitam o desempenho geral da rede. O tráfego de intermitência ocorria uniformemente entre os nós, em vez de ser causado por um cliente CL ou EL específico e, uma vez que as intermitências começavam, a rede não podia aumentar ainda mais a taxa de transferência de blobs. Em outras palavras, o tráfego intermitente é o maior gargalo em ambientes com largura de banda restrita e precisamos encontrar maneiras de mitigá-lo.

Além disso, nos comunicamos com várias equipes de clientes e incentivamos aprimoramentos para problemas relacionados à sincronização e aos pares.

O devnet Sunnyside ainda está funcionando 🏗️; Realização de 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 rede principal.