Today marks an important milestone for Tezos. We just triggered the
beginning of the first on-chain vote for self amendment. This process
could end in the successful migration from current protocol
Athens in about three months, if the participants decide so.
As advertised in the last meanwhile at Nomadic and as detailed in our previous post, we injected the hashes of two proposals. Both include the same enhancements except for one: the decreased amount in the number of tokens needed to be your own baker (the roll size).
This post includes instructions to download and observe the code, to recompute the hash of each proposal by yourself, and to examine the differences between the two, and with the current protocol.
It then presents the method we recommend to bakers if they wish to upvote either of the two proposals, and a quick reminder of what they will have to do next to confirm their choice in the next voting phases.
Finally, it gives instructions for people who want to volunteer in a live test on the Zeronet test network.
Getting the source code of both proposals
We just published the source code of both proposals for Athens:
the one that includes the change in roll size from 10,000 to 8,000
B the one without the roll size change. This code is exactly
what we documented in our previous blog
B simply does not include the change to roll size.
The source code of proposal
A is available in this tar
To compute the hash, you can use the
follows. The result should be
mkdir proposal_A curl http://blog.nomadic-labs.com/files/Athens_proposal_A.tar | tar x -C proposal_A tezos-protocol-compiler -hash-only proposal_A
Similarly a tar archive for proposal
B is located
hash should be
You can observe the differences between the two by using the standard
diff proposal_A proposal_B. It should only mention the
roll size change.
If you want to observe the changes with the current protocol, you can
diff against folder
proto_003_PsddFKi3 of the mainnet source
code. All the changes should be the ones detailed in our previous blog
post, except for the removal of the single use migration code from the
previous upgrade (from
How to upvote either of the proposals
The easiest way to create and sign a voting operation today is to use the command line Tezos client, as follows, and as detailed in the online documentation.
If you choose to upvote proposal
tezos-client submit proposals for <delegate> Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd
If you choose to upvote proposal
tezos-client submit proposals for <delegate> Psd1ynUBhMZAeajwcZJAeq5NrxorM6UCU4GJqxZ7Bx2e9vUWB6z
It is worth noting that these voting commands have been merged in the
mainnet distribution only recently, and bakers who want to use them
have to update their
tezos-client to the most recent version. This
update also includes patches from Obsidian Systems to vote with a
Ledger device. No update is needed for the node or
protocol: if you have a running and synchronised node, you do not need
to restart it.
What will come next
The current voting phase started on the 25th of February. At the end of this period, which should be in about three weeks, one proposal will have received a higher number of upvotes, and will be put to a direct vote.
At this point, bakers will have about three weeks to vote
pass on that proposal. It is very important that they do
participate, as the quorum must be reached for the amendment process
During these three weeks, we will publish an optional update of the node that will serve two purposes.
- First, it will embed the most upvoted candidate and the associated client and baking daemons, so that bakers can prepare themselves in advance to be ready to bake when the migration comes.
- Second, this update will include fixes to the node that are not strictly necessary for the network to operate and retrocompatible, but required for the third phase, the testing period, to succeed.
Let’s recall that during this third phase, the network spawns a test chain: a fork of the main chain with an expiration date (of 48 hours) and thus no value. Bakers are encouraged to bake on this test chain to try the new protocol in real conditions, with their actual baking keys. The current code for the node does not spawn this test chain. This has no incidence of the main chain, but deprives us of a useful testing mechanism.
Bakers who want to participate in the test chain will have to upgrade their nodes at this point. Our plan is to include the final baker for the main chain, and hopefully additional non vote related features such as snapshots, so as to limit the number of upgrades for bakers.
Finally, if everything goes well, bakers will be ready and vote
in the last voting phase, and the network will self amend.
Participating in the Zeronet rehearsal
In parallel, we have set up a rehearsal of the complete voting procedure on the Zeronet test network. Zeronet moves at a faster pace than Mainnet, giving the opportunity to try the voting procedure with voting periods lasting only 51 hours (in the optimistic case where all blocks are baked at the highest priority). If all goes well, the entire voting procedure should have completed before the end of the first voting period on Mainnet.
The goal of this simulation is twofold.
- First, we want to test the complete procedure in a public setting. This can help bring public confidence in the global process. This is also the occasion for bakers who use third party or homemade components (such as custom remote or hardware signers) to test how their system behaves during automatic upgrades and on a test chain.
- Second, this is the occasion for the community to learn to communicate and debate during the vote. For this reason, we encourage all participants to take the matter seriously. In particular, we would not want to delay the procedure for too long because someone abused the faucet and then forgot to launch their baking daemon, ending up in lots of missed blocks. In the same vein, we encourage all participants to be there and vote when their participation is needed, so that we do reach the quorum and supermajority, and the process can continue.
Here is the current state of this rehearsal:
- On Tuesday, we reset the Zeronet, to set up the new time constants that allow the vote to run much quicker than in Mainnet, while still allowing people in different time zones to have a chance to participate in each period.
- It is now time for participants to deploy their nodes, use the faucet to get some rolls, become delegates and start baking.
- Tomorrow, we shall publish a new Zeronet branch and Docker image that embeds the two proposals (the same as in Mainnet), and the two sets of associated baking daemons.
- In the next few days, we shall inject the two proposals, launching the voting procedure.
We invite active participants to discuss and organise the rest of the
rehearsal in a specific channel
#zerovote on the Baker’s slack
operated by Obsidian Systems (just email
an invite). And of course there is always
Riot for open
discussions and stackexchange to