Dune Network Development Update

After the successful protocol revision upgrade on Nov 5, 2019, we are now working on a more important upgrade, a complete protocol change, that will probably be scheduled for mid-December. This new protocol, called Babylon+, should provide the following changes:

• New baking account management features
• Import of the Babylon and Carthage amendments from Tezos, with some minor changes and fixes
• First version of the Love VM, a new on-chain smart contract language, much more powerful than Michelson

In this post, we will focus on the two first items, as the Love VM stuff deserves a full dedicated post, that we will publish in the next weeks.

Baking Account Management

In the past, bakers have faced three important problems:

• How to reduce their staking/number of rolls ?
• How to prevent over-delegation ?
• How to improve the security of their baking account ?

The new Baking Account Management features introduced in Babylon+ should help bakers deal with these problems. Every account in Dune has a set of parameters attached to it. By setting/changing these parameters, in a simple operation, bakers will be able to get better control over their baking activity.

How to reduce the staking/number of rolls ?

One of the first parameters that we introduced is maxrolls: it defines the maximal number of rolls that a baker wants to have. By default, maxrolls is not set, and there is no limit on the number of rolls. But a baker can use this parameter at any time to reduce (or later increase) the number of rolls he wants to work with. The impact is not immediate, since, as for the staking balance, the parameter only impacts the number of rolls 7 cycles later.

Here is an example of use : a baker has a balance of 1,000,000 $dun, i.e. 100 rolls. He wants to decrease his balance to 500,000 $dun. Today, that’s almost impossible, because the 1,000,000 $dun are frozen as deposits for his baked blocks and endorsements. Before Babylon+, the baker would have to stop their baker for a while, missing many blocks and endorsements and slowing down the network. With Babylon+, the baker can set maxrolls to 50. As a consequence, his baker will receive fewer blocks to bake/endorse 7 cycles later, and he should be able to recover 500,000 $dun.

How to prevent over-delegation ?

A second interesting parameter that we introduced is delegation. It’s a boolean telling the system whether delegation is possible or not. If a baker sets delegation to false for his account, any attempt to delegate to the baker account will fail. So, an over-delegated baker can use this parameter to prevent new delegations.

Note that maxrolls will also prevent any new delegation if the current number of rolls has already reached maxrolls.

In both cases, this feature prevents new delegations, it does not prevent existing delegations from increasing their balance, and so, their delegation.

How to improve the security of a baking account ?

Bakers might be worried about the secret key used to bake/endorse blocks. Attackers may try to target that key to get the tokens waiting to be used for deposits. To help secure such accounts, we introduced two parameters:

• The admin parameter can be used to define another account, that is responsible for managing the baker’s account. The admin can actually only modify the account parameters, nothing more.
• The white_list parameter can be used to define a short list (at most 4) of contracts, that can be the only recipients for transfers from this account. By default, the white_list is empty, and all accounts can be recipients. If the white_list is not empty, all originations from the account are also forbidden.

Using these parameters, a baker can set an admin for his baking account, and white-list only one address as the recipient for transfers from his baking account. If the baking account is compromised, the attacker won’t be able to transfer the funds.

Setting Account Parameters

We introduced two new commands in dune-client to read/write account parameters:

dune-client dune get parameters for ACCOUNT

This command will display a JSON file containing the current parameters for the given account.

dune-client dune change account parameters JSONFILE of ACCOUNT with admin ACCOUNT

This second command can be used to modify the parameters of an account. Note that, by default, the admin of any account is itself. You will also need to have the secret keys for both the account and the admin account.

The JSON file looks like:

{ "admin": "dn1ax1fXs5KD3MzoV6tcAyZ6rGLMaHBTYz5f",
  "white_list": [ "dn1ax1fXs5KD3MzoV6tcAyZ6rGLMaHBTYz5f" ]
}

In this example, the baker sets both the admin parameter and a white_list containing only the admin account.

Babylon and Carthage Tezos amendments

Babylon+ will introduce all the features of the Tezos amendments Babylon and Carthage. Babylon is described here. Carthage is mostly a bug fix amendment on Babylon.

Given the incompatibilities introduced by this new amendment, users should check that the tools that they are using have been upgraded to fit the new protocol, once it has been promoted.

From a user point of view, the main differences are:

• implicit accounts (accounts with an associated secret key, dn1/dn2/dn3) are now delegatable
• originated accounts (KT1 without code) are removed
• the spendable/delegatable flags are removed

The following mechanism is used to get rid of existing originated accounts:

• if an originated account is not delegated, or it is delegated to the same baker as its manager, its balance is simply credited to its manager account, and the originated account is discarded.
• if the manager of an originated account is not delegated, the balance of the originated account is credited to its manager, the manager is delegated to the same baker, and the originated account is discarded.
• if the manager is delegated to a different baker from the originated account (which can only happen if another originated account with the same manager was previously found delegating to the different baker and discarded), the originated account becomes a smart contract, using a contract code called manager.tz. dune-client will transparently convert any operation (transfer/delegation) on the originated account into an equivalent operation on the smart contract. Other tools will have to be able to deal with manager.tz contracts.

Note that, if an originated account is discarded, a forwarder will be set until the next protocol upgrade. All tokens credited to the originated accounts are transparently forwarded to its former manager. This mechanism can be used by bakers to distribute their rewards without changing the targets during the first cycles after the upgrade.

Conclusion

All these features should be available in Dune Network when the new protocol will be promoted, around mid-December. We will schedule an official date in the next days. In a forthcoming article, we will introduce the new Love VM, all its features and its use through Liquidity 2.0.