Trong lĩnh vực công nghệ blockchain đang phát triển nhanh chóng, TON (The Open Network) đang thu hút sự chú ý ngày càng tăng từ phía các nhà phát triển với tư cách là một nền tảng blockchain hiệu quả và linh hoạt. 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à những khả năng phong phú cho việc phát triển các ứng dụng phi tập trung.

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

Bài viết này sẽ cung cấp một phân tích chi tiết về các tính năng liên quan đến hợp đồng thông minh trên blockchain TON, cũng như những lỗ hổng trong hợp đồng thông minh TON thường bị bỏ qua.

Phân tích các tính năng không đồng bộ và cơ chế tài khoản của TON

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

Network Sharding và Giao tiếp Bất đồng bộ

Blockchain TON được thiết kế với ba loại chuỗi: Masterchain, Workingchains và Shardchains.

Masterchain là cốt lõi của toàn bộ mạng, 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 Workingchains và Shardchains và đảm bảo tính nhất quán và bảo mật mạng. Workingchains là các blockchain độc lập, với tối đa 2 ^ 32 chuỗ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 Workingchain có thể có các quy tắc và tính năng riêng để đáp ứng các nhu cầu ứng dụng khác nhau. Shardchains là các chuỗi con của Workingchains, được sử dụng để phân chia thêm khối lượng công việc của Workingchains, nâng cao khả năng xử lý và khả năng mở rộng. Mỗi Workingchain có thể được chia thành tối đa 2 ^ 60 Shardchains, với Shardchains xử lý một số giao dịch một cách độc lập để đạt được xử lý song song hiệu quả.

Lý thuyết, mỗi tài khoản có thể chiếm độc quyền một Shardchain, với mỗi tài khoản duy trì cân bằng COIN/TOKEN một cách độc lập. Các giao dịch giữa các tài khoản có thể hoàn toàn song song. Các tài khoản giao tiếp qua tin nhắn bất đồng bộ, và con đường để tin nhắn di chuyển giữa các Shardchains là log_16(N) - 1, trong đó N là số lượng Shardchains.

Nguồn hình ảnh: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574Trong thế giới web3, ở Ton, các tương tác được tiến hành thông qua việc gửi và nhận các thông điệp. Các thông điệp này có thể là nội bộ (thường được gửi bởi các hợp đồng thông minh tương tác với nhau) hoặc bên ngoài (được gửi bởi các nguồn bên ngoài). Quá trình truyền thông thông điệp không đòi hỏi phản hồi ngay lập tức từ hợp đồng mục tiêu, cho phép người gửi tiếp tục thực thi phần logic còn lại. Cơ chế truyền thông bất đồng bộ này cung cấp tính linh hoạt và khả năng mở rộng lớn hơn so với cuộc gọi đồng bộ của Ethereum, giảm thiểu các chướng ngại về hiệu suất do chờ đợi phản hồi, đồng thời cũng đưa ra thách thức trong việc xử lý đồng thời và điều kiện đua.

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

Trong TON, thông điệp thường bao gồm thông tin như người gửi, người nhận, số lượng và nội dung thông điệp. Nội dung thông điệp có thể bao gồm cuộc gọi chức năng, chuyển dữ liệu, hoặc nội dung tùy chỉnh khác. Định dạng thông điệp của TON được thiết kế linh hoạt và mở rộng, cho phép giao tiếp hiệu quả của các loại thông tin khác nhau giữa các hợp đồng khác nhau.

Hàng đợi tin nhắn và xử lý trạng thái

Mỗi hợp đồng duy trì một hàng đợi tin nhắn để lưu trữ những tin nhắn chưa được xử lý. Trong quá trình thực thi, hợp đồng xử lý các tin nhắn một cách tuần tự từ hàng đợi. Do việc xử lý tin nhắn là không đồng bộ, trạng thái của hợp đồng sẽ không được cập nhật ngay lập tức sau khi nhận một tin nhắn.

Ưu điểm của thông báo bất đồng bộ

• Cơ chế chia nhỏ hiệu quả: Cơ chế không đồng bộ của TON tương thích cao với thiết kế chia nhỏ của nó. Mỗi mảnh độc lập xử lý tin nhắn hợp đồng và thay đổi trạng thái, tránh trễ do đồng bộ qua các mảnh. Thiết kế này cải thiện tổng thể hiệu suất mạng và khả năng mở rộng.

• Tiêu Thụ Tài Nguyên Giảm: Tin nhắn không đồng bộ không yêu cầu phản hồi ngay lập tức, cho phép các hợp đồng TON thực thi trên nhiều khối và tránh tiêu thụ tài nguyên quá mức trong một khối duy nhất. Điều này cho phép TON hỗ trợ các hợp đồng thông minh phức tạp hơn và tốn nhiều tài nguyên hơn.

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

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

•Vấn đề Tính nhất quán của Trạng thái: Do tính không đồng bộ của việc truyền tin nhắn, các hợp đồng có thể nhận được các tin nhắn khác nhau vào thời điểm khác nhau, điều này yêu cầu các nhà phát triển chú ý đặc biệt đến tính nhất quán của trạng thái. Khi thiết kế hợp đồng, điều quan trọng là xem xét cách các thứ tự tin nhắn khác nhau có thể ảnh hưởng đến thay đổi trạng thái và đảm bảo hệ thống duy trì tính nhất quán trong tất cả các điều kiện.

•Điều Kiện Đua và Bảo Vệ: Xử lý tin nhắn không đồng bộ đưa ra các vấn đề điều kiện đua tiềm ẩn, nơi mà nhiều tin nhắn có thể cùng một lúc cố gắng sửa đổi trạng thái hợp đồng. Nhà phát triển cần triển khai các cơ chế khóa phù hợp hoặc sử dụng các thao tác giao dịch để ngăn chặn xung đột trạng thái.

•Xem xét về Bảo mật: Hợp đồng không đồng bộ dễ bị tấn công như tấn công người trung gian hoặc tấn công phát lại khi xử lý giao tiếp giữa các hợp đồng. Do đó, khi thiết kế hợp đồng không đồng bộ, rất quan trọng để giải quyết những rủi ro bảo mật tiềm ẩn này và áp dụng các biện pháp phòng ngừa, như sử dụng dấu thời gian, số ngẫu nhiên, hoặc phương pháp chữ ký đa bên.

Mô hình sổ cái

TON (The Open Network) sử dụng một mô hình trừu tượng tài khoản và sổ sách độc đáo khi thiết kế cơ sở hạ tầng blockchain của mình. Sự linh hoạt của mô hình này được phản ánh trong cách nó quản lý trạng thái tài khoản, truyền thông tin qua tin nhắn và thực thi hợp đồng.

Tài khoản trừu tượng hóa

Mô hình tài khoản của TON sử dụng trừu tượng dựa trên hợp đồng, trong đó mỗi tài khoản có thể được xem như một hợp đồng. Điều này tương đối giống với mô hình trừu tượng tài khoản của Ethereum nhưng linh hoạt và tổng quát hơn. Trong TON, tài khoản không chỉ là các thùng chứa cho tài sản; chúng còn bao gồm mã hợp đồng và dữ liệu trạng thái. Mỗi tài khoản bao gồm mã, dữ liệu và logic xử lý tin nhắn của nó.

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

Tính linh hoạt: Do mỗi tài khoản có thể thực thi mã hợp đồng riêng, các tài khoản TON có thể triển khai logic rất phức tạp. Các tài khoản không chỉ đơn giản là người giữ cân bằng mà còn có thể xử lý các chuyển đổi trạng thái phức tạp, giao tiếp tin nhắn giữa các tài khoản, và thậm chí là tự động hóa dựa trên điều kiện cụ thể. Điều này khiến mô hình tài khoản của TON linh hoạt và có khả năng mở rộng hơn so với các mô hình tài khoản blockchain 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, hỗ trợ truyền thông tin bất đồng bộ và hoạt động đa shard. Trạng thái của mỗi tài khoản được lưu trữ trong cấu trúc cây Merkle, cung cấp khả năng xác thực trạng thái hiệu quả.

Lưu trữ trạng thái

Thông tin trạng thái tài khoản được lưu trữ trong bộ nhớ cố định và được tổ chức thông qua một cây Merkle để đảm bảo tính toàn vẹn và an ninh. Thiết kế này cũng hỗ trợ truy vấn hiệu quả và xác minh trạng thái, đặc biệt là trong giao dịch chéo shard.

Một tài khoản hoặc trạng thái hợp đồng thông minh thông thường bao gồm các điều sau:

1. Số dư của đồng tiền cơ sở 2. Số dư của các đồng tiền khác 3. Mã hợp đồng thông minh (hoặc băm của nó) 4. Dữ liệu liên tục của hợp đồng thông minh (hoặc băm Merkle của nó) 5. Thống kê về số lượng đơn vị lưu trữ liên tục và việc sử dụng byte thô 6. Thời điểm gần đây của thanh toán đến bộ nhớ lưu trữ liên tục của hợp đồng thông minh (về cơ bản là số block chuỗi chính) 7. Khóa công khai cần thiết để chuyển đổi tiền tệ và gửi thông điệp từ tài khoản này (tùy chọn; mặc định, điều này bằng với account_id). Trong một số trường hợp, mã kiểm tra chữ ký phức tạp hơn có thể được tìm thấy ở đây, tương tự như đầu ra giao dịch Bitcoin; trong trường hợp như vậy, account_id sẽ là băm của mã này.

Không phải tất cả thông tin đều cần thiết cho mọi tài khoản. Ví dụ, mã hợp đồng thông minh chỉ liên quan đến các hợp đồng thông minh, không phải cho các tài khoản “đơn giản”. Ngoài ra, trong khi mỗi tài khoản phải có số dư không âm của đơn vị tiền tệ cơ bản (ví dụ, Gram cho chuỗi làm việc cơ sở và chuỗi shard), số dư cho các đơn vị tiền tệ khác có thể là không. Để tránh việc lưu trữ dữ liệu không sử dụng, loại kiểu tích tổ hợp được xác định trong quá trình tạo ra chuỗi làm việc, sử dụng các byte đánh dấu khác nhau để phân biệt các “hàm tạo”. Cuối cùng, trạng thái tài khoản được lưu trữ dưới dạng một bộ sưu tập các đơn vị trong bộ lưu trữ cố định của TVM.

Truyền thông tin và Xử lý

Cấu trúc sổ cái của TON bao gồm hỗ trợ tích hợp sẵn cho việc truyền tin bất đồng bộ. Mỗi tài khoản có thể xử lý các tin nhắn nhận được và cập nhật trạng thái của nó một cách độc lập. Cơ chế truyền tin bất đồng bộ này cho phép 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 bất kỳ hoạt động đơn lẻ nào.

mô hình Gas

TON (Mạng Mở) tối ưu hóa đáng kể hiệu suất thực thi của hợp đồng thông minh thông qua mô hình phí gas duy nhất của nó. Mô hình phí gas này được sử dụng để đo lường và giới hạn các tài nguyên tiêu thụ trong quá trình thực thi hợp đồng thông minh. So với các blockchain truyền thống như Ethereum, mô hình của TON phức tạp và hiệu quả hơn, cho phép quản lý chính xác hơn việc tiêu thụ tài nguyên trong quá trình thực thi hợp đồng.

Mô hình gas của TON có thể đo lường một cách chính xác các tài nguyên tính toán, thao tác lưu trữ và chi phí truyền thông tiêu thụ trong quá trình thực thi hợp đồng thông minh. Bằng cách cung cấp các đo lường chi tiết cho các tài nguyên như tính toán, lưu trữ và truyền thông, mô hình gas của TON ngăn chặn các thao tác có độ phức tạp quá cao tiêu tốn quá nhiều tài nguyên. Bằng cách giới hạn việc tiêu thụ gas, TON đảm bảo rằng mỗi nút mạng có thể phân phối công bằng các tài nguyên tính toán, tránh việc lạm dụng tài nguyên mạng bởi một hợp đồng hoặc thao tác đơn lẻ.

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 đồng thời trên các mảnh khác nhau mà không bị chặn lẫn nhau. Trong thiết kế này, mô hình gas được tích hợp chặt chẽ với cơ chế thực thi song song và phân mảnh. Bằng cách xử lý các hợp đồng song song trên nhiều phân mảnh khác nhau, TON có thể phân phối tính toán gas và thanh toán trên các nút và chuỗi khác nhau, tránh tắc nghẽn mạng và tối đa hóa sử dụng tài nguyên.

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

Hợp đồng thông minh TON dễ bỏ qua những kẽ hở

Trong bài viết phân tích bảo mật trước đây của chúng tôitrên TON, chúng tôi đã chi tiết về những lỗ hổng bảo mật phổ biến trong hệ sinh thái TON. Để tham khảo thêm, vui lòng xem bảng dưới đây:

Bài viết này sẽ tập trung vào những lỗ hổng trong các hợp đồng TON thường bị bỏ qua, như được tóm tắt bởi đội ngũ của chúng tôi:

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

Trong các hợp đồng thông minh TON, số thường được sử dụng để lưu trữ dữ liệu liên quan đến việc gửi tin nhắn. Ví dụ, trong đoạn mã bên dưới, nhiều trường hợp của số được sử dụng để đại diện cho các định danh tương ứng và độ dài lưu trữ dữ liệu, điều này đáng kể giảm đi tính đọc và bảo trì của mã. Các nhà phát triển khác có thể gặp khó khăn trong việc hiểu ý nghĩa và mục đích của các số này khi đọc mã. Để cải thiện tính đọc và bảo trì, nên xác định các giá trị số chính là hằng số có tên. Ví dụ, xác định0x18nhưNON_BOUNCEABLE.

1. check_std_addr(địa chỉ); là bột ngọt = 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(bột ngọt, 1);

Ngoài ra, đối với thông báo lỗi trong các điều kiện đánh giá hợp đồng, cũng nên định nghĩa các biến tương ứng để thay thế mã lỗi.

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

Trong hợp đồng TON, phân tích cú pháp dữ liệu tuân theo một thứ tự cố định, tải các loại dữ liệu được chỉ định từng bước từ dữ liệu thô. 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ư minh họa dưới đây:

Lưu ý rằngend_parse()được sử dụng để kiểm tra xem một lát cắt dữ liệu có rỗng hay không. Nếu lát cắt không rỗng, hàm sẽ ném 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 là như mong đợi. Nếu end_parse() Hàm phát hiện dữ liệu còn lại trong lát cắt, nó có thể chỉ ra rằng việc phân tích cú pháp dữ liệu không tiến hành như dự định hoặc có vấn đề với định dạng dữ liệu. Do đó, bằng cách gọi end_parse(), bạn có thể xác minh xem có bất kỳ sự bỏ sót hoặc bất thường nào trong quá trình phân tích không.

(3) Các trường hợp ngoại lệ gây ra bởi các loại và lưu trữ dữ liệu không khớp

Điều này chủ yếu liên quan đến sự phù hợp của Intvàuint các loại lưu trữ. Ví dụ: trong đoạn mã sau, store_int()function is used to store an Int Giá trị của -42, nhưng load_uint() được sử dụng để tải giá trị này, điều này có thể dẫn đến ngoại lệ.

(4) Sử dụng Đúng Cách của inline_ref và InlineCác bộ chỉnh sửa

Đầu tiên, quan trọng để phân biệt giữatrực tuyến và inline_refmodifiers:

trong dòng: Chức năng với InlineCác bộ điều chỉnh có mã của họ được chèn trực tiếp tại điểm gọi mỗi khi chúng được gọi. Điều này có nghĩa là mã thực tế của hàm được sao chép đến vị trí gọi thay vì được thực thi thông qua một bước nhảy hàm, điều này giảm thiểu chi phí gọi hàm nhưng có thể dẫn đến trùng lặp mã.

inline_ref: Các chức năng với inline_refmodifier lưu mã của họ trong một ô riêng biệt. Mỗi lần hàm được gọi, TVM thực thi mã được lưu trong ô quaCALLREFlệnh, tránh trùng lặp mã và cải thiện hiệu suất cho các chức năng phức tạp hơn hoặc được gọi nhiều lần.

Tóm lại, sử dụng trong đường line Đối với các hàm đơn giản để giảm chi phí cuộc gọi, nhưng hãy lưu ý đến khả năng trùng lặp mã. Dùng inline_ref cho các chức năng lớn hơn hoặc thường được gọi là để cải thiện hiệu quả và tránh lặp lại mã.

(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, mỗi chuỗi có thể được chia nhỏ hơn thành tối đa 2 ^ 60 phân đoạn. Ban đầu, có hai chuỗi làm việc: masterchain (-1) và basechain (0). Khi tính toán địa chỉ đích trong hợp đồng, điều quan trọng là phải chỉ định ID chuỗi công việc chính xác để đảm bảo rằng địa chỉ ví được tạo nằm trên chuỗi công việc chính xác. Để tránh tạo địa chỉ không chính xác, nên sử dụng force_chain()để chỉ định rõ ID chuỗi.

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

Quản lý hiệu quả các mã lỗi là rất quan trọng đối với thiết kế hợp đồng để đảm bảo tính nhất quán và tránh nhầm lẫn. Đối với hợp đồng thông minh TON, hãy đảm bảo rằng mỗi mã lỗi là duy nhất trong hợp đồng để ngăn xung đột và thông báo lỗi không rõ ràng. Ngoài ra, tránh xung đột với các mã lỗi tiêu chuẩn được xác định bởi nền tảng TON hoặc hệ thống cơ bản. Ví dụ: mã lỗi 333 cho biết ID chuỗi không khớp. Nên sử dụng mã lỗi từ 400 đến 1000 để ngăn chặn những xung đột như vậy.

(7) Lưu trữ Dữ liệu và Gọireturn() Sau khi hoàn thành hoạt động

Trong hợp đồng thông minh TON, xử lý tin nhắn liên quan đến việc chọn logic khác nhau dựa trên mã hoạt động. Sau khi hoàn thành logic tương ứng, hai bước bổ sung cần được thực hiện: Đầu tiên, nếu dữ liệu đã được sửa đổi, gọisave_data() để đảm bảo rằng các thay đổi được lưu trữ; Nếu không, những thay đổi sẽ không hiệu quả. Thứ hai, gọi return() để chỉ ra rằng hoạt động đã hoàn tất; nếu không, một ném(0xffff)sẽ kích hoạt ngoại lệ.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

if (cờ & 1) {

;; bỏ qua tất cả các tin nhắn bị trả lại

trả lại ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

if ((op == op::op_1())) {

xử lý_op1();

save_data();

return ();

}

if ((op == op::op_2())) {

handle_op2();

save_data();

return ();

if ((op == op::op_3())) {

handle_op3();

save_data();

return ();

}

throw(0xffff);

}

Tóm lại, blockchain TON, với kiến trúc sáng tạo và môi trường phát triển linh hoạt, đang trở thành một 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ì các hợp đồng thông minh đóng một vai trò ngày càng quan trọng trong hệ sinh thái TON, các vấn đề bảo mật không thể bị bỏ qua. Các nhà phát triển nên hiểu sâu sắc các đặc điểm của hệ sinh thái TON, tuân thủ nghiêm ngặt các thực tiễn tốt nhất và tăng cường các quy trình kiểm toán bảo mật để đảm bảo tính mạnh mẽ và bảo mật của hợp đồng. Chỉ bằng cách đó, những lợi thế của nền tảng TON mới có thể được nhận ra đầy đủ, xây dựng các ứng dụng phi tập trung an toàn và đáng tin cậy hơn và bảo vệ sự phát triển lành mạnh của toàn bộ hệ sinh thái.

Hệ sinh thái TON đang trải qua giai đoạn tăng trưởng nhanh chóng, thu hút quỹ đầu tư đáng kể và người dùng tích cực. Tuy nhiên, các vấn đề bảo mật đi kèm không thể bỏ qua. Để đảm bảo an ninh và đáng tin cậy cho hệ sinh thái TON, Beosin cung cấp kiểm toán bảo mật toàn diện và chuyên nghiệp được điều chỉnh cho các cuộc gọi và hoạt động của hợp đồng thông minh TON, hỗ trợ phát triển của hệ sinh thái.

Beosin có nhiều trường hợp thành công trong hệ sinh thái TON. Trước đây, Beosin đã tiến hành kiểm toán bảo mật kỹ lưỡng cho dự án stablecoin phi tập trung hàng đầu Aqua Protocol và cơ sở hạ tầng DeFi ONTON Finance. Kiểm toán bao gồm nhiều khía cạnh, bao gồm bảo mật mã hợp đồng thông minh, tính đúng đắn của việc triển khai logic kinh doanh, tối ưu hóa mã hợp đồng, phát hiện và khắc phục các lỗ hổng tiềm ẩn.

Tuyên bố:

1. Bài viết này được tái bản từ [Beosin], tiêu đề gốc "Beosin Hard Core Research | Từ rủi ro đến bảo vệ: Rủi ro bảo mật và đề xuất tối ưu hóa của TON Smart Contracts》, bản quyền thuộc về tác giả gốc [Beosin ], nếu bạn có bất kỳ phản đối nào đối với việc in lại, vui lòng liên hệ Đội ngũ Gate Learn, nhóm sẽ xử lý nó càng sớm càng tốt theo các quy trình liên quan.

2. Tuyên bố miễn trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn và không được đề cập trong.Gate, bài viết đã dịch không được sao chép, phân phối hoặc đạo văn.