TON智能合約的安全隱患與優(yōu)化建議
在區(qū)塊鏈技術(shù)快速發(fā)展的今天，TON (The Open Network) 作為一款高效且靈活的區(qū)塊鏈平臺，正受到越來越多開發(fā)者的關(guān)注。TON 的獨(dú)特架構(gòu)和特性為去中心化應(yīng)用的開發(fā)提供了強(qiáng)大的工具和豐富的可能性。
然而，隨著功能和復(fù)雜性的增加，智能合約的安全性也變得越來越重要。FunC 作為 TON 上的智能合約編程語言，以其靈活性和高效性著稱，但同時也帶來了許多潛在的風(fēng)險和挑戰(zhàn)。編寫安全可靠的智能合約，需要開發(fā)者深刻理解 FunC 語言的特性以及可能存在的風(fēng)險。
本文將詳細(xì)分析在 TON 區(qū)塊鏈上的一些與智能合約有關(guān)的特性，以及TON上智能合約容易被忽略的漏洞點(diǎn)。
Ton 異步特性與賬戶機(jī)制解析
智能合約異步調(diào)用
網(wǎng)絡(luò)分片與異步通信
TON 區(qū)塊鏈在設(shè)計上分為三種鏈：主鏈(Masterchain)，工作鏈(Workingchains）和分片鏈(Shardchains)。
主鏈?zhǔn)钦麄€網(wǎng)絡(luò)的核心，負(fù)責(zé)存儲全網(wǎng)的元數(shù)據(jù)和共識機(jī)制。它記錄所有工作鏈和分片鏈的狀態(tài)，并確保全網(wǎng)的一致性和安全性。工作鏈?zhǔn)仟?dú)立的區(qū)塊鏈，最多有 2^32條，負(fù)責(zé)處理特定類型的交易和智能合約。每個工作鏈可以有自己的規(guī)則和特性，以滿足不同的應(yīng)用需求。分片鏈?zhǔn)枪ぷ麈湹淖渔?，用于進(jìn)一步分割工作鏈的負(fù)載，提升處理能力和擴(kuò)展性。每個工作鏈最多拆分為 2^60 個 shard chain，分片鏈獨(dú)立處理部分交易，從而實現(xiàn)高效的并行處理。
理論上每一個賬戶都可以獨(dú)占一個 shard chain，每一個賬戶獨(dú)立維護(hù)自己的 COIN/TOKEN 余額，每一個賬戶間的交易都可以完全并行。賬戶與賬戶間通過異步消息進(jìn)行傳遞，消息在 shard chain 間傳遞的路徑為 log_16(N) - 1，其中 N 為 shard chain 的數(shù)量。
圖源：https://frontierlabzh.medium.com/ton-web3世界的weixin-e1d3ae3b3574
在Ton中，智能合約通過發(fā)送和接收消息進(jìn)行交互。這些消息可以是內(nèi)部消息（一般來說是智能合約互相交互所發(fā)送的消息）或外部消息（由外部來源發(fā)送的消息）。消息的傳遞過程不需要等待目標(biāo)合約的立即響應(yīng)，發(fā)送方可以繼續(xù)執(zhí)行其余的邏輯代碼。這種異步消息傳遞機(jī)制相較于以太坊的同步調(diào)用，提供了更高的靈活性和擴(kuò)展性，減少了因等待響應(yīng)導(dǎo)致的性能瓶頸，同時也帶來了處理并發(fā)和競爭條件的挑戰(zhàn)。
消息格式與結(jié)構(gòu)
在Ton中，消息通常包含發(fā)件人、收件人、金額、消息體等信息。消息體可以是函數(shù)調(diào)用、數(shù)據(jù)傳輸或其他自定義內(nèi)容。Ton使用的消息格式可以靈活定義和擴(kuò)展，使得不同合約之間能夠高效傳遞各種類型的信息。
消息隊列與狀態(tài)處理
每個合約都維護(hù)一個消息隊列，存儲尚未處理的消息。合約在執(zhí)行過程中，會根據(jù)隊列中的消息逐個處理。由于消息處理是異步的，合約的狀態(tài)在收到消息之前不會立即更新。
異步消息傳遞的優(yōu)勢
•高效的分片機(jī)制：Ton的異步機(jī)制與其分片設(shè)計高度契合。每個分片獨(dú)立處理合約的消息和狀態(tài)變化，避免了跨分片同步通信帶來的延遲問題。這種設(shè)計提升了整個網(wǎng)絡(luò)的吞吐量和可擴(kuò)展性。
•降低資源消耗：由于異步消息不要求即時響應(yīng)，Ton的合約執(zhí)行可以分散在多個區(qū)塊內(nèi)完成，避免了單個區(qū)塊內(nèi)資源的過度消耗。這使得Ton能夠支持更為復(fù)雜和資源密集型的智能合約。
•容錯性與可靠性：異步消息的傳遞機(jī)制使得系統(tǒng)更具容錯性。例如，如果某個合約由于資源限制或其他原因無法及時響應(yīng)消息，發(fā)送方仍然可以繼續(xù)處理其他邏輯，系統(tǒng)不會因為單個合約的延遲而停滯。
異步合約設(shè)計的挑戰(zhàn)
•狀態(tài)一致性問題：由于消息傳遞是異步的，合約的狀態(tài)在不同時刻可能會接收到不同的消息，這需要開發(fā)者特別注意狀態(tài)一致性問題。在設(shè)計合約時，必須考慮到不同消息順序可能帶來的狀態(tài)變化，確保系統(tǒng)在任何情況下都能保持一致性。
•競爭條件與防護(hù)：異步消息處理帶來了潛在的競爭條件問題，多個消息可能同時嘗試修改合約狀態(tài)。開發(fā)者需要引入適當(dāng)?shù)逆i機(jī)制或使用事務(wù)性操作來防止?fàn)顟B(tài)沖突。
•安全性考量：異步合約在處理跨合約通信時，容易受到中間人攻擊或重放攻擊。因此，在設(shè)計異步合約時，必須考慮到這些潛在的安全風(fēng)險，并采取措施防止它們發(fā)生，如使用時間戳、隨機(jī)數(shù)或多重簽名等手段。
賬本模型
Ton（The Open Network）在設(shè)計其區(qū)塊鏈基礎(chǔ)設(shè)施時，采用了一種獨(dú)特的賬戶抽象和賬本模型。這個模型的靈活性體現(xiàn)在它如何處理賬戶的狀態(tài)、消息傳遞以及合約的執(zhí)行。
賬戶抽象
Ton的賬戶模型采用了一種基于合約的抽象，每個賬戶都可以視為一個合約，這與以太坊的賬戶抽象模型有一些相似之處，但更加靈活和通用。在Ton中，賬戶不僅僅是持有資產(chǎn)的容器，它們還包含了合約代碼和狀態(tài)數(shù)據(jù)。每個賬戶都由其代碼（Code）、數(shù)據(jù)（Data）和消息處理（Message Handling）邏輯組成。
賬戶結(jié)構(gòu)：每個Ton賬戶都有一個唯一的地址，該地址是由賬戶代碼的哈希值、部署時的初始數(shù)據(jù)以及一些其他參數(shù)組合而成的。這意味著同樣的代碼和初始數(shù)據(jù)部署在不同的環(huán)境下（例如，不同的區(qū)塊鏈或分片）可能會生成不同的地址。
靈活性：由于每個賬戶都可以運(yùn)行自己的合約代碼，因此Ton的賬戶可以實現(xiàn)非常復(fù)雜的邏輯。賬戶不僅僅是簡單的余額持有者，還可以處理復(fù)雜的狀態(tài)轉(zhuǎn)移、跨賬戶的消息通信、甚至是基于特定條件的自動化操作。這使得Ton的賬戶模型比傳統(tǒng)區(qū)塊鏈上的賬戶模型更具擴(kuò)展性和靈活性。
賬本結(jié)構(gòu)
Ton的賬本結(jié)構(gòu)設(shè)計為高效處理大規(guī)模并發(fā)交易，支持異步消息傳遞和多分片操作。每個賬戶的狀態(tài)保存在Merkle樹結(jié)構(gòu)中，這使得Ton的賬本具有高效的狀態(tài)驗證能力。
狀態(tài)存儲
賬戶的狀態(tài)信息被存儲在持久化存儲中，并通過Merkle樹進(jìn)行組織，以確保狀態(tài)的完整性和安全性。這種設(shè)計還支持狀態(tài)的高效查詢和驗證，尤其是在跨分片交易的場景中。
帳戶或智能合約狀態(tài)通常包含以下內(nèi)容：
1.基礎(chǔ)貨幣的余額
2.其他貨幣的余額
3.智能合約代碼（或其哈希）
4.智能合約的持久化數(shù)據(jù)（或其Merkle哈希）
5.有關(guān)持久化存儲單元數(shù)和使用的原始字節(jié)數(shù)的統(tǒng)計信息
6.智能合約持久存儲的付款的最近時間（實際上是主鏈塊號）
7.轉(zhuǎn)移貨幣并從此帳戶發(fā)送消息所需的公鑰（可選; 默認(rèn)情況下等于 account_id 本身）。在某些情況下，類似于比特幣交易輸出所做的，可以在此處找到更復(fù)雜的簽名檢查代碼; 然后 account_id 將等于此代碼的哈希值。
并非所有的信息都是每個帳戶必須需要的。例如，智能合約代碼僅適用于智能合約，但不適用于“簡單”賬戶。此外，雖然任何賬戶必須具有主要貨幣的非零余額（例如，基本工作鏈的主鏈和分片鏈的 Gram），但其它貨幣的余額可能為零。為了避免保留未使用的數(shù)據(jù)，在工作鏈的創(chuàng)建期間定義了一個 sum-product 類型，它使用不同的標(biāo)記字節(jié)來區(qū)分不同的“夠造函數(shù)“。最終，帳戶狀態(tài)本身被保存為 TVM 持久化存儲的單元集合。
消息傳遞與處理
Ton的賬本結(jié)構(gòu)內(nèi)置了對異步消息傳遞的支持，每個賬戶可以獨(dú)立處理接收到的消息并更新其狀態(tài)。這種異步消息機(jī)制允許賬戶之間進(jìn)行復(fù)雜的交互，而不會因為某個操作的延遲而影響其他賬戶的正常運(yùn)行。
Gas 模型
Ton（The Open Network）區(qū)塊鏈通過其獨(dú)特的 Gas 費(fèi)模型大幅優(yōu)化了智能合約的執(zhí)行效率。Gas 費(fèi)模型在區(qū)塊鏈中用于衡量和限制智能合約執(zhí)行過程中消耗的資源。與傳統(tǒng)區(qū)塊鏈（如以太坊）的 Gas 模型相比，Ton 的模型設(shè)計更為復(fù)雜且高效，能夠更精確地管理合約執(zhí)行過程中的資源消耗。
細(xì)化的Gas消耗測量
Ton的Gas模型能夠精確測量智能合約在執(zhí)行過程中消耗的計算資源、存儲操作以及消息傳遞成本。通過對計算、存儲和消息傳遞等資源的細(xì)化測量，Ton 的 Gas 模型能夠防止某些復(fù)雜度過高的操作占用過多的資源。通過限制 Gas 消耗，Ton 確保了網(wǎng)絡(luò)的每個節(jié)點(diǎn)都能公平地分配計算資源，避免單一合約或操作對網(wǎng)絡(luò)資源的過度消耗。
并行處理與 Gas 優(yōu)化
Ton 支持智能合約的并行處理，這使得多個合約能夠同時在不同的分片上運(yùn)行，而不會相互阻塞。在這種設(shè)計下，其 Gas 模型與其并行執(zhí)行和分片機(jī)制緊密結(jié)合，通過在多個分片上并行處理合約，Ton 可以將 Gas 的計算和支付分散到不同的節(jié)點(diǎn)和鏈上，避免了網(wǎng)絡(luò)擁堵，同時最大化了資源利用率。
動態(tài) Gas 調(diào)整機(jī)制
Ton 的 Gas 模型中包含了動態(tài)調(diào)整機(jī)制，允許根據(jù)網(wǎng)絡(luò)的實時負(fù)載情況對 Gas 費(fèi)進(jìn)行調(diào)整。這意味著在網(wǎng)絡(luò)負(fù)載較低時，用戶可以以較低的 Gas 費(fèi)執(zhí)行合約，從而鼓勵在低負(fù)載時段進(jìn)行操作，平衡網(wǎng)絡(luò)的資源使用。這種機(jī)制不僅提升了用戶體驗，還通過市場化的方式控制了資源的使用峰值。
Ton 智能合約易忽略漏洞
在我們上一篇TON的安全分析文章中已經(jīng)詳細(xì)介紹了Ton生態(tài)的常規(guī)安全漏洞，也可參考下表:
本文將重點(diǎn)介紹我們團(tuán)隊總結(jié)出的TON合約中容易被忽略的漏洞點(diǎn)：
(1) 代碼可讀性優(yōu)化
在TON的智能合約中，會使用數(shù)字來存儲消息發(fā)送的相關(guān)數(shù)據(jù)，例如下面的代碼中，多次使用數(shù)字來表示對應(yīng)的標(biāo)識和數(shù)據(jù)存儲長度，這樣大大降低降低代碼的可讀性和可維護(hù)性。其他開發(fā)者在閱讀這些代碼時，很難理解這些數(shù)字的意義和用途。為了提高代碼的可讀性和可維護(hù)性，建議將關(guān)鍵的數(shù)字值定義為具名常量，例如：0x18定義為NON_BOUNCEABLE。
另外，在合約判斷條件中的錯誤提示信息，同樣建議定義對應(yīng)的變量替換錯誤碼。
(2)使用end_parse()確保數(shù)據(jù)完整性
在TON合約中，數(shù)據(jù)解析遵循固定的順序，從原始數(shù)據(jù)中逐步加載指定類型的數(shù)據(jù)。這種解析方式確保了數(shù)據(jù)的一致性和準(zhǔn)確性。如下所示：
注意這里的end_parse()用于檢查數(shù)據(jù)切片（slice）是否為空，如果切片不為空，函數(shù)會拋出一個異常。這樣可確保數(shù)據(jù)的格式和內(nèi)容都是符合預(yù)期的。如果end_parse()函數(shù)發(fā)現(xiàn)數(shù)據(jù)切片中仍然有剩余的數(shù)據(jù)，這可能表明數(shù)據(jù)解析沒有完全按照預(yù)期進(jìn)行，或者數(shù)據(jù)的格式存在問題。因此，通過調(diào)用end_parse()，可以檢查是否解析過程中數(shù)據(jù)有遺漏或異常。
(3)數(shù)據(jù)記載和存儲類型不匹配引發(fā)的異常
這里主要需要說明的是int和uint的存取類型匹配，如下所示的代碼中，數(shù)據(jù)存儲時使用了store_int()來存儲int類型的值為-42，但是卻使用了load_uint()來加載這個值，這里就可能出現(xiàn)異常。
(4)inline_ref和inline修飾符的合理使用
首先，需要闡述一下inline_ref和inline修飾符的區(qū)別：
lInline：使用inline修飾符的函數(shù)，其代碼會在每次調(diào)用時被直接插入到調(diào)用位置。也就是說，每次調(diào)用函數(shù)時，函數(shù)的實際代碼會被復(fù)制到調(diào)用的位置，而不是像普通函數(shù)那樣通過跳轉(zhuǎn)到函數(shù)體執(zhí)行。
linline_ref：使用 inline_ref修飾符的函數(shù)，其代碼存儲在一個獨(dú)立的cell中。每次調(diào)用函數(shù)時，TVM通過CALLREF命令來執(zhí)行存儲在cell中的代碼，而不是在調(diào)用位置插入函數(shù)代碼。
所以，inline修飾符適用于簡單函數(shù)，減少函數(shù)調(diào)用開銷，但可能導(dǎo)致合約代碼重復(fù)；而inline_ref 修飾符適用于較復(fù)雜或被多次調(diào)用的函數(shù)，通過將函數(shù)代碼存儲在單獨(dú)的cell中來提高效率，避免了代碼重復(fù)。那么可以總結(jié)為：當(dāng)函數(shù)較大或被多個地方調(diào)用時，建議使用inline_ref；反之，則建議使用inline。
(5)確定正確的工作鏈
TON允許創(chuàng)建多達(dá)2^32條工作鏈，每條工作鏈則可以細(xì)分為多達(dá)2^60個分片，前只有2個工作鏈：主鏈(-1)和基本鏈(0)。合約中計算目標(biāo)地址時，必須明確指定目標(biāo)地址所屬的鏈ID，以確保生成的錢包地址位于正確的工作鏈上。為了避免生成錯誤地址，建議使用 force_chain() 強(qiáng)制指定鏈ID。
(6)避免錯誤碼沖突
合約設(shè)計中，為了確保規(guī)范性和避免混淆，錯誤碼的管理非常關(guān)鍵。對于TON智能合約，首先應(yīng)確保每個錯誤碼在合約中是唯一的，避免在同一個合約中定義重復(fù)的錯誤碼，以防止錯誤碼的混淆和信息的不明確；其次TON平臺或底層系統(tǒng)已經(jīng)定義了一些標(biāo)準(zhǔn)的錯誤碼，應(yīng)避免與這些系統(tǒng)錯誤碼沖突，例如333錯誤碼表示的鏈ID不匹配。所以建議合約的錯誤碼最好在400到1000之間。
(7)操作完成后需要存儲數(shù)據(jù)和調(diào)用return()
在TON智能合約中，消息處理會根據(jù)op-code選擇不同的邏輯。完成對應(yīng)業(yè)邏輯后，還需完成兩項操作：首先，如果涉及數(shù)據(jù)更改，必須調(diào)用save_data()以確保數(shù)據(jù)被存儲，否則更改將無效；其次，必須調(diào)用return()以表示該操作完成，否則將觸發(fā)throw(0xffff)異常。
綜上所述，TON 區(qū)塊鏈憑借其創(chuàng)新的架構(gòu)和靈活的開發(fā)環(huán)境，正逐漸成為去中心化應(yīng)用開發(fā)者的理想平臺。然而，隨著智能合約在 TON 生態(tài)系統(tǒng)中扮演越來越重要的角色，合約安全性問題也不容忽視。開發(fā)者應(yīng)深入了解TON 生態(tài)的特性，嚴(yán)格遵循最佳實踐，強(qiáng)化安全審計流程，確保合約的穩(wěn)健性與安全性。只有這樣，才能充分發(fā)揮 TON 平臺的優(yōu)勢，構(gòu)建更加安全可靠的去中心化應(yīng)用，為整個生態(tài)系統(tǒng)的健康發(fā)展保駕護(hù)航。
目前TON生態(tài)正在快速發(fā)展，吸引了大量的資金與活躍用戶。然而，隨之而來的安全問題也不容忽視。
以上就是TON智能合約的安全隱患與優(yōu)化建議的詳細(xì)內(nèi)容，更多關(guān)于TON智能合約的資料請關(guān)注腳本之家其它相關(guān)文章！
你可能感興趣的文章
-
TON未來怎么樣？從技術(shù)特點(diǎn)解讀TON幣投資價值
從技術(shù)特點(diǎn)解讀TON幣投資價值！隨著幣安上線TON生態(tài)最大的游戲Notcoin以及由全流通token經(jīng)濟(jì)模型所引發(fā)的巨量財富效應(yīng)，TON在短時間內(nèi)即取得了極大的關(guān)注，短期內(nèi)TON幣有可…
2024-06-07 -
Mass Adoption是什么？TON在實現(xiàn)Mass Adoption上的優(yōu)勢和挑戰(zhàn)
Mass Adoption（大規(guī)模普及 / 采用），一直是 Web3 最核心的挑戰(zhàn),然而，市場往往更容易聚焦短期的財富效應(yīng)，忽略項目的可持續(xù)和實現(xiàn)Mass Adoption 的關(guān)鍵因素,自 2009 年BT…
2024-09-05 -
TON為何爆火？盤點(diǎn)TON生態(tài)上有哪些值得關(guān)注的熱門項目
今年以來，TON生態(tài)發(fā)展迅速，成為加密市場中無可爭議的黑馬,TON的TVL已經(jīng)躍升至加密市場前十，最近一個月資金凈流入26.59%，其表現(xiàn)仍然強(qiáng)勢,那么，TON為何爆火？TON生態(tài)上…
2025-05-07 -
TON網(wǎng)絡(luò)中斷的危機(jī)：TON底層設(shè)計局限與驗證者問題
TON一路走來，從誕生時就面臨著重大危機(jī)，后依靠社區(qū)自治完成涅槃,并且在早期發(fā)展時也面臨著熱度低，生態(tài)貧瘠,相必目前的狀況對于曾經(jīng)的TON生態(tài)而言，并不足以產(chǎn)生“致命威…
2024-09-02 -
TON網(wǎng)絡(luò)停止出塊超七小時，原因是什么？有何影響？
TON 網(wǎng)絡(luò)于北京時間8 月28 日早上6 點(diǎn)左右停止產(chǎn)生新區(qū)塊，這次意外的中斷引起了人們對該網(wǎng)絡(luò)的關(guān)注，在停機(jī)7 個多小時后，TON 宣布區(qū)塊鏈已開始正常出塊,那么，此次TON 網(wǎng)…
2024-08-30 -
TON生態(tài)日趨繁榮 爆發(fā)背后的幾個事實
TON生態(tài)你不得不知道的N個真相！短短4個月，在幣安加持下，Ton生態(tài)一路高歌猛進(jìn)，吊打一眾天王級L1、L2,期間，大家的認(rèn)知不斷被刷新，有力挺，也有質(zhì)疑，誰也無法說服誰…
2024-08-26 -
Telegram創(chuàng)始人被捕，資金大量撤出，TON生態(tài)還有價值嗎？
Telegram創(chuàng)始人被捕后TON還值得投資嗎？Telegram 平臺受創(chuàng)始人被捕消息影響或許將面臨平臺用戶量減少等情況，但對 TON 生態(tài)來說并不會“傷筋動骨”,而在言論 自由越發(fā)珍貴…
2024-08-25 -
DOGS爆火后TON生態(tài)一路長紅背后的秘密
詳解DOGS快速崛起之路！2024年8月21日，隨著Binance Launchpool的正式公告，TON鏈上的新晉meme幣DOGS即將在全球最大加密貨幣交易所Binance上線…
2024-08-22 -
一文全面解讀TON生態(tài)：進(jìn)展、用戶獲取與潛在風(fēng)險
TON 區(qū)塊鏈雖然仍處于早期階段，但前景廣闊,它與 Telegram 的 9 億用戶的整合為大規(guī)模采用提供了獨(dú)特的機(jī)會,鏈上指標(biāo)的快速增長、主要基金的大力支持以及各種生態(tài)系統(tǒng)項目…
2024-08-21 -
TON上線幣安后如何在TON生態(tài)找到潛力項目？
整個開放聯(lián)賽就像是 TON 生態(tài)的一次英雄會，借助關(guān)注度，既招攬了天下英才，又賺到了行業(yè)的“注意力”，而通過觀察競賽項目的價格變化，就能看到價值的直接“變現(xiàn)”能力，…
2024-08-20
