Releases: eosnetworkfoundation/eos-system-contracts
EOS System Contracts v3.5.0 Release Notes
This release focuses on REX changes.
Overview
Following the tokenomics update this release changes some minor REX system mechanics to make it easier to use, enforce lockup, and have a longer lockup duration.
Bpay Contract
A new contract that gets deployed on top of the eosio.bpay account.
This contract allows the distribution of system fees that flow into it into the hands of the top 21 BPs.
claimrewards
Claim rewards for a block producer.
You must have been producing at the moment that rewards were catalogued in the contract.
void claimrewards( const name owner );REX changes (system contract)
The core changes to REX are:
- Remove voting requirements
- Change 4 day lockup to dynamic lockup setting
- Will be 21 days on first deployment MSIG
- Immediately move all REX to the savings bucket
setrexmature
Sets configuration options for REX.
void setrexmature(
const std::optional<uint32_t> num_of_maturity_buckets,
const std::optional<bool> sell_matured_rex,
const std::optional<bool> buy_rex_to_savings
);num_of_maturity_buckets- Sets the number of days for lockupsell_matured_rex- Whether or not matured REX is sold immediatelybuy_rex_to_savings- Whether or not bought REX is moved immediately to savings
Reward contract
A new contract that gets deployed on top of the eosio.reward account.
This contract distributes rewards from the staking rewards bucket to a given set of strategies.
This new contract handles the distribution of fees to configurable destinations and rates.
This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.
Tables
struct strategies_row {
name strategy;
uint16_t weight;
uint64_t primary_key() const { return strategy.value; }
};The strategies table is always scoped to self (eosio.reward).
setstrategy
Available strategies:
eosio.rex- Distributes to the REX systemeosio.bonds- Distributes to EOS bonds
void setstrategy(
const name strategy,
const uint16_t weight
)Sets (create or update) a strategy's weight into effect for subsequent distributions.
strategy- Must be one of the predefined strategies aboveweight- A number proportional to the total weight of all strategies
delstrategy
void delstrategy( const name strategy );Removes a strategy from distributions.
distribute
void distribute();Claims its rewards from eosio.saving and distributes them to the designated strategies based on their weights.
Static methods
static uint32_t get_total_weight(
const name contract = "eosio.reward"_n
);The get_total_weight static method returns the sum of all weights for all configured strategies.
WASM Hashes
eosio.system - ad12d594b75bdb4ab84c568f29d97f1ce82f50cca55a1f8a7d0406d4728d0e4b
eosio.bpay - 90a0db1f7a4d1a7bccc5a5400edaa489ae685e0cd5b052de8440096139638efc
eosio.reward - 49155e7e98991d9dad21970bb1d1cfec0d5ab77e842feaaa0dac1d1a91180cc7
Contributors
Special thanks to the contributors that worked on this release:
Full Changelog: v3.4.0...v3.5.0
Contributors
Assets 2
EOS System Contracts v3.5.0 Pre-Release Notes (RC2)
A patch release to align bpay reward split by actual producer count.
WASM Hashes
eosio.bpay - 90a0db1f7a4d1a7bccc5a5400edaa489ae685e0cd5b052de8440096139638efc
Full Changelog: v3.5.0-rc1...v3.5.0-rc2
EOS System Contracts v3.5.0 Pre-Release Notes
This release focuses on REX changes.
Overview
Following the tokenomics update this release changes some minor REX system mechanics to make it easier to use, enforce lockup, and have a longer lockup duration.
Bpay Contract
A new contract that gets deployed on top of the eosio.bpay account.
This contract allows the distribution of system fees that flow into it into the hands of the top 21 BPs.
claimrewards
Claim rewards for a block producer.
You must have been producing at the moment that rewards were catalogued in the contract.
void claimrewards( const name owner );REX changes (system contract)
The core changes to REX are:
- Remove voting requirements
- Change 4 day lockup to dynamic lockup setting
- Will be 21 days on first deployment MSIG
- Immediately move all REX to the savings bucket
setrexmature
Sets configuration options for REX.
void setrexmature(
const std::optional<uint32_t> num_of_maturity_buckets,
const std::optional<bool> sell_matured_rex,
const std::optional<bool> buy_rex_to_savings
);num_of_maturity_buckets- Sets the number of days for lockupsell_matured_rex- Whether or not matured REX is sold immediatelybuy_rex_to_savings- Whether or not bought REX is moved immediately to savings
Reward contract
A new contract that gets deployed on top of the eosio.reward account.
This contract distributes rewards from the staking rewards bucket to a given set of strategies.
This new contract handles the distribution of fees to configurable destinations and rates.
This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.
Tables
struct strategies_row {
name strategy;
uint16_t weight;
uint64_t primary_key() const { return strategy.value; }
};The strategies table is always scoped to self (eosio.reward).
setstrategy
Available strategies:
eosio.rex- Distributes to the REX systemeosio.bonds- Distributes to EOS bonds
void setstrategy(
const name strategy,
const uint16_t weight
)Sets (create or update) a strategy's weight into effect for subsequent distributions.
strategy- Must be one of the predefined strategies aboveweight- A number proportional to the total weight of all strategies
delstrategy
void delstrategy( const name strategy );Removes a strategy from distributions.
distribute
void distribute();Claims its rewards from eosio.saving and distributes them to the designated strategies based on their weights.
Static methods
static uint32_t get_total_weight(
const name contract = "eosio.reward"_n
);The get_total_weight static method returns the sum of all weights for all configured strategies.
WASM Hashes
eosio.system - ad12d594b75bdb4ab84c568f29d97f1ce82f50cca55a1f8a7d0406d4728d0e4b
eosio.bpay - 32181be084b539d882d92ff85a3d0b9962c8cb7292902cc558bc9a77dedd8fa9
eosio.reward - 49155e7e98991d9dad21970bb1d1cfec0d5ab77e842feaaa0dac1d1a91180cc7
Contributors
Special thanks to the contributors that worked on this release:
Full Changelog: v3.4.0...v3.5.0-rc1
Contributors
Assets 2
EOS System Contracts v3.4.0 Release Notes
This release focuses on tokenomic changes.
Overview
Following a discussion around a tokenomics proposal this release introduces changes required to support a significant update in EOS tokenomics that changes the way EOS inflation and distribution function. These system smart contract changes are required to create an onchain multi-sig that block producers will vote on to approve or oppose the proposal.
Token Changes
The proposal centers around a lowering of the maximum supply to 2.1b tokens, and an issuing up to that target number instead of a slow inflation in order to create a fixed supply.
New actions on the eosio.token contract are required to make that possible, as well as some core changes to the way that block producers are paid when the token's maximum supply equals the current supply.
setmaxsupply
void setmaxsupply(
const name& issuer,
const asset& maximum_supply
);Sets the maximum supply of the token to maximum_supply.
The issuer must match the original issuer of the token.
issuefixed
void issuefixed(
const name& to,
const asset& supply,
const string& memo
);Issues the delta between the current supply and the supply parameter, and allocates those tokens to the to account.
A memo can also be included.
Changes to block producer rewards and eosio.saving
When a block producer calls claimrewards it will now check if the current supply is equal to
the maximum supply, and if so then it will use the tokens that the eosio account holds.
If not, then it will continue to inflate as it did prior to these changes.
New static methods
To make it easy for external parties to integrate with these changes, and to keep the contract clean internally two new static methods were introduced.
static asset get_max_supply(
const name& token_contract_account,
const symbol_code& sym_code
);
static name get_issuer(
const name& token_contract_account,
const symbol_code& sym_code
);Vesting Schedules
In order to distribute the fixed tokens to the relevant parties a vesting schedule is introduced. This allows dynamically setting date/rate pairs that define how much of the existing supply is distributed to block producers and the eosio.saving contract.
schedules table
struct schedules_info {
time_point_sec start_time;
double continuous_rate;
uint64_t primary_key() const { return start_time.sec_since_epoch(); }
};The schedules table holds the time/rate pairs, and is always scoped to self (eosio).
setschedule
void setschedule(
const time_point_sec start_time,
double continuous_rate
);Adds or updates a scheduled vesting distribution rate at a given date to the schedules table.
start_time- The date this rate can be appliedcontinuous_rate- A percentage of the current supply divided by 100
An example of a 5% distribution rate:
{"start_time": "2024-06-01T00:00:00Z", "continuous_rate": 0.05}delschedule
void delschedule(
const time_point_sec start_time
);Deletes a schedule if it exists, or fails.
execschedule
void execschedule();Executes the next schedule sorted by closest date. The schedule's start_time must have already passed.
setpayfactor
void setpayfactor(
int64_t inflation_pay_factor,
int64_t votepay_factor
);This new action is identical to the setinflation action except that it does not allow changing the annual_rate which would then compute the continuous_rate, as that is now set through vesting schedules.
This allows modifying the block producer bpay, vpay, and eosio.saving splits.
For more information about how these parameters work, see the comments on the code here.
unvest
void unvest(
const name account,
const asset unvest_net_quantity,
const asset unvest_cpu_quantity
);This action retires the unvested tokens from the b1 account, enforces only the unvested tokens can be touched, and updates the locking logic to allow b1 to take any remaining tokens that have already vested after the unvested tokens have been retired.
Fees Upgrade
In order to allow distribution of system fees to new buckets (block producers, rex, and RAM) and pushing fees from new origins, changes to the system contracts have been made and a new eosio.fees contract will be deployed.
System contract changes and new actions
donatetorex
void donatetorex(
const name& payer,
const asset& quantity,
const std::string& memo
);This allows anyone to donate EOS into the REX markets. Since a new eosio.fees contract will be controlling the distribution of fees the system contract needs a way to accept donations from external entities as previously it was only possible internally.
Important to note that this does not require a token transfer, and instead EOS will be taken from the account the same way as the system does in other actions like buyram.
buyramburn
struct action_return_buyram {
name payer;
name receiver;
asset quantity;
int64_t bytes_purchased;
int64_t ram_bytes;
asset fee;
};
action_return_buyram buyramburn(
const name& payer,
const asset& quantity,
const std::string& memo
);This action buys ram and burns it within a single action instead of having to call multiple actions.
logsystemfee
void logsystemfee(
const name& protocol,
const asset& fee,
const std::string& memo
);The logsystemfee adds another log to the system contracts that helps track fees, where they are coming from and where they are going. It is called inline in every action that would incur fees (such as name auctions, or ram market trades).
Changes to return values and logs
Both logbuyram and logsellram now have a const binary_extension<asset>& fee at the end of their parameter lists. This helps track that fee for external parties.
The action_return_buyram and action_return_sellram return value structs have also been modified to add an asset fee;
Static methods
New methods are exposed on eosio.system.hpp to exposed if REX is available or not. These are aimed at helping integrators that want to use the new donatetorex action.
static bool rex_system_initialized(
name system_account = "eosio"_n
);
static bool rex_available(
name system_account = "eosio"_n
);The get_core_symbol method was also modified to make it simpler to use.
static symbol get_core_symbol(
name system_account = "eosio"_n
);eosio.fees contract
This new contract handles the distribution of fees to configurable destinations and rates.
This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.
Tables
struct strategies_row {
name strategy;
uint16_t weight;
uint64_t primary_key() const { return strategy.value; }
};The strategies table is always scoped to self (eosio).
struct settings_row {
uint32_t epoch_time_interval = 600;
time_point_sec next_epoch_timestamp;
};The settings table is always scoped to self (eosio).
init
void init(
const uint32_t epoch_time_interval
);Initializes the eosio.fees contract and sets the interval allowed for distributions (in seconds).
setstrategy
Available strategies:
buyramburn- Buys ram and burns itbuyramself- Buy ram foreosio.feesand holds itdonatetorex- Sends fees to REXeosio.bpay- Sends fees to be paid to producers
void setstrategy(
const name strategy,
const uint16_t weight
)Sets (create or update) a strategy's weight into effect for subsequent distributions.
strategy- Must be one of the predefined strategies aboveweight- A number proportional to the total weight of all strategies
delstrategy
void delstrategy( const name strategy );Removes a strategy from distributions.
distribute
void distribute();Distributes accumulated fees to the designated strategies based on their weights once every epoch period. The next epoch is updated to be a distance of epoch_time_interval from the second this action is called.
Static methods
static uint16_t get_total_weight(
const name contract = "eosio.fees"_n
);The get_total_weight static method returns the sum of all weights for all configured strategies.
WASM Hashes
eosio.system - b78e2bfcceea88b337f195bb1e362a33cb5365aaaf02a2c32bcbf6698b1b832f
eosio.token - 0a16e1dac533c4558698c8754f41219839ba2a2b75e517e65ea2537f76681f49
Contributors
Special thanks to the contributors that worked on this release:
Full Changelog: https://github.com/eosnetwork...
Contributors
Assets 2
EOS System Contracts v3.4.0 Pre-Release Notes
This release focuses on tokenomic changes.
Overview
Following a discussion around a tokenomics proposal this release introduces changes required to support a significant update in EOS tokenomics that changes the way EOS inflation and distribution function. These system smart contract changes are required to create an onchain multi-sig that block producers will vote on to approve or oppose the proposal.
Token Changes
The proposal centers around a lowering of the maximum supply to 2.1b tokens, and an issuing up to that target number instead of a slow inflation in order to create a fixed supply.
New actions on the eosio.token contract are required to make that possible, as well as some core changes to the way that block producers are paid when the token's maximum supply equals the current supply.
setmaxsupply
void setmaxsupply(
const name& issuer,
const asset& maximum_supply
);Sets the maximum supply of the token to maximum_supply.
The issuer must match the original issuer of the token.
issuefixed
void issuefixed(
const name& to,
const asset& supply,
const string& memo
);Issues the delta between the current supply and the supply parameter, and allocates those tokens to the to account.
A memo can also be included.
Changes to block producer rewards and eosio.saving
When a block producer calls claimrewards it will now check if the current supply is equal to
the maximum supply, and if so then it will use the tokens that the eosio account holds.
If not, then it will continue to inflate as it did prior to these changes.
New static methods
To make it easy for external parties to integrate with these changes, and to keep the contract clean internally two new static methods were introduced.
static asset get_max_supply(
const name& token_contract_account,
const symbol_code& sym_code
);
static name get_issuer(
const name& token_contract_account,
const symbol_code& sym_code
);Vesting Schedules
In order to distribute the fixed tokens to the relevant parties a vesting schedule is introduced. This allows dynamically setting date/rate pairs that define how much of the existing supply is distributed to block producers and the eosio.saving contract.
schedules table
struct schedules_info {
time_point_sec start_time;
double continuous_rate;
uint64_t primary_key() const { return start_time.sec_since_epoch(); }
};The schedules table holds the time/rate pairs, and is always scoped to self (eosio).
setschedule
void setschedule(
const time_point_sec start_time,
double continuous_rate
);Adds or updates a scheduled vesting distribution rate at a given date to the schedules table.
start_time- The date this rate can be appliedcontinuous_rate- A percentage of the current supply divided by 100
An example of a 5% distribution rate:
{"start_time": "2024-06-01T00:00:00Z", "continuous_rate": 0.05}delschedule
void delschedule(
const time_point_sec start_time
);Deletes a schedule if it exists, or fails.
execschedule
void execschedule();Executes the next schedule sorted by closest date. The schedule's start_time must have already passed.
setpayfactor
void setpayfactor(
int64_t inflation_pay_factor,
int64_t votepay_factor
);This new action is identical to the setinflation action except that it does not allow changing the annual_rate which would then compute the continuous_rate, as that is now set through vesting schedules.
This allows modifying the block producer bpay, vpay, and eosio.saving splits.
For more information about how these parameters work, see the comments on the code here.
unvest
void unvest(
const name account,
const asset unvest_net_quantity,
const asset unvest_cpu_quantity
);This action retires the unvested tokens from the b1 account, enforces only the unvested tokens can be touched, and updates the locking logic to allow b1 to take any remaining tokens that have already vested after the unvested tokens have been retired.
Fees Upgrade
In order to allow distribution of system fees to new buckets (block producers, rex, and RAM) and pushing fees from new origins, changes to the system contracts have been made and a new eosio.fees contract will be deployed.
System contract changes and new actions
donatetorex
void donatetorex(
const name& payer,
const asset& quantity,
const std::string& memo
);This allows anyone to donate EOS into the REX markets. Since a new eosio.fees contract will be controlling the distribution of fees the system contract needs a way to accept donations from external entities as previously it was only possible internally.
Important to note that this does not require a token transfer, and instead EOS will be taken from the account the same way as the system does in other actions like buyram.
buyramburn
struct action_return_buyram {
name payer;
name receiver;
asset quantity;
int64_t bytes_purchased;
int64_t ram_bytes;
asset fee;
};
action_return_buyram buyramburn(
const name& payer,
const asset& quantity,
const std::string& memo
);This action buys ram and burns it within a single action instead of having to call multiple actions.
logsystemfee
void logsystemfee(
const name& protocol,
const asset& fee,
const std::string& memo
);The logsystemfee adds another log to the system contracts that helps track fees, where they are coming from and where they are going. It is called inline in every action that would incur fees (such as name auctions, or ram market trades).
Changes to return values and logs
Both logbuyram and logsellram now have a const binary_extension<asset>& fee at the end of their parameter lists. This helps track that fee for external parties.
The action_return_buyram and action_return_sellram return value structs have also been modified to add an asset fee;
Static methods
New methods are exposed on eosio.system.hpp to exposed if REX is available or not. These are aimed at helping integrators that want to use the new donatetorex action.
static bool rex_system_initialized(
name system_account = "eosio"_n
);
static bool rex_available(
name system_account = "eosio"_n
);The get_core_symbol method was also modified to make it simpler to use.
static symbol get_core_symbol(
name system_account = "eosio"_n
);eosio.fees contract
This new contract handles the distribution of fees to configurable destinations and rates.
This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.
Tables
struct strategies_row {
name strategy;
uint16_t weight;
uint64_t primary_key() const { return strategy.value; }
};The strategies table is always scoped to self (eosio).
struct settings_row {
uint32_t epoch_time_interval = 600;
time_point_sec next_epoch_timestamp;
};The settings table is always scoped to self (eosio).
init
void init(
const uint32_t epoch_time_interval
);Initializes the eosio.fees contract and sets the interval allowed for distributions (in seconds).
setstrategy
Available strategies:
buyramburn- Buys ram and burns itbuyramself- Buy ram foreosio.feesand holds itdonatetorex- Sends fees to REXeosio.bpay- Sends fees to be paid to producers
void setstrategy(
const name strategy,
const uint16_t weight
)Sets (create or update) a strategy's weight into effect for subsequent distributions.
strategy- Must be one of the predefined strategies aboveweight- A number proportional to the total weight of all strategies
delstrategy
void delstrategy( const name strategy );Removes a strategy from distributions.
distribute
void distribute();Distributes accumulated fees to the designated strategies based on their weights once every epoch period. The next epoch is updated to be a distance of epoch_time_interval from the second this action is called.
Static methods
static uint16_t get_total_weight(
const name contract = "eosio.fees"_n
);The get_total_weight static method returns the sum of all weights for all configured strategies.
Contributors
Special thanks to the contributors that worked on this release:
Full Changelog: v3.3.0...v3.4.0-rc1
Contributors
Assets 2
EOS System Contracts v3.3.0 Release Notes
This release contains new features.
Usecases
Ram Transfer Usecases
-
Improves EOS account creation:
a. Createnewaccountusingramtransferinstead ofbuyramorbuyrambytes -
Improves RAM token wrapper development:
a. Receive RAM without buy/sell actions (no fees to transferring RAM)
b. Existing RAM supply can be transferred to existing RAM token wrappers
c. DeFi composability usingmemofield
New Ram Actions
Ram Transfer
New RAM system contract action to transfer RAM from one account to another without any fees.
- Charges 0% fee to transfer
- Only uncommited RAM can be transferred
- Notify
to&fromusingrequire_recipient - Memo cannot exceed 256 bytes
- returns struct
action_return_ramtransfer
Ram Burn
New RAM system contract action to burn RAM from owner account.
- Burned RAM is transferred to
eosio.nullaccount - Should have no impact on RAM Bancor market, RAM supply should remain unchanged
- returns struct
action_return_ramtransfer
Ram Logging
Add buy RAM logging by including additional inline actions and notifications via the use of require_recipient.
bytes & quant are computed values based on Bancor algorithm market.
This allows payer or receiver to confirm exact bytes sent/received via notifications.
Buy Ram
- returns struct
action_return_buyram
Buy Ram Bytes
- returns struct
action_return_buyram
Buy Ram Self
- returns struct
action_return_buyram
Sell Ram
- returns struct
action_return_sellram
API Changes
- Add
require_recipient(receiver)onbuyram&buyrambytesactions
ACTION: ramtransfer
from {name}to {name}bytes {int64}memo {string}
ACTION: ramburn
owner {name}bytes {int64}memo {string}
ACTION: logbuyram
/**
* Logging for buyram & buyrambytes action
*
* @param payer - the ram buyer,
* @param receiver - the ram receiver,
* @param quantity - the quantity of tokens to buy ram with.
* @param bytes - the quantity of ram to buy specified in bytes.
* @param ram_bytes - the ram bytes held by receiver after the action.
*/
[[eosio::action]]
void logbuyram( const name& payer, const name& receiver, const asset& quantity, int64_t bytes, int64_t ram_bytes );ACTION: buyram buyrambytes buyramself
return struct action_return_buyram
"name": "action_return_buyram",
"base": "",
"fields": [
{
"name": "payer",
"type": "name"
},
{
"name": "receiver",
"type": "name"
},
{
"name": "quantity",
"type": "asset"
},
{
"name": "bytes_purchased",
"type": "int64"
},
{
"name": "ram_bytes",
"type": "int64"
}
]
ACTION: ramtransfer ramburn
returns struct action_return_ramtransfer
"name": "action_return_ramtransfer",
"base": "",
"fields": [
{
"name": "from",
"type": "name"
},
{
"name": "to",
"type": "name"
},
{
"name": "bytes",
"type": "int64"
},
{
"name": "from_ram_bytes",
"type": "int64"
},
{
"name": "to_ram_bytes",
"type": "int64"
}
]
ACTION: sellram
returns struct action_return_sellram
"name": "action_return_sellram",
"base": "",
"fields": [
{
"name": "account",
"type": "name"
},
{
"name": "quantity",
"type": "asset"
},
{
"name": "bytes_sold",
"type": "int64"
},
{
"name": "ram_bytes",
"type": "int64"
}
]
Preconditions
Ram Transfer Preconditions
frommust have sufficientram_bytesprior to transferfromdecreaseram_bytesbybytestomust existstoaccount can be a contracttoaccount can have zero available RAM bytestoincreaseram_bytesbybytes- handle
ram_managedaccounts
Ram Burn Preconditions
- Same conditions as
ramtransferaction
Further details on changes since last release
Special thanks to the contributors that worked on this release:
Full list of changes since last release
PRs
Set version to rc1 for release of ram_actions by ericpassmore in #114
Bump release to next version v3.3.0-dev by ericpassmore in #94
New ram_actions functions by DenisCarriere in #112
Full Changelog: v3.2.0...v3.3.0
Contributors
Assets 2
EOS System Contracts v3.2.0 Release Notes
This minor release contains removal of deferred transactions, test updates, and minor bug fixes.
Remove of Deferred Transactions
Removal of Deferred Transactions from System Contract
PRs
Within the system contracts the actions system_contract::bidname, system_contract::buyram, wrap::exec no longer issue deferred transactions. This is a change for the system_contract::bidname action, and failed bids will need an explict refund. For the system_contract::buyram action the default behavior remains unchanged. The wrap::exec action has been rewritten to use send instead of send_deferred.
Test Updates
PRs
- (62) Minor cleanup of eosio.token tests
- (67) Updated libtester removing no longer needed
runtime.hlibary - (68) Missed a referrence, updated libtester removing no longer needed
runtime.hlibary - (75) Fix powerup test to match leap update to explicit time_point_sec conversion
- (78) Fix misspelling in wasmcfg
Libtester has been undated to no longer use Runtime.h
Continuous Integration Updates
PRs
Documentation Updates
Further details on changes since last release
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
- (57) Github workflow update to automate triage lable.
- (59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.
- (62)) Minor cleanup of eosio.token tests
- (63) Documentation cleanup to remove old reasource staking references
- (67) Updated libtester removing no longer needed
runtime.hlibary - (68) Missed a referrence, updated libtester removing no longer needed
runtime.hlibary - (75) Fix powerup test to match leap update to explicit time_point_sec conversion
- (78) Fix misspelling in wasmcfg
- (88) Remove Deferred Transactions from System Contract
Full Changelog: v3.1.1...v3.2.0
Contributors
Assets 2
EOS System Contracts v3.2.0 Pre-Release Notes
This minor release contains removal of deferred transactions, test updates, and minor bug fixes.
Remove of Deferred Transactions
Removal of Deferred Transactions from System Contract
PRs
Within the system contracts the actions system_contract::bidname, system_contract::buyram, wrap::exec no longer issue deferred transactions. This is a change for the system_contract::bidname action, and failed bids will need an explict refund. For the system_contract::buyram action the default behavior remains unchanged. The wrap::exec action has been rewritten to use send instead of send_deferred.
Test Updates
PRs
- (62) Minor cleanup of eosio.token tests
- (67) Updated libtester removing no longer needed
runtime.hlibary - (68) Missed a referrence, updated libtester removing no longer needed
runtime.hlibary - (75) Fix powerup test to match leap update to explicit time_point_sec conversion
- (78) Fix misspelling in wasmcfg
Libtester has been undated to no longer use Runtime.h
Continuous Integration Updates
PRs
Documentation Updates
Further details on changes since last release
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
- (57) Github workflow update to automate triage lable.
- (59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.
- (62)) Minor cleanup of eosio.token tests
- (63) Documentation cleanup to remove old reasource staking references
- (67) Updated libtester removing no longer needed
runtime.hlibary - (68) Missed a referrence, updated libtester removing no longer needed
runtime.hlibary - (75) Fix powerup test to match leap update to explicit time_point_sec conversion
- (78) Fix misspelling in wasmcfg
- (88) Remove Deferred Transactions from System Contract
Full Changelog: v3.1.1...v3.2.0-rc1
Contributors
Assets 2
EOS System Contracts v3.1.1 Release Notes
This patch release contains bug fixes.
Read on for details.
Bug fixes
Replace std::deque and std::map with std::vector in contract actions and tables
Within the core contract, the fields rex_maturities and return_buckets within REX tables were unnecessarily utilizing std::deque and/or std::map to sequence objects. These have been replaced with std::vector with no change to the behavior of the core contract.
Update ICON_BASE_URL to a working address
ICON_BASE_URL is a prefix used for the icon URLs captured in the generated Ricardians for the system contracts. ICON_BASE_URL was previously being to set http://127.0.0.1/ricardian_assets/eosio.contracts/icons, which was not functional. The address has been updated to https://raw.githubusercontent.com/eosnetworkfoundation/eos-system-contracts/main/contracts/icons.
Further details on changes since last release
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v3.1.0...v3.1.1
Contributors
Assets 2
EOS System Contracts v3.1.0 Release Notes
Release 3.1.0 includes several changes to the core contract. It also introduces the boot contract. Other contracts remain unchanged in behavior since the last stable release.
Read on for details.
New features
Boot contract
The boot contract is a new contract introduced in this release that serves the purpose of bootstrapping a new blockchain, especially for testing purposes.
The core contract in its current state now depends on several host functions that are only made available on the blockchain after activation of certain protocol features. Without activation of the protocol features that make available the necessary host functions, it is not possible to deploy a contract that requires those host functions. However, activation of nearly all protocol features (with the exception of PREACTIVATE_FEATURE) require a privileged call to the preactivate_feature host function which is made accessible to users through the activate action within the core contract.
To break this Catch-22, the boot contract includes a similar activate action (which creates a dependency on the PREACTIVATE_FEATURE protocol feature), but it does not include any other features that would introduce dependencies on further protocol features. Therefore, it should always be possible to activate the PREACTIVATE_FEATURE protocol feature on a fresh EOSIO blockchain, deploy the boot contract to the privileged eosio account, and then use its activate action to activate additional protocol features that are needed for the deployment of the core contract.
Core contract
The core contract refers to the contract meant to be deployed to the privileged eosio account which provides many of the functions that users have come to expect from popular EOSIO blockchains, such as delegate proof of stake (DPoS), PowerUp, and more.
This release adds new functionality to the core contract.
Optionally restrict permission changes
The new action limitauthchg allows an account to opt into or out of restrictions on permission changes to their account through authorization additional constraints on the actions updateauth, deleteauth, linkauth, and unlinkauth. Each of those four auth-related actions now have a new binary extension argument: authorized_by (which is the name of a permission on the account). This may be either absent or empty for accounts which have not opted into limitauthchg.
An account may opt into the new restrictions by calling limitauthchg with a non-empty allow_perms or a non-empty disallow_perms (both cannot be non-empty). They may opt out again by calling limitauthchg with both an empty allow_perms and an empty disallow_perms.
If allow_perms is non-empty for an account, then the authorized_by permission name of an auth-related action involving that account must be contained in the allow_perms list; otherwise the transaction will abort. If disallow_perms is non-empty for an account, then the authorized_by permission name of an auth-related action involving that account must not be contained in the disallow_perms list; otherwise the transaction will abort. In either case, the core contract verifies that the specific permission of the account named by authorized_by is the one that authorizes the auth-related action.
Among its several uses, the limitauthchg action enables protection against one of the denial of service attack vectors of a particular contract pays solution in which a private key with restricted access to the CPU/NET resources paid for by an application is publicly distributed with the application code.
Configure WASM limits
Assuming CONFIGURABLE_WASM_LIMITS2=ON (which it is by default), the core contract will now include a new wasmcfg action which supports (and depends on) the CONFIGURABLE_WASM_LIMITS2 protocol feature.
This action allows increasing some of the limits enforced on WASM contracts by calling the action with wasmcfg("high"). The WASM limits can be restored back to the original values by calling the action with wasmcfg("low") or wasmcfg("default").
low limits during the window of time that the high limits were enforced. In addition, some of the limits are enforced at run-time, so bringing the configuration back down from high to low may break the contracts that were deployed and tested while the configuration was at high.
Tracked recent block information
The core contract has been updated to keep track within a blockinfo table the block height and timestamp of recent blocks in the blockchain's history. There is a rolling window tracking a maximum number of recent blocks (that max is currently hard-coded to 10), and the core contract will automatically garbage collect table entries for blocks that fall outside of that window.
The blockinfo table schema is a publicly specified interface and is versioned, so contracts are able to look into it to get information about recent blocks. The block_info.hpp header file is provided which can be included into other contracts to allow them to access information in the blockinfo table including via the convenient get_latest_block_batch_info function. The get_latest_block_batch_info can be used as an alternative means to get the current block height (under the assumption that the onblock has not failed) which can be useful in blockchains that have not activated the GET_BLOCK_NUM protocol feature.
Other changes
Core contract
The core contract also includes additional changes and bug fixes.
Memo field added to setcode and setabi
This additional field can help contract authors track deployed contract versions.
Enhanced setparams
Assuming SYSTEM_BLOCKCHAIN_PARAMETERS=ON (which it is by default), the setparams action is modified to take an augmented structure of parameters which now includes max_action_return_value_size (related to the ACTION_RETURN_VALUE protocol feature). The implementation of the action is also modified to use the new and more flexible set_parameters_packed host function, which is only available if the BLOCKCHAIN_PARAMETERS protocol feature has been activated.
REX rounding bug
This release includes a backport of EOSIO/eosio.system#54 (originally authored by @deckb) which works around the REX rounding bug that stopped accounts from selling REX.
Accounts may now use the voteupdate action to restore their account.
In addition, the bug has been fixed so it does not impact more accounts in the future.
Voting and vesting patches for b1 account
The core contract change which was used by BPs on the EOS network to freeze vesting of core tokens to the b1 account has been reproduced in the core contract made available in this release.
Updated Ricardians
The Ricardians of the core contract now include the EOS User Agreement (EUA) as well as the Block Producer Agreement which is relevant to the regproducer and regproducer2 actions.
Building, compatibility, and upgrading
Building
Instructions for building the system contracts are provided in the README.
This release depends on on CDT 3.0 at a minimum. CDT 3.0.0 is available.
Building the tests also requires Leap 3.1 at a minimum. Leap 3.1.0 is available. Building the tests is optional; see README for how to build with or without tests.
For now, the Leap dependency must be satisfied with a build of Leap 3.1 from source. Alternatively, look into DUNE for another way to build the contracts without needing to build CDT or Leap from source.
Note that this release has also simplified the build.sh script and dropped some options. You can still run it with no options provided if you have CDT installed on your system and do not wish to build the ...
