CIP: Coordinated Network Upgrades

I understand what you said. I mean we should think about the purpose of minimizing the downtime and the consequence. Minimizing the downtime isn’t our real target, but keep the community united and protect users benefits is. I know the proposal could help on ensuring that a sufficient amount of nodes are prepared for the upgrade, but for me if we just agree that we will upgrade, but we don’t know when upgrade, it’s equal to nothing agreed.

1 Like

Hello bud, just for my understanding going through this.

We check for 5/6 of the voting power not the number of validators have agreed for upgrade

The crank transaction triggers the check, since we are allowing anyone to submit it. Do we stop placing that after we upgraded or what happens if we place another crank txn after upgrade is all done it will keep rewriting?

Downgrade from V2 to V1 is not possible, but once we have removed the upgrade height flag in V3 then what ever majority validators run will determine what version will be used. if we trigger the crank txn. Is that right?

this is a very detailed explanation, thank you for posting this.

Hey @Brightlystake

Do we stop placing that after we upgraded or what happens if we place another crank txn after upgrade is all done it will keep rewriting?

If the crank message results in an upgrade i.e. from v2 to v3 then the tally will be reset.

Downgrade from V2 to V1 is not possible

Yes downgrading is not possible, if there is some bug or need to downgrade there will be a v3 release that matches v1 that validators will upgrade to

Is that right?

Yup that sounds right to me

1 Like