docs: ADR 016 Removing Token Voting for Upgrades

[evan-forbes]

Overview

rendered

TLDR; just remove the upgrade module and do this

// ValidateBasic performs stateless validation on a Header returning an error
// if any validation fails.
//
// NOTE: Timestamp validation is subtle and handled elsewhere.
func (h Header) ValidateBasic() error {
    if h.Height >= consts.BombHeight {
        return errors.New("bomb height reached or exceeded")
    }
    ...
    return nil
}

closes #1477

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[rootulp]

Overall LGTM

[github-actions]

PR Preview Action v1.3.0
🚀 Deployed preview to https://celestiaorg.github.io/celestia-app/pr-preview/pr-1491/
on branch gh-pages at 2023-03-22 11:25 UTC

[liamsi]

Just need to capture that between the options a decision was made. Otherwise LGTM

[cmwaters]

Token voting doesn't actually bypass social consensus. It is still only a coordinating mechanism that forces nodes to halt at an agreed upon height (kind of like a difficulty bomb). There is no enforcement of what the next binary could be.

[evan-forbes]

You are correct that people can always use which ever binary they choose, which is what the first part of the sentence was attempting to address.

Standard cosmos-sdk based chains are sovereign and have the ability to hardfork,

but the upgrade module does put a loose blocker to this by stopping binaries that don't match the version and the point of the onchain mechanism is to use token voting to decide. Meaning that the social contract is to do whatever token voting determines, which is not the social contract that celestia wants to adhere to.

[evan-forbes]

I understand avoiding the term bypass and will try to find a different word

[evan-forbes]

updated, and I tried to focus on difference in social contract more

[cmwaters]

Might be helpful to expand on what the upgrade mechanism would be. Given that we've decided to use a single binary sync which basically enables rolling upgrades, operators can update their binaries ahead of time and a height is embedded in the binary which indicates when to switch to the next state machine.

[MSevey]

Are there pending open questions/decisions that need to happen offline to move forward with this? Leaving my approval so we can merge if not.

[evan-forbes]

I have some offline updates that I still want to push, just been busy or ooo, apologies for any delay

[evan-forbes]

before merging, we should also understand how ibc uses the upgrade module. we might only want to remove the ability for the gov module to use the upgrade module, and then incorporate the existing upgrade management into social upgrades #1014

[cmwaters]

So the idea now is that the upgrade module still remains but we remove the proposal handler and the messages (do we even need to remove the messages if only governance can call this?).

I still think it's important that we clarify how, after these changes, a chain would expect to upgrade else this ADR feels incomplete.

[evan-forbes]

I still think it's important that we clarify how, after these changes, a chain would expect to upgrade else this ADR feels incomplete.

That's fair, we can postpone merging this one until ADR018 is finished, as I think that topic requires an entire separate ADR. Or perhaps we could just move the relevant portions of this ADR into that one and only merge that ADR.

[cmwaters]

That's fair, we can postpone merging this one until ADR018 is finished, as I think that topic requires an entire separate ADR. Or perhaps we could just move the relevant portions of this ADR into that one and only merge that ADR.

My personal view is that these shouldn't be considered two separate decisions but one

[evan-forbes]

that makes a lot of sense!

iirc per sync discussion this ADR was initially separate because we just wanted to explore what a difficulty bomb and removing the upgrade module would look like before we discussed it during the onsite, but wanted to wait on upgrades.

I'll close this ADR for now, and we can update ADR018 to ADR016