Today we are proud to announce a new release of the Tezos node and client.

The main features present in this release are:

• node support for snapshots (boot and synchronize a node in minutes),
• node support for new history modes (not everyone needs to be an archive),
• client integration for a multi-signature contract.

Remember that besides major features there are always a myriad of smaller improvements, have a look at the changelog.

We encourage bakers to switch to history mode “full” using a snapshot before the activation of Athens to speedup the validation of the transition block. Detailed instructions are available on the release page.

History modes

Gitlab MR

History mode, together with snapshots, is a feature that has been in the works for quite some time. For a full dive have a look at the original in-depth post. In a nutshell, the Tezos node now supports two additional history modes other than archive, allowing for a drastically reduced disk usage.

The archive mode keeps the whole history of the chain, that is all the blocks and all the contexts resulting from their application. For example it is possible to check that the block at level n had a transfer from Alice to Bob and query that the balance of both accounts in the context were updated. This mode is particularly useful for a block explorer or an application that needs to query the past.

History mode full still has the whole history of the chain but only keeps the blocks. This means that it is possible to replay the whole history from genesis and verify the integrity of the chain but it’s not possible to inspect a context far in the past. In our example we would be able to find the transaction from Alice to Bob at level n, but not query the effect on their balances. Note however that, if needed, it is possible to reconstruct an archive node from a full node by replaying the application of each block and obtaining each intermediate context. This mode is the new default for all newly deployed nodes.

History mode rolling pushes the concept further and permits to delete altogether all the data from a given cutoff point. In this case it’s not possible to access the entirety of the chain from genesis but the disk footprint is reduced even further.

At this time we discourage baking from a rolling node as not all necessary information might be available.

Baking from a full node is supported and recommended. Indeed, not only does the baker performance benefit from the reduced disk usage, but it also has no need for the archives. If a baking service needs the archives, they should consider deploying both a full node for baking, and an archive node for other purposes.

For more details refer to the documentation.

Snapshots

Gitlab MR

Snapshots are a compact and portable way to store the status of a Tezos chain. They can be easily transmitted and used to setup new nodes without the need to re-synchronize the chain as showcased in a recent blogpost from Rajath Alex of TQ.

When importing a snapshot from a third party, it is particularly important to verify that the block hash of the snapshot is correct and consistent with respect to several independent sources (block explorers, wallets, …). An attacker could provide a snapshot representing an alternative chain history to fool your node.

It is good practice to regularly take a snapshot of a node, for example with a cron job every night or week. The files produce are relatively small, especially when compressed. As of today a full snapshot takes 1.8GB (1.1 gzipped) while a rolling snapshot takes 417MB (137 gzipped).

For more details refer to the documentation.

Multisig

Gitlab MR

Tezos client now integrates a few commands to originate and interact with the multi-signature smart contract written in Michelson. The client supports originating the contract with the specified keys and the required threshold to unlock the funds. It is also possible to change existing keys, remove them or change the threshold. Being only a friendlier interface to a standard smart contract, it is still possible to interact with the multisig by performing a normal transaction from your favorite client or wallet.

More importantly, the contract has been formally proven to comply with the functional specification of a multisig using our Coq framework Mi-Cho-Coq. While this verification does not exclude the possibility of bugs in the specification or the Michelson interpreter, it gives a very high level of confidence in the correctness of this smart-contract. More details on the multisig and its verification will be available in future posts.

Originating a M-of-N multisig in Tezos is now as easy as:

tezos-client deploy multisig <contract-alias> \
             for <manager-account> \
             transferring <amount> from <source-account> \
             with threshold <M> \
             on public keys <signer-1 ... signer-N> \
             --burn-cap 100