Summary:

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 alpha to 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: A, the one that includes the change in roll size from 10,000 to 8,000 tez and B the one without the roll size change. This code is exactly what we documented in our previous blog post. B simply does not include the change to roll size.

The source code of proposal A is available in this tar archive.

To compute the hash, you can use the tezos-protocol-compiler as follows. The result should be Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd.

mkdir proposal_A
curl https://research-development.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 here. Its hash should be Psd1ynUBhMZAeajwcZJAeq5NrxorM6UCU4GJqxZ7Bx2e9vUWB6z.

You can observe the differences between the two by using the standard Unix tool 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 use 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 002_PsYLVpVv to 003_PsddFKi3).

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 A:

tezos-client submit proposals for <delegate> Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd

If you choose to upvote proposal B:

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 yay, nay or pass on that proposal. It is very important that they do participate, as the quorum must be reached for the amendment process to continue.

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 yay 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 tezos@obsidian.systems for an invite). And of course there is always Riot for open discussions and stackexchange to ask questions.