Dear validators and community members!

We announced this upcoming HardFork in our previous post, a weekly validators' activity report. Our team is conducting the very last tests for the release and in the meanwhile, we'd like to introduce you to the changes that are about to be included in this HF version. In the span of the next couple of days, a full mode version to be presented to the community.

Modification to cyber.msig contract

A description field has been added to propose action of the cyber.msig contract to describe a proposal. This field was added as binary_extension. It is not serialized if not specified in arguments. Thus, all existing libraries that generate arguments without specifying description will work correctly.

Problem description

The process for executing deferred proposals has also been modified. Previously, they were performed using deferred transaction mechanism, and such implementation leads to several problems:

• Users could not cancel a proposal previously scheduled for execution. Thus, the meaning of deferred proposals was lost, since users were not given any opportunities to manage the proposal during the delay period after reaching consensus.
• There was no easy way to control if a proposed transaction was completed successfully or not. That transaction was always executed as a deferred transaction (even in absence of a delay in execution). The only way to verify that it was successful was to find it in a list of completed transactions.
• A transaction should have included actions to provide all resources. And, although that was a system function (and not an agreement between actors who signed proposal), there was no way to provide resources to another user when actually executing the proposal. Given that, it was necessary to recreate proposal, re-collect all signatures and wait for the delay to end, if indicated.

Solution

CyberWay implemented an intrinsic that allows you to execute another transaction as a nested transaction (#1203). The contract cyber.msig uses this intrinsic to complete a transaction contained in proposal. Transaction is executed during exec action and a description of provided bandwidth is transmitted to the nested transaction. If proposal is not executed due to an error, then this will be reported when exec is executed. The proposal will remain in the list and a user will be able to execute it again after fixing the error.

New action schedule(name proposer, name proposal_name, name actor) has been implemented for deferred proposals. This action captures a fact of consensus. As soon as the delay specified in proposal ends, this transaction will need to be executed using exec. Now actors of proposal have the opportunity to withdraw their signature while waiting. In this case, proposal will not be fulfilled if there are not enough permissions to perform all its actions.

Also, the old_approvals_info table has been removed from contract code. It remains as a EOS code rudiment. Previously, it was used to correctly migrate to a new version of approval storage. CyberWay uses the new implementation and no longer needs this table. As a consequence, all the code related to this table has been removed as well.

Modification to cyberway.govern contract

The contract cyberway.govern has undergone a number of changes validators wise, in particular, ones which dishonestly take on the accepted obligations to generate blocks.

Сhanges in requirements to a validator

• Validators produce blocks in accordance with the sequence specified in the schedule. If the schedule contains N vaditors, then N blocks must be produced in 1 cycle.
  The concept of round is introduced - the time it takes to complete four cycles (the time for which 4×N blocks must be produced).

Validator is not rewarded if no one block was produced by him during one round. The highlighted reward to validators is marked on their special account at the beginning of the round. When the validator produces a block, he marks these funds as requested and at the beginning of the next round they are transferred to a validator account. If the validator skips block production, then this award is burned (this is reported using cyber.govern:burnreward event).

In case a validator skips 100 rounds (no any block produced during 4×100 cycles) in a row, his key will be reset and a ban on changing the key for 1 day will be set.

If 4 series are being skipped in a row of 100 rounds (no any block produced during 4×4×100 cycles), the validator will be automatically denounced by setting proxy_level to the maximum value and it will be forbidden to return to activity within 7 days.

Important! If a validator does not demonstrate any activity within 30 days, then any user can suspend the validator using cyber.stake:suspendcand action.

• The new action setshift( int8_t shift ) has been implemented in cyberway.govern contract.

This action allows producers (cyber.prods account) to set a rate of change in number of validators . The shift parameter sets the rate of change in the number of validators. Valid values ​​are limited by contract (-1, 0, +1).

The operation algorithm is the following:
* when assigning a new list of validators, their number will be changed to the value indicated in shift if the last change (or setshiftcall) was later than schedule_resize_min_delay (14 days).

The contract also limits the number of validators to the constants min_producers_num (21) and max_producers_num (101).

After updating the contract, a growth value of +1 will be selected and the time moment will be identified, meaning that the first validator number increase will occur in 14 days.

• Automatic reset of votes for a validator is cancelled if he reduces a percentage of deductions or obligation by minimum number of a stake.

For token issuer (i.e validators when it comes to CYBER tokens), ability to enable / disable the automatic reset of votes using the cyber.stake action: setautorcmode (symbol_code token_code, bool enabled) is implemented (after updating the contract for the CYBER token, this mode will be turned off).

However, even when the mode is on, the votes will not be reset automatically until the voter sets parameters with the action setautorc(name account, symbol_code token_code, bool break_fee_enabled, bool break_min_stake_enabled). This action helps a user indicate in violation of what conditions his vote for a validator should be suspended.

Bug fixed

Fixed high priority bug (#304) in cyber.govern program code due to which a user lost (under certain conditions) part of reward allocated to him when voting for validator. Despite the fact that we are talking about a small amount of funds (less than 2 CYBER), it was decided to add the special returnlosses action (without parameters) to the cyber.stake contract.

This action will be performed by validators only once. After performing return losses, the lost funds will be returned to their owner and a record of the successful transfer of funds will appear in the cyber.stake contract.

New feature: providing information about a validator (#329)

Problem description

In previous version, validator was not able to announce any info about himself on-chain

Solution

The action setinfo(name account, symbol_code token_code, string url, binary_extension <string> info) has been added to the cyber.stake contract. This action allows validator to provide a link to his page, as well as some additional information. The length of the url and info strings is limited to 2048 characters (max_validator_meta_size).

Cyberway contracts building process improved

The process of building contracts has been modified. In particular, contracts began to automatically generate ABI-descriptions using the contract code. This eliminates errors in the discrepancy of the contract code and its description.

This modification did not affect names of actions and their arguments; therefore, compatibility with existing libraries remains. To control for unexpected changes, a check was added to contracts build procedure to make sure that the generated ABI-description matches the expected one.

Also, Docker image generation was added when building system contracts. This image can be used by other projects to deploy the testnet, as well as initialize it from Genesis.

Don't hesitate to join our community via:

Commun:

https://commun.com/cyberway

Telegram:

• CyberWay - https://t.me/cyberway_en (for general questions and inquiries)
• CyberWay Validators - https://t.me/cyberway_validators_en (for questions and inquiries concerning validators of CyberWay platform)
• CyberWay Dev - https://t.me/cyberway_dev (for instant technical feedback from our Dev team)

Twitter:

We'll keep you updated over https://twitter.com/cyberwayio