Attention: Contract Authors, dApp Developers, SDK Maintainers and Validators

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. We will provide a more comprehensive update on the general changes closer to the commencement of the Mainnet activation.

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.

Note:

•  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.14 and above is the recommended version to use.
• Please update your rust toolchain to use the 03-25-2023 nightly version.

Also, please refer to the Casper Node v1.5.2 Resources section for Testnet Activation-specific activation time.

Key Features:

1. 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.

2. New endpoints - Non-breaking changes

• We added a significant feature via an RPC endpoint “speculative_exec”, which enables contract developers to estimate the potential gas cost of a deploy and test it on the testnet and integration networks. Refer to the pull request here for more details
• 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
• We have deprecated the get-balance RPC and replaced it with an enhanced version of the query-balance RPC. More details here

3. The system now provides meaningful responses for missing block information when queried, the following are endpoints which do.

• 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

4. We are also releasing a new version of Casper-types (v3.0.0), there are 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. And there are possible breaking changes depending on your specific implementation, like new key variants and changes under the changed section, details here.

5.Added 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.

6. 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.

7. In v1.5 we have enabled CORS, making it possible to make RPC calls to a node from a browser here and here.

8. Max ttl value in chainspec updated from 1day to 18hours.

9. Delegator limit of 952 per validator introduced in v1.4.5 is increased to 1200, however floor limit of 500 CSPR is still in place.

10 Redelegate: We have removed the need to make multiple contract 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 delegate 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.

11. 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.

12. 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.

13. Information: 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 the change. Note, the switch block will have no deploys,.

Testnet Activation Details

Activation: Era: 9904

1. 2023-07-17 16:15 UTC
2. 2023-07-17 09:15 US/PACIFIC
3. 2023-07-17 12:15 US/EASTERN
4. 2023-07-17 18:15 EUROPE/ZURICH
5. 2023-07-18 00:15 ASIA/HONG_KONG