{"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 hat Ihre Blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Eine h\u00e4ufige Frage von Nicht-Technikern zu verteilten Systemen lautet: \u201eWie viele TPS hat Ihre Blockchain?\u201c Allerdings hat die genannte Zahl h\u00e4ufig wenig mit dem zu tun, was der Fragesteller tats\u00e4chlich h\u00f6ren m\u00f6chte. In Wahrheit wollte er fragen: \u201eEntspricht Ihre Blockchain meinen Gesch\u00e4ftsanforderungen?\u201c Diese Anforderungen sind kein einzelner Wert, sondern eine Vielzahl von Bedingungen \u2013 dazu geh\u00f6ren die Ausfallsicherheit des Netzwerks, die Anforderungen an die Endg\u00fcltigkeit, die Gr\u00f6\u00dfe, die Art der Transaktionen und viele andere Parameter. Daher wird die Antwort auf die Frage \u201eWie viele TPS?\u201c wahrscheinlich nicht einfach sein und fast nie vollst\u00e4ndig. Ein verteiltes System mit Dutzenden oder Hunderten von Knoten, die ziemlich komplexe Berechnungen durchf\u00fchren, kann sich in unz\u00e4hligen verschiedenen Zust\u00e4nden befinden, die mit dem Zustand des Netzwerks, dem Inhalt der Blockchain, technischen St\u00f6rungen, wirtschaftlichen Problemen, Angriffen auf das Netzwerk und vielen anderen Gr\u00fcnden verbunden sind. Die Phasen, in denen Leistungsprobleme m\u00f6glich sind, unterscheiden sich von traditionellen Diensten, w\u00e4hrend ein Server des Blockchain-Netzwerks einen Netzwerkdienst darstellt, der die Funktionalit\u00e4ten einer Datenbank, eines Webservers und eines Torrent-Clients kombiniert, was ihn in Bezug auf das Lastprofil f\u00fcr alle Subsysteme \u2013 Prozessor, Arbeitsspeicher, Netzwerk, Speicher \u2013 \u00e4u\u00dferst komplex macht.<\/p>\n

<\/p>\n

Dezentralisierte Netzwerke und Blockchains sind f\u00fcr Entwickler zentralisierter Software oft neu und speziell. Daher m\u00f6chte ich wichtige Aspekte der Leistung und Stabilit\u00e4t dezentralisierter Netzwerke beleuchten, sowie Ans\u00e4tze zu deren Messung und zur Identifizierung von Engp\u00e4ssen. Wir werden verschiedene Leistungsprobleme behandeln, die die Geschwindigkeit der Servicebereitstellung f\u00fcr Blockchain-Nutzer einschr\u00e4nken, und die spezifischen Eigenschaften dieser Art von Software hervorheben.<\/p>\n

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

Phasen der Serviceanfrage durch den Blockchain-Kunden<\/h2>\n

<\/p>\n

Um fair \u00fcber die Qualit\u00e4t eines komplexen Dienstes zu sprechen, m\u00fcssen nicht nur die Durchschnittswerte, sondern auch Maximal- und Minimalwerte, Mediane und Perzentile ber\u00fccksichtigt werden. Theoretisch k\u00f6nnte man von 1000 TPS in einer Blockchain sprechen, aber wenn 900 Transaktionen sehr schnell durchgef\u00fchrt wurden und 100 f\u00fcr einige Sekunden 'h\u00e4ngen blieben', ist die Durchschnittszeit, die f\u00fcr alle Transaktionen ermittelt wird, nicht unbedingt eine faire Kennzahl f\u00fcr einen Kunden, der seine Transaktion in wenigen Sekunden abschlie\u00dfen wollte. Zeitliche 'L\u00fccken', verursacht durch vers\u00e4umte Konsensrunden oder Netzwerkpartitionierung, k\u00f6nnen den Service erheblich verschlechtern, der in Testumgebungen eine hervorragende Leistung zeigte.<\/p>\n

<\/p>\n

Um solche Engp\u00e4sse zu identifizieren, ist es wichtig, die Phasen zu verstehen, in denen eine echte Blockchain Schwierigkeiten haben k\u00f6nnte, Benutzer zu bedienen. Lassen Sie uns den Liefervorgang und den Prozess der Verarbeitung von Transaktionen sowie den Erhalt des neuen Status der Blockchain beschreiben, aus dem der Kunde ersehen kann, dass seine Transaktion verarbeitet und ber\u00fccksichtigt 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 Kunde w\u00e4hlt einen der Nodes aus und sendet seine Transaktion dorthin.<\/li>\n
  4. Der Kunde abonniert die Aktualisierungen der State-Datenbank des Nodes und wartet auf die Ergebnisse der Ausf\u00fchrung seiner Transaktion.<\/li>\n
  5. Der Node verbreitet die Transaktion im P2P-Netzwerk.<\/li>\n
  6. Mehrere oder ein Blockproduzent (BP) verarbeiten die gesammelten Transaktionen und aktualisieren die State-Datenbank.<\/li>\n
  7. Der BP bildet einen neuen Block, indem er die erforderliche Anzahl an Transaktionen verarbeitet.<\/li>\n
  8. Der BP verbreitet den neuen Block im P2P-Netzwerk.<\/li>\n
  9. Der neue Block wird dem Node zugestellt, mit dem der Kunde sich verbindet.<\/li>\n
  10. Der Node aktualisiert die State-Datenbank.<\/li>\n
  11. Der Node sieht das Update, das den Kunden betrifft, und sendet ihm eine Benachrichtigung \u00fcber die Transaktion.<\/li>\n<\/ol>\n

    <\/p>\n

    Lassen Sie uns nun diese Schritte genauer betrachten und potenzielle Leistungsprobleme in jedem Schritt beschreiben. Im Gegensatz zu zentralisierten Systemen werden wir auch die Ausf\u00fchrung von Code auf den Clients im Netzwerk betrachten. Oft wird bei der Messung der TPS die Verarbeitungszeit von Transaktionen von den Nodes erfasst und nicht vom Client \u2013 das ist nicht ganz fair. Den Clients ist es egal, wie schnell die Node ihre Transaktion verarbeitet hat; das Wichtigste f\u00fcr sie ist der Moment, in dem die verl\u00e4ssliche Information \u00fcber diese Transaktion, die im Blockchain enthalten ist, f\u00fcr sie verf\u00fcgbar wird. Genau diese Metrik ist im Grunde die Ausf\u00fchrungszeit der Transaktion. Das bedeutet, dass verschiedene Clients, selbst wenn sie die gleiche Transaktion senden, v\u00f6llig unterschiedliche Zeiten erhalten k\u00f6nnen, die von Faktoren wie dem Kanal, der Auslastung und der N\u00e4he der Node abh\u00e4ngen, usw. Daher ist es unerl\u00e4sslich, diese Zeit auf den Clients zu messen, da genau dieses Parameter optimiert werden muss.<\/p>\n

    <\/p>\n

    Vorbereitung der Transaktion auf der Client-Seite<\/h2>\n

    <\/p>\n

    Lassen Sie uns mit den ersten beiden Punkten beginnen: Die Transaktion wird vom Kunden erstellt und signiert. Merkw\u00fcrdigerweise kann dies auch ein Engpass in der Leistung der Blockchain aus der Sicht des Kunden sein. Dies ist f\u00fcr zentralisierte Dienste ungewohnt, die alle Berechnungen und Datenoperationen selbst \u00fcbernehmen, w\u00e4hrend der Kunde nur eine kurze Anfrage vorbereitet, die gro\u00dfe Datenmengen oder Berechnungen anfordern kann und ein fertiges Ergebnis erh\u00e4lt. In Blockchain-Systemen wird der Client-Code immer leistungsf\u00e4higer, w\u00e4hrend der Kern der Blockchain immer leichter wird. Massive Rechenaufgaben werden \u00fcblicherweise an die Client-Software delegiert. In Blockchains gibt es Clients, die eine einzelne Transaktion relativ lange vorbereiten k\u00f6nnen (ich spreche dabei von verschiedenen Merkle-Proofs, succinct proofs, threshold Signaturen und anderen komplexen Operationen auf der Client-Seite). Ein gutes Beispiel f\u00fcr eine unkomplizierte On-Chain-Verifizierung und die aufwendige Vorbereitung einer Transaktion auf der Client-Seite ist der Nachweis der Zugeh\u00f6rigkeit zu einer Liste auf Basis von Merkle-B\u00e4umen. Artikel<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Sie sollten auch bedenken, dass der Client-Code nicht einfach Transaktionen an die Blockchain sendet, sondern zun\u00e4chst den Zustand der Blockchain abruft \u2013 und diese Aktivit\u00e4t kann die Netzwerkauslastung und die Blockchain-Knoten beeinflussen. Daher ist es sinnvoll, bei Messungen das Verhalten des Client-Codes so vollst\u00e4ndig wie m\u00f6glich zu emulieren. Selbst wenn in Ihrer Blockchain gew\u00f6hnliche leichte Clients vorhanden sind, die bei einfachsten Transaktionen eine digitale Signatur f\u00fcr die \u00dcbertragung eines bestimmten Assets setzen, steigt die Anzahl der massiven Berechnungen auf dem Client mit jedem Jahr. Die Kryptographie wird robuster, und dieser Teil des Prozesses k\u00f6nnte in Zukunft zu einem signifikanten Engpass werden. Seien Sie also vorsichtig und \u00fcbersehen Sie nicht, dass bei einer Transaktion von 3,5 Sekunden, 2,5 Sekunden f\u00fcr die Vorbereitung und Signatur der Transaktion und 1,0 Sekunden f\u00fcr die \u00dcbermittlung im Netzwerk und das Warten auf eine Antwort verwendet werden. Um die Risiken dieses Engpasses zu bewerten, m\u00fcssen Sie Metriken von den Client-Maschinen sammeln, nicht nur von Blockchain-Knoten.<\/p>\n

    <\/p>\n

    Transaktion senden und ihren Status \u00fcberwachen<\/h2>\n

    <\/p>\n

    Der n\u00e4chste Schritt besteht darin, die Transaktion an den ausgew\u00e4hlten Blockchain-Knoten zu senden und den Status ihrer Aufnahme in den Transaktionspool abzurufen. Dieser Schritt \u00e4hnelt einem herk\u00f6mmlichen Datenbankaufruf: Der Knoten muss die Transaktion im Pool speichern und beginnen, Informationen dar\u00fcber \u00fcber das P2P-Netzwerk zu verbreiten. Der Ansatz zur Leistungsbewertung hier \u00e4hnelt der Bewertung der Leistung traditioneller Microservices im Web-API-Bereich, wobei die Transaktionen in Blockchain-Netzwerken aktualisiert und aktiv ihren Status \u00e4ndern k\u00f6nnen. Tats\u00e4chlich kann die Aktualisierung von Informationen zu einer Transaktion in bestimmten Blockchains mehrere Male stattfinden, z.B. beim Umschalten zwischen Forks der Kette oder wenn BPs (Block Producer) ihre Absicht mitteilen, die Transaktion in einen Block aufzunehmen. Einschr\u00e4nkungen hinsichtlich des Volumens dieses Pools und der Anzahl der darin enthaltenen Transaktionen k\u00f6nnen sich auf die Leistung der Blockchain auswirken. Wenn der Transaktionspool auf die maximal m\u00f6gliche Gr\u00f6\u00dfe gef\u00fcllt ist oder nicht im Arbeitsspeicher Platz findet, kann die Netzwerkleistung erheblich sinken. Blockchains haben keine zentralen Schutzmechanismen gegen den Fluss von Spam-Nachrichten, und wenn die Blockchain Transaktionen mit hohem Volumen und niedrigen Geb\u00fchren unterst\u00fctzt, kann dies zu einer \u00dcberlastung des Transaktionspools f\u00fchren \u2014 dies ist ein weiterer potenzieller Engpass in der Performance.<\/p>\n

    <\/p>\n

    In Blockchains sendet der Client eine Transaktion an beliebige Knoten im Blockchain-Netzwerk. Der Hash der Transaktion ist dem Client normalerweise bereits vor dem Versand bekannt, sodass er nur eine Verbindung herstellen und dann warten muss, bis die Blockchain ihren Status \u00e4ndert und die Transaktion einf\u00fcgt. Es ist wichtig zu beachten, dass die Messung von 'tps' (Transaktionen pro Sekunde) zu unterschiedlichen Ergebnissen f\u00fchren kann, abh\u00e4ngig von der Art der Verbindung zum Blockchain-Knoten. Dies kann \u00fcber einen normalen HTTP RPC oder einen WebSocket erfolgen, der das 'subscribe'-Muster erm\u00f6glicht. Im zweiten Fall erh\u00e4lt der Client fr\u00fcher eine Benachrichtigung, und der Knoten verbraucht weniger Ressourcen (haupts\u00e4chlich Speicher und Bandbreite) f\u00fcr die Statusantworten der Transaktion. Daher ist es bei der Messung von 'tps' entscheidend, die Art der Verbindung der Clients zu den Knoten zu ber\u00fccksichtigen. Um die Risiken eines Bottlenecks zu bewerten, sollte das Benchmarking des Blockchain-Systems in der Lage sein, Clients sowohl mit WebSocket- als auch mit HTTP RPC-Anfragen zu emulieren, in einem Verh\u00e4ltnis, das den realen Netzwerken entspricht, und zudem die Art und Gr\u00f6\u00dfe der Transaktionen variieren.<\/p>\n

    <\/p>\n

    Zur Bewertung der Risiken eines Bottlenecks sollten auch Metriken von den Client-Maschinen und nicht nur von den Blockchain-Knoten gesammelt werden.<\/p>\n

    <\/p>\n

    \u00dcbertragung von Transaktionen und Bl\u00f6cken \u00fcber das P2P-Netzwerk<\/h2>\n

    <\/p>\n

    In Blockchains wird f\u00fcr die \u00dcbertragung von Transaktionen und Bl\u00f6cken zwischen den Teilnehmern ein Peer-to-Peer (P2P) Netzwerk verwendet. Transaktionen breiten sich im Netzwerk aus, beginnend mit einem der Knoten, bis sie die Peer-Blockproduzenten erreichen, die die Transaktionen in Bl\u00f6cke b\u00fcndeln und die neuen Bl\u00f6cke mit dem gleichen P2P-Protokoll an alle Knoten im Netzwerk verteilen. Die Grundlage der meisten modernen P2P-Netzwerke sind verschiedene Modifikationen des Kademlia-Protokolls. Hier<\/a><\/noindex> eine gute kurze \u00dcbersicht \u00fcber dieses Protokoll, sowie hier ist<\/a><\/noindex> ein Artikel mit verschiedenen Messungen im BitTorrent-Netzwerk, der zeigt, dass dieser Netztyp komplexer und weniger vorhersehbar ist als ein starr konfiguriertes Netzwerk eines zentralisierten Dienstes. Dar\u00fcber hinaus hier ist<\/a><\/noindex> ein Artikel \u00fcber die Messung verschiedener interessanter Metriken f\u00fcr Ethereum-Knoten.<\/p>\n

    <\/p>\n

    Kurz gesagt unterst\u00fctzt jeder Peer in solchen Netzwerken eine eigene dynamische Liste anderer Peers, von denen er Informationsbl\u00f6cke anfordert, die nach Inhalt adressiert sind. Bei Erhalt 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 eine Zeit lang im Cache, sodass er den Informationsblock beim n\u00e4chsten Mal schneller bereitstellen kann. So gelangt popul\u00e4re Information in viele Caches \u00fcber zahlreiche Peers, w\u00e4hrend weniger popul\u00e4re Inhalte allm\u00e4hlich verdr\u00e4ngt werden. Die Peers f\u00fchren Buch dar\u00fcber, wie viel Information sie wem \u00fcbermittelt haben, und das Netzwerk versucht, aktive Verteiler zu belohnen, indem es deren Rating erh\u00f6ht und ihnen einen besseren Service-Level bietet, w\u00e4hrend inaktive Teilnehmer automatisch aus den Peer-Listen entfernt werden.<\/p>\n

    <\/p>\n

    Die Transaktion muss nun im Netzwerk verbreitet werden, damit die Blockproduzenten sie sehen und in einen Block aufnehmen k\u00f6nnen. Der Knoten \"verbreitet\" aktiv die neue Transaktion an alle Interessierten und h\u00f6rt im Netzwerk zu, w\u00e4hrend er auf einen Block wartet, in dem die ben\u00f6tigte Transaktion erscheint, um den wartenden Kunden zu benachrichtigen. Die Zeit, die das Netzwerk ben\u00f6tigt, um Informationen \u00fcber neue Transaktionen und Bl\u00f6cke in P2P-Netzen auszutauschen, h\u00e4ngt von einer Vielzahl von Faktoren ab: der Anzahl der ehrlichen, benachbarten Knoten (aus Netzsicht), der \"Temperatur\" der Caches dieser Knoten, der Blockgr\u00f6\u00dfen, der Transaktionen, der Art der \u00c4nderungen, der geografischen Lage des Netzwerks, der Anzahl der Knoten und vielen anderen Faktoren. Komplexe Messungen der Leistungsmetriken in solchen Netzwerken sind herausfordernd, da gleichzeitig die Bearbeitungszeiten sowohl auf den Clients als auch auf den Peers (Blockchain-Knoten) bewertet werden m\u00fcssen. Probleme in irgendeinem der P2P-Mechanismen, falsches Caching und die L\u00f6schung von Daten, ineffizientes Management der 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 am schwierigsten zu analysieren, zu testen und die Ergebnisse zu interpretieren.<\/p>\n

    <\/p>\n

    Die Verarbeitung von Blockchains und die Aktualisierung der Zustand-Datenbank<\/h2>\n

    <\/p>\n

    Der entscheidendste Teil der Funktionsweise eines Blockchain-Systems ist der Konsensalgorithmus, der auf die neu aus dem Netzwerk gewonnenen Bl\u00f6cke angewendet wird, sowie die Verarbeitung von Transaktionen und die Speicherung der Ergebnisse in der Zustandsdatenbank. Das Hinzuf\u00fcgen eines neuen Blocks zur Kette und die anschlie\u00dfende Auswahl der Hauptkette m\u00fcssen so schnell wie m\u00f6glich erfolgen. In der Praxis bedeutet jedoch \"muss\" nicht gleich \"funktioniert\", und man kann sich beispielsweise eine Situation vorstellen, in der zwei konkurrierende lange Ketten st\u00e4ndig zwischen einander wechseln, wobei die Metadaten von Tausenden von Transaktionen im Pool bei jedem Wechsel ge\u00e4ndert werden und somit st\u00e4ndige Rollbacks des Zustands der Zustandsdatenbank erzeugt werden. In Bezug auf die Identifizierung von Bottlenecks ist dieser Schritt einfacher als der Netzwerk-P2P-Schicht, da die Ausf\u00fchrung von Transaktionen und der Konsensalgorithmus strikt deterministisch sind, was die Messung hier einfacher macht.
    \nDas Wichtigste ist, die zuf\u00e4llige Leistungsverschlechterung dieses Schrittes nicht mit Netzwerkproblemen zu verwechseln \u2014 Nodes geben Blocks und Informationen zur Hauptkette langsamer weiter, und f\u00fcr den externen Kunden kann dies wie ein langsames Netzwerk erscheinen, obwohl das Problem an einer ganz anderen Stelle liegt.<\/p>\n

    <\/p>\n

    Zur Optimierung der Leistung ist es in diesem Stadium hilfreich, Metriken von den Knoten zu sammeln und zu \u00fcberwachen. Dabei sollten auch die Metriken zur Aktualisierung der State-Datenbank einbezogen werden: die Anzahl der auf dem Knoten verarbeiteten Bl\u00f6cke, deren Gr\u00f6\u00dfe, die Anzahl der Transaktionen, die H\u00e4ufigkeit von Fork-Wechseln, die Anzahl ung\u00fcltiger Bl\u00f6cke, die Laufzeit der virtuellen Maschine, die Dauer der Datenspeicherung usw. Dies hilft, Netzwerkprobleme nicht mit Fehlern im Chain-Processing-Algorithmus zu verwechseln.<\/p>\n

    <\/p>\n

    Eine virtuelle Maschine zur Verarbeitung von Transaktionen kann eine n\u00fctzliche Informationsquelle sein, die die Effizienz von Blockchain-Operationen optimiert. Die Menge der zugewiesenen Speicherkapazit\u00e4t, die Anzahl der Lese-\/Schreibbefehle und andere Kennzahlen zur Effektivit\u00e4t der Ausf\u00fchrung von Vertragscodes k\u00f6nnen Entwicklern wertvolle Einblicke geben. Zugleich sind Smart Contracts Programme, was bedeutet, dass sie theoretisch jede Art von Ressourcen nutzen k\u00f6nnen: CPU, Speicher, Netzwerk und Speicherplatz. Daher ist die Verarbeitung von Transaktionen ein eher ungewisser Prozess, der zudem stark variieren kann, wenn zwischen Versionen gewechselt wird oder sich der Code der Vertr\u00e4ge \u00e4ndert. Folglich sind Kennzahlen zur Verarbeitung von Transaktionen ebenfalls erforderlich, um die Leistung des Blockchain-Systems effektiv zu optimieren.<\/p>\n

    <\/p>\n

    Der Kunde erh\u00e4lt eine Benachrichtigung \u00fcber die Aufnahme der Transaktion in die Blockchain<\/h2>\n

    <\/p>\n

    Dies ist der letzte Schritt, um den Service des Blockchain-Kunden zu erhalten. Im Vergleich zu anderen Phasen gibt es hier keine hohen Gemeinkosten, dennoch sollte man die M\u00f6glichkeit in Betracht ziehen, dass der Kunde von einem Knoten einen umfangreichen Antwortdatensatz erh\u00e4lt (zum Beispiel ein Smart Contract, der ein Datenarray zur\u00fcckgibt). In jedem Fall ist dieser Moment der entscheidende, insbesondere f\u00fcr diejenigen, die die Frage stellen: \u201eWie hoch ist die TPS in Ihrer Blockchain?\u201c Denn genau hier wird die Zeit f\u00fcr den Serviceempfang festgehalten. <\/p>\n

    <\/p>\n

    An dieser Stelle ist es wichtig, die gesamte Zeit zu erfassen, die der Kunde mit dem Warten auf eine Antwort von der Blockchain verbracht hat. Genau diese Zeit wird der Benutzer in seiner Anwendung auf die Best\u00e4tigung warten, und deren Optimierung ist die Hauptaufgabe der Entwickler.<\/p>\n

    <\/p>\n

    Fazit<\/h1>\n

    <\/p>\n

    Infolgedessen k\u00f6nnen die Arten von Operationen, die in Blockchains ausgef\u00fchrt werden, beschrieben und in mehrere Kategorien eingeteilt werden:<\/p>\n

    <\/p>\n

      \n
    1. Kryptografische Transformationen, Erstellung von Beweisen<\/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 auf die Statusdatenbank, Aktualisierung der Daten zu Transaktionen und Bl\u00f6cken<\/li>\n
    5. read-only Anfragen an die Zustandsdatenbank, API der Blockchain-Knoten, Abonnementdienste <\/li>\n<\/ol>\n

      <\/p>\n

      Die technischen Anforderungen an moderne Blockchain-Knoten sind insgesamt sehr hoch \u2014 hier sind schnelle CPUs f\u00fcr die Kryptografie erforderlich, viel Arbeitsspeicher, um die Zustandsdatenbank zu speichern und schnell darauf zuzugreifen, sowie ein Netzwerk, das eine gro\u00dfe Anzahl gleichzeitig ge\u00f6ffneter Verbindungen unterst\u00fctzt, und umfangreicher Speicher. Diese hohen Anforderungen und die Vielzahl verschiedener Operationstypen f\u00fchren zwangsl\u00e4ufig dazu, dass die Ressourcen der Knoten nicht ausreichen, und dann kann jeder der oben genannten Schritte zum n\u00e4chsten Flaschenhals f\u00fcr die Gesamtleistung des Netzwerks werden.<\/p>\n

      <\/p>\n

      Bei der Entwicklung und Bewertung der Performance von Blockchains m\u00fcssen Sie all diese Aspekte ber\u00fccksichtigen. Dazu geh\u00f6rt das gleichzeitige Sammeln und Analysieren von Metriken sowohl von Clients als auch von Nodes im Netzwerk, das Suchen nach Korrelationen zwischen ihnen, das Bewerten der Servicebereitstellungszeit f\u00fcr Kunden sowie die Ber\u00fccksichtigung aller wesentlichen Ressourcen: CPU, RAM, Netzwerk und Speicher. Zudem m\u00fcssen Sie verstehen, wie diese Ressourcen verwendet werden und sich gegenseitig beeinflussen. All dies macht den Vergleich der Geschwindigkeiten verschiedener Blockchains in Bezug auf 'wie viele TPS' zu einer \u00e4u\u00dferst undankbaren Aufgabe, da es eine Vielzahl unterschiedlicher Konfigurationen und Zust\u00e4nde gibt. In gro\u00dfen zentralisierten Systemen, Clustern aus Hunderten von Servern, sind diese Probleme ebenfalls komplex und erfordern das Sammeln einer Vielzahl unterschiedlicher Metriken. Doch in Blockchains, aufgrund von P2P-Netzen, virtuellen Maschinen, die Vertr\u00e4ge verarbeiten, und interner Wirtschaft, gibt es weitaus mehr Freiheitsgrade. Dies f\u00fchrt dazu, dass Tests selbst auf mehreren Servern kaum aussagekr\u00e4ftig sind und nur sehr grobe Werte liefern, die kaum mit der Realit\u00e4t in Verbindung stehen.<\/p>\n

      <\/p>\n

      Bei der Entwicklung im Kern des Blockchain-Systems verwenden wir relativ komplexe Software, die den Start der Blockchain mit Dutzenden von Knoten orchestriert sowie Benchmark-Tests und die Sammlung von Metriken automatisiert. Ohne diese Informationen ist es \u00e4u\u00dferst schwierig, Protokolle, die mit vielen Teilnehmern arbeiten, zu debuggen und zu optimieren.<\/p>\n

      <\/p>\n

      Wenn jemand fragt: \u201eWie viele TPS hat Ihre Blockchain?\u201c, bieten Sie ihm eine Tasse Tee an und erkundigen Sie sich, ob er bereit ist, sich mit einer Reihe von Grafiken auseinanderzusetzen und alle drei Boxen von Blockchain-Leistungsproblemen sowie Ihre Vorschl\u00e4ge zu deren L\u00f6sung anzuh\u00f6ren\u2026<\/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 viele TPS hat Ihre Blockchain? | ProHoster","description":"Eine h\u00e4ufige Frage eines nicht-technischen Experten zu jeder verteilten System ist: \"Wie viel TPS hat Ihre Blockchain?\" In der Regel hat die Antwortzahl jedoch wenig mit dem zu tun, was der Fragesteller eigentlich h\u00f6ren wollte. Tats\u00e4chlich wollte er wissen: \"Entspricht Ihre Blockchain meinen Gesch\u00e4ftsanforderungen?\" und diese Anforderungen sind keine einzige Zahl, sondern eine Vielzahl von Bedingungen.","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. \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","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"},"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}]}}