Substrate Point: Forkless upgrades just change the default

[JoshOrndorff]

I think there is a chance in the Substrate module @kianenigma to really drive home some points that are set up in Game Theory and also in Blockchain. cc @jonasW3F @coax1d

In Game Theory they talk about the default effect. In blockchain we talk about upgrading networks by forking and how the default is to not change the rules at all. If you want to change anything, you can opt in to the change by updating your node.

In Substrate of course you present forkless runtime upgrades which is one of the killer features of Substrate. I think the point to drive home is that Substrate's forkless upgrade feature simply changes the default.

When using Substrate, the default is to follow the onchain governance whereas pre-substrate, the default is to keep the old rules. Even in Substrate you can still have consensus level forks. And if governance decides something you dislike, you still have the ability to "fork off" and keep the old rules. To take such a non-default position, write some new code and update your node. Same as before.

WDYT?

[kianenigma]

how the default is to not change the rules at all

I think all you said is true, but if you look at substrate at the meta-blockchain level, the default is still to keep not change the rule, but "rule" here means "do as the WASM blob wishes".

[JoshOrndorff]

Ah yeah! I exactly agree with you. That's also a great point to make. At the meta-protocol level the rules don't change we just keep executing the wasm as always.

So another also useful and also correct way to frame it is that Substrate provides a mechanism to upgrade the state machine from within the state machine without a consensus fork. If you are dissatisfied with the outcomes of this in-runtime game, you can still perform a regular old consensus fork and change the meta protocol rules from "just follow the wasm" to "follow this other wasm that is the same as the old one and possibly censor upgrade transactions if necessary".

[jonasW3F]

I actually like the perspective that @JoshOrndorff is proposing. I think we can agree that the idea behind it is correct, we just need a precise description. I'll try and correct me if I am mistaken in any of the fine nuances here.

All blockchains (including Polkadot) commonly "follow the consensus rules". But and in contrast to (most?) other blockchains, we form consensus not on static rules but on flexible ones. Concretely, we automatically follow everything that is legitimated by governance and then automatically adopted by all nodes. So, the rule is the same "follow consensus", but it leads to effectively other outcomes. In Polkadot's case, we obtain forkless upgrades while other blockchains are left with hard forks. What is important here is that Polkadot integrates a collective decision-making system into its consensus, something that not many other blockchains have.

Ultimately, if we touch the "default effect" in this topic, we should also highlight the social layer. Since Polkadot does this from the very beginning, its governance process (now OpenGov) is considered legitimate by pretty much every participant, creating a social norm where following changes (again, legitimated by governance) are the default.

[JoshOrndorff]

TIL Vitalik made the same point as far as I can tell back in 2017 https://vitalik.eth.limo/general/2017/12/17/voting.html

These three are all examples of loosely coupled coin voting, or coin voting as a layer 2 coordination institution. Ethereum does not have any examples of tightly coupled coin voting (or, coin voting as a layer 1 in-protocol feature), though it does have an example of tightly coupled miner voting: miners' right to vote on the gas limit. Clearly, tightly coupled voting and loosely coupled voting are competitors in the governance mechanism space, so it's worth dissecting: what are the advantages and disadvantages of each one?

Assuming zero transaction costs, and if used as a sole governance mechanism, the two are clearly equivalent. If a loosely coupled vote says that change X should be implemented, then that will serve as a "green flag" encouraging everyone to download the update; if a minority wants to rebel, they will simply not download the update. If a tightly coupled vote implements change X, then the change happens automatically, and if a minority wants to rebel they can install a hard fork update that cancels the change. However, there clearly are nonzero transaction costs associated with making a hard fork, and this leads to some very important differences.

One very simple, and important, difference is that tightly coupled voting creates a default in favor of the blockchain adopting what the majority wants, requiring minorities to exert great effort to coordinate a hard fork to preserve a blockchain's existing properties, whereas loosely coupled voting is only a coordination tool, and still requires users to actually download and run the software that implements any given fork. But there are also many other differences. Now, let us go through some arguments against voting, and dissect how each argument applies to voting as layer 1 and voting as layer 2.