TON (The Open Network) is a powerful blockchain platform that supports a variety of complex application scenarios. In the development of TON smart contracts, the sending of messages is a core concept. This article will delve into the composition, parsing, and sending mechanism of messages in TON, helping developers better understand and utilize this technology.
Overview of Message Types
In TON, there are three types of messages: external messages, internal messages, and logs.
External Messages
External messages are sent from outside the blockchain to a smart contract. Such messages must be explicitly accepted during the credit_gas phase of the smart contract. If the smart contract does not accept the external message, the node will not include it in the block or forward it to other nodes.
Internal Messages
Internal messages are sent between entities within the blockchain. Unlike external messages, internal messages can carry TON and pay for themselves. The smart contract receiving the internal message can choose not to accept it, in which case, the gas carried by the message will be deducted.
Logs
Logs are messages sent from a blockchain entity to the outside world. TON does not specify rules for handling logs, so the handling of logs is entirely up to the node. Logs may be ignored, recorded, or sent via non-blockchain means.
Detailed Explanation of Message Layout
Messages in TON are composed of three main parts: info, init, and body. The following is a detailed explanation of these parts.
Info Field
The Info field contains the metadata of the message, such as the source, destination, and other related information. In TON, CommonMsgInfoRelaxed is a common layout for the info field, which includes the source address, destination address, value, fees, and timestamp of the message.
Init Field
The Init field is used only during the initialization of the message and contains the initialization data of the smart contract. This field is optional and is represented by the Maybe type.
Body Field
The Body field is the payload of the message, containing the actual data to be transmitted. In TON, the serialization of the body field can be complex, but it can usually be simplified.
Message Serialization Example
The following is a simplified example of message serialization:
var msg = begin_cell()
.store_uint(0, 1) ;; tag
.store_uint(1, 1) ;; ihr_disabled
.store_uint(1, 1) ;; allow bounces
.store_uint(0, 1) ;; not bounced itself
.store_slice(source)
.store_slice(destination)
.store_coins(amount)
.store_dict(extra_currencies)
.store_coins(0) ;; ihr_fee
.store_coins(fwd_value) ;; fwd_fee
.store_uint(cur_lt(), 64) ;; lt of transaction
.store_uint(now(), 32) ;; unixtime of transaction
.store_uint(0, 1) ;; no init-field flag (Maybe)
.store_uint(0, 1) ;; inplace message body flag (Either)
.store_slice(msg_body)
.end_cell();
This example shows how to construct a message cell, including setting the tag, address, amount, and message body.
Message Sending Modes
In TON, different modes (mode) and flags (flag) can be used to customize the behavior of messages when sending. Here are some common modes:
- Regular message (Mode 0)
- Message carrying remaining value (Mode 64)
- Message carrying all the balance of the contract (Mode 128)
Flags can be used to specify additional behaviors, such as paying transaction fees separately, ignoring certain errors, or destroying the account.
Conclusion
Understanding the message sending mechanism of the TON blockchain is crucial for developers. By mastering the types, layout, and sending modes of messages, developers can more effectively build and deploy TON smart contracts. This article provides a beginner’s guide, but the world of TON is vast, and developers should continue to delve into learning and practice.