{"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\/de\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Wie viele TPS gibt es in Ihrer Blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die liebste Frage eines nicht-technischen Spezialisten zu jedem verteilten System lautet: \u201eWie viele TPS hat Ihre Blockchain?\u201c. Allerdings hat die Zahl, die als Antwort genannt wird, normalerweise wenig mit dem zu tun, was der Fragesteller h\u00f6ren m\u00f6chte. Tats\u00e4chlich wollte er fragen: \u201eEignet sich Ihre Blockchain f\u00fcr meine gesch\u00e4ftlichen Anforderungen?\u201c, und diese Anforderungen sind keine einzelne Zahl, sondern eine Vielzahl von Bedingungen - hierzu geh\u00f6ren die Ausfallsicherheit des Netzwerks, Anforderungen an die Endg\u00fcltigkeit, Gr\u00f6\u00dfen, Charakter der Transaktionen und viele andere Parameter. Daher wird die Antwort auf die Frage \u201eWie viele TPS?\u201c kaum einfach sein und fast nie vollst\u00e4ndig. Ein verteiltes System mit Dutzenden und Hunderten von Knoten, die recht komplexe Berechnungen durchf\u00fchren, kann sich in einer riesigen Anzahl verschiedener Zust\u00e4nde befinden, die mit dem Zustand des Netzwerks, dem Inhalt der Blockchain, technischen Ausf\u00e4llen, wirtschaftlichen Problemen, Angriffen auf das Netzwerk und vielen anderen Gr\u00fcnden verbunden sind. Die Phasen, in denen Leistungsprobleme auftreten k\u00f6nnen, unterscheiden sich von den traditionellen Diensten, und der Server eines Blockchain-Netzwerks ist ein Netzwerkdienst, der die Funktionen einer Datenbank, eines Webservers und eines Torrent-Clients kombiniert, was ihn in Bezug auf das Lastprofil f\u00fcr alle Subsysteme - Prozessor, Speicher, Netzwerk, Speicher - \u00e4u\u00dferst komplex macht.<\/p>\n

<\/p>\n

Es hat sich ergeben, dass dezentrale Netzwerke und Blockchains eine ziemlich spezielle und ungewohnte Software f\u00fcr Entwickler zentralisierter Software sind. Daher m\u00f6chte ich wichtige Aspekte der Leistung und Stabilit\u00e4t dezentraler Netzwerke, Ans\u00e4tze zu deren Messung und Ermittlung von Engp\u00e4ssen beleuchten. Wir werden verschiedene Leistungsprobleme betrachten, die die Geschwindigkeit der Bereitstellung von Dienstleistungen an Benutzer von Blockchains einschr\u00e4nken, und die Merkmale hervorheben, die f\u00fcr diese Art von Software typisch sind.<\/p>\n

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

Phasen der Diensteanforderung durch den Blockchain-Client<\/h2>\n

<\/p>\n

Um ehrlich \u00fcber die Qualit\u00e4t eines jeden komplexeren Services sprechen zu k\u00f6nnen, m\u00fcssen nicht nur Durchschnittswerte, sondern auch die Maximal-\/Minimalwerte, Mediane und Perzentile ber\u00fccksichtigt werden. Theoretisch kann man von 1000 TPS in einer Blockchain sprechen, aber wenn 900 Transaktionen mit enormer Geschwindigkeit ausgef\u00fchrt werden und 100 \u201ah\u00e4ngen bleiben\u2018 und einige Sekunden ben\u00f6tigen, dann ist die Durchschnittszeit aller Transaktionen nicht unbedingt eine ehrliche Kennzahl f\u00fcr einen Kunden, der seine Transaktion innerhalb weniger Sekunden abschlie\u00dfen wollte. Zeitliche \u201aGruben\u2018, die durch ausgelassene Konsensrunden oder Netzwerkteilungen verursacht werden, k\u00f6nnen den Service stark beeintr\u00e4chtigen, der in Tests hervorragende Leistungen zeigte.<\/p>\n

<\/p>\n

Um solche Engp\u00e4sse zu identifizieren, ist es notwendig, die Phasen gut zu verstehen, in denen eine echte Blockchain Schwierigkeiten bei der Bedienung der Benutzer haben kann. Lassen Sie uns den Lieferservice- und Verarbeitungszyklus von Transaktionen sowie den Erhalt eines neuen Zustands der Blockchain beschreiben, aus dem der Kunde best\u00e4tigen kann, dass seine Transaktion verarbeitet und erfasst wurde.<\/p>\n

<\/p>\n

    \n
  1. Die Transaktion wird auf dem Client erstellt<\/li>\n
  2. Die Transaktion wird auf dem Client signiert<\/li>\n
  3. Der Client w\u00e4hlt einen der Knoten und sendet seine Transaktion an ihn<\/li>\n
  4. Der Client abonniert die Updates der State-Datenbank des Knotens und wartet auf das Ergebnis der Ausf\u00fchrung seiner Transaktion<\/li>\n
  5. Der Knoten verbreitet die Transaktion im P2P-Netzwerk<\/li>\n
  6. Einige oder ein Blockproduzent (BP) verarbeitet die gesammelten Transaktionen und aktualisiert die State-Datenbank<\/li>\n
  7. Der BP erstellt einen neuen Block, indem er die erforderliche Anzahl von Transaktionen verarbeitet<\/li>\n
  8. Der BP verbreitet den neuen Block im P2P-Netzwerk<\/li>\n
  9. Der neue Block wird an den Knoten geliefert, auf den der Client zugreift<\/li>\n
  10. Der Knoten aktualisiert die State-Datenbank<\/li>\n
  11. Der Knoten sieht das Update bez\u00fcglich des Clients und sendet ihm eine Benachrichtigung \u00fcber die Transaktion<\/li>\n<\/ol>\n

    <\/p>\n

    Jetzt lassen Sie uns diese Phasen genauer betrachten und die potenziellen Leistungsprobleme in jeder Phase beschreiben. Im Gegensatz zu zentralisierten Systemen werden wir auch die Ausf\u00fchrung des Codes auf den Clients im Netzwerk betrachten. Oft wird beim Messen von TPS die Verarbeitungszeit von Transaktionen von Knoten und nicht vom Client erfasst \u2013 das ist nicht ganz fair. Es interessiert den Client nicht, wie schnell der Knoten seine Transaktion verarbeitet hat; das Wichtigste f\u00fcr ihn ist der Moment, in dem ihm die verifizierte Information \u00fcber diese Transaktion, die in die Blockchain aufgenommen wurde, zur Verf\u00fcgung steht. Diese Metrik ist im Grunde die Ausf\u00fchrungszeit der Transaktion. Das bedeutet, dass verschiedene Clients, selbst wenn sie dieselbe Transaktion senden, ganz unterschiedliche Zeiten erhalten k\u00f6nnen, die vom Kanal, der Auslastung und der N\u00e4he des Knotens abh\u00e4ngen usw. Daher ist es unbedingt erforderlich, diese Zeit auf den Clients zu messen, da dieser Parameter optimiert werden muss.<\/p>\n

    <\/p>\n

    Vorbereitung der Transaktion auf der Clientseite<\/h2>\n

    <\/p>\n

    Beginnen wir mit den ersten beiden Punkten: Die Transaktion wird vom Client erstellt und signiert. Merkw\u00fcrdigerweise kann dies auch ein Engpass f\u00fcr die Leistung der Blockchain aus Sicht des Clients sein. Dies ist ungewohnt f\u00fcr zentralisierte Dienste, die alle Berechnungen und Datenoperationen f\u00fcr sich beanspruchen, w\u00e4hrend der Client einfach eine kurze Anfrage vorbereitet, die in der Lage ist, gro\u00dfe Datenmengen oder Berechnungen anzufordern und das fertige Ergebnis zu erhalten. In Blockchains wird der Client-Code immer leistungsf\u00e4higer, w\u00e4hrend der Blockchain-Kern immer leichter wird, und umfangreiche Rechenaufgaben werden \u00fcblicherweise an die Client-Software \u00fcbertragen. In Blockchains gibt es Clients, die eine Transaktion recht lange vorbereiten k\u00f6nnen (ich spreche von verschiedenen Merkle-Proofs, succinct proofs, threshold signatures und anderen komplexen Operationen auf der Clientseite). Ein gutes Beispiel f\u00fcr eine einfache On-Chain-\u00dcberpr\u00fcfung und die anspruchsvolle Vorbereitung der Transaktion auf dem Client ist der Nachweis der Zugeh\u00f6rigkeit zu einer Liste basierend auf einem Merkle-Baum. Artikel<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Es ist auch wichtig zu beachten, dass der Client-Code nicht einfach Transaktionen an die Blockchain sendet, sondern zuerst den Zustand der Blockchain abfragt \u2013 und diese Aktivit\u00e4t kann die Auslastung des Netzwerks und der Blockchain-Knoten beeinflussen. Daher ist es sinnvoll, bei den Messungen das Verhalten des Client-Codes so genau wie m\u00f6glich zu emulieren. Selbst wenn in Ihrer Blockchain \u00fcbliche leichte Clients vorhanden sind, die eine normale digitale Signatur f\u00fcr eine einfache Transaktion zur \u00dcbertragung eines Verm\u00f6genswerts setzen, steigt mit jedem Jahr die Rechenleistung auf der Client-Seite an, die Kryptoalgorithmen werden robuster und dieser Teil der Verarbeitung k\u00f6nnte in der Zukunft zu einem erheblichen Engpass werden. Seien Sie also vorsichtig und \u00fcbersehen Sie nicht, dass in einer Transaktion, die 3,5 Sekunden dauert, 2,5 Sekunden f\u00fcr die Vorbereitung und Unterzeichnung der Transaktion ben\u00f6tigt werden und 1,0 Sekunden f\u00fcr den Versand an das Netzwerk und das Warten auf eine Antwort. Um das Risiko eines solchen Engpasses zu bewerten, m\u00fcssen Metriken von den Client-Maschinen gesammelt werden, nicht nur von den Blockchain-Knoten.<\/p>\n

    <\/p>\n

    \u00dcbermittlung der Transaktion und \u00dcberwachung ihres Status<\/h2>\n

    <\/p>\n

    Der n\u00e4chste Schritt besteht darin, die Transaktion an den gew\u00e4hlten Blockchain-Knoten zu senden und den Status ihrer Aufnahme in den Transaktionspool zu erhalten. Dieser Schritt \u00e4hnelt einem normalen Datenbankaufruf, der Knoten muss die Transaktion in den Pool einf\u00fcgen und beginnen, Informationen dar\u00fcber \u00fcber das P2P-Netzwerk zu verbreiten. Der Ansatz zur Leistungsbewertung ist hier \u00e4hnlich wie bei der Bewertung der Funktionsweise traditioneller Microservices \u00fcber Web-APIs, wobei die Transaktionen in den Blockchains aktualisiert werden k\u00f6nnen und aktiv ihren Status \u00e4ndern. Tats\u00e4chlich kann die Aktualisierung von Informationen \u00fcber eine Transaktion in einigen Blockchains mehrmals erfolgen, zum Beispiel beim Wechseln zwischen Forks der Kette oder wenn BP mitteilen, dass sie beabsichtigen, die Transaktion in einen Block aufzunehmen. Einschr\u00e4nkungen bei der Gr\u00f6\u00dfe dieses Pools und der Anzahl der Transaktionen darin k\u00f6nnen die Leistung der Blockchain beeinflussen. Wenn der Transaktionspool auf die maximal m\u00f6gliche Gr\u00f6\u00dfe gef\u00fcllt ist oder nicht in den Arbeitsspeicher passt, kann die Netzwerkleistung stark sinken. Blockchains haben keine zentralisierten Mittel zum Schutz vor dem Fluss von Spam-Nachrichten, und wenn die Blockchain Transaktionen mit hohem Volumen und niedrigen Geb\u00fchren unterst\u00fctzt, kann dies zu einer \u00dcberf\u00fcllung des Transaktionspools f\u00fchren \u2013 dies ist ein weiterer potenzieller Engpass bei der Leistung.<\/p>\n

    <\/p>\n

    In Blockchains sendet der Kunde die Transaktion an einen beliebigen Knoten der Blockchain, der Hash der Transaktion ist in der Regel dem Kunden noch vor dem Senden bekannt, sodass alles, was er braucht, die Verbindung herzustellen und nach der \u00dcbertragung darauf zu warten, dass die Blockchain ihren Zustand \u00e4ndert und seine Transaktion aufnimmt. Es sei darauf hingewiesen, dass bei der Messung von \u201aTPS\u2018 v\u00f6llig unterschiedliche Ergebnisse f\u00fcr verschiedene Verbindungsarten zum Knoten der Blockchain erzielt werden k\u00f6nnen. Dies kann ein gew\u00f6hnlicher HTTP RPC oder ein WebSocket sein, der das \u201aSubscribe\u2018-Muster erm\u00f6glicht. Im zweiten Fall erh\u00e4lt der Kunde fr\u00fcher eine Benachrichtigung, und der Knoten ben\u00f6tigt weniger Ressourcen (haupts\u00e4chlich Speicher und Datenverkehr), um den Status der Transaktion zu melden. Daher ist es wichtig, beim Messen von \u201aTPS\u2018 die Art der Verbindung der Kunden zu den Knoten zu ber\u00fccksichtigen. Deshalb sollte der Benchmark der Blockchain in der Lage sein, sowohl WebSocket- als auch HTTP RPC-Anfragen zu emulieren, in Anteilen, die realen Netzwerken entsprechen, sowie die Art und Gr\u00f6\u00dfe der Transaktionen zu \u00e4ndern.<\/p>\n

    <\/p>\n

    Um die Risiken des Auftretens dieses Bottleneck zu bewerten, m\u00fcssen auch Metriken von den Client-Maschinen gesammelt werden, und nicht nur von den Blockchain-Knoten.<\/p>\n

    <\/p>\n

    \u00dcbertragung von Transaktionen und Bl\u00f6cken \u00fcber ein p2p-Netzwerk<\/h2>\n

    <\/p>\n

    In Blockchains wird zur \u00dcbertragung von Transaktionen und Bl\u00f6cken zwischen den Teilnehmern eine Peer-to-Peer (p2p) Netzwerkarchitektur verwendet. Transaktionen verbreiten sich im Netzwerk, beginnend von einem der Knoten, bis sie die Peer-Blockproduzenten erreichen, die die Transaktionen in Bl\u00f6cke verpacken und \u00fcber dasselbe p2p-Netzwerk die neuen Bl\u00f6cke an alle Knoten im Netzwerk verbreiten. Die Grundlage der meisten modernen p2p-Netze sind verschiedene Modifikationen des Kademlia-Protokolls. Hier<\/a><\/noindex> eine gute kurze \u00dcbersicht \u00fcber dieses Protokoll, und hier<\/a><\/noindex> \u2014 ein Artikel mit verschiedenen Messungen im BitTorrent-Netzwerk, aus dem man erkennen kann, dass diese Art von Netzwerken komplexer und weniger vorhersehbar ist als ein starr konfiguriertes Netzwerk eines zentralisierten Dienstes. Au\u00dferdem, hier<\/a><\/noindex> ein Artikel \u00fcber die Messung verschiedener interessanter Metriken f\u00fcr Ethereum-Knoten.<\/p>\n

    <\/p>\n

    Kurz gesagt, jeder Peer in solchen Netzwerken f\u00fchrt seine eigene dynamische Liste von anderen Peers, von denen er Informationsbl\u00f6cke anfordert, die nach ihrem Inhalt adressiert sind. Bei Eingang einer Anfrage gibt der Peer entweder die ben\u00f6tigten Informationen weiter oder leitet die Anfrage an den n\u00e4chsten pseudo-zuf\u00e4lligen Peer in der Liste weiter. Nach Erhalt der Antwort \u00fcbermittelt er diese an den anfragenden und speichert sie f\u00fcr eine Weile im Cache, sodass er diesen Block bei der n\u00e4chsten Anfrage schneller bereitstellen kann. Dadurch befindet sich beliebte Information in einem gro\u00dfen Anteil der Caches vieler Peers, w\u00e4hrend unpopul\u00e4re Informationen allm\u00e4hlich verdr\u00e4ngt werden. Peers halten dar\u00fcber Buch, wer wie viel Informationen \u00fcbermittelt hat, und das Netzwerk versucht, aktive Geber zu belohnen, indem es ihre Bewertung erh\u00f6ht und ihnen einen h\u00f6heren Service-Level bieten, w\u00e4hrend inaktive Teilnehmer automatisch aus den Peerl Listen entfernt werden.<\/p>\n

    <\/p>\n

    Um die Transaktion zu verbreiten, muss sie nun im Netzwerk bekannt gemacht werden, damit die Blockproduzenten sie sehen und in einen Block einf\u00fcgen k\u00f6nnen. Der Knoten \u201everteilt\u201c aktiv die neue Transaktion an alle Interessierten und h\u00f6rt im Netzwerk zu, in der Erwartung, einen Block zu empfangen, in dessen Index die ben\u00f6tigte Transaktion erscheinen wird, um den wartenden Kunden zu benachrichtigen. Die Zeit, die das Netzwerk ben\u00f6tigt, um Informationen \u00fcber neue Transaktionen und Bl\u00f6cke in P2P-Netzwerken auszutauschen, h\u00e4ngt von einer Vielzahl von Faktoren ab: der Anzahl der ehrlichen, benachbarten (aus netzwerktechnischer Sicht) Knoten, der \u201eVorw\u00e4rmung\u201c der Caches dieser Knoten, der Gr\u00f6\u00dfe der Bl\u00f6cke, der Transaktionen, der Art der \u00c4nderungen, der Geographie des Netzwerks, der Anzahl der Knoten und vielen weiteren Faktoren. Komplexe Messungen der Leistungsmetriken in solchen Netzwerken sind eine anspruchsvolle Angelegenheit; es ist notwendig, die Bearbeitungszeiten sowohl auf den Clients als auch auf den Peers (Blockchain-Knoten) gleichzeitig zu bewerten. Probleme in einem der P2P-Mechanismen, falsches Vorladen und Caching von Daten, ineffizientes Management von Listen aktiver Peers und viele andere Faktoren k\u00f6nnen zu Verz\u00f6gerungen f\u00fchren, die die Effizienz des gesamten Netzwerks beeintr\u00e4chtigen, und dieser Engpass ist der schwierigste zu analysieren, zu testen und die Ergebnisse zu interpretieren.<\/p>\n

    <\/p>\n

    Verarbeitung der Blockkette und Aktualisierung der Statusdatenbank<\/h2>\n

    <\/p>\n

    Der wichtigste Teil der Arbeit der Blockchain ist der Konsensalgorithmus, seine Anwendung auf neue, aus dem Netzwerk erhaltene Bl\u00f6cke und die Verarbeitung von Transaktionen mit der Aufzeichnung der Ergebnisse in der Zustandsdatenbank. Das Hinzuf\u00fcgen eines neuen Blocks zur Kette und die darauf folgende Auswahl der Hauptkette sollten so schnell wie m\u00f6glich erfolgen. In der Realit\u00e4t bedeutet \u201esollte\u201c jedoch nicht \u201efunktioniert\u201c, und man kann sich beispielsweise eine Situation vorstellen, in der zwei lange konkurrierende Ketten st\u00e4ndig zwischen einander umschalten, die Metadaten von Tausenden von Transaktionen im Pool bei jedem Wechsel \u00e4ndern und kontinuierliche Rollbacks des Zustands der Zustandsdatenbank durchf\u00fchren. Diese Phase ist in Bezug auf die Identifizierung des Engpasses einfacher als die Netzwerkschicht, da die Ausf\u00fchrung von Transaktionen und der Konsensalgorithmus strikt deterministisch sind und es einfacher ist, hier irgendetwas zu messen.
    \nEs ist wichtig, zuf\u00e4llige Leistungseinbu\u00dfen in diesem Abschnitt nicht mit Netzwerkproblemen zu verwechseln \u2014 Knoten geben Bl\u00f6cke und Informationen \u00fcber die Hauptkette langsamer weiter, was f\u00fcr den externen Kunden wie ein langsames Netzwerk erscheinen kann, obwohl das Problem ganz woanders liegt.<\/p>\n

    <\/p>\n

    Zur Optimierung der Leistung in diesem Abschnitt ist es n\u00fctzlich, Metriken von den Knoten zu sammeln und zu \u00fcberwachen, einschlie\u00dflich derjenigen, die sich auf die Aktualisierung der Zustandsdatenbank beziehen: die Anzahl der Bl\u00f6cke, die auf dem Knoten verarbeitet werden, ihre Gr\u00f6\u00dfe, die Anzahl der Transaktionen, die Anzahl der Umschaltungen zwischen Ketten-Forks, die Anzahl der ung\u00fcltigen Bl\u00f6cke, die Laufzeit der virtuellen Maschine, die Zeit zur Datenspeicherung usw. Dies erm\u00f6glicht es, Netzwerkprobleme nicht mit Fehlern in den Algorithmen der Kettenverarbeitung zu verwechseln.<\/p>\n

    <\/p>\n

    Die mit der Verarbeitung von Transaktionen befasste virtuelle Maschine kann eine n\u00fctzliche Informationsquelle sein, um die Funktionalit\u00e4t der Blockchain zu optimieren. Die Anzahl der Speicherzuweisungen, die Anzahl der Lese-\/Schreiboperationen und andere Metriken zur Effizienz der Codeausf\u00fchrung von Vertr\u00e4gen k\u00f6nnen den Entwicklern viele n\u00fctzliche Informationen liefern. Gleichzeitig sind Smart Contracts Programme, was bedeutet, dass sie theoretisch jegliche Ressourcen verbrauchen k\u00f6nnen: CPU\/Speicher\/Netzwerk\/Speicher, sodass die Verarbeitung von Transaktionen ein recht unbestimmter Schritt ist, der sich zudem stark ver\u00e4ndert, wenn zwischen Versionen gewechselt wird und sich der Code der Vertr\u00e4ge \u00e4ndert. Daher sind Metriken zur Verarbeitung von Transaktionen auch f\u00fcr eine effektive Leistungsoptimierung der Blockchain erforderlich.<\/p>\n

    <\/p>\n

    Benachrichtigung des Kunden \u00fcber die Aktivierung der Transaktion in der Blockchain<\/h2>\n

    <\/p>\n

    Dies ist der abschlie\u00dfende Schritt f\u00fcr den Kunden, um den Blockchain-Dienst zu erhalten; im Vergleich zu anderen Phasen gibt es hier keine hohen Betriebskosten, aber es ist dennoch wichtig, die M\u00f6glichkeit eines umfangreichen Feedbacks von einem Knoten (z.B. ein Smart Contract, der ein Array von Daten zur\u00fcckgibt) zu ber\u00fccksichtigen. In jedem Fall ist dieser Moment der wichtigste f\u00fcr diejenigen, die die Frage stellen: \u201eWie viele TPS hat Ihre Blockchain?\u201c, da zu diesem Zeitpunkt die Zeit f\u00fcr den Erhalt des Dienstes erfasst wird. <\/p>\n

    <\/p>\n

    An diesem Punkt ist es unbedingt erforderlich, die gesamte Zeit zu \u00fcbermitteln, die der Kunde f\u00fcr das Warten auf die Antwort der Blockchain aufwenden musste. Diese Zeit wird der Benutzer in seiner Anwendung als Best\u00e4tigung erwarten, und die Optimierung dieser Zeit ist die Hauptaufgabe der Entwickler.<\/p>\n

    <\/p>\n

    Fazit<\/h1>\n

    <\/p>\n

    Infolgedessen k\u00f6nnen die in Blockchains ausgef\u00fchrten Operationstypen beschrieben und in mehrere Kategorien unterteilt werden:<\/p>\n

    <\/p>\n

      \n
    1. kryptographische Umwandlungen, Aufbau von Nachweisen<\/li>\n
    2. Peer-to-Peer-Netzwerke, Replikation von Transaktionen und Bl\u00f6cken<\/li>\n
    3. Verarbeitung von Transaktionen, Ausf\u00fchrung von Smart Contracts<\/li>\n
    4. Anwendung von \u00c4nderungen in der Blockchain an der Zustandsdatenbank, Aktualisierung der Transaktions- und Blockdaten<\/li>\n
    5. Read-Only-Anfragen an die Zustandsdatenbank, API der Blockchain-Node, Abonnementdienste <\/li>\n<\/ol>\n

      <\/p>\n

      Die technischen Anforderungen an die Nodes moderner Blockchains sind insgesamt \u00e4u\u00dferst anspruchsvoll \u2014 schnelle CPUs f\u00fcr die Kryptografie, viel Arbeitsspeicher, um die Zustandsdatenbank zu speichern und schnell darauf zuzugreifen, Netzwerkinteraktionen mit einer gro\u00dfen Anzahl gleichzeitig ge\u00f6ffneter Verbindungen und umfangreicher Speicherplatz. Solche hohen Anforderungen und die Vielzahl verschiedener Operationstypen f\u00fchren unvermeidlich dazu, dass die Ressourcen der Nodes m\u00f6glicherweise nicht ausreichen und jeder der zuvor behandelten Schritte zum Bottleneck der Gesamtleistung des Netzwerks werden kann.<\/p>\n

      <\/p>\n

      Wenn Sie Blockchains entwickeln und deren Leistung bewerten, m\u00fcssen Sie all diese Aspekte ber\u00fccksichtigen. Dazu ist es notwendig, Metriken gleichzeitig von den Clients und Knoten im Netzwerk zu sammeln und zu analysieren, Korrelationen zwischen ihnen zu suchen, die Zeit zur Bereitstellung von Diensten an die Kunden zu bewerten und alle Hauptressourcen: CPU\/Speicher\/Netzwerk\/Speicher zu ber\u00fccksichtigen, sowie zu verstehen, wie sie genutzt werden und sich gegenseitig beeinflussen. All dies macht den Vergleich der Geschwindigkeiten verschiedener Blockchains in Form von \u201eWie viele TPS?\u201c zu einer \u00e4u\u00dferst undankbaren Aufgabe, da es eine riesige Anzahl verschiedener Konfigurationen und Zust\u00e4nde gibt. In gro\u00dfen, zentralisierten Systemen mit Clustern aus Hunderten von Servern sind diese Probleme ebenso komplex und erfordern das Sammeln einer Vielzahl verschiedener Metriken, aber in Blockchains gibt es aufgrund der P2P-Netzwerke, virtuellen Maschinen und der internen Wirtschaft viel mehr Freiheitsgrade, was selbst Tests auf mehreren Servern unzuverl\u00e4ssig macht und nur extrem grobe Werte liefert, die kaum mit der Realit\u00e4t in Verbindung stehen.<\/p>\n

      <\/p>\n

      Daher verwenden wir bei der Entwicklung des Blockchain-Kerns zur Leistungsbewertung und zur Beantwortung der Frage \u201eHat es sich im Vergleich zum letzten Mal verbessert?\u201c ziemlich komplexe Software, die den Start der Blockchain mit Dutzenden von Knoten und einer automatischen Benchmark-Ausf\u00fchrung sowie das Sammeln von Metriken orchestriert. Ohne diese Informationen ist es extrem schwierig, Protokolle zu debuggen, die mit vielen Teilnehmern arbeiten.<\/p>\n

      <\/p>\n

      Wenn Sie also die Frage \u201eWie viele TPS hat Ihre Blockchain?\u201c erhalten, bieten Sie Ihrem Gespr\u00e4chspartner eine Tasse Tee an und erkundigen Sie sich, ob er bereit ist, sich mit einem Dutzend Grafiken auseinanderzusetzen und alle drei Kisten der Leistungsprobleme von Blockchains sowie Ihre Vorschl\u00e4ge zu deren L\u00f6sung anzuh\u00f6ren...<\/p>\n

      Quelle: 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\udd47Wie viel TPS hat Ihre Blockchain? | ProHoster","description":"Die beliebteste Frage zu jeder verteilten System von einer nicht-technischen Person ist: \u201eWie viel TPS hat Ihre Blockchain?\u201c","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}