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.
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 the community about the new features.
Nomadic Labs is currently preparing to submit its first protocol amendment proposals for a vote. Of course, it means selecting and implementing the contents of our proposals, but also monitoring that the process behaves as intended.
Specifically, this includes making sure that the voting and test chain mechanisms work as expected, and rehearsing the procedure.
It also means collaborating with our fellow Tezos core contributors to make sure that everything is in place, including the new voting feature in Obsidian Systems’ Ledger app.
More posts in the next weeks will prepare the ground for our proposal. For the time being, bakers should familiarise themselves with the voting procedure, fully described in this post.
We hope to organise a rehearsal via the Alphanet in coming weeks. We encourage bakers to join to test their setup is ready for the potential upgrade.
We intend to propose two competing amendments. The first one increases the current gas limit, the second one also increases the gas limit and, in addition, it also reduces the roll size. This lets us, the community, test the approval voting phase. Since one of these amendments may be the first to activate on the Tezos network, we felt it important to propose simple changes.
The main goal is to prove that Tezos can carry out a successful update both technically and as a community. After all, we are all novices to the Tezos governance procedure and this aims to be a first step towards more substantial amendments.
Rolls, the unit of stake used to assign rights to bakers, are currently set at 10k ꜩ. Because roll size can significantly influence node performance, both in terms of storage and computation time, we developed a specific set of benchmarks to evaluate it. These benchmarks test the reassignment of the rolls during the protocol upgrade as well as the evolution of the network for several cycles afterwards. Changing the roll size is not just a matter of changing a constant in one line of code!
Furthermore, roll size also has an economic impact on services that build on Tezos, especially delegation. Even if the community does agree to reduce roll size, it should be carried out progressively to minimize disruption. In a future post, we will describe further details about how rolls would be reallocated during a potential upgrade.
The second important change that we want to propose is a (much requested) increase of the gas limit for running Michelson smart contracts. We thought it wise to set the gas limit as a conservative value to protect the chain, with the intention that the Tezos amendment mechanism facilitates future improvements based on a thorough benchmarking.
The current relative weight of Michelson instructions were established on the basis of their algorithmic costs, using very conservative factors to distinguish between time, space and I/O consumption. Updating the limit to target an actual transaction throughput requires the estimation to be more fine grained, using real-time estimates on representative machines.
This performance analysis has been in the works for some time now and it is starting to show practical results.
The proposed amendments leaves the current weighting as is, but does increase the gas limit based on our preliminary results. In the future we hope to completely refine the weight distribution of instructions, and raise the limit once again based on the final benchmarks.
Independently from the amendment proposal, we are also intending to release an improved version of the node software which hosts the protocol. The design of Tezos conveniently isolates the logic of the protocol inside of a shell, which means changes that do not affect the protocol can be rolled out more easily.
Several efforts towards a lighter disk footprint and faster synchronisation of the node are almost ready to ship.
First, the node will be able to discard past states of the context using a “garbage collector”. This means that no chain data is discarded and no security property is lost in this process. Nodes will also, optionally, be able to more aggressively discard older blocks to allow running on the more size-constrained devices.
Second, the node will be able to bootstrap rapidly and safely using a snapshot of a context that was saved previously or provided by another node, without the need to re-download and replay all blocks since the genesis. Of course, the safety of this mechanism depends on the user providing a valid checkpoint on startup. This could be gathered from another node run by the same user for instance.
We will also use this series of posts to highlight the few important recent interactions we had with other members of the project.
Recently, a few of us have been visiting NYC to meet with other members of the Tezos ecosystem, including Obsidian Systems, Cryptonomic, CamlCase, as well as Jacob and Alison from TQ. We expect to collaborate more in the future, folks!
In October we organized a training session in Paris for new core protocol developers, with some of the presentations available on our Youtube channel.
Nomadic Labs is also compiling new material for training sessions targeted at smart contract and protocol developers that will take place in Q1.
Some of the elements overviewed in this Meanwhile at Nomadic post will be detailed in in-depth technical articles in the next few weeks. Topics will include:
- Checkpoints, Storage Snapshots and GC
- How the Amendment Procedure Works
- Benchmarking Michelson to Get Accurate Gas Accounting