Il prototipo Umbra di Hoskinson punta al ripristino di Midnight mentre la migrazione a BABE avanza nella QA

Charles Hoskinson sta testando Umbra, un archivio dati persistente sperimentale pensato per semplificare il ripristino attraverso l'infrastruttura utilizzata da Cardano e Midnight. Il prototipo è stato descritto in una trascrizione di uno Space su X esaminata da Cardano News ed è collegato al suo lavoro sulla futura architettura di bridge tra Cardano e Midnight. Separatamente, il repository pubblico del nodo di Midnight mostra la migrazione ufficiale del consenso da Aura a BABE in fase di quality assurance.

La sincronizzazione di Midnight passa attraverso Cardano DB Sync

Midnight è una chain partner di Cardano costruita per applicazioni che combinano la verifica pubblica della blockchain con dati protetti. Gli sviluppatori possono usare Midnight per creare applicazioni in cui le prove a conoscenza zero supportano divulgazione selettiva, calcolo privato e flussi di lavoro orientati alla conformità, mentre il livello di token pubblico include $NIGHT.

Hoskinson ha descritto una sequenza di infrastruttura locale che inizia con un nodo completo Cardano, prosegue attraverso cardano-db-sync, quindi richiede un nodo Midnight e infine un indicizzatore Midnight. Tale sequenza è coerente con la documentazione per gli operatori di Midnight.

La guida a cardano-db-sync di Midnight elenca un nodo Cardano in esecuzione come prerequisito e afferma che cardano-db-sync usa PostgreSQL per indicizzare i dati della blockchain in uno schema relazionale. La stessa guida afferma che il database deve essere riprodotto rispetto a Cardano Node 11.0.1 dopo l'aggiornamento van Rossem, invece di essere trattato come una semplice sostituzione binaria.

La documentazione istruisce anche gli operatori ad attendere che cardano-db-sync raggiunga almeno il 99 percento di sincronizzazione prima di procedere. La guida al nodo completo di Midnight richiede poi un'istanza accessibile di cardano-db-sync e la porta di PostgreSQL prima che il nodo Midnight possa essere avviato.

Tale modello operativo spiega perché un livello di ripristino sarebbe importante per sviluppatori e operatori di nodi. Un ambiente Midnight locale non è un semplice riavvio di un singolo binario. Dipende da diversi servizi sincronizzati, con i dati della chain di Cardano, lo stato del database, i dati del nodo Midnight e i dati applicativi indicizzati che devono tutti rimanere allineati.

Il prototipo Umbra si concentra su uno stato recuperabile

Umbra non è elencato come prodotto Midnight rilasciato. È il prototipo di Hoskinson per l'archiviazione e il ripristino dello stato necessario a wallet, indicizzatori, cronologia delle transazioni e componenti di infrastruttura correlati.

Secondo la trascrizione, il prototipo è progettato intorno a stato salvato, checkpoint, gestione di rollback e roll forward, recupero a freddo dopo arresto, connessioni sicure e ricostruzione dei dati di nodo e indicizzatore da registri precedentemente archiviati. Il test pianificato da Hoskinson è sincronizzare l'ambiente, eliminare i dati esistenti del nodo Midnight e dell'indicizzatore, quindi tentare di ricostruire entrambi da Umbra.

Una versione successiva potrebbe aggiungere checkpoint autoverificanti. Hoskinson ha descritto un modello in cui una prova a conoscenza zero confermerebbe che un checkpoint rappresenta uno stato valido, riducendo la quantità di fiducia richiesta nella parte che distribuisce lo snapshot.

Ha anche paragonato il possibile livello di distribuzione a Mithril. La documentazione di Mithril di Cardano descrive un protocollo di multifirma basato sullo stake che produce snapshot di blockchain certificati per supportare una sincronizzazione più rapida dei nodi Cardano e la validazione dello stato. Umbra potrebbe applicare un concetto correlato allo stato di Midnight, sebbene non sia stato pubblicato alcun piano di implementazione pubblico o un calendario di rilascio formale.

Hoskinson ha stimato che una versione iniziale potrebbe richiedere altri due o tre giorni di sviluppo concentrato, condizionata al completamento dei test di sincronizzazione e ripristino. Ha anche affermato che il progetto avrebbe bisogno in seguito di messa a prodotto, lavoro di audit e di un coinvolgimento più ampio degli sviluppatori prima di poter diventare infrastruttura di produzione.

La migrazione da Aura a BABE resta in QA

Midnight sta preparando anche una modifica separata alla sua infrastruttura di consenso. Hoskinson ha descritto Aura come l'attuale meccanismo transitorio di produzione dei blocchi e BABE come il modello a più lungo termine destinato al funzionamento decentralizzato, con GRANDPA che continua a fornire finalità.

Il lavoro è visibile nel repository pubblico del nodo di Midnight. La issue Aura to BABE aperta descrive un nuovo pallet-consensus-engine responsabile di una macchina a stati a doppio motore e del passaggio automatico da Aura a BABE. L'issue è stata aperta il 23 giugno ed è attualmente etichettata "QA in progress".

Il flusso di lavoro include un flag ActiveEngine per Aura o BABE, impostazioni di migrazione controllate dalla governance, slot di transizione memorizzati e un'inversione automatica a un confine di epoca BABE registrato. L'issue afferma anche che il passaggio deve essere rimandato finché GRANDPA non finalizza almeno un blocco iniettato, e che i test unitari devono coprire le transizioni di stato.

Due dipendenze restano elencate nell'issue pubblica: vincolo del confine di epoca e preparazione del comitato dei validatori. La stessa issue non mostra alcuna milestone e nessun branch o pull request collegato nella vista pubblica di GitHub.

Per operatori e team applicativi, il percorso di infrastruttura distribuibile è ancora la sequenza documentata: nodo Cardano, cardano-db-sync, nodo Midnight e indicizzatore. I punti di controllo ingegneristici concreti sono più ristretti della roadmap più ampia: un test di ripristino Umbra riproducibile e il completamento delle dipendenze sul confine di epoca e sul comitato richieste prima che BABE possa sostituire Aura nel nodo Midnight. Per l'infrastruttura di $NIGHT, entrambi i filoni puntano allo stesso obiettivo operativo, un ripristino più rapido di uno stato di chain utilizzabile e un percorso controllato dalla fase transitoria di produzione dei blocchi verso il modello di consenso previsto della rete.