原文作者：@Web3Mario

原文來(lái)源：TechFlow

引言：隨著幣安上線 TON 生態(tài)最大的游戲 Notcoin 以及由全流通 token 經(jīng)濟(jì)模型所引發(fā)的巨量財(cái)富效應(yīng)，TON 在短時(shí)間內(nèi)即取得了極大的關(guān)注。和朋友聊了下得知 TON 的技術(shù)門檻比較高，而且 DApp 開發(fā)范式與主流公鏈協(xié)議有很大的差異，因此花了一些時(shí)間深入研究了一下相關(guān)課題，有些心得體會(huì)，與諸君分享。簡(jiǎn)而言之，TON 的核心設(shè)計(jì)理念是以一種「自下而上」的方式重構(gòu)傳統(tǒng)的區(qū)塊鏈協(xié)議，并以舍棄互操作性為代價(jià)，實(shí)現(xiàn)對(duì)高并發(fā)和高可擴(kuò)展性的極致追求。

TON 的核心設(shè)計(jì)思想——高并發(fā)與高可擴(kuò)展性

可以這么說(shuō)，TON 中所有復(fù)雜的技術(shù)選型的目的都來(lái)自于對(duì)高并發(fā)與高可擴(kuò)展性的追求，當(dāng)然從其誕生的背景我們也不難理解這一點(diǎn)。TON，即 The Open Network，是一個(gè)去中心化的計(jì)算網(wǎng)絡(luò)，包含一個(gè) L1 區(qū)塊鏈和多個(gè)組件。TON 最初由 Telegram 的創(chuàng)始人 Nikolai Durov 及其團(tuán)隊(duì)共同開發(fā)，而發(fā)展到現(xiàn)在則由全球獨(dú)立貢獻(xiàn)者的社區(qū)支持并維護(hù)。其誕生要追溯到 2017 年，Telegram 團(tuán)隊(duì)開始為自己探索區(qū)塊鏈解決方案。由于當(dāng)時(shí)沒有現(xiàn)有的 L1 區(qū)塊鏈能夠支持 Telegram 的九位數(shù)用戶基礎(chǔ)，他們決定設(shè)計(jì)自己的區(qū)塊鏈，當(dāng)時(shí)稱為 Telegram Open Network。時(shí)間來(lái)到了 2018 年，為了獲得實(shí)現(xiàn) TON 所需的資源，Telegram 在 2018 年第一季度發(fā)起了 Gram 代幣（后來(lái)改名為 Toncoin）的銷售。2020 年由于監(jiān)管問題，Telegram 團(tuán)隊(duì)退出了 TON 項(xiàng)目。隨后，一小部分開源開發(fā)者和 Telegram 比賽獲勝者接手了 TON 的代碼庫(kù)，將項(xiàng)目名稱更名為 The Open Network，并繼續(xù)積極地開發(fā)區(qū)塊鏈至今，且遵循原始 TON 白皮書中概述的原則。

那么既然是以作為 Telegram 的去中心化執(zhí)行環(huán)境作為設(shè)計(jì)目標(biāo)，自然要面對(duì)兩個(gè)問題，高并發(fā)請(qǐng)求與海量數(shù)據(jù)，我們知道隨著技術(shù)發(fā)展到現(xiàn)在，號(hào)稱 TPS 最高的 Solana 實(shí)測(cè)最高 TPS 也只有 65000，這顯然不足以支撐百萬(wàn)級(jí) TPS 要求的 Telegram 生態(tài)。與此同時(shí)隨著 Telegram 的大規(guī)模應(yīng)用，其產(chǎn)生的數(shù)據(jù)量早已突破天際，而區(qū)塊鏈作為一個(gè)極度冗余的分布式系統(tǒng)，若要求網(wǎng)絡(luò)中每個(gè)節(jié)點(diǎn)都保存一份完整的數(shù)據(jù)，這也是不現(xiàn)實(shí)的。

因此為了解決上述兩個(gè)問題，TON 對(duì)主流的區(qū)塊鏈協(xié)議做出了兩個(gè)方面的優(yōu)化：

通過(guò)采用「無(wú)限分片范式」（Infinite Sharding Paradigm）設(shè)計(jì)系統(tǒng)，解決數(shù)據(jù)冗余問題，使其可以承載大數(shù)據(jù)，同時(shí)緩解性能瓶頸問題；

通過(guò)引入基于 Actor 模型的完全并行執(zhí)行環(huán)境，極大的提升網(wǎng)絡(luò) TPS；

當(dāng)下我們知道，分片（sharding）已經(jīng)成為了大部分區(qū)塊鏈協(xié)議提升性能降低成本的主流方案，而 TON 則將這點(diǎn)做到了極致，并提出了無(wú)限分片范式，所謂無(wú)限分片范式，指的是允許區(qū)塊鏈根據(jù)網(wǎng)絡(luò)負(fù)載動(dòng)態(tài)地增加或減少分片數(shù)量。這種范式使得 TON 能夠在保持高性能的同時(shí)，處理大規(guī)模的交易和智能合約操作，理論上 TON 可以為每個(gè)賬戶都建立一條專屬的賬戶鏈，并通過(guò)一定的規(guī)則保證這些鏈之間的一致性，

抽象的來(lái)理解，在 TON 中一共存在四層鏈結(jié)構(gòu)：

賬戶鏈（AccountChain）：該層鏈表示與某個(gè)賬戶相關(guān)的一系列交易所組成的鏈，之所以交易可以組成鏈?zhǔn)浇Y(jié)構(gòu)，是因?yàn)閷?duì)于一個(gè)狀態(tài)機(jī)來(lái)說(shuō)，只要執(zhí)行規(guī)則一致，狀態(tài)機(jī)在接收到相同順序的指令后得到的結(jié)果是一致的，因此所有區(qū)塊鏈分布式系統(tǒng)中都需要對(duì)交易進(jìn)行鏈?zhǔn)脚判?，TON 也不例外。賬戶鏈?zhǔn)?TON 網(wǎng)絡(luò)中最基本的組成單元，通常情況下賬戶鏈?zhǔn)且粋€(gè)虛擬的概念，不太可能真正存在一個(gè)獨(dú)立的賬戶鏈。

分片鏈（ShardChain）：在大部分的語(yǔ)境下，分片鏈才是 TON 中實(shí)際的組成單元，所謂分片鏈，即為一組賬戶鏈的集合。

工作鏈（WorkChain）：也可以叫做一組有自定義規(guī)則的分片鏈，例如創(chuàng)建一個(gè)基于 EVM 的工作鏈，在其上運(yùn)行 Solidity 智能合約。理論上，社區(qū)中的每個(gè)人都可以創(chuàng)建自己的工作鏈。事實(shí)上，構(gòu)建它是一個(gè)相當(dāng)復(fù)雜的任務(wù)，在此之前還要支付創(chuàng)建它的（昂貴）費(fèi)用，并獲得驗(yàn)證者的 2/3 的票數(shù)來(lái)批準(zhǔn)創(chuàng)建你的工作鏈。

主鏈（MasterChain）：最后在 TON 中有一條特殊的鏈被稱為主鏈，該鏈負(fù)責(zé)為所有分片鏈帶來(lái)最終性。一旦分片鏈的區(qū)塊的哈希值被合并到主鏈的區(qū)塊中，該分片鏈區(qū)塊及其所有父區(qū)塊被認(rèn)為具有最終性，這意味著它們可以被認(rèn)為是固定且不可變的內(nèi)容，而被所有分片鏈的后續(xù)區(qū)塊引用。

通過(guò)采用這樣的范式，使 TON 網(wǎng)絡(luò)具備以下三個(gè)特點(diǎn):

動(dòng)態(tài)分片: TON 可以自動(dòng)拆分和合并分片鏈以適應(yīng)負(fù)載的變化。這意味著新塊總是快速生成，而交易不會(huì)產(chǎn)生很長(zhǎng)的等待時(shí)間。

高度可擴(kuò)展: 通過(guò)無(wú)限分片范式，TON 能夠支持幾乎無(wú)限數(shù)量的分片，理論上可以達(dá)到 2 的 60 次方個(gè)工作鏈。

自適應(yīng)性: 當(dāng)網(wǎng)絡(luò)中的某個(gè)部分負(fù)載增加時(shí)，該部分可以被細(xì)分成更多的分片來(lái)處理增加的交易量。相反，當(dāng)負(fù)載減少時(shí)，分片可以合并以提高效率。

那么這樣一個(gè)多鏈系統(tǒng)，首先需要面臨的就是跨鏈通信問題，尤其是由于具有無(wú)限分片的能力，當(dāng)網(wǎng)絡(luò)中的分片數(shù)量達(dá)到一定量級(jí)后，鏈與鏈之間的信息路由將成為一件困難的事情。試想一下網(wǎng)絡(luò)中共有 4 個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)負(fù)責(zé)維護(hù) 1 條獨(dú)立的工作鏈，其中鏈接關(guān)系表示該節(jié)點(diǎn)除了負(fù)責(zé)自身的工作鏈中交易排序工作之外，還需要監(jiān)聽并處理目標(biāo)鏈中狀態(tài)變化，在 TON 中具體通過(guò)監(jiān)聽輸出隊(duì)列的消息實(shí)現(xiàn)，

展開全文

假設(shè)工作鏈 1 中的賬戶 A 希望向工作鏈 3 中的賬戶 C 發(fā)送一個(gè)消息。則需要設(shè)計(jì)到消息路由問題，在這個(gè)例子中有兩條路由路徑，工作鏈 1 -> 工作鏈 2-> 工作鏈 3，工作鏈 1 -> 工作鏈 4 -> 工作鏈 3。

當(dāng)面臨更復(fù)雜的情況時(shí)，就需要一個(gè)高效且低成本的路由算法快速完成消息通信，TON 選擇了所謂「超立方體路由算法」來(lái)實(shí)現(xiàn)跨鏈消息通信路由發(fā)現(xiàn)。所謂超立方體結(jié)構(gòu)指的是一種特殊的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，一個(gè) n 維超立方體是由 2^n 個(gè)頂點(diǎn)組成的，每個(gè)頂點(diǎn)都可以通過(guò)一個(gè) n 位的二進(jìn)制數(shù)來(lái)唯一標(biāo)識(shí)。在這個(gè)結(jié)構(gòu)中，任意兩個(gè)頂點(diǎn)如果在二進(jìn)制表示中只有一位不同，那么它們就是相鄰的。例如，在一個(gè) 3 維超立方體中，頂點(diǎn) 000 和頂點(diǎn) 001 是相鄰的，因?yàn)樗鼈冎辉谧詈笠晃簧喜煌６鲜隼蛹词且粋€(gè) 2 維超立方體。

在超立方體路由協(xié)議中，消息將從源工作鏈到目標(biāo)工作鏈的路由過(guò)程是通過(guò)比較源工作鏈和目標(biāo)工作鏈地址的二進(jìn)制表示來(lái)進(jìn)行的。路由算法會(huì)找到這兩個(gè)地址之間的最小距離（即二進(jìn)制表示中不同位的數(shù)量），并通過(guò)相鄰工作鏈逐步轉(zhuǎn)發(fā)信息，直到達(dá)到目標(biāo)工作鏈。這種方法能夠確保數(shù)據(jù)包沿著最短路徑傳輸，從而提高了網(wǎng)絡(luò)的通信效率。

當(dāng)然為了簡(jiǎn)化這個(gè)過(guò)程，TON 也提出了一個(gè)樂觀技術(shù)方案，當(dāng)用戶可以提供對(duì)某個(gè)路由路徑的有效證明，這通常是某個(gè) merkle trie root，節(jié)點(diǎn)即可直接承認(rèn)該用戶提交的消息的可信性，這也被稱為即時(shí)超立方體路由。

因此我們可以看到 TON 中的地址和其他區(qū)塊鏈協(xié)議有著明顯的區(qū)別，其他主流區(qū)塊鏈協(xié)議大都采用橢圓加密算法生成的公私鑰中公鑰對(duì)應(yīng)的哈希作為地址，因?yàn)榈刂分皇亲鑫ㄒ恍詤^(qū)分，而不需要承載路由尋址的功能，而 TON 中的地址有兩部分組成，（workchain_id, account_id），其中 workchain_id 即按照超立方體路由算法地址進(jìn)行編碼，在這里就不詳細(xì)展開了。

還有一個(gè)容易產(chǎn)生疑問的點(diǎn)，你可能已經(jīng)發(fā)覺到主鏈和每個(gè)工作鏈均有鏈接關(guān)系，那么所有跨鏈信息均通過(guò)主鏈做中繼不就可以了么，就像是 cosmos 那樣。在 TON 的設(shè)計(jì)理念中，主鏈僅用于處理最關(guān)鍵的任務(wù)，即維護(hù)眾多工作鏈的最終性，將消息通過(guò)主鏈做路由也不是不行，只是由此產(chǎn)生的手續(xù)費(fèi)用將十分昂貴。

最后簡(jiǎn)單提一下其共識(shí)算法，TON 采用了 BFT+PoS 的方式，即任意 staker 均有機(jī)會(huì)參與區(qū)塊打包，TON 的選舉治理合約會(huì)每隔一段時(shí)間，從所有 Stakers 中隨機(jī)選擇一個(gè)打包的驗(yàn)證者集群，被選中稱為驗(yàn)證者的節(jié)點(diǎn)將通過(guò) BFT 算法打包出塊，若打包錯(cuò)誤信息或作惡，其 stake 的 token 將會(huì)被罰沒，反之將得到出塊獎(jiǎng)勵(lì)。這基本上已經(jīng)是一個(gè)比較常見的選擇了，因此不在這里展開介紹。

基于 Actor 模型的智能合約和完全并行執(zhí)行環(huán)境

TON 中另一個(gè)與主流區(qū)塊鏈協(xié)議不同的點(diǎn)是其智能合約執(zhí)行環(huán)境。為了突破主流區(qū)塊鏈協(xié)議 TPS 的限制，TON 采用了自下而上的設(shè)計(jì)思路，采用 Actor 模型重構(gòu)了智能合約及其執(zhí)行方式，使其具備了完全并行執(zhí)行的能力。

我們知道主流的區(qū)塊鏈協(xié)議大都采用的是單線程串行的執(zhí)行環(huán)境，以 Ethereum 為例，其執(zhí)行環(huán)境 EVM 是一個(gè)以交易作為輸入的狀態(tài)機(jī)，當(dāng)出塊節(jié)點(diǎn)通過(guò)打包區(qū)塊完成對(duì)交易的排序后，將以該順序通過(guò) EVM 執(zhí)行交易，整個(gè)過(guò)程是完全串行并單線程的，即某個(gè)時(shí)刻只能有一筆被執(zhí)行，這樣做的好處是只要確認(rèn)了交易順序，執(zhí)行的結(jié)果在廣泛的分布式集群中就具有一致性，與此同時(shí)由于同時(shí)只有一筆交易被串行執(zhí)行，這就意味著在執(zhí)行過(guò)程中，不可能存在其他交易對(duì)某待訪問狀態(tài)數(shù)據(jù)進(jìn)行修改，這樣就實(shí)現(xiàn)了智能合約之間的互操作性。例如我們通過(guò) Uniswap 使用 USDT 購(gòu)買 ETH，當(dāng)該交易被執(zhí)行時(shí)，該交易對(duì)中 LP 的分布情況即為一個(gè)確定值，這樣就可以通過(guò)某些數(shù)學(xué)模型得出對(duì)應(yīng)的結(jié)果，但假設(shè)情況不是這樣的，在執(zhí)行某 bonding curve 的計(jì)算時(shí)，有其他 LP 添加了新的流動(dòng)性，那么計(jì)算結(jié)果將會(huì)是一個(gè)過(guò)時(shí)的結(jié)果，這顯然是不可接受的。

但是這種架構(gòu)也有明顯的局限性，那就是 TPS 的瓶頸，而這個(gè)瓶頸在當(dāng)前多核處理器下顯得很老舊，就像你用一個(gè)最新的 PC 去玩一些老的電腦游戲，比如紅警，當(dāng)作戰(zhàn)單位多到一定數(shù)量后，依然會(huì)發(fā)現(xiàn)卡的不行，這就是軟件架構(gòu)的問題。

你可能會(huì)聽到一些協(xié)議已經(jīng)在關(guān)注這個(gè)問題，并提出了自己的并行方案，以當(dāng)前號(hào)稱 TPS 最高的 Solana 為例，也具備并行執(zhí)行的能力。只不過(guò)其設(shè)計(jì)思路與 TON 不同，在 Solana 中，其核心思想是將所有交易按照?qǐng)?zhí)行依賴關(guān)系分為幾組，不同組之間不共享任何狀態(tài)數(shù)據(jù)。即不存在相同的依賴，這樣不同組內(nèi)的交易就可以并行執(zhí)行而不用擔(dān)心出現(xiàn)沖突的情況，而對(duì)于同組內(nèi)的交易，則還是沿用傳統(tǒng)的串行方式執(zhí)行。

而在 TON 中，其完全舍棄了串行執(zhí)行的架構(gòu)，轉(zhuǎn)而采用了一個(gè)專為并行而生的開發(fā)范式，Actor 模型來(lái)重構(gòu)執(zhí)行環(huán)境。所謂 Actor 模型是由 Carl Hewitt 在 1973 年首次提出，目的是通過(guò)消息傳遞來(lái)解決傳統(tǒng)并發(fā)程序中共享狀態(tài)的復(fù)雜性問題。每個(gè) Actor 都有自己的私有狀態(tài)和行為，且與其他 Actor 之間不共享任何狀態(tài)信息。Actor 模型是一種并發(fā)計(jì)算的計(jì)算模型，它通過(guò)消息傳遞來(lái)實(shí)現(xiàn)并行計(jì)算。在這個(gè)模型中，「Actor」是基本的工作單元，它能夠處理接收的消息、創(chuàng)建新的 Actor、發(fā)送更多消息、決定如何響應(yīng)接下來(lái)的消息。Actor 模型需要具備以下幾個(gè)特性：

封裝和獨(dú)立性：每個(gè) Actor 在處理消息時(shí)都是完全獨(dú)立的，可以并行處理消息而不會(huì)互相干擾。

消息傳遞：Actor 之間僅通過(guò)發(fā)送和接收消息進(jìn)行交互，消息傳遞是異步的。

動(dòng)態(tài)結(jié)構(gòu)：Actor 可以在運(yùn)行時(shí)創(chuàng)建更多的 Actor，這種動(dòng)態(tài)性使得 Actor 模型能夠根據(jù)需要擴(kuò)展系統(tǒng)。

TON 采用了這個(gè)架構(gòu)，來(lái)設(shè)計(jì)智能合約模型，這就意味著在 TON 中，每個(gè)智能合約都是一個(gè) Actor 模型，其具備完全獨(dú)立的存儲(chǔ)空間。因?yàn)椴灰蕾嚾魏瓮獠繑?shù)據(jù)。除此之外，對(duì)同一個(gè)智能合約的調(diào)用還是按照接收隊(duì)列中消息的排序進(jìn)行執(zhí)行，因此 TON 中的交易將可以被高效的并行執(zhí)行，而不需要擔(dān)心沖突問題。

然而這樣的設(shè)計(jì)方案也帶來(lái)了一些全新的影響，對(duì)于 DApp 開發(fā)者來(lái)說(shuō)，其習(xí)慣的開發(fā)范式將被打破，具體如下：

1. 智能合約之間的異步調(diào)用：在 TON 的智能合約內(nèi)部是無(wú)法原子性的調(diào)用外部合約或訪問外部合約數(shù)據(jù)的，我們知道在 Solidity 中，合約 A 的 function1 中調(diào)用合約 B 的 function2，或者通過(guò)合約 C 的只讀 function3 訪問某狀態(tài)數(shù)據(jù)，整個(gè)過(guò)程是原子性的，在一筆交易中被執(zhí)行，這是一件非常容易的事情，然而在 TON 中，這將不可能實(shí)現(xiàn)，任何與外部智能合約的交互都將通過(guò)打包新的交易異步執(zhí)行，這種由智能合約發(fā)起的交易也被稱為內(nèi)部消息。且執(zhí)行過(guò)程中無(wú)法阻塞以獲得執(zhí)行結(jié)果。

例如我們開發(fā)一個(gè) DEX，如果采用 EVM 中常見的范式，通常會(huì)有一個(gè)統(tǒng)一的 router 合約用于管理交易路由，而每個(gè) Pool 都單獨(dú)管理某個(gè)交易對(duì)相關(guān)的 LP 數(shù)據(jù)，那么假設(shè)當(dāng)前有兩個(gè)池子 USDT-DAI 和 DAI-ETH。當(dāng)用戶希望通過(guò) USDT 直接購(gòu)買 ETH，就可以通過(guò) router 合約在一筆交易中順序請(qǐng)求這兩個(gè)池子，完成原子性交易。然而在 TON 中就沒有這么容易實(shí)現(xiàn)了，需要思考新的開發(fā)范式，若仍然復(fù)用該該范式的話，那信息流可能是這樣的，這個(gè)請(qǐng)求將伴隨一個(gè)由用戶發(fā)起的 external message 和三個(gè) internal messages 完成（注意這是用于說(shuō)明差異性的，真實(shí)的開發(fā)中甚至連 ERC20 的范式也要重新設(shè)計(jì)）。

2. 需要仔細(xì)考慮跨合約調(diào)用時(shí)出現(xiàn)執(zhí)行錯(cuò)誤情況的處理流程，為每個(gè)合約間調(diào)用設(shè)計(jì)相應(yīng)的彈回（bounce）函數(shù)。我們知道在主流的 EVM 中，當(dāng)交易執(zhí)行時(shí)遇到問題時(shí)，整個(gè)交易將會(huì)被回滾，即被重置到執(zhí)行最初時(shí)的狀態(tài)。這在串行單線程模型中是容易理解的。然而在 TON 中，由于合約間調(diào)用采用了異步的方式執(zhí)行，即使后續(xù)某環(huán)節(jié)出錯(cuò)，由于前面已經(jīng)被成功執(zhí)行的交易已經(jīng)被執(zhí)行并確認(rèn)，這就有可能造成問題。因此 TON 中設(shè)置了一種特殊的消息類型，叫做彈回消息，即當(dāng)某內(nèi)部消息觸發(fā)的后續(xù)執(zhí)行過(guò)程出現(xiàn)錯(cuò)誤時(shí)，被觸發(fā)合約可以通過(guò)觸發(fā)合約預(yù)留的彈回函數(shù)將觸發(fā)合約中的某些狀態(tài)重置。

3. 在某些復(fù)雜情況下，先被接收的交易不一定先被執(zhí)行完畢，因此不可以預(yù)設(shè)這種時(shí)序關(guān)系。在這樣一個(gè)異步和并行智能合約調(diào)用的系統(tǒng)中，定義處理操作順序可能很難。這就是為什么 TON 中的每個(gè)消息都有它的邏輯時(shí)間 Lamport time（后面簡(jiǎn)稱 lt）。它用于理解哪個(gè)事件引發(fā)了另一個(gè)以及驗(yàn)證者首先需要處理什么。對(duì)于一個(gè)簡(jiǎn)單的模型，先被接收的交易一定先被執(zhí)行完成。

在這個(gè)模型中，A 和 B 分別表示兩個(gè)智能合約，則有如果 msg1_lt

然而在較為復(fù)雜的情況下，這個(gè)規(guī)則就會(huì)被打破。在官方文檔中有這樣的例子，假設(shè)我們有三個(gè)合約 A、B 和 C。在一筆交易中，A 發(fā)送兩個(gè)內(nèi)部消息 msg1 和 msg2：一個(gè)給 B，另一個(gè)給 C。盡管它們是按確切順序創(chuàng)建的（先 msg1，然后是 msg2），但我們無(wú)法確定 msg1 將在 msg2 之前被處理。這是因?yàn)閺?A 到 B 和從 A 到 C 的路由可能在長(zhǎng)度和驗(yàn)證者集中有所不同。如果這些合約位于不同的分片鏈中，其中一條消息可能需要幾個(gè)區(qū)塊才能到達(dá)目標(biāo)合約。即我們有兩種可能的交易路徑，如圖所示。

4. 在 TON 中，其智能合約的持久化存儲(chǔ)采用了一個(gè)以 Cell 為單元的有向無(wú)環(huán)圖作為數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)將按照編碼規(guī)則緊湊的壓縮為一個(gè) Cell，同時(shí)按照有向無(wú)環(huán)圖的方式向下延伸，這與 EVM 中狀態(tài)數(shù)據(jù)基于 hashmap 的結(jié)構(gòu)組織不同，由于數(shù)據(jù)請(qǐng)求算法的不同，TON 中為不同深度的數(shù)據(jù)處理設(shè)置了不同的 Gas 價(jià)格，越深的 Cell 數(shù)據(jù)處理所需要的 Gas 越高，因此在 TON 中存在一種 DOS 攻擊的范式，即某些惡意用戶通過(guò)發(fā)送大量垃圾消息占用某個(gè)智能合約中所有的淺層 Cell，這就意味著誠(chéng)實(shí)用戶的存儲(chǔ)成本將越來(lái)越高。而在 EVM 中，由于 hashmap 的查詢復(fù)雜度為 o(1)，因此有著相同的 Gas，不會(huì)有類似問題。所以 TON Dapp 開發(fā)者應(yīng)該盡量避免智能合約中出現(xiàn)無(wú)界數(shù)據(jù)類型。當(dāng)出現(xiàn)無(wú)界數(shù)據(jù)類型時(shí)，應(yīng)通過(guò)分片的方式將其打散。

5. 還有一些特征則不那么特殊了，例如智能合約需要為存儲(chǔ)支付租金，在 TON 中智能合約天然是可升級(jí)的，以及原生的抽象賬戶功能，即在 TON 中所有錢包地址均為智能合約，只是未被初始化等，這些需要開發(fā)者小心留意。

以上是這段時(shí)間我學(xué)習(xí) TON 相關(guān)技術(shù)的一些心得，與諸君分享，有寫錯(cuò)的地方還望大家指正，與此同時(shí)，我認(rèn)為憑借著 Telegram 天量的流量資源，TON 生態(tài)一定會(huì)為 Web3 帶來(lái)一些全新的應(yīng)用，有對(duì) TON DApp 開發(fā)感興趣的小伙伴也可以聯(lián)系我，和我們一起討論。