Chain Upgrades

Been thinking a lot about hard forks and chain upgrades recently. Talked about this at some length with Jae Kwon yesterday too.

After digesting that conversation I think I found a conclusion or guideline, and it affects the coupling of interfaces too.

So, if you have a chain with a highly engaged community, and the community includes devs, and they want/expect evolution, then you would want to go with a design that features clearly defined transaction types, like post or vote.

And you'd want to be able to upgrade that chain faster than you would (any) existing chain.

https://blurt.world/blurt/@jacobgadikian/baby-blockchains

For Blurt/steem/hive, hard forks look like:
https://gitlab.com/blurt/blurt/-/blob/dev/libraries/protocol/hardfork.d/0_1.hf

There's more to it than that, of course. But the general idea here is that a hard fork means just switching out a binary. There's no formal governance on it, and that is a bad thing. It's how Justin Sun stole from Steem users. Co-opt the witnesses, co-opt the chain.

For Cosmos-SDK chains so far, seems that the pattern has been governance, then tear down/stand up.

Logistically, the current state seems a bit of a nightmare if you want to upgrade rapidly. Too much cat herding would need to be done with validators.

So I talked to Alessio about this and we felt that a possible solution could be to use cosmosd and have the validators automatically download new binaries, which have been built using the reproducible build system and signed by each of the chain's validators. There's a bit of CI magic behind this where each validator does the build and signs automatically.

This setup also favors a tightly-coupled design and development in a monorepo.

If you have a chain with a general purpose API, like a KV store with ACLs, or a similar json storage mechanism, or you do not want application-like features (the chain in this case is more of a utility provider like Gaia or Akash and stability is a big part of its utility) then you wouldn't want to do rapid upgrades.

This second scenario would favor slower (ideally zero) upgrades and applications would sit on top of it.

Its front end would probably live in a separate repository and it may not even have a front end at all, since it is infrastructure.

Baby Blockchains

This thinking here about upgrades ties into the baby blockchain concept that I was mentioning.

I think that I'm getting closer to a clearly-defined concept here. Specifically, a baby blockchain or ChainDAO has:

• Flexible, secure, fast upgrade system
• Formal Governance for upgrades to ensure community approval
• Precisely defined transaction types
• Tight coupling to front end interfaces
• Stable currency features
• Rapidly evolving application features
• Highly engaged group of core stakeholders who desire to experiment and build something new
• Initially differentiated by community, not software.
  • Software differentiates over time
• ChainDAOs exist to mediate and serve their community, not the entire world