{"id":36157,"date":"2019-10-31T22:09:55","date_gmt":"2019-10-31T19:09:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-tps-v-vashem-blokchejne\/"},"modified":"2019-10-31T22:09:55","modified_gmt":"2019-10-31T19:09:55","slug":"skolko-tps-v-vashem-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Combien de TPS y a-t-il dans votre blockchain ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La question pr\u00e9f\u00e9r\u00e9e de tout non-initi\u00e9 concernant un syst\u00e8me d\u00e9centralis\u00e9 est : \u00ab Combien de TPS y a-t-il dans votre blockchain ? \u00bb. Cependant, le chiffre donn\u00e9 en r\u00e9ponse a g\u00e9n\u00e9ralement peu \u00e0 voir avec ce que l'interlocuteur esp\u00e9rait entendre. En r\u00e9alit\u00e9, il voulait demander : \u00ab Votre blockchain r\u00e9pond-elle \u00e0 mes exigences commerciales ? \u00bb, et ces exigences ne se r\u00e9sument pas \u00e0 un seul chiffre, mais constituent un ensemble de conditions \u2014 ici, la r\u00e9silience du r\u00e9seau, les exigences de finalit\u00e9, la taille, la nature des transactions et de nombreux autres param\u00e8tres. Ainsi, la r\u00e9ponse \u00e0 la question \u00ab combien de TPS \u00bb ne sera probablement pas simple, et presque jamais compl\u00e8te. Un syst\u00e8me d\u00e9centralis\u00e9 avec des dizaines et des centaines de n\u0153uds ex\u00e9cutant des calculs relativement complexes peut se trouver dans un grand nombre d'\u00e9tats diff\u00e9rents, en rapport avec l'\u00e9tat du r\u00e9seau, le contenu de la blockchain, les pannes techniques, les probl\u00e8mes \u00e9conomiques, les attaques sur le r\u00e9seau et de nombreuses autres raisons. Les \u00e9tapes o\u00f9 des probl\u00e8mes de performance peuvent survenir diff\u00e8rent de celles des services traditionnels, et le serveur du r\u00e9seau blockchain est un service en r\u00e9seau combinant les fonctions d'une base de donn\u00e9es, d'un serveur web et d'un client torrent, ce qui le rend extr\u00eamement complexe en termes de profil de charge sur tous les sous-syst\u00e8mes : processeur, m\u00e9moire, r\u00e9seau, stockage.<\/p>\n

<\/p>\n

Il se trouve que les r\u00e9seaux d\u00e9centralis\u00e9s et les blockchains sont des logiciels assez sp\u00e9cifiques et peu familiers pour les d\u00e9veloppeurs de logiciels centralis\u00e9s. C'est pourquoi je voudrais mettre en lumi\u00e8re des aspects importants de la performance et de la r\u00e9silience des r\u00e9seaux d\u00e9centralis\u00e9s, ainsi que des approches pour les mesurer et identifier les goulets d'\u00e9tranglement. Nous examinerons divers probl\u00e8mes de performance qui limitent la rapidit\u00e9 de fourniture de services aux utilisateurs de blockchains et soulignerons les caract\u00e9ristiques sp\u00e9cifiques \u00e0 ce type de logiciel.<\/p>\n

<\/a><\/noindex><\/p>\n

\u00c9tapes de la demande de service par le client de la blockchain.<\/h2>\n

<\/p>\n

Pour parler honn\u00eatement de la qualit\u00e9 de tout service relativement complexe, il est n\u00e9cessaire de tenir compte non seulement des valeurs moyennes, mais aussi des valeurs maximales\/minimales, des m\u00e9dianes et des percentiles. Th\u00e9oriquement, on peut parler de 1000 tps dans une blockchain donn\u00e9e, mais si 900 transactions s'effectuent avec une grande rapidit\u00e9 et que 100 'se bloquent' pendant plusieurs secondes, la dur\u00e9e moyenne cumul\u00e9e pour toutes les transactions n'est pas tout \u00e0 fait une m\u00e9trique fiable pour un client qui n'a pas pu finaliser une transaction en quelques secondes. Les 'trous' temporels caus\u00e9s par des tours de consensus manqu\u00e9s ou la division du r\u00e9seau peuvent s\u00e9rieusement d\u00e9grader un service qui, sur des bancs d'essai, affichait de tr\u00e8s bonnes performances.<\/p>\n

<\/p>\n

Pour identifier de tels goulets d'\u00e9tranglement, il est n\u00e9cessaire de bien comprendre les \u00e9tapes aux cours desquelles une blockchain r\u00e9elle peut rencontrer des difficult\u00e9s \u00e0 servir les utilisateurs. D\u00e9crivons le cycle de livraison et de traitement des transactions, ainsi que l'obtention d'un nouvel \u00e9tat de la blockchain, permettant au client de s'assurer que sa transaction a \u00e9t\u00e9 trait\u00e9e et prise en compte.<\/p>\n

<\/p>\n

    \n
  1. la transaction se forme sur le client<\/li>\n
  2. la transaction est sign\u00e9e sur le client<\/li>\n
  3. le client choisit un des n\u0153uds et envoie sa transaction<\/li>\n
  4. le client s'abonne aux mises \u00e0 jour de la base de donn\u00e9es d'\u00e9tat du n\u0153ud, attendant les r\u00e9sultats de l'ex\u00e9cution de sa transaction<\/li>\n
  5. le n\u0153ud diffuse la transaction sur le r\u00e9seau p2p<\/li>\n
  6. plusieurs, ou un seul BP (block producer) traitent les transactions accumul\u00e9es, mettant \u00e0 jour la base de donn\u00e9es d'\u00e9tat<\/li>\n
  7. le BP forme un nouveau bloc, apr\u00e8s avoir trait\u00e9 le nombre requis de transactions<\/li>\n
  8. le BP diffuse le nouveau bloc sur le r\u00e9seau p2p<\/li>\n
  9. le nouveau bloc est livr\u00e9 au n\u0153ud auquel le client s'adresse<\/li>\n
  10. le n\u0153ud met \u00e0 jour la base de donn\u00e9es d'\u00e9tat<\/li>\n
  11. le n\u0153ud voit la mise \u00e0 jour concernant le client et lui envoie une notification sur sa transaction<\/li>\n<\/ol>\n

    <\/p>\n

    Examinons maintenant ces \u00e9tapes en d\u00e9tail et d\u00e9crivons les probl\u00e8mes potentiels de performance \u00e0 chaque \u00e9tape. Contrairement aux syst\u00e8mes centralis\u00e9s, nous allons \u00e9galement consid\u00e9rer l'ex\u00e9cution du code sur les clients du r\u00e9seau. Il arrive souvent que lors de la mesure du TPS, le temps de traitement des transactions soit recueilli \u00e0 partir des n\u0153uds, et non des clients - ce n'est pas tout \u00e0 fait juste. Pour le client, peu importe \u00e0 quelle vitesse le n\u0153ud a trait\u00e9 sa transaction, ce qui compte le plus pour lui, c'est le moment o\u00f9 l'information v\u00e9rifi\u00e9e sur cette transaction, int\u00e9gr\u00e9e dans la blockchain, lui sera accessible. Cette m\u00e9trique est en fait le temps d'ex\u00e9cution de la transaction. Cela signifie que diff\u00e9rents clients, m\u00eame en envoyant la m\u00eame transaction, peuvent avoir des temps compl\u00e8tement diff\u00e9rents, qui d\u00e9pendent du canal, de la charge et de la proximit\u00e9 du n\u0153ud, etc. Par cons\u00e9quent, il est essentiel de mesurer ce temps du c\u00f4t\u00e9 des clients, car c'est ce param\u00e8tre qu'il faut optimiser.<\/p>\n

    <\/p>\n

    Pr\u00e9paration de la transaction du c\u00f4t\u00e9 du client<\/h2>\n

    <\/p>\n

    Commen\u00e7ons par les deux premiers points : la transaction est form\u00e9e et sign\u00e9e par le client. \u00c9trangement, cela peut \u00eatre aussi un goulot d'\u00e9tranglement de la performance de la blockchain du point de vue du client. C'est inhabituel pour les services centralis\u00e9s, qui prennent tous les calculs et les op\u00e9rations de donn\u00e9es pour eux, tandis que le client pr\u00e9pare simplement une courte requ\u00eate capable de demander un grand volume de donn\u00e9es ou de calculs, recevant un r\u00e9sultat pr\u00eat. Dans les blockchains, le code client devient de plus en plus puissant, tandis que le noyau de la blockchain devient de plus en plus l\u00e9ger, et les t\u00e2ches de calcul massives sont traditionnellement confi\u00e9es au logiciel client. Dans les blockchains, il existe des clients qui peuvent pr\u00e9parer une seule transaction assez longtemps (je parle des diff\u00e9rents merkle proofs, succinct proofs, signatures seuil et d'autres op\u00e9rations complexes c\u00f4t\u00e9 client). Un bon exemple de v\u00e9rification on-chain l\u00e9g\u00e8re et de pr\u00e9paration lourde de la transaction c\u00f4t\u00e9 client est la preuve d'appartenance \u00e0 une liste bas\u00e9e sur un arbre Merkle. article<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Il ne faut pas oublier que le code client ne se contente pas d'envoyer des transactions \u00e0 la blockchain, mais commence par interroger l'\u00e9tat de la blockchain \u2014 cette activit\u00e9 peut affecter la congestion du r\u00e9seau et des n\u0153uds de blockchain. Ainsi, lors de la r\u00e9alisation de mesures, il est raisonnable d'\u00e9muler aussi fid\u00e8lement que possible le comportement du code client. M\u00eame si votre blockchain utilise des clients l\u00e9gers qui apposent une signature num\u00e9rique standard sur une simple transaction de transfert d'un actif, la quantit\u00e9 de calculs sur le client augmente chaque ann\u00e9e, les algorithmes cryptographiques se renforcent, et cette partie du traitement peut devenir un goulot d'\u00e9tranglement significatif \u00e0 l'avenir. Par cons\u00e9quent, soyez vigilant et ne manquez pas une situation o\u00f9, dans une transaction de 3,5 secondes, 2,5 secondes sont consacr\u00e9es \u00e0 la pr\u00e9paration et \u00e0 la signature de la transaction, et 1,0 seconde \u00e0 l'envoi sur le r\u00e9seau et \u00e0 l'attente de la r\u00e9ponse. Pour \u00e9valuer les risques de l'apparition de ce goulot d'\u00e9tranglement, il est n\u00e9cessaire de collecter des m\u00e9triques \u00e0 partir des machines clientes, et pas seulement des n\u0153uds de blockchain.<\/p>\n

    <\/p>\n

    Envoi de la transaction et suivi de son statut<\/h2>\n

    <\/p>\n

    L'\u00e9tape suivante consiste \u00e0 envoyer la transaction au n\u0153ud blockchain s\u00e9lectionn\u00e9 et \u00e0 obtenir le statut de son acceptation dans le pool de transactions. Cette \u00e9tape est similaire \u00e0 une requ\u00eate classique \u00e0 une base de donn\u00e9es, le n\u0153ud doit enregistrer la transaction dans le pool et commencer \u00e0 diffuser les informations \u00e0 son sujet via le r\u00e9seau p2p. L'approche pour \u00e9valuer la performance ici est semblable \u00e0 celle utilis\u00e9e pour \u00e9valuer le fonctionnement des microservices traditionnels via une API Web, d'autant plus que les transactions dans les blockchains peuvent \u00eatre mises \u00e0 jour, changeant activement de statut. En fait, la mise \u00e0 jour des informations sur une transaction dans certaines blockchains peut se produire plusieurs fois, par exemple lors de commutations entre des forks de cha\u00eenes ou lorsque des BP annoncent leur intention d'inclure une transaction dans un bloc. Les limitations sur la taille de ce pool et le nombre de transactions qu'il contient peuvent influencer la performance de la blockchain. Si le pool de transactions est plein \u00e0 sa capacit\u00e9 maximale, ou ne tient pas en m\u00e9moire vive, la performance du r\u00e9seau peut chuter brusquement. Les blockchains ne disposent pas de moyens centralis\u00e9s pour se prot\u00e9ger contre le flot de messages ind\u00e9sirables, et si la blockchain supporte des transactions de grande taille et des frais bas, cela peut mener \u00e0 un d\u00e9bordement du pool de transactions \u2014 c'est un autre goulot d'\u00e9tranglement potentiel en mati\u00e8re de performance.<\/p>\n

    <\/p>\n

    Dans les blockchains, le client envoie une transaction \u00e0 n'importe quel n\u0153ud de blockchain qui lui pla\u00eet, le hachage de la transaction \u00e9tant g\u00e9n\u00e9ralement connu du client avant l'envoi, donc tout ce dont il a besoin est d'\u00e9tablir une connexion et ensuite, une fois la transaction envoy\u00e9e, d'attendre que la blockchain modifie son \u00e9tat en y int\u00e9grant sa transaction. Notons qu'en mesurant le 'tps', on peut obtenir des r\u00e9sultats totalement diff\u00e9rents selon les m\u00e9thodes de connexion au n\u0153ud de blockchain. Cela peut \u00eatre un RPC HTTP classique ou un WebSocket, permettant de mettre en \u0153uvre le mod\u00e8le 'subscribe'. Dans le second cas, le client recevra une notification plus t\u00f4t, et le n\u0153ud utilisera moins de ressources (principalement de la m\u00e9moire et du trafic) pour r\u00e9pondre sur l'\u00e9tat de la transaction. Ainsi, lors de la mesure du 'tps', il est essentiel de prendre en compte la m\u00e9thode de connexion des clients aux n\u0153uds. Par cons\u00e9quent, pour \u00e9valuer les risques d'apparition de ce goulet d'\u00e9tranglement, le benchmark de la blockchain doit \u00eatre capable d'\u00e9muler des clients \u00e0 la fois avec des requ\u00eates WebSocket et HTTP RPC, dans des proportions correspondant aux r\u00e9seaux r\u00e9els, ainsi que de modifier la nature et la taille des transactions.<\/p>\n

    <\/p>\n

    Pour \u00e9valuer les risques d'apparition de ce goulet d'\u00e9tranglement, il est \u00e9galement important de collecter des m\u00e9triques depuis les machines clientes, et pas seulement depuis les n\u0153uds de la blockchain.<\/p>\n

    <\/p>\n

    Transmission de transactions et de blocs par un r\u00e9seau P2P<\/h2>\n

    <\/p>\n

    Dans les blockchains, le transfert de transactions et de blocs entre participants utilise le peer-to-peer (P2P) networking. Les transactions se propagent dans le r\u00e9seau \u00e0 partir d'un des n\u0153uds, jusqu'\u00e0 atteindre des pairs \u2014 des producteurs de blocs \u2014 qui empaquent les transactions en blocs et, \u00e0 l'aide du m\u00eame P2P, diffusent les nouveaux blocs \u00e0 tous les n\u0153uds du r\u00e9seau. La plupart des r\u00e9seaux P2P modernes reposent sur diff\u00e9rentes modifications du protocole Kademlia. Voici<\/a><\/noindex> un bon aper\u00e7u de ce protocole, et voici<\/a><\/noindex> \u2014 un article avec diverses mesures dans le r\u00e9seau BitTorrent, qui permet de comprendre que ce type de r\u00e9seau est plus complexe et moins pr\u00e9visible qu'un r\u00e9seau rigoureusement configur\u00e9 d'un service centralis\u00e9. De plus, voici<\/a><\/noindex> un article sur la mesure de diverses m\u00e9triques int\u00e9ressantes pour les n\u0153uds Ethereum.<\/p>\n

    <\/p>\n

    En r\u00e9sum\u00e9, chaque pair dans ce type de r\u00e9seau maintient sa propre liste dynamique d'autres pairs, \u00e0 partir de laquelle il demande des blocs d'informations, adress\u00e9s par leur contenu. Lorsqu'il re\u00e7oit une demande, un pair fournit soit l'information requise, soit transmet la demande \u00e0 un autre pair pseudo-al\u00e9atoire de sa liste. Une fois la r\u00e9ponse obtenue, il la renvoie \u00e0 la personne qui a demand\u00e9 et met temporairement cette information en cache, la fournissant plus rapidement la prochaine fois. Ainsi, les informations populaires se retrouvent dans de nombreux caches de divers pairs, tandis que les informations moins populaires sont progressivement \u00e9vinc\u00e9es. Les pairs tiennent compte de qui a transmis quoi, et le r\u00e9seau essaie de stimuler les contributeurs actifs en augmentant leur classement et en leur offrant un meilleur niveau de service, tout en \u00e9vincant automatiquement les participants inactifs des listes de pairs.<\/p>\n

    <\/p>\n

    Ainsi, la transaction doit maintenant \u00eatre diffus\u00e9e \u00e0 travers le r\u00e9seau pour que les producteurs de blocs la voient et l'incluent dans un bloc. Le n\u0153ud \u00ab distribue \u00bb activement la nouvelle transaction \u00e0 tous les int\u00e9ress\u00e9s et \u00e9coute le r\u00e9seau en attendant un bloc dans l'index qui contiendra la transaction n\u00e9cessaire afin de notifier le client en attente. Le temps que le r\u00e9seau utilise pour s\u2019\u00e9changer des informations sur les nouvelles transactions et blocs dans les r\u00e9seaux p2p d\u00e9pend d'un tr\u00e8s grand nombre de facteurs : le nombre de n\u0153uds honn\u00eates et actifs \u00e0 proximit\u00e9 (d'un point de vue r\u00e9seau), la \u00ab temp\u00e9rature \u00bb des caches de ces n\u0153uds, la taille des blocs, des transactions, la nature des changements, la g\u00e9ographie du r\u00e9seau, le nombre de n\u0153uds et bien d'autres facteurs. Mesurer de mani\u00e8re complexe les m\u00e9triques de performance dans ces r\u00e9seaux est une t\u00e2che complexe ; il est n\u00e9cessaire d'\u00e9valuer simultan\u00e9ment le temps de traitement des requ\u00eates tant sur les clients que sur les pairs (n\u0153uds blockchain). Des probl\u00e8mes dans l'un des m\u00e9canismes p2p, un \u00e9crasement ou un cache de donn\u00e9es incorrect, la gestion inefficace des listes de pairs actifs et de nombreux autres facteurs peuvent entra\u00eener des retards qui nuisent \u00e0 l'efficacit\u00e9 de tout le r\u00e9seau, et ce goulet d'\u00e9tranglement est le plus difficile \u00e0 analyser, tester et interpr\u00e9ter.<\/p>\n

    <\/p>\n

    Traitement de la cha\u00eene de blocs et mise \u00e0 jour de la base de donn\u00e9es d'\u00e9tat<\/h2>\n

    <\/p>\n

    La partie la plus importante du fonctionnement de la blockchain est l'algorithme de consensus, son application aux nouveaux blocs re\u00e7us du r\u00e9seau et le traitement des transactions avec enregistrement des r\u00e9sultats dans la base de donn\u00e9es d'\u00e9tat. L'ajout d'un nouveau bloc \u00e0 la cha\u00eene et la s\u00e9lection de la cha\u00eene principale qui suit doit se faire le plus rapidement possible. Cependant, dans la r\u00e9alit\u00e9, \u00ab doit \u00bb ne signifie pas \u00ab fonctionne \u00bb, et l'on peut par exemple imaginer une situation o\u00f9 deux longues cha\u00eenes concurrentes alternent constamment, changeant les m\u00e9tadonn\u00e9es de milliers de transactions dans le pool \u00e0 chaque changement, et provoquant des retours en arri\u00e8re constants dans l'\u00e9tat de la base de donn\u00e9es d'\u00e9tat. Cette \u00e9tape, en termes de d\u00e9finition de goulet d'\u00e9tranglement, est plus simple que la couche r\u00e9seau p2p, car l'ex\u00e9cution des transactions et l'algorithme de consensus sont strictement d\u00e9terministes, et il est plus simple de mesurer quoi que ce soit ici.
    \nL'essentiel est de ne pas confondre la d\u00e9gradation al\u00e9atoire des performances \u00e0 ce stade avec des probl\u00e8mes de r\u00e9seau : les n\u0153uds d\u00e9livrent plus lentement les blocs et les informations sur la cha\u00eene principale et, pour le client externe, cela peut ressembler \u00e0 un r\u00e9seau lent, bien que le probl\u00e8me se cache en r\u00e9alit\u00e9 ailleurs.<\/p>\n

    <\/p>\n

    Pour optimiser les performances \u00e0 ce stade, il est utile de collecter et de surveiller les m\u00e9triques provenant des n\u0153uds eux-m\u00eames, en incluant celles qui concernent la mise \u00e0 jour de la base de donn\u00e9es d'\u00e9tat : le nombre de blocs trait\u00e9s sur le n\u0153ud, leur taille, le nombre de transactions, le nombre de basculements entre les branches de la cha\u00eene, le nombre de blocs invalides, le temps d'ex\u00e9cution de la machine virtuelle, le temps de validation des donn\u00e9es, etc. Cela permettra de ne pas confondre les probl\u00e8mes de r\u00e9seau avec les erreurs dans les algorithmes de traitement des cha\u00eenes.<\/p>\n

    <\/p>\n

    La machine virtuelle traitant les transactions peut \u00eatre une source d'information utile pour optimiser le fonctionnement de la blockchain. Le nombre d'allocations de m\u00e9moire, le nombre d'instructions de lecture\/\u00e9criture et d'autres m\u00e9triques concernant l'efficacit\u00e9 de l'ex\u00e9cution du code des contrats peuvent fournir beaucoup d'informations pr\u00e9cieuses aux d\u00e9veloppeurs. En m\u00eame temps, les contrats intelligents sont des programmes, et donc, en th\u00e9orie, ils peuvent consommer n'importe lequel des ressources : cpu\/m\u00e9moire\/r\u00e9seau\/stockage, donc le traitement des transactions est une \u00e9tape assez ind\u00e9finie, qui de plus change consid\u00e9rablement lors des transitions entre les versions et lors du changement de code des contrats. Par cons\u00e9quent, les m\u00e9triques concernant le traitement des transactions sont \u00e9galement n\u00e9cessaires pour une optimisation efficace des performances de la blockchain.<\/p>\n

    <\/p>\n

    Notification to the client about the transaction being included in the blockchain<\/h2>\n

    <\/p>\n

    C'est la derni\u00e8re \u00e9tape pour qu'un client obtienne un service blockchain. Compar\u00e9 aux autres \u00e9tapes, il n'y a pas de co\u00fbts g\u00e9n\u00e9raux importants ici, mais il faut tout de m\u00eame prendre en compte la possibilit\u00e9 d'une r\u00e9ponse volumineuse du n\u0153ud (par exemple, un contrat intelligent renvoyant un tableau de donn\u00e9es). En tout cas, c'est ce moment qui est le plus important pour celui qui a pos\u00e9 la question \u00ab combien de tps y a-t-il dans votre blockchain ? \u00bb, car c'est \u00e0 ce moment-l\u00e0 que le temps de r\u00e9ception du service est enregistr\u00e9. <\/p>\n

    <\/p>\n

    At this point, the total time spent by the client waiting for a response from the blockchain must be forwarded. This is the time the user will expect confirmation in their application, and optimizing it is the main task for developers.<\/p>\n

    <\/p>\n

    Conclusion<\/h1>\n

    <\/p>\n

    As a result, we can describe the types of operations performed in blockchains and divide them into several categories:<\/p>\n

    <\/p>\n

      \n
    1. cryptographic transformations, proof construction<\/li>\n
    2. peer-to-peer networking, transaction and block replication<\/li>\n
    3. transaction processing, execution of smart contracts<\/li>\n
    4. applying changes in the blockchain to the state database, updating transaction and block data<\/li>\n
    5. read-only queries to the state database, API of the blockchain node, subscription services <\/li>\n<\/ol>\n

      <\/p>\n

      In general, the technical requirements for nodes of modern blockchains are extremely serious \u2014 fast CPUs for cryptography, large amounts of RAM to store and quickly access the state database, network interactions using many simultaneously open connections, extensive storage. Such high demands and the abundance of various types of operations inevitably lead to the situation where nodes may lack resources, making any of the above stages a potential bottleneck for the overall network performance.<\/p>\n

      <\/p>\n

      Lors de la conception et de l'\u00e9valuation des performances des blockchains, vous devez prendre en compte tous ces aspects. Pour cela, il est n\u00e9cessaire de collecter et d'analyser simultan\u00e9ment les m\u00e9triques des clients et des n\u0153uds du r\u00e9seau, de rechercher des corr\u00e9lations entre eux, d'\u00e9valuer le temps de fourniture de services aux clients, de prendre en compte toutes les ressources principales : cpu\/m\u00e9moire\/r\u00e9seau\/stockage, et de comprendre comment elles sont utilis\u00e9es et s'influencent mutuellement. Tout cela rend la comparaison des vitesses de diff\u00e9rentes blockchains sous la forme \u00ab combien de TPS \u00bb extr\u00eamement ingrate, car il existe un grand nombre de configurations et d'\u00e9tats diff\u00e9rents. Dans les grands syst\u00e8mes centralis\u00e9s, avec des clusters de centaines de serveurs, ces probl\u00e8mes sont \u00e9galement complexes et n\u00e9cessitent la collecte d'un grand nombre de m\u00e9triques diff\u00e9rentes, mais dans les blockchains, en raison des r\u00e9seaux p2p, des machines virtuelles et des contrats traitant, de l'\u00e9conomie interne, le nombre de degr\u00e9s de libert\u00e9 est beaucoup plus \u00e9lev\u00e9, ce qui rend m\u00eame les tests sur plusieurs serveurs peu repr\u00e9sentatifs et ne montrant que des valeurs tr\u00e8s approximatives, presque sans lien avec la r\u00e9alit\u00e9.<\/p>\n

      <\/p>\n

      Donc, lors du d\u00e9veloppement dans le noyau de la blockchain, pour \u00e9valuer les performances et r\u00e9pondre \u00e0 la question \u00ab est-ce que cela s'est am\u00e9lior\u00e9 par rapport \u00e0 la derni\u00e8re fois ? \u00bb, nous utilisons un logiciel assez complexe qui orchestre le d\u00e9marrage de la blockchain avec des dizaines de n\u0153uds et un d\u00e9marrage automatique du benchmark et de la collecte de m\u00e9triques. Sans ces informations, il est extr\u00eamement difficile de d\u00e9boguer les protocoles fonctionnant avec de nombreux participants.<\/p>\n

      <\/p>\n

      Ainsi, lorsque vous recevez la question \u00ab combien de TPS y a-t-il dans votre blockchain ? \u00bb, proposez une tasse de th\u00e9 \u00e0 votre interlocuteur et pr\u00e9cisez s'il est pr\u00eat \u00e0 examiner une dizaine de graphiques, ainsi qu'\u00e0 \u00e9couter les trois grands ensembles de probl\u00e8mes de performance des blockchains et vos propositions pour les r\u00e9soudre...<\/p>\n

      Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d. \u041e\u0434\u043d\u0430\u043a\u043e, \u043d\u0430\u0437\u0432\u0430\u043d\u043d\u043e\u0435 \u0432 \u043e\u0442\u0432\u0435\u0442 \u0447\u0438\u0441\u043b\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u0438\u043c\u0435\u0435\u0442 \u043c\u0430\u043b\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0443\u0441\u043b\u044b\u0448\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0448\u0430\u044e\u0449\u0438\u0439. \u041d\u0430 \u0434\u0435\u043b\u0435, \u043e\u043d \u0445\u043e\u0442\u0435\u043b \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c \u201c\u043f\u043e\u0434\u043e\u0439\u0434\u0435\u0442 \u043b\u0438 \u0432\u0430\u0448 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u043f\u043e\u0434 \u043c\u043e\u0438 \u0431\u0438\u0437\u043d\u0435\u0441 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u201d, \u0438 \u044d\u0442\u0438 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u043d\u0435 \u043e\u0434\u043d\u043e \u0447\u0438\u0441\u043b\u043e, \u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u043b\u043e\u0432\u0438\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36157","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Combien de TPS dans votre blockchain ? | ProHoster","description":"La question pr\u00e9f\u00e9r\u00e9e de tout sp\u00e9cialiste non technique sur n'importe quel syst\u00e8me distribu\u00e9 est \u00ab Combien de TPS dans votre blockchain ? \u00bb","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043a\u043e\u043b\u044c\u043a\u043e TPS \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435? | ProHoster","og:description":"\u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:09:55+00:00","article:modified_time":"2019-10-31T19:09:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36157","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:15:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:49:44","updated":"2026-01-22 02:15:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}