Nesta série de três partes, revelaremos conquistas tecnológicas que podem melhorar significativamente o processamento de dados de aplicações executadas no Protocolo de Computador da Internet (ICP).
Esta atualização é um marco no roteiro do ICP chamado Stellarator, que atualmente está sendo promovido em toda a rede; o Stellarator fez avanços em armazenamento de dados em cadeia e taxa de transferência, permitindo que cada sub-rede suporte mais de 1TB de memória e carregue dados mais rapidamente, liberando oportunidades para aplicações ricas em dados que antes estavam limitadas por armazenamento e taxa de transferência.
Esse avanço permite que os desenvolvedores construam aplicações complexas que exigem processamento de dados em larga escala, trazendo novos níveis de utilidade para a tecnologia blockchain.
Como parte final desta série, Kamil Popielarz e Yvonne-Anne Pignolet compartilharão as últimas atualizações sobre o aumento da taxa de transferência de mensagens de entrada do computador da internet; se você perdeu as partes anteriores desta série, pode encontrá-las aqui e aqui.
Aumentar a taxa de transferência de mensagens de entrada
Se você é como nós, esperar que os dados sejam carregados no dapp não é seu passatempo favorito, então estamos felizes em anunciar que o Sistema Neural da Rede (NNS) está lançando otimizações para o Protocolo de Computador da Internet para aumentar a taxa de transferência de consenso.
Essas alterações de protocolo reduziram o consumo de largura de banda e o tempo necessários para a disseminação de blocos, mantendo as propriedades de segurança do ICP; assim, os usuários gastarão mais tempo interagindo com os dapps do ICP de forma mais rápida.
Contexto
O Protocolo de Computador da Internet coordena seus nós de rede, mesmo quando alguns nós se desviam do protocolo, para fornecer serviços de computação descentralizados.
É bem conhecido que o ICP pode hospedar quaisquer aplicações que combinam código e dados, conhecidas como contêineres, que podem processar mensagens de entrada submetidas pelo usuário e interagir com outros contêineres através da troca e execução de mensagens.
Os nós da rede não replicam mais a execução de cada contêiner em todos os nós, mas são divididos em vários fragmentos, chamados de sub-redes, cada uma adotando um protocolo de consenso robusto para garantir a execução e o estado consistente dos contêineres hospedados em seus nós.
O protocolo de consenso é responsável pela criação e verificação de blocos, cada bloco contém um conjunto de mensagens de contêiner, e uma vez que um consenso é alcançado sobre a ordem e o conteúdo desses blocos, os nós podem executar o código do contêiner de maneira determinística e consistente, mantendo a integridade do serviço de computação.
A carga útil do bloco contém mensagens de entrada enviadas pelo usuário para disparar chamadas de contêiner replicadas; após receber mensagens de entrada do usuário, o nó executará uma série de verificações (por exemplo, assinatura, tamanho, tempo de expiração); se essas verificações forem bem-sucedidas, o nó adicionará a mensagem à sua piscina de entrada e transmitirá a mensagem para outros nós na sub-rede usando o protocolo P2P do ICP.
Quando for a vez de um nó criar uma proposta de bloco, esse nó incluirá um conjunto de mensagens de entrada de sua piscina de entrada, e em seguida, esse nó transmitirá essa proposta para seus pares.
No entanto, como a maioria dos pares já possui a maioria dessas mensagens de entrada em sua piscina local, esse processo desperdiça largura de banda.
Outro ponto negativo desse método é que enviar uma proposta com 1000 mensagens de 4KB para todos os pares leva mais tempo do que enviar uma proposta com 1000 hashes.
Supondo que a cópia tenha uma largura de banda mínima sugerida de 300Mbit/s, transmitir uma proposta de bloco contendo uma carga útil de 4MB para todos os pares em uma sub-rede de 13 nós requer: 4MB * (13-1) / 300Mbit/s = 1.28 segundos.
Se cada hash for menor que 50 bytes, a mesma proposta pode ser transmitida para todos os nós a uma velocidade mais de 800 vezes maior; para sub-redes maiores, essas diferenças se acumulam, tornando o impacto ainda maior.
Otimização
Para reduzir o tempo de entrega da proposta e o consumo de largura de banda, o protocolo foi aprimorado para permitir que os nós incluam referências (hashes) a mensagens de entrada nos blocos, em vez de mensagens completas; como os nós de qualquer forma transmitem mensagens de entrada usando o protocolo P2P, as cópias devem ser capazes de reconstruir a proposta do bloco recuperando todas as mensagens de entrada de suas respectivas piscinas de entrada usando referências.
No entanto, algumas mensagens de entrada podem ser perdidas na piscina de entrada local de um nó, o que pode ocorrer devido a condições de rede ruins, piscina cheia, falha do nó ou comportamento malicioso de nós; o nó precisa ter todas as mensagens de entrada da proposta para validar e/ou executar a proposta; para obter as mensagens de entrada perdidas, o nó pode solicitar as mensagens que ainda não possui do nó par que publicou a proposta.
Para aumentar a chance de que todas as mensagens de entrada estejam na piscina de entrada de todos os pares antes de propor um bloco contendo seus hashes, alguns aspectos da implementação da piscina de entrada foram alterados.
Primeiro, os nós agora enviam mensagens de entrada diretamente para pares, em vez de enviar anúncios para pares e esperar que os pares solicitem, economizando pelo menos uma ida e volta, tornando a transmissão de mensagens de entrada para os pares mais rápida.
Além disso, a gestão do tamanho da piscina de entrada também foi aprimorada; até agora, há limites globais para o número de mensagens e seu tamanho total que podem ocupar a piscina, e se esses limites forem excedidos, o nó rejeitará qualquer mensagem de entrada transmitida por pares.
Portanto, sob carga muito alta, os nós em uma única sub-rede podem acabar com piscinas de entrada quase não intersecadas; nesse caso, para cada proposta de bloco, todos os nós devem solicitar todas as mensagens do criador do bloco, o que aumenta a latência e reduz a taxa de transferência.
Para resolver esse problema, o limite global foi substituído pelo limite de cada nó par, até agora, enquanto houver espaço na piscina de entrada para acomodar esse nó, ele aceitará mensagens de entrada desse nó.
Uma vez que em qualquer momento dado, cópias honestas transmitirão mensagens de entrada para cada limite par, podemos ter alta confiança de que, mesmo sob alta carga, os nós na mesma sub-rede terão piscinas de entrada altamente intersecadas.
Para minimizar as alterações no protocolo geral, um novo componente foi adicionado entre o P2P e o consenso, responsável por remover mensagens de entrada da proposta do remetente e re-adicioná-las ao destinatário, enquanto o restante da lógica do P2P e do consenso permanece inalterado.
Avaliação de desempenho
Para ilustrar o impacto da otimização, realizamos experimentos em uma sub-rede de teste com 13 nós, aplicando um RTT de 300ms entre os nós e limitando a largura de banda a 300 Mbps.
Experimentos mostram que a taxa de transferência aumentou de 2MB/s para 6MB/s transmitindo muitas pequenas mensagens (cerca de 4KB).
Da mesma forma, em nossos experimentos com grandes mensagens (um pouco menos de 2MB), a taxa de transferência aumentou de 2MB/s para 7MB/s.
Observe que em nossos experimentos nos concentramos apenas na taxa de transferência de consenso, e os contêineres que enviamos mensagens não estavam realizando nenhum trabalho significativo.
Abaixo está um gráfico mostrando a taxa de transferência dos experimentos acima:
Também realizamos experimentos que mostram que a adesão de nós a sub-rede (catching up) e falhas de nós, bem como sub-redes com muitos contêineres ou muitos nós, tem desempenho pelo menos tão bom quanto antes (e em muitos casos muito melhor).
Conclusão
Essas mudanças nos protocolos melhoraram a experiência do usuário do computador da internet, estabelecendo uma base para mudanças adicionais que lidam com mais e maiores mensagens.
Essas mudanças foram habilitadas em algumas sub-redes da mainnet, onde você pode experimentar pessoalmente como esses benefícios se aplicam a condições reais de rede e cargas variáveis, e não apenas a pequenos experimentos usando padrões de tráfego sintético.
Por favor, nos diga seu feedback; você pode compartilhar suas ideias a qualquer momento no canal DFINITY Developers X e no fórum de desenvolvedores, e continue a acompanhar mais atualizações sobre o roteiro técnico que será lançado em breve.
Conteúdo IC que você se importa
Avanços tecnológicos | Informações do projeto | Atividades globais
Siga o canal Binance do IC
Mantenha-se atualizado
