In dieser Zeit wurde eine vollständige Speicherungstestreihe für eine Datenschutz-Abgleich-DApp im Midnight-Ökosystem durchgeführt, wobei hauptsächlich die Stabilität des lokalen Leveldb-Privatstatus, die Expansionsgeschwindigkeit und die Zuverlässigkeit der Backup-Wiederherstellung im Fokus standen. Es lief 20 Tage lang, und das Verzeichnis des privaten Status stieg von 1,2 GB direkt auf 4,8 GB. Gleichzeitig wurde festgestellt, dass die offizielle Backup-Mechanik noch viele Verbesserungsmöglichkeiten bietet, was tatsächlich Auswirkungen auf die Datensicherheit und Compliance in institutionellen Szenarien hat. Dieser Artikel fasst die grundlegenden Probleme, den Einflussbereich und umsetzbare Betriebsempfehlungen auf der Grundlage der Testergebnisse zusammen, um den Midnight-Entwicklern und Betriebsteams als Referenz zu dienen.
Die getestete DApp richtet sich hauptsächlich an kleine und mittlere Institutionen für On-Chain-Privatabgleiche. Die täglichen aktiven Nutzer sind nicht die Top-Player, aber die Handelsfrequenz ist nicht niedrig. Sie wurde auf Basis des Kachina-Protokolls entwickelt, das auf Midnight basiert, wobei alle privaten Zustände in der lokalen Leveldb gespeichert sind. Diese praktische Messung zielt darauf ab, zu prüfen, ob dieses Speichersystem in der realen Geschäftswelt standhält, um potenzielle Betriebskosten im Voraus zu identifizieren und als Grundlage für zukünftige Optimierungen zu dienen.
Die Daten sind sehr anschaulich: Nach 20 Tagen ist der private Zustandsordner von 1,2 GB auf 4,8 GB gewachsen, die Wachstumsrate ist recht schnell. Die Gründe sind hauptsächlich zwei Punkte:
Erstens hat das Kachina-Protokoll derzeit keine automatische Bereinigung des Vertrags-Witness-Caches, der historischen Nachweis-Daten und der Rollback-Protokolle implementiert, wodurch temporäre Dateien sich weiter ansammeln.
Zweitens ist das Schreiben von Leveldb selbst offensichtlich amplifiziert, Aktualisierungen erfolgen durch Anhängen, alte Daten müssen auf die Kompaktion warten, um wirklich bereinigt zu werden, was die Speicherauslastung weiter erhöht.
Außerdem hat Midnight zur Gewährleistung der Privatsphäre jede Value in Leveldb serialisiert und verschlüsselt, was die Sicherheit erhöht, aber auch den Speicherplatz vergrößert. Die Tests haben ergeben, dass der Speicherbedarf nach der Verschlüsselung mehr als dreimal so hoch ist wie bei den ursprünglichen Daten. Die täglich erzeugten ursprünglichen Zustände der Institutionen betragen etwa 50 MB, was nach der Verarbeitung durch Leveldb auf 200 MB anwächst und nach der Verschlüsselung direkt auf 300 MB steigt. Langfristig müssen die Kapazitätsplanungen im Voraus genau berechnet werden.
Die Sicherungswiederherstellung war ein Schwerpunkt der Tests.
In der Midnight v1.3.0-Dokumentation steht klar, dass private Zustände lokal existieren und Datenlecks vermeiden. Aber die praktischen Tests haben gezeigt, dass das offizielle Backup-Skript noch erhebliches Optimierungspotenzial hat: Das Skript sichert nur die verschlüsselten Zustandsdateien und hat den Schlüsselindex, der zur Entschlüsselung benötigt wird, nicht gesichert, was zu einer Fehlermeldung „Zustandsintegrität kann nicht überprüft werden“ führt, sodass eine Wiederherstellung unmöglich ist.
Bei der Fernsicherung habe ich auch AWS S3 ausprobiert und festgestellt, dass es sich um ein typisches Sicherheitsbalancierungsthema handelt: Wenn der Schlüssel lokal bleibt, kann die verschlüsselte Datei in der Cloud nicht geöffnet werden, was die Sicherung nutzlos macht. Wenn der Schlüssel in die Cloud übertragen wird, widerspricht das dem Sicherheitsdesign „private Zustände dürfen nicht aus der lokalen Umgebung herausgegeben werden“. Entwickler müssen selbst einen Ausgleich zwischen Sicherheit und Verwendbarkeit der Sicherung finden.
Hier sollte klargestellt werden, dass die Probleme, die bei dieser Messung festgestellt wurden, in zwei Kategorien unterteilt werden sollten.
Eine Kategorie sind Optimierungspunkte auf der Implementierungsebene, wie das Fehlen von Schlüsselindizes im Backup-Skript und fehlende automatische Bereinigung, die in zukünftigen Versionen behoben werden können.
Eine andere Kategorie sind die Kompromisse auf der Design-Ebene, wie das Verwenden von lokalem Leveldb für die Privatsphäre, was zusätzliche Kosten für die Verschlüsselung mit sich bringt, was eine normale Abwägung zwischen Privatsphäre und Leistung darstellt. Die Datenschutzlogik des Kachina-Protokolls ist an sich solide, allerdings gibt es noch Verbesserungsbedarf bezüglich der Umsetzung und Benutzerfreundlichkeit im Betrieb.
Im horizontalen Vergleich zu anderen Datenschutz-Blockchains sind die Unterschiede ebenfalls sichtbar:
Leo verwendet ein Aufzeichnungsmodell, das das Schneiden historischer Aufzeichnungen unterstützt, sodass nur die wesentlichen Daten beibehalten werden können.
Filecoin FVM integriert IPFS nativ und kann große Zustände in verteiltem Speicher ablegen, um den lokalen Druck zu verringern.
Im Moment hat Midnight noch keine Datenpartitionierung, keine Datenarchivierung und keine Trennung von kalten und warmen Daten, alle Daten sind vermischt, und je länger, desto größer der Druck im Betrieb.
Die Zustandsynchronisierung hat auch viele Probleme gezeigt.
Die Effizienz beim Synchronisieren von Merkle-Nachweisen auf neuen Geräten ist durchschnittlich. Bei der parallelen Logik von Kachina wird die Synchronisierung mehrerer Verträge leicht zu Lock-Konkurrenzproblemen führen. Die Messung hat gezeigt, dass die Synchronisierung von 80 Vertragszuständen 42 Minuten gedauert hat, bei einer CPU-Auslastung von weniger als 10 %. Der Flaschenhals liegt hauptsächlich im IO-Warten. Zudem unterstützt die Synchronisierung keine Wiederaufnahme bei Unterbrechungen; wenn die Verbindung abbricht, muss von neuem begonnen werden. Die SST-Dateien von Leveldb sind im Binärformat und könnten auch von Prozesssperren belegt werden, was inkrementelle Synchronisierungen mit rsync sehr anfällig für Inkonsistenzen macht. Das sind alles Punkte, die durch Betriebstrategien vermieden werden müssen.
Bei einer mittelgroßen DApp (täglich 800+ aktive Nutzer, durchschnittlich 12 Abgleiche pro Person) kann man grob schätzen, dass der Speicherverbrauch in einem Jahr etwa 450 GB betragen kann, was mehr Festplattenspeicher erfordert als herkömmliche Datenbanken. Egal ob lokal oder in der Cloud, die Kosten sind nicht gering. Und wenn die Datenmenge zunimmt, kann die Kompaktion von Leveldb Schreibpausen verursachen. Während der Spitzenzeiten steigt die Verzögerung beim Schreiben von Zuständen von 12 ms auf 2,3 s, was die Geschäftsgeschwindigkeit deutlich beeinträchtigt.
Zusammenfassung der Kernprobleme (Problem - Phänomen - Einfluss - Vorschlag)
1. Leveldb speichert schnell.
In 20 Tagen von 1,2 GB auf 4,8 GB gewachsen, nach der Verschlüsselung mehr als dreimal so groß.
→ Die Speicherkosten steigen, was den Druck auf die Knoten erhöht.
→ Vorschlag: Regelmäßige Kompaktion konfigurieren, den Witness-Cache und die historischen Nachweis-Abfalldateien manuell bereinigen.
2. Das offizielle Backup-Skript ist unvollständig.
Nur verschlüsselte Zustände sichern, keine Schlüsselindizes sichern, Wiederherstellung schlägt fehl.
→ Festplattenschäden können wichtige Abgleichdaten verlieren und die Compliance beeinträchtigen.
→ Vorschlag: Benutzerdefinierte Skripte zur Synchronisierung von Backup-Zustandsdateien und Schlüsselindizes erstellen, Schlüssel offline sicher aufbewahren.
3. Die Effizienz der Zustandsynchronisierung ist zu niedrig.
80 Verträge synchronisiert in 42 Minuten, ohne Wiederaufnahme, deutliche Lock-Konkurrenz.
→ Die Anbindung neuer Knoten ist langsam, die Betriebseffizienz niedrig.
→ Vorschlag: Die Synchronisierungsreihenfolge anpassen, um Lock-Konflikte zu vermeiden, manuell SST-Dateien in Chargen aufteilen und synchronisieren.
4. Kalte und warme Daten sind nicht getrennt.
Historische und aktive Daten werden gemischt gespeichert, was durch die Kompaktion zu Schreibpausen führt.
→ Die Verzögerungen steigen während der Spitzenzeiten, was zu einem schlechteren Erlebnis führt.
→ Vorschlag: Historische Daten manuell in externen Speicher archivieren und offizielle Lösungen zur Trennung von kalten und warmen Daten verfolgen.
Insgesamt betrachtet ist dieses lokale Speichersystem von Midnight besser für persönliche Benutzer und leichte Szenarien geeignet. Um wirklich unternehmensgerechte Anwendungen zu unterstützen, muss die Speicherschicht weiter verbessert werden. Die Datenschutzfähigkeiten von Kachina sind das Kern-Highlight, aber es fehlen Funktionen wie automatische Archivierung, inkrementelle Sicherung und Trennung von kalten und warmen Daten, die für Unternehmen unbedingt erforderlich sind, was die Stabilität und Compliance erschwert.
Praktische Optimierungen im Betrieb (Priorität von hoch nach niedrig).
1. Dringender Verluststopp.
Benutzerdefinierte Backup-Skripte implementieren, die Zustandsdateien und Schlüsselindizes gemeinsam sichern, als doppelte Sicherheit lokal und offline.
2. Kostenkontrolle.
Jeden Morgen in der niedrigsten Spitzenzeit automatisch die Kompaktion von Leveldb auslösen und regelmäßig ungültige Caches bereinigen, um die Wachstumsrate zu kontrollieren.
3. Erlebnisoptimierung.
Die Synchronisierungsstrategie der Verträge anpassen, um Lock-Konkurrenz zu vermeiden und die Synchronisierungsgeschwindigkeit zu erhöhen.
4. Langfristige Architektur.
Die offiziellen Versionen verfolgen und die Integration von verteiltem Speicher und Datenpartitionierung im Auge behalten, um schrittweise an Unternehmensszenarien anzupassen.
Diese praktische Messung hat im Wesentlichen die Leistung der Leveldb-basierten Midnight-Ökosystem-DApps vollständig erfasst und die vier Kernprobleme identifiziert: Speicherausdehnung, Backup-Defizite, ineffiziente Synchronisierung und das Fehlen einer Trennung von kalten und warmen Daten. Auch die Vorteile des Kachina-Datenschutzdesigns und die Schwächen der Implementierung wurden validiert. Die in diesem Artikel gegebenen Vorschläge basieren auf praktischen Messdaten, die direkt eingesetzt werden können, um Entwicklern und dem Betrieb zu helfen, Speicherprobleme zu vermeiden und Kosten zu kontrollieren. Zukünftig sollte die Speicherung in Übereinstimmung mit den offiziellen Versionen weiter optimiert werden, damit Midnight besser in der Lage ist, Anwendungen unterschiedlicher Größenordnungen zu unterstützen und das Ökosystem stabiler zu machen.
#night @MidnightNetwork $NIGHT
