Hoskinsons Umbra Prototyp zielt auf Midnight Wiederherstellung, während die BABE Migration die Qualitätssicherung durchläuft

Charles Hoskinson testet Umbra, einen experimentellen persistenten Datenspeicher, der die Wiederherstellung über die von Cardano und Midnight genutzte Infrastruktur vereinfachen soll. Der Prototyp wurde in einem technischen X Space Transkript beschrieben, das von Cardano News geprüft wurde, und steht im Zusammenhang mit seiner Arbeit an einer zukünftigen Cardano und Midnight Bridge Architektur. Unabhängig davon zeigt Midnights öffentliches Node Repository die offizielle Aura zu BABE Konsens Migration in der Qualitätssicherung.

Midnight Sync läuft über Cardano DB Sync

Midnight ist eine Cardano Partnerchain, die für Anwendungen gebaut wurde, die öffentliche Blockchain Verifizierung mit geschützten Daten verbinden. Entwickler können Midnight nutzen, um Anwendungen zu erstellen, in denen Zero Knowledge Proofs selektive Offenlegung, private Berechnung und Compliance orientierte Workflows unterstützen, während die öffentliche Token Ebene $NIGHT umfasst.

Hoskinson beschrieb eine lokale Infrastruktursequenz, die mit einem Cardano Full Node beginnt, über cardano-db-sync weiterläuft, dann einen Midnight Node erfordert und schließlich einen Midnight Indexer. Diese Abfolge entspricht der Operator Dokumentation von Midnight.

Die Midnight cardano-db-sync Anleitung führt einen laufenden Cardano Node als Voraussetzung auf und erklärt, dass cardano-db-sync PostgreSQL verwendet, um Blockchain Daten in ein relationales Schema zu indexieren. Dieselbe Anleitung besagt, dass die Datenbank nach dem van Rossem Upgrade gegen Cardano Node 11.0.1 neu eingespielt werden muss, statt als einfacher binärer Austausch behandelt zu werden.

Die Dokumentation weist Operatoren außerdem an, zu warten, bis cardano-db-sync mindestens 99 Prozent Synchronisierung erreicht hat, bevor sie fortfahren. Die Midnight full-node Anleitung verlangt anschließend eine erreichbare cardano-db-sync Instanz und einen PostgreSQL Port, bevor der Midnight Node gestartet werden kann.

Dieses Betriebsmodell erklärt, warum eine Recovery Schicht für Entwickler und Node Operatoren wichtig wäre. Eine lokale Midnight Umgebung ist kein einfacher Neustart eines einzelnen Binaries. Sie hängt von mehreren synchronisierten Diensten ab, wobei Cardano Chain Daten, Datenbankzustand, Midnight Node Daten und indizierte Anwendungsdaten alle abgestimmt bleiben müssen.

Umbra Prototyp fokussiert sich auf wiederherstellbaren Zustand

Umbra ist nicht als veröffentlichtes Midnight Produkt gelistet. Es ist Hoskinsons Prototyp zum Speichern und Wiederherstellen des Zustands, der von Wallets, Indexern, Transaktionshistorie und verwandten Infrastrukturkomponenten benötigt wird.

Dem Transkript zufolge wird der Prototyp um gespeicherten Zustand, Checkpoints, Rollback und Roll Forward Verarbeitung, Cold Recovery nach einem Shutdown, sichere Verbindungen und die Rekonstruktion von Node und Indexer Daten aus zuvor gespeicherten Aufzeichnungen herum entworfen. Hoskinsons geplanter Test besteht darin, die Umgebung zu synchronisieren, die vorhandenen Midnight Node und Indexer Daten zu löschen und anschließend zu versuchen, beide aus Umbra wieder aufzubauen.

Eine spätere Version könnte sich selbst verifizierende Checkpoints hinzufügen. Hoskinson beschrieb ein Modell, in dem ein Zero Knowledge Proof bestätigen würde, dass ein Checkpoint gültigen Zustand repräsentiert, wodurch das erforderliche Maß an Vertrauen in die Partei, die den Snapshot verteilt, verringert würde.

Er verglich die mögliche Distributionsschicht außerdem mit Mithril. Cardanos Mithril Dokumentation beschreibt ein stakebasiertes Multisignatur Protokoll, das zertifizierte Blockchain Snapshots erzeugt, um schnellere Cardano Node Synchronisierung und Zustandsvalidierung zu unterstützen. Umbra könnte ein verwandtes Konzept auf den Midnight Zustand anwenden, obwohl kein öffentlicher Implementierungsplan oder formaler Veröffentlichungsplan veröffentlicht wurde.

Hoskinson schätzte, dass eine erste Version weitere zwei oder drei Tage konzentrierter Entwicklung erfordern könnte, abhängig vom Abschluss der Synchronisations und Recovery Tests. Er sagte außerdem, dass das Projekt später Produktisierung, Audit Arbeiten und breitere Entwicklerbeteiligung benötigen würde, bevor es zu Produktionsinfrastruktur werden könne.

Aura zu BABE Migration bleibt in QA

Midnight bereitet außerdem eine separate Änderung an seiner Konsens Infrastruktur vor. Hoskinson beschrieb Aura als den aktuellen Übergangsmechanismus für die Blockproduktion und BABE als das längerfristige Modell für den dezentralen Betrieb, wobei GRANDPA weiterhin Finalität bereitstellt.

Die Arbeit ist in Midnights öffentlichem Node Repository sichtbar. Das offene Aura zu BABE Issue beschreibt ein neues pallet-consensus-engine, das für eine Dual Engine Zustandsmaschine und den automatischen Wechsel von Aura zu BABE verantwortlich ist. Das Issue wurde am 23. Juni eröffnet und ist derzeit mit “QA in progress.” gekennzeichnet.

Der Arbeitsstrang umfasst ein ActiveEngine Flag für Aura oder BABE, Governance gesteuerte Migrationseinstellungen, gespeicherte Übergangsslots und einen automatischen Wechsel an einer protokollierten BABE Epochen Grenze. Das Issue führt außerdem aus, dass der Wechsel warten muss, bis GRANDPA mindestens einen injizierten Block finalisiert, und dass Unit Tests die Zustandsübergänge abdecken müssen.

Zwei Abhängigkeiten sind im öffentlichen Issue weiterhin aufgeführt: Bindung an die Epochen Grenze und Staging des Validator Committees. Dasselbe Issue zeigt keinen Meilenstein und keine verlinkten Branches oder Pull Requests in der öffentlichen GitHub Ansicht.

Für Operatoren und Anwendungsteams ist der einsetzbare Infrastrukturpfad weiterhin die dokumentierte Abfolge: Cardano Node, cardano-db-sync, Midnight Node und Indexer. Die konkreten Engineering Checkpoints sind enger gefasst als die umfassendere Roadmap: ein reproduzierbarer Umbra Recovery Test und der Abschluss der Abhängigkeiten an Epochen Grenze und Committee, die erforderlich sind, bevor BABE Aura im Midnight Node ersetzen kann. Für $NIGHT Infrastruktur zeigen beide Stränge auf dasselbe operative Ziel, schnellere Wiederherstellung eines nutzbaren Chain Zustands und ein kontrollierter Pfad von der Übergangs Blockproduktion hin zum beabsichtigten Konsensmodell des Netzwerks.