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 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
In a nutshell, the Tezos node now supports two additional history
modes other than
archive, allowing for a drastically reduced disk usage.
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.
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.
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 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.
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