Make implicit accounts delegatable
Implicit accounts (tz1, tz2, tz3) can directly set their delegate. Furthermore implicit accounts have the ability to delete their delegate by sending a "delegate" transaction with an empty delegate field. This change does not impact the ability for originated (KT1) accounts to set or delete their delegate.
The storage type of the "Delegated" accounts changes it's index from "Contract_hash" to "Contract_repr.Index". This change in the type signature allows that both implicit and originated accounts can be stored in the set.
Commit 148eabf8 changed the type of the key of the "Delegated" storage from "Contract_hash" to "Contract_repr.Index". The migration needs access to the previous type of the "Delegated" storage in order to read it from the context. For this reason the old types for the "Delegated" storage have been duplicated with the "_004" suffix. The "_004" types are only used during the migration.
During the migration all relevant originated contracts are cleared from the storage and the origination burn for their creation is refunded to their manager.
The migration folds over all existing contracts but only processes the originated contracts. Originated contracts that are not spendable or that have code are skipped. The remaining originated contracts are processed and their funds are returned to their manager contracts. When a single implicit account has multiple KT1 accounts that are delegated to different bakers the migration uses the randomness from the seed module in order to choose which baker to set as the delegate of the TZ1 account. Each baker will have a chance of being chosen proportionally to the size of the delegation of the KT1 account.
We have tested the migrations on
mainnet-staging as well as on
In both cases we applied a patch to
and added an artificial hardfork in
lib_client/block_header.ml in order to bake with
the real context. We started with the
003 context, upgraded it to
004 and then upgraded it to
The below benchmarks where taken a virtual machine on GCP with the data residing on an external SSD:
- n1-standard-4 (4 vCPUs, 15 GB memory)
- external SSD
|Sustained random IOPS limit||9,000.00||9,000.00|
|Sustained throughput limit (MB/s)||144.00||144.00|
- ~17 minutes to migrate from 003 to 004
- ~15 minutes to migrate from 004 to 005
- ~5 minutes to migrate from 003 to 004
- ~3 minutes to migrate from 004 to 005