Avalon v1.6.6

Update consisting of bug fixes and optimizations. Recommended for API nodes.

Optimizations

Total claimed rewards

claimedReward in accounts now tallies claimed rewards during CLAIM_REWARD execution so that obtaining total claimed rewards no longer iterates over every claimed vote made in the past.

Bug fixes

Content dist amount

Fixes an issue where the dist amount on contents exceeds the tally of all curation rewards for the votes as it did not take burns as a result of opposite votes into account.

Reindexing

A rebuild is required when upgrading from the previous release to reflect the above changes.

Avalon v1.6.5

Important update consisting of bug fixes.

Bug fixes

Block dist/burn amount validation

Fixed missing block dist/burn amount pre-validation that caused nodes to crash during last minute checks when the said invalid block gets accepted.

Others

Node v18 support

NodeJS v18 LTS is now supported in this release.

Reindexing

A rebuild is not required when upgrading from the previous release.

Avalon v1.6.4

Update consisting of performance optimizations at runtime and rebuild, resulting in 260% better rebuild performance. Recommended upgrade for all nodes.

Optimizations

Redundant GrowInt update

A redundant GrowInt update in chain.leaderRewards() has been removed so that the cache.updateOne() method will only be called once for the leader.

Redundant cloneDeep() method calls

The computationally expensive cloneDeep() method call have been skipped during rebuild in cache.updateOne() method, and eliminated in chain.generateLeaders() method.

In addition, the following methods calling cache.findOne() will skip the cloneDeep() method call:

• cache.updateOne()
• cache.addLeader()
• chain.leaderRewards()

As a result, cloneDeep() will only be called once during normal sync and will never be called during a rebuild, as compared to twice in the previous release.

Reindexing

A rebuild is not required when upgrading from the previous release.

Avalon v1.6.3

Update consisting of bug fixes. Optional upgrade for all nodes.

Bug fixes

Replay attempts

Reduced replay attempts to 25 which should be sufficient to successfully replay a valid block from p2p.

Validations

Improved balance validation in small number of operations.

Reindexing

A rebuild is not required when upgrading from the previous release.

Avalon v1.6.2

Update consisting of important bug fixes. Recommended for all nodes.

Bug fixes

Collision logging

To prevent logging spam, any block collisions are only logged once upon finalization of a block.

Rankings fixes

Fixed contents JSON metadata in rankings not being updated when updating one using the COMMENT_EDIT operation.

Account proposal votes

Fixed an issue where some votes get prematurely removed from the account proposalVotes array before they actually expire.

Reindexing

A rebuild is required when upgrading from the previous release. A pre-HF6 state from the previous release may be used to resume the rebuild with this release.

Avalon v1.6.1

Non-consensus update consisting of minor API changes and bug fixes. Optional upgrade for all nodes.

API changes

/allminers API

The /allminers API response now includes relevant leader stats when available.

Bug fixes

P2P sync improvements

Rather than halting sync upon encountering a bad block from a peer, attempts will be made to re-fetch the same block from another random peer to continue syncing good blocks.

Reindexing

A rebuild is not required when upgrading from the previous release.

Avalon v1.6

This is the 6th hardfork codenamed "Space Odyssey" on the main network, scheduled to execute at mainnet block 17,150,000.

Main Changes

Unset Signature Threshold

HF4 introduced multisig accounts on Avalon, however an operation was missing to unset signature thresholds for specific operations. The transaction type UNSET_SIG_THRESHOLD (type 23) has been added to complete the implementation of Avalon multisig accounts.

This transaction type contains one field named types which is an array of transaction types to unset signature threshold of. Once unset, the threshold will fall back to the default values.

Account creation with bandwidth

A new transaction type NEW_ACCOUNT_WITH_BW (type 24) allows the account creator to create accounts with starting bandwidth supplied by the account creator. This should make onboarding even easier as the newly created account with preloaded bandwidth can be used immediately without having to wait for bandwidth to recharge at base bandwidth growth rates.

Operation is the same as NEW_ACCOUNT with an additional field bw which is an integer to specify the bandwidth (in bytes) to supply the new account with.

Playlists

Enables the creation of ordered sequences of content IDs, which can be used for video playlists, HLS livestreams etc. The new transaction types to be used to interact with playlists are:

PLAYLIST_JSON (type 25)

Instantiates a new playlist with JSON metadata or update the JSON metadata of an existing one. Fields are link (string) and json (json object). link field is the unique playlist identifier specific to individual accounts and may not be confused with content permlink. json is the JSON object containing the playlist metadata.

PLAYLIST_PUSH (type 26)

Pushes new items to the playlist. Fields are link (string) and seq (array of two-element arrays). link field is the unique playlist identifier, whereas seq is an array that consists of two-element arrays containing the sequence ID (integers) to push the playlist item to followed by the playlist item itself, which is a string. For example:

[
    [100, "author/Qmabcdef"],
    [200, "author/Qmghijklm"],
    [300, "author2/Qm123abc"]
]

If a sequence ID is repeated, the last repeated item will be used.

PLAYLIST_POP (type 27)

Pops items from the playlist by sequence ID. Fields are link (string) and seq (array of integers). link field is the unique playlist identifier, whereas seq is an array of integers of sequence IDs to be popped from the playlist.

For example, to remove items with sequence IDs 50, 200, 230 from the playlist if exists, the seq field would be:

[50, 200, 230]

If the specified sequence ID(s) does not exist in the playlist already, the non-existent sequence ID is skipped.

Comment Edit

A more resource efficient transaction COMMENT_EDIT (type 28) to edit the JSON metadata of an existing content. Fields are link (string) which is the permlink of the existing content to be edited, and json which is the new JSON metadata to be updated with.

Account Auths

Allows an account to authorize another account to sign transactions on its behalf by custom key ID. Relevant operations:

ACCOUNT_AUTHORIZE (type 29)

Authorizes an account to sign transactions with the authorized account's custom key by ID. Fields are:

• user (accountName): the authorized account name
• id (string): the authorized custom key ID belonging to the authorized account
• types (array of integers): the array of transaction types that are authorized
• weight (integer): the weight of the account auth, just like a weighted custom key

ACCOUNT_REVOKE (type 30)

Revokes an account auth created previously with ACCOUNT_AUTHORIZE. Fields are (same as specified in ACCOUNT_AUTHORIZE):

• user (accountName): the authorized account name
• id (string): the authorized custom key ID belonging to the authorized account

For example, @alice has a custom key of ID foo and @bob wishes @alice to be able to sign transactions of type 7 and 8 on his behalf using the foo custom key. @bob would do an ACCOUNT_AUTHORIZE with the following payload:

{
    "user": "alice",
    "id": "foo",
    "types": [7, 8],
    "weight": 1
}

At any time, this permission may be revoked by @bob with ACCOUNT_REVOKE operation, with the following payload:

{
    "user": "alice",
    "id": "foo"
}

The allowed types and weight of the foo custom key belonging to @alice does not matter for this account auth.

Clear balances of @dtube.airdrop account

The unclaimed airdrops currently in @dtube.airdrop account has been periodically burning since the activation of HF4. As the account has been nulled, the account will be marked as blackhole and all balances will be removed when executing HF6 to remove any supply hangover.

Avalon DAO

The new governance system on Avalon which enables anyone to propose new ideas to be funded by the community and suggest any changes to blockchain parameters. It also forms the DAO membership consisting of active leaders and additional members specified in config.daoMembers array where members review proposals at certain stages and controls the @dtube master account.

Governance

The area to create proposals. There are two types of proposals, which are fund requests and chain updates. For more information on how each of them works, please review the proposal creation forms for fund requests and chain updates.

The proposal creation fee for fund requests consists of a base fee, in addition to subsequent fees for requested amount exceeding a certain amount. On the other hand, chain update proposals have a flat fee for proposal creation, all of which are refunded to the proposal creator upon successful completion/execution of the proposal, or burned if the proposal does not complete successfully.

Each proposal is identified by an incremental integer ID which is unique across the blockchain.

MasterDAO

DAO members may queue an operation which is allowed in config.masterDaoTxs to be executed by the master account's behalf. Each MasterDAO operation must be approved by at least 2/3 of all members in the DAO, and is identified by an incremental integer ID which is unique across the blockchain.

The MasterDAO may fund up to 50% of the requested amount in fund request proposals.

As @dtube will be used as the MasterDAO controller account, the leader will be programatically disabled upon hardfork execution and the ENABLE_NODE operation will be disallowed for the account going forward.

New Operations

FUND_REQUEST_CREATE (type 31)

Creates a fund request proposal. Fields are:

• title (string): Proposal title
• description (string): Proposal description
• url (string): Proposal URL (usually link to a DTube video)
• requested (asset): Requested funding in DTUBE
• receiver (accountName): Beneficiary of the fund request

FUND_REQUEST_CONTRIB (type 32)

Funds a fund request proposal during its funding period. Fields are:

• id (integer): The fund request proposal ID to fund
• amount (asset): Amount in DTUBE to fund

FUND_REQUEST_WORK (type 33)

Submit work JSON details to be reviewed by DAO members. Fields are:

• id (integer): The fund request proposal ID to submit work of
• work (json): The JSON details of the work completed for the fund request to be reviewed

FUND_REQUEST_WORK_REVIEW (type 34)

Submit a review of the work submitted by the proposal creator using the above operation. Fields are:

• id (integer): The fund request proposal ID to review submitted work of
• approve (boolean): Signal approval/disapproval of the work submitted
• memo (string): Some memo to be attached with the review

PROPOSAL_VOTE (type 35)

Votes for a proposal with DTUBE in its voting period. Fields are:

• id (integer): The proposal ID to vote on
• amount (asset): Amount to vote with. Negative amount signals NO vote and positive amount signals YES vote.

The amount used to vote for proposals will be locked until the voting period ends. The same locked coins may be used to vote for as many available proposals in their respective voting periods as possible.

PROPOSAL_EDIT (type 36)

Edits the proposal details while it is active. Fields are:

• id (integer): The proposal ID to edit details of
• title (string): Updated proposal title
• description (string): Updated proposal description
• url (string): Updated proposal URL (usually link to a DTube video)

CHAIN_UPDATE_CREATE (type 37)

Creates a chain update proposal. Fields are:

• title (string): Proposal title
• description (string): Proposal description
• url (string): Proposal URL (usually link to a DTube video)
• changes (array of array): Array of two-element arrays consisting of parameter to be updated and the new parameter value.

For example, to update rewardPoolAmount to 70000 and masterFee to 19, the following array will be the value of changes field:

[
    ["rewardPoolAmount", 70000],
    ["masterFee", 19]
]

MD_QUEUE (type 38)

Queues a new MasterDAO operation. Fields are:

• txtype (integer): The transaction type to be queued.
• payload (json): The transaction payload of the queued operation, which is the tx.data part of the transaction.

For example, to create a playlist on behalf of the master account, this would be the transaction to be hashed and signed:

{
    "type": 38,
    "data": {
        "txtype": 25,
        "payload": {
            "link": "official-playlist...

Avalon v1.5.2

Mainly non-consensus update containing performance and memory optimizations for node operation. Also contains most HF6 code but with the relevant config commented out so that it does not activate in this release. Recommended for all nodes.

New features

API documentation generator

A static webpage documenting Avalon API endpoints may be generated by running npm run apidoc. The output may be found in the apidoc folder which can be served as a static website. Such website has been made available at https://avalon.oneloved.tube.

Skip validations on rebuild

If you know what you are doing, you can skip all validations to speed up rebuilds by specifying REBUILD_NO_VALIDATE=1 env var. Such rebuild would only execute block transactions.

Blocks BSON indexer and appender

To optimize MongoDB memory usage and improve indexing efficiency, the blockchain data has been taken out of the database and would instead read and append to/from the blocks.bson file. For more info and upgrade instructions, please refer to the v1.5.2 upgrade doc.

Breaking changes

Transaction history indexing

Due to the changes required to take the blockchain data off the mongo database, a new env var TX_HISTORY has been introduced to allow indexing of transaction history separately, which is also more efficient than previous versions.

In addition, TX_HISTORY_ACCOUNTS may be specified to only index a comma-separated list of relevant accounts.

For example:

export TX_HISTORY=1
export TX_HISTORY_ACCOUNTS=ionomy,ionomycold

/history API

Due to the above changes, the /history API will now return an array of transactions in the same format as /tx, instead of an array of blocks containing the relevant transactions.

Support discontinuation of NodeJS v12 or below

Due to the new dependencies used in this update, NodeJS v12 or below will no longer work on this release. NodeJS v14 and v16 remains the supported versions.

Other changes

Removal of REBUILD_RESUME_BLK

The env var REBUILD_RESUME_BLK has been removed so that rebuilds can resume by reading the head state block number from the state collection in the database.

Reindexing

A rebuild is only required for nodes that require the use of /tx and /history APIs. Otherwise, following the upgrade instructions should suffice.

Avalon v1.5.1

Non-consensus update containing bug fixes and improvements. Recommended for public API nodes.

API changes

Content filtering (#66, #76)

Additional options has been added to /new, /hot, /trending, /content, /feed and /blog methods to allow filtering with tags, usernames, limits and timestamps. For more info on usage details, please see PR #87 and #92.

Leader age info (#90)

LEADER_STATS module now records the block number and timestamp of each leaders' first block mined so that such info may be retrieved with /rank/leaders and /leader/:account. Useful for determining leader age and starting point in the blockchain in which a leader starts producing blocks.

Bug fixes

API error handling (#83)

Fixed /feed/:username/:author/:link and /history error handling that caused Avalon to crashed when not handled properly.

Negative claimable reward failsafe

A negative claimable reward is caused by either precision errors with 100% author tips or when the gross curation payout decreases due to opposite votes made thereafter such that it is lower than totalTip when the author vote is claimed, resulting in a reward debt. The fix would set all claimable rewards to 0 if gross - totalTip is negative as any attempt to claim rewards less than 0.01 DTUBE will fail.

Reindexing

A rebuild is only required for nodes with LEADER_STATS module enabled or to resolve negative claimable rewards in existing state. Claimable rewards on all votes for a content re-compute on new incoming votes hence it will not cause any inconsistency issues with reward payouts.

Avalon v1.5

This is a hotfix for v1.4 on the main network which resolves the issue that the master account check being ignored when assigning the pre-loaded resources on account creation. Scheduled to execute at block 8,595,000.

Reindexing

A rebuild is not required when upgrading from v1.4 before block 8,595,000. However, it is required if not updated on-time as the state-breaking issue continue to persist on v1.4.