Today we are announcing a blockchain update that will require no adjustments for node operators.
The launch of a blockchain is a monumental task, and minor issues were encountered. This update will allow us to fix many of these issues – preparing the network for the next step.
The most pressing issue, especially for node operators accepted in Tranche 4, is that it takes 28 days to set a cMix ID on-chain if one is already nominating. This update will remove that restriction in the event that a cMix ID is not already set. With the Tranche 4 selection announcement coming out today, this will be very important for node operators.
This update also allows the team to fix some bugs in vesting schedules. The details are complex, and can be found below. But in general, some vesting schedules for both BetaNet Staking and newly purchased coins were improperly configured by the team. This update allows us to ensure that all coin holders have the same schedules and are playing by the same rules. These changes all require unanimous approval from the tech committee, and the tech committee will release the proposed changes with a minimum of 1 week of public comment before enactment.
Once the necessary fixes are made, a further update will be put forward which removes this ability. This will occur no later than the end of January.
The team introduced the trading freeze in order to ensure that during the hectic initial growing stages of the network, there is the leeway to solve issues like this. We anticipate that this is one of, if not the, last barrier to unlocking trading on the platform. This is why there has been no clear guidance on its ending – it is a buffer to help us solve launch issues, which are inherently unpredictable.
This runtime update will be put to Democracy tomorrow (1/5/2022) and will be up for voting for 1 week. If accepted, it will take effect on 1/12/2022.
As with other updates, please keep the discussion to the MainNet Forum in order to keep it tractable.
You can read the complete change logs and notes here: Release xx network v0.2.1 · xx-labs/xxchain · GitHub
Changelog:
-
Add set_cmix_id Call to Staking pallet. e3677d7
-
Migration to fix community Sale distribution vesting schedules. 168d503, 8e4a0cb
-
Add set_vesting Call to Claims pallet. 12b14db, aa51c3a
-
Add admin_set_vesting Call to the Vesting pallet. 61bd930, 5733619
-
Remove duplicate balance deposit event. b07d9f5
Add set_cmix_id Call to Staking pallet
Issue
There are multiple node operators from BetaNet which are actively nominating in MainNet, while maintaining their nodes in CanaryNet. Now, they have applied to tranche 4 of the transition program, and, if accepted, they will need to set a fresh MainNet cmix id on their stash account, otherwise they can’t become active validators. This is currently not possible and would result in many operators needing to fully unbond and wait 28 eras (days) in order to join the network.
Solution
The implementation of a new set_cmix_id Call allows stash accounts that don’t have a cmix id to set one without needing to unbond and wait 28 eras. However, if a stash account already has a cmix id it still can’t change it using this Call and needs to fully unbond. This means that node operators still need to take special care when first setting their cmix id and ensuring the cmix private keys and certificates are properly backed up.
Migration to fix community Sale distribution vesting schedules
Issue
In the latest community Sale, distributions are made directly in native xx coins using the XXPublic pallet, which holds coins allocated for sales. The team handles the distributions by calling a function on this pallet with a list of coin transfers, each with a destination, amount and vesting schedule. Due to an administrative error, the vesting schedule used in these transfers is incorrect: coins are being locked with a 1 year linear vest starting from 14 days after MainNet launch (end of the sale), when they should be in a 1 year lock instead.
Solution
We have implemented custom migration logic, that modifies the affected vesting schedules directly from on-chain storage, and that is executed with the runtime upgrade. The incorrect vesting schedules are deterministic, since they all have the same starting block of 201600 and are uniquely identified, since there aren’t any other schedules with this starting block. This way, the migration simply reads all the Vesting storage, loops through all vesting schedules per account, and if the starting block matches the target one, modifies that schedule to the format (lock, lock, new_starting_block), where new_starting_block is 14+365 days, i.e., 5457600. This migration has been tested against MainNet using the try-runtime feature offered by Substrate.
Add set_vesting Call to Claims pallet
Issue
When the Betanet Staking Rewards program was accepted and enacted, all the existing claims were automatically assigned the default 6 month vesting option, with the reward value being added to the claim value, and the 6 month linear vesting schedule added. However, due to a bug in this part of the logic, the principal value used to calculate the vesting lock was already increased by the reward amount. This resulted in a vesting schedule being applied to 0.8*(principal+reward)+reward = 0.8principal + 1.8reward instead of 0.8*principal + reward. This bug affects all the existing claims at the time of the enactment of the program (block 432000).
Solution
In order to fix the incorrect vesting schedules, a temporary set_vesting Call was added to the Claims pallet, that will allow the team to directly modify the vesting of leftover claims. The data for each vesting schedule correction will be publicly posted by the team in a newer version of the genesis block spreadsheet, which will allow everyone to audit the changes before they are made. Once the vesting schedules are fixed, the set_vesting Call will be removed from the Claims pallet in a future runtime upgrade.
Add admin_set_vesting Call to Vesting pallet
Issue
While investigating the previous issue, it became apparent that the logic for vesting schedules computation in Betanet Staking Rewards is incorrect for some situations, where existing locks on coins end while the rewards vesting period is ongoing. This creates an unfair advantage to some accounts that can have their rewards and the required principal vest faster than expected. Furthermore, any leftover claims that are claimed after the enactment of the program (block 432000) and before the above fix is applied, will still have the incorrect vesting schedule present in the xx network account that was funded by the claim.
Solution
In order to fix all incorrect vesting schedules, a temporary admin_set_vesting Call was added to the Vesting pallet, that will allow the team to directly modify Vesting storage. As with the solution above, the data for any vesting schedule fixes will be posted in a spreadsheet for auditing by the community. Once all vesting schedules in the system are fixed, the admin_set_vesting` Call will be removed from the Vesting pallet in a future runtime upgrade.
Remove duplicate balance deposit event
Issue
Whenever an extrinsic is executed, 20% of the fee is deposited into the account of the block author. This logic is implemented at the top-level of the Runtime, and it includes a Deposit event. A substrate change in paritytech/substrate#9425 added missing Deposit and Withdraw events to the Balances pallet, which results in the aforementioned Deposit event for extrinsic fees being duplicate.
Solution
The Deposit event was removed from the Author OnUnbalanced implementation that handles extrinsic fees.