引言：随着币安（Binance）上线TON生态中最大的游戏Notcoin，以及由全流通代币经济模型所引发的巨额财富效应，TON在短时间内便获得了极大的关注。在与朋友讨论后了解到，TON的技术门槛相对较高，并且其DApp开发范式与主流公链协议存在较大差异，因此我花费了一些时间深入研究了相关课题，并有一些心得体会，在此与大家分享。简而言之，TON的核心设计理念是以一种“自下而上”的方式重构传统的区块链协议，并以牺牲互操作性为代价，实现对高并发性和高可扩展性的极致追求。
TON的核心设计思想——高并发性与高可扩展性
可以说，TON中所有复杂的技术选择都是为了追求高并发性和高可扩展性。从其诞生背景来看，这一点不难理解。TON，即The Open Network，是一个去中心化的计算网络，包括一个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白皮书中概述的原则。
Vì vậy, khi thiết kế với mục tiêu là môi trường thực thi phi tập trung cho Telegram, tự nhiên phải đối mặt với hai vấn đề: yêu cầu đồng thời cao và dữ liệu hàng loạt. Chúng ta đều biết, cùng với sự phát triển của công nghệ đến nay, Solana, được cho là có TPS (Transaction Per Second) cao nhất, chỉ đạt được TPS tối đa là 65000, điều này rõ ràng không đủ để hỗ trợ hệ sinh thái Telegram yêu cầu hàng triệu TPS. Đồng thời, với việc sử dụng rộng rãi của Telegram, lượng dữ liệu được tạo ra đã vượt quá giới hạn, và với blockchain là một hệ thống phân tán có độ dư thừa cực cao, yêu cầu mỗi nút trong mạng lưu trữ một bản sao hoàn chỉnh của dữ liệu cũng không thực tế.
Do đó, để giải quyết hai vấn đề trên, TON đã thực hiện hai方面的优化 (bạn cần dịch đoạn này sang tiếng Việt) của giao thức blockchain chính lưu hành:
l Thông qua việc áp dụng thiết kế “Lý thuyết phân mảnh vô hạn” (Infinite Sharding Paradigm) cho hệ thống, giải quyết vấn đề dư thừa dữ liệu, cho phép nó có thể chở載dữ liệu lớn, đồng thời giảm bớt vấn đề ngòi ép hiệu suất;
l Thông qua việc giới thiệu môi trường thực thi hoàn toàn song song dựa trên mô hình Actor, nâng cao đáng kể TPS của mạng;
Làm blockchain của blockchain – Thông qua khả năng phân mảnh vô hạn để mỗi tài khoản đều có một chuỗi tài khoản riêng biệt
Hiện tại chúng ta biết, phân mảnh (sharding) đã trở thành giải pháp chính để nâng cao hiệu suất và giảm chi phí của hầu hết các giao thức blockchain, và TON đã phát triển điểm này đến cực hạn, và đã đề xuất ra Lý thuyết phân mảnh vô hạn, Lý thuyết phân mảnh vô hạn được hiểu là cho phép blockchain động態地 tăng hoặc giảm số lượng phân mảnh dựa trên tải mạng. Phương pháp này cho phép TON xử lý các giao dịch và thao tác hợp đồng thông minh trên quy mô lớn trong khi duy trì hiệu suất cao, lý thuyết TON có thể thiết lập một chuỗi tài khoản riêng biệt cho mỗi tài khoản, và bằng một số quy tắc đảm bảo sự nhất quán giữa những chuỗi này.
Hiểu một cách trừu tượng, trong TON có tổng cộng bốn lớp cấu trúc chuỗi:
账户链（AccountChain）：该层链表示与某个账户相关的一系列交易所组成的链，之所以交易可以组成链式结构，是因为对于一个状态机来说，只要执行规则一致，状态机在接收到相同顺序的指令后得到的结果是一致的，因此所有区块链分布式系统中都需要对交易进行链式排序，TON 也不例外。账户链是 TON 网络中最基本的组成单元，通常情况下账户链是一个虚拟的概念，不太可能真正存在一个独立的账户链。
分片链（ShardChain）：在大部分的语境下，分片链才是 TON 中实际的组成单元，所谓分片链，即为一组账户链的集合。
工作链（WorkChain）：也可以叫做一组有自定义规则的分片链，例如创建一个基于 EVM 的工作链，在其上运行 Solidity 智能合约。理论上，社区中的每个人都可以创建自己的工作链。事实上，构建它是一个相当复杂的任务，在此之前还要支付创建它的（昂贵）费用，并获得验证者的 2/3 的票数来批准创建你的工作链。
主链（MasterChain）：最后在 TON 中有一条特殊的链被称为主链，该链负责为所有分片链带来最终性。一旦分片链的区块的哈希值被合并到主链的区块中，该分片链区块及其所有父区块被认为具有最终性，这意味着它们可以被认为是固定且不可变的内容，而被所有分片链的后续区块引用。
通过采用这样的范式，使 TON 网络具备以下三个特点：
动态分片：TON 可以自动拆分和合并分片链以适应负载的变化。这意味着新块总是快速生成，而交易不会产生很长的等待时间。
高度可扩展：通过无限分片范式，TON 能够支持几乎无限数量的分片，理论上可以达到 2 的 60 次方个工作链。
自适应性：当网络中的某个部分负载增加时，该部分可以被细分成更多的分片来处理增加的交易量。相反，当负载减少时，分片可以合并以提高效率。
那么这样一个多链系统，首先需要面临的就是跨链通信问题，尤其是由于具有无限分片的能力，当网络中的分片数量达到一定量级后，链与链之间的信息路由将成为一件困难的事情。试想一下网络中共有 4 个节点，每个节点负责维护 1 条独立的工作链，其中链接关系表示该节点除了负责自身的工作链中交易排序工作之外，还需要监听并处理目标链中状态变化，在 TON 中具体通过监听输出队列的消息实现。
假设工作链 1 中的账户 A 希望向工作链 3 中的账户 C 发送一个消息。则需要设计到消息路由问题，在这个例子中有两条路由路径，工作链 1 -> 工作链 2-> 工作链 3，工作链 1 -> 工作链 4 -> 工作链 3。
当面临更复杂的情况时，就需要一个高效且低成本的路由算法快速完成消息通信，TON 选择了所谓「超立方体路由算法」来实现跨链消息通信路由发现。所谓超立方体结构指的是一种特殊的网络拓扑结构，一个 n 维超立方体是由 2^n 个顶点组成的，每个顶点都可以通过一个 n 位的二进制数来唯一标识。在这个结构中，任意两个顶点如果在二进制表示中只有一位不同，那么它们就是相邻的。例如，在一个 3 维超立方体中，顶点 000 和顶点 001 是相邻的，因为它们只在最后一位上不同。而上述例子即是一个 2 维超立方体。
Trong giao thức định tuyến siêu lập thể, thông điệp sẽ được định tuyến từ chuỗi làm việc nguồn đến chuỗi làm việc đích bằng cách so sánh biểu diễn nhị phân của địa chỉ chuỗi làm việc nguồn và đích. Thuật toán định tuyến sẽ tìm ra khoảng cách nhỏ nhất giữa hai địa chỉ này (tức số lượng các vị khác nhau trong biểu diễn nhị phân) và chuyển tiếp thông điệp qua các chuỗi làm việc liên tiếp, cho đến khi đạt được chuỗi làm việc đích. Phương pháp này đảm bảo rằng gói dữ liệu được truyền tải dọc theo đường dẫn ngắn nhất, từ đó nâng cao hiệu quả truyền thông của mạng.
Tất nhiên, để đơn giản hóa quá trình này, TON cũng đã đề xuất một giải pháp kỹ thuật lạc quan, khi người dùng có thể cung cấp một bằng chứng hiệu quả cho một đường dẫn định tuyến nhất định, thường là một gốc cây Merkle trie, nút sẽ trực tiếp thừa nhận tính đáng tin cậy của thông điệp được người dùng gửi, đây cũng được gọi là định tuyến siêu lập thể ngay lập tức.
Do đó, chúng ta có thể thấy địa chỉ trong TON có sự khác biệt rõ rệt so với các giao thức blockchain khác, hầu hết các giao thức blockchain chính thống đều sử dụng băm tương ứng với khóa công khai được tạo bởi thuật toán mã hóa eliptické, vì địa chỉ chỉ cần phân biệt duy nhất mà không cần phải chở đường dẫn định tuyến, trong khi địa chỉ trong TON có hai phần, (workchain_id, account_id), trong đó workchain_id được mã hóa theo thuật toán định tuyến siêu lập thể, ở đây sẽ không bàn về chi tiết.
Một điểm khác dễ gây nhầm lẫn, bạn có thể đã nhận thấy rằng chuỗi chính và mỗi chuỗi làm việc đều có mối quan hệ liên kết, vậy tất cả thông tin xuyên chuỗi đều thông qua chuỗi chính làm trung gian không được sao, giống như cosmos. Trong quan niệm thiết kế của TON, chuỗi chính chỉ sử dụng để xử lý nhiệm vụ quan trọng nhất, tức là duy trì tính cuối cùng của nhiều chuỗi làm việc, gửi thông điệp thông qua chuỗi chính cũng không phải là không thể, chỉ là chi phí phí chuyển khoản phát sinh từ đó sẽ rất đắt đỏ.
最后简单提一下其共识算法，TON 采用了 BFT+PoS 的方式，即任意 staker 均有机会参与区块打包，TON 的选举治理合约会每隔一段时间，从所有 Stakers 中随机选择一个打包的验证者集群，被选中称为验证者的节点将通过 BFT 算法打包出块，若打包错误信息或作恶，其 stake 的 token 将会被罚没，反之将得到出块奖励。这基本上已经是一个比较常见的选择了，因此不在这里展开介绍。
基于 Actor 模型的智能合约和完全并行执行环境
TON 中另一个与主流区块链协议不同的点是其智能合约执行环境。为了突破主流区块链协议 TPS 的限制，TON 采用了自下而上的设计思路，采用 Actor 模型重构了智能合约及其执行方式，使其具备了完全并行执行的能力。
我们知道主流的区块链协议大都采用的是单线程串行的执行环境，以 Ethereum 为例，其执行环境 EVM 是一个以交易作为输入的状态机，当出块节点通过打包区块完成对交易的排序后，将以该顺序通过 EVM 执行交易，整个过程是完全串行并单线程的，即某个时刻只能有一笔被执行，这样做的好处是只要确认了交易顺序，执行的结果在广泛的分布式集群中就具有一致性，与此同时由于同时只有一笔交易被串行执行，这就意味着在执行过程中，不可能存在其他交易对某待访问状态数据进行修改，这样就实现了智能合约之间的互操作性。例如我们通过 Uniswap 使用 USDT 购买 ETH，当该交易被执行时，该交易对中 LP 的分布情况即为一个确定值，这样就可以通过某些数学模型得出对应的结果，但假设情况不是这样的，在执行某 bonding curve 的计算时，有其他 LP 添加了新的流动性，那么计算结果将会是一个过时的结果，这显然是不可接受的。
Tuy nhiên, kiến trúc này cũng có những hạn chế rõ ràng, đó là ngưỡng TPS, và ngưỡng này dưới nhiều nhân xử lý hiện đại sẽ thấy lỗi thời, giống như bạn sử dụng một PC mới nhất để chơi một số trò chơi máy tính cũ, ví dụ như Command & Conquer, khi đơn vị chiến đấu đủ nhiều, bạn vẫn会发现卡的不行, đó là vấn đề kiến trúc phần mềm.
Bạn có thể nghe nói một số giao thức đã quan tâm đến vấn đề này và đã đưa ra các giải pháp song song của riêng họ, lấy Solana, hiện được cho là có TPS cao nhất, cũng có khả năng thực thi song song. Tuy nhiên, tư duy thiết kế của nó khác với TON, trong Solana, tư tưởng cốt lõi của nó là phân chia tất cả các giao dịch theo mối quan hệ phụ thuộc thực thi thành một số nhóm, giữa các nhóm không chia sẻ bất kỳ dữ liệu trạng thái nào. Không có sự phụ thuộc giống nhau, do đó các giao dịch trong các nhóm khác nhau có thể thực thi song song mà không cần lo lắng về xung đột, và đối với các giao dịch trong cùng một nhóm, vẫn sử dụng phương pháp tuần tự truyền thống.
Trong TON, nó hoàn toàn từ bỏ kiến trúc thực thi tuần tự, thay vào đó đã áp dụng một mô hình phát triển đặc biệt cho song song, mô hình Actor để tái cấu trúc môi trường thực thi. Nó gọi là mô hình Actor, được Carl Hewitt đề xuất lần đầu tiên vào năm 1973, mục đích是通过消息传递来解决传统并发程序中共享状态的复杂性问题. Mỗi Actor đều có trạng thái riêng và hành động của riêng mình, và không chia sẻ bất kỳ thông tin trạng thái nào với các Actor khác. Mô hình Actor là một mô hình tính toán song song, nó thực hiện tính toán song song thông qua việc truyền tin nhắn. Trong mô hình này, “Actor” là đơn vị công việc cơ bản, nó có thể xử lý tin nhắn nhận được, tạo ra các Actor mới, gửi nhiều tin nhắn hơn, quyết định cách phản ứng tiếp theo với tin nhắn. Mô hình Actor cần phải có một số đặc tính sau:
l Bao bọc và độc lập: Mỗi Actor khi xử lý tin nhắn đều hoàn toàn độc lập, có thể xử lý tin nhắn song song mà không gây ra sự干预lãng nhau.
l Truyền tin nhắn: Các Actor chỉ tương tác với nhau thông qua việc gửi và nhận tin nhắn, truyền tin nhắn là bất đồng bộ.
l Cấu trúc động: Các Actor có thể tạo ra nhiều Actor khi chạy, tính năng động này làm cho mô hình Actor có thể mở rộng hệ thống theo nhu cầu.
TON áp dụng kiến trúc này để thiết kế mô hình hợp đồng thông minh, có nghĩa là trong TON, mỗi hợp đồng thông minh đều là một mô hình Actor, có không gian lưu trữ hoàn toàn độc lập. Vì không phụ thuộc vào bất kỳ dữ liệu bên ngoài nào. Ngoài ra, các cuộc gọi đối với cùng một hợp đồng thông minh được thực hiện theo thứ tự của các thông điệp trong hàng đợi nhận, do đó các giao dịch trong TON sẽ có thể được thực hiện song song hiệu quả, mà không cần lo lắng về vấn đề xung đột.
Tuy nhiên, thiết kế giải pháp này cũng mang lại một số tác động mới, đối với nhà phát triển DApp, cách phát triển quen thuộc của họ sẽ bị phá vỡ, cụ thể như sau:
1. Gọi bất đồng bộ giữa các hợp đồng thông minh: bên trong các hợp đồng thông minh của TON, không thể gọi hoặc truy cập dữ liệu của hợp đồng bên ngoài một cách nguyên tử, chúng ta biết trong Solidity, hàm function1 của hợp đồng A gọi hàm function2 của hợp đồng B, hoặc truy cập dữ liệu trạng thái thông qua hàm chỉ đọc function3 của hợp đồng C, quá trình này là nguyên tử, được thực hiện trong một giao dịch, điều này rất dễ dàng, tuy nhiên trong TON, điều này sẽ không thể thực hiện được, mọi tương tác với hợp đồng thông minh bên ngoài đều sẽ được thực hiện bất đồng bộ thông qua gói mới giao dịch, giao dịch này được phát động bởi hợp đồng thông minh và cũng được gọi là thông điệp nội bộ. Và trong quá trình thực hiện không thể chặn để nhận kết quả thực hiện.
Ví dụ chúng ta phát triển một DEX, nếu áp dụng chuẩn mực thông thường trong EVM, thường sẽ có một hợp đồng router thống nhất để quản lý định tuyến giao dịch, và mỗi Pool đều quản lý riêng LP dữ liệu liên quan đến cặp giao dịch, giả sử hiện tại có hai bể USDT-DAI và DAI-ETH. Khi người dùng muốn mua ETH trực tiếp bằng USDT, có thể thông qua hợp đồng router yêu cầu tuần tự hai bể này, hoàn thành giao dịch nguyên tử. Tuy nhiên trong TON thì không dễ dàng thực hiện như vậy, cần phải suy nghĩ về chuẩn mực phát triển mới, nếu vẫn tiếp tục sử dụng chuẩn mực đó, thì luồng thông tin có thể như sau, yêu cầu này sẽ đi kèm theo một thông điệp bên ngoài do người dùng phát động và ba thông điệp nội bộ để hoàn thành (chú ý đây chỉ là để giải thích sự khác biệt, trong thực tế phát triển thậm chí còn cần thiết thiết kế lại chuẩn mực ERC20).
2. Cần cân nhắc kỹ lưỡng quá trình xử lý lỗi trong khi thực hiện các cuộc gọi giữa các hợp đồng, thiết kế các hàm phản hồi (bounce) tương ứng cho mỗi cuộc gọi giữa các hợp đồng. Chúng ta biết rằng trong EVM chính thống, khi một giao dịch gặp vấn đề khi thực thi, toàn bộ giao dịch sẽ được rollback, tức là được đặt lại về trạng thái ban đầu của nó. Điều này dễ hiểu trong mô hình đơn luồng song song. Tuy nhiên, trong TON, do các cuộc gọi giữa các hợp đồng được thực hiện theo cách bất đồng bộ, ngay cả khi một phần sau gặp lỗi, do các giao dịch trước đó đã được thực thi và xác nhận thành công, có thể gây ra vấn đề. Do đó, TON đã thiết lập một loại tin nhắn đặc biệt, gọi là tin nhắn phản hồi, tức là khi một quá trình thực thi sau khi kích hoạt bởi một tin nhắn nội bộ gặp lỗi, hợp đồng được kích hoạt có thể sử dụng hàm phản hồi được hợp đồng kích hoạt để đặt lại một số trạng thái trong hợp đồng kích hoạt.
3. Trong một số tình huống phức tạp, giao dịch đã nhận được trước không nhất thiết phải được thực hiện xong trước, do đó không thể giả định mối quan hệ thời gian này. Trong một hệ thống gọi hợp đồng thông minh bất đồng bộ và song song như TON, định nghĩa thứ tự xử lý các hoạt động có thể rất khó. Đó là lý do tại sao mỗi tin nhắn trong TON đều có thời gian logic Lamport time (sau này gọi tắt là lt) của nó. Nó được sử dụng để hiểu sự kiện nào kích hoạt sự kiện khác và xác nhận người xác thực cần xử lý gì trước. Đối với một mô hình đơn giản, giao dịch đã nhận được trước sẽ luôn được thực hiện và hoàn thành trước.
Trong mô hình này, A và B lần lượt biểu thị hai hợp đồng thông minh, có quy luật nếu msg1_lt < msg2_lt, thì tx1_lt < tx2_lt mối quan hệ thời gian.
Tuy nhiên, trong những trường hợp phức tạp hơn, quy tắc này sẽ bị phá vỡ. Trong tài liệu chính thức có ví dụ như sau: giả sử chúng ta có ba hợp đồng A, B và C. Trong một giao dịch, A gửi hai thông điệp nội bộ msg1 và msg2: một cho B, và một cho C. Mặc dù chúng được tạo theo thứ tự chính xác (trước msg1, sau đó là msg2), nhưng chúng ta không thể chắc chắn msg1 sẽ được xử lý trước msg2. Điều này xảy ra vì các lộ trình từ A đến B và từ A đến C có thể khác nhau về chiều dài và tập hợp xác thực者. Nếu những hợp đồng này nằm trên các shard chain khác nhau, một thông điệp có thể cần nhiều khối để đến hợp đồng mục tiêu. Tức là chúng ta có hai con đường giao dịch có thể, như được minh hoạ trong hình.
4. Trong TON, lưu trữ vĩnh cửu của hợp đồng thông minh sử dụng một đồ thị vô hướng có hướng với Cell là đơn vị, dữ liệu sẽ được nén chặt chẽ theo quy tắc mã hóa thành một Cell, đồng thời mở rộng theo cách của đồ thị vô hướng có hướng, khác với EVM trong đó dữ liệu trạng thái dựa trên cấu trúc hashmap, do khác biệt của thuật toán yêu cầu dữ liệu, TON đặt giá Gas khác nhau cho xử lý dữ liệu ở các độ sâu khác nhau, dữ liệu Cell ở độ sâu càng sâu cần nhiều Gas hơn, do đó trong TON có một mô hình tấn công DOS, tức là một số người dùng xấu ý bằng cách gửi nhiều thông điệp rác chiếm hết tất cả các Cell lềshallow trong một hợp đồng thông minh, điều này có nghĩa là chi phí lưu trữ của người dùng trung thực sẽ ngày càng tăng. Trong EVM, vì độ phức tạp truy vấn của hashmap là o(1), do đó có Gas giống nhau, không có vấn đề tương tự. Vì vậy, nhà phát triển TON Dapp nên tránh càng nhiều càng tốt các kiểu dữ liệu vô hạn trong hợp đồng thông minh. Khi xuất hiện kiểu dữ liệu vô hạn, nên phân mảnh nó theo cách.
5. Ngoài ra, vẫn còn một số đặc điểm không quá đặc biệt, ví dụ như hợp đồng thông minh cần thanh toán thuê lưu trữ, trong TON hợp đồng thông minh tự nhiên là có khả năng nâng cấp, cũng như tính năng tài khoản trừu tượng gốc, tức là trong TON tất cả địa chỉ ví đều là hợp đồng thông minh, chỉ là chưa được khởi tạo, những điều này cần nhà phát triển cẩn thận lưu ý.
