Uma pergunta favorita sobre qualquer sistema distribuído feita por uma pessoa não técnica é “Quantos tps existem em seu blockchain?” Contudo, o número dado na resposta geralmente tem pouco em comum com o que o questionador gostaria de ouvir. Na verdade, ele queria perguntar “será que seu blockchain atenderá aos meus requisitos de negócios?” e esses requisitos não são um número, mas muitas condições - aqui estão tolerância a falhas de rede, requisitos de finalidade, tamanhos, natureza das transações e muitos outros parâmetros. Portanto, é improvável que a resposta à pergunta “quantas tps” seja simples e quase nunca completa. Um sistema distribuído com dezenas ou centenas de nós realizando cálculos bastante complexos pode estar em um grande número de estados diferentes relacionados ao estado da rede, ao conteúdo do blockchain, a falhas técnicas, a problemas econômicos, a ataques à rede e muitos outros motivos. . Os estágios em que os problemas de desempenho são possíveis diferem dos serviços tradicionais, e um servidor de rede blockchain é um serviço de rede que combina a funcionalidade de um banco de dados, servidor web e cliente torrent, o que o torna extremamente complexo em termos de perfil de carga em todos os subsistemas : processador, memória, rede, armazenamento

Acontece que redes descentralizadas e blockchains são softwares bastante específicos e incomuns para desenvolvedores de software centralizados. Portanto, gostaria de destacar aspectos importantes do desempenho e da sustentabilidade das redes descentralizadas, abordagens para medi-las e encontrar gargalos. Veremos vários problemas de desempenho que limitam a velocidade de prestação de serviços aos usuários de blockchain e observaremos os recursos característicos desse tipo de software.

Etapas de uma solicitação de serviço por um cliente blockchain

Para falar honestamente sobre a qualidade de qualquer serviço mais ou menos complexo, é necessário levar em consideração não apenas valores médios, mas também máximo/mínimo, medianas, percentis. Teoricamente, podemos falar de 1000 tps em alguma blockchain, mas se 900 transações foram concluídas com enorme velocidade e 100 ficaram “presas” por alguns segundos, então o tempo médio coletado em todas as transações não é uma métrica completamente justa para um cliente que não consegui concluir a transação em alguns segundos. “Buracos” temporários causados por rodadas de consenso perdidas ou divisões de rede podem arruinar enormemente um serviço que mostrou excelente desempenho em bancos de testes.

Para identificar tais gargalos, é necessário ter um bom entendimento dos estágios em que uma blockchain real pode ter dificuldade em atender os usuários. Vamos descrever o ciclo de entrega e processamento de uma transação, bem como a obtenção de um novo estado do blockchain, a partir do qual o cliente poderá verificar se sua transação foi processada e contabilizada.

a transação é formada no cliente
a transação é assinada no cliente
o cliente seleciona um dos nós e envia sua transação para ele
o cliente assina atualizações no banco de dados de estado do nó, aguardando o aparecimento dos resultados de sua transação
o nó distribui a transação pela rede p2p
vários ou um BP (produtor de bloco) processa transações acumuladas, atualizando o banco de dados estadual
BP forma um novo bloco após processar o número necessário de transações
BP distribui um novo bloco pela rede p2p
o novo bloco é entregue ao nó que o cliente está acessando
nó atualiza banco de dados de estado
o nó vê a atualização referente ao cliente e envia a ele uma notificação de transação

Agora vamos examinar mais de perto esses estágios e descrever os possíveis problemas de desempenho em cada estágio. Ao contrário dos sistemas centralizados, também consideraremos a execução de código em clientes de rede. Muitas vezes, ao medir o TPS, o tempo de processamento da transação é coletado dos nós, e não do cliente - isso não é totalmente justo. O cliente não se importa com a rapidez com que o nó processou sua transação, o mais importante para ele é o momento em que informações confiáveis sobre essa transação incluída no blockchain ficam disponíveis para ele. É essa métrica que representa essencialmente o tempo de execução da transação. Isso significa que clientes diferentes, mesmo enviando a mesma transação, podem receber tempos completamente diferentes, que dependem do canal, carga e proximidade do nó, etc. Portanto é absolutamente necessário mensurar esse tempo nos clientes, pois este é o parâmetro que precisa ser otimizado.

Preparando uma transação no lado do cliente

Comecemos pelos dois primeiros pontos: a transação é formada e assinada pelo cliente. Curiosamente, isso também pode ser um gargalo no desempenho do blockchain do ponto de vista do cliente. Isso é incomum para serviços centralizados, que assumem todos os cálculos e operações com dados, e o cliente simplesmente prepara uma pequena solicitação que pode solicitar uma grande quantidade de dados ou cálculos, obtendo um resultado pronto. Em blockchains, o código do cliente torna-se cada vez mais poderoso, e o núcleo do blockchain torna-se cada vez mais leve, e tarefas computacionais massivas geralmente são transferidas para o software cliente. Em blockchains, existem clientes que podem preparar uma transação por um longo tempo (estou falando de várias provas merkle, provas sucintas, assinaturas de limite e outras operações complexas do lado do cliente). Um bom exemplo de verificação fácil na cadeia e preparação pesada de uma transação no cliente é a prova de adesão a uma lista baseada na Merkle-tree, aqui artigo.

Além disso, não esqueça que o código do cliente não apenas envia transações para o blockchain, mas primeiro consulta o estado do blockchain - e essa atividade pode afetar o congestionamento da rede e dos nós do blockchain. Portanto, ao fazer medições, seria razoável emular o comportamento do código do cliente da forma mais completa possível. Mesmo que em seu blockchain existam clientes leves comuns que colocam uma assinatura digital regular na transação mais simples para transferir algum ativo, a cada ano há cálculos ainda mais massivos no cliente, os algoritmos de criptografia estão ficando mais fortes e esta parte do processamento pode transformar-se num gargalo significativo no futuro. Portanto, tome cuidado e não perca a situação em que, em uma transação com duração de 3.5s, são gastos 2.5s na preparação e assinatura da transação e 1.0s no envio para a rede e aguardando resposta. Para avaliar os riscos desse gargalo, é necessário coletar métricas de máquinas clientes, e não apenas de nós de blockchain.

Enviando uma transação e monitorando seu status

A próxima etapa é enviar a transação para o nó blockchain selecionado e receber o status de aceitação no pool de transações. Esta etapa é semelhante a um acesso regular ao banco de dados; o nó deve registrar a transação no pool e começar a distribuir informações sobre ela através da rede p2p. A abordagem para avaliar o desempenho aqui é semelhante à avaliação do desempenho dos microsserviços tradicionais da API da Web, e as próprias transações em blockchains podem ser atualizadas e alterar ativamente seu status. Em geral, a atualização de informações de transação em alguns blockchains pode ocorrer diversas vezes, por exemplo, ao alternar entre bifurcações de cadeia ou quando os BPs anunciam sua intenção de incluir uma transação em um bloco. Limites no tamanho desse pool e no número de transações nele podem afetar o desempenho do blockchain. Se o pool de transações estiver cheio até o tamanho máximo possível ou não couber na RAM, o desempenho da rede poderá cair drasticamente. As blockchains não têm meios centralizados de proteção contra uma enxurrada de mensagens indesejadas e, se a blockchain suportar transações de alto volume e taxas baixas, isso pode causar o transbordamento do pool de transações – outro potencial gargalo de desempenho.

Em blockchains, o cliente envia uma transação para qualquer nó de blockchain que desejar, o hash da transação geralmente é conhecido pelo cliente antes do envio, então tudo que ele precisa fazer é conseguir a conexão e, após a transmissão, aguardar a mudança do blockchain. seu estado, possibilitando sua transação. Observe que medindo “tps” você pode obter resultados completamente diferentes para diferentes métodos de conexão a um nó blockchain. Pode ser um HTTP RPC normal ou um WebSocket que permite implementar o padrão “subscribe”. No segundo caso, o cliente receberá uma notificação mais cedo e o nó gastará menos recursos (principalmente memória e tráfego) em respostas sobre o status da transação. Portanto, ao medir “tps” é necessário levar em consideração a forma como os clientes se conectam aos nós. Portanto, para avaliar os riscos desse gargalo, o blockchain de referência deve ser capaz de emular clientes tanto com solicitações WebSocket quanto HTTP RPC, em proporções correspondentes às redes reais, bem como alterar a natureza das transações e seu tamanho.

Para avaliar os riscos desse gargalo, você também precisa coletar métricas de máquinas clientes, e não apenas de nós de blockchain.

Transmissão de transações e blocos via rede p2p

Em blockchains, a rede peer-to-peer (p2p) é usada para transferir transações e blocos entre participantes. As transações se espalham pela rede, começando em um dos nós, até chegarem aos pares produtores de blocos, que empacotam as transações em blocos e, usando o mesmo p2p, distribuem novos blocos para todos os nós da rede. A base da maioria das redes p2p modernas são várias modificações do protocolo Kademlia. aqui é um bom resumo deste protocolo, e aqui - um artigo com diversas medidas na rede BitTorrent, a partir do qual se pode compreender que este tipo de rede é mais complexa e menos previsível do que uma rede rigidamente configurada de um serviço centralizado. Também, aqui artigo sobre como medir várias métricas interessantes para nós Ethereum.

Em resumo, cada peer em tais redes mantém a sua própria lista dinâmica de outros peers a partir dos quais solicita blocos de informação que são endereçados por conteúdo. Quando um par recebe uma solicitação, ele fornece as informações necessárias ou passa a solicitação para o próximo par pseudo-aleatório da lista e, tendo recebido uma resposta, ele a transfere para o solicitante e a armazena em cache por um tempo, dando isso bloco de informações mais cedo na próxima vez. Assim, as informações populares acabam em um grande número de caches de um grande número de pares, e as informações impopulares são gradualmente substituídas. Os pares mantêm registos de quem transferiu quanta informação para quem, e a rede tenta estimular os distribuidores activos, aumentando as suas classificações e proporcionando-lhes um nível de serviço mais elevado, deslocando automaticamente os participantes inactivos das listas de pares.

Portanto, a transação agora precisa ser distribuída por toda a rede para que os produtores de blocos possam vê-la e incluí-la no bloco. O nó “distribui” ativamente uma nova transação para todos e escuta a rede, aguardando um bloco em cujo índice aparecerá a transação necessária para notificar o cliente em espera. O tempo que a rede leva para transferir informações sobre novas transações e blocos entre si em redes p2p depende de um grande número de fatores: o número de nós honestos trabalhando próximos (do ponto de vista da rede), o “quente- up” dos caches desses nós, o tamanho dos blocos, as transações, a natureza das mudanças, a geografia da rede, o número de nós e muitos outros fatores. Medições complexas de métricas de desempenho em tais redes são uma questão complexa; é necessário avaliar simultaneamente o tempo de processamento de solicitações tanto em clientes quanto em pares (nós blockchain). Problemas em qualquer um dos mecanismos p2p, remoção e cache incorretos de dados, gerenciamento ineficaz de listas de peers ativos e muitos outros fatores podem causar atrasos que afetam a eficiência de toda a rede como um todo, sendo esse gargalo o mais difícil de analisar. , teste e interpretação dos resultados.

Processamento de blockchain e atualização de banco de dados de estado

A parte mais importante do blockchain é o algoritmo de consenso, sua aplicação aos novos blocos recebidos da rede e o processamento das transações com registro dos resultados no banco de dados estadual. Adicionar um novo bloco à cadeia e depois selecionar a cadeia principal deve funcionar o mais rápido possível. No entanto, na vida real, “deveria” não significa “funciona”, e pode-se, por exemplo, imaginar uma situação em que duas longas cadeias concorrentes estão constantemente alternando entre si, alterando os metadados de milhares de transações no pool a cada troca. e revertendo constantemente o banco de dados de estado. Esta etapa, em termos de definição do gargalo, é mais simples que a camada de rede p2p, pois a execução da transação e o algoritmo de consenso são estritamente determinísticos e é mais fácil medir qualquer coisa aqui.
O principal é não confundir degradação aleatória no desempenho desta etapa com problemas de rede - os nós são mais lentos na entrega de blocos e informações sobre a cadeia principal, e para um cliente externo isso pode parecer uma rede lenta, embora o problema esteja em um lugar completamente diferente.

Para otimizar o desempenho nesta fase, é útil coletar e monitorar métricas dos próprios nós, e incluir nelas aquelas relacionadas à atualização do banco de dados de estado: o número de blocos processados no nó, seu tamanho, o número de transações, o número de alternâncias entre bifurcações da cadeia, o número de blocos inválidos, o tempo de operação da máquina virtual, o tempo de confirmação de dados, etc. Isso evitará que problemas de rede sejam confundidos com erros em algoritmos de processamento em cadeia.

Uma máquina virtual processando transações pode ser uma fonte útil de informações que pode otimizar a operação do blockchain. O número de alocações de memória, o número de instruções de leitura/gravação e outras métricas relacionadas à eficiência da execução do código do contrato podem fornecer muitas informações úteis aos desenvolvedores. Ao mesmo tempo, os contratos inteligentes são programas, o que significa que em teoria podem consumir qualquer um dos recursos: CPU/memória/rede/armazenamento, portanto o processamento de transações é uma etapa bastante incerta, que, além disso, muda muito ao transitar entre versões e ao alterar códigos de contrato. Portanto, métricas relacionadas ao processamento de transações também são necessárias para otimizar efetivamente o desempenho do blockchain.

Recebimento pelo cliente de notificação sobre a inclusão de uma transação no blockchain

Esta é a etapa final do cliente blockchain receber o serviço; em comparação com outras etapas, não há grandes custos indiretos, mas ainda vale a pena considerar a possibilidade de o cliente receber uma resposta volumosa do nó (por exemplo, um contrato inteligente retornando uma matriz de dados). De qualquer forma, este ponto é o mais importante para quem fez a pergunta “quantos tps tem na sua blockchain?”, pois Neste momento é registrado o horário de recebimento do atendimento.

Neste local sempre há o envio do tempo integral que o cliente teve que gastar aguardando uma resposta do blockchain; é esse tempo que o usuário aguardará a confirmação em sua aplicação, e é a sua otimização que é o principal tarefa dos desenvolvedores.

Conclusão

Como resultado, podemos descrever os tipos de operações realizadas em blockchains e dividi-las em diversas categorias:

transformações criptográficas, construção de provas
rede peer-to-peer, transação e replicação de blocos
processamento de transações, execução de contratos inteligentes
aplicando alterações no blockchain ao banco de dados estadual, atualizando dados sobre transações e blocos
solicitações somente leitura para banco de dados estadual, API de nó blockchain, serviços de assinatura

Em geral, os requisitos técnicos para nós de blockchain modernos são extremamente sérios - CPUs rápidas para criptografia, uma grande quantidade de RAM para armazenar e acessar rapidamente o banco de dados de estado, interação de rede usando um grande número de conexões abertas simultaneamente e grande armazenamento. Esses requisitos elevados e a abundância de diferentes tipos de operações levam inevitavelmente ao fato de que os nós podem não ter recursos suficientes e, então, qualquer um dos estágios discutidos acima pode se tornar outro gargalo para o desempenho geral da rede.

Ao projetar e avaliar o desempenho de blockchains, você deverá levar todos esses pontos em consideração. Para fazer isso, você precisa coletar e analisar métricas simultaneamente de clientes e nós de rede, procurar correlações entre eles, estimar o tempo que leva para fornecer serviços aos clientes, levar em consideração todos os recursos principais: cpu/memória/rede/armazenamento , entender como eles são usados e influenciam uns aos outros. Tudo isso torna a comparação das velocidades de diferentes blockchains na forma de “quantos TPS” uma tarefa extremamente ingrata, uma vez que existe um grande número de configurações e estados diferentes. Em grandes sistemas centralizados, clusters de centenas de servidores, esses problemas também são complexos e também exigem a coleta de um grande número de métricas diferentes, mas em blockchains, devido às redes p2p, às máquinas virtuais que processam contratos, às economias internas, ao número de graus de liberdade é muito maior, o que faz com que o teste mesmo em vários servidores, seja não indicativo e mostre apenas valores extremamente aproximados que quase não têm ligação com a realidade.

Portanto, ao desenvolver no núcleo do blockchain, para avaliar o desempenho e responder à pergunta “melhorou em relação à última vez?” usamos um software bastante complexo que orquestra o lançamento de um blockchain com dezenas de nós e lança automaticamente um benchmark e coleta métricas ; sem essas informações é extremamente difícil depurar protocolos que funcionam com múltiplos participantes.

Então, quando você receber a pergunta “quantos TPS tem na sua blockchain?”, ofereça um chá ao seu interlocutor e pergunte se ele está pronto para olhar uma dezena de gráficos e também ouvir todas as três caixas de problemas de desempenho da blockchain e suas sugestões para resolvendo-os...

Fonte: habr.com

Quantos TPS existem no seu blockchain?