A pergunta favorita de qualquer não técnico sobre um sistema distribuído é "Quantos tps há na sua blockchain?" No entanto, o número mencionado em resposta geralmente tem pouco a ver com o que o questionador gostaria de saber. Na verdade, ele queria perguntar "sua blockchain atende às minhas necessidades empresariais?", e essas necessidades não são um único número, mas sim uma série de condições — incluindo a resiliência da rede, requisitos de finalização, tamanhos, natureza das transações e muitos outros parâmetros. Portanto, a resposta à pergunta "quantos tps" é improvável que seja simples e quase nunca completa. Um sistema distribuído com dezenas e centenas de nós realizando cálculos bastante complexos pode existir em uma enorme variedade de estados, relacionados ao estado da rede, ao conteúdo da blockchain, a falhas técnicas, problemas econômicos, ataques à rede e várias outras razões. As etapas nas quais problemas de desempenho podem ocorrer diferem dos serviços tradicionais, e o servidor da rede blockchain é um serviço de rede que combina a funcionalidade de banco de dados, servidor web e cliente torrent, tornando-o extremamente complexo em termos 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 centralizado. Por isso, gostaria de destacar aspectos importantes de desempenho e resiliência das redes descentralizadas, abordagens para medi-los e identificar gargalos. Vamos examinar diversos problemas de desempenho que limitam a velocidade de serviço para os usuários de blockchains e notar as características que são peculiares a esse tipo de software.

Etapas de solicitação de serviço pelo cliente da blockchain

Para falar honestamente sobre a qualidade de qualquer serviço mais ou menos complexo, é necessário considerar não apenas as médias, mas também os valores máximos/mínimos, medianas e percentis. Teoricamente, pode-se falar de 1000 tps em algum blockchain, mas se 900 transações forem realizadas com grande rapidez, enquanto 100 "congelaram" por alguns segundos, a média de tempo coletada de todas as transações não é uma métrica totalmente honesta para o cliente que não conseguiu concluir o negócio em poucos segundos. As "cavernas temporais" causadas por rodadas de consenso perdidas ou divisão da rede podem prejudicar muito um serviço que apresentou excelente desempenho em testes.

Para identificar esses bottlenecks, é necessário ter uma boa compreensão das etapas em que um blockchain real pode enfrentar dificuldades ao atender os usuários. Vamos descrever o ciclo de entrega e o processamento de transações, bem como a obtenção de um novo estado do blockchain, do qual o cliente pode se certificar de que sua transação foi processada e contabilizada.

a transação é formada no cliente
a transação é assinada no cliente
o cliente escolhe um dos nós e envia sua transação para ele
o cliente se inscreve para atualizações da base de dados de estado do nó, esperando por resultados da execução da sua transação
o nó espalha a transação pela rede p2p
vários ou um BP (produtor de bloco) processam as transações acumuladas, atualizando a base de dados de estado
o BP forma um novo bloco, processando o número necessário de transações
o BP espalha o novo bloco pela rede p2p
o novo bloco é entregue ao nó que o cliente está acessando
o nó atualiza a base de dados de estado
o nó vê a atualização relacionada ao cliente e envia uma notificação sobre a transação para ele

Agora, vamos analisar esses estágios em mais detalhes e descrever os potenciais problemas de desempenho em cada um deles. Ao contrário dos sistemas centralizados, também vamos considerar a execução do código nos clientes da rede. Com frequência, ao medir tps, o tempo de processamento das transações é coletado a partir dos nós, e não dos clientes — o que não é totalmente justo. Para o cliente, o quão rápido o nó processou sua transação não é relevante; o que realmente importa para ele é o momento em que a informação confiável sobre essa transação, incluída na blockchain, se torna disponível. Essa métrica é, na essência, o tempo de execução da transação. Isso significa que diferentes clientes, mesmo enviando a mesma transação, podem obter tempos completamente diferentes, dependendo do canal, da carga e da proximidade do nó, entre outros fatores. Portanto, é absolutamente necessário medir esse tempo nos clientes, uma vez que esse é o parâmetro que precisa ser otimizado.

Preparação da transação no lado do cliente

Começaremos com os primeiros dois pontos: a transação é formada e assinada pelo cliente. Surpreendentemente, isso pode ser também um gargalo de desempenho da blockchain do ponto de vista do cliente. Isso é incomum para serviços centralizados, que realizam todos os cálculos e operações com dados por conta própria, enquanto o cliente apenas prepara uma solicitação curta, capaz de requisitar um grande volume de dados ou cálculos, recebendo o resultado pronto. Nas blockchains, o código do cliente se torna cada vez mais potente, e o núcleo da blockchain se torna cada vez mais leve, enquanto tarefas computacionais massivas tendem a ser entregues ao software do cliente. Existem clientes nas blockchains que podem levar um bom tempo para preparar uma única transação (estou falando sobre várias provas Merkle, provas sucintas, assinaturas threshold e outras operações complexas do lado do cliente). Um bom exemplo de verificação leve on-chain e preparação pesada da transação no cliente é a prova de pertencimento a uma lista baseada em Merkle-tree, aqui está. artigo.

Também não devemos esquecer que o código do cliente não apenas envia transações para a blockchain, mas primeiro solicita o estado da blockchain — e essa atividade pode impactar a carga da rede e dos nodos da blockchain. Portanto, ao realizar medições, é sensato emular o comportamento do código do cliente da forma mais completa possível. Mesmo que em sua blockchain existam apenas clientes leves que assinam digitalmente uma transação simples de transferência de algum ativo, a cada ano a quantidade de cálculos massivos no cliente ainda aumenta, os algoritmos criptográficos se fortalecem e essa parte do processamento pode se tornar um gargalo significativo no futuro. Por isso, tenha cuidado e não deixe passar a situação em que, em uma transação que leva 3,5s, 2,5s são gastos na preparação e assinatura da transação, e 1,0s no envio para a rede e aguardando uma resposta. Para avaliar os riscos de surgimento desse gargalo, é necessário coletar métricas das máquinas dos clientes, e não apenas dos nodos da blockchain.

Envio de transação e monitoramento do seu status

A próxima etapa é enviar a transação para o nodo da blockchain escolhido e obter o status de sua aceitação no pool de transações. Esta etapa é semelhante a uma solicitação comum a um banco de dados, o nodo deve registrar a transação no pool e começar a disseminar informações sobre ela através da rede P2P. A abordagem para avaliar o desempenho aqui é semelhante à avaliação do funcionamento de microserviços tradicionais de Web API, sendo que as próprias transações nas blockchains podem ser atualizadas, mudando ativamente de status. Na verdade, a atualização das informações sobre uma transação pode ocorrer várias vezes em algumas blockchains, por exemplo, ao alternar entre forks da cadeia ou quando os BP informam sobre a intenção de incluir a transação em um bloco. Restrições sobre o tamanho desse pool e o número de transações nele podem influenciar o desempenho da blockchain. Se o pool de transações estiver cheio até o tamanho máximo possível, ou não couber na memória RAM, o desempenho da rede pode cair drasticamente. As blockchains não têm meios centralizados de proteção contra o fluxo de mensagens de lixo e, se a blockchain suporta transações de grande volume e baixas taxas, isso pode levar ao transbordo do pool de transações — este é mais um potencial gargalo de desempenho.

Nos blockchains, um cliente envia uma transação para qualquer nó do blockchain que preferir. O hash da transação é geralmente conhecido pelo cliente antes do envio, então tudo o que ele precisa fazer é estabelecer uma conexão e aguardar a alteração do estado do blockchain, que incluirá sua transação. Vale notar que ao medir 'tps', podem-se obter resultados bastante diferentes dependendo do método de conexão ao nó do blockchain. Isso pode ser uma RPC HTTP comum ou WebSocket, que permite implementar o padrão 'subscribe'. No segundo caso, o cliente receberá a notificação mais cedo, e o nó gastará menos recursos (principalmente memória e tráfego) respondendo ao estado da transação. Portanto, ao medir 'tps', deve-se considerar o método de conexão dos clientes aos nós. Assim, para avaliar os riscos de surgimento desse bottleneck, o benchmark do blockchain deve ser capaz de emular clientes tanto com solicitações WebSocket quanto com RPC HTTP, em proporções que correspondam a redes reais, além de variar a natureza e o tamanho das transações.

Para avaliar os riscos de surgimento desse bottleneck, também é necessário coletar métricas das máquinas dos clientes, e não apenas dos nós do blockchain.

Transferência de transações e blocos pela rede p2p

Nos blockchains, para a transferência entre os participantes de transações e blocos, utiliza-se uma rede peer-to-peer (p2p). As transações se espalham pela rede, começando a partir de um dos nós, até alcançarem os peers-produtores de blocos, que empacotam as transações em blocos e, através do mesmo p2p, distribuem novos blocos para todos os nós da rede. A base da maioria das redes p2p modernas são diferentes modificações do protocolo Kademlia. Aqui uma boa visão geral deste protocolo, e aqui — um artigo com várias medições na rede BitTorrent, que pode ser entendido — que este tipo de rede é mais complexo e menos previsível do que uma rede de serviço centralizado rigidamente configurada. Além disso, aqui um artigo sobre a medição de várias métricas interessantes para nós Ethereum.

Em resumo, cada peer nessas redes mantém sua própria lista dinâmica de outros peers, de quem solicita blocos de informações endereçados por seu conteúdo. Ao receber uma solicitação, o peer pode devolver a informação necessária ou passar o pedido para o próximo peer pseudo-aleatório da lista, e ao receber uma resposta, a envia de volta ao solicitante e a cacheia por um tempo, oferecendo esse bloco de informação mais rapidamente na próxima vez. Assim, informações populares ficam armazenadas em muitos caches de diversos peers, enquanto as não populares são gradualmente eliminadas. Os peers controlam quem transferiu quantas informações e a rede tenta estimular os compartilhadores ativos, elevando suas classificações e garantindo-lhes um nível de serviço mais alto, automaticamente eliminando participantes inativos das listas de peers.

Assim, a transação agora precisa ser propagada pela rede para que os produtores de bloco a vejam e a incluam em um bloco. O nó ativamente "distribui" a nova transação para todos interessados e escuta a rede, aguardando um bloco, no índice do qual a transação desejada aparecerá, para notificar o cliente aguardando. O tempo que a rede leva para trocar informações sobre novas transações e blocos em redes p2p depende de uma grande quantidade de fatores: o número de nós honestos e ativos nas proximidades (do ponto de vista da rede), a "temperatura" dos caches desses nós, o tamanho dos blocos, das transações, a natureza das mudanças, a geografia da rede, o número de nós e muitos outros fatores. Medir métricas de desempenho em tais redes é uma tarefa complexa, exigindo a avaliação simultânea do tempo de processamento de solicitações tanto em clientes quanto em peers (nós da blockchain). Problemas em qualquer um dos mecanismos p2p, substituição e cache de dados incorretos, gestão ineficiente das listas de peers ativos e muitos outros fatores podem causar atrasos, afetando a eficiência de toda a rede como um todo, e esse gargalo é o mais complicado de analisar, testar e interpretar resultados.

Processamento da cadeia de blocos e atualização do banco de dados de estados

A parte mais importante do funcionamento de um blockchain é o algoritmo de consenso, sua aplicação a novos blocos recebidos da rede e o processamento das transações com registro dos resultados no banco de dados de estado. A adição de um novo bloco à cadeia e a seleção subsequente da cadeia principal devem ocorrer o mais rapidamente possível. No entanto, na vida real, "deve" não significa "funciona", e, por exemplo, podemos imaginar uma situação em que duas longas cadeias competidoras alternam constantemente entre si, alterando os metadados de milhares de transações no pool a cada alternância e realizando constantes reverterções no estado do banco de dados. Esta etapa, em termos de identificação de gargalos, é mais simples do que a camada p2p da rede, pois a execução das transações e o algoritmo de consenso são estritamente determinísticos, e é mais fácil medir algo aqui.
O principal é não confundir a degradação aleatória do desempenho desta etapa com problemas de rede — os nós entregam blocos e informações sobre a cadeia principal mais lentamente, e para o cliente externo isso pode parecer uma rede lenta, embora o problema esteja em outro lugar.

Para otimizar o desempenho nesta etapa, é útil coletar e monitorar métricas diretamente dos nós e incluir aquelas que dizem respeito à atualização do banco de dados de estado: o número de blocos processados no nó, seu tamanho, o número de transações, a quantidade de alternâncias entre forks de cadeias, 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 permitirá distinguir problemas de rede de erros nos algoritmos de processamento das cadeias.

A máquina virtual que processa transações pode ser uma fonte de informação útil para otimizar o funcionamento do blockchain. A quantidade de alocações de memória, o número de instruções de leitura/escrita e outras métricas relacionadas à eficiência da execução do código dos contratos podem fornecer muitas informações valiosas para os desenvolvedores. Ao mesmo tempo, contratos inteligentes são programas, e em teoria, eles podem consumir qualquer um dos recursos: cpu/memória/rede/armazenamento, então o processamento de transações é uma etapa bastante indefinida, que também muda muito ao longo das versões e na alteração do código dos contratos. Portanto, métricas relacionadas ao processamento de transações também são necessárias para uma otimização eficaz do desempenho do blockchain.

Recebendo a notificação do cliente sobre a ativação da transação na blockchain

Esta é a etapa final para o recebimento do serviço de blockchain pelo cliente. Comparado a outras etapas, aqui não há grandes custos adicionais, mas ainda assim é importante considerar a possibilidade de o cliente receber uma resposta volumosa da node (por exemplo, um contrato inteligente que retorna um array de dados). De qualquer forma, este momento é o mais importante para quem pergunta "qual é a quantidade de tps na sua blockchain?", pois é neste momento que é registrado o tempo de recebimento do serviço.

Neste ponto, deve ser enviado o tempo total que o cliente teve que esperar pela resposta da blockchain. Este é o tempo que o usuário aguardará a confirmação em seu aplicativo, e a otimização desse tempo é a principal tarefa dos desenvolvedores.

Conclusão

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

transformações criptográficas, construção de provas
rede peer-to-peer, replicação de transações e blocos
processamento de transações, execução de contratos inteligentes
aplicação de mudanças na blockchain ao state database, atualização de dados sobre transações e blocos
consultas read-only ao state database, API da node de blockchain, serviços de assinatura

De fato, os requisitos técnicos para nodes de blockchains modernas são extremamente rigorosos — são necessários CPUs rápidos para criptografia, uma grande quantidade de memória RAM para armazenar e acessar rapidamente o state database, interação de rede utilizando um grande número de conexões abertas simultaneamente e armazenamento amplo. Esses altos requisitos e a abundância de diferentes tipos de operações inevitavelmente resultam em insuficiência de recursos nas nodes, e então, qualquer uma das etapas acima pode se tornar um gargalo para o desempenho geral da rede.

Ao desenvolver e avaliar o desempenho de blockchains, você precisará levar tudo isso em consideração. Para isso, é necessário coletar e analisar métricas simultaneamente de clientes e nós da rede, buscar correlações entre elas, avaliar o tempo de fornecimento de serviços aos clientes, ter em mente todos os recursos principais: cpu/memória/rede/armazenamento, entender como eles são utilizados e como influenciam uns aos outros. Tudo isso torna a comparação de velocidades de diferentes blockchains em termos de "quantos TPS" uma tarefa extremamente ingrata, pois existe uma enorme quantidade 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 distintas, mas em blockchains, devido a redes p2p, máquinas virtuais, processos de contratos, economias internas, o número de graus de liberdade é muito maior, o que torna o teste mesmo em alguns servidores não representativo e mostrando apenas valores extremamente aproximados, quase sem relação com a realidade.

Portanto, ao desenvolver no núcleo do blockchain, para avaliar o desempenho e responder à pergunta "melhorou em comparação com a última vez?", usamos um software bastante complexo que orquestra a execução do blockchain com dezenas de nós e a execução automática de benchmarks e coleta de métricas, sem essas informações é extremamente difícil depurar protocolos que operam com múltiplos participantes.

Assim, ao receber a pergunta "quantos TPS no seu blockchain?", ofereça ao interlocutor um chá e pergunte se ele está disposto a se debruçar sobre uma dezena de gráficos, bem como ouvir sobre os três principais problemas de desempenho dos blockchains e suas propostas para solucioná-los...

Fonte: habr.com