Release Candidate 0.18.0rc1

GOLOS·CORE Equality HF·18 Release Notes

This page contains general information about a new BlockChain version from Golos·Core, based on new realised features and named as HF·18. Golos·Core recommends all witnesses, seed nodes and anyone else who uses the witness plug-in have to update to HF·18.

Reindexing

HF·18 requires reindexing from all previous versions.

Overview

HF·18 is a release with miscellaneous bug fixes enhancements and released new functionallity.

New features

• Golos Power delegation
• Preventing various abuse kinds of the Golos Power delegation operation
• HF•18 provides more flexible pricing policy on the exchange due to remove old data and use actual only for determining the exchange rate and the ratio of cryptocurrencies
• Ability for users to edit their profile by using the posting key
• Ability for users to propose a transaction which requires approval of multiple accounts in order to execute
• Ability for users to update their posts and comments regardless of when they were published

New technical capabilities

• Increasing system performance due to placing frequently and rarely used database fields in different objects
• Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively
• Using tags to create requests for obtaining the necessary information
• Getting shared memory status
• Ability to paginate private messages and send them out to user's screen
• Improving storage subsystem of chain blocks
  

Golos Power Delegation

This feature allows a user to delegate for a time unused part of Golos Power to another user as if she/he owned the Golos Power and could dispose it.The time-lending part of Golos Power will give the lender extra bandwidth and extra voting power for getting up a certain bonus.

It is also possible to withdraw the delegated Golos Power. This means in case of unforeseen circumstances the lender can change the delegated amount, as well as carry out the return of the delegated Golos Power in full.

The active key is required to perform these actions.

Preventing various abuse kinds of the Golos Power delegation operation

In order to prevent various fraud operations (or abuses) related with transfering delegated Golos Power from account to account, as well as cashing Golos Power into Golos, delaying operation is provided. It works as follows. This feature provides quick cashing Golos into Golos Power but requires a time delay in seven days for cashing the Golos Power into Golos.

The lender can also revoke the delegated Golos Power any time. In this case the delegated Golos Power will be withdrawn from borrower’s account immediately and returned to lender’s account in seven days.

HF•18 provides more flexible pricing policy on the exchange due to remove old data and use actual only for determining the exchange rate and the ratio of cryptocurrencies

In previous versions for determining rate of cryptocurrencies, such as Golos and GBG (Golden Backed by Golos), both new and old data were used. To fix this problem in HF•18 dynamic parameter was implemented. It shows the ratio and exchange rate of two kinds of cryptocurrencies. The value of this ratio is determined by delegates of the system. The course values proposed by delegates are stored in a database. Before determining new resulting value of the course all of old values are removed from the database and not used in calculation of the current course of Golos and GBG. The resulting value of the course is defined as the average value.

The feature provides more correct pricing policy for Golos and GBG on the stock exchange.

Ability for users to edit their profile by using the posting key

HF•18, unlike the previous version, allows a user to edit the profile fields by using the posting key. In previous versions it was possible to edit any profile field by using the active key only, and was not always acceptable.

In the HF•18 version, the profile fields are divided into two groups. The first group consists of fields which are the most significant profile data (keys: posting, active, owner and memo), and another group - the fields which are less significant, but often used (avatar, gender, location, etc.).

Now, to edit the first group of the fields the user has to use the active key as before. But it is not required anymore for editing other fields of the profile. The user can easily do it by using the posting key as well.

Ability for users to propose a transaction which requires approval of multiple accounts in order to execute

HF•18 allows a user to propose a transaction on the blockchain which consists of multiple operations and requires approval of multiple accounts in order to execute. Each operation from the transaction requires an approve of the author whom the operation is intended. At any time a participant of the transaction can either approve or decline any operation too.

When a sufficient number of approvals have been granted, the operations in the proposal are evaluated. For collection of the signatures an expiration time is assigned, after which the transaction is either canceled or executed. Even if the transaction fails, the proposal will be kept until the expiration time. The author, as well as other participants of the transaction, can change their decisions and update the signatures before the expiration time.

As soon as the proposed transaction get sufficient approvals, the proposal will be regarded as resolved, and all future updates will be invalid.

In case having a refused operation the participant may form a request to delete the proposed transaction. The proposed transaction may be deleted by either author or any participant.

Ability for users to update their posts or comments regardless of when they were published

In the previous versions of the blockchain there was a time limit, after which any comment and post could not be edited. Because of this reason, user's publications might become obsolete and be unactual. The authors instead of updating them had to publish similar posts in accordance with the current situation. In HF•18 version this inconvenience is absent and users should not worry about when they were published and can edit and update their posts at any time.

Increasing system performance due to placing frequently and rarely used database fields in separate objects

A post with the comments are located in a separate object on a disk. To process the object it needs to be moved from disk to shared memory. If the object is too large the process is slowed down due to pumping of pages.

The object contains rarely used fields, such as: name of author, title, tags, some texts and links to other objects. Besides, it also contains frequently used and updated fields, such as: counters of voted users and expected bonus.

While voting, the counters are often updated and to process the object it needs to be moved every time from the disk to shared memory. Moving large object takes a long time and therefore frequent voting slows down system operation.

In HF•18 to increase system performance it was solved as follows. The frequently used and rarely used fields have been replaced into two separate objects respectively. In this case only the object with frequently used fields is loaded into shared memory. It takes much less time for processing the blocks and allows to increase system performance, while voting.

Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively

In previous version the methods, which provided getting lists of operations (in block, in transaction, on accounts ), were located in database_api plug-in. To get information about operations done by a user it was necessary to start account_history plug-in, which then started those methods in database_api. As a result the process took much time the user could get unneeded information.

In HF•18 some methods were reallocated between plug-ins. Two methods get_ops_in_block and get_transaction were moved from database_api plug-in to new separate operation_history plug-in to index operations in blocks and transactions. One more method get_account_history was moved from database_api to account_history to index account operations.

Such reallocation allows the user to form a request for obtaining information about operations of the transactions (or blocks) without receiving unnecessary history of accounts. In addition, it allows to decrease the server and memory loads and increase system performance.

Using tags to create requests for obtaining the necessary information

Searching information by using tag initiates index operations, which require lots of shared memory. Moreover, they search for various types of information, which is useless for core user group and can be useful for individual user only.

Since index operations spend significant resources, all methods which manage the operations, were moved from social_network plug-in to new separate plug-in named Tag. Other methods which provide access to root elements, were left in the social_network plug-in. Besides this, some unused fields were removed from their methods at all.

New optional vote_limit parameter was implemented in the blockchain to set the maximum number of voted users. By default this value is 10000.
Because of too big number of comments to the post it makes difficult to view and search for useful information. In this case a user can generate a request via using the tag to receive comments selected in accordance with choosing characters in the tag. Due to implementation of vote_limit parameter the size of the server response can be reduced to the set number. Moreover, there is additional field active_votes_count is added in the response, that allows the user to see total number of voters without receiving a full list.

The reallocation of methods allows the user to pull out just a needed part of the content while searching, determined by the specified characters in the tag.

Getting shared memory status

New method get_database_info was created in the database_api plug-in for picking up the main information about shared memory. This allows a user to form a request for getting memory status, namely: total size, free size, used size, reserved for certain needs size and a list of indexes stored in shared memory (index name and number of its entries).

Ability to paginate private messages and send them out to user's screen

HF•18 allows a user to pull out her/his private messages from whole list of outgoing (or incoming) messages and paginate them while viewing. The user can also limit number of getting messages. Needed changes have been made in the private_message plug-in.

Improving storage subsystem of chain blocks

The system has two repositories: the first one is shared memory (shared_memory.bin) to store current system state, and the second one is signed chain blocks (block_log) followed each other. Block_log is rarely using block. It is used for getting body of a signed block via API calls to synchronize nodes data and in other operations. These operations require many system calls — opening a file, positioning in it, reading file data. At the same time there happens а write to the end of the file, which also requires the same operations and so on. Such parallel access to the file often causes conflicts with blocking access to this file.

In HF•18 this problem was solved due to implementation of technology, which provides simultaneous access to read data from the file. Currently, blocking occurs when writing to the file block_logonly.