caritas

6 лет назад

The next version of HardFork 19.0

Note: I have not made any changes to it to furnish the detailed information as it is, I just translated from russion to english language.
Sourse:https://wiki.golos.io/golosd/HardFork/HF19_ReleaseNotice-rus.html

The introduction of the referral program in the blockchain Golos
(Task number 295 )

The decision of the delegates was proposed to implement a new functionality in HF-19.0 - to introduce a referral program to attract new users.

Implement new functionality

The implementation of the referral program 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 added:

creating a referral account for the invited user. As a referrer for a referral account, both a user who directly invited another user or a third-party account can be specified;
termination of the referral program by the user-referral through the redemption of your account. The operation allows the referral to redeem his account to stop paying the referrer;
receiving information about the referral user;
receiving information about the referral user by his comment or post.

where:
referral- the name of the referral account;
referrer- name of the referrer account;
interest_rate- the percentage of payments to the referrer from referral income multiplied by 100. The maximum percentage of payments to the referrer is set by voting delegates through the operation update_chain_properties(). Payments to a referer are made through the appointment of a referrer as a beneficiary in published posts;
end_date- End date for payments to the referrer from referral earnings. The maximum payment period for the referee is set by delegates voting through the operation update_chain_properties();
break_fee- The amount of redemption referral of your account to stop paying the referrer. If the payment amount is 0, the account cannot be redeemed. The maximum payout amount is chosen by delegates through a update_chain_properties()median operation .

An example of specifying a command for an operation to stop paying a referrer is:

break_free_referral referral account name> true

To obtain information about the user-referral through the cli_walletcommand is used get_account. To give the referral account a special status in the system golos.api.getAccounts(), the following fields were added to the API method response :

"referrer_account": "test",
"referrer_interest_rate": 900,
"referral_end_date": "2018-09-26T14:00:00",
"referral_break_fee": "0.002 GOLOS"
In the period of the referral program for the referral account, the field values correspond to the fields from account_referral_options. After the termination of the referral program of the field take zero values.
To obtain information about the referral user by his comment or post beneficiaries, an object with the parameters account is added to the field and weight =. Payment to the referer is carried out taking into account these parameters.

Changing the method of calculating remuneration to curators (revision for the penalty box of voting)
(Task number 898 )

The beginning of voting for the post begins immediately after the completion of its publication. The amount of remuneration to curators for voting depends on the time of voting. The duration of the interval for voting was 30 minutes - the auction window (English auction window), which opened immediately after the creation of the post. The weight of the voice given in the interval of this window was calculated by the formula

W = t / (30 × 60) × weight
Where:
t is the voting time since the window was opened (in seconds);
(30 × 60) - window duration (in seconds);
weight - voice weight of the account.

In accordance with this formula, the resulting weight W decreases in proportion to the early voting — an earlier vote given during the open window period receives a smaller weight. In this case, the missing (cut off) part of tokens is charged to the author of the post. Voting during the open window is more beneficial for the authors of the post.

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

it became possible to change the duration of the auction window by voting delegates through the operation update_chain_properties();
it became possible to return the missing (cut off) part of the tokens either to the pool of rewards, or to curators who voted after the auction window was closed. The decision about where to direct the cut part of tokens is made by the author of the post.

To this end, comment_options_operationan option has been added to the method comment_auction_window_reward_destinationthat takes the following values:
to_reward_fund- return of tokens to the reward pool. When tokens are returned to the remuneration pool, a virtual operation auction_window_reward_operation is generated;
to_curators- return of tokens to curators who voted after the auction window is closed;
to_author- only for posts created before the release of HF-19.0 (after the release of HF-19.0, the choice of this option will not be possible).

The ability of delegates to change the time intervals devoted to the creation of posts, leaving comments and voting
(Tasks №№533 , 1002 )

Delegates were asked to reduce the time intervals allowed for the creation of posts, leaving comments on the post and voting, constituting 5 minutes, 20 and 3 seconds, respectively. Such rigidly fixed intervals have a disadvantage. For example, in the allotted time of 20 s, up to ten or more comments may appear, on the responses of which delegates have to spend considerable time.

The HF-19.0 version now has the ability to change the length of the intervals (windows) set aside for creating posts, leaving comments and voting, as well as the ability to change the maximum number of posts, comments and votes left during these intervals.

In operation update_chain_properties, by which is configured blokcheyn, settings are added posts_window, posts_per_window, comments_window, comments_per_window, votes_window, votes_per_window. Using these parameters, delegates can set the duration of the intervals during which posts are allowed to be created, leave comments and vote, as well as the number of comments and votes left during these intervals. The values of these parameters are determined by delegates voting through the update_chain_properties () operation, the results of which are taken as median values.

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

In addition, in the version of HF-19.0, an algorithm has been improved that limits the excessive activity of users in creating posts, in commenting and voting. The algorithm allows you to more flexibly perform actions in a row without waiting for the completion of the 20-second interval until the start of the next action. The algorithm works on the "battery" principle. The minimum frequency of actions taken is determined by the formula

V=window/items
where:
window- the duration of the interval allotted for a separate type of action;
items- the number of publications, comments or votes left for the allotted interval.

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

The user can create posts, leave comments or participate in the vote, subject to the availability of resources (charge) in his "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.

The accrual of the delegating force votes to the share of curatorial
(Task number 756 )

The number of people willing to delegate the power of voice is small. This is partly due to the fact that the delegator (SG investor) does not receive any deductions from curator fees and therefore does not receive a fee at all.

In the HF-19.0 version, the ability to set the percentage of deductions to the SG investor has been added. The curator, who is delegated to the SG, according to the results of voting for the post, deducts a portion of curatorial payments to the investor.
The algorithm for accruing to investors for SG is implemented in accordance with the following features:

Payment of remuneration to investors occurs simultaneously with payments to curators who have been delegated by SG investors. The investor is charged a certain percentage of the payment to the curator. The size of the deduction to the investor is determined by the following formula:

Вознаграждение инвестору = (вознаграждение куратора) × (доля инвестора в СГ куратора) × (процент отчислений инвестору)
где:
доля инвестора в СГ куратора = (количество делегированной СГ) / (общее количество СГ куратора)

The percentage of contributions to the investor is appointed directly by the investor. The upper value of the percentage of deductions to the investor is determined by voting delegates using the operation update_chain_properties().
A new virtual operation has been added to the blockchain delegation_reward_operation, which is used to notify delegates about the rewards they receive for the delegated SG.
The possibility of rejection of the beneficiary delegated to the SG (in case of unwillingness to exchange payments with the investor). For this operation was added reject_vesting_shares_delegation_operation.
If the recipient refuses the delegated SG, it will not be automatically credited to the recipient’s balance sheet. The return of the delegated SG to the delegate takes place after the end of the freezing for 7 days.

The ability of the user to store personal information in the storage hash table in the form of key-value
(Task number 924 )

By the decision of the delegates, it was proposed to implement a new functionality in HF-19.0 - to enable the user to save the information he needs in the hash table of the repository in the form of a key-value.

The solution is based on the creation of a new plug- account_notesin that allows an account to save the necessary information for it in the system database hash table as “key-value” entries, depending on the configuration file settings config.ini. The amount of information for storage on a separate Node (node) of the blockchain is determined taking into account the resources of this Node.

The plugin account_notesimplements a call to an operation set_value_operationthat creates, changes and deletes an entry in the storage hash table. The operation is invoked with the account, key, and value fields.
To change an entry in a hash table, the operation is invoked with the key of an already existing entry. To delete an entry in the hash table, the operation is invoked with the key of the already existing entry and an empty value.

The config.inifollowing configurable parameters have been added to the configuration file : - an-tracked-accounts- “white” list of accounts. Used to specify a list of accounts allowed to save records. By default, an empty field is set to allow the storage of records for all accounts;

an-untracked-accounts- "black" list of accounts. Contains a list of accounts that are not allowed to keep records. The default is an empty field;
an-max-key-length- the maximum number of characters in the key. The default value is 20;
an-max-value-length- The maximum number of characters in the record. The default value is 512;
an-max-note-count- The maximum number of entries for one account. The 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 the successful storage of information, the user must query the node for its current configuration and match the data of the saved record with the boundary values of this node.
After HF-19.0, the cost of the bendwich resources for operations custom_jsonwill increase due to multiplication by the value of the multiplier. The default multiplier value is 100. Delegates can change this value by voting through the operation update_chain_properties(). This allows users with more SG to store more often and larger information in a hash table, unlike users with a smaller number of SG.

Author’s ability to set curator fees for a post
(Tasks №№324 , 677 )

In the previous version, the share of payment to curators was unchanged and amounted to 25% of the amount of remuneration to the author of the post. In the HF-19.0 version, delegates are given the opportunity to change this value and set the limits of its changes in the range from 25 to 100% inclusive.

In the event that delegates set the interval of possible payout rates to curators, authors can also set this value at their discretion for each published post, but within the boundaries set by the delegates. After creating a post, the author can indicate the percentage of curatorial deductions from the expected remuneration for this post (the author cannot choose the percentage of curatorial deductions until delegates determine its boundary values). This allows the author of the post, increasing the percentage of curatorial contributions, to encourage curators to vote for their posts more often.

The amount of funds received from the percentage of curatorial deductions is distributed between the curators in accordance with their weight. Curator weight is determined by one of three algorithms:

The old algorithm (bounded) is an algorithm according to which the share of the curator's remuneration is determined depending on the voting time and the Power of the Voice used. In the HF-19.0 version, this method of distributing remuneration between curators is preserved.
Linear algorithm (linear). The weight of the curator depends on the means in the form of the Power of the Voice and does not depend on the time of voting. Set by default.
Square Root Algorithm (sqrt_root). The weight of the curator is calculated taking into account the existing votes for the post (given by other curators) and depends on the time of voting. For example, if 2 curators voted with the same Power of the Voice, but at different times, then the second of those who voted will receive a reward less than the first twice.
In the HF-19.0 version, delegates are given the opportunity to choose one of the three algorithms given through an operation update_chain_properties.

A comment_options_operationstructure has been added to the operation comment_curation_rewards_percent. With this operation, the author can set the percentage of curatorial deductions.

Note:
Since this functionality is not approved by delegates, currently the percentage of curatorial payments is fixed and amounts to 25%.

Eliminating the response in the get_account API method response
(Task number 825 )

In the incoming response to an get_accountsAPI method request, information about the number of posts and comments was exclusively in the field post_count, and the field was comment_countalways returned empty. Also, there was no any error message that could lead users to a confused state.

In version HF-19.0, this drawback is eliminated. A method was developed get_accountsto correctly write data to the appropriate fields when creating a post and a comment. The field comment_countcontains the number of comments, and the field contains post_countonly the number of posts.

Changes in system logic with system debt exceeding 10%
(Task number 952 )

In previous versions of the blockchain, the following algorithm was incorporated into the logic of the system in terms of GBG emissions:

if the total value of all GBG tokens, calculated at the price incorporated in the system, does not exceed 10% of the value of all GBG and GOLOS tokens, the authors of posts are charged in accordance with the following scheme:
if the system’s debt does not exceed 2%, then the authors of posts are rewarded in the form of GBG;
if the system’s debt is above 2%, but does not exceed 5%, then the post authors are rewarded in the form of GBG and GESTS. At the same time, as the system’s debt increases from 2 to 5% inclusive, the proportion of GBG to GESTS decreases proportionally (for example, if the system’s debt is 3.5%, the remuneration is in the form of GBG and GESTS in a 1: 1 ratio. only as GESTS);
if the system’s debt exceeds 5%, remuneration to the authors of posts is terminated. At the same time, the owners of GBG tokens do not stop paying interest charges;
if the total value of all GBG tokens, calculated at the price incorporated in the system, exceeds 10% of the value of all GBG and GOLOS tokens, the payment of interest charges to GBG tokens owners continues without discontinuing the emission of this type of tokens.
In the HF-19.0 version, changes were made to the system logic regarding GBG emissions. The algorithm has changed when the system has a debt in excess of 10%. The modified part of the algorithm:

if the total value of all GBG tokens, calculated at the price incorporated in the system, exceeds 10% of the value of all GBG and GOLOS tokens, the payment of interest charges to GBG tokens owners is terminated without discontinuing the emission of this type of tokens.
When the system’s debt is exceeded by 10%, the system sets a flag indicating that the limit value of the GBG token has been reached. The user will be notified of the status of this flag when executing an API operation to obtain information about the current state of the system.

Resetting the power of the voice to another account after restoring the account
(Task number 971 )

In previous versions of the blockchain, there was no protection of the funds in the account in the event of unauthorized access to the account’s private key. The attacker, having taken possession of the account's private key, could change it and, on behalf of the account, launch an operation to withdraw all funds in the form of GESTS. At the same time, when the account was restored, the withdrawal operation continued and the attempt to cancel it was unsuccessful.

In the HF-19.0 version, a revision was introduced to block the withdrawal of funds from an account in the event of a loss of a private key or unauthorized access to the account's private key.
Improved operation withdraw_vesting. The withdrawal operation lasts for 13 weeks. During this operation, the funds are withdrawn in the form of GESTS once every seven days. After the account (account) is restored, the operation is automatically canceled set_withdraw_vesting_route. Removes all the findings from the schedule. At the same time, all payments in GESTS are restored with the exception of that part of the funds, which had already been withdrawn as payments before the account was restored.

Optimization of the calculation of expected payments to the author and curators
(Task number 976 )

After the post is published, a voting window opens, during which the percentage of accrual to the author and curators of the remuneration for the post is determined. The payment algorithm consists of such operations as viewing the list of curators, determining the percentage of payments for each of the curators, as well as the time of their vote, taking into account the penalty box. This process consumes significant system resources. In order for the author and the curator to get information about the expected (predicted) payments to them, it would be necessary to perform more complex calculations and, accordingly, increase the load on the system.

In the new version of the blockchain, it was proposed to show the expected payments to the author and the curators in a simpler way, ensuring that the payout values are close to the real and with the least load on the system.
After implementing strategies using the auction window, the message received has full information about the weight of votes of the curators, so the calculation of expected payments can be optimized. Operations have been removed from the algorithm for calculating expected payments; the result of which does not have a significant effect on the final result. The reduction of operations in the algorithm for calculating the expected payouts ensured a reduction in the loads on the system without a significant deviation from the actual payout values.

Ability to paginate and sort the result received from the API query
(Task number 981 )

View the list of those who voted for the post is done through API requests of the form social_network::select_active_votes. The number of voters may be excessively large and therefore it may take a long time to view the list of votes in the form of “likes” or “dislikes”. In the previous version of the blockchain, voices appeared in the list according to their appearance in the voting window without regard to their weight, which made it difficult to analyze the voting results.

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 to reduce their weight (the voices with the greatest weight are located at the top of the list). The sorting of votes is done automatically. Revision allows to reduce the time to view the voting results.

Fixed error in counting the number of private messages
(Task number 990 )

The user has the opportunity to receive statistical information about the number of incoming personal messages from accounts, including those assigned to him in correspondence (eng. Pinned), from unknown (eng. Unknown) and blocked (eng. Ignored) accounts. In the previous blockchain version, after the user deletes messages from one of these types of accounts, the data on the number of personal messages from another type of account could also be changed and be incorrect (for example, display the maximum possible value). In the HF-19.0 version, the counters processing the number of personal messages received by the user are refined for each type of account. Refinement ensured the correct counting of the user's personal messages from all types of accounts.

Terminology used
Account (eng. Account) - a user account stored in the system for his identification (authentication) and provision of access to his personal data and settings.
Referral account - an account created for the invited user (referral) to the system by another user (referrer) of this system.
The median value is a value determined by sampling from the middle of a set of numbers arranged in a specific order (descending or ascending). For example, the median value of the set {8, 8, 7, 2, 1} equals 7, since this number is in the middle of the set. If a set consists of an even number of numbers, then the result is the half-sum of two adjacent values. For example, the median value of the set {7, 5, 3, 1} is 4.
Post(eng. to post - post, publish) - any article or entry on a web page containing a title, a list of keywords and the text itself.
Referral is a user of the system, invited and registered in the system on the recommendation of another user of this system.
Referrer (eng. Referrer) is a user of the system that attracts other users to this system.
Token (eng. Token ) - an internal payment unit designed to represent the digital balance in an asset (not a cryptocurrency).