Key Dates:

         Mainnet Activation: Era-10553 , Time -  2023-08-29 13:04 UTC                            

Key Changes: 

Security Performance Resilience & Robustness

1. Fast Syncing nodes: In v1.5.2 we introduce the Fast-sync feature that 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.
   The legacy joining mechanism is completely overhauled, now 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 we have reduced it 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.
   More on the mechanism of syncing can be found here.
2. Deploy acceptor enhancement: We have removed the option in config.toml to disable the account verification for deploys , this is a network optimization  here.

 

Features and enhancements

1. Redelegate: We have removed the need to make multiple contract calls in the system  and multiple user actions in cspr.live, 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 on the change here.
2. Node launcher updated: The node launcher is updated to always run the highest version of the node binary. Thus in case of 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 have the option to force the launcher to start a specific version of the node, using casper-node-launcher -f <version>, for more refer here.
3. Removed trie-store integrity checks: In previous versions of the network, when a crash or similar situation was encountered, upon restart the node would do an integrity check on the DB, which would take several hours to complete - due to the size of the DB. In v1.5.0 we have removed this functionality and totally removed the environment variable (CL_RUN_INTEGRITY_CHECKS) which used to enable integrity checks.
4. v1.4.5 Delegator limit: 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.

RPC- Event Stream-Client & Metrics

1. Improved JSON-RPC implementation: We have removed the dependency on wrap-json-rpc with our own implementation, which is compliant with the JSON-RPC 2.0 specification(here). This replaces the crate wrap-json-rpc with the new casper-json-rpc. The immediate changes to the json-rpc server which are of interest to the users are captured below and further changes coming in v2.0.0 are captured in the Appendix of the document.
   1. Most error responses contain more detailed, informative messages relating to the reason for the error.
   2. HTTP requests must include a header 'Content-Type: application/json'.
   3. As per the spec, if the 'id' field is missing from a request, no JSON-RPC response is sent, only an HTTP 400 Bad Request is returned with a JSON body explaining that the request was missing the 'id' field.
   4. For cases where the request is valid JSON, but not a valid JSON-RPC request, we now return the correct error code -32600 (Invalid Request) rather than -32700 (Parse error).
   5. For RPCs where the 'params' field may be omitted, we no longer ignore errors when parsing the field.  Until and including 1.4.6, for an RPC like this, if the 'params' field could not be parsed it was treated as if it were omitted and a success response was generated.  As of 1.5.0, failure to parse `params` will result in an error response.
      For more information(here and here).
2. Added meaningful response to RPC:  
   In previous versions of the network, when a user made a query to a node for block   information, using Client or SDK and that block or state is missing for that node, the system did not provide any meaningful response, instead returned as successful. We have now included a meaningful response by indicating what that node's lowest contiguous block height is, i.e., the block from which it holds all subsequent global states. Thus, clearly indicating to the user to query another node or block for the required information. Following are the endpoints affected –chain_get_block
   chain_get_block_transfers
   chain_get_state_root_hash
   chain_get_era_info_by_switch_block
   state_get_auction_info
   state_get_account_info
   query_global_state - only when queried by using BlockHash.
   2780, 2781, 2788, 2789, 2362
   Please note that it is possible to query a node for a block it does not have(due to fast-syncing and not having legacy data), in that case we need to keep querying another peer and repeat till we find a peer who has that block.
3. Query node status:  We enhanced the ability to query for the node’s status, by adding run-mode field to the `/status` endpoint and the `info_get_status` to JSON-RPC, which indicates which state a node currently is in:
   1. reactor_state indicating the node's current operating mode such as 'fast syncing', 'archival syncing', 'participating'.
   2. last_progress indicating the time the node last made progress.
   3. available_block_range indicating the highest contiguous sequence of the block chain for which the node has complete data.
   4. block_sync indicating the state of the block synchronizer component.
   5. We changed the starting_state_root_hash field from the REST and JSON-RPC status endpoints to now represent the state root hash of the lowest block in the available block range.
      
      More information here and  here.
4. Query Chainspec content:  In this release we have added a new RPC endpoint "info_get_chainspec". Querying this endpoint, will output the bytes of the chainspec.toml (optionally accounts and global state toml) file(s), which can then be used to view the contents of the chainspec by writing the output to a file, more here.
   This change was primarily made since chainspec is part of the protocol definition and should be able to provide it if challenged.
5. Cross-origin RPC support:  A website that needs to make, say RPC calls to a Casper node via an app on the website, currently in v1.4.15 of the node would not be able to do so. Modern browsers do not allow arbitrary calls to domains without the proper CORS header being set, as the assumed default is "deny". In v1.5.0 we have enabled CORS, making it possible to make RPC calls to a node from a browser; here.
6. Deprecating get-balance RPC: We have deprecated the get-balance rpc(to be removed in v2.0.0) and replaced it with an enhanced version query-balance rpc, the following are some key points to note about the new rpc endpoint.
   1. use the public key or account hash to query the purse.
   2. use uref of the purse to query.
   3. do not have to use the state-root hash to query.
      
      All preexisting features of the get-deploy query are retained in the new query-balance endpoint, and we encourage the user to use it, more infomation here.
7. Metrics Changes: In this release we have made changes to some of the metrics, for a detailed list of changes refer to this PR, please find some notable ones added/removed/renamed from the same list.
   1. block_accumulator_block_acceptors, block_accumulator_known_child_blocks to report status of the block accumulator component.
   2. forward|historical)_block_sync_duration_seconds to report the progress of block synchronization
   3. deploy_buffer_total_deploys, deploy_buffer_held_deploys, deploy_buffer_dead_deploys to report status of the deploy buffer component.
   4. (lowest|highest)_available_block_height to report the low/high values of the complete block range (the highest contiguous chain of blocks for which the node has complete data).
   5. execution_queue_size to report the number of blocks enqueued pending execution.
   6. In this release chain_height metric is deprecated in favor of highest_available_block_height and current_era metric renamed to consensus_current_era.
      
      Note: In this release we removed the ‘pending deploy count’ metric since the block proposer component was removed. However we can get the same information about pending deploy count by using subtraction to the following metrics '(deploy_buffer_total_deploys - deploy_buffer_dead_deploy)'.

Smart Contracting

There are no breaking changes to smart contracts in v1.5.0, however smart contract package string prefix changes may need some refactoring(refer below)to parser etc; authors must also ensure their rust-toolchain is this build - nightly-03-25-2023 Non-breaking changes as described below.

1. Allow session and smart contract logic to ask for deploy approvals: Added a 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 signature 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.
2. DICTIONARY_ITEM_KEY_MAX_LENGTH increased: The DICTIONARY_ITEM_KEY_MAX_LENGTH has been increased from, usize of 64 to 128. Earlier, say one was calling the Account hash and using it as a dictionary item key, because of the prefix it would be 64 hex bytes + prefix, now with added length this is a non-issue, here.
3. New convenience functions: Added two new helper functions named_dictionary_get() and named_dictionary_put() , these are convenience functions which calls the runtime::get key() internally to get the dictionary's URef followed by storage::dictionary_get() or storage::dictionary_put() this helps avoid making multiple calls to the contract API, more here.
4. Testbuilder updates: In v1.5.2,we order the transforms for multiple deploys within a block; in order to reflect the change in test harness, we also updated the WasmTestBuilder to track the transforms in the correct order here.
5. Undo v1.4.5 changes: We introduced a trie leaf size (“max stored value”) limit in v1.4.5(details here) - tldr; thus if any new smart contract tried to create a value larger than 8MB, that contract's execution would have failed. We have reverted the limit in v1.5.2.
6. Gas cost estimation: We added a significant feature via a RPC endpoint speculative_exec, which enables contract developers to estimate the potential gas cost of a deploy, here. In order to support this we added a new speculative execution JSON-RPC HTTP server and added settings to config.toml. This server is disabled by default and the out of the box port(configurable) is 7778. A node needs to enable this server in order to serve speculative execution endpoint calls.
7. Contract package string prefix corrected: The contract package string prefix changed from ``contract-package-wasm" to "contract-package. This requires no change if developers are encoding using the old format(to be deprecated in v2.0.0), since we handle parsing the old format in the node itself. However any parser or decoder should be updated to accept the new format; or if there is any specific use-case to accept the old format in the code that needs to be refactored to support parsing the old format since the node will not be outputting the old format(contract-package-wasm), more details here.
8. Improve detection of invalid WASM: We fixed an issue where there was no charge for execution of incorrect wasm files, wasm magic bytes, empty modules, general corruption or a no memory section- now these will involve a cost to the tune of 2.5CSPR, more here.

Informational:

Below we have a list of informational notes relevant to the node release v1.5.2.

1. Full list of changes in released v1.5.2 is under changelog sections 1.5.0-rc.1, 1.5.1 and 1.5.2 here and full list of changes to configs here.
2. List of stories from project board included in v1.5.2 here.
3. Upgrade instructions are - here.
4. 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.
5. Casper-types (v3.0.0) is the latest recommended version to use.
6. JS SDK - 2.14 and above is the recommended version to use.
7. Please update your rust toolchain to use the 03-25-2023 nightly version.
8. 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.
9. Operators should note that the non-validating nodes in 1.5.2 are more of an observer and do not participate in the network in the same way as in before 1.5.2, thus any metrics setup that depends on them will need to be modified likewise to be dependent on a validating node instead.
10. After upgrading to 1.5.2 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.

Note: We have also done significant work in 1.5.2 architecturally, that gives the protocol a jump start in preparation of future v2.0.0 of the Casper node protocol, for example the Zug consensus and more.