Existem muitas métricas relacionadas à lógica e qualidade da blockchain. Eles ajudam a identificar gargalos no código e a encontrar problemas lógicos e de otimização no consenso e nos algoritmos finais em blockchains. Qualquer desenvolvimento de sistemas distribuídos, incluindo blockchains, requer uma análise do trabalho de muitos nós ao mesmo tempo. Eles permitem que a equipe do projeto monitore o estado de toda a rede blockchain, veja problemas com nós individuais, detecte a ocorrência de ataques de DoS na rede e muito mais. Vejamos os principais. Vamos mergulhar.
"Transações por segundo"
No caso de sistemas distribuídos, o TPS é um número muito sombrio e ambíguo, que nem sempre reflete a qualidade real do serviço prestado aos usuários. As medições de TPS chegaram até nós a partir de bancos de dados distribuídos. Os TPS nos bancos de dados são padronizados para as transações de teste ou seus conjuntos (alguns INSERT, alguns UPDATE, tantos DELETEs no contexto de SELECT constante) para uma configuração de cluster codificada ou mesmo na mesma máquina. Essas métricas geralmente fornecem apenas estimativas aproximadas do desempenho de bancos de dados ou blockchains distribuídos, pois o tempo de processamento da transação pode variar bastante, dependendo de muitos fatores.
Bancos de dados orientados a consistência (consulte “Teorema do CAP”) não confirmam a transação até receberem um número suficiente de confirmações de outros nós e isso é lento. E os bancos de dados orientados à disponibilidade consideram uma transação que foi simplesmente gravada em disco com êxito. Eles imediatamente fornecem dados atualizados ao cliente e são muito rápidos (embora, no futuro, essa transação possa ser revertida). Além disso, se as transações usadas no benchmark atualizarem apenas uma célula com dados, o TPS obviamente será maior do que nos casos em que as transações possam afetar muitas células e bloquear uma à outra. Os algoritmos para trabalhar com esses bloqueios em cada banco de dados são implementados de maneira própria - é por isso que não vemos "competições TPS" entre Oracle, MSSQL, PostgreSQL, por um lado, e MongoDB, Redis, Tarantool, por outro - esses são mecanismos internos muito diferentes e tarefas diferentes .
Na minha opinião, "medir o TPS" da blockchain significa fazer uma gama completa de medidas de seu desempenho:
- em condições repetíveis
- com um número próximo da realidade de validadores de bloco
- usando vários tipos de transações:
- típico da blockchain estudada (por exemplo, transfer () da principal criptomoeda)
- carregando subsistema de armazenamento (uma grande quantidade de mudanças de cada transação)
- carregando largura de banda (grande volume de transações)
- Carregamento da CPU (no caso de grandes transformações ou cálculos de criptografia)
Para falar sobre as “transações por segundo”, você precisa descrever todas as condições (o número de validadores, sua distribuição geográfica, nível de perda de pacotes etc.) e descrever a lógica do benchmarking. Em blockchains, simplesmente rolar uma transação para um banco de dados interno não significa sua aceitação por consenso. Por exemplo, no caso de Prova de Trabalho, estatisticamente, as transações nunca são concluídas e, se uma transação for incluída em um bloco em uma máquina, isso não significa que será aceita por toda a rede (por exemplo, se outro fork for vencido).
Se o blockchain tiver um algoritmo adicional para garantir a finalização das transações (EOS, Ethereum 2.0, Polkadot usa um consenso com a finalização do GRANDPA), o tempo de processamento pode ser considerado o intervalo entre como o nó "viu" a transação e o próximo bloco finalizado em que essa transação foi realizada. incluído. Assim, mais próximo da realidade, o “TPS” raramente é visto nas promessas do projeto. Naturalmente, eles são mais baixos do que os descritos no White Paper, mas são o mais informativos possível.
Por isso, aviso novamente, muitos significados diferentes podem ser incorporados no termo "TPS". Seja cético e peça detalhes.
Métricas específicas de Blockchain
Tps locais
O número de transações processadas pelo nó e o tempo máximo / médio / min de seu processamento no nó local é muito conveniente para medir, pois as funções que executam essa operação geralmente são explicitamente alocadas no código. Você pode simplesmente medir quanto tempo a transação funcionou, atualizando o banco de dados de estado. Essas transações ainda não podem ser aceitas por consenso, mas já passaram na validação e o nó já pode fornecer dados atualizados ao cliente (supondo que a cadeia de distribuição não apareça).
Essa métrica não é muito honesta: se outra bifurcação da cadeia for escolhida como principal, as estatísticas das transações de reversão também deverão ser revertidas. Mas para testes, isso quase sempre pode ser negligenciado.
Geralmente, este é o número que está escrito em breves relatórios: "nossa blockchain obteve 8.000 tps ontem", pois é fácil de medir - apenas um nó em execução e um script que o carrega são suficientes. Nesse caso, não há atraso na rede, o que torna a rede lenta e chega a um consenso, e a métrica mostra o desempenho do banco de dados do estado sem a influência da rede. Este número não é a largura de banda real da rede blockchain, mas mostra o limite para o qual se esforçará se o consenso e a rede forem rápidos o suficiente.
O resultado de qualquer transação de blockchain são várias atualizações atômicas no armazenamento. Por exemplo, uma transação de pagamento no Bitcoin é a remoção de vários UTXOs antigos (exclusão) e a adição de vários novos UTXOs (inserção), e no Ethereum é a execução de um código de contrato inteligente curto e, novamente, a atualização de vários pares de valores-chave. O número dessas operações de gravação "atômica" pode ser uma excelente métrica que permite identificar gargalos no subsistema de armazenamento e na lógica de transação interna.
Além disso, os nós de blockchain podem ser implementados em várias linguagens de programação - isso é mais confiável. Isso deve ser levado em consideração ao avaliar o desempenho da rede, por exemplo, o nó Ethereum existe nas implementações no Rust and Go. Outras blockchains também procuram ter implementações adicionais para confiabilidade.
Quantidade de blocos produzidos localmente
Essa métrica simples mostra qual validador quantos blocos produzidos. É um produto de consenso e pode ser considerado o principal para avaliar a “utilidade” para uma rede de validadores individuais.
Ganhando dinheiro em cada bloco, os validadores estão interessados na operação e segurança estáveis de suas máquinas. Esse número ajuda a determinar qual dos candidatos validadores é o mais qualificado, protegido e preparado para trabalhar em uma rede pública com os ativos de usuários reais. O valor da métrica pode ser verificado publicamente, basta baixar o blockchain e calcular quem produziu quantos blocos.
Finalidade e último bloqueio irreversível
Em redes com finalidades claramente implementadas (EOS, Ethereum, Tendermint, Polkadot, etc), além do consenso principal e rápido (em que uma assinatura de validador por bloco é suficiente), alguns blocos exigem a coordenação de um grupo de validadores. Esses blocos são considerados finais e o algoritmo de coleta de assinaturas é considerado final. A tarefa da finalidade é garantir que todas as transações incluídas na blockchain antes do bloco finalizado nunca sejam bombeadas e não substituídas por outra bifurcação da cadeia. Essa é uma proteção contra ataques de gasto duplo em redes de prova de participação e uma maneira de, rapidamente, em alguns segundos, retornar uma confirmação confiável de uma transação de criptomoeda para um usuário.
Do ponto de vista do usuário da blockchain, a transação não é concluída no momento em que é aceita pelo nó, mas quando um bloco aparece que finaliza a cadeia em que a transação está localizada. Para finalizar um bloco, os validadores devem recebê-lo em uma rede p2p e trocar assinaturas entre si. É aqui que a velocidade real da blockchain é verificada, porque o usuário está interessado no momento de finalizar o bloco com sua transação, e não apenas em aceitá-lo e gravá-lo no disco de um dos nós.
Os algoritmos de finalidade também diferem, se cruzam e combinam com o principal consenso (leia-se: Casper no Ethereum, Últimos blocos irreversíveis na EOS, GRANDPA no Parity Polkadot e suas modificações, por exemplo, MixBytes RANDPA).
Para redes em que nem todos os blocos são finalizados, uma métrica útil é o atraso do último bloco finalizado em relação ao último bloco atual. Este número mostra como os validadores estão atrasados, concordando com a cadeia correta. Se a diferença for grande, o algoritmo de finalização requer análise e otimização adicionais.
Outras métricas de blockchain
O restante das métricas geralmente depende muito do tipo de consenso, portanto, não é muito correto representá-las entre as principais. Entre esses parâmetros, por exemplo: o número de garfos de corrente, seu comprimento em blocos, a ocupação de blocos com transações, etc. Eles podem ser usados para identificar situações de separação de rede ou localizar rapidamente problemas de um validador específico.
Camada P2P
É extremamente importante lembrar a base intermediária das redes blockchain - o subsistema ponto a ponto. É ela quem introduz atrasos vagos na entrega de blocos e transações entre validadores. Quando o número de validadores é pequeno, eles são localizados, as listas de pares são codificadas, tudo funciona bem e rapidamente. Mas vale a pena adicionar validadores, distribuir nós geograficamente e emular a perda de pacotes, pois falhas significativas aparecem em "tps".
Por exemplo, ao testar o consenso da EOS com o algoritmo de finalidade opcional, aumentar o número de validadores até 80-100 máquinas espaçadas em quatro continentes não afetou significativamente a velocidade de alcançar a finalidade. Ao mesmo tempo, um aumento na perda de pacotes afetou fortemente o atraso de finalização, o que indica a necessidade de configuração adicional da camada p2p para maior resistência à perda de pacotes de rede e não à latência grande. Infelizmente, existem muitas configurações e fatores diferentes, portanto, apenas benchmarks nos permitem entender o número efetivo de validadores que fornecem uma velocidade bastante confortável da blockchain.
O subsistema p2p do dispositivo pode ser entendido a partir da documentação, por exemplo, na libp2p ou na documentação do protocolo Kademlia ou BitTorrent .
Métricas importantes para p2p são:
- tráfego de entrada e saída
- número de conexões com ou sem êxito com outros pares
- quantas vezes os dados do chunk em cache anteriormente foram retornados e quantas vezes foi necessário encaminhar a solicitação ainda mais em busca do chunk desejado (análogo de ocorrências / falhas de cache)
Por exemplo, um grande número de erros ao acessar dados significa que apenas um pequeno número de nós possui os dados solicitados, e eles não têm tempo para distribuí-los a todos, e a quantidade de tráfego p2p recebido / dado permitirá que você estabeleça um nó com problemas na configuração ou no canal da rede.
Métricas do sistema de nós da Blockchain
As métricas padrão do sistema de nós blockchain são descritas em um grande número de fontes, então eu as descreverei brevemente. Sua função é ajudar a procurar gargalos e erros em todas as partes do código, mostrando quais subsistemas dos nós estão mais carregados e quais tarefas.
CPU
Eles falam sobre quantos cálculos o processador executa. Se a carga da CPU for alta, o nó está calculando algo, usando ativamente a lógica ou a FPU (quase nunca usada em cadeias de blocos). Nas cadeias de blocos, isso pode ser devido, por exemplo, ao fato de o nó verificar assinaturas eletrônicas, processar transações com criptografia pesada ou fazer cálculos complexos.
A CPU pode ser "cortada" em várias métricas mais úteis para entender quais partes do código são as mais caras. Por exemplo, sistema é o código do kernel, usuário é processos do usuário, io está aguardando a E / S de dispositivos externos lentos (disco / rede) etc. Aqui está um bom artigo relacionado.
Memória
As blockchains modernas usam bancos de dados de valores-chave (LevelDB, RocksDB), que mantêm constantemente os dados quentes na memória. Como em qualquer serviço carregado, vazamentos de memória sempre são possíveis como resultado de erros ou ataques direcionados ao código do nó. Se o consumo do nó de memória aumentar ou aumentar acentuadamente, isso provavelmente será causado por um aumento no número de chaves no banco de dados de estado, grandes filas de transações ou um aumento no número de mensagens entre diferentes subsistemas do nó. A sobrecarga da memória pode indicar um possível aumento nos limites de dados em blocos ou a complexidade máxima da transação.
Para nós completos, https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png, que correspondem aos clientes da rede, as métricas de cache de arquivos também são importantes. Os clientes acessam várias partes do banco de dados do estado e do log de transações. Isso cria um aumento de blocos antigos do disco, o que pode bloquear novos blocos, o que, por sua vez, diminui a resposta ao cliente.
Rede
As principais métricas da rede interna são a quantidade de tráfego em bytes, o número de pacotes de rede enviados e recebidos para cada um e protocolos, a taxa de perda de pacotes. Nas cadeias de blocos, essas métricas geralmente não recebem muita atenção, porque as blockchains ainda não processam transações a uma velocidade de 1 Gbit / s.
Existem projetos de blockchain que permitem aos usuários compartilhar seus wifi ou fornecer serviços para armazenar e transferir arquivos ou mensagens. Ao testar essas redes, a quantidade e a qualidade do tráfego através da interface de rede tornam-se métricas extremamente importantes, pois um canal de rede lotado afeta todos os outros serviços na máquina, sem exceção.
Armazenamento
O subsistema de disco é o componente mais lento de qualquer serviço e geralmente é a causa de sérios problemas de desempenho. Registro excessivo, um backup inesperado, um padrão de leitura / gravação inconveniente, um grande volume total de blockchain - tudo isso pode levar a uma desaceleração significativa na operação do nó ou a requisitos seriamente excessivos de hardware.
O log de transações pode tecnicamente ser considerado como WAL ( WAL ) para o banco de dados estadual, portanto, essas métricas de armazenamento são importantes que permitem procurar gargalos nos mecanismos dos bancos de dados modernos de valor-chave. Estes são o número de IOPS de leitura / gravação, latência máxima / min / média e muitas outras métricas que ajudam a otimizar as operações do disco.
Conclusão
Portanto, examinamos vários conjuntos de métricas que podem fornecer informações muito valiosas sobre a operação da rede blockchain e as possibilidades de sua otimização. Para resumir, você pode coletá-los em três grupos:
- métricas blockchain de nós:
o número de blocos produzidos, o número de transações processadas, o tempo de processamento, o tempo de finalização etc. - métricas do subsistema p2p:
o número de solicitações de acerto / erro, o número de pares ativos, o volume e a estrutura do tráfego p2p, etc. - métricas do sistema de nós:
CPU, memória, armazenamento, rede, etc.
Cada um dos grupos é importante à sua maneira, uma vez que em cada um dos subsistemas pode haver erros restringindo a operação de outros componentes, e diminuir a velocidade de um pequeno número de validadores pode ter um sério impacto em toda a rede. Além disso, os erros mais complicados nos algoritmos de consenso e finalidade surgem apenas com um grande fluxo de transações ou alterações nos parâmetros de consenso. Sua análise requer condições de teste reproduzíveis e cenários de carga complexos.
O desenvolvimento de blockchains é sempre a orquestração de várias máquinas, scripts para definir configurações e lançamento coordenado de nós e benchmarks, um servidor para coletar métricas e logs de todas as máquinas. Portanto, ao desenvolver seu blockchain, considere contratar um devedor qualificado - ele fornecerá suporte inestimável à equipe de desenvolvimento. Boa sorte