Das Binance-Ledger: der Motor unter der Haube der Binance-Plattform
Die wichtigsten Punkte
Das Ledger von Binance speichert Kontostände und Transaktionen und ermöglicht die Durchführung von Transaktionen.
Es schafft die Voraussetzungen für hohen Durchsatz, Rund-um-die Uhr-Verfügbarkeit und Datengenauigkeit auf Bit-Ebene.
Das Fundament von Binance – warum das Binance-Ledger eine der wichtigsten Technologien der Binance-Plattform ist. Erfahre hier, wie es genau aufgebaut ist und welche Probleme es beim Betrieb der größten Kryptobörse der Welt löst.
Hast du dich jemals gefragt, wie Binance von einem technischen Standpunkt aus gesehen eigentlich funktioniert? Angesichts der Notwendigkeit, täglich Millionen von Transaktionen für eine riesige Nutzerbasis zu verarbeiten, lohnt es sich, einen Blick auf den Motor unter der Haube der Binance-Plattform zu werfen.
Das Fundament der technischen Operationen von Binance ist sein Ledger. Dieses speichert Kontostände und Transaktionen und ermöglicht die Durchführung von Transaktionen.
Hohe Anforderungen an das Binance-Ledger
Wie du dir vorstellen kannst, sind die Anforderungen an das Ledger hoch, damit es der massiven Nachfrage der Nutzer gewachsen ist. Das Hauptbuch von Binance muss vor allem drei wichtigen Kriterien genügen:
Hoher Durchsatz mit der Kapazität für eine große Anzahl von TPS (Transaktionen pro Sekunde) zu Höchstlastzeiten
Rund-um-die-Uhr-Verfügbarkeit ohne Ausfallzeiten
Datengenauigkeit auf Bit-Ebene, ohne Mittelverluste oder Transaktionsfehler
Schauen wir uns ein Beispiel für einen einfachen Ledger-Eintrag an. Hier ist eine übliche Transaktion, bei der 1 BTC von Konto 1 auf Konto 2 überwiesen wird.
Guthaben vor der Transaktion:
Saldo vor der Transaktion:
Guthaben nach der Transaktion:
Tabelle 2
Bei dieser Transaktion gibt es zwei Befehle:
Konto 1 -1 BTC
Konto 2 +1 BTC
Bei der Transaktion werden zwei Guthabenprotokolle für die Prüfung und den Abgleich gespeichert.
Tabelle 3
Die Standardlösung der Branche
Branchenübliche Ledger-Lösungen basieren auf einer relationalen Datenbank. Um zum vorherigen Beispiel zurückzukehren, können die beiden Befehle der Transaktion in zwei SQL-Befehle übersetzt und in einer Datenbanktransaktion ausgeführt werden (Tabelle 4) .
Tabelle 4
Die Vorteile der Lösung
Sie ist recht einfach zu implementieren.
Es ist einfach, gängige Datenbankoptimierungstechniken wie Lesen/Schreiben-Splitting und Sharding anzuwenden, um die Leistung zu verbessern.
Die Wiederherstellung nach einem Failover sowie die Überwachung und Wartung einer kommerziellen Datenbank sind für die Entwickler leicht zu bewerkstelligen.
Die Nachteile der Lösung
Die Transaktionen pro Sekunde (TPS) sinken stark, wenn es aufgrund von Zeilensperren (Rowlocks) zu Wettlaufsituationen (Race conditions) kommt.
Leistungsverbesserungen durch horizontale Skalierung sind schwierig.
Das sogenannte Hot-Account-Problem
Leider wird die branchenübliche Standardlösung den hohen Anforderungen von Binance nicht gerecht. Während einer Transaktion müssen die Zeilensperren für jede betroffene Zeile aufrechterhalten werden. Während einige Konten relativ wenige Transaktionen zu bewältigen haben, gibt es natürlich auch stark beanspruchte Konten, die viele Transaktionen gleichzeitig ausführen. In diesem Fall kann nur eine Transaktion Zeilensperren für dieses Konto vornehmen.
Die anderen Transaktionen können dann nichts weiter tun, als auf die Freigabe der Sperre zu warten. Wir bezeichnen diese Situation als das Hot-Account-Problem stark beanspruchter Konten, und interne Tests haben gezeigt, dass die TPS dabei um mindestens das Zehnfache sinken. Dieses Problem ist nachfolgend in Tabelle 5 dargestellt.
Beispiel für ein Hot-Account:
Tabelle 5
Die Ledger-Lösung von Binance
Wie lösen wir das Hot-Account-Problem?
Eine mögliche Lösung für unser Problem besteht darin, das Multi-Thread-Modell auf innovative Weise in einen Single-Thread-Modus umzuwandeln. Dadurch wird die Wettlaufsituation vermieden, und das Hot-Account-Problem tritt nicht auf.
Neues Thread-Modell
Nachrichtenbasierte Kommunikation
Nach der Implementierung unseres neuen Thread-Modells muss noch ein Kommunikationsproblem gelöst werden. Die Zustandsmaschinenebene ist eine Single-Thread-Ebene, aber die Netzwerkebene ist eine Multi-Thread-Ebene. Wie kann also eine effiziente Kommunikation zwischen den beiden Ebenen stattfinden?
Ein Disruptor [1] ist das nächste Teil dieses Puzzles. Er schafft eine sperrfreie, hochleistungsfähige Warteschlange auf der Grundlage eines Ringpufferdesigns.
Hohe Datenverfügbarkeit
Bisher haben wir eine hohe Leistungsfähigkeit mit einem In-Memory-Modell und dem lokalen RocksDB-Speicher [2] erreicht. Doch hier stellt sich eine neue Herausforderung: Wir müssen eine hohe Datenverfügbarkeit sicherstellen.
Um Datenkonsistenz zwischen den Knoten zu gewährleisten, verwenden wir einen Raft-Konsensalgorithmus [3]. Das bedeutet, dass die Anzahl der Datensicherungen der Anzahl der nicht-führenden Knoten entspricht. Der Algorithmus stellt außerdem sicher, dass das System auch dann noch funktioniert, wenn mindestens die Hälfte der Knoten nicht-kompromittiert ist, um eine hohe Dienstverfügbarkeit zu gewährleisten.
Raft-Domänenrollen:
Leader. Der Leader verarbeitet alle Client-Anfragen und repliziert die Operation an alle Follower.
Follower. Die Follower folgen dem Leader bei allen Operationen. Wenn der Leader ausfällt, wird einer der Follower zum neuen Leader gewählt.
Lerner. Lerner sind nicht-stimmberechtigte Follower, die jeden Idempotenz-/Transaktionsänderungssatz an andere Dienste senden.
Raft-Domänenrollen
CQRS (Command Query Responsibility Segregation)
Weitere wichtige Kriterien, die unsere Lösung erfüllen muss, sind die höhere Schreibleistung des Ledgers und die Fähigkeit, verschiedene Abfragebedingungen zu bewältigen. Zu diesem Zweck müssen wir verschiedene Domänen schaffen. Die Raft-Domäne gewährleistet ein effizienteres Schreiben auf der Grundlage von RocksDB und Raft, und die View-Domäne empfängt die Nachrichten der Raft-Domäne und speichert sie in der relationalen Datenbank für externe Abfragen. Es ist auch möglich, eine Zuständigkeitstrennung bei Befehlsabfragen auf der Architekturebene zu implementieren.
Ledger-Architektur
Gesamtarchitektur
Beziehungen zwischen Raft und Ledger:
Tabelle 6
View-Domänenrollen
Raft-Legder-Center
Empfängt die vom Lerner erzeugte Nachricht und speichert die Transaktions- und Guthabendaten in MySQL zu Abfragezwecken.
Verarbeitung von Anfragen
Eine Transaktionsanfrage geht zunächst durch die Netzwerkebene, die Ledger-Ebene (Request Handler) und die Raft-Ebene (Raft Log Sync). Dann geht sie zurück zur Ledger-Ebene (Zustandsmaschine), zur Netzwerkebene (Response Handler) und gibt schließlich eine Antwort an den Client zurück.
Die Daten werden über die Warteschlange zwischen zwei Ebenen weitergeleitet.
Netzwerkebene – Deserialisierung der RPC-Anfrage und Einreihung in die Anfrage-Warteschlange.
Ledger-Ebene – Abruf der Anfrage aus der Warteschlange und Vorbereitung des Kontexts. Anschließend werden die Anfrage-Metadaten in die Raft-Warteschlange gestellt.
Raft-Ebene – Abruf der Anfrage-Metadaten aus der Raft-Warteschlange und Synchronisierung mit allen Followern. Anschließend wird das Ergebnis in die Anwenden-Warteschlange gestellt.
Ledger-Ebene– Abruf der Daten aus der Anwenden-Warteschlange und Aktualisierung der Zustandsmaschine. Anschließend wird das Ergebnis in die Antwort-Warteschlange gestellt.
Netzwerkebene – Abruf des Ergebnisses aus der Antwort-Warteschlange und Aufbau und Serialisierung der Antwortdaten, bevor diese an den Client gesendet werden.
Verarbeitung von Anfragen
Datenwiederherstellung
Jeder Ledger-Knoten löst einen generischen Snapshot auf Basis eines bestimmten Zeitraums aus. Zusätzlich implementieren wir auch einen konstanten Snapshot. Jeder Knoten wird mit demselben Raft-Protokollindex ausgelöst, um sicherzustellen, dass die Zustandsmaschine identisch ist, wenn jeder Knoten einen Snapshot auslöst. Der Snapshot wird dann zur Überprüfung durch Checker und als Cold-Backup auf S3 hochgeladen.
Beim Neustart des Ledgers wird der lokale Snapshot gelesen und die Zustandsmaschine neu aufgebaut. Dann wird das lokale Raft-Protokoll wiedergegeben und das neueste Protokoll vom Leader synchronisiert, bis es mit dem neuesten Index übereinstimmt. Wenn der lokale Snapshot oder das Raft-Protokoll nicht vorhanden sind, werden sie vom Leader bezogen.
Snapshot und Wiederherstellung
Katastrophen-Toleranz
Um die Verfügbarkeit und Fehlertoleranz zu verbessern, werden die Ledger-Knoten in verschiedenen Umgebungen eingesetzt. Solange mehr als die Hälfte der Knoten ordnungsgemäß funktioniert, gehen keine Daten verloren und ein Failover wird innerhalb von einer Sekunde abgeschlossen.
Selbst wenn das gesamte Cluster ausfallen sollte, was sehr unwahrscheinlich ist, können wir es über den in Amazon S3 gespeicherten konstanten Snapshot wiederherstellen und die letzten verlorenen Daten über das nachgelagerte System abrufen.
Fehlertoleranz
Leistungsfähigkeit
Die folgende Tabelle zeigt die Hardware-Spezifikationen für den Leistungstest
Interne Tests zeigen, dass ein 4-Knoten-Cluster (ein Leader, zwei Follower und ein Lerner) mehr als 10.000 TPS verarbeiten kann. Das Cluster ist so konzipiert, dass es alle Transaktionen nacheinander verarbeitet. Es gibt keine Sperren und Wettlaufsituationen. Daher sind die TPS für ein Hot-Account genauso hoch wie in den normalen Szenarien.
TPS Hot-Account
Die folgende Abbildung zeigt die Latenzzeit der einzelnen Transaktionen. Die meisten Transaktionen konnten innerhalb von zehn Millisekunden abgeschlossen werden, die langsameren innerhalb von 25 Millisekunden.
Latenzzeit in Millisekunden
Branchenführer mit Binance-Ledger
Wir sind unglaublich stolz auf die erreichten Ergebnisse und auf unsere einzigartige Ledger-Lösung. Wie du gesehen hast, ist die branchenübliche Standardlösung aufgrund des Hot-Account-Problems nicht in der Lage, die Bedürfnisse von Binance und seinen Kunden zu erfüllen. Mit einem Ansatz, der speziell für die Infrastruktur von Binance entworfen wurde, haben wir eine der reibungslosesten Börsen- und Produkterfahrungen geschaffen, die es gibt. Wir freuen uns, dass du von unseren Angeboten profitieren kannst, und hoffen, dass du nun besser verstehst, wie ein Dienst wie Binance funktioniert.
Weiterführende Informationen über unsere technologische Infrastruktur findest du in folgenden Artikeln:
(Binance Blog) Einsatz von MLOps zum Aufbau einer End-to-End-Pipeline für maschinelles Lernen in Echtzeit
(Binance Blog) Lerne den CTO kennen: Rohit spricht über Kryptos, Blockchain, Web3 und seinen ersten Monat bei Binance
Referenzen
[1] LMAX-Disruptor
[2] RocksDB