Eine Lieblingsfrage von Nicht-Technikern zu verteilten Systemen lautet: „Wie viele TPS befinden sich in Ihrer Blockchain?“ Allerdings hat die als Antwort angegebene Zahl meist wenig mit dem zu tun, was der Fragesteller gerne hören würde. Tatsächlich wollte er fragen: „Wird Ihre Blockchain meinen Geschäftsanforderungen entsprechen?“ Und diese Anforderungen sind nicht eine Zahl, sondern viele Bedingungen – hier sind Netzwerkfehlertoleranz, Endgültigkeitsanforderungen, Größen, Art der Transaktionen und viele andere Parameter. Daher ist die Antwort auf die Frage „Wie viele TPS“ wahrscheinlich nicht einfach und fast nie vollständig. Ein verteiltes System mit Dutzenden oder Hunderten von Knoten, die recht komplexe Berechnungen durchführen, kann sich in einer Vielzahl unterschiedlicher Zustände befinden, die vom Zustand des Netzwerks, dem Inhalt der Blockchain, technischen Ausfällen, wirtschaftlichen Problemen, Angriffen auf das Netzwerk und vielen anderen Gründen abhängen . Die Phasen, in denen Leistungsprobleme auftreten können, unterscheiden sich von herkömmlichen Diensten. Ein Blockchain-Netzwerkserver ist ein Netzwerkdienst, der die Funktionalität einer Datenbank, eines Webservers und eines Torrent-Clients vereint, was ihn hinsichtlich des Lastprofils auf allen Subsystemen äußerst komplex macht : Prozessor, Speicher, Netzwerk, Speicher

Es kommt vor, dass dezentrale Netzwerke und Blockchains für zentralisierte Softwareentwickler recht spezifische und ungewöhnliche Software sind. Daher möchte ich wichtige Aspekte der Leistungsfähigkeit und Nachhaltigkeit dezentraler Netzwerke, Ansätze zu deren Messung und das Auffinden von Engpässen hervorheben. Wir werden verschiedene Leistungsprobleme untersuchen, die die Geschwindigkeit der Bereitstellung von Diensten für Blockchain-Benutzer einschränken, und die für diese Art von Software charakteristischen Merkmale beachten.

Phasen einer Serviceanfrage durch einen Blockchain-Client

Um ehrlich über die Qualität einer mehr oder weniger komplexen Dienstleistung zu sprechen, müssen Sie nicht nur Durchschnittswerte, sondern auch Maximum/Minimum, Median und Perzentile berücksichtigen. Theoretisch können wir in manchen Blockchains von 1000 tps sprechen, aber wenn 900 Transaktionen mit enormer Geschwindigkeit abgeschlossen wurden und 100 für ein paar Sekunden „steckengeblieben“ waren, dann ist die durchschnittliche Zeit, die über alle Transaktionen hinweg gesammelt wurde, für einen Kunden keine völlig faire Messgröße wen ich die Transaktion nicht in wenigen Sekunden abschließen konnte. Vorübergehende „Lücken“, die durch verpasste Konsensrunden oder Netzwerkaufteilungen verursacht werden, können einen Dienst, der auf Prüfständen eine hervorragende Leistung gezeigt hat, erheblich ruinieren.

Um solche Engpässe zu identifizieren, ist es notwendig, die Phasen gut zu verstehen, in denen eine echte Blockchain möglicherweise Schwierigkeiten hat, Benutzer zu bedienen. Beschreiben wir den Zyklus der Lieferung und Verarbeitung einer Transaktion sowie des Erhaltens eines neuen Status der Blockchain, anhand dessen der Kunde überprüfen kann, ob seine Transaktion verarbeitet und abgerechnet wurde.

Die Transaktion wird auf dem Client gebildet
Die Transaktion wird auf dem Client signiert
Der Client wählt einen der Knoten aus und sendet seine Transaktion an diesen
Der Client abonniert Aktualisierungen der Statusdatenbank des Knotens und wartet auf das Erscheinen der Ergebnisse seiner Transaktion
Der Knoten verteilt die Transaktion über das P2P-Netzwerk
Mehrere oder ein BP (Blockproduzent) verarbeitet akkumulierte Transaktionen und aktualisiert die Statusdatenbank
BP bildet einen neuen Block, nachdem die erforderliche Anzahl von Transaktionen verarbeitet wurde
BP verteilt einen neuen Block über das P2P-Netzwerk
Der neue Block wird an den Knoten übermittelt, auf den der Client zugreift
Der Knoten aktualisiert die Statusdatenbank
Der Knoten sieht die Aktualisierung bezüglich des Kunden und sendet ihm eine Transaktionsbenachrichtigung

Schauen wir uns nun diese Phasen genauer an und beschreiben die potenziellen Leistungsprobleme in jeder Phase. Im Gegensatz zu zentralisierten Systemen berücksichtigen wir auch die Codeausführung auf Netzwerk-Clients. Bei der TPS-Messung wird die Transaktionsverarbeitungszeit häufig von den Knoten und nicht vom Client erfasst – das ist nicht ganz fair. Dem Kunden ist es egal, wie schnell der Knoten seine Transaktion abwickelt; das Wichtigste für ihn ist der Moment, in dem ihm zuverlässige Informationen über diese in der Blockchain enthaltene Transaktion zur Verfügung stehen. Diese Metrik ist im Wesentlichen die Transaktionsausführungszeit. Dies bedeutet, dass verschiedene Clients, selbst wenn sie dieselbe Transaktion senden, völlig unterschiedliche Zeiten erhalten können, die vom Kanal, der Auslastung und der Nähe des Knotens usw. abhängen. Daher ist es unbedingt erforderlich, diese Zeit auf den Clients zu messen, da es sich hierbei um den Parameter handelt, der optimiert werden muss.

Vorbereiten einer Transaktion auf Kundenseite

Beginnen wir mit den ersten beiden Punkten: Die Transaktion wird vom Kunden erstellt und unterzeichnet. Seltsamerweise kann dies aus Sicht des Kunden auch ein Flaschenhals der Blockchain-Leistung sein. Dies ist ungewöhnlich für zentralisierte Dienste, die alle Berechnungen und Operationen mit Daten übernehmen, und der Kunde bereitet einfach eine kurze Anfrage vor, die eine große Menge an Daten oder Berechnungen anfordern kann, um ein fertiges Ergebnis zu erhalten. In Blockchains wird der Client-Code immer leistungsfähiger und der Blockchain-Kern immer leichter, und umfangreiche Rechenaufgaben werden normalerweise auf die Client-Software übertragen. In Blockchains gibt es Clients, die eine Transaktion über einen längeren Zeitraum vorbereiten können (ich spreche von verschiedenen Merkle-Beweisen, prägnanten Beweisen, Schwellenwertsignaturen und anderen komplexen Vorgängen auf der Client-Seite). Ein gutes Beispiel für eine einfache On-Chain-Verifizierung und eine intensive Vorbereitung einer Transaktion auf dem Client ist hier der Nachweis der Mitgliedschaft in einer auf Merkle-Tree basierenden Liste Beitrag.

Vergessen Sie auch nicht, dass der Client-Code nicht einfach Transaktionen an die Blockchain sendet, sondern zunächst den Status der Blockchain abfragt – und diese Aktivität kann sich auf die Überlastung des Netzwerks und der Blockchain-Knoten auswirken. Daher wäre es sinnvoll, bei Messungen das Verhalten des Client-Codes möglichst vollständig nachzubilden. Auch wenn es in Ihrer Blockchain gewöhnliche Light-Clients gibt, die die einfachste Transaktion zur Übertragung eines Vermögenswerts mit einer regelmäßigen digitalen Signatur versehen, gibt es jedes Jahr immer noch umfangreichere Berechnungen für den Client, Kryptoalgorithmen werden immer leistungsfähiger und dieser Teil der Verarbeitung kann in Zukunft zu einem erheblichen Engpass werden. Seien Sie daher vorsichtig und verpassen Sie nicht die Situation, in der bei einer 3.5 Sekunden dauernden Transaktion 2.5 Sekunden für die Vorbereitung und Unterzeichnung der Transaktion aufgewendet werden und 1.0 Sekunden für das Senden an das Netzwerk und das Warten auf eine Antwort. Um die Risiken dieses Engpasses einzuschätzen, müssen Sie Metriken von Client-Rechnern und nicht nur von Blockchain-Knoten sammeln.

Senden einer Transaktion und Überwachen ihres Status

Der nächste Schritt besteht darin, die Transaktion an den ausgewählten Blockchain-Knoten zu senden und den Status zur Aufnahme in den Transaktionspool zu erhalten. Diese Phase ähnelt einem regulären Datenbankzugriff; der Knoten muss die Transaktion im Pool aufzeichnen und beginnen, Informationen darüber über das P2P-Netzwerk zu verteilen. Der Ansatz zur Leistungsbewertung ähnelt hier der Leistungsbewertung herkömmlicher Web-API-Microservices, und die Transaktionen selbst in Blockchains können aktualisiert werden und ihren Status aktiv ändern. Im Allgemeinen kann die Aktualisierung von Transaktionsinformationen auf einigen Blockchains mehrmals erfolgen, beispielsweise beim Wechsel zwischen Chain Forks oder wenn BPs ihre Absicht bekannt geben, eine Transaktion in einen Block aufzunehmen. Beschränkungen der Größe dieses Pools und der Anzahl der darin enthaltenen Transaktionen können sich auf die Leistung der Blockchain auswirken. Wenn der Transaktionspool bis zur maximal möglichen Größe gefüllt ist oder nicht in den Arbeitsspeicher passt, kann die Netzwerkleistung stark sinken. Blockchains verfügen über keine zentralen Mittel zum Schutz vor einer Flut von Junk-Nachrichten. Wenn die Blockchain Transaktionen mit hohem Volumen und niedrigen Gebühren unterstützt, kann dies zu einem Überlauf des Transaktionspools führen – ein weiterer potenzieller Leistungsengpass.

Bei Blockchains sendet der Client eine Transaktion an einen beliebigen Blockchain-Knoten seiner Wahl. Der Hash der Transaktion ist dem Client normalerweise vor dem Senden bekannt. Er muss also lediglich die Verbindung herstellen und nach der Übertragung warten, bis sich die Blockchain ändert seinen Zustand und ermöglicht so seine Transaktion. Beachten Sie, dass Sie durch die Messung von „tps“ völlig unterschiedliche Ergebnisse für verschiedene Verbindungsmethoden zu einem Blockchain-Knoten erhalten können. Dies kann ein regulärer HTTP-RPC oder ein WebSocket sein, mit dem Sie das „Subscribe“-Muster implementieren können. Im zweiten Fall erhält der Client früher eine Benachrichtigung und der Knoten verbraucht weniger Ressourcen (hauptsächlich Speicher und Datenverkehr) für Antworten zum Transaktionsstatus. Bei der Messung von „tps“ muss daher die Art und Weise berücksichtigt werden, wie Clients eine Verbindung zu Knoten herstellen. Um die Risiken dieses Engpasses beurteilen zu können, muss die Benchmark-Blockchain daher in der Lage sein, Clients sowohl mit WebSocket- als auch mit HTTP-RPC-Anfragen in Proportionen zu emulieren, die realen Netzwerken entsprechen, sowie die Art der Transaktionen und ihre Größe zu ändern.

Um die Risiken dieses Engpasses einzuschätzen, müssen Sie auch Metriken von Client-Rechnern und nicht nur von Blockchain-Knoten sammeln.

Übertragung von Transaktionen und Blöcken über ein P2P-Netzwerk

In Blockchains werden Peer-to-Peer-Netzwerke (P2P) verwendet, um Transaktionen und Blöcke zwischen Teilnehmern zu übertragen. Transaktionen verteilen sich im gesamten Netzwerk, beginnend bei einem der Knoten, bis sie Peer-Blockproduzenten erreichen, die Transaktionen in Blöcke packen und mit demselben P2P neue Blöcke an alle Netzwerkknoten verteilen. Die Grundlage der meisten modernen P2P-Netzwerke sind verschiedene Modifikationen des Kademlia-Protokolls. Hier eine gute Zusammenfassung dieses Protokolls und hier - ein Artikel mit verschiedenen Messungen im BitTorrent-Netzwerk, aus dem hervorgeht, dass diese Art von Netzwerk komplexer und weniger vorhersehbar ist als ein starr konfiguriertes Netzwerk eines zentralisierten Dienstes. Auch, hier Artikel über die Messung verschiedener interessanter Metriken für Ethereum-Knoten.

Kurz gesagt, jeder Peer in solchen Netzwerken unterhält seine eigene dynamische Liste anderer Peers, von denen er Informationsblöcke anfordert, die durch Inhalte adressiert werden. Wenn ein Peer eine Anfrage erhält, gibt er entweder die erforderlichen Informationen weiter oder leitet die Anfrage an den nächsten pseudozufälligen Peer aus der Liste weiter. Nachdem er eine Antwort erhalten hat, leitet er diese an den Anforderer weiter und speichert sie für eine Weile im Cache, um ihn anzugeben Informationsblock beim nächsten Mal früher. So landen populäre Informationen in einer großen Anzahl von Caches einer großen Anzahl von Peers und unpopuläre Informationen werden nach und nach ersetzt. Peers führen Aufzeichnungen darüber, wer wie viele Informationen an wen weitergegeben hat, und das Netzwerk versucht, aktive Vertriebspartner zu stimulieren, indem es ihre Bewertungen erhöht und ihnen ein höheres Serviceniveau bietet, wodurch inaktive Teilnehmer automatisch von Peer-Listen verdrängt werden.

Daher muss die Transaktion nun im gesamten Netzwerk verteilt werden, damit Blockproduzenten sie sehen und in den Block einbinden können. Der Knoten „verteilt“ aktiv eine neue Transaktion an alle und lauscht dem Netzwerk und wartet auf einen Block, in dessen Index die erforderliche Transaktion erscheint, um den wartenden Client zu benachrichtigen. Die Zeit, die das Netzwerk benötigt, um in P2P-Netzwerken Informationen über neue Transaktionen und Blöcke untereinander zu übertragen, hängt von einer sehr großen Anzahl von Faktoren ab: der Anzahl der ehrlichen Knoten, die in der Nähe arbeiten (aus Netzwerksicht), der „Warm-“ „Up“ der Caches dieser Knoten, die Größe der Blöcke, Transaktionen, die Art der Änderungen, die Netzwerkgeographie, die Anzahl der Knoten und viele andere Faktoren. Umfassende Messungen von Leistungsmetriken in solchen Netzwerken sind eine komplexe Angelegenheit; es ist notwendig, die Anforderungsverarbeitungszeit sowohl auf Clients als auch auf Peers (Blockchain-Knoten) gleichzeitig zu bewerten. Probleme in einem der P2P-Mechanismen, falsche Datenbeseitigung und Zwischenspeicherung, ineffektive Verwaltung der Listen aktiver Peers und viele andere Faktoren können zu Verzögerungen führen, die sich auf die Effizienz des gesamten Netzwerks als Ganzes auswirken. Dieser Engpass ist am schwierigsten zu analysieren , Test und Interpretation der Ergebnisse.

Blockchain-Verarbeitung und Aktualisierung der Statusdatenbank

Der wichtigste Teil der Blockchain ist der Konsensalgorithmus, seine Anwendung auf neue vom Netzwerk empfangene Blöcke und die Verarbeitung von Transaktionen mit Aufzeichnung der Ergebnisse in der Staatsdatenbank. Das Hinzufügen eines neuen Blocks zur Kette und das anschließende Auswählen der Hauptkette sollte so schnell wie möglich funktionieren. Im wirklichen Leben bedeutet „sollte“ jedoch nicht „funktioniert“, und man kann sich beispielsweise eine Situation vorstellen, in der zwei lange konkurrierende Ketten ständig untereinander wechseln und dabei bei jedem Wechsel die Metadaten von Tausenden von Transaktionen im Pool ändern und ständiges Zurücksetzen der Statusdatenbank. Diese Phase ist im Hinblick auf die Definition des Engpasses einfacher als die P2P-Netzwerkschicht, weil Transaktionsausführung und Konsensalgorithmus sind streng deterministisch und es ist hier einfacher, alles zu messen.
Die Hauptsache ist, eine zufällige Verschlechterung der Leistung dieser Phase nicht mit Netzwerkproblemen zu verwechseln – Knoten liefern langsamer Blöcke und Informationen über die Hauptkette, und für einen externen Client kann dies wie ein langsames Netzwerk aussehen, obwohl das Problem darin liegt ein völlig anderer Ort.

Um die Leistung in dieser Phase zu optimieren, ist es sinnvoll, Metriken von den Knoten selbst zu sammeln und zu überwachen und in diese Metriken einzubeziehen, die sich auf die Aktualisierung der Statusdatenbank beziehen: die Anzahl der auf dem Knoten verarbeiteten Blöcke, ihre Größe, die Anzahl der Transaktionen, die Anzahl der Wechsel zwischen Kettenzweigen, die Anzahl ungültiger Blöcke, die Betriebszeit der virtuellen Maschine, die Datenfestschreibungszeit usw. Dadurch wird verhindert, dass Netzwerkprobleme mit Fehlern in den Kettenverarbeitungsalgorithmen verwechselt werden.

Eine virtuelle Maschine, die Transaktionen verarbeitet, kann eine nützliche Informationsquelle sein, die den Betrieb der Blockchain optimieren kann. Die Anzahl der Speicherzuweisungen, die Anzahl der Lese-/Schreibanweisungen und andere Kennzahlen im Zusammenhang mit der Effizienz der Vertragscodeausführung können Entwicklern viele nützliche Informationen liefern. Gleichzeitig sind Smart Contracts Programme, was bedeutet, dass sie theoretisch alle Ressourcen verbrauchen können: CPU/Speicher/Netzwerk/Speicher, sodass die Transaktionsverarbeitung eine eher unsichere Phase ist, die sich außerdem beim Wechsel zwischen Versionen stark ändert und beim Ändern von Vertragscodes. Daher sind auch Metriken im Zusammenhang mit der Transaktionsverarbeitung erforderlich, um die Blockchain-Leistung effektiv zu optimieren.

Erhalt einer Benachrichtigung des Kunden über die Aufnahme einer Transaktion in die Blockchain

Dies ist die letzte Phase, in der der Blockchain-Client den Dienst erhält. Im Vergleich zu anderen Phasen fallen keine großen Gemeinkosten an, aber es lohnt sich dennoch, die Möglichkeit in Betracht zu ziehen, dass der Client eine umfangreiche Antwort vom Knoten erhält (z. B. einen Smart Contract). Rückgabe eines Datenarrays). Auf jeden Fall ist dieser Punkt der wichtigste für denjenigen, der die Frage gestellt hat: „Wie viele TPS sind in Ihrer Blockchain?“, denn In diesem Moment wird der Zeitpunkt des Empfangs der Dienstleistung erfasst.

An dieser Stelle wird immer die gesamte Zeit gesendet, die der Client damit verbringen musste, auf eine Antwort von der Blockchain zu warten. Dies ist die Zeit, in der der Benutzer auf die Bestätigung in seiner Anwendung wartet, und es ist deren Optimierung Hauptaufgabe der Entwickler.

Fazit

Infolgedessen können wir die Arten von Operationen beschreiben, die auf Blockchains ausgeführt werden, und sie in mehrere Kategorien einteilen:

kryptografische Transformationen, Beweiskonstruktion
Peer-to-Peer-Netzwerke, Transaktions- und Blockreplikation
Transaktionsverarbeitung, Ausführung von Smart Contracts
Anwenden von Änderungen in der Blockchain auf die Statusdatenbank, Aktualisieren von Daten zu Transaktionen und Blöcken
schreibgeschützte Anfragen an die Statusdatenbank, die Blockchain-Knoten-API und Abonnementdienste

Im Allgemeinen sind die technischen Anforderungen an moderne Blockchain-Knoten äußerst hoch: schnelle CPUs für die Kryptografie, viel RAM zum Speichern und schnellen Zugriff auf die Statusdatenbank, Netzwerkinteraktion über eine große Anzahl gleichzeitig geöffneter Verbindungen und großer Speicher. Solch hohe Anforderungen und die Fülle an unterschiedlichen Arten von Operationen führen unweigerlich dazu, dass Knoten möglicherweise nicht über genügend Ressourcen verfügen, und dann kann jede der oben diskutierten Phasen zu einem weiteren Engpass für die Gesamtleistung des Netzwerks werden.

Bei der Gestaltung und Bewertung der Leistung von Blockchains müssen Sie alle diese Punkte berücksichtigen. Dazu müssen Sie gleichzeitig Metriken von Clients und Netzwerkknoten sammeln und analysieren, nach Korrelationen zwischen ihnen suchen, die Zeit abschätzen, die für die Bereitstellung von Diensten für Clients benötigt wird, und alle wichtigen Ressourcen berücksichtigen: CPU/Speicher/Netzwerk/Speicher , verstehen, wie sie genutzt werden und sich gegenseitig beeinflussen. All dies macht den Vergleich der Geschwindigkeiten verschiedener Blockchains in Form von „Wie viele TPS“ zu einer äußerst undankbaren Aufgabe, da es eine Vielzahl unterschiedlicher Konfigurationen und Zustände gibt. In großen zentralisierten Systemen, Clustern aus Hunderten von Servern, sind diese Probleme ebenfalls komplex und erfordern auch die Erfassung einer großen Anzahl unterschiedlicher Metriken, aber in Blockchains sind es aufgrund von P2P-Netzwerken, virtuellen Maschinen, die Verträge verarbeiten, internen Ökonomien und der Anzahl der Abschlüsse Der Freiheitsgrad ist viel größer, wodurch der Test auch auf mehreren Servern durchgeführt werden kann, er ist nicht indikativ und zeigt nur äußerst ungefähre Werte an, die fast keinen Bezug zur Realität haben.

Daher verwenden wir bei der Entwicklung im Blockchain-Kern eine recht komplexe Software, die den Start einer Blockchain mit Dutzenden von Knoten orchestriert, automatisch einen Benchmark startet und Metriken sammelt, um die Leistung zu bewerten und die Frage zu beantworten: „Hat sie sich im Vergleich zum letzten Mal verbessert?“ ; Ohne diese Informationen ist es äußerst schwierig, Protokolle zu debuggen, die mit mehreren Teilnehmern funktionieren.

Wenn Sie also die Frage „Wie viele TPS befinden sich in Ihrer Blockchain?“ erhalten, bieten Sie Ihrem Gesprächspartner etwas Tee an und fragen Sie ihn, ob er bereit ist, sich ein Dutzend Diagramme anzusehen und sich auch alle drei Kästchen mit Blockchain-Leistungsproblemen und Ihre Vorschläge dazu anzuhören sie lösen...

Source: habr.com