Từ rủi ro đến bảo vệ: rủi ro bảo mật và đề xuất tối ưu hóa cho hợp đồng thông minh TON

Nguồn: Beosin

Với sự phát triển nhanh chóng của công nghệ blockchain ngày nay, TON (The Open Network), với tư cách là một nền tảng blockchain hiệu quả và linh hoạt, ngày càng nhận được nhiều sự quan tâm của các nhà phát triển. Kiến trúc và tính năng độc đáo của TON cung cấp các công cụ mạnh mẽ và khả năng phong phú để phát triển các ứng dụng phi tập trung.

Tuy nhiên, khi chức năng và độ phức tạp tăng lên, tính bảo mật của hợp đồng thông minh ngày càng trở nên quan trọng. Là ngôn ngữ lập trình hợp đồng thông minh trên TON, FunC được biết đến với tính linh hoạt và hiệu quả nhưng cũng tiềm ẩn nhiều rủi ro và thách thức. Viết hợp đồng thông minh an toàn và đáng tin cậy đòi hỏi các nhà phát triển phải hiểu biết sâu sắc về đặc điểm của ngôn ngữ FunC và những rủi ro có thể xảy ra.

Bài viết này sẽ phân tích chi tiết một số tính năng liên quan đến hợp đồng thông minh trên chuỗi khối TON, cũng như các điểm dễ bị tổn thương dễ bị bỏ qua của hợp đồng thông minh trên TON.

Ton các tính năng không đồng bộ và phân tích cơ chế tài khoản

Cuộc gọi không đồng bộ trong hợp đồng thông minh

Phân chia mạng và giao tiếp không đồng bộ

Blockchain TON được chia thành ba loại chuỗi trong thiết kế: chuỗi chính Chuỗi (Masterchain), chuỗi làm việc (Workingchains) và chuỗi phân đoạn (Shardchains).

Chuỗi chính là cốt lõi của toàn bộ mạng và chịu trách nhiệm lưu trữ siêu dữ liệu và cơ chế đồng thuận của toàn bộ mạng. Nó ghi lại trạng thái của tất cả các chuỗi công việc và chuỗi phân đoạn, đồng thời đảm bảo tính nhất quán và bảo mật của toàn bộ mạng. Chuỗi làm việc là một chuỗi khối độc lập, có tối đa 2^32 khối, chịu trách nhiệm xử lý các loại giao dịch và hợp đồng thông minh cụ thể. Mỗi chuỗi công việc có thể có các quy tắc và đặc điểm riêng để đáp ứng các nhu cầu ứng dụng khác nhau. Chuỗi Sharding là các chuỗi con của chuỗi công việc, được sử dụng để phân chia thêm tải trọng của chuỗi công việc và cải thiện khả năng xử lý cũng như khả năng mở rộng. Mỗi chuỗi công việc có thể được chia thành tối đa 2^60 chuỗi phân đoạn và chuỗi phân đoạn xử lý một số giao dịch một cách độc lập, nhờ đó đạt được khả năng xử lý song song hiệu quả.

Về mặt lý thuyết, mỗi tài khoản có thể chiếm giữ một chuỗi phân đoạn độc quyền, mỗi tài khoản duy trì độc lập số dư COIN/TOKEN của riêng mình và các giao dịch giữa mỗi tài khoản có thể hoàn toàn song song. Các tài khoản được truyền qua các tin nhắn không đồng bộ. Đường dẫn của các tin nhắn được truyền giữa các chuỗi phân đoạn là log_16(N) - 1, trong đó N là số lượng chuỗi phân đoạn.

Nguồn hình ảnh: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574 trong thế giới web3

Ở Ton, hợp đồng thông minh tương tác bằng cách gửi và nhận tin nhắn. Những tin nhắn này có thể là tin nhắn nội bộ (nói chung là tin nhắn được gửi bởi các hợp đồng thông minh tương tác với nhau) hoặc tin nhắn bên ngoài (tin nhắn được gửi từ các nguồn bên ngoài). Quá trình gửi tin nhắn không cần đợi phản hồi ngay lập tức của hợp đồng đích và người gửi có thể tiếp tục thực thi phần còn lại của mã logic. So với các cuộc gọi đồng bộ của Ethereum, cơ chế nhắn tin không đồng bộ này mang lại tính linh hoạt và khả năng mở rộng cao hơn, giảm tắc nghẽn hiệu suất do chờ phản hồi và cũng mang đến những thách thức trong việc xử lý các điều kiện đồng thời và chạy đua.

Định dạng và cấu trúc tin nhắn

Trong Ton, tin nhắn thường bao gồm người gửi, người nhận, số tiền, nội dung tin nhắn và các thông tin khác. Nội dung thư có thể là lệnh gọi hàm, truyền dữ liệu hoặc nội dung tùy chỉnh khác. Định dạng tin nhắn mà Ton sử dụng có thể được xác định và mở rộng một cách linh hoạt, cho phép nhiều loại thông tin khác nhau được truyền tải một cách hiệu quả giữa các hợp đồng khác nhau.

Tin nhắn Xử lý hàng đợi và trạng thái

Mỗi hợp đồng duy trì một hàng đợi tin nhắn để lưu trữ các tin nhắn chưa được xử lý. Trong quá trình thực hiện hợp đồng, nó sẽ được xử lý từng cái một theo các tin nhắn trong hàng đợi. Vì quá trình xử lý tin nhắn không đồng bộ nên trạng thái của hợp đồng không được cập nhật ngay lập tức cho đến khi nhận được tin nhắn.

Ưu điểm của nhắn tin không đồng bộ

Cơ chế phân chia hiệu quả: Cơ chế không đồng bộ của Ton và phân chia của nó Thiết kế hoàn toàn phù hợp . Mỗi phân đoạn xử lý các thông báo hợp đồng và thay đổi trạng thái một cách độc lập, tránh vấn đề chậm trễ do giao tiếp đồng bộ giữa các phân đoạn gây ra. Thiết kế này cải thiện thông lượng và khả năng mở rộng của toàn bộ mạng.

Giảm mức tiêu thụ tài nguyên: Vì các tin nhắn không đồng bộ không yêu cầu phản hồi ngay lập tức nên việc thực hiện hợp đồng của Ton có thể được hoàn thành trong nhiều khối, tránh tiêu thụ quá nhiều tài nguyên trong một khối. Điều này cho phép Ton hỗ trợ các hợp đồng thông minh phức tạp và tốn nhiều tài nguyên hơn.

→Khả năng chịu lỗi và độ tin cậy: Cơ chế gửi tin nhắn không đồng bộ giúp hệ thống có khả năng chịu lỗi cao hơn. Ví dụ: nếu một hợp đồng không thể phản hồi tin nhắn kịp thời do hạn chế về tài nguyên hoặc các lý do khác, thì người gửi vẫn có thể tiếp tục xử lý logic khác và hệ thống sẽ không bị đình trệ do sự chậm trễ của một hợp đồng.

Thách thức của thiết kế hợp đồng không đồng bộ

→Vấn đề về tính nhất quán của trạng thái: Vì việc gửi tin nhắn không đồng bộ nên trạng thái của hợp đồng có thể thay đổi vào những thời điểm khác nhau . Các thông báo khác nhau được nhận, điều này đòi hỏi các nhà phát triển phải đặc biệt chú ý đến các vấn đề về tính nhất quán của trạng thái. Khi thiết kế hợp đồng, phải tính đến những thay đổi trạng thái có thể xảy ra do các chuỗi thông báo khác nhau gây ra để đảm bảo rằng hệ thống duy trì tính nhất quán trong mọi trường hợp.

rent Điều kiện chủng tộc và bảo vệ: Việc xử lý thông báo không đồng bộ mang đến các vấn đề tiềm ẩn về điều kiện chủng tộc và nhiều thông báo có thể cố gắng sửa đổi trạng thái hợp đồng cùng một lúc. Các nhà phát triển cần đưa ra các cơ chế khóa thích hợp hoặc sử dụng các hoạt động giao dịch để ngăn chặn xung đột trạng thái.

→ Các cân nhắc về bảo mật: Hợp đồng không đồng bộ dễ bị tấn công bởi kẻ trung gian hoặc tấn công lặp lại khi xử lý thông tin liên lạc giữa các hợp đồng. Vì vậy, khi thiết kế hợp đồng không đồng bộ, những rủi ro bảo mật tiềm ẩn này phải được xem xét và có biện pháp ngăn chặn chúng xảy ra như sử dụng dấu thời gian, số ngẫu nhiên hoặc đa chữ ký.

Mô hình sổ cái

Ton (Mạng mở) sử dụng một tài khoản duy nhất khi thiết kế các mô hình sổ cái và cơ sở hạ tầng blockchain của mình. Tính linh hoạt của mô hình này được phản ánh qua cách nó xử lý trạng thái tài khoản, nhắn tin và thực hiện hợp đồng.

Tóm tắt tài khoản

Mô hình tài khoản của Ton áp dụng tính năng trừu tượng hóa dựa trên hợp đồng. Mỗi tài khoản có thể được coi là một hợp đồng, tương tự như tài khoản Ethereum. mô hình trừu tượng có một số điểm tương đồng nhưng linh hoạt và tổng quát hơn. Ở Ton, tài khoản không chỉ là nơi chứa tài sản mà còn chứa mã hợp đồng và dữ liệu trạng thái. Mỗi tài khoản bao gồm logic xử lý mã, dữ liệu và tin nhắn.

Cấu trúc tài khoản: Mỗi tài khoản Ton có một địa chỉ duy nhất, là sự kết hợp giữa giá trị băm của mã tài khoản, dữ liệu ban đầu trong quá trình triển khai và một số thông số khác. Điều này có nghĩa là cùng một mã và dữ liệu ban đầu được triển khai trong các môi trường khác nhau (ví dụ: các chuỗi khối hoặc phân đoạn khác nhau) có thể tạo ra các địa chỉ khác nhau.

Tính linh hoạt: Vì mỗi tài khoản có thể chạy mã hợp đồng riêng nên tài khoản của Ton có thể triển khai logic rất phức tạp. Tài khoản không chỉ là chủ sở hữu số dư đơn giản mà còn có thể xử lý các chuyển khoản trạng thái phức tạp, liên lạc bằng tin nhắn giữa các tài khoản và thậm chí cả các hoạt động tự động dựa trên các điều kiện cụ thể. Điều này làm cho mô hình tài khoản của Ton có khả năng mở rộng và linh hoạt hơn so với mô hình trên các chuỗi khối truyền thống.

Cấu trúc sổ cái

Cấu trúc sổ cái của Ton được thiết kế để xử lý hiệu quả các giao dịch đồng thời quy mô lớn và hỗ trợ nhắn tin không đồng bộ cũng như hoạt động trên nhiều phân đoạn. Trạng thái của mỗi tài khoản được lưu trữ trong cấu trúc cây Merkle, cho phép sổ cái của Ton có khả năng xác minh trạng thái hiệu quả.

Bộ nhớ trạng thái

Thông tin trạng thái tài khoản được lưu trữ trong bộ lưu trữ liên tục và được tổ chức thông qua cây Merkle để đảm bảo tính toàn vẹn và bảo mật của trạng thái. Thiết kế này cũng cho phép truy vấn và xác minh trạng thái hiệu quả, đặc biệt là trong các tình huống giao dịch chéo.

Trạng thái tài khoản hoặc hợp đồng thông minh thường chứa các nội dung sau:

1. Số dư của loại tiền cơ bản

2. Số dư của các loại tiền tệ khác

3. Mã hợp đồng thông minh (hoặc hàm băm của nó)

4. Dữ liệu liên tục của hợp đồng thông minh (hoặc hàm băm Merkle của nó)

5. đơn vị lưu trữ liên tục Thống kê số byte thô

6 Thời gian thanh toán gần đây nhất được duy trì bởi hợp đồng thông minh (thực tế là số khối chuỗi chính)

7. gửi từ tài khoản này Khóa chung cần thiết cho tin nhắn (tùy chọn; mặc định là account_id). Trong một số trường hợp, tương tự như những gì được thực hiện với đầu ra giao dịch Bitcoin, bạn có thể tìm thấy mã kiểm tra chữ ký phức tạp hơn ở đây; account_id khi đó sẽ bằng hàm băm của mã này.

Không phải mọi thông tin đều bắt buộc đối với mọi tài khoản. Ví dụ: mã hợp đồng thông minh chỉ hoạt động với hợp đồng thông minh chứ không hoạt động với các tài khoản "đơn giản". Ngoài ra, mặc dù bất kỳ tài khoản nào cũng phải có số dư bằng tiền tệ chính (ví dụ: chuỗi chính cho chuỗi hoạt động cơ bản và Gram cho chuỗi phân đoạn), các loại tiền tệ khác có thể có số dư bằng 0. Để tránh giữ lại dữ liệu không sử dụng, loại sản phẩm tổng được xác định trong quá trình tạo chuỗi công việc, sử dụng các byte đánh dấu khác nhau để phân biệt các "hàm tạo" khác nhau. Cuối cùng, trạng thái tài khoản sẽ được lưu dưới dạng tập hợp các ô để lưu trữ lâu dài TVM.

Chuyển và xử lý tin nhắn

Cấu trúc sổ cái của Ton có hỗ trợ tích hợp cho tính năng nhắn tin không đồng bộ. Mỗi tài khoản có thể xử lý tin nhắn đã nhận và cập nhật trạng thái một cách độc lập. Cơ chế nhắn tin không đồng bộ này cho phép các tương tác phức tạp giữa các tài khoản mà không ảnh hưởng đến hoạt động bình thường của các tài khoản khác do sự chậm trễ trong một thao tác.

Mô hình Gas

Blockchain Ton (Mạng mở) tối ưu hóa đáng kể hiệu quả thực thi của các hợp đồng thông minh thông qua mô hình phí Gas độc đáo. Mô hình phí gas được sử dụng trong blockchain để đo lường và hạn chế các tài nguyên tiêu thụ trong quá trình thực hiện hợp đồng thông minh. So với mô hình Gas của các chuỗi khối truyền thống (chẳng hạn như Ethereum), thiết kế mô hình của Ton phức tạp và hiệu quả hơn, đồng thời có thể quản lý mức tiêu thụ tài nguyên chính xác hơn trong quá trình thực hiện hợp đồng.

Đo lường mức tiêu thụ khí tinh chế

Mô hình Ton's Gas có thể đo lường chính xác tài nguyên máy tính, hoạt động lưu trữ và chi phí gửi tin nhắn mà hợp đồng thông minh tiêu thụ trong quá trình thực thi. Thông qua việc đo lường chi tiết các tài nguyên như điện toán, lưu trữ và nhắn tin, mô hình Ton's Gas có thể ngăn chặn một số hoạt động quá phức tạp chiếm quá nhiều tài nguyên. Bằng cách hạn chế mức tiêu thụ Gas, Ton đảm bảo rằng mỗi nút trong mạng có thể phân bổ tài nguyên máy tính một cách công bằng và tránh tiêu thụ quá mức tài nguyên mạng chỉ bằng một hợp đồng hoặc hoạt động.

Xử lý song song và tối ưu hóa Gas

Ton hỗ trợ xử lý song song các hợp đồng thông minh, cho phép nhiều hợp đồng chạy trên các phân đoạn khác nhau cùng lúc mà không chặn lẫn nhau. Theo thiết kế này, mô hình Gas của nó được tích hợp chặt chẽ với cơ chế thực thi và phân chia song song bằng cách xử lý song song các hợp đồng trên nhiều phân đoạn, Ton có thể phân tán các tính toán và thanh toán Gas đến các nút và chuỗi khác nhau, tránh tắc nghẽn mạng, đồng thời tối đa hóa việc sử dụng tài nguyên.

Cơ chế điều chỉnh khí động

Mô hình Ton’s Gas bao gồm cơ chế điều chỉnh động cho phép điều chỉnh phí Gas theo tải thời gian thực của mạng. Điều này có nghĩa là khi tải mạng thấp, người dùng có thể thực hiện hợp đồng với phí gas thấp hơn, từ đó khuyến khích hoạt động trong thời gian tải thấp và cân bằng việc sử dụng tài nguyên của mạng. Cơ chế này không chỉ cải thiện trải nghiệm người dùng mà còn kiểm soát việc sử dụng tài nguyên ở mức cao nhất thông qua cách tiếp cận theo định hướng thị trường.

Hợp đồng thông minh Ton rất dễ bị bỏ qua các lỗ hổng

Trong Bài viết phân tích bảo mật TON trước đã trình bày chi tiết về các lỗ hổng bảo mật chung của hệ sinh thái Ton. Bạn cũng có thể tham khảo bảng sau: > p>

Bài viết này sẽ tập trung vào các điểm dễ bị tổn thương dễ bị bỏ qua trong hợp đồng TON được nhóm của chúng tôi tóm tắt:

(1) Tối ưu hóa khả năng đọc mã

< p>Trong hợp đồng thông minh của TON, các số được sử dụng để lưu trữ dữ liệu liên quan được gửi qua tin nhắn. Ví dụ: trong đoạn mã sau, các số được sử dụng nhiều lần để thể hiện nhận dạng tương ứng và độ dài lưu trữ dữ liệu, điều này làm giảm đáng kể khả năng đọc và độ dài lưu trữ dữ liệu. của mã. Khi các nhà phát triển khác đọc mã này, rất khó để hiểu ý nghĩa và mục đích của những con số này. Để cải thiện khả năng đọc và khả năng bảo trì của mã, nên xác định các giá trị số chính dưới dạng hằng số được đặt tên, ví dụ: 0x18 được xác định là NON_BOUNCEABLE.

check_std_addr(address);var msg = begin_cell()   store_uint(0x18, 6) ;; nobounce   store_slice( địa chỉ)   store_coins(số tiền)   store_uint(0, 1 + 4 + 4 + 64 + 32 + 1  ;+ 1)   end_cell();send_raw_message(msg, 1);

Ngoài ra, nên xác định các biến tương ứng cho thông báo lỗi trong hợp đồng điều kiện phán đoán Thay thế mã lỗi.

(2) Sử dụng end_parse() đảm bảo tính toàn vẹn của dữ liệu

Trong hợp đồng TON, việc phân tích dữ liệu tuân theo một thứ tự cố định, tải dần các loại dữ liệu được chỉ định từ dữ liệu gốc. Phương pháp phân tích cú pháp này đảm bảo tính nhất quán và chính xác của dữ liệu. Như hiển thị bên dưới:

Lưu ý rằng end_parse() ở đây được sử dụng để kiểm tra xem lát (lát) dữ liệu có trống hay không. Nếu lát cắt không trống, hàm sẽ đưa ra một ngoại lệ. Điều này đảm bảo rằng định dạng và nội dung của dữ liệu như mong đợi. Nếu hàm end_parse() phát hiện vẫn còn dữ liệu trong lát dữ liệu, điều này có thể cho thấy quá trình phân tích cú pháp dữ liệu không diễn ra chính xác như mong đợi hoặc có vấn đề với định dạng của dữ liệu. Do đó, bằng cách gọi end_parse(), bạn có thể kiểm tra xem có bất kỳ thiếu sót hoặc ngoại lệ nào trong dữ liệu trong quá trình phân tích cú pháp hay không.

(3) Các ngoại lệ do không khớp giữa bản ghi dữ liệu và loại lưu trữ

Điều chính cần lưu ý ở đây là loại truy cập của int và uint khớp với nhau. dữ liệu Khi lưu trữ, store_int() được sử dụng để lưu trữ giá trị kiểu int là -42, nhưng Load_uint() được sử dụng để tải giá trị này.

(4)inline_ref và việc sử dụng hợp lý các công cụ sửa đổi nội tuyến

Trước hết, cần giải thích sự khác biệt giữa công cụ sửa đổi inline_ref và công cụ sửa đổi nội tuyến:

lInline: Mã của hàm sử dụng công cụ sửa đổi nội tuyến sẽ có. Mỗi lần nó được gọi, nó sẽ được chèn trực tiếp vào vị trí gọi. Nghĩa là, mỗi khi một hàm được gọi, mã thực tế của hàm sẽ được sao chép vào vị trí gọi, thay vì được thực thi bằng cách nhảy đến thân hàm như hàm thông thường.

linline_ref: Một hàm sử dụng công cụ sửa đổi inline_ref, có mã được lưu trữ trong một ô riêng biệt. Mỗi khi một hàm được gọi, TVM sẽ thực thi mã được lưu trong ô thông qua lệnh CALLREF thay vì chèn mã hàm vào vị trí cuộc gọi.

Vì vậy, công cụ sửa đổi nội tuyến phù hợp với các hàm đơn giản, giảm chi phí gọi hàm, nhưng có thể dẫn đến trùng lặp mã hợp đồng; trong khi công cụ sửa đổi inline_ref phù hợp với các hàm phức tạp hơn hoặc được gọi nhiều hơn, bằng cách lưu trữ mã chức năng Trong một ô riêng biệt để nâng cao hiệu quả và tránh trùng lặp mã. Khi đó có thể tóm tắt như sau: khi hàm lớn hoặc được gọi từ nhiều nơi thì nên sử dụng inline_ref nếu không thì nên sử dụng inline.

(5) Xác định chuỗi công việc chính xác

TON cho phép tạo tối đa 2^32 chuỗi công việc và mỗi chuỗi công việc có thể được chia thành tối đa 2^60 điểm Ở đó chỉ có 2 chuỗi hoạt động trước lát cắt: chuỗi chính (-1) và chuỗi cơ bản (0). Khi tính toán địa chỉ đích trong hợp đồng, ID chuỗi chứa địa chỉ đích phải được chỉ định rõ ràng để đảm bảo rằng địa chỉ ví được tạo nằm trên chuỗi hoạt động chính xác. Để tránh tạo địa chỉ sai, bạn nên sử dụng Force_chain() để buộc chỉ định ID chuỗi.

(6) Tránh xung đột mã lỗi

Trong thiết kế hợp đồng, để đảm bảo tiêu chuẩn hóa và tránh nhầm lẫn, việc quản lý mã lỗi là rất quan trọng. Đối với hợp đồng thông minh TON, trước hết, bạn nên đảm bảo rằng mỗi mã lỗi là duy nhất trong hợp đồng và tránh xác định các mã lỗi lặp lại trong cùng một hợp đồng để tránh nhầm lẫn về mã lỗi và thông tin không rõ ràng. Thứ hai, nền tảng TON hoặc hệ thống cơ bản có; Một số mã lỗi tiêu chuẩn đã được xác định và nên tránh xung đột với các mã lỗi hệ thống này. Ví dụ: mã lỗi 333 cho biết ID chuỗi không khớp. Vì vậy, mã lỗi của hợp đồng tốt nhất là nằm trong khoảng từ 400 đến 1000.

(7) Sau khi thao tác hoàn tất, bạn cần lưu trữ dữ liệu và gọi return()

Trong hợp đồng thông minh TON, quá trình xử lý tin nhắn sẽ chọn logic khác nhau tùy theo hoạt động -mã số. Sau khi hoàn thành logic nghiệp vụ tương ứng, cần hoàn thành hai thao tác: thứ nhất, nếu có thay đổi dữ liệu, phải gọi save_data() để đảm bảo rằng dữ liệu được lưu trữ, nếu không các thay đổi sẽ không hợp lệ. được gọi để cho biết rằng thao tác đã hoàn tất, nếu không, ngoại lệ Throw(0xffff) sẽ được kích hoạt.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) không tinh khiết {int flags = cs~load_uint(4); code>if (flags & 1) {   bỏ qua tất cả các tin nhắn bị trả lại   return (); slice sender_address = cs~load_msg_addr();load_data();int op = in_msg_body~load_op();if ((op == op::op_1())) {   hand_op1();   save_data();   ; return (); if ((op == op::op_2())) {   code>    save_data();   return (); if ((op == op::op_3( )) ) {   hand_op3();   save_data();   return (); throw(0xffff);

Tóm lại, chuỗi khối TON, với kiến ​​trúc đổi mới và tính linh hoạt của nó. môi trường phát triển đang dần trở thành nền tảng lý tưởng cho các nhà phát triển ứng dụng phi tập trung. Tuy nhiên, vì hợp đồng thông minh đóng vai trò ngày càng quan trọng trong hệ sinh thái TON nên không thể bỏ qua vấn đề bảo mật hợp đồng. Các nhà phát triển cần có hiểu biết sâu sắc về các đặc điểm của hệ sinh thái TON, tuân thủ nghiêm ngặt các phương pháp hay nhất, tăng cường quy trình kiểm tra bảo mật và đảm bảo tính bền vững và bảo mật của hợp đồng. Chỉ bằng cách này, chúng ta mới có thể phát huy hết lợi thế của nền tảng TON, xây dựng các ứng dụng phi tập trung an toàn và đáng tin cậy hơn, đồng thời bảo vệ sự phát triển lành mạnh của toàn bộ hệ sinh thái.

Hiện tại, hệ sinh thái TON đang phát triển nhanh chóng, thu hút một lượng lớn tiền và người dùng tích cực. Tuy nhiên, không thể bỏ quacác vấn đề bảo mật phát sinh.