You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The upcoming Casper Node 1.5.2 release includes several notable changes intended to improve the functionality of the Casper Node. The following are the key changes of relevance for our contract, SDK and dApp developers to put in context to test their contracts and applications on Testnet.
Please review the changes below (to Node and Casper Types), test your contracts on the Testnet(currently on 1.5.2) and refactor your contracts, SDK and dApps as per the changes specified in the previous section.
The Casper-Client v2.0.0 is released and published on crates.io for general availability. The memo is here and contains the RPC and other changes for node 1.5.2. This is the recommended version to use.
Casper-types (v3.0.0) is the latest version to use more information below.
JS SDK - 2.13.3 and above is the recommended version to use.
Please update your rust toolchain to use the 03-25-2023 nightly version.
Key Features:
Fast-sync feature enables a node to participate with the network much faster; historically, all nodes had to have all data from genesis to tip,with 1.5 that's no longer true. Nodes join as close to the tip of the chain as possible and then attempt to keep up with the tip. To participate in the validation process, a validating node needs a subset of blocks equal to the current tip minus the time to live (TTL) period, which is currently 24 hours in mainnet today but which we are reducing to 18 hours with 1.5.2.
We recommend that validators/operators use fast sync ttl mode and not full sync when joining the network - that will save disk space, additionally we observed sync ttl mode takes under 4 hours in general to sync to tip, thus enabling quicker participation.
New endpoints - Non-breaking changes
A groundbreaking new RPC endpoint “speculative_exec”, which enables contract developers to estimate the potential gas cost of a deploy and test it against live networks- including mainnet. Refer to the pull request here for more details. This needs to be enabled on a node by the node operator in the config.toml by setting 'enable-server' to true
Status endpoint added run mode. Refer to the pull request here for details.
A new RPC and REST endpoint "info_get_chainspec". Querying this endpoint will output the bytes of the chainspec.toml, which can then be used to view the contents of the chainspec by writing the output to a file, etc. More information can be found here.
The get-balance RPC has been deprecated and replaced with an enhanced version of the query-balance RPC. More details here.
The system now provides meaningful responses for missing block information when queried. The following endpoints are impacted:
chain_get_block
chain_get_block_transfers
chain_get_era_info_by_switch_block
chain_get_era_summary
chain_get_state_root_hash
query_balance
query_global_state
speculative_exec
state_get_account_info
state_get_auction_info
state_get_dictionary_item
state_get_item
A new version of Casper-types (v3.0.0), which includes several updates, including the addition of many new keys and stored value variants, a new type for UnbondingPurses, and an increase in DICTIONARY_ITEM_KEY_MAX_LENGTH from 64 to 128. There are possible breaking changes depending on the specific implementation, like new key variants and changes under the changed section, details here.
An exciting new feature, where smart contracts are allowed to load the already present authorized_keys across the wasm boundaries, this is particularly useful for contracts that use multi signatures and need to have role-based security in the contract logic. The contract_api/wasm ffi runtime is updated with a new function list_authorization_keys(), which returns a list of Account hashes that have signed the deploy in context , which from the calling account context is the authorization keys, here.
Max stack height value has been changed from 200 to 500. This also enables the usage of expensive 3rd party crates such as Odra and halo2 here.
In v1.5 CORS is implemented, making it possible to make RPC calls to a node directly from a browser here and here. By default, CORS is disabled on the node.
Max ttl value in chainspec updated from 1day to 18hours. For details, please view the discussion.
Delegator limit of 952 per validator introduced in v1.4.5 is increased to 1200, and the minimum delegation floor remains 500 CSPR.
Redelegate: We have removed the need to use 2 calls when un-delegating from a validator and delegating to another validator. Prior to V1.5.0, users had to make one call to undelegate await the un-bonding period and delegate to desired validator, however from this release onwards, un-delegating users will get an option to redelegate to another validator, while un-delegating from current validator. This change should also be reflected in the un-delegation workflow on the block explorer for the users of the network, more info here.
Operators should note that the non-validating nodes in 1.5 are more of an observer and do not participate in the network in the same way as in before 1.5, thus any metrics setup that depends on them will need to be modified likewise to be dependent on a validating node.
Node launcher is updated to always run the highest version of the node binary. Thus, for a new node user or if the global state file is corrupted and node is restarted, the launcher will run the highest version of the node binary. The operators now also have the option to force the launcher to start a specific version of the node here. Please note that nodes no longer connect to nodes that are not on the same protocol version.
Informational: After upgrading to 1.5 the first block will be an immediate switch block; thus system proposer unique key is 00 instead of 01 or 02, the user must be aware of this and should make necessary changes at their end to accommodate. Note, the switch block will have no deploys.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Summary
The upcoming Casper Node 1.5.2 release includes several notable changes intended to improve the functionality of the Casper Node. The following are the key changes of relevance for our contract, SDK and dApp developers to put in context to test their contracts and applications on Testnet.
Upgrade instructions and activation time.
Please review the changes below (to Node and Casper Types), test your contracts on the Testnet(currently on 1.5.2) and refactor your contracts, SDK and dApps as per the changes specified in the previous section.
Key Features:
Fast-sync feature enables a node to participate with the network much faster; historically, all nodes had to have all data from genesis to tip,with 1.5 that's no longer true. Nodes join as close to the tip of the chain as possible and then attempt to keep up with the tip. To participate in the validation process, a validating node needs a subset of blocks equal to the current tip minus the time to live (TTL) period, which is currently 24 hours in mainnet today but which we are reducing to 18 hours with 1.5.2.
We recommend that validators/operators use fast sync ttl mode and not full sync when joining the network - that will save disk space, additionally we observed sync ttl mode takes under 4 hours in general to sync to tip, thus enabling quicker participation.
New endpoints - Non-breaking changes
The system now provides meaningful responses for missing block information when queried. The following endpoints are impacted:
A new version of Casper-types (v3.0.0), which includes several updates, including the addition of many new keys and stored value variants, a new type for UnbondingPurses, and an increase in DICTIONARY_ITEM_KEY_MAX_LENGTH from 64 to 128. There are possible breaking changes depending on the specific implementation, like new key variants and changes under the changed section, details here.
An exciting new feature, where smart contracts are allowed to load the already present authorized_keys across the wasm boundaries, this is particularly useful for contracts that use multi signatures and need to have role-based security in the contract logic. The contract_api/wasm ffi runtime is updated with a new function list_authorization_keys(), which returns a list of Account hashes that have signed the deploy in context , which from the calling account context is the authorization keys, here.
Max stack height value has been changed from 200 to 500. This also enables the usage of expensive 3rd party crates such as Odra and halo2 here.
In v1.5 CORS is implemented, making it possible to make RPC calls to a node directly from a browser here and here. By default, CORS is disabled on the node.
Max ttl value in chainspec updated from 1day to 18hours. For details, please view the discussion.
Delegator limit of 952 per validator introduced in v1.4.5 is increased to 1200, and the minimum delegation floor remains 500 CSPR.
Redelegate: We have removed the need to use 2 calls when un-delegating from a validator and delegating to another validator. Prior to V1.5.0, users had to make one call to undelegate await the un-bonding period and delegate to desired validator, however from this release onwards, un-delegating users will get an option to redelegate to another validator, while un-delegating from current validator. This change should also be reflected in the un-delegation workflow on the block explorer for the users of the network, more info here.
Operators should note that the non-validating nodes in 1.5 are more of an observer and do not participate in the network in the same way as in before 1.5, thus any metrics setup that depends on them will need to be modified likewise to be dependent on a validating node.
Node launcher is updated to always run the highest version of the node binary. Thus, for a new node user or if the global state file is corrupted and node is restarted, the launcher will run the highest version of the node binary. The operators now also have the option to force the launcher to start a specific version of the node here.
Please note that nodes no longer connect to nodes that are not on the same protocol version.
Informational: After upgrading to 1.5 the first block will be an immediate switch block; thus system proposer unique key is 00 instead of 01 or 02, the user must be aware of this and should make necessary changes at their end to accommodate. Note, the switch block will have no deploys.
More detailed release notes is here.
Beta Was this translation helpful? Give feedback.
All reactions