Meanwhile at Cryptium Labs #1 Part III
If you haven’t read them yet, here are links to Part I and Part II. In Part III, another feature we are working on is described: simplifying the delegation process and removing verbose on smart contracts.
This article has the following contents: it starts with a recap on the different types of accounts that Tezos supports. Secondly, we describe the typical delegation process that every Tezos delegator undergoes. Thirdly, we describe an implementation that simplifies the delegation process by enabling Tezos stakeholders to make delegations directly with their implicit accounts. This is followed by a description, with the help of diagrams, of the migration process and the clean-up of KT1 empty accounts. It ends with an overview of the implications of this feature for various stakeholders in the ecosystem.
Account Types on Tezos
Implicit and Originated Accounts
Implicit accounts are those identified by an address that starts with tz1, tz2, or tz3 depending on the curve. They are commonly referred as main accounts.
Originated accounts are those identified by an address that starts with KT1, they are commonly referred to as originations or delegations, but they are in fact smart contracts with the following parameters or properties:
The Delegation Process
Taking the current accounts system into consideration, whenever a Tezos stakeholder wishes to make a delegation to a baker, it requires a multi-step process that involves:
- Creation of an implicit account.
- One or multiple transactions that creates an originated account and sets the parameters.
- Another transaction to fund the originated account with the amount that the stakeholder wishes to delegate from an implicit account.
This process is common in most hardware, software and combination of both wallets that support Tezos delegations (view all how-to delegate guides).
Simplifying the Delegation Process and Removing Verbose in Tezos Smart Contracts
Step 1: Making Implicit Accounts Delegatable
This proposed implementation enables delegations directly from implicit accounts. This is done by allowing implicit accounts to set their delegate or baker. As usual, the code is open-source and available here: https://gitlab.com/nomadic-labs/tezos/merge_requests/43.
[DEPRECATED] Step 2: KT1 Clean-up
The migration process described below has been deprecated. The updated migration strategy is described in Meanwhile at Cryptium Labs #1 Part VI.
In addition to making implicit accounts delegatable, the migration process will perform the following steps:
- If the TZ1 account has only one KT1 account: Fold the funds of the KT1 account back to their manager TZ1 account and set the baker of the TZ1 account to the same one as in the initial delegation.
- If the TZ1 account has more than one originated account (each one with more than 0 XTZ in their balance): fold all the funds back to the TZ1 account and appoint the baker that is selected by staked-weighed randomness. The algorithm leverages the same random seed generator as the baking and endorsement slots assignment (see section The Random Baker Selection Algorithm).
- At the end of this process, all empty delegation accounts will be cleaned up.
- All origination fees that stakeholders burned in order to create the KT1 accounts will be refunded to the respective TZ1 accounts.
The migration code is also open-source and available here: https://gitlab.com/nomadic-labs/tezos/merge_requests/43.
The Random Baker Selection Algorithm
Although there have been other approaches to processing the case of implicit accounts with more than one active delegation, the random baker selection algorithm is preferred as it mitigates the likelihood of larger bakers being favoured over smaller bakers.
In 2) the baker, to which the implicit account will be appointed to, will be selected with the following algorithm. For illustration, let us consider the following scenario where a TZ1 account has generated delegations A, B, and C, which have different amounts (10, 90, 900) and different bakers (A, B, C). The algorithm will act as follows:
- Generate as many sets of values as initial delegations. In this example, it will create 3 sets: A : [0–9], B : [10–89], and C : [90–899], taking the amounts of each delegation into consideration.
- Read the number generated by the same RNG (random number generator) that assigns baking and endorsement slots (documentation). In this example the RNG returned the number 55.
- See in which of the sets the number falls into and select the baker accordingly. In this example, as the number 55 falls in set B as 55 ∈ [10–89], the implicit account (TZ1'), now delegatable, will be appointed to baker B with the entire amount.
Implications for Stakeholders
Delegators
The simplification of the delegation process does not change the Tezos economic model. Furthermore, it is implemented in a way that minimises the impact on the status quo of delegations as much as possible.
Stakeholders that have only one delegation per implicit account will not be affected by this change. The migration process will assign the funds from the KT1 account back to the TZ1 account, which will be delegated to the former baker.
Delegators that have originated more than one delegation from one implicit account and are actively delegating to more than one baker (all delegations have more than 0 XTZ), will have time to manage their multiple delegations. The migration process will assign the funds from all the delegations to the TZ1 account and delegate to one of the former bakers, as described in the previous section (The Random Baker Selection Algorithm).
Lastly, as indicated above, after the clean-up of empty KT1 accounts, all the origination fees will be refunded to the corresponding TZ1 account.
Client and Wallet Developers
With this simplification, Tezos client and wallet developers will have the ability to enable their users to make delegations directly with their implicit accounts and simplify the steps required for making delegations that originated accounts require. If client and wallet developers wish to, they can leverage this feature to create more seamless experiences for their users.
Decentralised Application Developers
By making implicit accounts delegatable and cleaning-up all the empty originated accounts, the original notion of KT1 accounts being smart contracts is recovered. This is due to smart contracts no longer carrying verbose logic nor required parameters for making a delegation.
Current and Future Core Developers
By cleaning-up all the empty originated account and bringing back the original notion of KT1 accounts being pure smart contracts, it will facilitate future implementations of protocol amendments, such as the implementation of zk-snarks and formal verification methods.
Final Remarks
In Part III, we describe another feature we are working on, which aims to simplify the delegation process and to remove verbose logic in Tezos smart contracts, caused by the current delegation process.
This feature, just like all other features, will be proposed in the upcoming Proposal period (end of May, beginning of June). Nevertheless, it must be voted by the community to be adopted. Should the proposal containing this feature be selected by the community, we will release documentation and guides to make the process as smooth as possible. For instance:
- A list of implicit accounts that have more than one originated account, balances of which are higher than 0 XTZ.
Acknowledgements
We would like to thank Nomadic Labs, Tocqueville Group, Arthur Breitman and others who have spent time in bouncing ideas, discussions, and have provided us feedback and reviews on code and writings.
What Next?
- Meanwhile at Cryptium Labs #1 Part IV: Same structure as Part III, but describing another interesting feature we have been working on.
- Reddit written AMA Q&A (21st May 2019, details TBA).
