HF4 "Harry Potter"

[techcoderx]

This is the 4th hardfork codenamed "Harry Potter" on the main network.

Main changes

Multi-signature accounts (#59)

3 new transaction types have been added to enable multi-signature setups on Avalon.

NEW_WEIGHTED_KEY (type 20)

Same as NEW_KEY but with an additional field weight (integer) to specify custom key weight. All custom keys that are not created using this operation have the default weight of 1.

SET_SIG_THRESHOLD (type 21)

Sets the required signature threshold for each transaction type (including a default threshold for all other types, if specified). This transaction type contains one field thresholds, a JSON object specifying the required threshold for the particular transaction type to be updated. For example:

{
    "default": 3,
    "3": 5,
    "17": 1
}

The default threshold for all transaction types for an account if never specified is 1.

SET_PASSWORD_WEIGHT (type 22)

Sets the weight of the master password that allows for all transaction types. This transaction type contains one field weight (integer), which is the new key weight of the master password. The default weight is 1 if it is never set by the account.

Transactions signed with multiple signatures use a new signature format, which is an array consisting of the base58 encoded signatures and their corresponding public key recovery ID.

[
    ["5edCvv5QtRUEQ3PxHTpxZmF7BBGkzbtUhRAwRk3U8XusVACTZ6FvHBFgwQGLPz7d9LVLPgeyxf4Bim1tJzFn25yg", 0],
    ["3QNZ9o9sW1n1YoqTbyYS87FJf3NEhMD1jnLL5cjPFCwB3HUq3LEA1o8CELpU7sH6vvKda5wU6HB2CUgKGUPjD5yG", 0],
    ["uAUU5pr4ntyUc7dAzard7SkzBa413EofkB9kdJFF4P5MyzQvwQVwD1DmfYKp7imphYZYUbtFtCro4QN1G5qaM5q", 1]
]

Preloaded resources for accounts created with burn (#55)

New accounts created after the hardfork with burn will include a small amount of VP and some base BW growth proportionate to the burn amount so that the newly created account can transact right away. The preloaded VP will be 50% of the VP per burn and the base BW growth will be set to 50% of the bwGrowth based on the burn amount. This does not include accounts created by @dtube or accounts created before the hardfork.

Periodic burn of unclaimed airdrops (#57)

As originally planned, 100% of the unclaimed airdrops will be burned. This hardfork will begin the periodic burn on the @dtube.airdrop account which will execute a burn event every config.ecoBlocks and will burn the total dist amount of the reward pool cycle.

1,456,279.83 DTUBE (~32% of the circulating supply) will be burned and removed from the circulating supply over approximately 647 days after hardfork activation date.

Disallow voting for leaders without a valid leader signing key

To begin the cleanup of the leader voting page that is filled with crossed-out accounts and to enforce voting for real active leaders, this hardfork will no longer allow voting for accounts without a valid leader_pub.

Limit custom keys to 25

Part of the fixes for #40, each account may only create up to 25 custom keys, which should be more than enough considering that there are only 23 transaction types so far. This may need to be increased as more transaction types are added.

Increased leader count

To allow more leaders to be able to produce blocks over time, the leader count has been increased from 13 to 15.

Other changes

Leader stats

Leader statistics from the now-depreciated extended API has been merged into the main Avalon repository and can be enabled with LEADER_STATS=1.

New APIs

/accountByKey/:pub - lookup accounts by public key
/distribution - retrieve wealth distribution of the DTUBE token
/leader/:account (merged from extended API) - retrieve details of one leader
/rank/:key (merged from extended API) - retreive chain rankings. :key may be balance, subs or leaders.
/tx/:hash (merged from extended API) - lookup transaction by hash

New option to restore from blocks.zip or unzipped mongo dump

When restoring blocks for rebuild, the option UNZIP_BLOCKS=1 may be specified to unzip the blocks.zip file before restoring blocks into the database. If not specified, the unzip process is skipped.

NodeJS v16 support

The latest v16 LTS release is now officially supported. It is likely that v10 will no longer be supported as the end-of-life as reached, so please update to the latest version.

Bug fixes

Chain ID match check on peer connection

Checks that all connected peers have a matching config.originHash to prevent different chains from talking to each other.

Improved node sync

• Fixed an issue causing Avalon to stop receiving blocks from the network when transitioning from p2p recover to live mode that is caused by Avalon requesting blocks from peers that is beyond the head block
• Checks connected peers every replay_interval and activates p2p recover mode when it detects substantial lag behind the network due to latency issues during live sync

Improved chain state disk writer

Implemented a writer queue to ensure that the mongo write batches are executed in the correct order. This fixes state inconsistency issues when the batches are executed in the wrong order due to slow execution as the later batch finishes execution first before the previous batch.

Distributed collection document fix

Fixed an issue in the CLAIM_REWARD transaction where the document in the distributed collection refers to the incorrect reward claimant.

Reindexing

A rebuild is recommended for non-public API nodes when upgrading from the previous release due to the chain state inconsistency that has been fixed in this release, and is strongly suggested for public API nodes due to the addition of new modules and non-consensus fixes.

Please express your approval or disapproval for this hardfork by a thumbs up (or down) so that we can merge this as soon as possible and notify the relevant exchanges to update their nodes. The hardfork will be set to activate in about 14 days (multiples of 195 blocks) from the time it gets approved and merged.

[techcoderx]

Thank you everyone for the review. We have exceeded the required 9 approvals required for hardfork execution and the required 10 for the chain to continue after the hardfork with the new leaders set. I'm merging this hardfork and setting this hardfork to execute at block 8,500,050 which is in ~14.5 days provided if no one misses blocks.

Chain state rebuild is recommended as mentioned above.