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 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.
About SmartState
Launched in 2019 and incorporated in Dubai, SmartState is an independent Web3 security company providing top-notch external security audits and enterprise level blockchain security services.
We’ve built a professional team of skilled white-hat hackers, cyber security experts, analysts and developers. The SmartState team have extensive experience in ethical hacking and cyber security, blockchain & Web3 development, financial and economic sectors.
We’ve conducted security audits for >300 projects so far. None of code audited by SmartState had been hacked. Blockchains like TON, large projects like EYWA, 1inch and CrossCurve & exchanges such as Binance and KuCoin rely on our experience.
🚀 Concerned about your project & assets security? Book free security consultation! Let’s get in touch: info@smartstate.tech
Stay tuned and find more about us and what we provide on our:
Disclaimer
Always 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.
