引言
TON（The Open Network）作为由 Telegram 团队最初设计的去中心化区块链平台，以其高性能和可扩展性在 Web3 领域独树一帜。然而，TON 的独特之处不仅在于其与 Telegram 的深度整合带来的易用性，更在于其与传统区块链截然不同的架构设计——非主流的 FunC 智能合约语言、独特的账户模型以及复杂的交易机制，都为安全研究带来了全新挑战。
本文将从账户生成、Token 形态、交易特性三个核心维度，深入剖析 TON 的技术原理，并重点探讨用户资产安全中可能存在的风险点。
TON 账户体系：从私钥到智能合约地址
公私钥生成机制
TON 主要采用 Ed25519 算法生成密钥对，其流程如下：
- 私钥生成：随机生成 32 字节的种子
- 公钥计算：通过 Ed25519 算法从私钥推导出原始公钥（32 字节）
- 公钥编码：原始公钥可进一步转换为“美化”形式，携带校验位
原始公钥示例：
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D美化公钥示例：
Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2账户地址的独特生成方式
与以太坊等传统区块链不同，TON 的账户地址并非直接由公钥哈希计算得出，而是一个智能合约地址。这意味着用户在拥有账户之前，需要先计算地址、接收初始代币，然后再部署合约。
地址计算过程包含以下关键参数：
- workchainId：标识智能合约所属的分片链（TON 由多条分片链组成）
- initial data：包含用户公钥，是钱包合约所有权的凭证
- account_id：由公钥等数据计算得出的唯一标识
地址的两种表现形式：
-
原始形式：
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296 -
用户友好形式（主网示例）：
- Bounceable:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX - Non-bounceable:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
- Bounceable:
观察可发现，不同形式的地址仅在首尾字符存在差异，中间的 account_id 完全一致。这种设计体现了 TON 对地址兼容性和安全性的考量。
钱包合约：所有权验证与消息处理
TON 的钱包合约是用户资产管理的核心。以 wallet-v4 为例，其 recv_external 函数处理外部消息时，会读取合约存储中的四个关键参数：
- stored_seqno：消息序列号，防止重放攻击
- stored_subwallet：子钱包 ID，用于隔离不同应用场景
- public_key：用户公钥，验证消息签名
- plugins：插件字典，支持扩展功能
合约通过以下逻辑验证消息合法性：
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()); // 检查消息是否过期
throw_unless(33, msg_seqno == stored_seqno); // 检查序列号
throw_unless(34, subwallet_id == stored_subwallet); // 检查子钱包 ID这种设计确保了只有持有正确私钥的用户才能控制钱包，同时通过序列号和有效期机制防范重放攻击。
Token 机制：从 Jettons 到 NFT
Jettons（同质化代币）
TON 上的同质化代币称为 Jettons，其核心组件包括：
- Jetton Minter：代币发行合约，负责创建和管理代币
- Jetton Wallet：用户持有的代币账户合约，记录余额
- Jetton Master：代币元数据合约，定义名称、符号、精度等属性
与 ERC-20 不同，TON 的每个 Jetton 持有者都拥有独立的合约实例，这带来了更细粒度的控制能力，但也增加了合约复杂性。
NFT（非同质化代币）
TON 的 NFT 标准（如 TEP-62）同样采用独立合约架构：
- NFT Collection：集合合约，管理 NFT 的创建和元数据
- NFT Item：单个 NFT 合约，记录所有者、元数据 URI 等信息
- Royalty：版税机制合约，支持创作者在二级市场获得分成
交易特性：Bounceable 与非 Bounceable
TON 的交易机制中，Bounceable 和 Non-bounceable 是两个关键概念：
- Bounceable 交易：如果接收方合约不存在或执行失败，消息会被“反弹”，原始资金扣除手续费后返回发送方
- Non-bounceable 交易：消息即使发送失败也不会反弹，资金可能永久丢失
这种设计对资产安全有直接影响：
- 首次转账：向新地址首次转账时，建议使用 Bounceable 模式，防止因地址错误导致资金损失
- 合约部署：部署钱包合约前，必须通过 Non-bounceable 交易转入初始资金
资产安全风险分析
假充值攻击（类型一：假币）
攻击者可能创建与目标代币（如 USDT）完全相同的 metadata，但使用不同的 minter 合约。如果交易所或钱包的自动化入账程序仅检查代币名称和符号，而未验证 minter 合约地址，就会导致错误入账。
防御措施：
- 验证代币的 minter 合约地址是否为官方地址
- 检查代币的 Jetton Master 合约代码哈希
- 对入账代币进行合约级白名单验证
假充值攻击（类型二：反弹机制）
利用 TON 的 Bounceable 特性，攻击者可以：
- 向目标地址发送 Bounceable 交易
- 如果目标地址不存在或合约执行失败，资金自动反弹
- 攻击者声称已转账，利用系统确认延迟进行欺诈
防御措施：
- 确认交易状态为
finalized而非pending - 检查交易是否产生反弹消息
- 使用 Non-bounceable 模式接收首次转账
安全实践建议
针对 TON 生态的安全防护，查找币安全团队建议：
-
钱包开发：
- 严格实现 seqno 验证机制
- 支持多重签名和紧急暂停功能
- 定期审计合约代码
-
交易所集成：
- 实现代币合约白名单系统
- 对入账交易进行多维度验证（minter 地址、合约哈希、交易状态）
- 建立假充值检测模型
-
用户操作：
- 转账前确认地址格式正确
- 首次接收代币选择 Bounceable 模式
- 使用官方钱包或经过审计的第三方钱包
结语
TON 的独特架构带来了创新的用户体验，但也引入了全新的安全挑战。从账户生成的钱包合约，到 Token 机制的智能合约，再到交易特性的反弹机制，每个环节都可能成为攻击者的突破口。理解这些技术细节，是保障资产安全的前提。
查找币安全团队已推出 TON 智能合约安全审计服务，涵盖钱包合约、Jetton 合约、NFT 合约等全品类审计。我们持续关注 TON 生态的安全动态，欢迎有审计需求的项目方与我们深入交流。
本文由查找币安全团队整理发布