Nguồn: Mario Kan Web3
Giới thiệu: Với việc Binance ra mắt TON, Notcoin, trò chơi lớn nhất trong hệ sinh thái và Do hiệu ứng tài sản to lớn do mô hình kinh tế mã thông báo lưu hành đầy đủ gây ra, TON đã thu hút được sự chú ý lớn trong một khoảng thời gian ngắn. Sau khi trò chuyện với một người bạn, tôi được biết rằng ngưỡng kỹ thuật của TON tương đối cao và mô hình phát triển DApp rất khác so với các giao thức chuỗi công khai chính thống, vì vậy tôi đã dành thời gian nghiên cứu chuyên sâu về các chủ đề liên quan và chia sẻ một số hiểu biết sâu sắc với bạn. Nói tóm lại, khái niệm thiết kế cốt lõi của TON là xây dựng lại giao thức blockchain truyền thống theo cách "từ dưới lên" và đạt được tính đồng thời cao và khả năng mở rộng cao nhưng phải đánh đổi bằng khả năng tương tác theo đuổi mục tiêu cuối cùng.
Ý tưởng thiết kế cốt lõi của TON - tính đồng thời cao và khả năng mở rộng cao
Nó có thể như thế này Nó Có thể nói rằng 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ó để hiểu điều này từ bối cảnh ra đời của nó. TON, hay Mạng mở, là mạng điện toán phi tập trung bao gồm chuỗi khối 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, hiện được hỗ trợ và duy trì bởi cộng đồng toàn cầu gồm những người đóng góp độc lập. Nó ra đời 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, nên họ đã quyết định thiết kế blockchain của riêng mình, khi đó được gọi là Mạng mở Telegram. Thời điểm đã đến vào năm 2018. Để có được nguồn lực cần thiết để triển khai TON, Telegram đã triển khai đợt bán token Gram (sau đổi tên thành Toncoin) vào quý đầu tiên của năm 2018. 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 The Open Network và tiếp tục tích cực phát triển chuỗi khối cho đến ngày nay, tuân thủ các nguyên tắc được nêu trong sách trắng TON ban đầu.
Vì mục tiêu thiết kế là phục vụ như một môi trường thực thi phi tập trung cho Telegram, nên chúng tôi đương nhiên phải đối mặt với hai vấn đề, số lượng yêu cầu đồng thời cao và dữ liệu khổng lồ. Với sự phát triển của công nghệ đến hiện tại, Solana, được cho là có TPS cao nhất, lại có TPS tối đa đo được chỉ là 65.000, rõ ràng là không đủ để hỗ trợ hệ sinh thái Telegram vốn đòi hỏi hàng triệu TPS. Đồng thời, với ứng dụng quy mô lớn của Telegram, lượng dữ liệu mà nó tạo ra đã vượt quá bầu trời. Là một hệ thống phân tán cực kỳ dư thừa, blockchain yêu cầu mọi nút trong mạng phải lưu một bản sao hoàn chỉnh của dữ liệu. cũng không thực tế.
Vì vậy, để giải quyết hai vấn đề trên, TON đã thực hiện hai tối ưu hóa cho các giao thức blockchain chính thống:
Bằng cách áp dụng hệ thống thiết kế "Mô hình phân mảnh vô hạn" (Infinite Sharding Paradigm), vấn đề dư thừa dữ liệu đã được giải quyết và có thể tải được Dữ liệu lớn , đồng thời giảm bớt tắc nghẽn về hiệu suất;
Bằng cách 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, TPS mạng được cải thiện đáng kể ;< /p>
Xây dựng chuỗi blockchain - cho phép mỗi tài khoản có một chuỗi tài khoản độc quyền thông qua khả năng phân chia không giới hạn
Bây giờ chúng tôi biết rằng sharding đã trở thành một giải pháp chủ đạo cho hầu hết các giao thức blockchain nhằm cải thiện hiệu suất và giảm chi phí, và TON sẽ làm được điều này. Nó đã đạt đến mức cực đoan và đề xuất mô hình sharding vô hạn. được gọi là mô hình phân đoạn vô hạn đề cập đến việc cho phép chuỗi khối tự động tăng hoặc giảm số lượng phân đoạn theo tải mạng. Mô hình này cho phép TON xử lý các giao dịch và hoạt động hợp đồng thông minh quy mô lớn trong khi vẫn duy trì hiệu suất cao. Về lý thuyết, TON có thể thiết lập chuỗi tài khoản độc quyền cho từng 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 tính nhất quán nhất định,
< p style="text-align: left;">Hiểu một cách trừu tượng, có tổng cộng cấu trúc chuỗi bốn lớp trong TON:
AccountChain: Lớp chuỗi này đại diện cho một chuỗi bao gồm một chuỗi các giao dịch liên quan đến một tài khoản. Lý do tại sao các giao dịch có thể hình thành cấu trúc chuỗi là vì đối với một máy trạng thái, miễn là vì các quy tắc thực thi là nhất quán nên kết quả mà máy trạng thái thu được sau khi nhận được hướng dẫn theo cùng một trình tự là nhất quán. Do đó, việc sắp xếp chuỗi giao dịch là bắt buộc trong tất cả các hệ thống phân tán blockchain. Chuỗi tài khoản là đơn vị thành phần cơ bản nhất trong mạng TON. Thông thường, chuỗi tài khoản là một khái niệm ảo và khó có khả năng tồn tại chuỗi tài khoản độc lập.
ShardChain: Trong hầu hết các bối cảnh, chuỗi phân đoạn là đơn vị thành phần thực tế trong TON, cái gọi là chuỗi phân đoạn là một tập hợp của chuỗi tài khoản.
WorkChain: Nó cũng có thể được gọi là một tập hợp các chuỗi sharding với các quy tắc tùy chỉnh, chẳng hạn như tạo chuỗi hoạt động A dựa trên EVM trên đó các hợp đồng thông minh Solidity chạy. Về lý thuyết, mọi người trong cộng đồng đều có thể tạo chuỗi công việc của riêng mình. Trên thực tế, việc xây dựng nó là một nhiệm vụ khá phức tạp, trước đó phải trả phí (đắt tiền) để tạo ra nó và nhận được 2/3 số phiếu bầu của những người xác nhận để phê duyệt việc tạo chuỗi làm việc của bạn.
Chuỗi chính (MasterChain): Cuối cùng, có một chuỗi đặc biệt trong TON được gọi là chuỗi chính, chịu trách nhiệm cho tất cả các Sharded dây chuyền mang lại sự cuối cùng. Sau khi hàm băm của khối chuỗi phân đoạn được hợp nhất vào khối của chuỗi chính, khối chuỗi phân đoạn đó và tất cả các khối gốc của nó được coi là cuối cùng, nghĩa là chúng có thể được coi là cố định và không thể phá vỡ. Nội dung đã thay đổi sẽ được tham chiếu bởi các khối tiếp theo trong tất cả phân đoạn. dây chuyền.
Bằng cách áp dụng mô hình như vậy, mạng TON có ba đặc điểm sau:
Phân đoạn động: TON có thể tự động phân chia và hợp nhất các chuỗi phân đoạn để thích ứng với những thay đổi về tải. Điều này có nghĩa là các khối mới luôn được tạo nhanh chóng và giao dịch không phải chờ đợi lâu.
Khả năng mở rộng cao: Thông qua mô hình phân mảnh vô hạn, TON có thể hỗ trợ số lượng phân đoạn gần như không giới hạn, về mặt lý thuyết có thể đạt tới 2 60 công việc dây chuyền.
Khả năng thích ứng: Khi tải trên một phần mạng nhất định tăng lên, phần đó có thể được chia thành nhiều phần hơn để xử lý lượng tăng lên. khối lượng giao dịch. Ngược lại, khi tải giảm, các phân đoạn có thể được hợp nhất để tăng hiệu quả.
Điều đầu tiên mà một hệ thống đa chuỗi như vậy cần phải đối mặt là vấn đề giao tiếp xuyên chuỗi, đặc biệt là do Khả năng phân chia không giới hạn, khi số lượng phân đoạn trong mạng đạt đến một mức nhất định, việc định tuyến thông tin giữa các chuỗi sẽ trở thành một nhiệm vụ khó khăn. Hãy tưởng tượng rằng có 4 nút trong mạng và mỗi nút chịu trách nhiệm duy trì chuỗi công việc độc lập. Mối quan hệ liên kết cho thấy rằng ngoài việc chịu trách nhiệm sắp xếp các giao dịch trong chuỗi công việc của riêng mình, nút còn cần giám sát và xử lý trạng thái. những thay đổi trong chuỗi mục tiêu, được triển khai trong TON 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 chuỗi công việc 1 muốn gửi tin nhắn đến tài khoản C trong chuỗi công việc 3. Sau đó, bạn cần thiết kế vấn đề định tuyến tin nhắn. Trong ví dụ này, có hai đường dẫn định tuyến, chuỗi công việc 1 -> chuỗi công việc 2-> 3.
Khi gặp những tình huống phức tạp hơn, cần có thuật toán định tuyến hiệu quả và chi phí thấp để hoàn thành nhanh chóng việc liên lạc bằng tin nhắn. TON đã chọn cái gọi là "thuật toán định tuyến hypercube". " Để hiện thực hóa việc khám phá lộ trình liên lạc bằng tin nhắn xuyên chuỗi. Cái gọi là cấu trúc siêu khối đề cập đến một cấu trúc liên kết mạng đặc biệt. Một siêu khối n chiều bao gồm 2^n đỉnh và mỗi đỉnh có thể được xác định duy nhất bằng một số nhị phân n-bit. Trong cấu trúc này, hai đỉnh bất kỳ sẽ liền kề nhau nếu chúng chỉ khác nhau một bit trong biểu diễn nhị phân. Ví dụ, trong siêu khối 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à siêu khối 2 chiều.

Trong giao thức định tuyến hypercube, quy trình định tuyến của một tin nhắn từ chuỗi công việc nguồn đến chuỗi công việc đích được thực hiện bằng cách so sánh các biểu diễn nhị phân của chuỗi công việc nguồn và địa chỉ chuỗi công việc đích. Thuật toán định tuyến tìm khoảng cách tối thiểu (tức là số bit khác nhau trong biểu diễn nhị phân) giữa hai địa chỉ này và chuyển dần thông tin qua các chuỗi công việc liền kề cho đến khi đạt được chuỗi công việc đích. Phương pháp này đảm bảo rằng các gói dữ liệu được truyền theo đường dẫn ngắn nhất, do đó cải thiện hiệu quả truyền thông của mạng.
Tất nhiên, để đơn giản hóa quy 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 bằng chứng hiệu quả về một đường dẫn định tuyến nhất định, đó là. Thông thường là một Merkle trie root nhất định, nút có thể trực tiếp nhận ra độ tin cậy của tin nhắn do người dùng gửi, còn được gọi là định tuyến hypercube tức thời.
Vì vậy, chúng ta có thể thấy rằng các địa chỉ trong TON khác biệt đáng kể 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 khác đều được tạo bằng thuật toán mã hóa hình elip. tương ứng với khóa chung trong khóa chung và khóa riêng được sử dụng làm địa chỉ, vì địa chỉ chỉ để phân biệt tính duy nhất và không cần mang chức năng đánh địa chỉ định tuyến. Địa chỉ trong TON bao gồm hai phần, (workchain_id, account_id) , trong đó Workchain_id dựa trên Địa chỉ thuật toán định tuyến hypercube được mã hóa, điều này sẽ không được thảo luận chi tiết ở đây.
Còn một điểm nữa rất dễ gây nghi ngờ. Có thể bạn đã nhận thấy rằng chuỗi chính và mỗi chuỗi công việc đều có mối quan hệ liên kết nên tất cả đều là chuỗi chéo. thông tin được truyền Chuỗi chính không thể được sử dụng làm rơle, giống như Cosmos? Trong ý tưởng thiết kế của TON, chuỗi chính chỉ được sử dụng để xử lý các nhiệm vụ quan trọng nhất, tức là duy trì tính hữu hạn của nhiều chuỗi công việc. Không thể định tuyến các thông điệp qua chuỗi chính, nhưng phí xử lý sẽ rất tốn kém. .
Cuối cùng, hãy đề cập ngắn gọn về thuật toán đồng thuận của nó. TON áp dụng phương pháp BFT+PoS, nghĩa là bất kỳ người đặt cược nào cũng có cơ hội tham gia vào cuộc bầu cử của TON. hợp đồng quản trị Thỉnh thoảng, một cụm trình xác thực được đóng gói sẽ được chọn ngẫu nhiên từ tất cả các Staker. Nút đã chọn, được gọi là trình xác thực, sẽ được đóng gói để tạo các khối thông qua thuật toán BFT. Nếu gói chứa thông tin sai hoặc có hành vi xấu. mã thông báo đã đặt cược sẽ bị mất, nếu không bạn sẽ nhận được phần thưởng khối. Về cơ bản đây là sự lựa chọn phổ biến nên tôi sẽ không giới thiệu ở đây.
Một hợp đồng thông minh và môi trường thực thi song song hoàn toàn dựa trên mô hình Actor
Một hợp đồng khác trong TON với Điều khác biệt giữa các giao thức blockchain chính thống là môi trường thực thi hợp đồng thông minh của chúng. Để vượt qua những hạn chế của TPS của các giao thức blockchain chính thống, TON áp dụng ý tưởng thiết kế từ dưới lên và sử dụng mô hình Actor để xây dựng lại các hợp đồng thông minh và phương thức thực thi của chúng, để chúng có khả năng song song hoàn toàn.
Chúng tôi biết rằng hầu hết các giao thức blockchain chính thống đều sử dụng môi trường thực thi nối tiếp một luồng, lấy Ethereum làm ví dụ, môi trường thực thi EVM của nó là một môi trường dựa trên giao dịch. Máy trạng thái đầu vào, khi nút tạo khối hoàn thành việc sắp xếp các giao dịch theo khối đóng gói, các giao dịch sẽ được thực hiện thông qua EVM theo thứ tự này, toàn bộ quá trình hoàn toàn nối tiếp và đơn luồng, nghĩa là chỉ có thể thực hiện một giao dịch. được xử lý tại một thời điểm nhất định, ưu điểm của việc này là miễn là trình tự giao dịch được xác nhận, kết quả thực hiện sẽ nhất quán trên một loạt các cụm phân tán. Đồng thời, vì chỉ có một giao dịch được thực hiện nối tiếp tại một thời điểm. Đồng thời, điều này có nghĩa là trong quá trình thực hiện, các giao dịch khác không thể sửa đổi dữ liệu trạng thái nhất định để truy cập, do đó đạt được khả năng tương tác giữa các hợp đồng thông minh. Ví dụ: chúng tôi sử dụng USDT để mua ETH thông qua Uniswap. Khi giao dịch được thực hiện, việc phân phối LP trong cặp giao dịch là một giá trị nhất định. Bằng cách này, kết quả tương ứng có thể thu được thông qua các mô hình toán học nhất định, nhưng giả sử đây là trường hợp. không phải vậy, khi thực hiện tính toán một đường cong liên kết nhất định, nếu các LP khác thêm thanh khoản mới thì kết quả tính toán sẽ là kết quả lỗi thời, điều này rõ ràng là không thể chấp nhận được.
Nhưng kiến trúc này cũng có những hạn chế rõ ràng, đó là nút cổ chai của TPS, và nút cổ chai này dường như đã rất cũ trong các bộ xử lý đa lõi hiện tại, giống như bạn Nếu bạn sử dụng PC mới nhất để chơi một số trò chơi máy tính cũ, chẳng hạn như Red Alert, khi số lượng đơn vị chiến đấu đạt đến một con số nhất định, bạn vẫn sẽ thấy trò chơi bị kẹt.
Bạn có thể nghe nói rằng một số giao thức đã chú ý đến vấn đề này và đã đề xuất các giải pháp song song của riêng họ. Sử dụng Solana, hiện được cho là có TPS cao nhất, như một ví dụ, nó cũng có Khả năng thực thi song song. Tuy nhiên, ý tưởng thiết kế của nó khác với TON. Ở Solana, ý tưởng cốt lõi của nó là chia tất cả các giao dịch thành nhiều nhóm theo sự phụ thuộc thực thi và không có dữ liệu trạng thái nào được chia sẻ giữa các nhóm khác nhau. Tức là không có sự phụ thuộc giống hệt nhau nên các giao dịch trong các nhóm khác nhau có thể được thực hiện song song mà không lo xảy ra xung đột, trong khi các giao dịch trong cùng một nhóm vẫn được thực hiện theo cách nối tiếp truyền thống.
Trong TON, nó hoàn toàn từ bỏ kiến trúc thực thi nối tiếp và thay vào đó áp dụng mô hình phát triển được thiết kế đặc biệt cho tính song song, mô hình Actor để tạo lại môi trường thực thi Bản dựng. Cái gọi là mô hình Actor được Carl Hewitt đề xuất lần đầu tiên vào năm 1973 để giải quyết sự phức tạp của trạng thái chia sẻ trong các chương trình đồng thời truyền thống thông qua việc truyền tin nhắn. Mỗi Actor có trạng thái và hành vi riêng và không có thông tin trạng thái nào được chia sẻ với các Actor khác. Mô hình Actor là một mô hình tính toán điện toán đồng thời thực hiện tính toán song song thông qua việc truyền thông điệp. Trong mô hình này, "Tác nhân" là đơn vị công việc cơ bản, có thể xử lý các tin nhắn đã nhận, tạo Tác nhân mới, gửi thêm tin nhắn và quyết định cách trả lời các tin nhắn tiếp theo. Mô hình Diễn viên cần có các đặc điểm sau:
Tính đóng gói và tính độc lập: Mỗi Diễn viên là Họ hoàn toàn độc lập khi xử lý tin nhắn và các tin nhắn có thể được xử lý song song mà không gây nhiễu lẫn nhau.
Truyền tin nhắn: Các tác nhân chỉ tương tác với nhau bằng cách gửi và nhận tin nhắn, còn việc truyền tin nhắn là không đồng bộ.
Cấu trúc động: Actor có thể tạo ra nhiều Actor hơn trong thời gian chạy. Động lực này cho phép mô hình Actor mở rộng hệ thống khi cần thiết.
TON áp dụng kiến trúc này để thiết kế các mô hình hợp đồng thông minh, có nghĩa là trong TON, mỗi hợp đồng thông minh là một mô hình Actor với không gian lưu trữ hoàn toàn độc lập. Bởi vì nó không dựa vào bất kỳ dữ liệu bên ngoài nào. Ngoài ra, các lệnh gọi đến cùng một hợp đồng thông minh vẫn được thực hiện theo thứ tự tin nhắn trong hàng đợi nhận, do đó các giao dịch trong TON có thể được thực hiện song song một cách hiệu quả mà không lo xung đột.
Tuy nhiên, kế hoạch thiết kế như vậy cũng mang lại một số tác động 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ỡ, như sau:
1. Lệnh gọi không đồng bộ giữa các hợp đồng thông minh: 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 các hợp đồng thông minh của TON. Chúng tôi biết rằng trong Solidity, rất dễ dàng để gọi. chức năng 2 của hợp đồng B trong chức năng 1 của hợp đồng A hoặc để truy cập dữ liệu trạng thái nhất định thông qua chức năng chỉ đọc 3 của hợp đồng C. Toàn bộ quá trình là nguyên tử và được thực hiện trong một giao dịch, tuy nhiên, trong TON, điều này sẽ không xảy ra. có thể, mọi tương tác 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 đóng gói các giao dịch mới. Các giao dịch như vậy do hợp đồng thông minh khởi tạo còn được gọi là tin nhắn nội bộ. Và nó không thể bị chặn trong quá trình thực thi để có được kết quả thực thi. Ví dụ: nếu chúng tôi phát triển DEX, nếu chúng tôi áp dụng mô hình chung trong EVM, thì thường sẽ có một hợp đồng bộ định tuyến thống nhất để quản lý định tuyến giao dịch và mỗi hợp đồng sẽ Nhóm sẽ quản lý riêng dữ liệu LP liên quan đến một cặp giao dịch nhất định, giả sử rằng hiện có hai nhóm USDT-DAI và DAI-ETH. Khi người dùng muốn mua ETH trực tiếp thông qua USDT, họ có thể tuần tự yêu cầu hai nhóm này trong một giao dịch thông qua hợp đồng bộ định tuyến để hoàn thành giao dịch nguyên tử. Tuy nhiên, việc triển khai trong TON không dễ dàng như vậy. Chúng ta cần nghĩ đến một mô hình phát triển mới. Nếu chúng ta vẫn sử dụng lại mô hình này, luồng thông tin có thể giống như thế này. Yêu cầu này sẽ đi kèm với một thông báo bên ngoài do người dùng khởi tạo. và ba thông báo nội bộ đã được hoàn thành (lưu ý rằng điều này được sử dụng để minh họa sự khác biệt. Trong quá trình phát triển thực tế, ngay cả mô hình của ERC20 cũng sẽ phải được thiết kế lại).

2. Cần xem xét kỹ quá trình xử lý lỗi thực thi khi gọi qua các hợp đồng và thiết kế hàm thoát tương ứng cho mỗi lệnh gọi giữa các hợp đồng. Chúng tôi biết rằng trong EVM chính thống, khi gặp sự cố trong quá trình thực hiện giao dịch, toàn bộ giao dịch sẽ bị khôi phục, tức là được đặt lại về trạng thái khi nó được thực hiện ban đầu. Điều này dễ hiểu trong mô hình đơn luồng nối tiếp. Tuy nhiên, trong TON, do lệnh gọi giữa các hợp đồng được thực hiện không đồng bộ, ngay cả khi xảy ra lỗi ở một số liên kết tiếp theo, vì giao dịch được thực hiện thành công trước đó đã được thực hiện và xác nhận, điều này có thể gây ra sự cố. Do đó, một loại thông báo đặc biệt được thiết lập trong TON, được gọi là thông báo trả lại. Nghĩa là, khi xảy ra lỗi trong quá trình thực thi tiếp theo được kích hoạt bởi một thông báo nội bộ, hợp đồng được kích hoạt có thể kích hoạt một sự kiện nhất định trong hợp đồng thông qua chức năng trả lại. được bảo lưu bởi hợp đồng kích hoạt Một số trạng thái được đặt lại.

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

Trong mô hình này, A và B tương ứng đại diện cho hai hợp đồng thông minh và có mối quan hệ về thời gian sao cho nếu msg1_lt < msg2_lt thì tx1_lt < tx2_lt.
Tuy nhiên, trong những tình huống phức tạp hơn, quy tắc này sẽ bị phá vỡ. Có một ví dụ về điều này trong tài liệu chính thức, 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 đến C. Mặc dù chúng được tạo theo thứ tự chính xác (đầu tiên là msg1, sau đó là msg2), chúng ta không thể chắc chắn rằng msg1 sẽ được xử lý trước msg2. Điều này là do các tuyến đường từ A đến B và từ A đến C có thể khác nhau về độ dài và bộ trình xác thực. Nếu các hợp đồng này nằm trên các chuỗi phân đoạn khác nhau, một trong các tin nhắn có thể mất vài khối để đến được hợp đồng mục tiêu. Nghĩa là, chúng ta có hai đường giao dịch khả thi, như trong hình.

4. Trong TON, việc lưu trữ liên tục hợp đồng thông minh của nó sử dụng biểu đồ chu kỳ có hướng với Ô làm đơn vị làm cấu trúc dữ liệu. Dữ liệu sẽ được nén gọn vào Ô theo quy tắc mã hóa. Đồng thời, nó mở rộng xuống dưới dạng biểu đồ chu kỳ có hướng, khác với tổ chức cấu trúc dựa trên hashmap của dữ liệu trạng thái trong EVM. Do các thuật toán yêu cầu dữ liệu khác nhau, TON đặt giá Gas khác nhau cho các độ sâu khác nhau của dữ liệu. xử lý càng sâu thì Gas cần thiết để xử lý dữ liệu Cell càng cao, do đó có một mô hình tấn công DOS trong TON, tức là một số người dùng độc hại chiếm giữ tất cả các Cell nông trong một hợp đồng thông minh nhất định bằng cách gửi một số lượng lớn tin nhắn rác. , đồng nghĩa với việc tính trung thực Chi phí lưu trữ của người dùng sẽ ngày càng cao hơn. Trong EVM, vì độ phức tạp truy vấn của hashmap là o(1), nên nó có cùng Gas và sẽ không có vấn đề tương tự. Do đó, các nhà phát triển TON Dapp nên cố gắng tránh các loại dữ liệu không giới hạn trong hợp đồng thông minh. Khi các loại dữ liệu không giới hạn xuất hiện, chúng sẽ được chia nhỏ thông qua phân đoạn.

5. Ngoài ra còn có một số tính năng ít đặc biệt hơn. Ví dụ: hợp đồng thông minh cần trả tiền thuê dung lượng lưu trữ, hợp đồng thông minh có thể nâng cấp tự nhiên bằng TON và chức năng tài khoản trừu tượng gốc, nghĩa là, trong TON Tất cả các địa chỉ ví trong đều là hợp đồng thông minh, nhưng chưa được khởi tạo, v.v. Các nhà phát triển cần hết sức chú ý đến những điều này.
Trên đây là một số kinh nghiệm của tôi khi học các công nghệ liên quan đến TON trong giai đoạn này. Tôi muốn chia sẻ với các bạn. Tôi hy vọng các bạn có thể sửa cho tôi nếu có. Đồng thời, tôi tin rằng với nguồn lưu lượng truy cập khổng lồ của Telegram, hệ sinh thái TON chắc chắn sẽ mang lại một số ứng dụng mới cho Web3. Những người bạn quan tâm đến việc phát triển TON DApp cũng có thể liên hệ với tôi để thảo luận với chúng tôi.