初识TON:帐号、Token、交易与资产安全
By Johan
背景TON(The Open Network) 是一个去中心化的区块链平台,由Telegram 团队最初设计和开发。 TON 的目标是提供一个高效能和可扩展的区块链平台,以支援大规模的去中心化应用程式(DApps) 和智慧合约。
TON 如此特殊,它是易用的,它与Telegram 深度结合,使得普通人也能轻易使用代币;它又是复杂的,它与其他区块链有着截然不同的架构,而且使用非主流的FunC智能合约语言。今天我们从帐号、Token、交易的角度讨论一下TON 的特色及用户资产安全问题。
TON 的特点帐号生成TON 帐号位址的产生方式与大多数区块链都不同,它是一个智慧合约地址。首先,开局一个私钥,TON 主要使用Ed25519 演算法产生公钥,产生流程如下:
这里有两种形式的公钥,一种是由私钥计算的原始公钥,形如:
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
另一种是美化后的公钥,它携带了公钥的一些资讯和校验位,形如:Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
如果认为得到公钥就能像以太坊一样得到帐号地址就太天真了,光是用户的公钥还不足以计算出用户的帐号位址。我们刚刚说了,用户的帐号地址是一个智能合约地址,但是我们连帐号都没有,怎么部署智能合约?正确的顺序是先计算地址,接收一点初始金额的代币,然后就可以部署合约。帐号位址的计算过程如下图所示:
使用者的地址也有多种形式,首先是原始形式,形如:
0b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
以及使用者友善形式,形如:
Mainnet Bounceable EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX Nonbounceable UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRodHi0Mnet R0cRoVLHi0Mhjilvhd Nonbounceable 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
细心观察这几个位址就可以看出,它们只有首尾几个字元存在差别,中间的accountid 是一样的,但是我们还是无法看出公钥和帐号位址之间的关系,其实玄机就藏在在开头的initial data 中,它包含了一个使用者的公钥,使用者就是透过它掌握钱包合约的所有权。 workchainId 很好理解,TON 并不是只有一条单链,它由非常多的分片组成,每个分片是整个网路的一部分,处理特定的一组帐号和交易。为了定位和管理智能合约,需要明确指出它们位于哪个分片中。 Bounceable 和Nonbounceable 有什么不同?这和智能合约的工作机制有关,我们先继续往下看。
钱包合约以下是一个用户钱包合约的一段原始码,可以看到它在接收到用户的讯息时读取了4 个参数(storedseqno storedsubwallet publickey plugins):
walletv4codefc
() recvexternal(slice inmsg) impure { var signature = inmsgloadbits(512) var cs = inmsg var (subwalletid validuntil msgseqno) = (csloaduint(32) 22cs loaduint(32)) throwif(36 validuntil lt= now()) var ds = getdata()beginparse() var (storedseqno storedsubwallet publickey plugins) = (storedseqno storedsubdset publickey plugins) = (storedseqno storedsubdset publickey plugins) = (storeduint(32) loaduint(32) dsloaduint(256) dsloaddict()) ##The Initial Data dsendparse() throwunless(33 msgseqno == storedseqno) throwunless(34 subwalletid == storedsubwallet ) throwunless(35 checksignature(slicehash(inmsg) signature publickey)) //}
没错,这个用户的钱包合约在部署的时候,需要传入一些初始参数,其中就包含了一个256 位元的publickey 讯息,这样就确保了每个用户使用相同的合约程式码时,有一个独立的合约地址。用户发起的一切交易都需要对inmsg 签名,然后透过自己的钱包合约验证签名(checksignature) 后,由合约去呼叫链上的一切操作。从这里我们也可以推断出,一个用户的公钥其实是可以对应无数钱包位址的,只需要部署不同原始码的钱包或不同的初始化数据,就能得到完全不同的合约位址。
Jetton TokenToken 是资产在链上的表现形式,所以它是我们需要了解的一个基本元素。 Jetton 是TON token 的标准形式,Jetton 由两部分合约组成,Jettonminter 和Jettonwallet:
代币发行时,会创建一个Jettonminter 合约,合约初始化记录了代币的总量、管理员、钱包代码等资讯。
当代币分发给用户时,Minter 合约会为用户部署一个钱包合约,并在合约初始化时记录用户的余额、所有权、代币Minter 合约地址、用户钱包代码等信息,每个用户都会独立部署一个合约。注意,这里创建的合约是用于管理特定Jetton 代币的钱包合约,与用户的帐号钱包合约并不相同,这里的owneraddress 记录的是用户的帐号钱包地址。
当用户Alice 给用户Bob 转帐时,呼叫关系如下:
Alice 在链下的APP 签名,并透过呼叫她的钱包合约下达操作指令。这些指令会进一步呼叫她的代币钱包来转帐。当Bob 的代币钱包收到代币后,它会通知Bob 的钱包合约即Bob Jettonwallet 的Owner 地址。如果交易过程中有剩余的Gas,也会回传给回应位址,通常为Alice 的帐号合约。
这是Tonviewer 浏览器解析的一笔Jetton 代币转帐:
一个ERC20 转帐最少只需要呼叫一个合约,而一笔Jetton 代币转帐至少要呼叫四个合约,这么做是为了让转帐可以在链上并发进行,提高交易效率。
交易当TON 中的某个帐户发生某些事件时,它会引发一笔交易,最常见的事件是“接收某个讯息”,交易包括以下内容:
交易需要注意几个特性:
1 非同步:TON 的交易并不是一次呼叫里完成的,它可能需要透过讯息传递到多个不同的智能合约去执行一系列呼叫。由于分片链中的路由不同,TON 并不能保证多个智慧合约之间的讯息传递顺序。
usdt交易平台网站2 手续费非同步的特性还会带来一个问题,就是消耗的手续费难以预估。因此在发起交易时,钱包通常会多发送一些代币作为手续费。如果调用的合约有良好的手续费处理机制,那么剩余的手续费最后会返还到用户钱包。用户可能会观察到钱包代币突然变少,过几分钟又变多,就是这个原因。
3 反弹:反弹是合约的一种错误处理机制,当呼叫的合约不存在或抛出错误时,如果交易设定为可反弹的,那么就会反弹回一个bounced 讯息给发起呼叫的合约。例如:用户发起一笔转账,如果呼叫过程出错了,那么就需要反弹讯息,这样用户的钱包合约才能将自己的余额恢复。几乎所有在智能合约之间发送的内部讯息都应该是可弹回的,即应该设置它们的“bounce”位元。
资产安全TON 有许多功能会带来安全问题,因此使用者也需要了解一些常见的陷阱。
手续费截留攻击上面说到钱包经常需要多发送一些手续费以防止交易执行失败,这让攻击者找到了作恶的机会。如果你是TON 钱包用户,你可能碰到过这样的情况,钱包里总是会收到各种NFT 或代币,本来以为只是一些垃圾代币空投,但是一查交易讯息,竟然可以卖不少钱?可是当启动交易时,发现所需的手续费超高1 TON,这时就需要注意了,这可能是手续费诈骗。
攻击者利用精心建构的代币合约,让钱包的预估转帐手续费超高,而实际执行时却只是截留手续费,并未发送转帐讯息。
首尾号钓鱼首尾号钓鱼不是TON 上才有,各大公链都存在这种钓鱼攻击。攻击者会为全网每个用户地址都产生一个首尾号相同的高仿帐号,当用户发送一笔转账时,攻击者用高仿帐号也尾随发送一笔小额转账,目的是在用户的收款记录里留下一张纪录。当收款用户想要转回一笔代币时,可能会从历史记录里复制地址,这时很可能复制到攻击者的地址,导致转账到错误地址,攻击者可谓是精准拿捏用户的行为了。
comment 钓鱼TON 在转帐时可以添加一个comment,用于备注交易讯息,这个功能在交易所充值时会频繁用到,交易所通常会要求用户在充值时备注一下用户ID。但这个功能经常会被恶意利用,攻击者透过在备注里写入诈欺资讯来骗取用户的资产。如图所示:
使用者尤其需要注意Anonymous Telegram Number 这个NFT,如果使用者用Anonymous Telegram Number 开通了TG 号,但没开TwoStep Verification,一旦这个NFT 被钓走,骇客就可以直接登入目标TG 号,实施后续的资产盗取及欺骗行为。
智能合约漏洞智能合约的安全漏洞会导致用户放在智能合约的资金受损,用户在选择专案时需要选择经过良好审计的专案。 TON 的智能合约主要使用FunC 语言来编程,也有使用更高阶的Tact,或更底层的Fift,都是原创程度很高的语言。新的程式语言会带来新的安全风险,特别是对开发者而言,要有安全编程的良好习惯,掌握最佳安全实践,并且在部署生产环境之前经过严格的安全审计,限于篇幅,本文暂不讨论合约安全。慢雾安全团队推出TON 智慧合约安全审计服务,欢迎有审计需求的朋友一起探讨。
假储值攻击钱包或交易所用户需要注意假储值攻击,通常有两种类型的假储值攻击:
总结本文从TON 的公私钥创作、钱包合约、Token 的形式、交易特性等角度介绍了TON 的一些基础的技术原理,同时也探讨了使用TON 的过程中可能存在的安全问题,希望能给大家的学习带来启发。
参考连结:
https//docstonorg/
https//githubcom/tonblockchain/walletcontract