Tác giả: @Web3Mario
Mở đầu: Sau khi Binance niêm yết Notcoin – trò chơi lớn nhất trong hệ sinh thái TON – cùng hiệu ứng tài sản khổng lồ từ mô hình token lưu thông hoàn toàn, TON nhanh chóng thu hút được sự chú ý mạnh mẽ. Qua trao đổi với bạn bè, tôi nhận ra rằng rào cản kỹ thuật của TON khá cao và mô hình phát triển DApp có nhiều điểm khác biệt so với các giao thức blockchain phổ biến. Vì vậy, tôi đã dành thời gian nghiên cứu sâu về chủ đề này và xin chia sẻ một số quan sát. Tóm lại, triết lý thiết kế cốt lõi của TON là tái cấu trúc giao thức blockchain truyền thống theo cách "từ dưới lên", đánh đổi khả năng tương tác để đạt được hiệu suất xử lý cao và khả năng mở rộng cực đại.
Triết lý thiết kế cốt lõi của TON – Hiệu suất cao và khả năng mở rộng cực đại
Có thể nói rằng mọi lựa chọn kỹ thuật phức tạp trong TON đều hướng tới mục tiêu đạt được hiệu suất cao và khả năng mở rộng tối đa. Từ bối cảnh ra đời của TON, điều này cũng dễ hiểu. TON (The Open Network) là một mạng lưới tính toán phi tập trung, bao gồm một blockchain lớp 1 (L1) và nhiều thành phần khác. TON ban đầu do Nikolai Durov – người đồng sáng lập Telegram – cùng đội ngũ của ông phát triển, và hiện tại được duy trì bởi cộng đồng các nhà đóng góp độc lập trên toàn cầu. Dự án bắt nguồn từ năm 2017, khi nhóm Telegram bắt đầu tìm kiếm giải pháp blockchain riêng. Do không có blockchain L1 nào hiện hữu lúc đó có thể hỗ trợ cơ sở hàng trăm triệu người dùng của Telegram, họ quyết định tự xây dựng nền tảng riêng, ban đầu gọi là Telegram Open Network. Đến năm 2018, để huy động nguồn lực triển khai TON, Telegram đã bán token Gram (sau đổi tên thành Toncoin) vào quý I năm đó. Năm 2020, do vướng phải vấn đề pháp lý, nhóm Telegram rút lui khỏi dự án. Sau đó, một nhóm nhỏ các nhà phát triển mã nguồn mở và những người chiến thắng cuộc thi Telegram đã tiếp quản kho mã nguồn của TON, đổi tên dự án thành The Open Network và tiếp tục phát triển tích cực cho đến nay, tuân thủ các nguyên tắc đã nêu trong whitepaper gốc.
Vì mục tiêu thiết kế là trở thành môi trường thực thi phi tập trung cho Telegram, nên TON cần giải quyết hai thách thức rõ ràng: lượng yêu cầu đồng thời cực lớn và khối lượng dữ liệu khổng lồ. Chúng ta biết rằng ngay cả Solana – blockchain tuyên bố có TPS cao nhất – cũng chỉ đạt mức tối đa khoảng 65.000 TPS trong thử nghiệm thực tế, điều này rõ ràng là không đủ để đáp ứng yêu cầu về hàng triệu TPS như hệ sinh thái Telegram. Đồng thời, với quy mô sử dụng khổng lồ của Telegram, lượng dữ liệu tạo ra đã vượt xa giới hạn, và vì blockchain là một hệ thống phân tán cực kỳ dư thừa, việc yêu cầu mỗi nút trong mạng lưu trữ toàn bộ dữ liệu là điều không thực tế.
Để giải quyết hai vấn đề trên, TON đã tối ưu hóa giao thức blockchain phổ thông ở hai khía cạnh chính:
-
Áp dụng "Mô hình phân mảnh vô hạn" (Infinite Sharding Paradigm) nhằm giải quyết vấn đề dư thừa dữ liệu, giúp xử lý khối lượng lớn dữ liệu và giảm thiểu nghẽn cổ chai hiệu suất;
-
Giới thiệu môi trường thực thi song song hoàn toàn dựa trên mô hình Actor, nâng cao đáng kể TPS của mạng lưới;
Xây dựng chuỗi cho blockchain – Mỗi tài khoản có một chuỗi tài khoản riêng nhờ khả năng phân mảnh vô hạn
Hiện nay, phân mảnh (sharding) đã trở thành giải pháp phổ biến để tăng hiệu suất và giảm chi phí cho hầu hết các giao thức blockchain. TON đưa điều này lên mức cực đoan bằng cách đề xuất "Mô hình phân mảnh vô hạn" – tức là cho phép blockchain tự động tăng hoặc giảm số lượng phân mảnh tùy theo tải mạng. Mô hình này giúp TON duy trì hiệu suất cao trong khi xử lý lượng lớn giao dịch và hợp đồng thông minh, về lý thuyết có thể tạo một chuỗi tài khoản riêng biệt cho từng tài khoản, đồng thời đảm bảo tính nhất quán giữa các chuỗi này thông qua các quy tắc nhất định.
Trừu tượng hóa hơn, trong TON tồn tại bốn lớp cấu trúc chuỗi:
-
Chuỗi tài khoản (AccountChain): Lớp này biểu thị chuỗi các giao dịch liên quan đến một tài khoản cụ thể. Giao dịch có thể tạo thành cấu trúc chuỗi vì đối với một máy trạng thái, nếu quy tắc thực thi giống nhau thì kết quả sẽ giống nhau khi nhận được các lệnh theo cùng một thứ tự. Do đó, mọi hệ thống blockchain phân tán đều cần sắp xếp giao dịch theo chuỗi, TON cũng không ngoại lệ. AccountChain là đơn vị cấu thành cơ bản nhất trong mạng TON, thường là một khái niệm ảo chứ không tồn tại vật lý như một chuỗi độc lập.
-
Chuỗi phân mảnh (ShardChain): Trong hầu hết ngữ cảnh, ShardChain mới là đơn vị thực tế cấu thành TON – tức là một tập hợp các AccountChain.
-
Chuỗi làm việc (WorkChain): Cũng có thể hiểu là một nhóm ShardChain với quy tắc tùy chỉnh. Ví dụ: tạo một WorkChain dựa trên EVM để chạy các hợp đồng thông minh Solidity. Về lý thuyết, bất kỳ ai trong cộng đồng cũng có thể tạo WorkChain riêng. Tuy nhiên, việc xây dựng nó là một nhiệm vụ khá phức tạp, đòi hỏi chi phí cao để khởi tạo và cần nhận được sự chấp thuận từ ít nhất 2/3 số trình xác thực.
-
Chuỗi chính (MasterChain): Cuối cùng, TON có một chuỗi đặc biệt gọi là MasterChain, chịu trách nhiệm mang lại tính dứt khoát (finality) cho tất cả các ShardChain. Khi hash khối của một ShardChain được gộp vào khối của MasterChain, khối ShardChain đó và tất cả các khối cha của nó được coi là đã đạt tính dứt khoát – nghĩa là nội dung cố định và bất biến, có thể được các khối ShardChain sau đó tham chiếu.
Việc áp dụng mô hình này trao cho mạng TON ba đặc điểm nổi bật:
-
Phân mảnh động: TON có thể tự động tách hoặc gộp ShardChain để thích nghi với sự thay đổi tải. Điều này đảm bảo khối mới luôn được tạo nhanh chóng mà không gây độ trễ dài cho giao dịch.
-
Khả năng mở rộng rất cao: Nhờ mô hình phân mảnh vô hạn, TON có thể hỗ trợ gần như vô hạn số lượng phân mảnh, lý thuyết có thể đạt tới 2^60 WorkChain.
-
Tính thích nghi: Khi tải ở một phần mạng tăng lên, phần đó có thể được chia nhỏ thành nhiều phân mảnh hơn để xử lý lượng giao dịch tăng. Ngược lại, khi tải giảm, các phân mảnh có thể được gộp lại để tăng hiệu quả.
Với một hệ thống đa chuỗi như vậy, vấn đề đầu tiên phải đối mặt là giao tiếp giữa các chuỗi, đặc biệt khi khả năng phân mảnh vô hạn khiến số lượng phân mảnh tăng đến mức lớn, việc định tuyến thông tin giữa các chuỗi sẽ trở nên khó khăn. Hãy tưởng tượng một mạng có 4 nút, mỗi nút phụ trách duy trì một WorkChain độc lập. Mối liên kết biểu thị rằng ngoài việc sắp xếp giao dịch trong WorkChain của mình, nút còn phải lắng nghe và xử lý thay đổi trạng thái từ chuỗi mục tiêu – trong TON, điều này được thực hiện cụ thể bằng cách theo dõi hàng đợi tin nhắn đầu ra.
Giả sử tài khoản A trên WorkChain 1 muốn gửi tin nhắn đến tài khoản C trên WorkChain 3. Khi đó, cần giải quyết bài toán định tuyến. Trong ví dụ này, có hai lộ trình: WorkChain 1 -> WorkChain 2 -> WorkChain 3 và WorkChain 1 -> WorkChain 4 -> WorkChain 3.
Khi tình huống phức tạp hơn, cần một thuật toán định tuyến hiệu quả và tiết kiệm chi phí để hoàn thành nhanh chóng việc truyền tin. TON lựa chọn "thuật toán định tuyến siêu khối lập phương" (hypercube routing algorithm) để giải quyết việc phát hiện lộ trình truyền tin liên chuỗi. Cấu trúc siêu khối lập phương là một dạng tô-pô mạng đặc biệt: một siêu khối lập phương n chiều gồm 2^n đỉnh, mỗi đỉnh được định danh duy nhất bằng một số nhị phân n bit. Trong cấu trúc này, hai đỉnh kề nhau nếu biểu diễn nhị phân của chúng chỉ khác nhau đúng một bit. Ví dụ, trong siêu khối lập phương 3 chiều, đỉnh 000 và 001 kề nhau vì chúng chỉ khác nhau ở bit cuối. Ví dụ trên chính là một siêu khối lập phương 2 chiều.
Trong giao thức định tuyến siêu khối lập phương, quá trình định tuyến tin nhắn từ WorkChain nguồn đến WorkChain đích được thực hiện bằng cách so sánh biểu diễn nhị phân của địa chỉ hai WorkChain. Thuật toán sẽ tìm khoảng cách nhỏ nhất giữa hai địa chỉ (số bit khác nhau), rồi chuyển tiếp dần qua các WorkChain kề nhau cho đến khi đến đích. Cách này đảm bảo dữ liệu đi theo đường đi ngắn nhất, nâng cao hiệu quả truyền thông trong mạng.
Tất nhiên, để đơn giản hóa quá trình, TON cũng đề xuất một giải pháp tối ưu: nếu người dùng cung cấp được bằng chứng hợp lệ cho một lộ trình định tuyến (thường là một gốc Merkle trie), nút có thể công nhận ngay tính tin cậy của tin nhắn do người dùng gửi – còn gọi là định tuyến siêu khối lập phương tức thì.
Do đó, ta thấy địa chỉ trong TON 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 phổ biến sử dụng hàm băm của khóa công khai (từ thuật toán mã hóa đường cong elliptic) làm địa chỉ, vì địa chỉ chỉ cần đảm bảo tính duy nhất, không cần chức năng định tuyến. Trong khi đó, địa chỉ TON gồm hai phần: (workchain_id, account_id), trong đó workchain_id được mã hóa theo thuật toán định tuyến siêu khối lập phương – chi tiết này sẽ không trình bày sâu ở đây.
Một điểm dễ gây thắc mắc: bạn có thể nhận thấy MasterChain nối với mọi WorkChain, vậy sao không dùng MasterChain làm trung gian cho mọi thông tin liên chuỗi – giống như Cosmos? Theo triết lý thiết kế TON, MasterChain chỉ xử lý nhiệm vụ then chốt nhất: duy trì tính dứt khoát cho các WorkChain. Việc định tuyến tin nhắn qua MasterChain cũng có thể thực hiện, nhưng sẽ tốn phí rất cao.
Cuối cùng, xin nhắc sơ qua cơ chế đồng thuận: TON sử dụng kết hợp BFT+PoS, nghĩa là bất kỳ staker nào cũng có cơ hội tham gia đóng gói khối. Hợp đồng bầu cử quản trị của TON sẽ định kỳ chọn ngẫu nhiên một nhóm trình xác thực từ toàn bộ Staker. Các nút được chọn sẽ dùng thuật toán BFT để đóng gói khối; nếu đưa thông tin sai hoặc hành vi ác ý, token stake sẽ bị phạt cháy, ngược lại sẽ nhận thưởng đóng gói khối. Đây là lựa chọn khá phổ biến hiện nay nên sẽ không trình bày sâu thêm.
Hợp đồng thông minh dựa trên mô hình Actor và môi trường thực thi song song hoàn toàn
Một điểm khác biệt nữa của TON so với các giao thức blockchain phổ biến là môi trường thực thi hợp đồng thông minh. Để vượt qua giới hạn TPS của các giao thức blockchain truyền thống, TON áp dụng tư duy thiết kế "từ dưới lên", dùng mô hình Actor để tái cấu trúc hợp đồng thông minh và cách thực thi, từ đó đạt được khả năng thực thi song song hoàn toàn.
Chúng ta biết rằng hầu hết các giao thức blockchain phổ biến đều dùng môi trường thực thi tuần tự đơn luồng. Lấy Ethereum làm ví dụ, môi trường thực thi EVM là một máy trạng thái nhận giao dịch làm đầu vào. Khi nút đóng gói khối hoàn tất việc sắp xếp giao dịch, các giao dịch sẽ được thực thi theo đúng thứ tự đó trong EVM – toàn bộ quá trình hoàn toàn tuần tự và đơn luồng, nghĩa là tại một thời điểm chỉ có một giao dịch được thực thi. Cách này đảm bảo rằng miễn là thứ tự giao dịch được xác định, kết quả thực thi sẽ nhất quán trong một cụm phân tán rộng lớn. Đồng thời, vì chỉ có một giao dịch được thực thi tại một thời điểm, nên không thể có giao dịch khác sửa đổi dữ liệu trạng thái đang chờ truy cập, từ đó đảm bảo tính tương tác giữa các hợp đồng thông minh. Ví dụ, khi dùng Uniswap để mua ETH bằng USDT, tại thời điểm giao dịch được thực thi, phân bố LP trong cặp giao dịch là một giá trị xác định, nhờ đó có thể dùng các mô hình toán học để tính ra kết quả tương ứng. Nhưng nếu không phải như vậy – giả sử trong khi đang tính toán bonding curve, có LP khác bổ sung thanh khoản mới, thì kết quả tính toán sẽ lỗi thời, điều này rõ ràng là không thể chấp nhận.
Tuy nhiên, kiến trúc này cũng có hạn chế rõ ràng: đó là nút thắt TPS, và nút thắt này ngày càng lỗi thời trong bối cảnh bộ xử lý đa nhân hiện đại – giống như dùng một PC mới nhất để chơi các game cũ như Red Alert, khi số lượng đơn vị chiến đấu vượt ngưỡng nhất định sẽ vẫn bị giật – đó chính là vấn đề kiến trúc phần mềm.
Bạn có thể nghe nói rằng một số giao thức đã bắt đầu quan tâm đến vấn đề này và đề xuất giải pháp song song riêng. Chẳng hạn, Solana – hiện được mệnh danh là blockchain 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 Solana khác với TON. Trong Solana, tư tưởng cốt lõi là chia tất cả giao dịch thành các nhóm dựa trên phụ thuộc thực thi, các nhóm khác nhau không chia sẻ bất kỳ dữ liệu trạng thái nào – tức là không có phụ thuộc chung, nhờ đó các giao dịch trong các nhóm khác nhau có thể thực thi song song mà không lo xung đột. Còn trong cùng một nhóm, giao dịch vẫn được thực thi tuần tự theo cách truyền thống.
Trong khi đó, TON hoàn toàn loại bỏ kiến trúc thực thi tuần tự, thay vào đó dùng một khuôn mẫu phát triển chuyên biệt cho song song – mô hình Actor – để tái cấu trúc môi trường thực thi. Mô hình Actor lần đầu được Carl Hewitt đề xuất năm 1973, nhằm giải quyết sự phức tạp do chia sẻ trạng thái trong chương trình đồng thời truyền thống bằng cách truyền tin nhắn. Mỗi Actor có trạng thái riêng và hành vi riêng, không chia sẻ bất kỳ thông tin trạng thái nào với Actor khác. Mô hình Actor là một mô hình tính toán đồng thời, thực hiện tính toán song song thông qua truyền tin nhắn. Trong mô hình này, "Actor" là đơn vị công việc cơ bản, có khả năng xử lý tin nhắn nhận được, tạo Actor mới, gửi thêm tin nhắn, và quyết định cách phản hồi các tin nhắn tiếp theo. Mô hình Actor cần có các đặc điểm sau:
-
Đóng gói và tính độc lập: Mỗi Actor hoàn toàn độc lập khi xử lý tin nhắn, có thể xử lý song song mà không ảnh hưởng lẫn nhau.
-
Truyền tin nhắn: Các Actor chỉ tương tác bằng cách gửi và nhận tin nhắn, việc truyền tin nhắn là bất đồng bộ.
-
Cấu trúc động: Actor có thể tạo thêm Actor mới trong lúc chạy, tính linh hoạt này giúp 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, nghĩa là trong TON, mỗi hợp đồng thông minh là một Actor, có không gian lưu trữ hoàn toàn độc lập, không phụ thuộc vào bất kỳ dữ liệu bên ngoài nào. Ngoài ra, các lời gọi đến cùng một hợp đồng thông minh vẫn được thực thi theo thứ tự tin nhắn trong hàng đợi nhận. Do đó, giao dịch trong TON có thể được thực thi hiệu quả theo cách song song mà không lo xung đột.
Tuy nhiên, thiết kế này cũng mang lại những ảnh hưởng mới, buộc nhà phát triển DApp phải thay đổi thói quen lập trình, cụ thể như sau:
1. Gọi bất đồng bộ giữa các hợp đồng thông minh: Trong TON, không thể gọi nguyên tử đến hợp đồng bên ngoài hay truy cập dữ liệu của hợp đồng bên ngoài. Chúng ta biết rằng 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 qua hàm chỉ đọc function3 của hợp đồng C – toàn bộ quá trình là nguyên tử và được thực thi trong một giao dịch – điều này rất dễ dàng. Tuy nhiên trong TON, điều này là không thể: mọi tương tác với hợp đồng thông minh bên ngoài đều phải được đóng gói thành giao dịch mới và thực thi bất đồng bộ. Loại giao dịch do hợp đồng khởi tạo này còn gọi là tin nhắn nội bộ (internal message), và quá trình thực thi không thể bị chặn để lấy kết quả.
Ví dụ, nếu ta phát triển một DEX, theo khuôn mẫu phổ biến trên EVM, thường sẽ có một hợp đồng router dùng để quản lý định tuyến giao dịch, trong khi mỗi Pool riêng biệt quản lý dữ liệu LP cho cặp giao dịch tương ứng. Giả sử hiện có hai pool: USDT-DAI và DAI-ETH. Khi người dùng muốn mua ETH trực tiếp bằng USDT, có thể dùng hợp đồng router để yêu cầu tuần tự hai pool trong một giao dịch, hoàn tất giao dịch nguyên tử. Tuy nhiên trong TON, điều này không dễ thực hiện như vậy, cần suy nghĩ lại khuôn mẫu phát triển. Nếu vẫn dùng khuôn mẫu cũ, luồng thông tin có thể như sau: yêu cầu này sẽ đi kèm một external message do người dùng khởi tạo và ba internal message (lưu ý: đây chỉ để minh họa sự khác biệt, trong phát triển thực tế thậm chí khuôn mẫu ERC20 cũng cần thiết kế lại).
2. Cần cân nhắc kỹ quy trình xử lý lỗi khi gọi giữa các hợp đồng, thiết kế hàm trả lại (bounce) phù hợp cho từng lời gọi hợp đồng. Chúng ta biết rằng trong EVM phổ biến, khi thực thi giao dịch gặp lỗi, toàn bộ giao dịch sẽ bị hoàn tác (rollback), tức là hệ thống trở lại trạng thái ban đầu – điều này dễ hiểu trong mô hình tuần tự đơn luồng. Tuy nhiên trong TON, do việc gọi giữa các hợp đồng được thực hiện bất đồng bộ, ngay cả khi khâu sau xảy ra lỗi, các giao dịch trước đó đã được thực thi thành công và xác nhận, điều này 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 trả lại (bounce message): khi quá trình thực thi hậu quả do một internal message kích hoạt gặp lỗi, hợp đồng bị gọi có thể kích hoạt hàm bounce được dự trữ sẵn trong hợp đồng gọi để thiết lập lại một số trạng thái trong hợp đồng gọi.
3. Trong một số trường hợp phức tạp, giao dịch được nhận trước chưa chắc thực thi xong trước, do đó không thể mặc định mối quan hệ thứ tự như vậy. Trong hệ thống gọi hợp đồng thông minh bất đồng bộ và song song như vậy, việc định nghĩa thứ tự thao tác có thể rất khó. Vì vậy, mỗi tin nhắn trong TON đều có thời gian logic riêng – Lamport time (gọi tắt là lt). Nó dùng để xác định sự kiện nào gây ra sự kiện khác và trình xác thực cần xử lý gì trước. Với mô hình đơn giản, giao dịch nhận trước chắc chắn thực thi xong trước.
Trong mô hình này, A và B biểu thị hai hợp đồng thông minh, nếu msg1_lt < msg2_lt thì tx1_lt < tx2_lt.
Tuy nhiên trong trường hợp phức tạp hơn, quy tắc này có thể bị phá vỡ. Tài liệu chính thức đưa ra ví dụ: giả sử có ba hợp đồng A, B, C. Trong một giao dịch, A gửi hai tin nhắn nội bộ msg1 và msg2: một đến B, một đến C. Mặc dù chúng được tạo theo thứ tự chính xác (trước là msg1, sau là msg2), ta không thể đảm bảo msg1 sẽ được xử lý trước msg2. Bởi vì đường đi từ A đến B và từ A đến C có thể khác nhau về độ dài và tập hợp trình xác thực. Nếu các hợp đồng nằm trên các ShardChain khác nhau, một tin nhắn có thể mất vài khối mới đến được hợp đồng đích. Nghĩa là có hai lộ trình giao dịch khả dĩ, như hình vẽ.
4. Trong TON, việc lưu trữ bền vững của hợp đồng thông minh sử dụng một đồ thị có hướng không chu trình (DAG) với đơn vị là Cell. Dữ liệu sẽ được nén chặt theo quy tắc mã hóa thành một Cell, sau đó mở rộng xuống dưới theo cấu trúc DAG – khác với cách tổ chức dữ liệu trạng thái dựa trên hashmap trong EVM. Do thuật toán truy vấn dữ liệu khác nhau, TON đặt giá Gas khác nhau cho dữ liệu ở các độ sâu khác nhau: Cell càng sâu thì xử lý càng tốn Gas. Do đó, trong TON tồn tại kiểu tấn công DOS: người dùng ác ý có thể gửi lượng lớn tin nhắn rác chiếm toàn bộ Cell tầng nông trong một hợp đồng thông minh, khiến chi phí lưu trữ của người dùng trung thực ngày càng tăng. Trong EVM, do độ phức tạp truy vấn hashmap là O(1), Gas là như nhau, nên không có vấn đề tương tự. Vì vậy, nhà phát triển DApp trên TON nên tránh tối đa kiểu dữ liệu không giới hạn trong hợp đồng. Khi gặp kiểu dữ liệu không giới hạn, cần phân mảnh (shard) để phân tán dữ liệu.
5. Một số đặc điểm khác ít đặc biệt hơn: hợp đồng thông minh cần trả phí thuê lưu trữ, hợp đồng thông minh trên TON vốn dĩ có thể nâng cấp, và có chức năng tài khoản trừu tượng (AA) bản địa – tức là mọi địa chỉ ví trên TON đều là hợp đồng thông minh, chỉ là chưa được khởi tạo, những điểm này nhà phát triển cần lưu ý cẩn thận.
Trên đây là một số cảm nhận cá nhân sau thời gian tìm hiểu công nghệ TON, xin chia sẻ cùng mọi người. Nếu có chỗ nào sai sót, mong được chỉ giáo. Đồng thời, tôi tin rằng với lượng truy cập khổng lồ từ Telegram, hệ sinh thái TON chắc chắn sẽ mang lại những ứng dụng hoàn toàn mới cho Web3. Những ai quan tâm đến phát triển DApp trên TON có thể liên hệ tôi để cùng thảo luận.
@web3_mario
