August 2024 network updates and voting

Voting

After network will be upgraded (to be prepared for voting) to commit 140320b (or newer) it will be proposed to validators to vote for following changes:

Config parameter 8

(capabilities version:7 capabilities:46

will be changed to

(capabilities version:8 capabilities:494)

Version 7 to 8 increase will activate the following changes:

• Check mode on invalid action_send_msg. Ignore action if IGNORE_ERROR (+2) bit is set, bounce if BOUNCE_ON_FAIL (+16) bit is set. This will allow to write more error resistant contracts because even incrorect messages will be correctly handled if right flag is uses.
• Slightly change random seed generation to fix mix of addr_rewrite and addr. This eliminate potential UB.
• Fill in skipped_actions for both invalid and valid messages with IGNORE_ERROR mode that can't be sent. This will fill in presented but not used before field in transaction description.
• Allow unfreeze through external messages. This functionality presented but was temporarily disabled earlier.
• Don't use user-provided fwd_fee and ihr_fee for internal messages. This will eliminate some non-practical edge-cases that previously required attention from smart-contract developers.

Capabilities update is as following:

Current capabilities are : capCreateStatsEnabled | capBounceMsgBody | capReportVersion | capShortDequeue == 2 | 4 | 8| 32 == 46

Proposed capabilites are : capCreateStatsEnabled | capBounceMsgBody | capReportVersion | capShortDequeue | capStoreOutMsgQueueSize | capMsgMetadata | capDeferMessages == 2 | 4 | 8| 32 | 64 | 128 | 256 == 494

Added capabilities are:

• capStoreOutMsgQueueSize - activate explicitly storing queue size in the state. This simplify queue managing.
• capMsgMetadata - add transaction chain metadata to message envelopes during routes. This will allow much simpler indexing of chains and also gives node information to distribute load between transaction chains during block generation
• capDeferMessages - allow node to postpone message routing if shardchain is overloaded. This will allow load distribution during block generation.

Config parameter 12

( workchains:(hme_root   root:(hm_edge     label:(hml_same v:0 n:32)     node:(hmn_leaf       value:(workchain enabled_since:1573821854 actual_min_split:0 min_split:0 max_split:4 basic:1 active:1 accept_msgs:1 flags:0 zerostate_root_hash:x55B13F6D0E1D0C34C9C2160F6F918E92D82BF9DDCF8DE2E4C94A3FDF39D15446 zerostate_file_hash:xEE0BEDFE4B32761FB35E9E1D8818EA720CAD1A0E7B4D2ED673C488E72E910342 version:0         format:(wfmt_basic vm_version:-1 vm_mode:0))))))

to

( workchains:(hme_root   root:(hm_edge     label:(hml_same v:0 n:32)     node:(hmn_leaf       value:(workchain enabled_since:1573821854 actual_min_split:0 min_split:2 max_split:4 basic:1 active:1 accept_msgs:1 flags:0 zerostate_root_hash:x55B13F6D0E1D0C34C9C2160F6F918E92D82BF9DDCF8DE2E4C94A3FDF39D15446 zerostate_file_hash:xEE0BEDFE4B32761FB35E9E1D8818EA720CAD1A0E7B4D2ED673C488E72E910342 version:0         format:(wfmt_basic vm_version:-1 vm_mode:0))))))

this will make default number of shardchains in basechain equal to 4. Such configuration often happens under the load (more over it is not new for TON for 2 years default number of shardchains was even higher - 16). This default increase is motivated by growing size of basechain state, currently if serialization happens at the moment of low load (with one shard) final state is very big and serialization process is long and resource consuming. Dividing it to 4 parts will make nodes more efficient. Besides it will eliminate many event of splits and merges (because current load in TON is "on the edge" and basechain pass from one state to another many times per day) which will make message delivery, transaction times and so on more predictable.