Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

v0.19.0
Compare
Choose a tag to compare
@afalaleev afalaleev released this 30 Nov 09:20
· 104 commits to master since this release
v0.19.0
7a0cb22

GOLOS·CORE

The new HardFork 19.0 version

Golos·Core announced the release of the next HardFork version 19.0, which introduces new functionality, as well as the shortcomings of previous versions. Updates approved by majority vote of witnesses.

Reindexing:
HF 19.0 requires reindexing from all previous versions.

Referral program implementation in the Golos blockchain (the issue #295)

Feature description
Witnesses proposed to implement a new functionality in HF-19.0 — to introduce a referral program to attract new users.

Solution
The referral program implementation provides for remuneration of users (referrers) who invited their friends or third parties through social networks to register on the blockchain (by viewing third-party publications or placing their own posts about the blockchain).

To implement the referral program in HF-19.0 the following operations were introduced:

  • Creating a referral account for the invited user. Both a user who directly invited another user or a third-party account can be specified as a referrer for the referral account.
  • Termination of the referral program by a referral through a redemption of her/his account. The operation allows a referral to redeem her/his account to stop paying a referrer.
  • Obtaining an information about a referral.
  • Obtaining an information about a referral by her/his comment or post.

Example to create a referral account name using cli_wallet:

create_account_referral test "0.200 GOLOS" "0.000001 GESTS" <referral account name> "{}" {"referrer": "test", "interest_rate": 900, "end_date": "2018-09-26T14:00:00", "break_fee": "0.000 GOLOS"} true

Here are:
referral — a referral account name;
referrer — a referral name;
interest_rate — referrer payout percentage of referral income multiplied by 100. Maximum payout percentage to the referrer is set by witnesses voting via the operation update_chain_properties(). Payments to the referrer are made through appointment of the referrer as a beneficiary in published posts;
end_date — end date of payments to referrer from referral income. Maximum payment period for a referrer is set by witnesses voting via the operation update_chain_properties();
break_fee — an amount of redemption by a referral of her/his account to stop payments to referrer. If the payment amount is 0, then an account cannot be redeemed. Maximum payout amount is selected by witnesses via the update_chain_properties() operation by median value.

  1. Example of operation to stop paying a referrer:
break_free_referral <referral account name> true
  1. To obtain an information about a referral via cli_wallet, the get_account command is used.
    To highlight the referral account in system, the following fields have been added to a response of the golos.api.getAccounts() API method:
    "referrer_account": "test",
    "referrer_interest_rate": 900,
    "referral_end_date": "2018-09-26T14:00:00",
    "referral_break_fee": "0.002 GOLOS"

During the referral program time for a referral account, field values correspond to fields from account_referral_options. After termination of the referral program, the fields take zero values.

  1. To obtain an information about a referral by her/his comment or post, an object with the parameters account=<referrer name> and weight=<referrer_interest_rate> is added to the beneficiaries field. Payment to the referer is carried out taking into account these parameters.

Changing the method of calculating remuneration to curators (the issue #898)

Problem description

Voting for a post begins as soon as it is published. Amount of remuneration to curators for voting depends on the time of voting. In order to make voting via using robot programs ineffective, a time interval of 30 minutes is introduced. This is an auction window which is opened immediately as soon as the post is completed. The weight of vote given in the auction window was calculated by the formula

W = t / (30 × 60) × weight

Here are:
t — voting time since window opening (in seconds);
(30 × 60) — window duration (in seconds);
weight — account weight.

In accordance with this formula, the resulting weight W decreases in proportion to early voting — earlier vote cast during the open window, gains less weight. In this case the missing (cut off) part of tokens is charged to author of the post. Therefore, voting during the open window is more beneficial to authors of posts.

Solution

It became possible to change the duration of the auction window by witnesses voting through the operation update_chain_properties().

In the HF-19.0 version (at witnesses suggestion) the algorithm for more flexible accrual of remuneration to curators has been improved, including:

  • the auction window duration is to be a voted parameter and will be set by witnesses voting via the operation update_chain_properties();
  • missing (cut off) part of tokens should be returned either to reward pool or to the curators who voted after closing the auction window.

Decision about where to direct the cut part of tokens, is made by a user.

For this purpose the following option comment_auction_window_reward_destination has been implemented in method comment_options_operation. The option accepts the following values:

  • to_reward_fund — return tokens to rewards pool;
  • to_curators — return tokens to curators who voted after closing the auction window;
  • to_author — return tokens to autor (used for posts that were created before HF-19.0 release to provide backward compatibility).

Possibility for witnesses to adjust the time intervals reserved for posting, for leaving comments and voting (the issues #533, #1002)

Problem description

Now the time intervals allowed for posting, for leaving comments to the post and voting are 5 min, 20 and 3 seconds, respectively. Such tightly spaced intervals cause inconvenience to users. For example, in a time of 20 s, up to ten or more comments may appear, and witnesses have to spend too much time to answer them.

Feature solution
In the HF-19.0 version it is possible to change the length of the intervals (also known as windows) specifically reserved for posting, for leaving comments and for voting, as well as the ability to change the permissible maximum of publications, comments and votes left during these intervals. The parameters posts_window, posts_per_window, comments_window, comments_per_window, votes_window, votes_per_window are added to the operation update_chain_properties, which is configured with the blockchain. Having these parameters, witness can specify the duration of the intervals during which posting, leaving comments and voting are allowed, as well as the number of publications, comments and votes allowed during those intervals. The values of these parameters are determined by witnesses voting through the update_chain_properties() operation, the results of which are considered as median values.

In the HF-19.0 version the commenting window duration and the allowed number of comments left within this window are 200 s and 10 pcs respectively. The voting window duration and the permissible number of votes to be left within this window are 15 s and 5 pcs respectively.

In addition, in this very version, an algorithm that operates on limiting the excessive activity of users in posting, commenting and voting has been improved. The algorithm allows to perform various actions in a row without waiting for the completion of the 20-second interval until the start of the next action in a more flexible way. The algorithm implemented is based on the «battery» principle. The minimum frequency of actions taken is determined by the following formula:

V = window / items

Here are:
window — is the length of the interval allocated for a type of actions;
items — the number of publications, comments or votes left within the interval.

The median value is selected by sorting out the values specified by witnesses by two values: the minimum frequency of actions and the length of the window in which these actions can be performed.

The user can posting, leave comments or participate in voting depending on the availability of resources (charge) in his/her particular «battery». The algorithm records the time of appearance of the post and the contents of the charge of the «battery», consumed with leaving each comment to the post or vote.

Deduction of a piece of funds from the curator payment to accrual this piece to the Golos Power lender (the issue #756)

Problem description

The number of people willing to delegate the Golos Power tend to be small. Partly, due to the fact that the GP lender (GP investor) does not receive any deductions from curator fees and therefore does not receive a fee at all.

Feature solution
Version HF-19.0 includes the ability to regulate the percentage of deductions to the GP lender. The curator receiving the GP delegated (according to the results of the voting for the post) deducts a portion of the curatorial payments to the lender.
The algorithm of investors’ GP accrual is implemented in accordance with the following features:

  1. Payment of remuneration to lenders with payments to curators (who receive the delegated VP by lenders) occurs simultaneously. The lender is charged a certain percentage of the payment to the curator. The amount of deduction to the lender is determined by the following formula:
lender’s remuneration = (curator’s remuneration) × (lender’s share in curator’s GP) × (percentage of lender’s contributions)
Here is:
lender's share in the curator’s GP = (number of delegated GP) / (total curator’s GP)

  1. The percentage of contributions addressed to the lender is appointed directly by the lender.
    The upper value of the percentage of deductions to the lender is determined by witnesses voting using the update_chain_properties() operation.

  2. A new virtual operation, delegation_reward_operation, has been added to the blockchain, which is assigned to notify lender about the rewards she/he receive for the GP delegated.

  3. The possibility of rejection of GP delegated by the beneficiary (in case of unwillingness to exchange payments with the lender). The operation reject_vesting_shares_delegation_operation has been added for this use.
    If the recipient refuses the delegated GP, it will not be automatically credited to the recipient’s balance sheet. The return of the delegated GP to the lender takes place after the end of the freezing for a period of 7 days.

Ability to store user's personal information in storage hash table in the key-value form (the issue #924)

Feature description
Witnesses proposed to implement the following functionality in HF-19.0 — to provide a user to save necessary information in storage hash table in the key-value form.

Solution
The solution is based on creation of a new account_notes plug-in, which allows an account to save necessary information in database as «key-value» entries depending on settings of the configuration file config.ini. The amount of information to be stored on a separate blockchain node is determined depending on this node resources.

The account_notes plugin implements a call to the set_value_operation operation, which allow an account to create, modify, and delete an entry in the storage hash table. The operation is called with the account, key, and value fields.
To change an entry in a hash table, the operation is called with same key of already existing entry. To delete an entry in a hash table, the operation is called with same key of already existing entry and with empty value.

The following parameters have been added to configuration file config.ini:

  • an-tracked-accounts — «tracked» accounts list. Used to specify a list of accounts that are allowed to save records. By default, an empty field is set to allow all accounts to store entries.
  • an-untracked-accounts — «untracked» accounts list. Contains a list of accounts that are not allowed to store entries. The field is empty by default.
  • an-max-key-length — maximum number of characters allowed in the key. Default value is 20.
  • an-max-value-length — maximum number of characters allowed in the entry. Default value is 512.
  • an-max-note-count — maximum number of entries allowed per account. Default value is 10.

If the set limit values are exceeded in the saved record, the operation is not performed. No error message is displayed. In order to control whether or not the information is saved successfully, a user should query the node with its current configuration and match the data of the saved record with the boundary values of this node.
After HF-19.0 release the cost resources bandwidth for operation custom_json will increase due to the multiplication by the multiplier value (the user’s bandwidth will be spent faster when the custom_ison operations are used). The default multiplier value is 100. Witnesses can change this value by voting via the update_chain_properties() operation. This allows users with more Golos Power to store more often and larger information in a hash table, unlike users with a smaller number of Golos Power.

Ability of a post author to set the percentage of curatorial deductions (the issues #324, #677)

In the previous version the curator's percent (percent of payment to curators from payment of the author) was always equal to 25 %. In the HF-19.0 version, witnesses are given the opportunity to change it and set limits the percentage of curatorial payments to between 25 and 100 % inclusive.

In case witnesses set the interval of possible values for the share of payments to curators, authors can also change this value at their discretion, but within the established limits. It allows authors to encourage curators to vote for their posts more often while increasing the percentage of curatorial deductions. After creating a post, the author can indicate the percentage of curatorial deductions from the expected remuneration for this post.

The amount of funds received from the percentage of curatorial contributions is distributed among curators in accordance with their weights. The curator's weight is determined by one of three algorithms:

  • Previously used algorithm — is an algorithm according to which for curatorial payments is determined depending on the voting time and used Golos Power. In the HF-19.0 version, this method of distributing remuneration between curators is preserved.
  • Linear algorithm. The curator's weight depends on funds in the Golos Power and does not depend on the voting time. Set by default.
  • Square root algorithm. The curator's weight is calculated taking into account the existing votes for the post (given by other curators) and depends on the voting time. For example, in case two curators voted having the same Golos Power, but at different times, the second of the voters will receive a reward twice less than the first of them.

In the HF-19.0 version, witnesses are given the opportunity to set one of the three algorithms via the update_chain_properties operation.

The structure content_curation_rewards_percent added to the operation comment_options_operation. Having this operation given, the author can set the percentage of curatorial deductions.

Note:
As this feature was not accepted in the current way the curator´s percent is fixed at 25 %.

Fixed bug in return result of the API method get_account (the issue #825)

Bug description
Incoming response to request of the API method get_accounts contained information about number of posts and comments in one field post_count only. In addition, the comment_count field was always returned empty. Also, there was no error message, which could lead users to an embarrassing state.

bugfix
This drawback has been eliminated in version HF-19.0. The get_accounts method has been modified to correctly write data to the appropriate fields when creating a post and comment. The comment_count field contains number of comments, while the post_count field contains only the number of posts.

Changes in system logic for the case when the system debt exceeds 10 % (the issue #952)

Problem description
In previous blockchain versions, the system operated in accordance with the following algorithm in terms of GBG emission:

  • if the total amount of GBG tokens calculated at the system price set does not exceed 10 % of all GBG and GOLOS tokens, authors of posts are rewarded with GBG tokens according to the following schema:
    • if the system’s debt does not exceed 2 %, then authors of posts are rewarded in the GBG form;
    • if the system’s debt is above 2 %, but does not exceed 5 %, then authors of posts are rewarded in the GBG and GESTS form. In this case, if the system’s debt increases from 2 to 5 % inclusive, the quantitative ratio of GBG to GESTS decreases accordingly (for example, if the system’s debt is 3,5 %, the reward is accrued in the GBG and GUESTS form in the 1:1 ratio. If the system’s debt is 3,5 %, the reward is accrued in the GESTS form only);
    • if the system’s debt exceeds 5 %, remuneration to authors of posts is terminated. At the same time, interest payments to owners of GBG tokens continues;
  • if the total amount of GBG tokens calculated at the system price set exceeds 10 % of all GBG and GOLOS tokens, payment of interest accruals to GBG token holders continues without termination of GBG emission.

Solution
In the HF-19.0 version, changes were made to the system logic regarding GBG emissions. The algorithm has changed when the system’s debt exceeds 10 %. Changed the following part:

  • if the total amount of GBG tokens calculated at the system price set exceeds 10 % of all GBG and GOLOS tokens, payment of interest accruals to GBG token holders is terminated without termination of GBG emission.

If the system’s debt exceeds 10 %, the system sets a flag indicating that the limit value of the GBG token is reached. The user will be notified of the status of this flag when obtaining information about the current system state.

Account recovery after losing the account’s private key (the issue #971)

Problem description
In previous blockchain versions, there was no protection of funds available on the account in case unauthorized access was occured to the account’s private key. If the attacker took possession of the account's private key, then she/he could change it and using the account name, could run the operation to withdraw all funds in the GESTS form. Moreover, when the account was restored, the withdrawal operation continued and attempt to cancel it failed.

Solution
In the HF-19.0 version introduced revision to block the funds withdrawal from an account in case the account's private key was lost or unauthorized access was occurred to the key.
The withdraw_vesting operation has been modified. The withdrawal operation lasts for 13 weeks. During this operation, the funds are transferred in the form of GESTS with a frequency of once in seven days. After the account is restored, the set_withdraw_vesting_route operation is automatically canceled. Moreover, all withdrawal operations are removed from schedule. All payments in GESTS are recovered with the exception of those funds that were already withdrawn as payments before the account was restored.

Optimization of the calculation of expected payments to author and curators (the issue #976)

Problem description
After publishing the post, a window opens for voting. During this interval, the percentage of payment to the author and curators is determined for the publication of the post. The payment algorithm consists of such operations as viewing the list of curators, determining the percentage of payments for each of curators, the time of their voting with taking into account penalty time interval. This process requires significant system resources. In order to obtain information about the expected (projected) payments to the author and the curator, it would be necessary to perform more complex calculations andand as a consequence increase the load on the system.

Solution

In new blockchain version, it was proposed to issue the expected payments to the author and the curators in a simpler way, ensuring that the obtain payout values are close to real values and it does not require a large load on the system.

After implementing strategies using the auction window, the received message has full information about the weight of the curators ' votes, so the calculation of the expected payments can be optimized. Operations, which does not have a significant impact on the final result, have been removed from algorithm for calculating the expected payments. The reduction of operations in the algorithm provided a reduction in the load on the system without a significant deviation from the real values of payments

Paging and sorting the result obtained via the API request (the issue #981)

Problem description
View a list of voted for a post is done through API requests in the form social_network::select_active_votes. Number of voters may be too large and therefore viewing the list of votes in the form of «likes» or «dislikes» may take a long time. In the previous blockchain version, votes displayed in the list according to their appearance in the voting window without taking into account their weight, which made it difficult to analyze the voting results.

Solution
In the HF-19.0 version, a new functionality has been implemented that provides paginal input of the list of voters, as well as sorting of votes based on their weight (the votes with the highest weight are placed at the top of the list). The votes are sorted automatically. Revision allows to reduce the time to view the voting results.

Fixed bug in counting the private messages (the issue #990)

A user has the opportunity to obtain statistical information about a number of private messages received from accounts such as pinned, unknown and ignored accounts.

In the previous blockchain version, after the user deletes messages received from one of these accounts, information about number of private messages received from another account type could also be changed and be incorrect (for example, was displayed the most possible value).

In the HF-19.0 version, the counters processing the number of private messages have been modified for each type of account. The modification provided a correct counting the user's personal messages for all types accounts after deleting any piece of them.

Assets 2
Loading