Nomadic Labs
Nomadic Labs
Athens: Proposals Injected!

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.

an Athenian voting token

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 | 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.

an Athenian voting token

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

Athens: Our Proposals for the First Voted Amendment

This blog post is a preview of Athens: our protocol proposal for the first voted upgrade of Tezos. As announced in the last meanwhile at Nomadic, we shall propose two upgrades: one lowers the roll size to 8,000 tez, the other leaves it unchanged at 10,000 tez. Both alternatives will include an increase of the gas limit. The hashes of both versions will be proposed on mainnet later this week, now that a new proposal period has begun. Later this week, we will publish a...

Read More
Amendments at Work in Tezos

We are now on the verge of submitting a protocol upgrade to a vote, and it seems like a good opportunity to explain in details the way in which Tezos node handles amendment in practice. Brace yourselves, this article is quite technical, as are all articles in our in-depth category. Still, as we did in the previous one on snapshots, we’ll try to explain the stakes and announcements and give a brief summary in a short foreword understandable even by non-programmers. The original whitepaper...

Read More
Introducing Snapshots and History Modes for the Tezos Node

In this article, we introduce two new features for the Tezos node: snapshots and history modes. A snapshot is a file that contains everything necessary to restore the state of a node at a given block. A node restored via a snapshot can synchronise and help other nodes synchronise in the existing network. The only difference is that you cannot query the chain context (balances, baking rights, etc.) before the restoration point, but you can still get the full chain history. In conjunction, we also...

Read More
Nomadic Labs at Fosdem 2019

Fosdem is of the largest gatherings of Free and Open Source Developers in Europe. It’s held every year in Brussels during the first weekend of February. This year Nomadic Labs is involved in the organization of the “Blockchain and Crypto-currencies devroom”, a one day workshop to present Blockchain projects to the FOSS community. We strongly believe in open source and we want to share our work with the FOSS community at large. We will also present our work on the Tezos project,...

Read More
Meanwhile at Nomadic Labs #1

This post is the first of a series covering the on-going work at Nomadic Labs. In these posts, we focus on our current top priorities, but of course we have many more projects in the works. Preparing Our First Amendment Proposals Tezos is capable, by design, of automatically amending its economic protocol without the need for a manual update or hard-fork. The current protocol is designed to amend itself only after a successful voting procedure, ensuring that there is awareness and consensus in...

Read More
Study, Learn and Work with Nomadic Labs

Nomadic Labs is opening its doors to students from all around the world to join our internship program. We are interested in many research and practical projects ranging from parallel programming using hardware accelerators, to verification of Michelson contracts, creation of ReasonML/Michelson decentralized applications and privacy analysis of the Tezos network. Internships are tailored to Master’s students. Some proposals have already been submitted to a few European universities. They will typically run for a maximum of six months. We will happily receive and evaluate applications from...

Read More
Nomadic Labs at Popl 2019

POPL is one of the most prominent conferences in Programming Languages, this year held in Portugal. Programming Language Theory is at the core of the Tezos project as demonstrated by the sponsoring of the Tezos Foundation for the conference. Nomadic Labs is happy to attend the conference and looking forward to meeting researchers and industrial partners interested in advancing the state of the art in blockchain technology. The program is available on the POPL website....

Read More
Hello, world!

We’re a team built around lead architects of the Tezos seed protocol, Benjamin “klakplok”, Grégoire “hnrgrgr” and Pierre “chambart” of OCamlPro with the help of the Tezos Foundation. After a busy year and the successful launch of Tezos our team finally has a home: Nomadic Labs. In the last year, our team has grown rapidly to more than 30 permanent developers, coming from both academia and industry - many of whom hold a PhD in computer science fields. Among them, Pierre Boutillier,...

Read More
  • 2
  • 3

Receive Updates