簡介：幣安推出TON生態系統中最大的遊戲Notcoin后，其全流通的代幣經濟創造了巨大的財富效應，TON迅速獲得了很多關注。和朋友聊天，發現TON技術壁壘高，DApp開發模式與主流區塊鏈協定大不相同。因此，我花了一些時間深入研究這個主題，並有一些見解可以與您分享。空年，TON的核心設計理念是從頭開始重建傳統的區塊鏈協定，專注於實現高併發性和可擴充性，即使這意味著犧牲互操作性。

TON的核心設計原則——高併發性和可擴充

可以說，TON所有複雜技術選擇的目的，都源於對高併發、高可擴展性的追求。當然，我們從它的誕生背景來理解這一點並不難理解。TON或開放網路是一個分散的計算網路，包括一個L1區塊鏈和多個元件。TON最初由Telegram創始人尼古拉·杜羅夫（Nikolai Durov）及其團隊開發，現在由全球獨立貢獻者社區支持和維護。它的誕生可以追溯到2017年，當時Telegram團隊開始為自己探索區塊鏈解決方案。由於當時沒有現有的L1區塊鏈可以支撐Telegram的九位數使用者群，他們決定設計自己的區塊鏈，然後稱為Telegram Open Network。時間到了2018年。單子，為了獲得實施TON所需的資源，Telegram在2018年第一季度啟動了Gram代幣（后更名為Toncoin）的銷售。2020年，由於監管問題，Telegram團隊退出了TON專案。隨後，一小群開源開發者和Telegram競賽獲勝者接管了TON的代碼庫，將專案更名為The Open Network，並繼續積極開發區塊鏈，直到今天，堅持原始TON白皮書中概述的原則。

由於TON被設計為Telegram的去中心化執行環境，它必須解決兩個主要挑戰：高併發請求和海量數據。即使是聲稱是最快的Solana的最高測試每秒交易量(TPS)（每秒交易數），也只有65,000，遠遠空Telegram所需的百萬級每秒交易量(TPS)。此外，Telegram生成的大量數據無法由區塊鏈管理，因為每個節點都存儲了數據的完整副本。

為了應對這些挑戰，TON通過兩種方式優化了主流區塊鏈協定：

l 它使用「無限分片範式」來減少數據冗餘，使其能夠處理大量數據並緩解性能瓶頸。

l 通過引入基於Actor模型的全並行執行環境，網路每秒交易量(TPS)得到極大提升;

構建一個鏈區塊鏈 - 通過無限分片為每個帳戶提供自己的專用鏈

我們現在知道，分片已經成為大多數區塊鏈協定提高性能和降低成本的主流解決方案，TON將這一點發揮到了極致，提出了無限分片範式，即所謂的無限分片範式。 指允許區塊鏈根據網路負載動態增加或減少分片數量。這種範式使TON能夠處理大規模交易和智慧合約操作，同時保持高性能。理論上，TON可以為每個帳戶建立一個獨佔的帳戶鏈，並通過一定的規則來保證這些鏈之間的互操作性。一致性，

從本質上講，TON的鏈結構由四層組成

帳戶鏈：該層表示連結到特定帳戶的一系列交易。事務形成一個鏈，因為在狀態機中，一致的執行規則確保狀態機在同一單子處理指令時產生相同的結果。因此，所有區塊鏈系統都要求交易在鏈中連結，TON也不例外。AccountChain是TON網路中最基本的單元。通常，AccountChain是一個虛擬概念，獨立的AccountChain不太可能存在。

分片鏈：在大多數情況下，分片鏈是TON內的實際單位。分片鏈本質上是帳戶鏈的集合。

WorkChain：也稱為一組具有自定義規則的分片鏈，例如基於運行 Solidity 智能合約以太坊虛擬機(EVM)創建 WorkChain。理論上，社區中的任何人都可以創建自己的工作鏈。但是，建造一個非常複雜，需要支付（高）創建費並獲得驗證者 2/3 的批准。

主鏈：TON年，有一條獨特的鏈稱為主鏈，它為所有分片鏈提供最終性。當分片鏈塊的哈希值包含在主鏈塊中時，該分片鏈塊及其所有父塊都被認為是最終的，這意味著它們是固定的和不可變的，被所有後續分片鏈塊引用。

這種範式為TON網路提供了三個關鍵特徵：

動態分片：TON可以自動拆分和合併分片鏈以適應不斷變化的負載，確保快速生成新區塊，交易不會遇到多延遲。

高可擴展性：憑藉其無限的分片範式，TON幾乎可以支撐無限數量的分片，理論上最多可達 2^60 個工作鏈。

適應性：當部分網路負載增加時，可以細分為更多分片來處理更高的事務交易量。相反，當負載減少時，分片可以合併以提高效率。

在這樣的多鏈系統中，主要的挑戰是跨鏈通信。由於具有無限分片的能力，當網路中的分片數量顯著增長時，鏈之間的路由資訊變得複雜。例如，假設一個具有四個節點的網路，每個節點維護一個獨立的工作鏈。每個節點除了管理自己的交易排序外，還必須監控和處理其他鏈中的狀態變化。在TON中，這是通過監視輸出佇列中的消息來完成的。

假設工作鏈 1 中的帳戶 A 想要向工作鏈 3 中的帳戶 C 發送消息。這需要設計郵件路由解決方案。在此示例中，有兩個路由路徑：工作鏈 1 -> 工作鏈 2 -> 工作鏈 3 和工作鏈 1 -> 工作鏈 4 -> 工作鏈 3。

在更複雜的場景中，快速消息通信需要高效且低成本的路由演演演算法。TON使用「超多維數據集路由演演演算法」跨鏈郵件路由發現。超立方體結構是一種特殊的網路拓撲，其中 n 維超立方體具有 2^n 個頂點，每個頂點由 n 位二進位數唯一標識。在此結構中，如果任意兩個頂點的二進位表示僅相差一位，則它們相鄰。例如，在三維超立方體中，頂點 000 和頂點 001 相鄰，因為它們僅在最後一位不同。上面的例子是一個二維超立方體。

在超多維數據集路由協議中，消息從源工作鏈到目標工作鏈的路由是通過比較其二進位位址來完成的。該演演演算法找到這些位址之間的最小距離（即不同位的數量），並通過相鄰的工作鏈轉發消息，直到到達目的地。這樣可以確保數據包遵循最短路徑，從而提高網路通信效率。為了簡化這一過程，TON還提供了一個樂觀的解決方案。如果使用者可以提供路由路徑的有效證明，通常是Merkle trie根，則節點可以立即驗證消息的真實性。這稱為即時超立方體路由。因此，TON位址與其他區塊鏈協定中的位址有很大不同。大多數區塊鏈協定使用橢圓加密演演演算法生成的公鑰哈希作為位址，專注於唯一性，而不需要路由功能。在TON中，位址由兩部分組成：（workchain_id，帳戶_id），workchain_id根據超立方體路由演演演算法進行編碼。有人可能想知道為什麼不通過類似於Cosmos的MasterChain傳遞所有跨鏈資訊。在TON的設計中，主鏈只處理維護工作鏈最終性的最關鍵任務。雖然可以通過主鏈路由消息，但相關費用將高得令人望而卻步。

最後，讓我們簡要討論一下它的共識演演演算法。TON採用BFT（拜占庭將軍問題容差）和權益證明（權益證明）的組合。這意味著任何質押者都可以參與區塊創建。TON選舉治理合約定期從所有質押者中隨機選擇一組驗證者。然後，這些選定的驗證者使用 BFT 演演演算法創建塊。如果驗證者創建無效區塊或惡意行為，他們的質押代幣將被沒收。相反，他們因成功創建有效區塊而獲得獎勵。這種方法很常見，所以我們不會在這裡進一步詳細介紹。

在完全並行執行環境中利用Actor模型的智能合約

與主流區塊鏈協定相比，TON的另一個關鍵區別是其智慧合約執行環境。為了克服主流區塊鏈協定面臨的每秒交易量(TPS)限制，TON採用自下而上的設計方法，採用Actor模型重構智能合約及其執行，實現完全並行的執行能力。

大多數主流區塊鏈協定使用單線程串行執行環境。例如，以太坊的執行環境（以太坊虛擬機(EVM)）作為按順序處理事務的狀態機運行。形成區塊並訂購交易后，通過以太坊虛擬機(EVM)逐個執行。這種完全串行的單線程進程意味著在任何給定時間只處理一個事務。優點是一旦建立了事務單子，執行結果在分散式網路中保持一致。此外，由於一次只執行一個事務，因此沒有其他事務可以更改正在訪問的狀態數據，從而確保智能合約之間的互操作性。例如，當使用 Uniswap 購買帶有USDT二餅時，流動性池的分佈在執行期間是固定值。這允許數學模型確定確切的結果。相反，如果其他流動性提供者在聯合曲線計算過程中增加了流動性，結果就會過時，這顯然是不可接受的。

然而，這種架構也有明顯的局限性，特別是每秒交易量(TPS)瓶頸，現代多核處理器感覺已經過時了。這類似於在全新的PC上玩紅色警戒等舊電腦遊戲;當作戰單位數量達到一定水準時，您仍然會遇到明顯的滯後。這是由於軟體體系結構問題。

一些協定正在解決這個問題，並提出了自己的並行解決方案。例如，聲稱擁有最高每秒交易量(TPS)的Solana也支援並行執行。但是，Solana的設計與TON的設計不同。Solana的核心思想是根據所有事務的執行依賴關係對所有事務進行分組，確保不同的組不共用任何狀態數據。這意味著沒有共用依賴關係，允許不同組中的事務並行執行而不會發生衝突。同一組中的事務仍按順序執行。

相比之下，TON完全放棄了串行執行架構，採用了專門為並行性設計的開發範式，使用 Actor 模型來重構其執行環境。Actor 模型由 Carl Hewitt 於 1973 年首次提出，旨在通過消息傳遞解決傳統併發程式中共用狀態的複雜性。每個Actor都有自己的私有狀態和行為，並且不會與其他Actor共享狀態資訊。Actor 模型是一種併發計算模型，通過消息傳遞實現並行處理。在此模型中，“Actor”是一個基本單元，可以處理收到的消息、創建新的Actor、發送其他消息以及決定如何回應後續消息。Actor 模型必須具有以下特徵：

封裝和獨立性：每個Actor在處理消息時完全獨立運行，允許並行消息處理而不會受到干擾。

消息傳遞：參與者僅通過發送和接收消息進行交互，消息傳遞是異步的。

動態結構：Actor可以在運行時創建額外的Actor，允許Actor模型根據需要動態擴展系統。

TON 在其智慧合約模型中採用了這種架構，這意味著TON中的每個智慧合約都基於 Actor 模型，並且具有完全獨立的存儲，因為它不依賴於任何外部數據。此外，對同一智慧合約的調用在接收佇列中的消息單子執行。這使得TON中的事務能夠有效地並行執行，而不必擔心衝突。但是，這種設計也帶來了一些新的挑戰。對於DApp開發人員來說，他們熟悉的開發模式將通過以下方式被打亂：

1. 異步智能合約調用：在TON中，無法原子調用外部合約或訪問智能合約內的外部合約數據。例如，在 Solidity 中，合約 A 的函數 1 可以直接調用合約 B 的函數 2 或通過合約 C 的唯讀函數 3 訪問某些狀態數據，所有這些都在單個事務中完成。但是，在TON中，這是無法實現的。與外部智能合約的任何交互都將通過創建新事務（稱為由智能合約發起的內部消息）來異步執行。無法阻止執行進程以等待結果。

例如，如果我們正在開發一個去中心化交易所並遵循通用以太坊虛擬機(EVM)範式，我們通常有一個統一的路由器合約來管理交易路由，而每個池獨立管理特定交易對的 LP 數據。假設我們有兩個池：USDT-DAI 和 DAI-二餅。當使用者想要直接通過USDT購買二餅時，他們可以使用路由器合約在單個原子事務中按順序與這兩個池進行交互。但是，在TON，此過程並不那麼簡單，需要不同的開發方法。如果我們嘗試重用這個以太坊虛擬機(EVM)範式，資訊流將涉及一個由用戶發起的外部消息和三個內部消息來完成交易（注意，這個例子是為了突出差異;在實際開發中，即使是 ERC20 範式也需要重新設計）。

1. 需要仔細考慮跨合約調用中的錯誤處理，為每個合約間交互設計適當的退回函數。在主流以太坊虛擬機(EVM)系統中，如果在事務執行過程中發生錯誤，整個事務將回滾到其初始狀態。這在串行單線程模型中很簡單。但是，在TON中，由於合約間調用是異步執行的，如果在稍後階段發生錯誤，則先前成功執行的事務已經得到確認，這可能會導致問題。因此，TON引入了一種稱為退回郵件的特殊郵件類型。如果後續執行內部消息時出現錯誤，觸發合約可以使用觸發合約中預留的反彈函數重置觸發合約中的某些狀態。

2. 在複雜場景下，先收到的事務可能不會先完成，因此不能假設特定的執行單子。在異步和並行智慧合約系統中，定義處理單子可能具有挑戰性。這就是為什麼TON中的每條消息都有其邏輯時間，稱為Lamport時間（lt）。它有助於確定哪個事件觸發了另一個事件以及驗證者需要首先處理的內容。在一個簡單的模型中，首先收到的交易首先執行。

在此模型中，A 和 B 表示兩個智能合約。如果msg1_lt < msg2_lt，那麼tx1_lt < tx2_lt順序。

但是，在更複雜的情況下，可以打破此規則。官方文檔提供了一個例子：假設我們有三個合約，A、B 和 C。在一個事務中，A 發送兩條內部消息 msg1 和 msg2，一條發送給 B，另一條發送給 C。儘管它們是在特定單子中創建的（首先是 msg1，然後是 msg2），但我們不能確定 msg1 將在 msg2 之前處理。出現這種不確定性是因為從 A 到 B 以及從 A 到 C 的路由在長度和驗證器集上可能有所不同。如果這些合約位於不同的分片鏈中，一條消息可能需要幾個區塊才能到達目標合約。因此，如圖所示，有兩種可能的事務路徑。

1. 在TON中，智能合約的持久存儲使用以單元為單元的有向無環圖(DAG)結構。數據根據特定的編碼規則緊湊地壓縮到單元格中，並以有向無環圖(DAG)的方式向下擴展。這與狀態數據以太坊虛擬機(EVM)中使用的基於哈希圖的結構形成鮮明對比。由於數據訪問演演演算法不同，TON為處理不同深度的數據分配了不同的gas價格;更深層次的細胞數據處理需要更多的gas。因此，TON面臨一種DOS攻擊，惡意使用者用大量垃圾郵件淹沒智能合約，填滿所有淺層單元。這增加了誠實使用者的存儲成本。相比之下，以太坊虛擬機(EVM) 的哈希圖的查詢複雜度為 O（1），可確保一致的gas成本並避免類似問題。因此，TON Dapp 開發人員應避免在智能合約中使用無限數據類型。當需要無限數據類型時，應使用分片對它們進行分區。

1. 有些功能不太獨特，例如要求智能合約支付存儲租金。在TON中，智能合約本質上是可升級的，並帶有本機抽象帳戶函數，這意味著TON中的所有錢包位址都是智能合約的，只是未初始化。開發人員需要密切關注這些方面。

免責聲明：

1. 本文轉載自 [Theblockbeats]。所有版權均屬於原作者 [Web3Mario]。如果對此轉載有異議，請聯繫Gate Learn團隊，他們會及時處理。
2. 免責聲明：本文中表達的觀點和意見僅代表作者的觀點和意見，不構成任何投資建議。
3. 文章到其他語言的翻譯由Gate Learn團隊完成。除非另有說明，否則禁止複製、分發或抄襲翻譯后的文章。