Une question préférée sur tout système distribué d'un spécialiste non technique est «Combien de tps sont dans votre blockchain?». Cependant, le nombre donné en réponse n'a généralement pas grand-chose à voir avec ce que l'intervenant aimerait entendre. En fait, il voulait demander `` votre blockchain répondra-t-elle à mes besoins commerciaux '', et ces exigences ne sont pas un numéro, 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 ne sera presque jamais complète. Un système distribué avec des dizaines et 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 de réseau et à bien d'autres raisons. Les étapes auxquelles des problèmes de performances sont possibles diffèrent des services traditionnels, et le 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 rend extrêmement difficile en termes de profil de charge pour tous les sous-systèmes : processeur, mémoire, réseau, stockage

Il se trouve que les réseaux décentralisés et les chaînes de blocs sont des logiciels assez spécifiques et inhabituels pour les développeurs de logiciels centralisés. Par conséquent, je voudrais souligner les 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 prendrons en compte divers problèmes de performances qui limitent la vitesse de fourniture d'un service aux utilisateurs de la blockchain et notons les fonctionnalités spécifiques à ce type de logiciel.

Étapes de demande de service client Blockchain

Afin de parler honnêtement de la qualité de tout service plus ou moins complexe, vous devez prendre en compte non seulement les valeurs moyennes, mais aussi le maximum / minimum, les médianes, les centiles. Théoriquement, nous pouvons parler de 1000 tps dans une blockchain, mais si 900 transactions ont été exécutées à une vitesse énorme et 100 ont été «gelées» pendant plusieurs secondes, le temps moyen collecté pour toutes les transactions n'est pas tout à fait une mesure honnête pour un client qui en quelques secondes n'a pas pu terminer la transaction. Les «fosses» temporaires causées par des tours de consensus manquants ou la séparation du réseau peuvent ruiner considérablement un service qui a montré d'excellentes performances sur les bancs d'essai.

Pour identifier un tel goulot d'étranglement - et il est nécessaire de bien comprendre les étapes auxquelles la vraie 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 blockchain à partir duquel le client peut vérifier que sa transaction a été traitée et prise en compte.

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 des noeuds, en attendant l'apparition des résultats de l'exécution de sa transaction
un nœud propage une transaction sur un réseau p2p
plusieurs ou un BP (producteur de blocs) traitera les transactions accumulées, mettant à jour la base de données d'état
BP forme un nouveau bloc, traitant le nombre requis de transactions
BP distribue un nouveau bloc sur le réseau p2p
le nouveau bloc est livré au nœud accessible par le client
le nœud met à jour la base de données d'état
le nœud voit la mise à jour relative au 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érons également l'exécution de code sur les clients réseau. Très souvent, lors de la mesure des tps, le temps de traitement des transactions est collecté à partir des nœuds, et non du client - ce n'est pas tout à fait honnête. Le client ne se soucie pas de la rapidité avec laquelle le nœud a traité sa transaction, la chose la plus importante pour lui est le moment où des informations fiables sur cette transaction, incluses dans la blockchain, lui sont disponibles. C'est cette métrique qui est essentiellement le temps qu'il faut pour terminer une 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 est donc absolument nécessaire de mesurer ce temps sur les clients, car c'est ce paramètre qui doit être optimisé.

Préparation des transactions côté client

Commençons par les deux premiers points: la transaction est formée et signée par le client. Curieusement, cela pourrait également être le goulot d'étranglement des performances de la blockchain du point de vue du client. Cela est inhabituel pour les services centralisés, qui prennent tous les calculs et opérations de données pour eux-mêmes, et le client prépare simplement une courte demande qui peut demander une grande quantité de données ou de calculs, obtenant un résultat fini. Dans les chaînes de blocs, le code client devient de plus en plus puissant, et le cœur de la chaîne de blocs devient de plus en plus léger, et il est habituel de confier des tâches informatiques massives aux logiciels clients. Il y a des clients dans les chaînes de blocs qui peuvent préparer une seule transaction pendant assez longtemps (je parle de diverses preuves de merkle, de preuves succinctes, de signatures de seuil et d'autres opérations complexes côté client). Un bon exemple de vérification en chaîne facile et de préparation difficile d'une transaction sur un client est la preuve d'appartenance à une liste basée sur Merkle-tree, voici un article .

N'oubliez pas non plus que le code client n'envoie pas seulement des transactions à la blockchain, mais demande d'abord l'état de la blockchain - et cette activité peut affecter la charge du réseau et les nœuds de la blockchain. Ainsi, en prenant des mesures, il sera raisonnable d'émuler le comportement du code client de la manière la plus complète possible. Même si votre blockchain a des clients légers réguliers qui mettent une simple signature numérique sur la transaction la plus simple pour transférer des actifs, chaque année il y a encore des calculs plus massifs sur le client, les algorithmes cryptographiques se renforcent, et cette partie du traitement peut se transformer en un goulot d'étranglement important dans l'avenir. Par conséquent, soyez prudent et ne manquez pas la situation lorsque, dans une transaction de 3,5 s, 2,5 s sont consacrés à la préparation et à la signature de la transaction, et 1,0 s à l'envoi au réseau et l'attente d'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 de la chaîne de blocs.

Envoi d'une transaction et suivi de son statut

L'étape suivante consiste à envoyer la transaction au nœud de chaîne de blocs sélectionné et à recevoir l'état de son adoption dans le pool de transactions. Cette étape est similaire à un accès normal à la base de données, le nœud doit écrire la transaction dans le pool et commencer à distribuer des informations à ce sujet via le réseau p2p. L'approche de l'évaluation des performances ici est similaire à l'évaluation des performances des microservices API Web traditionnels, et les transactions dans les chaînes de blocs elles-mêmes peuvent être mises à jour et changer activement leur statut. En général, la mise à jour des informations de transaction dans certaines chaînes de blocs peut se produire plusieurs fois, par exemple, lors du basculement entre les fourches d'une chaîne ou lorsque BP informe de son intention d'inclure une transaction dans un bloc. Les limitations du volume de ce pool et du nombre de transactions qu'il contient peuvent affecter les performances de la blockchain. Si le pool de transactions est obstrué à la taille maximale possible ou ne tient pas dans la RAM, les performances du réseau peuvent chuter considérablement. Les blockchains n'ont pas de protection centralisée contre le flux de messages indésirables, et si la blockchain prend en charge des transactions à volume élevé et des frais peu élevés, cela peut entraîner un débordement du pool de transactions - c'est un autre goulot d'étranglement potentiel des performances.

Dans les chaînes de blocs, le client envoie la transaction à n'importe quel nœud de la chaîne de blocs qu'il aime, le hachage de la transaction est généralement connu du client avant l'envoi, donc tout ce qu'il doit faire est d'obtenir une connexion et après le transfert, attendre que la chaîne de blocs change d'état, en activant sa transaction. Notez qu'en mesurant "tps", vous pouvez obtenir des résultats complètement différents pour différentes façons de vous connecter à un nœud de chaîne de blocs. Il peut s'agir d'un RPC HTTP standard ou d'un WebSocket, vous permettant d'implémenter le modèle "subscribe". Dans le deuxième cas, le client recevra une notification plus tôt et le nœud dépensera moins de ressources (principalement de mémoire et de trafic) pour les réponses concernant l'état de la transaction. Ainsi, lorsque vous mesurez des "tps", vous devez considérer la façon dont les clients se connectent aux nœuds. Par conséquent, pour évaluer les risques de ce goulot d'étranglement, la référence de la blockchain doit pouvoir émuler des clients avec des requêtes WebSocket et HTTP RPC, en fractions correspondant à des réseaux réels, ainsi que changer 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 de la chaîne de blocs.

Transmission des transactions et des blocs sur un réseau p2p

Dans les chaînes de blocs, la mise en réseau peer-to-peer (p2p) est utilisée pour transférer entre les participants à la transaction et les blocs. Les transactions sont distribuées sur le réseau, en commençant par l'un des nœuds, jusqu'à ce qu'elles atteignent des blocs de pairs de producteurs qui regroupent les transactions en blocs et en utilisant le même p2p distribuent de nouveaux blocs sur tous les nœuds du réseau. La base de la plupart des réseaux p2p modernes est diverses modifications du protocole Kademlia. Voici un bon bref aperçu de ce protocole, et voici un article avec diverses mesures sur le réseau BitTorrent, selon lequel vous pouvez comprendre que ce type de réseau est plus compliqué et moins prévisible qu'un réseau de service centralisé configuré en dur. En outre, voici un article sur la mesure de diverses mesures intéressantes pour les nœuds Ethereum.

En bref, chaque homologue de ces réseaux maintient sa propre liste dynamique d'autres homologues qui demandent des blocs d'informations qui sont adressés par le contenu. À la réception de la demande, l'homologue donne les informations nécessaires ou transmet la demande à l'homologue pseudo-aléatoire suivant de la liste, et après avoir reçu la réponse, la transmet au demandeur et la met en cache pendant un certain temps, donnant ce bloc d'informations la prochaine fois plus tôt. Ainsi, les informations populaires apparaissent dans un grand nombre de caches chez un grand nombre de pairs, et les informations impopulaires sont progressivement évincées. Les pairs gardent une trace de qui a transmis la quantité d'informations à qui, et le réseau essaie de stimuler les distributeurs actifs en augmentant leur classement et en leur fournissant un niveau de service plus élevé, supprimant automatiquement les participants inactifs des listes de pairs.

Ainsi, la transaction doit maintenant être distribuée sur le réseau afin que les producteurs de blocs puissent la voir et l'inclure dans le bloc. Noda "distribue" activement une nouvelle transaction à tout le monde et écoute le réseau, en attente du bloc, dans l'index duquel la transaction nécessaire apparaîtra pour notifier le client en attente. Le temps jusqu'à ce que le réseau s'envoie des informations sur les nouvelles transactions et 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 réseau), le "réchauffement" du cache 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 de nombreux autres facteurs. La mesure complète des mesures de performance dans de tels réseaux est une question complexe, il est nécessaire d'évaluer simultanément le temps de traitement des demandes sur les clients et les pairs (nœuds de la chaîne de blocs). Des problèmes dans l'un des mécanismes p2p, une extrusion et une mise en cache des données incorrectes, une gestion inefficace des listes de pairs actives et de nombreux autres facteurs peuvent entraîner des retards qui affectent l'efficacité de l'ensemble du réseau dans son ensemble, et ce goulot d'étranglement est le plus difficile à analyser, tester et interprétation des résultats.

Traitement de la chaîne de blocs et mise à jour de la base de données d'état

La partie la plus importante du travail de la blockchain est l'algorithme de consensus, son application aux nouveaux blocs reçus du réseau et le traitement des transactions avec l'enregistrement des résultats dans la base de données d'état. L'ajout d'un nouveau bloc à la chaîne et la sélection ultérieure de la chaîne principale devraient fonctionner aussi rapidement que possible. Cependant, dans la vraie vie, «devrait» ne signifie pas «fonctionne», et vous pouvez, par exemple, imaginer une situation où deux longues chaînes concurrentes basculent constamment entre elles, changeant les métadonnées de milliers de transactions dans le pool à chaque commutateur, et annulant constamment l'état de la base de données d'état. Cette étape, en termes de détermination du goulot d'étranglement, est plus simple que la couche p2p du réseau, car l'exécution des transactions et l'algorithme de consensus sont strictement déterminés, et mesurer quoi que ce soit ici est plus facile.
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 donnent des blocs et des informations sur la chaîne principale plus lentement 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'inclure celles liées aux mises à 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 commutations entre les fourches de chaîne, le nombre de blocs invalides , temps d'exécution de la machine virtuelle, temps de validation des données, etc. Cela ne confondra pas les problèmes de réseau avec des erreurs dans les algorithmes de traitement en chaîne.

Une machine virtuelle exécutant des transactions peut être une source utile d'informations qui peut optimiser le fonctionnement de la blockchain. Le nombre d'allocations de mémoire, le nombre d'instructions de lecture / écriture et d'autres mesures concernant l'efficacité de l'exécution du code de contrat peuvent fournir de nombreuses informations utiles aux développeurs. Dans le même temps, les contrats intelligents sont des programmes, ce qui signifie qu'en théorie, ils peuvent consommer n'importe laquelle des ressources: processeur / mémoire / réseau / stockage, de sorte que le traitement des transactions est une étape assez incertaine, qui change en outre considérablement lors du passage d'une version à l'autre et lorsque changer le code des contrats. Par conséquent, des mesures concernant le traitement des transactions sont également nécessaires pour optimiser efficacement les performances de la blockchain.

Client recevant une notification d'inclusion de transaction dans la blockchain

C'est la dernière étape de la réception d'un service de blockchain par un client, par rapport aux autres étapes, il n'y a pas de gros frais généraux, mais cela vaut quand même la peine d'envisager la possibilité pour un client de recevoir une réponse en volume d'un nœud (par exemple, un contrat intelligent qui renvoie un tableau de données). En tout cas, ce moment est le plus important pour celui qui a posé la question «combien de tps sont dans votre blockchain?», Car à ce moment, l'heure de réception du service est fixée.

A cet endroit, il y a toujours un envoi du temps plein que le client a dû attendre une réponse de la blockchain, c'est cette fois que l'utilisateur attendra la confirmation dans sa candidature, et c'est son optimisation qui est la tâche principale des développeurs.

Conclusion

En conséquence, il est possible de décrire les types d'opérations effectuées sur les blockchains et de 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 chaîne de blocs à la base de données d'état, mettre à jour les données de transaction et de bloc
requêtes en lecture seule pour déclarer la base de données, l'API de la chaîne de blocs, les services d'abonnement

En général, les exigences techniques pour les nœuds des chaînes de blocs modernes sont extrêmement sérieuses - ce sont des processeurs rapides pour la cryptographie, une grande quantité de RAM afin de stocker et d'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 volumineux. Ces exigences élevées et l'abondance de divers types d'opérations conduisent inévitablement au fait que les ressources des nœuds peuvent ne pas être suffisantes, et alors l'une des étapes discutées ci-dessus peut devenir le prochain goulot d'étranglement pour les performances globales du réseau.

Lors du développement et de l'évaluation des performances des blockchains, vous devrez prendre en compte tous ces points. Pour ce faire, vous devez collecter et analyser des métriques à la fois auprès des clients et des nœuds de réseau, rechercher les corrélations entre eux, évaluer la durée de fourniture du service aux clients, prendre en compte toutes les ressources principales: cpu / mémoire / réseau / stockage, comprendre comment elles sont utilisées et s'influencer mutuellement. Tout cela fait que la comparaison des vitesses de différentes chaînes de blocs sous la forme de «combien de TPS» est une tâche extrêmement ingrate, car il existe un grand nombre de configurations et de conditions différentes. Dans les grands systèmes centralisés, des clusters de centaines de serveurs, ces problèmes sont également complexes et nécessitent également la collecte d'un grand nombre de mesures différentes, mais dans les chaînes de blocs, en raison des réseaux p2p, des machines virtuelles exécutant des contrats, de l'économie interne, le nombre de degrés de liberté est beaucoup plus important, ce qui rend le test beaucoup plus important, ce qui rend le test même sur plusieurs serveurs, il ne montre pas 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 d'une blockchain dans le noyau, pour évaluer les performances et répondre à la question «a-t-elle amélioré par rapport à la dernière fois», nous utilisons un logiciel assez compliqué, orchestrant le lancement de la blockchain avec des dizaines de nœuds et lançant automatiquement la référence et collectant des métriques, sans ces informations, il est extrêmement difficile de déboguer Protocoles qui fonctionnent avec de nombreux participants.

Donc, après avoir reçu la question «combien de TPS est dans votre blockchain?», Proposez à la personne à qui vous parlez du thé et découvrez s'il est prêt à se familiariser avec une douzaine de graphiques et écoutez également les trois boîtes de problèmes de performances de la blockchain et vos suggestions pour les résoudre ...

Combien de TPS sont dans votre blockchain?