Understanding the message re-bounce issue in TON
The Telegram Open Network (TON) is an innovative decentralized platform that has gained significant popularity among developers, users, and investors. However, as with any outstanding blockchain technology, the TON ecosystem faces its unique security concerns and potential threats that may impact the integrity and reliability of dApps built on the network. In this article, we will delve into one of the security concerns that developers should take into account when developing on TON: the message re-bounce issue.
Bounceable and non-bounceable messages in TON
TON supports bounceable and non-bounceable message types. Bounceability is a key feature that allows messages to be bounced back with the remainder of the original value, minus all processing and gas fees, in case the destination contract does not exist or throws an unhandled exception while processing the message. In contrast, non-bounceable messages are not bounced back in case of any issues.
Message flow sharding and re-bounce problems
The TON blockchain, despite its similarities with other networks like Ethereum, has several unique features that set it apart. One such feature is its innovative sharding solution designed to boost scalability by dividing the network into smaller shards, enabling it to process thousands of transactions per second.
To develop smart contracts on TON while considering sharding, one best practice is to respect the contract "hierarchy" and split the contract logic flow into small parts to optimize data transfer and control the load of hierarchy layers and high-loaded contracts.
Another sharding-based key feature is that TON smart contracts can be partially executed. Regarding the message flow, this might happen because in contrast to sequential messaging processes, where a second message is sent after the first and a third after the second in a cascade manner, TON executes all the messages from the message chain simultaneously across different shards.
TON network does not provide the messages “supply chain”, instead, this is the developer’s responsibility to handle the integrity, correctness and fullness of the message flow. As message flow is sharded, bounced messages are not re-bounced by design in TON. So, developers must think of catching, handling and proceeding bounced messages effectively when developing smart contracts on TON.
Conclusion
The TON ecosystem is designed to provide a secure and reliable platform for users. However, its unique features can pose potential security concerns and threats if not properly addressed. By understanding TON's unique features, common security concerns, being aware of potential threats, and following best practices, developers can enjoy the benefits of the TON network while minimizing the risk of security breaches.
Disclaimer
DYOR. This article does not constitute legal, financial or investment advice, and we are not responsible for any decisions based on our analysis or recommendations.
