July 30th 2018: Tezos betanet has now launched, and this article doesn’t reflect the current state of the project. You can still read through it, but the code examples won’t work as is, and will need various changes. Up to date documentation for the betanet is available [here][21]. You can change the address to access docs for other branches like [zeronet][22].

A word about different testnets: there is usually a zeronet running, which follows new developments closely and an alphanet which is more stable. The real network is currently called betanet (transactions persist to the main network). The alphanet is currently obsolete.

My writing is usually focused on the technical side of things, but I’d like to point out that the foundation issues have been resolved and we are going to see more active support for both the Tezos project itself and the surrounding ecosystem from now on.

Since the last article, I’ve finally had the chance to look at the Tezos zeronet – a testnet that runs a very recent version of Tezos. The alphanet that most people used before was running code from November, so it’s not a surprise that the zeronet works a lot better. There have been many changes and upgrades, including some that require changes to application code. I’ll describe them bellow.

The most noticeable changes are:

• six decimal places for tez values
• hashing data now requires type information
• data structure literals use different syntax

Six decimals simply provide more granularity. After three decimal places, a comma can be used to improve readability (but doesn’t have to be). I’ve created a zeronet branch in my projects that contains the updated code required to run them on the zeronet. You can see how to work with the new format there, or read the precise rules in the Michelson language doc.

The hash instruction now requires that we provide a type in addition to the data being hashed. This solved minor issues where there were multiple ways to represent the same information, which however produced different hashes, such as the timestamps 2018-04-12T14:38:42Z and 2018-04-12T14:38:42+00:00. Both of these refer to an identical moment in time, but produce different hashes. Since the client doesn’t know what type the data is, it can’t convert them to one standardized format.

./tezos-client hash data '"2018-04-12T14:38:42+00:00"'
"exprv9MHB3j4v8JcA6MTM1aLRRoQm9wiVkCucFyfzu3VkLa98wQTHP"

./tezos-client hash data '"2018-04-12T14:38:42Z"'
"exprvQkU7R7ZPY4VUkbs7CrpJ9cyVqH3N2qC7bWD8PmobTsGu3prM3"

Now that we can provide a type as well, any possible representations can be converted to a canonical format.

./tezos-client hash data '"2018-04-12T14:38:42Z"' of type 'timestamp'
"exprvQkU7R7ZPY4VUkbs7CrpJ9cyVqH3N2qC7bWD8PmobTsGu3prM3"

./tezos-client hash data '"2018-04-12T14:38:42+00:00"' of type 'timestamp'
"exprvQkU7R7ZPY4VUkbs7CrpJ9cyVqH3N2qC7bWD8PmobTsGu3prM3"

The data structures have a new syntax for literals. Instead of (List 1) or (List) for empty list respectively, we now need to use {1} or {}. (Map 1 a) or (Map) becomes {Elt 1 a} or {}. You’ll notice that both lists and maps use curly brackets, so we need to use Elt to distnguish them. Multiple elements are separated by a semicolon: {1;2;3;4} or {Elt 1 a; Elt 3 b}.

If you have some alphanet contracts that you’d like to use with the zeronet, you’ll have to fix the literals. The rest of the contract should work as expected.

Front-end devs should review code that handles tez values and make sure that the six decimals are correctly displayed. In case integer values with the smallest possible unit are used, you’ll need to multiply amounts to account for extra decimal spaces.

Servers interacting with the blockchain will need more changes – if you are using the command line commands, you’ll need to change hash commands to include data types. You’ll need to fix storage parsing too. The RPC is changing more often and you should check for changes to endpoint paths and input and output formats. A nice overview of endpoints is here.

If you try using Liquidity, you’ll notice that you can’t originate contracts using the web interface. You can, however, use the compiled Michelson sources to originate contracts on zeronet manually through the CLI. Just make sure to change the literals. Remember that you can use the header in Liquidity to let the compiler know which version of Liquidity to expect.

The zeronet client also features an improved man command, and new functionality for bakers and delegates. Since Tezos uses a proof-of-stake mechanism to determine consensus, some nodes are chosen to create (bake) new blocks. These are called bakers. Bakers are incentivized to be honest with baking rewards and the risk of losing a bond, should they try to cheat. Since not everyone will want to take part in this process themselves, there is a possibility of delegating one’s stake to a baker that bakes on one’s behalf.

More documentation about baking is available at the official docs website. The baking mechanism now uses more realistic constants, so that people can fine tune their systems, but they are still subject to change.

I’ve updated my automated insurance contract with some new functionality – namely, it now allows investors that bankroll the contract to withdraw profits. At least twice the amount of combined prices of all policies has to remain in the contract, or the withdrawal will fail. This is meant to ensure that the contract always has enough money to pay out in case of insurance events. The formula or the constants can be adjusted as needed, the current values are just suggestions.

In a production environment, if the contract needs to be upgraded, the procedure could be:

1. Start the new contract, use it for any new policies.
2. Stop selling new policies on the old contract, or linking to it from anywhere.
3. Wait for all the policies in the old contract to expire.
4. Withdraw any profits from the old contract.
5. The old contract gets destroyed when its balance reaches zero.

The new code can be seen in the zeronet branch of the project repo. The demo has been broken for a while, and it’s broken again :) but has now been updated by Richard & Ondřej, and is available at demo.smartcontractlabs.ee. Make sure to reinstall the linked TezBox fork to get the newest version. TezBox is developed by Stephen Andrews.

In the last dev update, other important changes have been announced. Perhaps the most interesting for smart contracts, the calling convention in Michelson is going to be changed. TRANSFER_TOKENS will not be resolved synchronously and the return value won’t be available for immediate use. Instead, any transactions will be evaluated after the evaluation of the current contract is completed.

Where needed, the target contract can return results by calling back the caller contract with the result. The called contract has to be constructed specifically with this in mind – the contract that calls us back needs an entry point.

The main contract could then have a parameter type that looks like this:

# annotations can be used to improve clarity
parameter (or (string @normal_input) (nat @callback_input));

This change will require rewriting all contracts that currently exist, with more focus on working in asynchronous manner. It should also make it easier to avoid reentrancy bugs.

Further down the line, we can expect the hash consing optimization, that has been mentioned a couple times. It’s a way of deduplicating storage, and it will let us reuse existing code cheaply. Therefore, even if we use a lot of common code in our contracts, it won’t make storage prohibitively expensive and it won’t be necessary to have external libraries of contracts for basic functionality.

If you are curious about using Tezos or already building something, come and chat on the developer channel. If you liked this article, you can sign up to my email list about Tezos smart contracts.