Releases: cyberway/cyberway.contracts
Cyberway.contracts v2.1.1 Release Notes
Cyberway.contracts v2.1.0 Release Notes
Cyberway.contracts v2.1.0 Release Notes
Blockchain development team announces the cyberway.contracts v2.1.0 version release. This version includes:
— Modification to cyber.msig contract.
— Modification to cyber.govern contract (voting for validators).
— New feature implemented.
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
proposalpreviously 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 theproposal. Given that, it was necessary to recreateproposal, 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:suspendcandaction.
- The new action
setshift( int8_t shift )has been implemented incyberway.governcontract.
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.
Cyberway system contracts v2.0.0 Release Notes
CyberWay contracts v2.0.0 Release Notes
The Golos•Core team presents a set of the system smart contracts implementing basic logic of CyberWay platform. CyberWay smart contracts communicate with each other in the form of actions.
The set includes the following system smart contracts: cyber.bios, cyber.msig, cyber.token, cyber.domain, cyber.stake, cyber.govern.
cyber.bios
cyber.bios contract contains actions for creation and processing of account names, bid auction of account names, management of account authorities.
cyber.domain
cyber.domain contract contains actions for creation and processing of domain names, the creation or removal of binding domain names to accounts, the creation of user names associated with an account, the change of domain name owners, as well as the purchase of domain names at bid auction.
cyber.msig
cyber.msig contract contains actions to sign multi-signature transaction and send it to the blockchain, as well as offer another user to sign the transaction.
cyber.stake
cyber.stake contract contains actions to vote for validators and dispose of user's votes and resources on their balance sheets most effectively. This contract also contains operations for transferring the voting right to another user during the voting.
cyber.token
cyber.token contract provides actions for managing tokens, creating new tokens, storing information about created tokens, as well as for transferring tokens between accounts.
cyber.govern
cyber.govern contract contains the logic of the voting for validators, as well as the logic for distributing validator's reward for blocks produced in accordance with DPoS algorithm.
Cyberway system contracts v2.0.0-rc2 Release Notes
Description is coming soon...
Cyberway system contracts v2.0.0-rc1 Release Notes
Description is coming soon...