Astrolabe Tezos Test Network

What is the Astrolabe test network?

It is important to note that, at the time of writing, features available on the Astrolabe test network have not been included and are not guaranteed to be included in an upcoming Tezos protocol proposal.

The Astrolabe test network was launched on Friday, the 4th of December 2020. More precisely, its first block (activation) happened on 2020-12-04T13:52:08Z GTM. The Astrolabe test network continues to run stably and no issues have been found so far.

We encourage the Tezos community to read about these features and to test them directly by interacting with the Tezos Astrolabe test network. If you wish to make any contributions or report issues, please use this GitLab issue template.

List of features

The list below includes the features, which are currently available on the Astrolabe test network. Astrolabe’s developer documentation can be found on the website metastatedev.gitlab.io/astrolabe-docs.

List of features
Summary & final remarks
More resources

Multi-Asset Shielded Pool

The multi-asset shielded pool, or MASP for short, allows transfers for all assets to share a common and joined privacy pool. More information about the MASP can be found here.
A contract that can be used with the MASP is available here and can be deployed by anyone on Astrolabe.

Baking accounts

Background

Related articles: Enhancing baking accounts and stateful baking accounts.

For an overview of design and features in comparison with the current state of baking in Tezos, please refer to our previous Stateful Baking Accounts post. In this post, we’ll go into further detail on how the new baking accounts work and how to interact with them. For users’ convenience, the feature is supported by the Tezos client and the Tezos wallet.

Features

A baking (or interchangeably baker) account is a first-class account type, represented by a baker hash with the prefix SG1 (e.g. SG1fpFaowYY8G7PfkYdKkGmsMziHKUfrHRHW). A baker account is associated with baker-specific state with the ability to change the key they use to participate in the consensus, governance and other interactions with the chain. Furthermore, baker accounts are enhanced with a generic multi-signature Michelson script.

Baker registration

Similar to smart contracts, baker accounts are originated on chain. The client command to register a baker that injects Baker_registration operation:

tezos-client register baker <alias> transferring <qty> from <src> with
  consensus key <key> and threshold <threshold> and owner keys [<key>...]

A successful result of the Baker_registration operation will contain the baker hash of the registered account that will be added to the wallet under the given <alias> as witnessed by the client command:

tezos-client list known contracts

When registering, the baker accounts may be credited with a given <qty> amount from the <src> contract. A <consensus_key> is a public key such as the ones used for implicit accounts. This implies that the baker’s consensus key is a revealed public key.

Furthermore, the <threshold> and owner [<key>...]s (one or more keys) are set in the baking account’s multi-signature (multisig) script. The owner keys are public keys that are authorized to prepare signatures for interactions with the baker account via the multisig script and the threshold represents the minimum number of signatures required to authorize a multisig call. Note that when only one owner key is given, the baker script is recognized by the client as a single-signature, for which simpler client commands are provided.

Consensus key

A consensus key is a public key. A baker account has exactly one active consensus key and at most one pending consensus key. When an operation to change baker’s consensus key is applied, the new key is pending before it becomes active. Consensus keys (both active and pending) must be unique. It is forbidden to attach a consensus key to a baker contract, if it is already being used as an allocated implicit account (i.e., a tz[123] account whose balance is greater than ꜩ0). This means that there is 1-to-1 mapping between a baker account and its consensus key.

An active baker consensus key can be used to bake and endorse and as a source and target of operations:

propose and vote on protocol upgrades
being delegated to
transfer from and to
origination
baker registration

Please note that although it is possible to set delegation targeting a baker’s consensus key, it is preferable to delegate to the baker account address (i.e. baker hash) as consensus keys may change.

In Michelson, the instructions SET_DELEGATE and CREATE_CONTRACT now accept baker_hash for delegate.

On operation application, the hashes of consensus keys (i.e. public key hashes) are mapped to their baker contracts. The mapping from consensus keys to baker accounts applied in an operation is attached to the operation metadata (receipts) in the field "mapped_keys", e.g.:

{
   "mapped_keys":
      [ { "consensus_key": "tz1UJbFsTQfdpa1qYrqHG9Ykw834AXi5WqRR",
          "baker": "SG1fpFaowYY8G7PfkYdKkGmsMziHKUfrHRHW" } ]
}

When an active consensus key is used as the source of an operation, it
will be the baker account that uses this consensus key who pays for the
operation burns and fees. For balance transfers, the balance will be
credited or debited from the baker’s account (because the consensus key
may not be allocated with balance). Also, the baker account’s internal
counter is being used for replay protection.

A consensus key can be changed at any point. This may be done with commands (on a single-signature and a multi-signature baker script, respectively):

tezos-client set baker <bkr> consensus key to <key>

# forge a signature
tezos-client sign baker transaction on <bkr> setting consensus key to <key> with key <owner_key>
# submit the operation with given signatures
tezos-client set multisig baker <bkr> consensus key to <key> on behalf of <src> with signatures [<signature>...]

The given key then becomes a pending consensus key with its activation cycle set to Constants.preserved_cycles + 2 = 7 cycles from the current cycle. On the start of the activation cycle, a pending consensus key becomes the active consensus key and the previous active consensus key is freed up. Should a new consensus key be set before the current pending key becomes active, the previous pending consensus key will be replaced and free up and the activation cycle will reset to Constants.preserved_cycles + 2 cycles from the current cycle.

A pending consensus key may not be used as a source of target of operations until it becomes active.

A command to look-up a baker by an active consensus key is provided:

tezos-client find baker with consensus key <src>

Generic multisig script

Baker accounts include a generic multisig script. For now, baker accounts cannot deploy custom scripts.

For those familiar with the multisig script integrated into the tezos client: The generic multisig is similar, but instead of having the possible actions hard-coded in the script’s parameter, it accepts a generic lambda expression that may be used to submit custom actions as well as perform the same actions as the non-generic multisig.

The baker generic multisig script is based on the generic multisig that may be used with originated (KT1) contracts. The difference is that the generic action allows one to submit baker operations. Baker operations are operations that may only be applied from baker contract scripts and not from originated contracts. For the generic multisig script the type of the generic action is extended from returning a list of operations:

(lambda %operation
        unit
        (list operation))

to return a pair of a list of operations and a list of baker operations:

(lambda %operation
        unit
        pair (list operation) (list baker_operation)))

The baker script is authorized with what we call owner keys. These keys are stored in the script’s storage together with a threshold, which determines the minimum number of signatures required to successfully call some action. When only one owner key is set, it is said to be single-signature. The script also contains a counter for replay protection.

A list of predefined actions and a generic call with a Michelson lambda expression are supported by the client for both single-signature and multi-signature variants.

Baker script client commands

Single-signature is a special case of multi-sig (it has a single owner key). Because of this, single-signature actions may be submitted in a single command, which forges the signature and calls the script. For single-signature commands, the baker account is set as the source and will be paying for the transaction fees and burns that may incur.

The following single-signature commands are available:

Transfer: tezos-client from baker contract <bkr> transfer <qty> to <dst>
Submit proposals: tezos-client from baker contract <bkr> submit proposals for protocols [<proposal>...]
Submit ballot: tezos-client from baker contract <bkr> submit ballot for protocol <proposal> <yays_per_roll> <nays_per_roll> <passes_per_roll>
Set baker active: tezos-client set baker <bkr> <active/inactive>
Toggle new delegations: tezos-client set baker <bkr> <accepting/declining> new delegations
Set consensus key: tezos-client set baker <bkr> consensus key to <key>
Set owner keys: tezos-client set baker <bkr> threshold to <threshold> and owner keys to [<owner_key>...]
Generic: tezos-client call generic baker <bkr> with lambda <lambda>

Calling multi-signature contracts is a bit more involved. There are triples of commands:

“prepare” commands to display the threshold, public keys, and byte sequence to sign for a multisigned transfer
“sign” commands to forge a signature with a given key
“transaction” commands that call the script with the given signatures

The multi-signature commands are:

Transfer:

tezos-client prepare baker transaction on <bkr> transferring <qty> to <dst>
tezos-client sign baker transaction on <bkr> transferring <qty> to <dst> with key <owner_key>
tezos-client from multisig baker <bkr> transfer <qty> to <dst> on behalf of <src> with signatures [<signature>...]

Submit proposals:

tezos-client prepare baker transaction on <bkr> submitting proposals [<proposal>...]
tezos-client sign baker transaction on <bkr> submitting proposals [<proposal>...] with key <owner_key>
tezos-client from multisig baker <bkr> submit proposals on behalf of <src> with signatures [<signature>...] for protocols [<proposal>...]

Submit ballot:

tezos-client prepare baker transaction on <bkr> submitting ballot <proposal> <yays_per_roll> <nays_per_roll> <passes_per_roll>
tezos-client sign baker transaction on <bkr> submitting ballot <proposal> <yays_per_roll> <nays_per_roll> <passes_per_roll> with key <owner_key>
tezos-client from multisig baker <bkr> submit ballot on behalf of <src> with signatures [<signature>...] for protocol <proposal> <yays_per_roll> <nays_per_roll> <passes_per_roll>

Set baker active:

tezos-client prepare baker transaction on <bkr> setting it <active/inactive>
tezos-client sign baker transaction on <bkr> setting it <active/inactive> with key <owner_key>
tezos-client set multisig baker <bkr> <active/inactive> on behalf of <src> with signatures [<signature>...]

Toggle new delegations:

tezos-client prepare baker transaction on <bkr> setting it <accepting/declining> new delegations
sign baker transaction on <bkr> setting it <accepting/declining> new delegations with key <owner_key>
tezos-client set multisig baker <bkr> <accepting/declining> new delegations on behalf of <src> with signatures [<signature>...]

Set consensus key:

tezos-client prepare baker transaction on <bkr> setting consensus key to <key>
tezos-client sign baker transaction on <bkr> setting consensus key to <key> with key <owner_key>
tezos-client set multisig baker <bkr> consensus key to <key> on behalf of <src> with signatures [<signature>...]

Set owner keys:

tezos-client prepare baker transaction on <bkr> setting threshold to <threshold> and owner keys to [<owner_key>...]
tezos-client sign baker transaction on <bkr> setting threshold to <threshold> and owner keys to [<owner_key>...] with key <owner_key>
tezos-client set multisig bakers <bkr> threshold to <threshold> and owner keys to [<owner_key>...] on behalf of <src> with signatures [<signature>...]

Generic:

tezos-client prepare baker transaction on <bkr> calling generic lambda <lambda>
tezos-client sign baker transaction on <bkr> calling generic lambda <lambda> with key <owner_key>
tezos-client call generic multisig baker <bkr> with lambda <lambda> on behalf of <src> with signatures [<signature>...]

Arguments:

<bkr>: baker_hash or its alias
<src>: a contract that pays for the call’s fees
<owner_key>: baker owner key that has to match one of the public keys set in baker script’s storage to authorize the call by verifying its signature
<threshold>: a minimum number of signatures required
<key>: public key
<proposal>: the protocol hash proposal to vote for
<yays_per_roll>: number of yays per roll (total number of yays/nays/passes must be equal to 100)
<nays_per_roll>: number of nays per roll (total number of yays/nays/passes must be equal to 100)
<passes_per_roll>: number of passes per roll (yays, nays and passes must add up to 100)

The commands works with the counter in the baker’s script storage to prevent replay attacks and construct signed payload that verifies ownership if the signing owner key(s) matches the one(s) in script’s storage.

Toggle delegations

Related article: Delegation toggle.

A baker operation to toggle accepting new delegations and a Michelson instruction to submit this operation is available. When a baker account toggles delegations off, any new delegations to the baker will fail. Any existing delegations may still be withdrawn. When the toggle is on, any new delegations will be automatically accepted.

Vote overrides

Related article: Governance improvements.

A new manager operation for vote override is added, which allows delegated implicit accounts that have at least one roll worth of tokens (ꜩ8000) to vote on protocol upgrades. The voting power for implicit accounts works in a similar fashion to bakers’ voting power, i.e. at the beginning of each voting period, every delegated implicit account that owns one roll or more has its stake in number of rolls stored in a list called the delegators voting listings. In addition to the number of rolls, the delegate of the account whose vote may be overriden is also persisted for the duration of a voting period.

When a vote override is submitted, the delegator’s full rolls will not be counted towards the delegate’s voting power, instead its weight will count towards the delegator’s own ballot. Any change that is less than a roll cannot be overriden and will still contribute to delegate’s voting power.

To submit a vote override ballot, the follow command is available:

submit override ballot for <src> <proposal> <yays_per_roll> <nays_per_roll> <passes_per_roll>

Baker reactivation

Because baker accounts are no longer internally self-delegated, one can no longer reactivate an inactive baker account with the baker registration or self-delegation command. Instead, a baker account may be reactivated via the baker script with the commands given above.

PVSS key

Baking accounts have the ability to set their public PVSS key. Although PVSS is currently not being used in the protocol, it is planned to be used in a future protocol upgrade for randomness generation. For now, this feature can be safely ignored.

Michelson

Michelson types related to baker accounts:

baker_hash - the b58check hash of the baker account (prefixed “SG1”)
pvss_key - PVSS public key
baker_operations - baker operations are internal, they may only be submitted from a baker script

Michelson instructions to submit supported baker operations:

SUBMIT_PROPOSALS :: list string : 'S -> baker_operation : 'S
SUBMIT_BALLOT :: string : nat : nat : nat : 'S -> baker_operation : 'S
SET_BAKER_ACTIVE :: bool : 'S -> baker_operation : 'S
TOGGLE_BAKER_DELEGATIONS :: bool : 'S -> baker_operation : 'S
SET_BAKER_CONSENSUS_KEY :: key : 'S -> baker_operation : 'S
SET_BAKER_PVSS_KEY :: pvss_key : 'S -> baker_operation : 'S

Summary & final remarks

The Astrolabe test network is a Tezos test network developed, launched, and maintained by Metastate. The purpose of the Astrolabe test network is to facilitate developer quality assurance, as well as early and public testing on features that have been implemented by our team. It is important to note that, at the time of writing, features available on the Astrolabe test network have not been included and are not guaranteed to be included in an upcoming Tezos protocol proposal.

The Astrolabe test network was launched on Friday, the 4th of December 2020. More precisely, its first block (activation) happened on 2020-12-04T13:52:08Z GTM. To this date, the test network continues to run stably and no issues have been found.

More resources

Metastate’s Tezos chronicle website
Multi-Asset Shielded Pool Integration on Tezos
MASP Project

Image credits: Astrolabe - By Yann Gwilhoù.

Metastate has ceased its activities on the 31st of January 2021. The team members have joined a new company and working on a new project. If you're interested in distributed systems research and engineering and systems engineering in Rust, checkout the open positions at Heliax.

If you have any feedback or questions on this article, please do not hesitate to contact us: hello@heliax.dev.