Aggiornamento software su Fuxi-8000 Testnet

Nota del redattore: Fuxi-8000 è stato aggiornato senza problemi a v0.10.2 a 50000 di altezza.

Mette in risalto:

Programma di aggiornamento di Fuxi-8000 Testnet:

  • Fase uno (16 gennaio ~ 18 gennaio) : avviamo la rete con iris v0.10.0 in modo decentralizzato. Dopodiché, prevediamo che la rete funzionerà per due giorni.
  • Fase due (18 gennaio ~ 21 gennaio) : dopo che Fuxi-8000 si è stabilizzato, il team di sviluppo ha presentato una proposta di aggiornamento del software Smooth runtime alla v0.10.2 . Più del 70% del potere di voto è passato a v0.10.2 prima di # 50000, ora sono attivate nuove funzioni in v0.10.2.
  • Fase tre (21 gennaio ~ 25 gennaio) : il team verificherà il flusso di lavoro di aggiornamento del software per ripristinare l’errore di consenso: aggiornamento della patch . Il team attiverà un errore di consenso deliberatamente inserito in v0.10.2. Questo errore causerà l’arresto della rete ed è necessario passare alla v0.10.2-patch per v0.10.2-patch rete.
  • Quarta fase (25 gennaio ~ 29 gennaio) : In questa fase proveremo a esportare uno snapshop di blockchain e usarlo come file di genesi per una nuova catena. Questo è un altro tipo di aggiornamento software: Riavvia aggiornamento . In questa fase, presenteremo prima una proposta di system-halt . Se questa proposta viene approvata, Tendermint si fermerà a una certa altezza. Quindi, è possibile esportare l’istantanea o scaricare il nuovo file di genesi fornito dal team IRIS e riavviare con la nuova versione v0.11.0 .
  • Test di carico (29 gennaio ~ 3 febbraio) : prevediamo di implementare un bot di transazione che spinga i tps di sistema a un certo livello. Prevediamo che il TPS aumenterà da 100 a 500 nei giorni seguenti.

Evoluzione dell’aggiornamento

Il primo esperimento di aggiornamento runtime di Fuxi-4000 è stato molto stimolante, ma l’aggiornamento del software in Fuxi-7000 ha bloccato la catena. Il team di sviluppo ha pensato molte volte alla creazione di un flusso di lavoro di aggiornamento più robusto in seguito. IRIShub v0.10.0 contiene molte modifiche sostanziali. Oltre alle modifiche all’architettura di cui abbiamo già parlato, la caratteristica più interessante è ridefinire il flusso di lavoro di aggiornamento del software.

Tipi di aggiornamento software

Volontario : in caso di rilascio non interrotto del percorso del software IRIShub, il validatore potrebbe eseguire l’aggiornamento alla versione più recente e riavviare i nodi. IRIShub v0.10.1 è buono per l’aggiornamento volontario.

Smooth : aggiornamento del software di runtime in cui Tendermint raccoglierà i segnali di versione dalle intestazioni di blocco e dirà se viene superata la soglia predefinita. Quando viene raggiunto l’obiettivo, verrà attivata la nuova logica.

Patch : quando si verifica un errore di consenso, come i conflitti di apphash, è possibile distribuire una patch con l’aggiornamento di classe III. Tendermint riprodurrà l’ultimo blocco per ripristinare lo stato dell’applicazione.

Riavvio : quando le modifiche dell’iride non sono più compatibili con le versioni precedenti, è necessario questo tipo di aggiornamento. Esportiamo uno snapshop di blockchain e lo usiamo come file di genesi per una nuova catena.

Aggiornamento software in fase II

  • In primo luogo, un indirizzo di profiler tenuto dal team di sviluppo invierà una proposta di aggiornamento software sull’aggiornamento da v0.10.0 a v0.10.2 al 18 gennaio 2019.
  • Per far passare questa proposta, dobbiamo raggiungere una partecipazione superiore all’85,72% e oltre l’83,4% di loro vota sì. Quindi si prevede che i validatori inizino a installare IRISHub v0.10.2 e si riavviino con questa nuova versione.
  $ iris version 
v0.10.2
$ iriscli version
v0.10.2
  • Lo stato del tuo nodo sarà diverso:
  { "Node_info": { "protocol_version": { "p2p": "5", "blocco": "8", "app": "1"}, "id": "57019a13c2469260eb9033d7b714cc6e664643bb", "listen_addr": "tcp : //0.0.0.0: 26656" , "rete": "-8000 Fuxi", "versione": "0.27.3", "canali": "4020212223303800", "moniker": "test", "altro": { "tx_index": "on", "rpc_address": "tcp: //0.0.0.0: 26657"}}, "sync_info": { "latest_block_hash": "859AD1BD65608AB3E13E1BDF68F03B6D08E2656441CD069FBA171AAAF9DC178D", "latest_app_hash": "99024C01117EBA268DAF3BA4638EA2FD34571A6E4F3A24ADD5A4BE903DF8F548", "latest_block_height ":" 32063" , "latest_block_time": "2019-01-19T06: 28: 04.668226481Z", "catching_up": false}, "validator_info": { "indirizzo": "", "pub_key": { "type" : "tendermint / PubKeyEd25519", "valore": ""}, "voting_power": "100"}} 

Come puoi vedere, il campo app è bloccato da 0 a 1.

  • I validatori avranno tre giorni, fino al blocco 5000, per fare ciò come indicato come switch-height nella proposta, mentre Tendermint raccoglierà successivamente i segnali di versione dalle intestazioni del blocco.
  • Alla fine del periodo di aggiornamento, aka. switch-height , se Tendermint afferma che oltre il 70% del potere di voto utilizza v0.10.2 , questa proposta di aggiornamento verrà passata e verranno attivate nuove funzioni dalla v0.10.2 .
  • Verificare che questo processo di aggiornamento del runtime abbia esito positivo eseguendo il comando seguente per eseguire query sulle informazioni di aggiornamento:
  Informazioni sull'aggiornamento di iriscli 

L’output di esempio dovrebbe essere simile a:

  Informazioni sull'aggiornamento di iriscli --node = localhost: 26657 
{
"Versione corrente": {
"UpgradeInfo": {
"ID proposta": "0",
"Protocollo": {
"versione": "0",
"software": "https://github.com/irisnet/irishub/releases/tag/v0.10.0",
"altezza": "1"
}
},
"Successo": vero
},
"last_failed_version": "0",
"upgrade_in_progress": {
"ID proposta": "1",
"Protocollo": {
"versione": "1",
"software": "https://github.com/irisnet/irishub/releases/tag/v0.10.2",
"altezza": "50000"
}
}
}

Dovresti vedere che in upgrade_config, la version è 1 e ProposalID è quella della proposta di aggiornamento.

  • Per interrogare quanti validatori sono passati alla nuova versione, eseguire questo comando:
  aggiorna i segnali di query di aggiornamento 
[
"Fca13yrfhk4z5kzs9kqunamtfxrtpver5zvese2udl",
"Fca1wqpkyd68ludlruqtdryzs0ss5dya47m25vawzh"
]
  • Se hai dimenticato di eseguire l’aggiornamento a una nuova versione, ma altri nodi si sono aggiornati correttamente alla nuova versione, il tuo nodo mostrerà i messaggi di errore di panico nei registri di output. Non preoccuparti, puoi comunque scaricare IRIShub v0.10.2 e ricominciare. Quindi, non vedrai più i messaggi di panico
  iris start --home =  

Nuova funzione in v0.10.2

  • Il proponente deve depositare il 30% del deposito minimo al momento della presentazione della proposta

Aggiornamento software in fase III

  • Testeremo il flusso di lavoro di aggiornamento del software per ripristinarlo da un errore di consenso. In v0.10.2, c’è un uovo di pasqua🥚: il team attiverà deliberatamente un errore di consenso. Questo 🐞 farà arrestare la rete
  • Questo bug impedirà al sistema di creare nuovi blocchi, mentre la versione con patch di iris risolverà il problema e ricaricherà gli stati dell’applicazione. Come validatore, devi tornare alla v0.10.1-patch per tornare in diretta
  iris start --home --replay-last-block 
  • Se più di 2/3 della potenza di voto è passata alla versione con patch, la rete riprenderà a creare blocchi.

Aggiornamento software in fase IV

  • In primo luogo, un indirizzo di profiler tenuto dal team di sviluppo presenterà una proposta System-Halt per fermare la catena a circa # 160.000 di altezza
  • Per far passare questa proposta, dobbiamo raggiungere una partecipazione superiore all’85,72% e oltre l’83,4% di loro vota sì. Quindi si prevede che la catena si fermerà dopo 20.000 blocchi.
  • Dopo che la catena è stata interrotta, il team di sviluppo esporta uno snapshop di blockchain e lo utilizza come file di genesi per riavviare la catena, ancora chiamata Fuxi-8000 . Questo è un altro tipo di aggiornamento software: Riavvia aggiornamento . Tutti i validatori dovrebbero scaricare. la nuova genesi e inizia con la nuova versione v0.11.0 . Se i validatori +2/3 diventano online, la nuova catena inizierà a creare blocchi.