Giới thiệu: Sau khi Binance ra mắt Notcoin, trò chơi lớn nhất trong hệ sinh thái TON và nền kinh tế mã thông báo lưu hành đầy đủ của nó đã tạo ra hiệu ứng giàu có khổng lồ, TON nhanh chóng thu hút được rất nhiều sự chú ý. Trò chuyện với bạn bè, tôi phát hiện ra rằng TON có rào cản kỹ thuật cao và mô hình phát triển DApp của nó rất khác so với các giao thức blockchain chính thống. Vì vậy, tôi đã dành thời gian nghiên cứu sâu về chủ đề này và có một số hiểu biết sâu sắc để chia sẻ với bạn. Trên short, triết lý thiết kế cốt lõi của TON là xây dựng lại các giao thức blockchain truyền thống từ đầu, tập trung vào việc đạt được tính đồng thời và khả năng mở rộng cao, ngay cả khi điều đó có nghĩa là hy sinh khả năng tương tác.

TON Nguyên tắc thiết kế cốt lõi - Tính đồng thời và khả năng mở rộng cao

Có thể nói, mục đích của tất cả các lựa chọn công nghệ phức tạp trong TON đều xuất phát từ việc theo đuổi tính đồng thời cao và khả năng mở rộng cao. Tất nhiên, không khó để chúng ta hiểu điều này từ nền tảng của sự ra đời của nó. TON, hay Mạng mở, là một mạng máy tính phi tập trung bao gồm một blockchain L1 và nhiều thành phần. TON ban đầu được phát triển bởi người sáng lập Telegram Nikolai Durov và nhóm của ông, và hiện được hỗ trợ và duy trì bởi một cộng đồng toàn cầu gồm những người đóng góp độc lập. Sự ra đời của nó bắt đầu từ năm 2017, khi nhóm Telegram bắt đầu khám phá các giải pháp blockchain cho chính họ. Vì không có blockchain L1 hiện tại nào vào thời điểm đó có thể hỗ trợ cơ sở người dùng chín con số của Telegram, họ quyết định thiết kế blockchain của riêng mình, sau đó được gọi là Mạng mở Telegram. Thời điểm đến vào năm 2018. Năm lệnh để có được các nguồn lực cần thiết để triển khai TON, Telegram đã triển khai bán mã thông báo Gram (sau này đổi tên thành Toncoin) trong quý đầu tiên của năm 2018. Vào năm 2020, nhóm Telegram đã rút khỏi dự án TON do các vấn đề pháp lý. Sau đó, một nhóm nhỏ các nhà phát triển nguồn mở và những người chiến thắng cuộc thi Telegram đã tiếp quản cơ sở mã của TON, đổi tên dự án thành Mạng mở và tiếp tục tích cực phát triển blockchain cho đến ngày nay, tuân thủ các nguyên tắc được nêu trong sách trắng TON gốc.

Vì TON được thiết kế để trở thành môi trường thực thi phi tập trung của Telegram, nó phải giải quyết hai thách thức chính: yêu cầu đồng thời cao và dữ liệu khổng lồ. Ngay cả TPS (giao dịch mỗi giây) được thử nghiệm cao nhất của Solana, được cho là nhanh nhất, cũng chỉ là 65.000, short nhiều so với TPS hàng triệu cấp cần thiết cho Telegram. Ngoài ra, lượng dữ liệu khổng lồ do Telegram tạo ra không thể được quản lý bởi một blockchain nơi mọi nút lưu trữ một bản sao hoàn chỉnh của dữ liệu.

Để giải quyết những thách thức này, TON các giao thức blockchain chính thống được tối ưu hóa theo hai cách:

l Nó sử dụng "Mô hình Phân mảnh vô hạn" để giảm dự phòng dữ liệu, cho phép nó xử lý một lượng lớn dữ liệu và giảm bớt tắc nghẽn hiệu suất.

l Bằng cách giới thiệu một môi trường thực thi song song hoàn toàn dựa trên mô hình Diễn viên, TPS mạng được cải thiện rất nhiều;

Xây dựng Blockchain chuỗi - cung cấp cho mỗi tài khoản chuỗi chuyên dụng của riêng mình thông qua Phân mảnh vô hạn

giờ chúng ta biết rằng sharding đã trở thành giải pháp chủ đạo cho hầu hết các giao thức blockchain để cải thiện hiệu suất và giảm chi phí, và TON đã đưa điều này đến mức cực đoan và đề xuất mô hình phân mảnh vô hạn, cái gọi là mô hình phân mảnh vô hạn. Đề cập đến việc cho phép blockchain tự động tăng hoặc giảm số lượng phân đoạn dựa trên tải mạng. Mô hình này cho phép TON xử lý các giao dịch quy mô lớn và hoạt động hợp đồng thông minh trong khi vẫn duy trì hiệu suất cao. Về lý thuyết, TON có thể thiết lập một chuỗi tài khoản độc quyền cho mỗi tài khoản và đảm bảo khả năng tương tác giữa các chuỗi này thông qua các quy tắc nhất định. tính nhất quán

Về bản chất, cấu trúc chuỗi của TON bao gồm bốn lớp

AccountChain: Lớp này đại diện cho một loạt các giao dịch được liên kết với một tài khoản cụ thể. Các giao dịch tạo thành một chuỗi bởi vì, trong một máy trạng thái, các quy tắc thực thi nhất quán đảm bảo rằng máy trạng thái tạo ra kết quả tương tự khi xử lý các lệnh trong cùng một lệnh. Do đó, tất cả các hệ thống blockchain đều yêu cầu các giao dịch phải được liên kết trong một chuỗi và TON cũng không khác. AccountChain là đơn vị cơ bản nhất trong mạng TON. Thông thường, AccountChain là một khái niệm ảo và AccountChain độc lập khó có thể tồn tại.

ShardChain: Trong hầu hết các ngữ cảnh, ShardChain là đơn vị thực tế trong TON. ShardChain về cơ bản là một tập hợp các AccountChains.

WorkChain: Còn được gọi là một tập hợp các chuỗi phân đoạn với các quy tắc tùy chỉnh, chẳng hạn như tạo WorkChain dựa trên EVM để chạy Solidity hợp đồng thông minh. Về lý thuyết, bất kỳ ai trong cộng đồng cũng có thể tạo WorkChain của riêng họ. Tuy nhiên, việc xây dựng một cái khá phức tạp và đòi hỏi phải trả phí sáng tạo (cao) và nhận được sự chấp thuận từ 2/3 Người xác thực.

MasterChain: Trong TON, có một chuỗi duy nhất được gọi là MasterChain, cung cấp tính cuối cùng cho tất cả các chuỗi phân đoạn. Khi giá trị Hàm băm của khối Chuỗi phân đoạn được bao gồm trong khối MasterChain, khối Chuỗi phân đoạn đó và tất cả các khối mẹ của nó được coi là cuối cùng, có nghĩa là chúng cố định và bất biến, được tham chiếu bởi tất cả các khối Chuỗi phân đoạn tiếp theo.

Mô hình này cung cấp cho mạng TON ba tính năng chính:

Phân mảnh động: TON có thể tự động tách và hợp nhất các chuỗi phân đoạn để thích ứng với tải thay đổi, đảm bảo các khối mới được tạo nhanh chóng và các giao dịch không gặp phải sự chậm trễ long

Khả năng mở rộng cao: Với mô hình phân mảnh vô hạn, TON có thể hỗ trợ gần như không giới hạn số lượng phân đoạn, về mặt lý thuyết lên tới 2 ^ 60 WorkChains.

Khả năng thích ứng: Khi một phần của mạng trải qua tải tăng lên, nó có thể chia nhỏ thành nhiều phân đoạn hơn để xử lý khối lượng giao dịch cao hơn. Ngược lại, khi tải giảm, các mảnh có thể hợp nhất để nâng cao hiệu quả.

Trong một hệ thống đa chuỗi như thế này, thách thức chính là giao tiếp chuỗi cross. Với khả năng phân mảnh vô hạn, khi số lượng phân đoạn trong mạng tăng lên đáng kể, việc định tuyến thông tin giữa các chuỗi trở nên phức tạp. Ví dụ: hãy tưởng tượng một mạng có bốn nút, mỗi nút duy trì một WorkChain độc lập. Mỗi nút, bên cạnh việc quản lý phân loại giao dịch của riêng mình, cũng phải theo dõi và xử lý các thay đổi trạng thái trong các chuỗi khác. Trong TON, điều này được thực hiện bằng cách giám sát các tin nhắn trong hàng đợi đầu ra.

Giả sử Tài khoản A trong WorkChain 1 muốn gửi tin nhắn đến Tài khoản C trong WorkChain 3. Điều này đòi hỏi phải thiết kế một giải pháp định tuyến tin nhắn. Trong ví dụ này, có hai đường dẫn định tuyến: WorkChain 1 -> WorkChain 2 -> WorkChain 3 và WorkChain 1 -> WorkChain 4 -> WorkChain 3.

Trong các tình huống phức tạp hơn, một thuật toán định tuyến hiệu quả và chi phí thấp là cần thiết để liên lạc tin nhắn nhanh. TON sử dụng "thuật toán định tuyến hypercube" để khám phá định tuyến tin nhắn chuỗi cross. Cấu trúc hypercube là một cấu trúc liên kết mạng đặc biệt trong đó một hypercube n chiều có 2^n đỉnh, mỗi đỉnh được xác định duy nhất bởi một số nhị phân n-bit. Trong cấu trúc này, hai đỉnh bất kỳ đều liền kề nhau nếu các biểu diễn nhị phân của chúng chỉ khác nhau một bit. Ví dụ, trong một hypercube 3 chiều, đỉnh 000 và đỉnh 001 liền kề nhau vì chúng chỉ khác nhau ở bit cuối cùng. Ví dụ trên là một hypercube 2 chiều.

Trong giao thức định tuyến hypercube, việc định tuyến một tin nhắn từ WorkChain nguồn đến WorkChain đích được thực hiện bằng cách so sánh các địa chỉ nhị phân của chúng. Thuật toán tìm khoảng cách tối thiểu giữa các địa chỉ này (tức là số lượng bit khác nhau) và chuyển tiếp tin nhắn qua các WorkChains liền kề cho đến khi đến đích. Điều này đảm bảo rằng gói dữ liệu đi theo con đường ngắn nhất, nâng cao hiệu quả truyền thông mạng. Để đơn giản hóa quá trình này, TON cũng đưa ra một giải pháp lạc quan. Nếu người dùng có thể cung cấp bằng chứng hợp lệ về đường dẫn định tuyến, thường là gốc trie Merkle, nút có thể xác minh ngay tính xác thực của tin nhắn. Điều này được gọi là định tuyến hypercube tức thì. Do đó, các địa chỉ TON khác biệt đáng kể so với các địa chỉ trong các giao thức blockchain khác. Hầu hết các giao thức blockchain sử dụng Hàm băm khóa công khai được tạo bởi các thuật toán mã hóa elip làm địa chỉ, tập trung vào tính duy nhất mà không cần các chức năng định tuyến. Trong TON, địa chỉ bao gồm hai phần: (workchain_id, tài khoản_id), với workchain_id được mã hóa theo thuật toán định tuyến hypercube. Người ta có thể tự hỏi tại sao không chuyển tiếp tất cả thông tin chuỗi cross thông qua MasterChain, tương tự như Cosmos. Trong thiết kế của TON, MasterChain chỉ xử lý nhiệm vụ quan trọng nhất là duy trì tính cuối cùng của WorkChains. Mặc dù có thể định tuyến tin nhắn thông qua MasterChain, nhưng các khoản phí liên quan sẽ rất cao.

Cuối cùng, hãy thảo luận ngắn gọn về thuật toán đồng thuận của nó. TON sử dụng kết hợp BFT (Đứt gãy Byzantine Tolerance) và PoS (Bằng chứng về cổ phần). Điều này có nghĩa là bất kỳ người đặt cọc nào cũng có thể tham gia vào việc tạo khối. Hợp đồng quản trị bầu cử TON định kỳ chọn một nhóm Người xác thực ngẫu nhiên từ tất cả những người đặt cược. Những Người xác thực được chọn này sau đó sử dụng thuật toán BFT để tạo các khối. Nếu trình xác thực tạo các khối không hợp lệ hoặc hành động độc hại, mã thông báo đã đặt cọc của họ sẽ bị tịch thu. Ngược lại, họ nhận được phần thưởng khi tạo thành công các khối hợp lệ. Phương pháp này khá phổ biến, vì vậy chúng tôi sẽ không đi vào chi tiết hơn ở đây.

Hợp đồng thông minh sử dụng mô hình Actor trong môi trường thực thi hoàn toàn song song

Một điểm khác biệt chính khác về TON so với các giao thức blockchain chính là môi trường thực thi hợp đồng thông minh của nó. Để khắc phục những hạn chế TPS mà các giao thức blockchain chính thống phải đối mặt, TON sử dụng phương pháp thiết kế từ dưới lên và sử dụng mô hình Actor để tái tạo lại hợp đồng thông minh và việc thực thi chúng, cho phép khả năng thực thi song song hoàn toàn.

Hầu hết các giao thức blockchain chính thống sử dụng môi trường thực thi nối tiếp, đơn luồng. Ví dụ, môi trường thực thi của Ethereum, EVM, hoạt động như một máy trạng thái xử lý các giao dịch tuần tự. Sau khi một khối được hình thành và các giao dịch được đặt hàng, chúng được thực hiện từng cái một thông qua EVM. Quá trình đơn luồng, nối tiếp hoàn toàn này có nghĩa là chỉ có một giao dịch được xử lý tại bất kỳ thời điểm nào. Ưu điểm là một khi lệnh giao dịch được thiết lập, kết quả thực hiện vẫn nhất quán trên một mạng phân tán. Hơn nữa, vì chỉ có một giao dịch được thực hiện tại một thời điểm, không có giao dịch nào khác có thể thay đổi dữ liệu trạng thái được truy cập, đảm bảo khả năng tương tác giữa các hợp đồng thông minh. Ví dụ: khi sử dụng Uniswap để mua ETH bằng USDT, phân phối của nhóm thanh khoản là một giá trị cố định trong quá trình thực hiện. Điều này cho phép các mô hình toán học xác định kết quả chính xác. Ngược lại, nếu các nhà cung cấp thanh khoản khác thêm thanh khoản trong quá trình tính toán Đường cong Bonding Curve, kết quả sẽ lỗi thời, điều này rõ ràng là không thể chấp nhận được.

Tuy nhiên, kiến trúc này cũng có những hạn chế rõ ràng, đặc biệt là nút cổ chai TPS, cảm thấy lỗi thời với các bộ xử lý đa lõi hiện đại. Nó tương tự như chơi các trò chơi máy tính cũ như Red Alert trên PC hoàn toàn mới; Khi số lượng đơn vị chiến đấu đạt đến một cấp độ nhất định, bạn vẫn gặp phải độ trễ đáng kể. Điều này là do các vấn đề về kiến trúc phần mềm.

Một số giao thức đang giải quyết vấn đề này và đã đề xuất các giải pháp song song của riêng họ. Ví dụ: Solana, tuyên bố có TPS cao nhất, cũng hỗ trợ thực thi song song. Tuy nhiên, thiết kế của Solana khác với TON. Ý tưởng cốt lõi của Solana là nhóm tất cả các giao dịch dựa trên các phụ thuộc thực thi của chúng, đảm bảo rằng các nhóm khác nhau không chia sẻ bất kỳ dữ liệu trạng thái nào. Điều này có nghĩa là không có sự phụ thuộc chung, cho phép các giao dịch trong các nhóm khác nhau thực hiện song song mà không có xung đột. Các giao dịch trong cùng một nhóm vẫn được thực hiện tuần tự.

Ngược lại, TON hoàn toàn từ bỏ kiến trúc thực thi nối tiếp và áp dụng một mô hình phát triển được thiết kế đặc biệt cho tính song song, sử dụng mô hình Actor để xây dựng lại môi trường thực thi của nó. Mô hình Diễn viên, lần đầu tiên được đề xuất bởi Carl Hewitt vào năm 1973, nhằm mục đích giải quyết sự phức tạp của các trạng thái được chia sẻ trong các chương trình đồng thời truyền thống thông qua việc truyền thông điệp. Mỗi Diễn viên có trạng thái và hành vi riêng và không chia sẻ thông tin trạng thái với các Diễn viên khác. Mô hình Actor là một mô hình tính toán đồng thời đạt được xử lý song song thông qua việc truyền thông điệp. Trong mô hình này, "Diễn viên" là một đơn vị cơ bản có thể xử lý các tin nhắn đã nhận, tạo Diễn viên mới, gửi tin nhắn bổ sung và quyết định cách trả lời các tin nhắn tiếp theo. Mô hình Diễn viên phải có các đặc điểm sau:

Đóng gói và Độc lập: Mỗi Actor hoạt động hoàn toàn độc lập khi xử lý tin nhắn, cho phép xử lý tin nhắn song song mà không bị nhiễu.

Truyền thông điệp: Các tác nhân chỉ tương tác thông qua việc gửi và nhận tin nhắn, với việc truyền thông điệp không đồng bộ.

Cấu trúc động: Diễn viên có thể tạo thêm Diễn viên trong thời gian chạy, cho phép mô hình Diễn viên tự động mở rộng hệ thống khi cần.

TON áp dụng kiến trúc này cho mô hình hợp đồng thông minh của mình, có nghĩa là mỗi hợp đồng thông minh trong TON đều dựa trên mô hình Actor và có bộ nhớ hoàn toàn độc lập vì nó không phụ thuộc vào bất kỳ dữ liệu bên ngoài nào. Hơn nữa, các cuộc gọi đến cùng một hợp đồng thông minh được thực hiện trong lệnh tin nhắn trong hàng đợi nhận. Điều này cho phép các giao dịch trong TON được thực hiện song song một cách hiệu quả mà không lo ngại về xung đột. Tuy nhiên, thiết kế này cũng giới thiệu một số thách thức mới. Đối với các nhà phát triển DApp, mô hình phát triển quen thuộc của họ sẽ bị phá vỡ theo những cách sau:

1. Cuộc gọi Hợp đồng thông minh không đồng bộ: Trong TON, không thể gọi nguyên tử các hợp đồng bên ngoài hoặc truy cập dữ liệu hợp đồng bên ngoài trong hợp đồng thông minh. Ví dụ, trong Solidity, hàm của Hợp đồng A1 đơn giản gọi hàm của Hợp đồng B2 hoặc truy cập dữ liệu trạng thái nhất định thông qua hàm chỉ đọc của Hợp đồng C3, tất cả trong một giao dịch duy nhất. Tuy nhiên, trong TON, điều này không thể đạt được. Bất kỳ tương tác nào với hợp đồng thông minh bên ngoài sẽ được thực hiện không đồng bộ bằng cách tạo các giao dịch mới, được gọi là thông điệp nội bộ do hợp đồng thông minh khởi xướng. Quá trình thực hiện không thể bị chặn để chờ kết quả.

Ví dụ: nếu chúng tôi đang phát triển DEX và tuân theo mô hình EVM chung, chúng tôi thường có một hợp đồng bộ định tuyến thống nhất để quản lý định tuyến giao dịch, trong khi mỗi nhóm quản lý độc lập dữ liệu LP cho các cặp giao dịch cụ thể. Giả sử chúng ta có hai hồ bơi: USDT-DAI và DAI-ETH. Khi người dùng muốn mua ETH trực tiếp với USDT, họ có thể sử dụng hợp đồng bộ định tuyến để tương tác tuần tự với hai nhóm này trong một giao dịch nguyên tử duy nhất. Tuy nhiên, trên TON, quá trình này không đơn giản và đòi hỏi một cách tiếp cận phát triển khác. Nếu chúng ta cố gắng sử dụng lại mô hình EVM này, luồng thông tin sẽ liên quan đến một thông điệp bên ngoài do người dùng khởi xướng và ba thông điệp nội bộ để hoàn thành giao dịch (lưu ý rằng ví dụ này là để làm nổi bật sự khác biệt; trong phát triển thực tế, ngay cả mô hình ERC20 cũng cần phải được thiết kế lại).

1. Cần xem xét cẩn thận để xử lý lỗi trong các cuộc gọi hợp đồng chéo, thiết kế các chức năng trả lại phù hợp cho từng tương tác giữa các hợp đồng. Trong các hệ thống EVM chính thống, nếu xảy ra lỗi trong quá trình thực hiện giao dịch, toàn bộ giao dịch sẽ được đưa trở lại trạng thái ban đầu. Điều này là đơn giản trong một mô hình đơn luồng nối tiếp. Tuy nhiên, trên TON, vì các cuộc gọi liên hợp đồng được thực hiện không đồng bộ, nếu xảy ra lỗi ở giai đoạn sau, các giao dịch được thực hiện thành công trước đó đã được xác nhận, có khả năng gây ra sự cố. Do đó, TON đã giới thiệu một loại tin nhắn đặc biệt gọi là tin nhắn bị trả lại. Nếu xảy ra lỗi trong quá trình thực hiện tin nhắn nội bộ tiếp theo, hợp đồng được kích hoạt có thể sử dụng chức năng trả lại được dành riêng trong hợp đồng kích hoạt để đặt lại một số trạng thái nhất định trong hợp đồng kích hoạt.

2. Trong các tình huống phức tạp, các giao dịch được nhận trước có thể không được hoàn thành trước, vì vậy bạn không thể giả định một lệnh thực hiện cụ thể. Trong một hệ thống hợp đồng thông minh không đồng bộ và song song, việc xác định lệnh xử lý có thể là một thách thức. Đây là lý do tại sao mọi tin nhắn trong TON đều có thời gian hợp lý, được gọi là thời gian Lamport (lt). Nó giúp xác định sự kiện nào đã kích hoạt sự kiện khác và những gì Người xác thực cần xử lý trước. Trong một mô hình đơn giản, các giao dịch nhận được đầu tiên được thực hiện đầu tiên.

Trong mô hình này, A và B đại diện cho hai hợp đồng thông minh. Nếu msg1_lt < msg2_lt, thì tx1_lt < tx2_lt về trình tự.

Tuy nhiên, trong các tình huống phức tạp hơn, quy tắc này có thể bị phá vỡ. Tài liệu chính thức cung cấp một ví dụ: giả sử chúng ta có ba hợp đồng, A, B và C. Trong một giao dịch, A gửi hai tin nhắn nội bộ, msg1 và msg2, một đến B và một cho C. Mặc dù chúng được tạo ra trong một lệnh cụ thể (msg1 trước, sau đó msg2), chúng tôi không thể chắc chắn rằng msg1 sẽ được xử lý trước msg2. Sự không chắc chắn này phát sinh vì các tuyến đường từ A đến B và từ A đến C có thể khác nhau về độ dài và bộ xác thực. Nếu các hợp đồng này nằm trong các chuỗi phân đoạn khác nhau, một thư có thể mất vài khối để đạt được hợp đồng đích. Do đó, có hai con đường giao dịch có thể, như minh họa.

1. Trong TON, lưu trữ liên tục cho hợp đồng thông minh sử dụng cấu trúc đồ thị có định hướng không tuần hoàn (DAG với các ô là đơn vị. Dữ liệu được nén nhỏ gọn vào một ô theo các quy tắc mã hóa cụ thể và mở rộng xuống một cách DAG. Điều này trái ngược với cấu trúc dựa trên hashmap được sử dụng trong EVM cho dữ liệu trạng thái. Do các thuật toán truy cập dữ liệu khác nhau, TON chỉ định các mức giá gas khác nhau để xử lý dữ liệu ở các độ sâu khác nhau; Xử lý dữ liệu tế bào sâu hơn đòi hỏi nhiều gas hơn. Do đó, TON phải đối mặt với một loại tấn công DOS, trong đó người dùng độc hại tràn ngập một hợp đồng thông minh với một số lượng lớn tin nhắn rác, lấp đầy tất cả các ô nông. Điều này làm tăng chi phí lưu trữ cho người dùng trung thực. Ngược lại, hashmap của EVM có độ phức tạp truy vấn là O(1), đảm bảo chi phí gas nhất quán và tránh các vấn đề tương tự. Do đó, các nhà phát triển TON Dapp nên tránh sử dụng các kiểu dữ liệu không giới hạn trong hợp đồng thông minh. Khi các kiểu dữ liệu không liên kết là cần thiết, chúng nên được phân vùng bằng cách sử dụng phân đoạn.

1. Một số tính năng ít độc đáo hơn, chẳng hạn như yêu cầu hợp đồng thông minh phải trả tiền thuê để lưu trữ. Trên TON, hợp đồng thông minh vốn có thể nâng cấp và đi kèm với các chức năng tài khoản trừu tượng gốc, có nghĩa là tất cả các địa chỉ ví trong TON đều hợp đồng thông minh, chỉ là chưa được khởi tạo. Các nhà phát triển cần chú ý đến những khía cạnh này.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Theblockbeats]. Tất cả bản quyền thuộc về tác giả gốc [Web3Mario]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.