EPIC: Social Upgrades #1014
Comments
|
related to #1009 in that we also want to remove most text based governance proposals and upgrade proposals |
|
After implementing auto switching upgrades, there's an interesting addition proposed by @cmwaters where we can add a signalling component. Each node would gossip when each node is ready to upgrade. Nodes can then vote to upgrade after they have received 2/3s. This would also need to be communicated with light clients, which would also need to upgrade at that time. |
|
It seems like it would be trivial to Sybil attack such a signaling mechanism, and in fact I struggle to imagine a future where such a mechanism isn't Sybil attacked eventually. |
apologies @MicahZoltu, I wasn't clear enough, by 2/3's I mean 2/3's of the voting power of validators, not just full nodes. Would this still be subject to a sybil attack? It seems like it would be easy to check if a message was sent from from a validator and remove a peer if they're not, but I definitely could be missing something. |
|
Ah, if it is 2/3 of validators (not nodes) then it isn't susceptible to Sybil. This is still susceptible to governance attacks though. In a well designed PoS network validators are tightly constrained on the damage they can do, usually limited to censorship and double spending within finality window. It is important to be careful not to give validators additional powers like the ability to push out a rule change onto users (which effectively is ultimately unconstrained power). Thinking more on this, I am somewhat against the signalling mechanism you have proposed. Imagine if an honest minority wants to execute a fork away from a dishonest majority. By having them wait for the signal from the validators they would be functionally blocked from forking away by the dishonest majority. If a user has decided that they want to apply a rule chain, they should be allowed to do so freely regardless of what other network participants think/want. |
No one's blocking anyone from forking. A minority simply takes the block chain, makes some updates to the validator set and starts their own alternative binary. A signalling mechanism is merely a coordination tool; you can't force node operators to upgrade or to not. Computers are just faster and more reliable at coordinating than if we were to try organize something on discord for example. |
|
Perhaps I'm missing something, but manual updates to validator set feels fraught with peril. For starters, the honest minority would need to know in advance which validators are honest and which are dishonest. This information may not be known until you attempt to fork and find that some validators didn't upgrade. Even then, you cannot differentiate between validators that intentionally didn't upgrade their clients (because they oppose the fork) and those who just weren't paying attention. It feels disingenuous to fully slash those who were just not paying attention. On top of that, I believe the validator set changes over time, so you would need to author a list of validators to remove, and then release quickly enough after that list was published before a substantial number of those validators can rotate out. All in all, it feels like this sort of fork should be reserved only for the worst case scenarios like active censorship of the blockchain, and shouldn't be the way to handle contentious upgrades where the community is split on how to proceed. |
How are you typically expected to sync from genesis with this method? Do you have to run older, unsupported binaries? This seems unsustainable if older binaries have to be supported in perpetuity. What upgrade method do we plan to test in the incentivized testnet? |
How else do you fork with only an honest minority and a dishonest majority without changing the validator set in some way. Anyway, I think I may have confused you here. I wasn't really talking about forks, I just brought it up to say that this is an orthogonal process. It's purely to automate coordination. Instead of saying everyone needs to update at height 100. Everyone updates in their own time and then communicates to other nodes that they're ready to upgrade. When 2/3+ of the validator set have communicated their intention to upgrade, the next block proposer proposes a block with the new app version. If it gets accepted everyone then switches to the new version (this means of course that a binary will include two state machines: the old and the new). |
Yes, for example osmosis is up to v13 which means you'd start at v1 till you reached the upgrade height, swap in v2 and keep doing that until you reached the head of the chain. Old binaries don't have to be supported in perpetuity in terms of software maintenance, they just need to exist. |
IMO we should force an upgrade at a certain height regardless of who's ready to upgrade or not, and automatically un-delegate the validators that didn't signal. Validators should not have the power to delay or block upgrades that the community wants. See the thread in #1009 (comment) for reasoning. |
I think that's a very bad pattern. Old binaries do need to at least be supported with security upgrades and to ensure they remain compatible with the p2p network otherwise we'd need to maintain 13 different p2p networks. It sounds like a long-term nightmare. |
People run clients with a new ruleset that is incompatible with the old ruleset and the system forks. Validators that run the old ruleset will leak out of the new ruleset chain and validators that run the new ruleset will leak out of the old ruleset chain.
The problem I see is that 2/3 may never come, in which case the group who wants to run the new ruleset is "blocked" from doing so by the 1/3+ group that doesn't want the new rules. I think this could be resolved with a deadline where the fork happens at |
Yeah ideally you could use the latest version to process all txs since genesis. This might not be too difficult for Celestia if we think it will ossify rather quickly. But if the SDK supports one form of upgrading strategy it may be difficult to do another as we essentially need all txs to be versioned and a state machine capable of processing each version.
Hmm somewhat. If the network has moved on to a new version, say v2, then the only nodes running v1 are catching up. There is a far less threat surface to nodes catching up because they simply don't have the latest state so no-one is interested in them. Far more critical is the latest version which may have vulnerabilities that could take users funds for example. |
I think that's how Bitcoin (soft forks) and Ethereum work, afaik. If statements for block heights to enable new features etc. |
## Overview wraps the sdk's standard upgrade module to remove the ability to submit upgrade proposals. The idea being that this maintains compatibility with the IBC module (which requires access to the upgrade module's keeper), while still removing the ability for the upgrade module to work by not registering the upgrade module's msg server or begin block. Also, when we implement #1014 we can progressively flesh this module out with our own logic. closes #1571 ## Checklist - [x] New and updated code has appropriate documentation - [x] New and updated code has new and/or updated testing - [x] Required CI checks are passing - [x] Visual proof for any user facing features like CLI or documentation updates - [x] Linked issues closed with keywords --------- Co-authored-by: Rootul P <[email protected]>
## Overview This PR adds a very minimal version module, which will update the app version in the header using end block based on a config. The configs are just hardcoded maps atm, but its possible for a user to pass their own via app options. This PR also isn't meant to be a final solution for #1014 or #1568, but more of an exploratory demo of one way they could done. the majority of #1594 ## Checklist - [x] New and updated code has appropriate documentation - [x] New and updated code has new and/or updated testing - [x] Required CI checks are passing - [x] Visual proof for any user facing features like CLI or documentation updates - [x] Linked issues closed with keywords --------- Co-authored-by: Rootul P <[email protected]> Co-authored-by: rene <[email protected]>
|
closing as celestia-app is currently reliant upon a socially coordinated upgrade. Note that this is different from any flavor of signalling |
|
Where can one read more about this "socially coordinated upgrade" process? |
We've discussed the desire for validators and consensus fullnodes to be able to update binaries before the actual upgrade height. This differs from the standard cosmos-sdk upgrade module, which typically relies on switching binaries at the upgrade height.
Tracking
The text was updated successfully, but these errors were encountered: