@Cyberwaydev Proposals for Improving CyberWay System Contracts
Dear CyberWay users and validators! We suggest that you get familiarized with the proposals for changing the logic in system contracts.
The change of these contracts requires two following steps:
- Signing of hardfork proposal authorizing the adoption of the new contracts
- Fulfillment of the signed proposal
And definitely the changes should be discussed by CyberWay validators. So, please, pay attention.
1. Validators are to get rewards only when they produce blocks
Why
Presently, the validators reward consists of two parts. The first one that is 10 % of reward allocated for block production is transferred directly to validator. The rest of the reward is divided between the validators according to the votes they get from the users. From the second part, a validator can take a fee for his/her service and distribute the rest between the users that voted for him/her.
The second part of the award is paid to the validator, regardless of his/her activity (block production). This is to be changed.
The proposed change is intended to increase the social responsibility of validators.
2. Stake reward (the second part of the validator's reward) to be burned in case when validator is not producing blocks
Why
The second part of the validator's reward was introduced in order to stimulate validators’ activity. When non-producing blocks validators are not paid, this part of reward to be burned.
@cyberwaydev team puts forward burning unpaid CYBER tokens for stake.
3. The validator’s key to be reset automatically in case of missing blocks
Why
In order to have a smooth launch of CyberWay the function of resetting the validator’s key was not introduced. However, we believe that validators have to take seriously what they are doing and paid to do. The harmful behavior towards the network, namely the missing of blocks - has to be constantly prevented. So, the validators keys have to be reset automatically in this case.
We suggest this functionality to increase the stability of the network. The proposed time for resetting the key is 100 periods for changing the validator schedule (1 change occurs every 4N blocks, where N is the current number of validators in the schedule). Additionally, a restriction is placed on the recovery of the key in 1 day after its reset.
4. The validators have to decide on number of network validators
Why
When CyberWay was first introduced as a protocol, the number of validators with an uneven distribution of votes was to grow automatically. This functionality was added in order to ensure an easy growth of validators.
However, till now CyberWay has lots of inactive validators, the accounts that used to be witnesses of the former Golos blockchain and were transferred from Golos blockchain. The algorithm interprets this situation as a signal to grow the number of network validators.
@cyberwaydev proposes to cancel this algorithm and allow the validators to control the number of validators themselves (however, for security reasons the number of validators always has to be more than 21).
5. The votes have to be recast when the validator increases his/her fee
Why
There is an automatic reset of votes when the validator increases his/her fee for the service.The users have to make a conscious decision when they vote for validators, choosing a validator with the lowest percentage of reward allocated to the validator for block production.
If the validator decreases his/her fee then the votes given for him/her remain intact. CyberWay is keenly interested in validators focusing on the optimal cost ratio at which they can maintain a node, providing quality services to the blockchain, and attract new voters to vote for him/her.
@cyberwaydev wants users / voters be aware if the payments to them from the validators decreases and prevent situation when the validator changes contract for worse to users from his/her side.
6. The votes for inactive validators have to be reset
Why
When CyberWay was launched, all Golos blockchain witnesses as well as the votes casted for them were transferred to the CyberWay as they are. Some of these validators never appeared on the new platform in a role of validator. However, due to them there is a strong disproportion in terms of votes cast. The situation has to be corrected in order to give better chances to the new willing to work for CyberWay validators.
@cyberwaydev proposes to reset the votes cast for the validator after a month of his/her inactivity.
7. The input parameters of the cyber.stake contract to be fixed
Why
cyber.stake contract has a number of non-critical errors that has to be corrected. The errors are the following:
7.1 A number of methods that accept an asset with accuracy different from CYBER. Such methods include delegatevote, withdraw, delegateuse, recalluse, create, enable
7.2 When registering an agent (potentially active user), a number of parameters are not checked for a consistent state. These parameters include - balance (agent balance) and min_own_staked (minimum amount of own stake), candidate_key (candidate key for validators) and enabled (flag to enable block generation).
7.3 A missing verification that the total percentage of distributed proxy votes does not exceed 100%
7.4 The error that leads to the loss of staked tokens (CYBERs) during a vote for validators.
8. The procedure of rejecting a transaction launched using the cyber.msig contract to be introduced.
Why
The user of CyberWay or an application can use the contract cyber.msig in case it is necessary to collect several signatures for a transaction. The CyberWay validators use this contract explicitly to perform joint actions on behalf of cyber.prods. The same is true for the leaders of the Golos application.
Currently, the cyber.msig contract has the following features:
- The cyber.msig :: exec method starts a deferred transaction to execute a proposal as there is no other way to execute a formed transaction from a code of a smart contract. Each individual action from a transaction cannot be completed due to inline-action size restrictions.
- You can specify a deferred execution time when creating a transaction. It can be done for both personal subjective reasons, and if any of the accounts has an additional waiting period.
The problems with the current implementation:
- The cyber.msig :: exec method returns a positive result even if the transaction completed returns error
- It is difficult to detect an error occurred while executing a running transaction
- You can not cancel the transaction with deferred execution time.
It should be mentioned that EOS blockchain is planning to cancel deferred transactions as well as process eos.msig in accordance with the proposal:
https://github.com/EOSIO/spec-repo/blob/master/esr_deprecate_deferred.md
We propose:
- Getting rid of the deferred transactions in cyber.msig before this event occurs in EOS
- Implementing the cyber.msig :: schedule method which will keep the time when the transaction has to be executed instead of initiating a deferred transaction in the cyber.msig :: exec method
- cyber.msig :: exec can be called after cyber.msig :: schedule at the end of the deferred period
- cyber.msig :: exec can be called immediately if the deferred execution time of the transaction was not specified at the time of creating the proposal
- To allow calling the methods cyber.msig :: approve and cyber.msig :: unapprove after calling cyber.msig :: schedule, thus activating the ability to cancel the start of a deferred transaction in cyber.msig
- To build in an intrinsic function into CyberWay blockchain code to call a transaction directly from the smart contract code
- To start a transaction through the implemented intrinsic function using cyber.msig :: exec method which will return an execution error if the completion of the transaction is impossible.
Benefits expected after the implementation:
- The cyber.msig :: exec method will return an error directly to the user in case it happens during execution
- It will become possible to cancel deferred transactions created through cyber.msig
- It will be possible to create a transaction with a deferred execution time by calling cyber.msig :: exec method but it will be executed automatically.
9. A description when creating a proposal in cyber.msig. to be added
Why
Currently created proposal does not contain any description. It’s not convenient for those who creates them as they have to describe proposals somewhere else. Golos dApp leaders use cyber.msig to change Golos dApp settings, but are forced to to transmit information about them using Telegram.
We believe that this functionality has to increase transparency of decisions taken by leaders / validators.
10. The storage (“safe deposit”) has to be implemented within cyber.token system registry
Why
Many Golos blockchain users may remember such functionality as “safe deposit” on Golos blockchain. Our team suggests implementing the very same feature in the cyber.token system registry. By default, the “safe deposit” is turned off, but the user can turn it on. When the function is turned on:
- The assets continue to be stored on the user account
- All funds transferred to the user go to the “safe deposit”
- The user has the opportunity to determine the amount of liquid funds that can be used at any time
- The user has the ability to set a trusted account. If there are two signatures - a user and a trusted account, the transaction for withdrawing is performed
- Settings by the user:
1. The withdrawal period from the “safe deposit”
2. The maximum withdrawal period from a “safe deposit” is 30 days
3. Amount of assets available for withdrawal without restrictions
4. Trusted account
The implemented functionality will allow users to manage their assets better.
All the parties interested are invited to give their opinion on the proposed adjustments, especially CyberWay validators. Please, comment here and message in our Telegram channels until late Monday afternoon, January 27th so that we would definitely take them into account.
FYI: @creator, @lex, @alexna, @goloscore, @marina, @stihi-io, @golosio, @nickshtefan, @andreypf, @atticlabcway, @ropox, @solox, @vik, @denis-skripnik, @ladyzarulem, @micu, @fomka, @mommo, @zxcat, @siberianbear, @steepshot, @anyx, @arcange, @kulturagolosa, @xtar, @psk, @anarxist, @cryptocode, @golosboard, @zarathustra, @hustla, @celeste
Don't hesitate to join our community via:
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
Best regards, @cyberwaydev team: @andreypf, @marina, @maslenitsa, @muhazokotuha, @zxcat, @annaeq, @anazarov79, @kaynarov, @s-medvedev, @eugin