Interesting read! Many clever ideas (e.g. time-locked deposit, baker to split in yes/no address, etc.)
"As in the Exploration Vote Period, bakers submit their votes using the ballot operation, with their votes weighted proportionally to the number of rolls in their staking balance at the beginning of the Promotion Vote Period. As in the Exploration Vote Period, each baker may send only one ballot operation during this period."
I see it is contested later in the article but why start with the above logic? Additionally, don't we risk they go short in the meantime and approve a bad proposition? Is there even an advantage of snapping it in the beginning i.o. in the end?
After voting, are we able to change our vote (e.g. new information/clarity has appeared)? I do understand allowing this may introduce uncertainty.
Scary to read about (code changes are huge and possible attack vectors). Theoretically, if voting participation is low, some one eventually could just fork with malicious code once the quorum reaches a low enough level? Say I have 20% of the network in rolls distribution, split into 2 bakers. Propose malicious changes and vote for them on only one baker until the quorum reaches such a level where I can use both bakers (the full 20%) and approve my own changes?
Tezos would have to be dying and very unprofitable for such low interest and participation from bakers. The 20% quorum floor you refer to is at 0% voter participation which is not going to happen.
Malfeasance can be blocked by mobilizing “nay” votes also
Can someone explain the more technical aspects of this process? It says that a baker is to send a hash of a tarball of .ml files (Michelson code). How does this code actually make its way into the source code on gitlab? Does this require a Tezos developer to merge the code? What if "the people" vote Yes to proposal, but the devs all think it's dumb. Do they have the ultimate power to reject code changes?
Upgrading to protocol 3 earlier this week took massive coordination between bakers. If "the network" automatically switches to the voted-for fork, how are bakers ensured to run the latest code?
The process of gossiping the tarball on the network? That's something the nodes do, I don't think there's documentation on this beyond the code comments. The process is explained in the white paper.
No one's saying developers aren't involved, obviously someone, somewhere, has to write code for a proposal to exist.
003 was a security patch that required quick deployment. On-chain governance is slow and deliberative by design, it's not meant as a replacement for security patches. The process for the latter is bound to remain ad hoc for a long time.
Say only 79% is reached. What happens if this majority still wants to upgrade? Nothing is stopping these individuals from creating their own implementation of Tezos with this upgrade now added correct?
I'm just trying to understand this process from all angles.
lol. Well at least you didn't pick 1.
I work in agile software design. I was hoping there was some in depth user research based study. I'm sure there was more thought put into that than you are leading on, but as you said...it can be amended.
My intuition is that the quorum is the more important variable and it auto adjusts. As far as the majority goes, I think outcomes are bimodal: some decisions are largely consensual and will clear most bars, some aren't and will likely be more contentious, so I don't think there's a lot of sensitivity to that parameter.
My only worry is that people will vote impulsively or won't educate themselves enough to vote responsibly or even vote in general. Eg: The American political system.
Then again, that will be helped by only allowing bakers the ability to vote.
Either way, it will be a fascinating journey to be a part of.