Introduction to TON: Accounts, Tokens, Transactions, and Security
Background
TON (The Open Network) is a decentralized blockchain platform initially designed and developed by the Telegram team. TON aims to provide a high-performance and scalable blockchain platform to support large-scale decentralized applications (DApps) and smart contracts.
TON is unique in its ease of use and deep integration with Telegram, allowing ordinary users to easily handle tokens. However, it also presents complexities with its distinct architecture and the use of the unconventional FunC smart contract language. Today, we will discuss TON’s characteristics and asset security from the perspectives of accounts, tokens, and transactions.
Characteristics of TON
Account Generation
TON’s account address generation differs from most blockchains, as it is a smart contract address. Initially, a private key is created using the Ed25519 algorithm to generate a public key, as shown below:
There are two types of public keys: the raw public key and the “enhanced” public key, which includes additional information and a checksum.
An example of a raw public key looks like this:
`E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D`
And a enhanced public key looks like this:
`Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2`
Obtaining a public key alone is not enough to derive an account address, as in Ethereum. A TON account address is a smart contract address. The correct process is to compute the address, receive an initial token amount, and then deploy the contract. The address calculation process is illustrated below:
There are multiple forms of user addresses, such as the raw form:
`0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296`
And the user-friendly form:
Mainnet:
Bounceable:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
By examining these addresses, you can see that only the first and last few characters differ. The middle `account_id` remains the same. The relationship between the public key and account address is embedded in the `initial data`, which includes the user’s public key. The `workchainId` identifies the shard within the TON network where the account resides, as TON consists of many shards, each handling a specific set of accounts and transactions. The `Bounceable` and `Non-bounceable` flags relate to the smart contract’s operation.
Wallet Contracts
A user’s wallet contract source code snippet shows that it reads four parameters upon receiving a message:(stored_seqno, stored_subwallet, public_key, plugins):
wallet-v4-code.fc
() recv_external(slice in_msg) impure {
var signature = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));
throw_if(36, valid_until <= now());
var ds = get_data().begin_parse();
var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data
ds.end_parse();
throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, subwallet_id == stored_subwallet);
throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
//…This ensures each user, deploying identical contract code, has a unique contract address. All transactions initiated by a user must be signed and verified by their wallet contract before executing any operations on the blockchain. This mechanism allows a public key to correspond to multiple wallet addresses by deploying different wallet codes or initialization data.
Jetton Tokens
Tokens represent assets on the blockchain, making them a fundamental concept to understand. Jetton is the standard token form in the TON network, comprising two contract components: Jetton-minter and Jetton-wallet.
When a token is issued, a Jetton-minter contract is created. This contract initialization records the total supply of the token, the administrator, wallet code, and other relevant information.
When tokens are distributed to users, the Minter contract deploys a wallet contract for each user. During this initialization, the contract records the user’s balance, ownership, the address of the Minter contract, and the user’s wallet code. Each user receives a unique wallet contract. It’s important to note that the wallet contract created here is specifically for managing the Jetton tokens and is different from the user’s account wallet contract. The `owner_address` in this context records the user’s account wallet address.
When Alice transfers tokens to Bob, the call sequence is:
Alice signs the transaction using her app off-chain and issues commands through her wallet contract. These commands further invoke her token wallet to execute the transfer. When Bob’s token wallet receives the tokens, it notifies Bob’s wallet contract (the owner address of Bob’s Jetton wallet). If there is any remaining gas during the transaction, it is returned to the responding address, usually Alice’s account contract.
This is a Jetton token transfer analyzed by the Tonviewer browser:
A Jetton token transfer involves at least four contracts to facilitate on-chain concurrency and improve transaction efficiency.
Transactions
When an event occurs in a TON account, it triggers a transaction. The most common event is ‘receiving a message.’ A transaction includes the following components:
1. The incoming message that triggered the contract.
2. Contract actions initiated by the incoming message (optional).
3. Outgoing messages to other participants (optional).
Key transaction features include:
1. Asynchronous Nature: Transactions in TON are not completed in a single call; they may require a series of calls to multiple different smart contracts through message passing. Due to different routing in the shard chains, TON cannot guarantee the order of message delivery between multiple smart contracts.
2. Fees: The asynchronous nature also brings the issue of unpredictable fee consumption. Therefore, when initiating a transaction, the wallet usually sends extra tokens as fees. If the called contract has a good fee handling mechanism, the remaining fees will be refunded to the user’s wallet. Users might observe their wallet tokens suddenly decreasing and then increasing again after a few minutes, which explains this behavior.
3. Bounce: Bounce is an error-handling mechanism for contracts. If the called contract does not exist or throws an error, and if the transaction is set to be bounceable, a bounced message will be returned to the calling contract. For example, if a user initiates a transfer and the call process fails, a bounce message is needed so that the user’s wallet contract can restore its balance. Almost all internal messages sent between smart contracts should be bounceable, which means their “bounce” bit should be set.
Asset Security
TON’s unique features introduce several security challenges. Users should be aware of common pitfalls, such as:
Fee Scavenging Attacks
As mentioned earlier, wallets often need to send extra fees to prevent transaction failures, which presents an opportunity for attackers. If you are a TON wallet user, you might encounter a situation where your wallet receives various NFTs or tokens that initially seem like junk airdrops. However, upon checking the transaction details, you might find that they are worth a significant amount of money. But when you attempt to execute the transaction, you discover that the required fees are exorbitantly high (1 TON). This could be a fee scam.
Attackers use carefully constructed token contracts to make the wallet’s estimated transfer fee extremely high, while in reality, the execution only captures the fee without actually sending the transfer message.
Address Phishing
Front-and-Back Address Phishing is not unique to TON; it exists on all major public blockchains. Attackers generate counterfeit accounts with identical front and back characters for every user address across the network. When a user makes a transfer, the attacker follows with a small transaction using the counterfeit account, aiming to leave a record in the user’s transaction history. When the recipient wants to return a token, they might copy the address from the transaction history and inadvertently copy the attacker’s address, resulting in the transfer to the wrong address. This method demonstrates the attacker’s precise manipulation of user behavior.
Comment Phishing
TON allows adding a comment when making a transfer to include transaction information. This feature is frequently used when depositing to exchanges, as exchanges usually require users to include their user ID in the comment. However, this feature can often be maliciously exploited by attackers. They write fraudulent information in the comments to deceive users and steal their assets, as shown in the illustration:
Users need to be especially cautious with the Anonymous Telegram Number NFT. If a user activates a Telegram account using an Anonymous Telegram Number without enabling Two-Step Verification, a phishing attack could lead to this NFT being stolen. In such a case, the hacker can directly access the target Telegram account, facilitating subsequent asset theft and fraudulent activities.
Smart Contract Vulnerabilities
Security vulnerabilities in smart contracts can lead to the loss of funds stored in those contracts. Therefore, users should choose projects that have undergone thorough security audits. TON’s smart contracts are primarily programmed using the FunC language, but some use the more advanced Tact or the lower-level Fift. These are highly original languages, and the novelty of new programming languages brings new security risks. Developers need to adopt secure programming practices, master best security practices, and conduct rigorous security audits before deploying to the production environment. Due to space constraints, this article will not delve into contract security in detail. The Slowmist security team offers TON smart contract security audit services, and we welcome those in need of audits to discuss further.
Fake Deposit Attacks
Wallet and exchange users should also beware of fake deposits, often through:
1. Fake Tokens: Attackers issue tokens with identical metadata to legitimate tokens. Automated systems failing to verify the Minter contract can lead to incorrect deposits.
2. Bounced Messages: If the recipient’s wallet contract doesn’t exist and the transaction is Bounceable, the message is returned, less the fee.
Conclusion
This article introduces TON’s fundamental technical principles, covering public/private key creation, wallet contracts, token forms, and transaction characteristics. We also discussed potential security issues users may encounter. We hope this information enhances your understanding of TON.
