Il existe de nombreuses métriques liées à la logique et à la qualité de la blockchain. Ils aident à identifier les goulots d'étranglement dans le code et à trouver des problèmes logiques et d'optimisation dans les algorithmes de consensus et finaux dans les chaînes de blocs. Tout développement de systèmes distribués, y compris les chaînes de blocs, nécessite une analyse du travail de nombreux nœuds à la fois. Ils permettent à l'équipe du projet de surveiller l'état de l'ensemble du réseau blockchain, de voir les problèmes avec les nœuds individuels, de détecter la survenue d'attaques DoS sur le réseau et bien plus encore. Regardons les principaux. Plongeons dedans.
"Transactions par seconde"
Dans le cas des systèmes distribués, TPS est un numéro très maussade et ambigu, qui ne reflète pas toujours la qualité réelle du service rendu aux utilisateurs. Les mesures du TPS nous sont venues de bases de données distribuées. Le TPS dans les bases de données est normalisé pour les transactions de test ou leurs ensembles (certains INSERT, certains UPDATE, tant de SUPPRESSION sur le fond de SELECT constant) pour une configuration de cluster codée en dur ou même sur la même machine. Ces mesures ne donnent généralement que des estimations approximatives des performances des bases de données distribuées ou des chaînes de blocs, car le temps de traitement des transactions peut varier considérablement en fonction de nombreux facteurs.
Les bases de données axées sur la cohérence (voir «Théorème CAP») ne valident pas la transaction tant qu'elles n'ont pas reçu un nombre suffisant de confirmations des autres nœuds, ce qui est lent. Et les bases de données orientées vers la disponibilité considèrent une transaction qui a été simplement écrite sur disque comme un succès. Ils donnent immédiatement au client des données mises à jour et c'est très rapide (bien qu'à l'avenir, cette transaction puisse être annulée). De plus, si les transactions utilisées dans le benchmark ne mettent à jour qu'une seule cellule avec des données, le TPS sera évidemment plus élevé que dans les cas où les transactions peuvent affecter de nombreuses cellules et se bloquer les unes les autres. Les algorithmes pour travailler avec ces verrous dans chaque base de données sont implémentés à leur manière - c'est pourquoi nous ne voyons pas de «compétitions TPS» entre Oracle, MSSQL, PostgreSQL d'une part et MongoDB, Redis, Tarantool d'autre part - ce sont des mécanismes internes très différents et des tâches différentes .
À mon avis, «mesurer le TPS» de la blockchain signifie prendre une gamme complète de mesures de ses performances:
- dans des conditions reproductibles
- avec un nombre proche de la réalité de validateurs de blocs
- en utilisant différents types de transactions:
- typique de la blockchain étudiée (par exemple, transfer () de la crypto-monnaie principale)
- chargement du sous-système de stockage (une grande quantité de modifications de chaque transaction)
- chargement de la bande passante (grand volume de transactions)
- Chargement du CPU (en cas de crypto-transformations massives ou de calculs)
Pour parler des «transactions par seconde» chères, vous devez décrire toutes les conditions (le nombre de validateurs, leur géodistribution, le niveau de perte de paquets, etc.) et décrire la logique du benchmarking. Dans les chaînes de blocs, le simple roulement d'une transaction sur une base de données interne ne signifie pas son acceptation par consensus. Par exemple, dans le cas de la preuve de travail, statistiquement, les transactions ne sont jamais terminées du tout, et si une transaction est incluse dans un bloc sur une machine, cela ne signifie pas qu'elle sera acceptée par l'ensemble du réseau (par exemple, si une autre fourchette gagne).
Si la blockchain dispose d'un algorithme supplémentaire pour garantir la finalité des transactions (EOS, Ethereum 2.0, parachains Polkadot qui utilisent le consensus avec la finalité GRANDPA), alors le temps de traitement peut être considéré comme l'écart entre le nœud «a vu» la transaction et le prochain bloc finalisé où cette transaction a été inclus. Tel, plus proche de la réalité, le «TPS» est rarement vu dans les promesses de projet. Naturellement, ils sont inférieurs à ceux décrits dans le livre blanc, mais ils sont aussi informatifs que possible.
Je vous préviens donc encore une fois, de nombreuses significations différentes peuvent être intégrées dans le terme «TPS». Soyez sceptique et demandez des détails.
Mesures spécifiques à la blockchain
Tps locaux
Le nombre de transactions traitées par le nœud et le temps max / moy / min de leur traitement sur le nœud local sont très pratiques à mesurer, car les fonctions qui effectuent cette opération sont généralement explicitement allouées dans le code. Vous pouvez simplement mesurer la durée de la transaction en mettant à jour la base de données d'état. Ces transactions peuvent ne pas encore être acceptées par consensus, mais ont déjà été validées, et le nœud peut déjà fournir au client des données mises à jour (en supposant que la chaîne de fourches n'apparaît pas).
Cette métrique n'est pas très honnête: si une autre fourche de la chaîne est choisie comme principale, les statistiques sur les transactions annulées doivent également être annulées. Mais pour les tests, cela peut presque toujours être négligé.
Souvent, c'est le nombre qui est écrit dans de brefs rapports: «notre blockchain a obtenu 8 000 tps hier», car elle est facile à mesurer - un seul nœud en cours d'exécution et un script qui le charge suffisent. Dans ce cas, il n'y a pas de retard sur le réseau, ce qui ralentit le consensus du réseau et la métrique montre les performances de la base de données d'état sans influence du réseau. Ce nombre n'est pas la bande passante réelle du réseau blockchain, mais montre la limite à laquelle il s'efforcera si le consensus et le réseau sont assez rapides.
Le résultat de toute transaction blockchain est plusieurs mises à jour atomiques du stockage. Par exemple, une transaction de paiement dans Bitcoin est la suppression de plusieurs anciens UTXO (suppression) et l'ajout de plusieurs nouveaux UTXO (insertion), et dans Ethereum c'est l'exécution d'un code de contrat intelligent court et, encore une fois, la mise à jour de plusieurs paires clé-valeur. Le nombre de ces opérations d'écriture «atomiques» peut être une excellente mesure qui vous permet d'identifier les goulots d'étranglement dans le sous-système de stockage et la logique de transaction interne.
De plus, les nœuds de la chaîne de blocs peuvent être implémentés dans plusieurs langages de programmation - c'est plus fiable. Cela doit être pris en compte lors de l'évaluation des performances du réseau, par exemple, le nœud Ethereum existe dans les implémentations sur Rust and Go. D'autres blockchains cherchent également à avoir des implémentations supplémentaires pour la fiabilité.
Quantité de blocs produits localement
Cette métrique simple montre à quel validateur le nombre de blocs produits. Il s'agit d'un produit consensuel et peut être considéré comme le principal pour évaluer «l'utilité» d'un réseau de validateurs individuels.
Gagner de l'argent sur chaque bloc, les validateurs sont intéressés par le fonctionnement stable et la sécurité de leurs machines. Ce nombre permet de déterminer lequel des candidats validateurs est le plus qualifié, protégé et prêt à travailler sur un réseau public avec les atouts d'utilisateurs réels. La valeur de la métrique peut être vérifiée publiquement en téléchargeant simplement la chaîne de blocs et en calculant qui a produit combien de blocs.
Finalité et dernier bloc irréversible
Dans les réseaux avec une finalité clairement implémentée (EOS, Ethereum, Tendermint, Polkadot, etc.), en plus du consensus rapide et de base (dans lequel une signature de validateur par bloc suffit), certains blocs nécessitent une coordination par un groupe de validateurs. Ces blocs sont considérés comme définitifs et l'algorithme de collecte de signature est considéré comme définitif. La tâche de la finalité est de s'assurer que toutes les transactions incluses dans la blockchain avant le bloc finalisé ne sont jamais pompées et ne sont pas remplacées par un autre fork de la chaîne. Il s'agit d'une protection contre les attaques à double dépense dans les réseaux de preuve de participation et un moyen de retourner rapidement, en quelques secondes, une confirmation fiable d'une transaction de crypto-monnaie à un utilisateur.
Du point de vue de l'utilisateur de la blockchain, la transaction ne se termine pas au moment où elle est acceptée par le nœud, mais lorsqu'un bloc apparaît qui finalise la chaîne dans laquelle se trouve la transaction. Pour finaliser un bloc, les validateurs doivent recevoir ce bloc sur un réseau p2p et échanger des signatures entre eux. C'est ici que la vitesse réelle de la blockchain est vérifiée, car l'utilisateur est intéressé par le moment de finaliser le bloc avec sa transaction, et pas seulement de l'accepter et de l'écrire sur le disque de l'un des nœuds.
Les algorithmes de finalité diffèrent, se croisent et se combinent également avec le consensus principal (à lire: Casper dans Ethereum, Last Irreversible Blocks dans EOS, GRANDPA dans Parity Polkadot et leurs modifications, par exemple MixBytes RANDPA).
Pour les réseaux où tous les blocs ne sont pas finalisés, une métrique utile est le décalage entre le dernier bloc finalisé et le dernier bloc actuel. Ce nombre montre comment les validateurs sont à la traîne, se mettant d'accord sur la bonne chaîne. Si l'écart est important, l'algorithme de finalisation nécessite une analyse et une optimisation supplémentaires.
Autres métriques de la blockchain
Les autres métriques dépendent généralement fortement du type de consensus, il n'est donc pas très correct de les représenter parmi les principaux. Parmi ces paramètres, par exemple: le nombre de fourches à chaîne, leur longueur en blocs, l'occupation des blocs avec transactions, etc. Ils peuvent être utilisés pour identifier des situations de séparation de réseau ou localiser rapidement les problèmes d'un validateur spécifique.
Couche P2P
Il est extrêmement important de se rappeler la base intermédiaire des réseaux de chaînes de blocs - le sous-système peer-to-peer. C'est elle qui introduit de vagues retards dans la livraison des blocs et des transactions entre valideurs. Lorsque le nombre de validateurs est faible, ils sont localisés, les listes de pairs sont codées en dur, tout fonctionne bien et rapidement. Mais cela vaut la peine d’ajouter des valideurs, de répartir géographiquement les nœuds et d’émuler les pertes de paquets, car des défaillances importantes apparaissent dans «tps».
Par exemple, lors du test du consensus EOS avec l'algorithme de finalité facultatif, l'augmentation du nombre de validateurs, même à 80-100 machines réparties sur quatre continents, n'a pas affecté de manière significative la vitesse de finalisation. Dans le même temps, une augmentation de la perte de paquets a fortement affecté le décalage de finalité, ce qui indique la nécessité d'une configuration supplémentaire de la couche p2p pour une plus grande résistance à la perte de paquets réseau et non à une latence importante. Malheureusement, il existe de nombreux paramètres et facteurs différents, par conséquent, seuls les repères nous permettent de comprendre le nombre effectif de validateurs qui fournissent une vitesse assez confortable de la blockchain.
Le sous-système p2p du périphérique peut être compris à partir de la documentation, par exemple, sur libp2p ou de la documentation sur le protocole Kademlia ou BitTorrent .
Les métriques importantes pour p2p sont:
- trafic entrant-sortant
- nombre de connexions réussies / infructueuses avec d'autres pairs
- combien de fois les données de bloc précédemment mises en cache ont été renvoyées, et combien de fois il a été nécessaire de transmettre la demande davantage à la recherche du bloc souhaité (analogue des hits / misses du cache)
Par exemple, un grand nombre de ratés lors de l'accès aux données signifie que seul un petit nombre de nœuds ont les données demandées, et ils n'ont pas le temps de les distribuer à tout le monde, et la quantité de trafic p2p reçu / donné vous permettra d'établir un nœud qui a des problèmes avec la configuration du réseau ou le canal.
Métriques du système de nœuds Blockchain
Les métriques système standard des nœuds de la chaîne de blocs sont décrites dans un grand nombre de sources, je vais donc les décrire brièvement. Leur rôle est d'aider à rechercher les goulots d'étranglement et les erreurs dans toutes les parties du code, en montrant quels sous-systèmes des nœuds sont les plus chargés et quelles tâches.
CPU
Ils parlent du nombre de calculs effectués par le processeur. Si la charge CPU est élevée, le nœud calcule quelque chose, en utilisant activement la logique ou le FPU (presque jamais utilisé dans les blockchains). Dans les chaînes de blocs, cela peut être, par exemple, dû au fait que le nœud vérifie les signatures électroniques, traite les transactions avec une cryptographie lourde ou effectue des calculs complexes.
Le processeur peut être «découpé» en plusieurs mesures plus utiles pour comprendre quelles parties du code sont les plus coûteuses. Par exemple, le système est le code du noyau, l'utilisateur est le processus utilisateur, io attend les E / S des périphériques externes lents (disque / réseau), etc. Voici un bon article connexe.
La mémoire
Les blockchains modernes utilisent des bases de données de valeurs-clés (LevelDB, RocksDB), qui gardent constamment des données chaudes en mémoire. Comme pour tout service chargé, des fuites de mémoire sont toujours possibles à la suite d'erreurs ou d'attaques ciblées sur le code du nœud. Si la consommation du nœud de mémoire augmente ou a fortement augmenté, cela est probablement dû à une augmentation du nombre de clés dans la base de données d'état, à de grandes files d'attente de transactions ou à une augmentation du nombre de messages entre les différents sous-systèmes du nœud. Le sous-chargement de la mémoire peut indiquer une augmentation possible des limites de données dans les blocs ou une complexité de transaction maximale.
Pour les nœuds complets, qui sont https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png qui correspondent aux clients réseau, les mesures de cache de fichiers sont également importantes. Les clients accèdent à différentes parties de la base de données d'état et du journal des transactions. Cela crée une recrudescence d'anciens blocs du disque, ce qui peut évincer de nouveaux blocs, ce qui ralentit à son tour la réponse au client.
Réseau
Les principales mesures du réseau interne sont la quantité de trafic en octets, le nombre de paquets réseau envoyés et reçus pour chacun et les protocoles, le taux de perte de paquets. Dans les chaînes de blocs, ces métriques ne reçoivent souvent pas beaucoup d'attention, car les blockchains ne traitent pas encore les transactions à une vitesse de 1 Gbit / sec.
Il existe des projets de blockchain qui permettent aux utilisateurs de partager leur wifi ou de fournir des services de stockage et de transfert de fichiers ou de messages. Lors du test de tels réseaux, la quantité et la qualité du trafic via l'interface réseau deviennent des mesures extrêmement importantes, car un canal réseau encombré affecte tous les autres services sur la machine, sans exception.
Stockage
Le sous-système de disques est le composant le plus lent de tous les services et est souvent la cause de graves problèmes de performances. Journalisation excessive, sauvegarde inattendue, schéma de lecture / écriture gênant, grand volume total de blockchain - tout cela peut entraîner un ralentissement significatif du fonctionnement du nœud ou des exigences matérielles excessivement importantes.
Le journal des transactions peut techniquement être considéré comme WAL ( WAL ) pour la base de données d'état, par conséquent, ces mesures de stockage sont importantes qui vous permettent de rechercher des goulots d'étranglement dans les mécanismes des bases de données de valeurs-clés modernes. Il s'agit du nombre d'E / S par seconde en lecture / écriture, de la latence max / min / moyenne et de nombreuses autres mesures qui aident à optimiser les opérations sur le disque.
Conclusion
Nous avons donc examiné plusieurs ensembles de métriques qui peuvent fournir des informations très précieuses sur le fonctionnement du réseau blockchain et les possibilités de son optimisation. Pour résumer, vous pouvez les regrouper en trois groupes:
- métriques blockchain des nœuds:
le nombre de blocs produits, le nombre de transactions traitées, leur temps de traitement, le temps de finalisation, etc. - mesures du sous-système p2p:
le nombre de requêtes hit / miss, le nombre de pairs actifs, le volume et la structure du trafic p2p, etc. - métriques système des nœuds:
CPU, mémoire, stockage, réseau, etc.
Chacun des groupes est important à sa manière, car dans chacun des sous-systèmes, il peut y avoir des erreurs limitant le fonctionnement des autres composants, et ralentir même un petit nombre de validateurs peut avoir un impact sérieux sur l'ensemble du réseau. De plus, les erreurs les plus délicates dans les algorithmes de consensus et de finalité ne surviennent qu'avec un flux de transactions important ou des changements de paramètres de consensus. Leur analyse nécessite des conditions de test reproductibles et des scénarios de charge complexes.
Le développement des blockchains est toujours l'orchestration de plusieurs machines, des scripts pour la mise en place des configurations et le lancement coordonné des nœuds et des benchmarks, un serveur pour collecter les métriques et les logs de toutes les machines. Par conséquent, lors du développement de votre blockchain, envisagez d'embaucher un développeur qualifié - cela fournira un soutien inestimable à l'équipe de développement. Bonne chance