Une question favorite sur tout système distribué posée par une personne non technique est « Combien de tps y a-t-il sur votre blockchain ? » Cependant, le chiffre donné en réponse a généralement peu de points communs avec ce que la personne qui pose la question aimerait entendre. En fait, il voulait demander « votre blockchain répondra-t-elle aux exigences de mon entreprise », et ces exigences ne sont pas un chiffre, mais de nombreuses conditions - voici la tolérance aux pannes du réseau, les exigences de finalité, la taille, la nature des transactions et de nombreux autres paramètres. Il est donc peu probable que la réponse à la question « combien de tps » soit simple, et presque jamais complète. Un système distribué avec des dizaines ou des centaines de nœuds effectuant des calculs assez complexes peut se trouver dans un grand nombre d'états différents liés à l'état du réseau, au contenu de la blockchain, aux pannes techniques, aux problèmes économiques, aux attaques sur le réseau et bien d'autres raisons. . Les étapes auxquelles des problèmes de performances sont possibles diffèrent des services traditionnels, et un serveur réseau blockchain est un service réseau qui combine les fonctionnalités d'une base de données, d'un serveur Web et d'un client torrent, ce qui le rend extrêmement complexe en termes de profil de charge sur tous les sous-systèmes. : processeur, mémoire, réseau, stockage

Il se trouve que les réseaux décentralisés et les blockchains sont des logiciels assez spécifiques et inhabituels pour les développeurs de logiciels centralisés. Par conséquent, je voudrais souligner des aspects importants de la performance et de la durabilité des réseaux décentralisés, les approches pour les mesurer et trouver les goulots d'étranglement. Nous examinerons divers problèmes de performances qui limitent la vitesse de fourniture des services aux utilisateurs de la blockchain et noterons les fonctionnalités caractéristiques de ce type de logiciel.

Étapes d'une demande de service par un client blockchain

Afin de parler honnêtement de la qualité de tout service plus ou moins complexe, il faut prendre en compte non seulement les valeurs moyennes, mais aussi les maximum/minimum, les médianes, les centiles. Théoriquement, nous pouvons parler de 1000 900 tps dans certaines blockchains, mais si 100 transactions ont été effectuées à une vitesse énorme et que XNUMX ont été « bloquées » pendant quelques secondes, alors le temps moyen collecté sur toutes les transactions n'est pas une mesure tout à fait juste pour un client. avec qui je n'ai pas pu finaliser la transaction en quelques secondes. Des « trous » temporaires causés par des cycles de consensus manqués ou des divisions de réseau peuvent grandement ruiner un service qui a montré d'excellentes performances sur les bancs de test.

Pour identifier de tels goulots d’étranglement, il est nécessaire de bien comprendre les étapes auxquelles une véritable blockchain peut avoir des difficultés à servir les utilisateurs. Décrivons le cycle de livraison et de traitement d'une transaction, ainsi que l'obtention d'un nouvel état de la blockchain, à partir duquel le client peut vérifier que sa transaction a été traitée et comptabilisée.

la transaction est formée sur le client
la transaction est signée sur le client
le client sélectionne l'un des nœuds et lui envoie sa transaction
le client s'abonne aux mises à jour de la base de données d'état du nœud, en attendant l'apparition des résultats de sa transaction
le nœud distribue la transaction sur le réseau p2p
plusieurs ou un BP (producteur de blocs) traite les transactions accumulées, mettant à jour la base de données d'état
BP forme un nouveau bloc après avoir traité le nombre requis de transactions
BP distribue un nouveau bloc sur le réseau p2p
le nouveau bloc est livré au nœud auquel le client accède
le nœud met à jour la base de données d'état
le nœud voit la mise à jour concernant le client et lui envoie une notification de transaction

Examinons maintenant ces étapes de plus près et décrivons les problèmes de performances potentiels à chaque étape. Contrairement aux systèmes centralisés, nous considérerons également l’exécution de code sur les clients réseau. Très souvent, lors de la mesure du TPS, le temps de traitement des transactions est collecté auprès des nœuds et non du client - ce n'est pas tout à fait juste. Le client ne se soucie pas de la rapidité avec laquelle le nœud a traité sa transaction, le plus important pour lui est le moment où des informations fiables sur cette transaction incluse dans la blockchain lui deviennent disponibles. C'est cette métrique qui représente essentiellement le temps d'exécution de la transaction. Cela signifie que différents clients, même en envoyant la même transaction, peuvent recevoir des heures complètement différentes, qui dépendent du canal, de la charge et de la proximité du nœud, etc. Il faut donc absolument mesurer ce temps sur les clients, puisque c'est le paramètre qu'il faut optimiser.

Préparer une transaction côté client

Commençons par les deux premiers points : la transaction est formée et signée par le client. Curieusement, cela peut également constituer un goulot d'étranglement dans les performances de la blockchain du point de vue du client. Ceci est inhabituel pour les services centralisés, qui prennent en charge tous les calculs et opérations avec des données, et le client prépare simplement une courte demande pouvant demander une grande quantité de données ou de calculs, obtenant ainsi un résultat prêt à l'emploi. Dans les blockchains, le code client devient de plus en plus puissant, le cœur de la blockchain devient de plus en plus léger et des tâches informatiques massives sont généralement transférées au logiciel client. Dans les blockchains, certains clients peuvent préparer une transaction pendant assez longtemps (je parle de diverses preuves Merkle, preuves succinctes, signatures de seuil et autres opérations complexes côté client). Un bon exemple de vérification simple en chaîne et de préparation lourde d'une transaction sur le client est la preuve d'appartenance à une liste basée sur Merkle-tree, ici article.

N'oubliez pas non plus que le code client n'envoie pas simplement des transactions à la blockchain, mais interroge d'abord l'état de la blockchain - et cette activité peut affecter la congestion du réseau et des nœuds de la blockchain. Ainsi, lors de la prise de mesures, il serait raisonnable d'émuler le plus complètement possible le comportement du code client. Même si dans votre blockchain il y a des clients légers ordinaires qui apposent une signature numérique régulière sur la transaction la plus simple pour transférer un actif, chaque année, des calculs encore plus massifs sont effectués sur le client, les algorithmes de cryptographie deviennent plus forts et cette partie du traitement peut devenir un goulot d'étranglement important à l'avenir. Par conséquent, soyez prudent et ne manquez pas la situation où, dans une transaction d'une durée de 3.5 s, 2.5 s sont dépensées pour préparer et signer la transaction, et 1.0 s pour l'envoyer au réseau et attendre une réponse. Pour évaluer les risques de ce goulot d'étranglement, vous devez collecter des métriques à partir des machines clientes, et pas seulement à partir des nœuds blockchain.

Envoi d'une transaction et suivi de son statut

L'étape suivante consiste à envoyer la transaction au nœud blockchain sélectionné et à recevoir le statut d'acceptation dans le pool de transactions. Cette étape est similaire à un accès régulier à une base de données : le nœud doit enregistrer la transaction dans le pool et commencer à distribuer les informations la concernant via le réseau p2p. L'approche d'évaluation des performances ici est similaire à l'évaluation des performances des microservices API Web traditionnels, et les transactions elles-mêmes dans les blockchains peuvent être mises à jour et modifier activement leur statut. En général, la mise à jour des informations de transaction sur certaines blockchains peut se produire plusieurs fois, par exemple lors du basculement entre des fourches de chaîne ou lorsque les BP annoncent leur intention d'inclure une transaction dans un bloc. Les limites imposées à la taille de ce pool et au nombre de transactions qu'il contient peuvent affecter les performances de la blockchain. Si le pool de transactions est rempli à la taille maximale possible ou ne rentre pas dans la RAM, les performances du réseau peuvent chuter considérablement. Les blockchains ne disposent d'aucun moyen centralisé de protection contre un flot de messages indésirables, et si la blockchain prend en charge des transactions à volume élevé et des frais faibles, cela peut entraîner un débordement du pool de transactions, un autre goulot d'étranglement potentiel en termes de performances.

Dans les blockchains, le client envoie une transaction à n'importe quel nœud blockchain de son choix, le hachage de la transaction est généralement connu du client avant l'envoi, il lui suffit donc d'établir la connexion et, après la transmission, d'attendre que la blockchain change son état, permettant sa transaction. Notez qu'en mesurant « tps », vous pouvez obtenir des résultats complètement différents pour différentes méthodes de connexion à un nœud blockchain. Il peut s'agir d'un HTTP RPC standard ou d'un WebSocket qui vous permet d'implémenter le modèle « abonnement ». Dans le second cas, le client recevra une notification plus tôt et le nœud consacrera moins de ressources (principalement de la mémoire et du trafic) aux réponses sur l'état de la transaction. Ainsi, lors de la mesure du « tps », il est nécessaire de prendre en compte la manière dont les clients se connectent aux nœuds. Ainsi, pour évaluer les risques de ce goulot d'étranglement, la blockchain de référence doit être capable d'émuler des clients avec des requêtes WebSocket et HTTP RPC, dans des proportions correspondant aux réseaux réels, ainsi que de modifier la nature des transactions et leur taille.

Pour évaluer les risques de ce goulot d'étranglement, vous devez également collecter des métriques à partir des machines clientes, et pas seulement à partir des nœuds blockchain.

Transmission de transactions et de blocs via le réseau p2p

Dans les blockchains, le réseau peer-to-peer (p2p) est utilisé pour transférer des transactions et des blocs entre les participants. Les transactions se propagent dans tout le réseau, en commençant par l'un des nœuds, jusqu'à ce qu'elles atteignent les producteurs de blocs homologues, qui regroupent les transactions en blocs et, en utilisant le même p2p, distribuent de nouveaux blocs à tous les nœuds du réseau. La base de la plupart des réseaux P2P modernes repose sur diverses modifications du protocole Kademlia. Ici un bon résumé de ce protocole, et ici - un article avec diverses mesures dans le réseau BitTorrent, à partir duquel on peut comprendre que ce type de réseau est plus complexe et moins prévisible qu'un réseau configuré de manière rigide d'un service centralisé. Aussi, ici article sur la mesure de diverses métriques intéressantes pour les nœuds Ethereum.

En bref, chaque homologue de ces réseaux maintient sa propre liste dynamique d'autres homologues à laquelle il demande des blocs d'informations adressés par contenu. Lorsqu'un homologue reçoit une requête, soit il donne les informations nécessaires, soit il transmet la requête au homologue pseudo-aléatoire suivant de la liste, et après avoir reçu une réponse, il la transmet au demandeur et la met en cache pendant un certain temps, donnant ainsi bloc d'informations plus tôt la prochaine fois. Ainsi, les informations populaires se retrouvent dans un grand nombre de caches d'un grand nombre de pairs, et les informations impopulaires sont progressivement remplacées. Les pairs enregistrent qui a transféré quelle quantité d'informations à qui, et le réseau tente de stimuler les distributeurs actifs en augmentant leurs notes et en leur fournissant un niveau de service plus élevé, déplaçant automatiquement les participants inactifs des listes de pairs.

La transaction doit donc maintenant être distribuée sur tout le réseau afin que les producteurs de blocs puissent la voir et l'inclure dans le bloc. Le nœud « distribue » activement une nouvelle transaction à tout le monde et écoute le réseau, en attendant un bloc dans l'index duquel la transaction requise apparaîtra afin d'avertir le client en attente. Le temps nécessaire au réseau pour transférer les informations sur les nouvelles transactions et les nouveaux blocs dans les réseaux p2p dépend d'un très grand nombre de facteurs : le nombre de nœuds honnêtes travaillant à proximité (d'un point de vue du réseau), la « chaleur » « » des caches de ces nœuds, la taille des blocs, les transactions, la nature des changements, la géographie du réseau, le nombre de nœuds et bien d'autres facteurs. Les mesures complexes des mesures de performance dans de tels réseaux sont une question complexe ; il est nécessaire d'évaluer simultanément le temps de traitement des requêtes sur les clients et les pairs (nœuds blockchain). Des problèmes dans l'un des mécanismes p2p, une expulsion et une mise en cache incorrectes des données, une gestion inefficace des listes de pairs actifs et de nombreux autres facteurs peuvent provoquer des retards qui affectent l'efficacité de l'ensemble du réseau, et ce goulot d'étranglement est le plus difficile à analyser. , test et interprétation des résultats.

Traitement de la blockchain et mise à jour de la base de données d'état

La partie la plus importante de la blockchain est l'algorithme de consensus, son application aux nouveaux blocs reçus du réseau et le traitement des transactions avec enregistrement des résultats dans la base de données d'état. L'ajout d'un nouveau bloc à la chaîne, puis la sélection de la chaîne principale devraient fonctionner le plus rapidement possible. Cependant, dans la vraie vie, « devrait » ne signifie pas « fonctionne », et on peut, par exemple, imaginer une situation dans laquelle deux longues chaînes concurrentes basculent constamment entre elles, modifiant les métadonnées de milliers de transactions dans le pool à chaque changement. , et en annulant constamment la base de données d'état. Cette étape, en termes de définition du goulot d'étranglement, est plus simple que la couche réseau p2p, car l'exécution des transactions et l'algorithme de consensus sont strictement déterministes, et il est plus facile de mesurer quoi que ce soit ici.
L'essentiel est de ne pas confondre la dégradation aléatoire des performances de cette étape avec des problèmes de réseau - les nœuds sont plus lents à fournir des blocs et des informations sur la chaîne principale, et pour un client externe, cela peut ressembler à un réseau lent, bien que le problème réside dans un endroit complètement différent.

Pour optimiser les performances à ce stade, il est utile de collecter et de surveiller les métriques des nœuds eux-mêmes, et d'y inclure celles liées à la mise à jour de la base de données d'état : le nombre de blocs traités sur le nœud, leur taille, le nombre de transactions, le nombre de commutateurs entre les fourches de chaîne, le nombre de blocs invalides, le temps de fonctionnement de la machine virtuelle, le temps de validation des données, etc. Cela évitera que les problèmes de réseau soient confondus avec des erreurs dans les algorithmes de traitement en chaîne.

Une machine virtuelle traitant des transactions peut être une source d’informations utile permettant d’optimiser le fonctionnement de la blockchain. Le nombre d'allocations de mémoire, le nombre d'instructions de lecture/écriture et d'autres mesures liées à l'efficacité de l'exécution du code contractuel peuvent fournir de nombreuses informations utiles aux développeurs. En même temps, les contrats intelligents sont des programmes, ce qui signifie qu'en théorie ils peuvent consommer n'importe quelle ressource : processeur/mémoire/réseau/stockage, le traitement des transactions est donc une étape plutôt incertaine, qui, de plus, change considérablement lors du passage d'une version à l'autre. et lors de la modification des codes de contrat. Par conséquent, des mesures liées au traitement des transactions sont également nécessaires pour optimiser efficacement les performances de la blockchain.

Réception par le client d'une notification concernant l'inclusion d'une transaction dans la blockchain

Il s'agit de la dernière étape de la réception du service par le client blockchain ; par rapport aux autres étapes, il n'y a pas de frais généraux importants, mais il vaut toujours la peine d'envisager la possibilité que le client reçoive une réponse volumineuse du nœud (par exemple, un contrat intelligent). renvoyant un tableau de données). En tout cas, ce point est le plus important pour celui qui a posé la question « combien y a-t-il de tps dans votre blockchain ? », car A ce moment, l'heure de réception du service est enregistrée.

A cet endroit, il y a toujours un envoi du temps complet que le client a dû passer à attendre une réponse de la blockchain ; c'est ce temps que l'utilisateur attendra la confirmation dans son application, et c'est son optimisation qui est la priorité. tâche principale des développeurs.

Conclusion

De ce fait, on peut décrire les types d’opérations effectuées sur les blockchains et les diviser en plusieurs catégories :

transformations cryptographiques, construction de preuves
mise en réseau peer-to-peer, réplication de transactions et de blocs
traitement des transactions, exécution de contrats intelligents
appliquer les modifications de la blockchain à la base de données d'état, mettre à jour les données sur les transactions et les blocs
requêtes en lecture seule vers la base de données d'état, l'API du nœud blockchain, les services d'abonnement

En général, les exigences techniques des nœuds blockchain modernes sont extrêmement sérieuses : des processeurs rapides pour la cryptographie, une grande quantité de RAM pour stocker et accéder rapidement à la base de données d'état, une interaction réseau utilisant un grand nombre de connexions ouvertes simultanément et un stockage important. Des exigences aussi élevées et l'abondance de différents types d'opérations conduisent inévitablement au fait que les nœuds peuvent ne pas disposer de suffisamment de ressources, et l'une des étapes évoquées ci-dessus peut alors devenir un autre goulot d'étranglement pour les performances globales du réseau.

Lors de la conception et de l’évaluation des performances des blockchains, vous devrez prendre en compte tous ces points. Pour ce faire, vous devez collecter et analyser simultanément les métriques des clients et des nœuds du réseau, rechercher des corrélations entre elles, estimer le temps nécessaire pour fournir des services aux clients, prendre en compte toutes les ressources principales : processeur/mémoire/réseau/stockage. , comprendre comment ils sont utilisés et s’influencent mutuellement. Tout cela fait de la comparaison des vitesses de différentes blockchains sous la forme de « combien de TPS » une tâche extrêmement ingrate, car il existe un grand nombre de configurations et d'états différents. Dans les grands systèmes centralisés, les clusters de centaines de serveurs, ces problèmes sont également complexes et nécessitent également la collecte d'un grand nombre de métriques différentes, mais dans les blockchains, en raison des réseaux p2p, des machines virtuelles traitant les contrats, des économies internes, du nombre de degrés de liberté est beaucoup plus grande, ce qui rend le test même sur plusieurs serveurs, il n'est pas indicatif et ne montre que des valeurs extrêmement approximatives qui n'ont presque aucun lien avec la réalité.

Par conséquent, lors du développement dans le noyau de la blockchain, pour évaluer les performances et répondre à la question « est-ce amélioré par rapport à la dernière fois ? », nous utilisons un logiciel assez complexe qui orchestre le lancement d'une blockchain avec des dizaines de nœuds et lance automatiquement un benchmark et collecte des métriques. ; sans ces informations, il est extrêmement difficile de déboguer des protocoles qui fonctionnent avec plusieurs participants.

Alors, lorsque vous recevez la question « combien de TPS y a-t-il dans votre blockchain ? », proposez du thé à votre interlocuteur et demandez-lui s'il est prêt à regarder une douzaine de graphiques et écoutez également les trois cases des problèmes de performances de la blockchain et vos suggestions de les résoudre...

Source: habr.com

Combien de TPS y a-t-il sur votre blockchain ?