Releases: xxfoundation/xxchain
xx network v0.2.6
This is xx network release v0.2.6.
This release will be paired with an on-chain runtime upgrade to new runtime version 206.
Previous releases v0.2.5-1
and v0.2.5-2
already included multiple client-side changes and an updated native runtime.
This release finalizes all changes to runtime 206.
This release was built and tested using rustc 1.68.2 (9eb3afe9e 2023-03-27)
.
Upgrade Notes
Upgrade is not mandatory but it is recommended. Unless you are still on version v0.2.5
or earlier, please read the following warning.
The new runtime 206 requires host functions that were introduced in release v0.2.5-1
. This means that once the runtime gets activated on-chain, chain binaries with version v0.2.5
or older will panic and crash. Please update your binary if your version is not at least v0.2.5-1
.
Runtimes
Versions:
- xx network: 206
- canary: 200
Runtimes compiled using srtool v0.9.25 via Makefile target make build-xxnetwork-runtime.
Runtime information (using subwasm):
Running subwasm v0.18.0
ποΈ Runtime size: 1.044 MB (1,094,499 bytes)
π Compressed: Yes, 79.20%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-206 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x80d48a6d825f6684fb60bd21c1a4dd35ec9e00d945e81e555f722924d4a9030c
π³οΈ authorizeUpgrade hash: 0x8df0ddefdee87201c53e21bc65d7e0e84d5c07371afcc22596a9f556c2ee8ff5
#οΈβ£ Blake2-256 hash: 0xbbe3a2b6057f81eb3e00a7cc8cc1dc51116693ccf0bfc9e6cef1734ead1a3c80
π¦ IPFS: https://www.ipfs.io/ipfs/QmSt9rCHbn1Z7MFXsGc9CdjnQqpVSR6BanMZwxKe1Wsvod
Changes
Full Changelog:
- xxchain -> v0.2.5-2...v0.2.6
- substrate -> xxfoundation/substrate@xxchain-v0.2.5-2...xx-labs:substrate:xx-network-v0.2.6
Client
- Add TLS enabled bootnode addresses to genesis spec. af8d7fa
Runtime
- Multiple substrate upgrades (see full changelog above)
- Preserve all call indexes, in order to not increase transaction version, and keep ledger support xxfoundation/substrate@3bd797c, xxfoundation/substrate@1cf0f98
- pallet-democracy: Do not request the proposal when scheduling xxfoundation/substrate@1ce1bfb
- Migrations: 0c8db3e, 9b743e6, cc46aa8, b89175e
- Modify Treasury SpendOrigin 69c667c
- Fix benchmarks. Add new weights with production binary 4ce2904
- Add NFTs pallet πΌοΈ ff5893a
- Disable Uniques pallet 00fa6fa
- Enable bridge π 1dfc0a9
- Bridge adjustment migration 43cb5e9
xx network v0.2.5-2
This is xx network release v0.2.5-2.
This release includes new bootnode addresses using DNS in the JSON genesis spec.
It also includes latest client-side changes from Substrate, that fix some issues using multisig and other features in the web wallet.
Upgrade notes
Upgrade is MANDATORY, since the old bootnode addresses will be discontinued by the end of January 2023, so older versions of the binary won't be able to sync the blockchain.
Please upgrade your nodes as soon as possible.
Due to changes in behaviour of database type detection, starting a node can run into the following error: State Database error: Incompatible pruning modes
.
To avoid it start your node with the flag --state-pruning <PRUNING_MODE>
, using the PRUNING_MODE
mentioned in the error message.
Detailed instructions on how to do the upgrade can be found here: https://forum.xx.network/t/upgrade-procedure-for-xxnetwork-chain-v0-2-5-2-mandatory-upgrade/6889
Changes
Full Changelog: https://github.com/xx-labs/xxchain/compare/v0.2.5-1..v0.2.5-2
Client
- Update genesis spec to use new bootnodes with DNS 8bb22f8
This release was built and tested using rustc 1.66.0 (69f9c33d7 2022-12-12).
This binary also includes a native runtime 206 with some extra changes compare to last version (v0.2.5-1).
However, the on-chain xxnetwork runtime is staying the same at 205, as we are not recommending upgrading it on-chain for now.
Once that time comes, a release will be issued and it will contain changelogs for the major changes.
xx network v0.2.5-1
This is xx network release v0.2.5-1.
This release includes an important hotfix for a client-side crash on reporting a valid Grandpa equivocation.
Upgrade is mandatory, please upgrade your validators as soon as possible.
This release was built and tested using rustc 1.64.0 (a55dd71d5 2022-09-19).
Changes
Full Changelog: https://github.com/xx-labs/xxchain/compare/v0.2.5..v0.2.5-1
Client
- Fix creation of justification with equivocating precommits in commit xxfoundation/substrate@42655d2
There are multiple more changes in this binary from upgrading Substrate to the latest commits, which are not described due to the urgency of this release.
This binary also includes a native runtime 206 with many changes.
However, the xxnetwork runtime is staying the same at 205, as we will not be upgrading it on-chain for now. Once that time comes, a release will be issued and it will contain changelogs for the major changes.
xx network v0.2.5
This is xx network release v0.2.5.
This release includes runtime changes, as well as a small client-side change.
Upgrade is not mandatory, but is encouraged.
This release was built and tested using rustc 1.62.0 (a8314ef7d 2022-06-27)
.
Runtimes
Versions:
- xx network: 205
- canary: 200
Runtimes compiled using srtool v0.9.21 via Makefile target make build-xxnetwork-runtime.
Runtime information (using subwasm):
Running subwasm v0.18.0
ποΈ Runtime size: 0.762 MB (798,690 bytes)
π Compressed: Yes, 74.60%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-205 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x300728a40ab526498fb5be80f7139448856042c53ba350b6507efac8af2401f2
π³οΈ authorizeUpgrade hash: 0x60745d60c0aebb5ffcf698b340522143f2af789ef7a28e4f584c11d5f43234f8
#οΈβ£ Blake2-256 hash: 0x1c79f23eaa5e1a11c416310828c26aa540dd224e863ac2b76bb05056e017d296
π¦ IPFS: https://www.ipfs.io/ipfs/QmVFXGKUSJ1R7as3WfbJY4D1BY7rw429EQ3AWXj4mE9YzQ
Changes
Full Changelog: v0.2.4...v0.2.5
Client
- Remove disabled bootnodes from genesis block specification included in the binary. 482111b
Runtime
- Staking pallet fix: use
total_with_custody
when computing each nominator payout. xxfoundation/substrate@4329025
xx network v0.2.4
This is xx network release v0.2.4.
This release includes a client side refactor that reduces the size of the compiled release binary by 25%.
Upgrade is not mandatory, but is encouraged.
Runtimes
The phoenixx runtime was removed. The protonet runtime was renamed to canary.
Versions:
- xx network: 204
- canary: 200
Runtimes compiled using srtool v0.9.21 via Makefile target make build-xxnetwork-runtime
.
Runtime information (using subwasm):
Running subwasm v0.18.0
ποΈ Runtime size: 0.762 MB (798,616 bytes)
π Compressed: Yes, 74.59%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-204 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x11f42c25cdb3fd775d4a66bb36c1fc37f59e722f58f4246b38407fe4d9014a77
π³οΈ authorizeUpgrade hash: 0xaf1d297207f4b0c230e9d19c9b94b477b5e1b4399948b8adb0daa5d6ec5d9a6a
#οΈβ£ Blake2-256 hash: 0xec15386559dc91df7b58f0c974ec9ccd810a807801da430381bc164d047c69e4
π¦ IPFS: https://www.ipfs.io/ipfs/QmTueaSFRFKR3g2qjXkQBmKkKnQeS6SeeeWGiR9JjBUovm
Changes
Full Changelog: v0.2.3...v0.2.4
Client
- Fix compilation with rustc 1.61.0. xxfoundation/substrate@278a0f8, xxfoundation/substrate@290c18f, xxfoundation/substrate@ba78567, xxfoundation/substrate@adc6e7b, xxfoundation/substrate@f8471fa, 4b2cfe8
- Client side refactor. 7b1ad04, f7d1e0a, e4867e3, 961666f, 93eda91, f9646a5, 91ea0f6, f2007ae, 4e156a0, d5f4183
- Remove phoenixx runtime
- Rename protonet to canary
- Create runtime-common for all configuration values common to both runtimes
- Use features in order to reduce final size by removing canary runtime when compiling release binary
- Fix all tests and try-runtime compilation
Runtime
- Staking pallet changes adding Custody to Exposure struct and using it when computing reward payout. xxfoundation/substrate@2159f74
- Staking pallet migration to add a custody value of 0 to all existing Exposures. xxfoundation/substrate@0ba345b
- Bump runtime to 204 and include Staking pallet changes. 5ea73b5
xx network v0.2.3
This is xx network release v0.2.3.
This release includes only runtime changes, no client-side changes, so xxnetwork-chain upgrade is not strictly necessary.
Runtime versions:
xx network: 203
xx protonet: 200
phoenixx: 200
Runtime information (using subwasm):
subwasm info xxnetwork_runtime-203.compact.compressed.wasm
ποΈ Runtime size: 0.795 MB (833,115 bytes)
π Compressed: Yes, 74.36%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-203 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x092f5d2602817416b6a8cb567f2db88f7abb66f9cad3d94480afcf7d685a406c
π³οΈ authorizeUpgrade hash: 0x6ba81489caa2ec9fcd956eeb67cd673f6048ded1facb75f0cb8353e04bb98eca
#οΈβ£ Blake2-256 hash: 0x0b46a6f95890932e163c72e3722bc707d029545eb34b6daa24500d6595919c83
π¦ IPFS: https://www.ipfs.io/ipfs/QmWUZeyEYhinoQqxwAUQkFfmZug6MD6aK9vH9bHTfYrwWj
Runtime changes
Changelog:
- Allow calls to
Balances
pallet andVesting::vested_transfer
. 6f32766
xx network v0.2.2
This is xx network release v0.2.2.
This release includes only runtime changes, no client-side changes, so xxnetwork-chain upgrade is not strictly necessary.
Runtime versions:
xx network: 202
xx protonet: 200
phoenixx: 200
Runtime information (using subwasm):
subwasm info xxnetwork_runtime-202.compact.compressed.wasm
ποΈ Runtime size: 0.795 MB (833,655 bytes)
π Compressed: Yes, 74.34%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-202 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0xe94286ea4a6c606ed5e6531a0eca2713fab3c7a8806eaab49a204bc3a11c82ae
π³οΈ authorizeUpgrade hash: 0xfaf1744ec22a9e721e53b78bb162d512f17f75fc0883f95406e5fd6f57218515
#οΈβ£ Blake2-256 hash: 0x7731f60a91dfb7f15bbf759dde9ada39956dab7c321d4717fe988fc37e8ac67b
π¦ IPFS: https://www.ipfs.io/ipfs/QmS3ZjGZP4prQczjkZpap9ihTdu8zypon8xiHHaSqLNCRV
Runtime changes
Changelog:
- Remove
set_vesting
Call from theClaims
pallet. 308ecf9 - Remove
admin_set_vesting
Call from theVesting
pallet. adf6d46, 63a7de3 - Remove migration to fix community Sale distribution vesting schedules. 226e3d0
- Use free balance rather than total balance for elections phragmen. 2f0aca8
- Add
transfer_cmix_id
Call to theStaking
pallet. 63ee4a5, 373e0d6, 63b8a0b, bc444bf - Ensure min validator commission when election happens off-chain. f2c37a3, b253bb0
Remove admin vesting Calls and sale fix migration
Issue
After fixing all incorrect vesting schedules, the privileged functions and migration are not necessary anymore.
Solution
Remove the set_vesting
Call from the Claims
pallet, the admin_set_vesting
Call from the Vesting
pallet and the migration that fixed community sale.
Use free balance rather than total balance for elections phragmen
Issue
When voting for Council members, if the user specifies the whole account balance, a lock is placed on coins that get reserved to vote, resulting in a negative transferable balance.
Solution
Use the account's free_balance
instead of total_balance
when calculating the amount to vote with. This will correctly exclude the reserved coins.
Add transfer_cmix_id
Call to the Staking
pallet
Issue
For node operators that are part of the Mainnet Transition Program, currently the team multiplier is applied only to the coins staked by the validator wallet. This can cause lower returns on staked coins, if a validator is over-nominated. In order to fix this issue, the team multiplier will count coins staked on the validator wallet and an extra nominator wallet. However, for node operators to be able to take advantage of this new system, the majority of their coins should be in the nominator wallet. The only way to do this is to unbond, wait 28 days and then transfer the coins to a new wallet. Furthermore, a new node with a new cmix id needs to be launched from the new wallet.
Solution
The implementation of a new transfer_cmix_id
Call allows node operators to transfer their cmix id between two stash accounts. Since having a cmix id is a requirement for any wallet to validate, it can only be transferred when the validator is out of the elected validator set. Using this new Call, node operators will be able to transfer their validator between two accounts, with only a single era of downtime, without needing to unbond any staked coins, or launch a new node from scratch.
Ensure min validator commission when election happens off-chain
Issue
When there are more wallets intending to validate than the size of the validator set, the Staking phragmen election is processed off-chain. Part of this procedure is a snapshot of validators and nominators that is taken midway through the second session of each era. Then, the election results are processed at the end of the second session. If a wallet stops validating after the snapshot is taken, it can still be elected, and it will have a commission of 0%, which doesn't respect the minimum validator commission that is configured by the Staking pallet. This issue can also occur if a validator is offline for the whole of the second session, being auto-chilled at the end of the session, before the election results are processed.
Solution
When processing election results and getting validator preferences, if commission is zero, set it to the minimum allowed commission.
xx network v0.2.1
This is xx network release v0.2.1.
This release includes only runtime changes, no client-side changes, so xxnetwork-chain upgrade is not strictly necessary.
Runtime versions:
- xx network: 201
- xx protonet: 200
- phoenixx: 200
Runtime information (using subwasm):
subwasm info xxnetwork_runtime-201.compact.compressed.wasm
ποΈ Runtime size: 0.796 MB (834,667 bytes)
π Compressed: Yes, 74.32%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-201 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x76cca0d527479a1c711f23dd437854207f7f33797494445c53997f822443a311
π³οΈ authorizeUpgrade hash: 0x07e07fbe214db26d11ea864400f633e421fe8a7864e4fa36663b77208291530a
#οΈβ£ Blake2-256 hash: 0xf93192d5b27666920333c0e6b4195e2807c807568d91ee2220d074e86ebf6867
π¦ IPFS: https://www.ipfs.io/ipfs/QmUj51NjLNRDo6qvYiwbu5mJv9XM89se3Jm3VwYcF72Ufs
Runtime changes
Changelog:
- Add
set_cmix_id
Call to theStaking
pallet. e3677d7 - Migration to fix community Sale distribution vesting schedules. 168d503, 8e4a0cb
- Add
set_vesting
Call to theClaims
pallet. 12b14db, aa51c3a - Add
admin_set_vesting
Call to theVesting
pallet. 61bd930, 5733619 - Remove duplicate balance deposit event. b07d9f5
Add set_cmix_id
Call to the 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 administration 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 the Claims
pallet
Issue
When the Betanet Staking Rewards program was accepted and enacted, all the existing claims were automatically applied 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.8*principal + 1.8*reward
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 the 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 end 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.
xx network mainnet launch
This is the xx network mainnet release!
xxnetwork-chain v0.2.0
xxnetwork runtime - 200
genesis block hash: 0x50dd5d206917bf10502c68fb4d18a59fc8aa31586f4e8856b493e43544aa82aa
subwasm info xxnetwork_runtime.compact.compressed.wasm ξ² 1.34 ο ξ³ β ξ³ οΊ 23:08 ο³ 06.12.21 ο
ποΈ Runtime size: 0.792 MB (830,471 bytes)
π Compressed: Yes, 74.20%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V14
π₯ Core version: xxnetwork-200 (xxlabs-xxnetwork-0.tx1.au0)
π³οΈ system.setCode hash: 0x240841b5c742e867c499eedadab9a802992846a405f97669de3b755ee0b17ca6
π³οΈ authorizeUpgrade hash: 0xd2420503108df21128170e9c84ed172848db9b05bb882edbf3791755e519efff
#οΈβ£ Blake2-256 hash: 0xc08900c106463e7e698287aee0ba3c0b6d0bf62058ab7dcf5d5189a244858b27
π¦ IPFS: https://www.ipfs.io/ipfs/QmReq1LuSgBCCVxqvuJ1Kg9XeJrmKtXSd3rDJ7AD8b5a6D
xx protonet v0.1.2
xxnetwork-chain v0.1.2
New protonet runtime 102.
The new runtime includes the following changes:
Staking pallet: v3.0.0 -> v3.1.0
- Added
chill_other
extrinsic that allows removing validators that no longer meet the minimum validator bond, when it gets increased. - Fix the logic of
validate
to allow existing validators to modify their commission without needing to stop first.
XXNetwork pallet: v0.1.0 -> v0.1.1
- Fix custody payout to always empty Custody and Reserve accounts at the end of the custody period. This prevents any funds sent to these accounts from getting stuck forever.
- Fix
TotalCustody
underflow when paying out extra custody funds. If an account has extra funds, theTotalCustody
value might reach 0 before desired.
protonet runtime: v0.1.0 -> v0.1.2
- Increase custody period from 45 days to 3 years. This allows continued testing for the team multiplier in protonet.
- Bump spec version to 102.
Runtime info (using subwasm):
subwasm info protonet_runtime-120.compact.compressed.wasm
ποΈ Runtime size: 0.647 MB (678,599 bytes)
π Compressed: Yes, 70.71%
β¨ Reserved meta: OK - [6D, 65, 74, 61]
π Metadata version: V13
π₯ Core version: protonet-102 (xxlabs-protonet-0.tx1.au0)
π³οΈ system.setCode hash: 0x7b603ffbe473aec7e418a1ab98b9d68d2b6da7da5930f13c01431a136711173e
π³οΈ authorizeUpgrade hash: 0x27c8dae1523bad03ac9213f765fc96d7bab2ed007b7b932ac52c8c1e60c7f4eb
#οΈβ£ Blake2-256 hash: 0x6f5faff167ad338b4eb8fba86f32944027b54919d7781fafd790fdfa62642af7
π¦ IPFS: https://www.ipfs.io/ipfs/QmZjagQEU1h13xQ4DD3ZWMhuXFFASxnJAmbtDSqPnFENcH