Aggiornamento dell'Ingegneria del Hub & Lancio della Prima Consumer Chain

blog originale: https://medium.com/the-interchain-foundation/hub-engineering-update-first-consumer-chain-launch-ae680a3020bc

È tempo per un aggiornamento dell'ingegneria dal team Cosmos Hub di Informal Systems!

Utilizzando Replicated Security per la prima volta, Neutron è stato ufficialmente lanciato come consumer chain l'11 maggio. Questo aggiornamento copre l'aggiornamento dell'ingegneria per il periodo aprile-maggio '23, che includeva il lancio di Neutron!

La Prima Consumer Chain! - Retrospettiva sul Lancio di Neutron Il lancio di consumer chains è stato effettuato molte volte nelle testnet e, di fatto, viene eseguito centinaia di volte alla settimana nei nostri test automatizzati. Di solito, i dettagli tecnici di un lancio di una consumer chain sono troppo noiosi da scrivere. Tuttavia, la vita reale è inevitabilmente diversa dalla fase di test. Abbiamo avuto alcune complicazioni durante il lancio di Neutron, ma nulla che abbia causato problemi permanenti e le problematiche non dovrebbero ripresentarsi per i futuri lanci. Riassumerò il lancio e le complicazioni qui.

Nota: quando dico "noi" in questo post, non mi riferisco solo al team di Informal. È stato uno sforzo di molti team guidati da Neutron, tra cui noi, l'ICF, Hypha, Strangelove, CryptoCrew e naturalmente l'intero set di validatori.

Problemi con le multisig segnalati e risolti - dal 25 aprile al 4 maggio Circa due settimane prima del lancio, abbiamo iniziato a ricevere segnalazioni secondo cui i validatori avevano problemi nell'usare le multisig e i dispositivi Ledger per firmare le transazioni di assegnazione delle chiavi. Di default, i validatori utilizzano le stesse chiavi sulle consumer chains che utilizzano sull'Hub, ma è considerata una buona pratica di sicurezza utilizzare una chiave diversa per le consumer chains, ed è questo che consentono di fare le transazioni di assegnazione delle chiavi.

Si è scoperto che i dispositivi Ledger e le multisig non erano in grado di firmare le transazioni di assegnazione delle chiavi a causa di complicazioni legate a Amino, un formato dati che è stato in gran parte rimosso da Cosmos, ma è ancora utilizzato nei dispositivi Ledger e nelle multisig. Per risolvere il problema è stato necessario apportare una piccola modifica al formato delle transazioni di assegnazione delle chiavi.

Abbiamo completato questa modifica intorno al 4 maggio, la settimana prima del lancio, e abbiamo inviato una notifica per un aggiornamento d'emergenza da eseguire lunedì 8 maggio, la data originale programmata per il lancio di Neutron. Questo aggiornamento conteneva anche una correzione per un bug che avrebbe potuto potenzialmente fermare l'Hub.

Aggiornamento d'emergenza dell'Hub - 8 maggio Il team di Neutron ha saggiamente deciso di posticipare il loro lancio di qualche giorno, a mercoledì 10, per evitare complicazioni nell'aggiornamento.

L'aggiornamento del lunedì è andato relativamente bene, con un minimo tempo di inattività e nessun incidente grave. Subito dopo l'aggiornamento, i validatori sono stati in grado di utilizzare la transazione di assegnazione delle chiavi dai loro dispositivi multisig e Ledger. Grazie al team di Notional per la consulenza fornita a Neutron nel posticipare il lancio e per aver contribuito a coordinare l'aggiornamento!

Tuttavia, il "tempo di spawn" di Neutron è stato il lunedì, anche se il loro effettivo lancio è stato ritardato. Al momento dello spawn, il client IBC e il file genesis per la consumer chain vengono creati sull'Hub e, da questo momento, non possono essere modificati. Tutti i validatori che non erano stati in grado di utilizzare la transazione di assegnazione delle chiavi prima della correzione erano presenti nel file genesis con le loro chiavi Hub.

Ciò significa che, per eseguire Neutron, avrebbero dovuto mettere le loro chiavi Cosmos Hub sul loro validatore Neutron. Questo non è un problema per il software, ma dal punto di vista della sicurezza operativa, la maggior parte dei validatori preferirebbe evitare di spostare le chiavi su computer diversi.

Lancio di Neutron - dal 10 maggio all'11 maggio Abbiamo eseguito l'aggiornamento d'emergenza dell'Hub così rapidamente perché non volevamo che i validatori che non erano stati in grado di assegnare le chiavi fossero puniti in modo ingiusto per il downtime. Tuttavia, abbiamo presto capito di poter avere un problema più grande. Un numero molto elevato di validatori non era stato in grado di assegnare le chiavi prima del momento dello spawn, e dopo lo spawn, il genesis era bloccato. Le assegnazioni delle chiavi potevano ancora essere effettuate, ma avrebbero avuto effetto solo dopo l'avvio di Neutron.

Per avviare una consumer chain con sicurezza replicata, è necessario almeno il 67% dei validatori dell'Hub. Questo 67% dovrebbe provenire dai validatori che non utilizzavano multisig o Ledger, o dai validatori disposti a eseguire temporaneamente la consumer chain con le loro chiavi Hub. Con molte iniziative il 10, siamo riusciti a mettere insieme abbastanza potenza per avviare la catena, anche se ci sono volute molte ore. Grazie a tutti i validatori che ci hanno aiutato in questa fase.

Abbiamo deciso di aspettare fino al giorno successivo prima di avviare il relayer. Una volta avviato, avrebbe iniziato a recuperare tutti i pacchetti di sicurezza replicata che aggiornano l'insieme di validatori della consumer chain. Questi pacchetti avrebbero aggiornato le chiavi per i validatori che avevano utilizzato la transazione di assegnazione delle chiavi del consumatore dopo il momento dello spawn di lunedì. Questa è una cosa positiva, ma la nostra preoccupazione era che potesse essere possibile che i validatori che ci avevano aiutato utilizzando la chiave Hub anziché la chiave del consumatore potessero essere messi offline una volta che le chiavi fossero state aggiornate. Poiché stavamo operando con una maggioranza risicata, questo avrebbe potuto causare un blocco. Volevamo avere il maggior numero possibile di persone online e riposate per aiutare a gestire questa situazione.

L'11, abbiamo avuto alcune difficoltà a far partire i relayer, ma sono troppo noiose per entrarci nei dettagli qui. Ma una volta che i relayer sono stati avviati, i pacchetti hanno iniziato a passare molto rapidamente e la catena si è sincronizzata. Neutron è ora la prima consumer chain con sicurezza replicata, protetta da Cosmos Hub.

Una nota sull'unbonding Alcuni utenti hanno sciolto le loro ATOM staked durante la finestra di lancio di Neutron (dal 8 maggio all'11 maggio). Questi token saranno completamente sbloccati entro il 1° giugno.

Neutron è diventato ufficialmente una consumer chain l'8 maggio. Questo è noto come il suo "spawn time" (momento di creazione). Tuttavia, non ha iniziato a funzionare fino all'11 maggio. Quando è iniziato, ha ricevuto tutti i pacchetti VSC per gli unbonding che sono avvenuti dopo il momento dello spawn e ha avviato il conto alla rovescia del periodo di unbonding di 20 giorni. 20 giorni dopo l'11 è il 31, quindi entro il 1° giugno sarà completato il periodo di unbonding di tutti i pacchetti VSC ricevuti l'11.

Come funziona l'unbonding con la Replicated Security? Una parte fondamentale del protocollo Replicated Security è la preservazione del periodo di unbonding della consumer chain in tutte le circostanze. Questo avviene in modo semplice:

Quando un utente invia una transazione di unbonding, viene creata una registrazione dell'operazione di unbonding pendente. Questa operazione di unbonding può essere completata quando sono soddisfatte due condizioni: a. Sono trascorsi 21 giorni sul Cosmos Hub. b. Ogni consumer chain segnala che i loro periodi di unbonding sono anche trascorsi. Alla fine del blocco in cui è iniziato l'unbonding, viene inviato a tutte le consumer chain un pacchetto di cambiamento dell'insieme di validatori (VSC packet). Questo contiene il cambiamento di potenza causato dall'unbonding e eventuali altri cambiamenti di potenza da quel blocco. Una volta che la consumer chain riceve il pacchetto di cambio dell'insieme di validatori, inizia il proprio conto alla rovescia del periodo di unbonding. Su Neutron, il periodo di unbonding è di 20 giorni. Dopo che è trascorso questo periodo, la consumer chain invia un pacchetto VSC maturato al Cosmos Hub. Ora tutte le operazioni di unbonding corrispondenti possono essere completate, una volta che è trascorso anche il periodo di unbonding dell'Hub. Questo protocollo garantisce che, in qualsiasi caso, il periodo di unbonding della consumer chain venga rispettato.

Come si può evitare ciò in futuro? Sebbene questo meccanismo garantisca la sicurezza delle consumer chain al massimo grado, i ritardi nell'unbonding possono essere scomodi e dovrebbero probabilmente essere evitati. Va notato che una consumer chain non può ritardare indefinitamente l'unbonding. Se una consumer chain ritarda l'unbonding per più di 5 settimane, verrà rimossa dal Cosmos Hub e tutti gli unbonding verranno rilasciati.

Per evitare il tipo di ritardo minore discusso qui, il modo più semplice è ridurre il periodo di unbonding delle consumer chain. Per illustrare, se i periodi di unbonding delle consumer chain fossero più brevi di una settimana rispetto a quelli dell'Hub Cosmos, una consumer chain dovrebbe essere fermata per una settimana prima che qualsiasi unbonding venga ritardato sull'Hub. Questo teoricamente ridurrebbe leggermente la sicurezza, ma molto probabilmente non in modo significativo.

Stiamo anche studiando il protocollo per vedere se potrebbe essere possibile eliminare del tutto il meccanismo di pausa dell'unbonding. Ciò probabilmente richiederà di fare l'assunzione che gli orologi siano sempre sincronizzati e di rendere la sicurezza delle consumer chain più difficile da quantificare in modo esatto, ma potrebbe valerne la pena.

Altre aggiornamenti di ingegneria Gran parte del lavoro di aprile e maggio è stata focalizzata sulla preparazione e sul lancio della prima consumer chain, Neutron.

Soft opt-out Neutron ha scelto di lanciare con la funzione di "soft opt-out" discussa nell'ultimo aggiornamento, che consente al 5% più piccolo dei validatori su Cosmos Hub di optare per non eseguire la consumer chain. Abbiamo proceduto ad implementarla in tempo per il lancio di Neutron: #833

Codice di migrazione da standalone a consumer completato La migrazione da standalone a consumer consentirà alle chain che attualmente operano come standalone di diventare consumer chain. Stride la utilizzerà durante il suo lancio. Abbiamo lavorato su questo con Stride nei mesi scorsi, ma in aprile l'abbiamo integrato: #757, #794, #832

Revisione audit di Oak Oak Security è stata recentemente finanziata per effettuare un audit di Interchain Security con i fondi della comunità di Cosmos Hub. Abbiamo ricevuto il loro rapporto iniziale, lo abbiamo esaminato e discusso con il team di audit. Hanno individuato alcune problematiche in cui una consumer chain malintenzionata avrebbe potuto potenzialmente bloccare Cosmos Hub, ma questo rientra nel modello di sicurezza attuale di Replicated Security. Stiamo risolvendo queste problematiche e altre per avanzare verso un paradigma di "consumer chain non attendibile", ma questo lavoro è in corso.

Una delle problematiche individuate da Oak Security era quella in cui un aggressore avrebbe potuto bloccare una consumer chain creando milioni di spam di denominazioni (tipi di token). Questa problematica era molto simile a una che avevamo già stava indagando sul lato della catena fornitrice di ICS. Ora possiamo confermare che queste problematiche sono state affrontate e risolte sia su Cosmos Hub che su Neutron.

Testnet di Neutron e correzioni Nel testnet di Neutron, abbiamo riscontrato un bug in cui più messaggi di assegnazione di chiavi potevano causare un blocco sulla consumer (questo è stato riscontrato anche nell'audit di Oak alcune settimane dopo). Abbiamo risolto questa problematica sia sul lato della consumer che su quello del fornitore: #850, #846

Problema dei multisig Alla fine del mese, abbiamo iniziato a ricevere segnalazioni secondo cui l'assegnazione delle chiavi non funzionava per i validatori che utilizzavano multisig e dispositivi Ledger. Abbiamo iniziato a lavorare su una soluzione per questo problema modificando leggermente il formato della transazione di assegnazione delle chiavi.

Preparativi per l'aggiornamento di emergenza Abbiamo iniziato a preparare un aggiornamento di emergenza per Cosmos Hub contenente le correzioni relative alle denominazioni e ai multisig discussi in precedenza. La maggior parte del lavoro su questo aggiornamento è avvenuta a maggio, però. Abbiamo già pubblicato informazioni in merito altrove, ma non le coprirò qui in quanto saranno nell'aggiornamento di maggio. Anticipo: è andato piuttosto bene.