Eine Lieblingsfrage eines nicht-technischen Spezialisten zu einem verteilten System lautet: „Wie viele tps befinden sich in Ihrer Blockchain?“. Die als Antwort angegebene Nummer hat jedoch normalerweise wenig mit dem zu tun, was der Fragesteller hören möchte. Tatsächlich wollte er fragen, ob Ihre Blockchain meinen Geschäftsanforderungen entspricht. Diese Anforderungen sind nicht eine Zahl, sondern viele Bedingungen. Hier finden Sie die Fehlertoleranz des Netzwerks, Anforderungen an die Endgültigkeit, Größe, Art der Transaktionen und viele andere Parameter. Die Antwort auf die Frage „wie viele tps“ ist daher wahrscheinlich nicht einfach und wird fast nie vollständig sein. Ein verteiltes System mit Dutzenden und Hunderten von Knoten, die ziemlich komplexe Berechnungen durchführen, kann sich in einer Vielzahl unterschiedlicher Zustände befinden, die sich auf den Zustand des Netzwerks, Blockchain-Inhalte, technische Fehler, wirtschaftliche Probleme, Netzwerkangriffe und viele andere Gründe beziehen. Die Phasen, in denen Leistungsprobleme möglich sind, unterscheiden sich von herkömmlichen Diensten, und der Blockchain-Netzwerkserver ist ein Netzwerkdienst, der die Funktionalität einer Datenbank, eines Webservers und eines Torrent-Clients kombiniert, was das Lastprofil für alle Subsysteme äußerst schwierig macht : Prozessor, Speicher, Netzwerk, Speicher

So kam es, dass dezentrale Netzwerke und Blockchains für Entwickler zentraler Software eine sehr spezifische und ungewöhnliche Software sind. Daher möchte ich wichtige Aspekte der Leistung und Nachhaltigkeit von dezentralen Netzwerken, Ansätze zu deren Messung und Auffinden von Engpässen hervorheben. Wir werden verschiedene Leistungsprobleme betrachten, die die Geschwindigkeit der Bereitstellung eines Dienstes für Blockchain-Benutzer begrenzen, und die für diese Art von Software spezifischen Funktionen beachten.

Blockchain-Client-Service-Anforderungsstufen

Um ehrlich über die Qualität eines mehr oder weniger komplexen Dienstes zu sprechen, müssen Sie nicht nur Durchschnittswerte, sondern auch Maximal- / Minimalwerte, Mediane und Perzentile berücksichtigen. Theoretisch können wir über 1000 tps in einer Blockchain sprechen, aber wenn 900 Transaktionen mit einer enormen Geschwindigkeit ausgeführt wurden und 100 Transaktionen einige Sekunden lang "aufgelegt" wurden, ist die durchschnittliche Zeit, die für alle Transaktionen gesammelt wurde, keine ganz ehrliche Metrik für einen Kunden, der in wenigen Sekunden konnte die Transaktion nicht abgeschlossen werden. Temporäre „Pits“, die durch fehlende Konsensrunden oder Netzwerktrennung verursacht werden, können einen Dienst, der auf Prüfständen eine hervorragende Leistung zeigte, erheblich ruinieren.

Um einen solchen Engpass zu identifizieren, ist es notwendig, die Phasen, in denen die echte Blockchain möglicherweise Schwierigkeiten hat, Benutzer zu bedienen, gut zu verstehen. Beschreiben wir den Liefer- und Verarbeitungszyklus einer Transaktion sowie das Abrufen eines neuen Blockchain-Status, anhand dessen der Client überprüfen kann, ob seine Transaktion verarbeitet und berücksichtigt wurde.

1. Transaktion wird auf dem Client gebildet
2. Transaktion wird auf dem Client signiert
3. Der Client wählt einen der Knoten aus und sendet seine Transaktion an ihn
4. Der Client abonniert Aktualisierungen der Statusdatenbank der Knoten und wartet auf das Erscheinen der Ergebnisse der Ausführung seiner Transaktion
5. Ein Knoten verbreitet eine Transaktion über ein P2P-Netzwerk
6. Mehrere oder ein BP (Blockproduzent) verarbeiten akkumulierte Transaktionen und aktualisieren die Statusdatenbank
7. BP bildet einen neuen Block, der die erforderliche Anzahl von Transaktionen verarbeitet
8. BP verteilt neuen Block über das P2P-Netzwerk
9. Der neue Block wird an den Knoten übergeben, auf den der Client zugreift
10. Knoten aktualisiert Statusdatenbank
11. Der Knoten sieht die Aktualisierung in Bezug auf den Client und sendet ihm eine Transaktionsbenachrichtigung

Schauen wir uns nun diese Schritte genauer an und beschreiben mögliche Leistungsprobleme bei jedem Schritt. Im Gegensatz zu zentralisierten Systemen berücksichtigen wir auch die Codeausführung auf Netzwerkclients. Sehr oft wird bei der Messung von tps die Transaktionsverarbeitungszeit von Knoten und nicht vom Client erfasst - dies ist nicht ganz ehrlich. Dem Kunden ist es egal, wie schnell der Knoten seine Transaktion verarbeitet hat. Das Wichtigste für ihn ist der Moment, in dem ihm zuverlässige Informationen zu dieser Transaktion, die in der Blockchain enthalten sind, zur Verfügung stehen. Diese Metrik ist im Wesentlichen die Zeit, die zum Abschließen einer Transaktion benötigt wird. Dies bedeutet, dass verschiedene Clients, selbst wenn sie dieselbe Transaktion senden, völlig unterschiedliche Zeiten empfangen können, die vom Kanal, der Last und der Nähe des Knotens usw. abhängen. Daher ist es unbedingt erforderlich, diese Zeit auf Clients zu messen, da dieser Parameter optimiert werden muss.

Transaktionsvorbereitung auf Client-Seite

Beginnen wir mit den ersten beiden Punkten: Die Transaktion wird vom Kunden gebildet und signiert. Seltsamerweise könnte dies aus Sicht eines Kunden auch der Engpass bei der Blockchain-Leistung sein. Dies ist ungewöhnlich für zentralisierte Dienste, die alle Berechnungen und Datenoperationen für sich selbst übernehmen. Der Client bereitet einfach eine kurze Anforderung vor, die eine große Menge von Daten oder Berechnungen anfordern kann, um ein fertiges Ergebnis zu erhalten. In Blockchains wird Client-Code immer leistungsfähiger, und der Blockchain-Kern wird immer leichter, und es ist üblich, Client-Software massive Computeraufgaben zu übertragen. Es gibt Clients in Blockchains, die eine einzelne Transaktion für eine ziemlich lange Zeit vorbereiten können (ich spreche von verschiedenen Merkle-Proofs, prägnanten Proofs, Schwellensignaturen und anderen komplexen Operationen auf der Clientseite). Ein gutes Beispiel für die einfache Überprüfung in der Kette und die schwierige Vorbereitung einer Transaktion auf einem Kunden ist der Nachweis der Zugehörigkeit zu einer auf Merkle-Tree basierenden Liste. Hier ist ein Artikel .

Vergessen Sie auch nicht, dass der Clientcode nicht nur Transaktionen an die Blockchain sendet, sondern zuerst nach dem Status der Blockchain fragt. Diese Aktivität kann sich auf die Netzwerklast und die Blockchain-Knoten auswirken. Wenn Sie also Messungen durchführen, ist es sinnvoll, das Verhalten des Client-Codes so vollständig wie möglich zu emulieren. Selbst wenn Ihre Blockchain über normale Light-Clients verfügt, die der einfachsten Transaktion zur Übertragung eines Assets eine einfache digitale Signatur hinzufügen, werden auf dem Client jedes Jahr noch umfangreichere Berechnungen durchgeführt, kryptografische Algorithmen werden stärker, und dieser Teil der Verarbeitung kann zu einem schwerwiegenden Engpass werden die Zukunft. Seien Sie daher vorsichtig und verpassen Sie nicht die Situation, wenn in einer Transaktion von 3,5 Sekunden 2,5 Sekunden für die Vorbereitung und Unterzeichnung der Transaktion und 1,0 Sekunden für das Senden an das Netzwerk und das Warten auf eine Antwort aufgewendet werden. Um die Risiken dieses Engpasses zu bewerten, müssen Sie Metriken von Client-Computern und nicht nur von Blockchain-Knoten erfassen.

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 ihrer Übernahme im Transaktionspool zu erhalten. Diese Phase ähnelt einem normalen Datenbankzugriff. Der Knoten sollte die Transaktion in den Pool schreiben und Informationen darüber über das P2P-Netzwerk verteilen. Der Ansatz zur Bewertung der Leistung ähnelt hier der Bewertung der Leistung herkömmlicher Web-API-Mikrodienste, und Transaktionen in Blockchains selbst können aktualisiert werden und ihren Status aktiv ändern. Im Allgemeinen kann die Aktualisierung von Transaktionsinformationen in einigen Blockchains mehrmals erfolgen, beispielsweise beim Umschalten zwischen Gabeln einer Kette oder wenn BP über die Absicht informiert, eine Transaktion in einen Block aufzunehmen. Einschränkungen des Volumens dieses Pools und der Anzahl der darin enthaltenen Transaktionen können die Leistung der Blockchain beeinträchtigen. Wenn der Transaktionspool auf die maximal mögliche Größe verstopft ist oder nicht in den Arbeitsspeicher passt, kann die Netzwerkleistung erheblich sinken. Blockchains bieten keinen zentralen Schutz gegen den Fluss von Junk-Nachrichten. Wenn die Blockchain Transaktionen mit hohem Volumen und niedrige Gebühren unterstützt, kann dies zu einem Überlauf des Transaktionspools führen. Dies ist ein weiterer potenzieller Leistungsengpass.

In Blockchains leitet der Client die Transaktion an einen beliebigen Blockchain-Knoten weiter. Der Hash der Transaktion ist dem Client normalerweise vor dem Senden bekannt. Er muss also nur eine Verbindung herstellen und nach der Übertragung warten, bis die Blockchain ihren Status ändert, und die Transaktion aktivieren. Beachten Sie, dass Sie durch Messen von "tps" völlig unterschiedliche Ergebnisse für verschiedene Arten der Verbindung mit einem Blockchain-Knoten erhalten können. Dies kann ein normaler HTTP-RPC oder WebSocket sein, mit dem Sie das Muster "Abonnieren" implementieren können. Im zweiten Fall erhält der Client früher eine Benachrichtigung, und der Knoten verwendet weniger Ressourcen (hauptsächlich Speicher und Datenverkehr) für Antworten zum Status der Transaktion. Wenn Sie also "tps" messen, müssen Sie berücksichtigen, wie Clients eine Verbindung zu Knoten herstellen. Um die Risiken dieses Engpasses beurteilen zu können, muss der Benchmark der Blockchain in der Lage sein, Clients mit WebSocket- und HTTP-RPC-Anforderungen in Bruchteilen zu emulieren, die realen Netzwerken entsprechen, sowie die Art der Transaktionen und ihre Größe zu ändern.

Um die Risiken dieses Engpasses zu bewerten, müssen Sie auch Metriken von Client-Computern und nicht nur von Blockchain-Knoten erfassen.

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

In Blockchains wird das Peer-to-Peer-Netzwerk (p2p) verwendet, um zwischen Transaktionsteilnehmern und Blöcken zu übertragen. Transaktionen werden über das Netzwerk verteilt, beginnend mit einem der Knoten, bis sie Peer-Blöcke von Produzenten erreichen, die Transaktionen in Blöcke packen und mit demselben p2p neue Blöcke über alle Knoten des Netzwerks verteilen. Die Basis der meisten modernen P2P-Netzwerke sind verschiedene Modifikationen des Kademlia-Protokolls. Hier ist ein guter kurzer Überblick über dieses Protokoll, und hier ist ein Artikel mit verschiedenen Messungen im BitTorrent-Netzwerk, nach dem Sie verstehen können, dass dieser Netzwerktyp komplizierter und weniger vorhersehbar ist als ein hart konfiguriertes zentrales Dienstnetzwerk. Hier ist auch ein Artikel über das Messen verschiedener interessanter Metriken für Ethereum-Knoten.

Kurz gesagt, jeder Peer in solchen Netzwerken führt eine eigene dynamische Liste anderer Peers, die Informationsblöcke anfordern, die von Inhalten adressiert werden. Nach Empfang der Anforderung gibt der Peer entweder die erforderlichen Informationen an oder sendet die Anforderung an den nächsten pseudozufälligen Peer aus der Liste. Nach Erhalt der Antwort leitet er sie an den Anforderer weiter und speichert sie für eine Weile zwischen, wobei er diesen Informationsblock das nächste Mal früher weitergibt. Daher erscheinen populäre Informationen in einer großen Anzahl von Caches in einer großen Anzahl von Peers, und unpopuläre Informationen werden allmählich verdrängt. Peers verfolgen, wer wie viele Informationen an wen übermittelt hat, und das Netzwerk versucht, aktive Distributoren zu stimulieren, indem es ihre Bewertung erhöht und ihnen ein höheres Serviceniveau bietet, wodurch inaktive Teilnehmer automatisch von der Liste der Peers gestrichen werden.

Daher muss die Transaktion jetzt über das Netzwerk verteilt werden, damit Blockhersteller sie sehen und in den Block aufnehmen können. Noda "verteilt" aktiv eine neue Transaktion an alle und hört auf das Netzwerk und wartet auf den Block, in dessen Index die erforderliche Transaktion angezeigt wird, um den wartenden Client zu benachrichtigen. Die Zeit, bis das Netzwerk sich gegenseitig Informationen über neue Transaktionen und Blöcke in P2P-Netzwerken sendet, hängt von einer sehr großen Anzahl von Faktoren ab: der Anzahl der ehrlichen Knoten, die in der Nähe arbeiten (aus Netzwerksicht), dem "Aufwärmen" der Caches dieser Knoten, der Größe der Blöcke, Transaktionen, der Art der Änderungen , Netzwerkgeographie, Anzahl der Knoten und viele andere Faktoren. Umfassende Messungen von Leistungsmetriken in solchen Netzwerken sind eine komplexe Angelegenheit. Es ist erforderlich, gleichzeitig die Verarbeitungszeit von Anforderungen auf Clients und Peers (Blockchain-Knoten) zu bewerten. Probleme bei einem der p2p-Mechanismen, fehlerhafte Datenextrusion und Caching, ineffiziente Verwaltung aktiver Peer-Listen und viele andere Faktoren können zu Verzögerungen führen, die sich auf die Effizienz des gesamten Netzwerks auswirken. Dieser Engpass ist am schwierigsten zu analysieren, zu testen und zu testen Interpretation der Ergebnisse.

Blockkettenverarbeitung und Aktualisierung der Statusdatenbank

Der wichtigste Teil der Arbeit der Blockchain ist der Konsensalgorithmus, seine Anwendung auf neue vom Netzwerk empfangene Blöcke und die Transaktionsverarbeitung mit Aufzeichnung der Ergebnisse in der Statusdatenbank. Das Hinzufügen eines neuen Blocks zur Kette und die anschließende Auswahl der Hauptkette sollte so schnell wie möglich funktionieren. Im wirklichen Leben bedeutet "sollte" jedoch nicht "funktioniert", und Sie können sich beispielsweise eine Situation vorstellen, in der zwei lange konkurrierende Ketten ständig untereinander wechseln, die Metadaten von Tausenden von Transaktionen im Pool bei jedem Wechsel ändern und den Status der Statusdatenbank ständig zurücksetzen. Dieser Schritt zur Ermittlung des Engpasses ist einfacher als die Netzwerk-P2P-Schicht, weil Die Transaktionsausführung und der Konsensalgorithmus sind streng festgelegt, und die Messung hier ist einfacher.
Die Hauptsache ist, die zufällige Verschlechterung der Leistung dieser Stufe nicht mit Netzwerkproblemen zu verwechseln - die Knoten geben Blöcke und Informationen über die Hauptkette langsamer und für einen externen Client kann es wie ein langsames Netzwerk aussehen, obwohl das Problem an einer völlig anderen Stelle liegt.

Um die Leistung in dieser Phase zu optimieren, ist es hilfreich, Metriken von den Knoten selbst zu erfassen und zu überwachen und diejenigen einzuschließen, die sich auf Aktualisierungen der Statusdatenbank beziehen: die Anzahl der auf dem Knoten verarbeiteten Blöcke, ihre Größe, Anzahl der Transaktionen, Anzahl der Switches zwischen Kettengabeln, Anzahl ungültiger Blöcke , Laufzeit der virtuellen Maschine, Festschreibungszeit der Daten usw. Dies wird Netzwerkprobleme nicht mit Fehlern in den Kettenverarbeitungsalgorithmen verwechseln.

Eine virtuelle Maschine, die Transaktionen durchläuft, kann eine nützliche Informationsquelle sein, die den Betrieb der Blockchain optimieren kann. Die Anzahl der Speicherzuweisungen, die Anzahl der Lese- / Schreibanweisungen und andere Metriken hinsichtlich der Effizienz der Ausführung von Vertragscode können Entwicklern viele nützliche Informationen liefern. Gleichzeitig sind intelligente Verträge Programme, was bedeutet, dass sie theoretisch alle Ressourcen verbrauchen können: CPU / Speicher / Netzwerk / Speicher. Daher ist die Transaktionsverarbeitung ein ziemlich unsicherer Schritt, der sich beim Wechsel zwischen Versionen und wann zusätzlich stark ändert Änderung des Vertragscodes. Daher sind auch Metriken zur Transaktionsverarbeitung erforderlich, um die Blockchain-Leistung effektiv zu optimieren.

Client erhält Benachrichtigung über die Aufnahme von Transaktionen in die Blockchain

Dies ist die letzte Phase des Empfangs eines Blockchain-Dienstes durch einen Client. Im Vergleich zu anderen Phasen gibt es keinen großen Overhead. Es lohnt sich jedoch, die Möglichkeit in Betracht zu ziehen, dass ein Client eine Volumenantwort von einem Knoten erhält (z. B. einen intelligenten Vertrag, der ein Array von Daten zurückgibt). In jedem Fall ist dieser Moment der wichtigste für denjenigen, der die Frage gestellt hat: "Wie viele tps sind in Ihrer Blockchain?", Weil In diesem Moment ist der Zeitpunkt des Empfangs des Dienstes festgelegt.

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

Fazit

Infolgedessen ist es möglich, die Arten von Operationen zu beschreiben, die an Blockchains ausgeführt werden, und sie in mehrere Kategorien zu unterteilen:

1. kryptografische Transformationen, Beweisbildung
2. Peer-to-Peer-Netzwerk, Transaktions- und Blockreplikation
3. Transaktionsverarbeitung, Ausführung intelligenter Verträge
4. Anwenden von Änderungen in der Blockchain auf die Statusdatenbank, Aktualisieren von Transaktions- und Blockdaten
5. Schreibgeschützte Anforderungen an Statusdatenbank, Blockchain-Knoten-API und Abonnementdienste

Im Allgemeinen sind die technischen Anforderungen an die Knoten moderner Blockchains äußerst hoch: Es handelt sich um schnelle CPUs für die Kryptografie, eine große Menge an RAM zum Speichern und schnellen Zugriff auf die Statusdatenbank, Netzwerkinteraktion mit einer großen Anzahl gleichzeitig geöffneter Verbindungen und Volumenspeicher. Solche hohen Anforderungen und die Fülle verschiedener Arten von Operationen führen unweigerlich dazu, dass die Ressourcen der Knoten möglicherweise nicht ausreichen, und dann kann jeder der oben diskutierten Schritte zum nächsten Engpass für die gesamte Netzwerkleistung werden.

Bei der Entwicklung und Bewertung der Leistung von Blockchains müssen Sie alle diese Punkte berücksichtigen. Dazu müssen Sie gleichzeitig Metriken von Clients und Netzwerkknoten erfassen und analysieren, nach Korrelationen zwischen ihnen suchen, die Zeit bewerten, zu der der Service für Kunden bereitgestellt wird, alle wichtigen Ressourcen berücksichtigen: CPU / Speicher / Netzwerk / Speicher, verstehen, wie sie verwendet werden, und sich gegenseitig beeinflussen. All dies macht den Vergleich der Geschwindigkeiten verschiedener Blockchains in Form von „wie vielen TPS“ zu einer äußerst undankbaren Aufgabe, da es eine Vielzahl unterschiedlicher Konfigurationen und Bedingungen gibt. In großen zentralisierten Systemen, Clustern von Hunderten von Servern, sind diese Probleme ebenfalls komplex und erfordern auch die Erfassung einer großen Anzahl unterschiedlicher Metriken. In Blockchains ist jedoch aufgrund von P2P-Netzwerken, virtuellen Maschinen, auf denen Verträge ausgeführt werden, der internen Wirtschaftlichkeit die Anzahl der Freiheitsgrade viel größer, was den Test ausmacht Selbst auf mehreren Servern werden nur extrem ungefähre Werte angezeigt, die fast keinen Zusammenhang mit der Realität haben.

Daher verwenden wir bei der Entwicklung einer Blockchain im Kernel, um die Leistung zu bewerten und die Frage zu beantworten, ob sie sich im Vergleich zum letzten Mal verbessert hat, eine ziemlich komplizierte Software, die den Start der Blockchain mit Dutzenden von Knoten koordiniert und den Benchmark automatisch startet und Metriken sammelt. Ohne diese Informationen ist das Debuggen äußerst schwierig Protokolle, die mit vielen Teilnehmern funktionieren.

Nachdem Sie die Frage „Wie viele TPS befinden sich in Ihrer Blockchain?“ Erhalten haben, bieten Sie der Person, mit der Sie sprechen, Tee an und finden Sie heraus, ob sie bereit ist, sich mit einem Dutzend Diagrammen vertraut zu machen. Hören Sie sich auch alle drei Felder mit Blockchain-Leistungsproblemen und Ihre Lösungsvorschläge an.