原文作者：Johan
背景
TON(The Open Network) 是一個去中心化的區(qū)塊鏈平臺，由 Telegram 團隊最初設(shè)計和開發(fā)。TON 的目標是提供一個高性能和可擴展的區(qū)塊鏈平臺，以支持大規(guī)模的去中心化應(yīng)用 (DApps) 和智能合約。
TON 如此特殊，它是易用的，它與 Telegram 深度結(jié)合，使得普通人也能輕易使用代幣；它又是復(fù)雜的，它與其他區(qū)塊鏈有著截然不同的架構(gòu)，而且使用非主流的 FunC 智能合約語言。今天我們從賬號、Token、交易的角度討論一下 TON 的特點及用戶資產(chǎn)安全問題。
TON 的特點
賬號生成
TON 賬號地址的生成方式與大多數(shù)區(qū)塊鏈都不同，它是一個智能合約地址。首先，開局一個私鑰，TON 主要使用 Ed 25519 算法生成公鑰，生成流程如下：
這里有兩種形式的公鑰，一種是由私鑰計算出的原始公鑰，形如：
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
另一種是「美化」后的公鑰，它攜帶了公鑰的一些信息和校驗位，形如：Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
如果認為得到公鑰就能像以太坊那樣得到賬號地址就太天真了，僅僅有用戶的公鑰還不足以計算出用戶的賬號地址。我們剛剛說了，用戶的賬號地址是一個智能合約地址，但是我們連賬號都沒有，怎么部署智能合約？正確的順序是先計算地址，接收一點初始金額的代幣，然后就可以部署合約。賬號地址的計算過程如下圖所示：
用戶的地址也有多種形式，首先是原始形式，形如：
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
以及用戶友好形式，形如：
Mainnet:
Bounceable:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
Non-bounceable:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
Testnet:
Bounceable:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
Non-bounceable:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
細心觀察這幾個地址就可以看出，它們只有首尾幾個字符存在差別，中間的 `account_id` 是一樣的，但是我們還是無法看出公鑰和賬號地址之間的關(guān)系，其實玄機就藏在開頭的 `initial data` 中，它包含了一個用戶的公鑰，用戶就是通過它掌握錢包合約的所有權(quán)。`workchainId` 很好理解，TON 并不是只有一條單鏈，它由非常多的分片組成，每個分片是整個網(wǎng)絡(luò)的一部分，處理特定的一組賬號和交易。為了定位和管理智能合約，需要明確指出它們位于哪個分片中。`Bounceable` 和 `Non-bounceable` 有什么區(qū)別？這和智能合約的工作機制相關(guān)，我們先繼續(xù)往下看。
錢包合約
以下是一個用戶錢包合約的一段源代碼，可以看到它在接收到用戶的消息時讀取了 4 個參數(shù) (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));
//...
}
沒錯，這個用戶的錢包合約在部署的時候，需要傳入一些初始參數(shù)，其中就包含了一個 256 位的 public_key 信息，這樣就確保了每個用戶使用相同的合約代碼時，有一個獨立的合約地址。用戶發(fā)起的一切交易都需要對 `in_msg` 簽名，然后通過自己的錢包合約驗證簽名 (check_signature) 后，由合約去調(diào)用鏈上的一切操作。從這里我們也可以推斷出，一個用戶的公鑰其實是可以對應(yīng)無數(shù)錢包地址的，只需要部署不同源代碼的錢包或者不同的初始化數(shù)據(jù)，就能得到完全不同的合約地址。
Jetton Token
Token 是資產(chǎn)在鏈上的表現(xiàn)形式，所以它是我們需要了解的一個基本元素。Jetton 是 TON token 的標準形式，Jetton 由兩部分合約組成，Jetton-minter 和 Jetton-wallet：
代幣被發(fā)行時，會創(chuàng)建一個 Jetton-minter 合約，合約初始化記錄了代幣的總量、管理員、錢包代碼等信息。
代幣被分發(fā)給用戶時，Minter 合約會為用戶部署一個錢包合約，并在合約初始化時記錄用戶的余額、所有權(quán)、代幣 Minter 合約地址、用戶錢包代碼等信息，每個用戶都會獨立部署一個合約。注意，這里創(chuàng)建的合約是用于管理特定 Jetton 代幣的錢包合約，與用戶的賬號錢包合約并不相同，這里的 owner_address 記錄的是用戶的賬號錢包地址。
當(dāng)用戶 Alice 給用戶 Bob 轉(zhuǎn)賬時，調(diào)用關(guān)系如下：
Alice 在鏈下的 APP 簽名，并通過調(diào)用她的錢包合約下達操作指令。這些指令會進一步調(diào)用她的代幣錢包進行轉(zhuǎn)賬。當(dāng) Bob 的代幣錢包收到代幣后，它會通知 Bob 的錢包合約（即 Bob Jetton-wallet 的 Owner 地址）。如果交易過程中有剩余的 Gas，還會返回給響應(yīng)地址，通常為 Alice 的賬號合約。
這是 Tonviewer 瀏覽器解析的一筆 Jetton 代幣轉(zhuǎn)賬：
一個 ERC 20 轉(zhuǎn)賬最少只需要調(diào)用一個合約，而一筆 Jetton 代幣轉(zhuǎn)賬至少要調(diào)用四個合約，這么做是為了讓轉(zhuǎn)賬可以在鏈上并發(fā)進行，提高交易效率。
交易
當(dāng) TON 中的某個帳戶發(fā)生某些事件時，它會引發(fā)一筆交易，最常見的事件是「接收某個消息」，交易包括以下內(nèi)容：
最初觸發(fā)合約的傳入消息（存在特殊的觸發(fā)方式）
由傳入消息引起的合約行動，例如更新合約的存儲（可選）
發(fā)送給其他參與者的傳出消息（可選）
交易需要注意幾個特性：
1. 異步：TON 的交易并不是在一次調(diào)用里完成的，它可能需要通過消息傳遞到多個不同的智能合約去執(zhí)行一系列調(diào)用。由于分片鏈中的路由不同，TON 并不能保證多個智能合約之間的消息傳遞順序。
2. 手續(xù)費: 異步的特性還會帶來一個問題，即消耗的手續(xù)費難以預(yù)估。因此在發(fā)起交易時，錢包通常會多發(fā)送一些代幣做為手續(xù)費。如果調(diào)用的合約有良好的手續(xù)費處理機制，那么剩余的手續(xù)費最后會返還到用戶錢包。用戶可能會觀察到錢包代幣突然變少，過幾分鐘又變多，就是這個原因。
3. 反彈：反彈是合約的一種錯誤處理機制，當(dāng)調(diào)用的合約不存在或者拋出錯誤時，如果交易設(shè)置為可反彈的，那么就會反彈回一個 bounced 消息給發(fā)起調(diào)用的合約。例如：用戶發(fā)起一筆轉(zhuǎn)賬，如果調(diào)用過程出錯了，那么就需要反彈消息，這樣用戶的錢包合約才能將自己的余額恢復(fù)。幾乎所有在智能合約之間發(fā)送的內(nèi)部消息都應(yīng)該是可彈回的，即應(yīng)該設(shè)置它們的「bounce」位。
資產(chǎn)安全
TON 有很多特性會帶來安全問題，因此用戶也需要了解一些常見的陷阱。
手續(xù)費截留攻擊
上面說到錢包經(jīng)常需要多發(fā)送一些手續(xù)費以防止交易執(zhí)行失敗，這讓攻擊者找到了作惡的機會。如果你是一個 TON 錢包用戶，你可能碰到過這樣的情況，錢包里總是會收到各種 NFT 或者代幣，本以為只是一些垃圾代幣空投，但是一查交易信息，竟然可以賣不少錢？可是當(dāng)發(fā)起交易時，發(fā)現(xiàn)需要的手續(xù)費超高（1 TON），這時就需要注意了，這可能是手續(xù)費詐騙。
攻擊者利用精心構(gòu)造的代幣合約，讓錢包的預(yù)估轉(zhuǎn)賬手續(xù)費超高，而實際執(zhí)行時卻只是截留手續(xù)費，并未發(fā)送轉(zhuǎn)賬消息。
首尾號釣魚
首尾號釣魚不是 TON 上才有，各大公鏈都存在這種釣魚攻擊。攻擊者會為全網(wǎng)每個用戶地址都生成一個首尾號相同的高仿賬號，當(dāng)用戶發(fā)送一筆轉(zhuǎn)賬時，攻擊者用高仿賬號也尾隨發(fā)送一筆小額轉(zhuǎn)賬，目的是在用戶的收款記錄里留下一個記錄。當(dāng)收款用戶想要轉(zhuǎn)回一筆代幣時，可能會從歷史記錄里復(fù)制地址，這時很可能復(fù)制到攻擊者的地址，導(dǎo)致轉(zhuǎn)賬到錯誤地址，攻擊者可謂是精準拿捏用戶的行為了。
comment 釣魚
TON 在轉(zhuǎn)賬時可以添加一個 comment，用于備注交易信息，這個功能在交易所充值時會頻繁用到，交易所通常會要求用戶在充值時備注一下用戶 ID。但這個功能經(jīng)常會被惡意利用，攻擊者通過在備注里寫入欺詐信息來騙取用戶的資產(chǎn)。如圖所示：
用戶尤其需要注意 Anonymous Telegram Number 這個 NFT，如果用戶用 Anonymous Telegram Number 開通了 TG 號，但沒開 Two-Step Verification，一旦這個 NFT 被釣走，黑客就可以直接登錄目標 TG 號，實施后續(xù)的資產(chǎn)盜取及欺騙行為。
智能合約漏洞
智能合約的安全漏洞會導(dǎo)致用戶放在智能合約的資金受損，用戶在選擇項目時需要選擇經(jīng)過良好審計的項目。TON 的智能合約主要使用 FunC 語言來編程，也有使用更高級的 Tact，或者更底層的 Fift，都是原創(chuàng)程度很高的語言。新的編程語言會帶來新的安全風(fēng)險，特別是對開發(fā)者而言，要有安全編程的良好習(xí)慣，掌握最佳安全實踐，并且在部署生產(chǎn)環(huán)境之前經(jīng)過嚴格的安全審計，限于篇幅，本文暫不討論合約安全。
假充值攻擊
錢包或交易所用戶需要注意假充值攻擊，通常有兩種類型的假充值攻擊：
假幣，攻擊者發(fā)行一個 metadata 和目標代幣相同的代幣，如果自動化入賬程序沒有檢查這是否是正確的 minter 合約，那么就會導(dǎo)致錯誤入賬。
反彈，TON 的轉(zhuǎn)賬過程需要在兩個用戶的錢包合約之間發(fā)生調(diào)用關(guān)系，如果接收方的錢包合約不存在，并且交易設(shè)置為 Bounceable，這時消息會被反彈，原始資金在扣除手續(xù)費后將返還給發(fā)送方。對細節(jié)感興趣的朋友可以查看我們之前披露過的假充值文章。
總結(jié)
本文從 TON 的公私鑰創(chuàng)建、錢包合約、Token 的形式、交易特性等角度介紹了 TON 的一些基礎(chǔ)的技術(shù)原理，同時也探討了使用 TON 的過程中可能存在的安全問題，希望能給大家的學(xué)習(xí)帶來啟發(fā)。
參考鏈接：
https://docs.ton.org/
https://github.com/ton-blockchain/wallet-contract
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
