Skip to content

Avalon v1.6
Compare
Choose a tag to compare
@techcoderx techcoderx released this 28 Jun 01:47
· 71 commits to master since this release
1.6
01c27a2
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

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-dao-1",
            "json": {
                "title": "Official Playlist 1",
                "desc": "A playlist by @dtube that is created by the MasterDAO controller."
            }
        }
    },
    "sender": "daomember123",
    "ts": 170123456789
}

MD_SIGN (type 39)

Approve a queued MasterDAO operation, provided the operation isn't expired. Fields are:

  • id (integer): The ID of the MasterDAO operation to approve

The queued operation will attempt to execute once it receives sufficient approvals before its expiration time.

Snapshots

A DAO member snapshot will be taken for every proposal creation and MasterDAO operation being queued. Leaders who are missing blocks will not be included in the snapshot.

New APIs

/dao: Get latest and next proposal IDs, active proposals
/dao/master: Get latest and next MasterDAO operation IDs
/dao/master/op/:id: Get MasterDAO operation by ID
/dao/master/ops/:status/:skip?: Paginated list of MasterDAO operations by status. :status may be queued, expired, executed or errored.
/proposal/:id: Get proposal by ID
/proposal/votes/:id/:approves?: Get proposal votes by ID, optionally filtered by approval/disapproval. :approves is a boolean true or false.
/proposal/votesByVoter/:voter/:approves?: Retrieve all proposal votes by voter, optionally filtered by approval/disapproval. :approves is a boolean true or false.
/playlist/:author/:link: Playlist by playlist author and link.

New modules

PLAYLIST_JSON: Indexes JSON content of playlists. Will be required for HLS stream APIs when it gets added in a later release.
DAO_VOTES: Indexes proposal votes. Required for /proposal/votes/:id/:approves? and /proposal/votesByVoter/:voter/:approves? APIs.

Reindexing

A rebuild is not required when upgrading from v1.5.2 release.

Assets 2
Loading