Es gibt viele Metriken, die sich auf die Logik und Qualität der Blockchain beziehen. Sie helfen dabei, Engpässe im Code zu identifizieren und logische und Optimierungsprobleme im Konsens und in den endgültigen Algorithmen in Blockchains zu finden. Jede Entwicklung verteilter Systeme, einschließlich Blockchains, erfordert eine Analyse der Arbeit vieler Knoten gleichzeitig. Sie ermöglichen es dem Projektteam, den Status des gesamten Blockchain-Netzwerks zu überwachen, Probleme mit einzelnen Knoten zu erkennen, das Auftreten von DoS-Angriffen auf das Netzwerk zu erkennen und vieles mehr. Schauen wir uns die wichtigsten an. Lass uns eintauchen.
"Transaktionen pro Sekunde"
Bei verteilten Systemen ist TPS eine sehr launische und mehrdeutige Zahl, die nicht immer die tatsächliche Qualität des den Benutzern bereitgestellten Dienstes widerspiegelt. TPS-Messungen kamen aus verteilten Datenbanken zu uns. TPS in Datenbanken sind einige standardisiert für die Testtransaktionen oder ihre Sätze (einige INSERT, einige UPDATE, so viele DELETEs vor dem Hintergrund der Konstanten SELECT) für eine fest codierte Clusterkonfiguration oder sogar auf demselben Computer. Diese Metriken geben normalerweise nur grobe Schätzungen der Leistung verteilter Datenbanken oder Blockchains, da die Transaktionsverarbeitungszeit in Abhängigkeit von vielen Faktoren stark variieren kann.
Konsistenzorientierte Datenbanken (siehe „CAP-Theorem“) schreiben die Transaktion erst fest, wenn sie eine ausreichende Anzahl von Bestätigungen von anderen Knoten erhalten, und dies ist langsam. Verfügbarkeitsorientierte Datenbanken betrachten eine Transaktion, die einfach auf die Festplatte geschrieben wurde, als Erfolg. Sie geben dem Kunden sofort aktualisierte Daten und diese sind sehr schnell (obwohl diese Transaktion in Zukunft möglicherweise zurückgesetzt wird). Wenn die im Benchmark verwendeten Transaktionen nur eine Zelle mit Daten aktualisieren, ist der TPS offensichtlich höher als in Fällen, in denen Transaktionen viele Zellen beeinflussen und sich gegenseitig blockieren können. Die Algorithmen für die Arbeit mit diesen Sperren in jeder Datenbank sind auf ihre eigene Weise implementiert. Deshalb sehen wir keine "TPS-Wettbewerbe" zwischen Oracle, MSSQL, PostgreSQL einerseits und MongoDB, Redis, Tarantool andererseits. Dies sind sehr unterschiedliche interne Mechanismen und unterschiedliche Aufgaben .
Meiner Meinung nach bedeutet „Messen des TPS“ der Blockchain, dass alle Leistungsmessungen der Blockchain durchgeführt werden:
- unter wiederholbaren Bedingungen
- mit einer realitätsnahen Anzahl von Blockvalidatoren
- mit verschiedenen Arten von Transaktionen:
- typisch für die untersuchte Blockchain (z. B. transfer () der Hauptkryptowährung)
- Laden des Speichersubsystems (eine große Anzahl von Änderungen aus jeder Transaktion)
- Ladebandbreite (großes Transaktionsvolumen)
- CPU-Auslastung (bei massiven Kryptotransformationen oder Berechnungen)
Um über die geschätzten „Transaktionen pro Sekunde“ zu sprechen, müssen Sie alle Bedingungen (Anzahl der Validatoren, Geoverteilung, Paketverluststufe usw.) und die Logik des Benchmarking beschreiben. In Blockchains bedeutet das einfache Rollen einer Transaktion in einer internen Datenbank nicht, dass sie im Konsens akzeptiert wird. Im Fall von Proof-of-Work werden Transaktionen statistisch gesehen überhaupt nicht abgeschlossen. Wenn eine Transaktion in einem Block auf einem Computer enthalten ist, bedeutet dies nicht, dass sie vom gesamten Netzwerk akzeptiert wird (z. B. wenn eine andere Abzweigung gewinnt).
Wenn die Blockchain über einen zusätzlichen Algorithmus verfügt, um die Endgültigkeit von Transaktionen sicherzustellen (EOS, Ethereum 2.0, Polkadot-Fallschirme, die einen Konsens mit der GRANDPA-Endgültigkeit verwenden), kann die Verarbeitungszeit als Lücke zwischen dem Knoten, der die Transaktion „gesehen“ hat, und dem nächsten abgeschlossenen Block betrachtet werden, in dem sich diese Transaktion befand enthalten. Solch realitätsnahes „TPS“ wird in Projektversprechen selten gesehen. Natürlich sind sie niedriger als die im Whitepaper beschriebenen, aber sie sind so informativ wie möglich.
Ich warne Sie also noch einmal, dass der Begriff „TPS“ viele verschiedene Bedeutungen enthalten kann. Seien Sie skeptisch und fragen Sie nach Details.
Blockchain-spezifische Metriken
Lokale tps
Die Anzahl der vom Knoten verarbeiteten Transaktionen und die maximale / durchschnittliche / minimale Verarbeitungszeit auf dem lokalen Knoten sind sehr bequem zu messen, da die Funktionen, die diese Operation ausführen, normalerweise explizit im Code zugewiesen werden. Sie können einfach messen, wie lange die Transaktion funktioniert hat, indem Sie die Statusdatenbank aktualisieren. Diese Transaktionen werden möglicherweise noch nicht im Konsens akzeptiert, haben jedoch die Validierung bereits bestanden, und der Knoten kann dem Client bereits aktualisierte Daten bereitstellen (vorausgesetzt, die Gabelkette wird nicht angezeigt).
Diese Metrik ist nicht sehr ehrlich: Wenn ein anderer Teil der Kette als Hauptzweig ausgewählt wird, müssen auch Statistiken zu zurückgesetzten Transaktionen zurückgesetzt werden. Zum Testen kann dies jedoch fast immer vernachlässigt werden.
Oft ist dies die Zahl, die in kurzen Berichten geschrieben steht: "Unsere Blockchain hat gestern 8.000 tps erhalten", da es einfach zu messen ist - nur ein laufender Knoten und ein Skript, das sie lädt, reichen aus. In diesem Fall gibt es keine Netzwerkverzögerung, die das Erreichen des Konsenses im Netzwerk verlangsamt, und die Metrik zeigt die Leistung der Statusdatenbank ohne den Einfluss des Netzwerks. Diese Zahl ist nicht die tatsächliche Bandbreite des Blockchain-Netzwerks, sondern zeigt die Grenze an, bis zu der es streben wird, wenn der Konsens und das Netzwerk schnell genug sind.
Das Ergebnis jeder Blockchain-Transaktion sind mehrere atomare Aktualisierungen des Speichers. Ein Zahlungsvorgang in Bitcoin ist beispielsweise das Entfernen mehrerer alter UTXO (Löschen) und das Hinzufügen mehrerer neuer UTXO (Einfügen). In Ethereum wird ein kurzer intelligenter Vertragscode ausgeführt und erneut mehrere Schlüssel-Wert-Paare aktualisiert. Die Anzahl dieser "atomaren" Schreibvorgänge kann eine hervorragende Metrik sein, mit der Sie Engpässe im Speichersubsystem und in der internen Transaktionslogik identifizieren können.
Blockchain-Knoten können auch in mehreren Programmiersprachen implementiert werden - dies ist zuverlässiger. Dies sollte bei der Bewertung der Netzwerkleistung berücksichtigt werden. Beispielsweise ist der Ethereum-Knoten in Implementierungen auf Rust and Go vorhanden. Andere Blockchains streben ebenfalls zusätzliche Implementierungen für die Zuverlässigkeit an.
Lokal produzierte Blockmenge
Diese einfache Metrik zeigt, welcher Validator wie viele Blöcke produziert hat. Es ist ein Konsensprodukt und kann als das Hauptprodukt zur Bewertung des „Nutzens“ für ein Netzwerk einzelner Validatoren angesehen werden.
Validatoren, die mit jedem Block Geld verdienen, sind an einem stabilen Betrieb und der Sicherheit ihrer Maschinen interessiert. Diese Nummer hilft zu bestimmen, welcher der Kandidaten-Validatoren am besten qualifiziert, geschützt und bereit ist, in einem öffentlichen Netzwerk mit den Ressourcen realer Benutzer zu arbeiten. Der Wert der Metrik kann öffentlich überprüft werden, indem einfach die Blockchain heruntergeladen und berechnet wird, wer wie viele Blöcke produziert hat.
Endgültigkeit und letzter irreversibler Block
In Netzwerken mit klar implementierter Endgültigkeit (EOS, Ethereum, Tendermint, Polkadot usw.) erfordern einige Blöcke zusätzlich zum grundlegenden, schnellen Konsens (bei dem eine Validatorsignatur pro Block ausreicht) die Koordination durch eine Gruppe von Validatoren. Diese Blöcke gelten als endgültig, und der Signaturerfassungsalgorithmus wird als endgültig betrachtet. Die Aufgabe der Endgültigkeit besteht darin, sicherzustellen, dass alle Transaktionen, die in der Blockchain vor dem finalisierten Block enthalten sind, niemals abgepumpt und nicht durch einen anderen Zweig der Kette ersetzt werden. Dies ist ein Schutz vor Angriffen mit doppelten Ausgaben in Proof-of-Stake-Netzwerken und eine Möglichkeit, einem Benutzer in wenigen Sekunden schnell eine zuverlässige Bestätigung einer Kryptowährungstransaktion zurückzugeben.
Aus Sicht des Blockchain-Benutzers wird die Transaktion nicht zu dem Zeitpunkt abgeschlossen, zu dem sie vom Knoten akzeptiert wird, sondern wenn ein Block angezeigt wird, der die Kette abschließt, in der sich die Transaktion befindet. Um einen Block abzuschließen, müssen Validatoren diesen Block in einem P2P-Netzwerk empfangen und Signaturen miteinander austauschen. Hier wird die tatsächliche Geschwindigkeit der Blockchain überprüft, da der Benutzer daran interessiert ist, den Block mit seiner Transaktion abzuschließen und ihn nicht nur zu akzeptieren und auf die Festplatte eines der Knoten zu schreiben.
Finalitätsalgorithmen unterscheiden sich auch, überschneiden sich und kombinieren sich mit dem Hauptkonsens (zu lesen: Casper in Ethereum, Last Irreversible Blocks in EOS, GRANDPA in Parity Polkadot und deren Modifikationen, zum Beispiel MixBytes RANDPA).
Für Netzwerke, in denen nicht jeder Block finalisiert ist, ist eine nützliche Metrik die Verzögerung des letzten finalisierten Blocks gegenüber dem aktuellen letzten Block. Diese Zahl zeigt, wie die Validatoren zurückbleiben und sich auf die richtige Kette einigen. Wenn die Lücke groß ist, erfordert der Finalisierungsalgorithmus zusätzliche Analyse und Optimierung.
Andere Blockchain-Metriken
Der Rest der Metriken hängt normalerweise stark von der Art des Konsenses ab, daher ist es nicht sehr richtig, sie unter den wichtigsten darzustellen. Zu diesen Parametern gehören beispielsweise die Anzahl der Kettengabeln, ihre Länge in Blöcken, die Belegung von Blöcken mit Transaktionen usw. Sie können verwendet werden, um Netzwerktrennungssituationen zu identifizieren oder Probleme eines bestimmten Validators schnell zu lokalisieren.
P2P-Schicht
Es ist äußerst wichtig, sich an die Zwischenbasis von Blockchain-Netzwerken zu erinnern - das Peer-to-Peer-Subsystem. Sie ist es, die vage Verzögerungen bei der Lieferung von Blöcken und Transaktionen zwischen Validatoren einführt. Wenn die Anzahl der Validatoren gering ist, werden sie lokalisiert, Peer-Listen sind fest codiert, alles funktioniert gut und schnell. Es lohnt sich jedoch, Validatoren hinzuzufügen, Knoten geografisch zu verteilen und den Paketverlust zu emulieren, da in "tps" erhebliche Fehler auftreten.
Wenn Sie beispielsweise den EOS-Konsens mit dem optionalen Finalitätsalgorithmus testen, hat die Erhöhung der Anzahl der Validatoren auf 80 bis 100 Maschinen auf vier Kontinenten die Geschwindigkeit des Erreichens der Finalität nicht wesentlich beeinflusst. Gleichzeitig wirkte sich eine Zunahme des Paketverlusts stark auf die Verzögerung der Endgültigkeit aus, was darauf hinweist, dass eine zusätzliche Konfiguration der p2p-Schicht erforderlich ist, um einen höheren Widerstand gegen den Verlust von Netzwerkpaketen und nicht gegen eine große Latenz zu gewährleisten. Leider gibt es viele verschiedene Einstellungen und Faktoren, daher können wir nur anhand von Benchmarks die effektive Anzahl von Validatoren verstehen, die eine recht komfortable Geschwindigkeit der Blockchain bieten.
Das p2p-Subsystem des Geräts kann aus der Dokumentation beispielsweise zu libp2p oder der Dokumentation zum Kademlia- oder BitTorrent- Protokoll verstanden werden.
Wichtige Metriken für p2p sind:
- eingehender und ausgehender Verkehr
- Anzahl erfolgreicher / erfolgloser Verbindungen mit anderen Peers
- Wie oft wurden zuvor zwischengespeicherte Chunk-Daten zurückgegeben und wie oft musste die Anforderung auf der Suche nach dem gewünschten Chunk weiter weitergeleitet werden (analog zu Cache-Treffern / -Fehlern)?
Zum Beispiel bedeutet eine große Anzahl von Fehlern beim Zugriff auf Daten, dass nur eine kleine Anzahl von Knoten die angeforderten Daten hat und sie keine Zeit haben, sie an alle zu verteilen, und die Menge des empfangenen / gegebenen P2P-Verkehrs ermöglicht es Ihnen, einen Knoten einzurichten, der Probleme mit der Netzwerkkonfiguration oder dem Kanal hat.
Systemmetriken für Blockchain-Knoten
Die Standardsystemmetriken von Blockchain-Knoten werden in einer Vielzahl von Quellen beschrieben, daher werde ich sie kurz beschreiben. Ihre Aufgabe besteht darin, bei der Suche nach Engpässen und Fehlern in allen Teilen des Codes zu helfen und zu zeigen, welche Subsysteme der Knoten am meisten geladen sind und welche Aufgaben.
CPU
Sie sprechen darüber, wie viele Berechnungen der Prozessor durchführt. Wenn die CPU-Auslastung hoch ist, berechnet der Knoten etwas, indem er aktiv Logik oder FPU verwendet (fast nie in Blockchains verwendet). In Blockchains kann dies beispielsweise darauf zurückzuführen sein, dass der Knoten elektronische Signaturen überprüft, Transaktionen mit starker Kryptografie verarbeitet oder komplexe Berechnungen durchführt.
Die CPU kann in mehrere weitere nützliche Metriken unterteilt werden, um zu verstehen, welche Teile des Codes am teuersten sind. Das System ist beispielsweise der Kernel-Code, der Benutzer ist der Benutzerprozess, io wartet auf E / A von langsamen externen Geräten (Festplatte / Netzwerk) usw. Hier ist ein guter verwandter Artikel .
Speicher
Moderne Blockchains verwenden Schlüsselwertdatenbanken (LevelDB, RocksDB), die ständig heiße Daten im Speicher halten. Wie bei allen geladenen Diensten sind Speicherverluste aufgrund von Fehlern oder gezielten Angriffen auf den Knotencode immer möglich. Wenn der Verbrauch des Speicherknotens zunimmt oder stark zugenommen hat, wird dies höchstwahrscheinlich durch eine Zunahme der Anzahl von Schlüsseln in der Statusdatenbank, große Transaktionswarteschlangen oder eine Zunahme der Anzahl von Nachrichten zwischen verschiedenen Subsystemen des Knotens verursacht. Eine Unterlastung des Speichers kann auf eine mögliche Erhöhung der Datenlimits in Blöcken oder auf eine maximale Transaktionskomplexität hinweisen.
Für Vollknoten (https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png), die Netzwerkclients entsprechen, sind auch Dateicache-Metriken wichtig. Clients greifen auf verschiedene Teile der Statusdatenbank und des Transaktionsprotokolls zu. Dies führt zu einem Anstieg alter Blöcke von der Festplatte, wodurch neue Blöcke verdrängt werden können, was wiederum die Reaktion auf den Client verlangsamt.
Netzwerk
Die wichtigsten internen Netzwerkmetriken sind die Menge des Datenverkehrs in Bytes, die Anzahl der gesendeten und empfangenen Netzwerkpakete für jedes Protokoll sowie die Paketverlustrate. In Blockchains wird diesen Metriken oft nicht viel Aufmerksamkeit geschenkt, weil Blockchains verarbeiten Transaktionen noch nicht mit einer Geschwindigkeit von 1 Gbit / s.
Es gibt Blockchain-Projekte, mit denen Benutzer ihr WLAN freigeben oder Dienste zum Speichern und Übertragen von Dateien oder Nachrichten bereitstellen können. Beim Testen solcher Netzwerke werden Quantität und Qualität des Datenverkehrs über die Netzwerkschnittstelle zu äußerst wichtigen Messgrößen, da ein überfüllter Netzwerkkanal ausnahmslos alle anderen Dienste auf dem Computer beeinflusst.
Lagerung
Das Festplattensubsystem ist die langsamste Komponente in einem Dienst und verursacht häufig schwerwiegende Leistungsprobleme. Übermäßige Protokollierung, eine unerwartete Sicherung, ein unbequemes Lese- / Schreibmuster, ein großes Blockchain-Gesamtvolumen - all dies kann zu einer erheblichen Verlangsamung des Knotenbetriebs oder zu ernsthaft übermäßigen Anforderungen an die Hardware führen.
Das Transaktionsprotokoll kann technisch als WAL ( WAL ) für die Statusdatenbank betrachtet werden. Daher sind diese Speichermetriken wichtig, mit denen Sie nach Engpässen in den Mechanismen moderner Schlüsselwertdatenbanken suchen können. Dies sind die Anzahl der Lese- / Schreib-IOPS, die maximale / min / durchschnittliche Latenz und viele andere Metriken, die zur Optimierung des Festplattenbetriebs beitragen.
Fazit
Daher haben wir verschiedene Metriksätze untersucht, die sehr wertvolle Informationen über den Betrieb des Blockchain-Netzwerks und die Möglichkeiten seiner Optimierung liefern können. Zusammenfassend können Sie sie in drei Gruppen sammeln:
- Blockchain-Metriken von Knoten:
die Anzahl der produzierten Blöcke, die Anzahl der verarbeiteten Transaktionen, ihre Verarbeitungszeit, die Finalisierungszeit usw. - Subsystem P2P-Metriken:
die Anzahl der Hit / Miss-Anfragen, die Anzahl der aktiven Peers, das Volumen und die Struktur des P2P-Verkehrs usw. - Systemmetriken von Knoten:
CPU, Speicher, Speicher, Netzwerk usw.
Jede der Gruppen ist auf ihre Weise wichtig, da in jedem der Subsysteme Fehler auftreten können, die den Betrieb anderer Komponenten einschränken, und eine Verlangsamung selbst einer kleinen Anzahl von Validatoren schwerwiegende Auswirkungen auf das gesamte Netzwerk haben kann. Außerdem treten die schwierigsten Fehler bei Konsens- und Finalitätsalgorithmen nur bei einem großen Transaktionsfluss oder Änderungen der Konsensparameter auf. Ihre Analyse erfordert reproduzierbare Testbedingungen und komplexe Lastszenarien.
Die Entwicklung von Blockchains ist immer die Orchestrierung mehrerer Maschinen, Skripte zum Erstellen von Konfigurationen und zum koordinierten Starten von Knoten und Benchmarks, ein Server zum Sammeln von Metriken und Protokollen von allen Maschinen. Erwägen Sie daher bei der Entwicklung Ihrer Blockchain, einen qualifizierten Entwickler einzustellen, der dem Entwicklungsteam unschätzbare Unterstützung bietet. Viel glück