Mô tả chi tiết về các tính năng kỹ thuật và mô hình phát triển hợp đồng thông minh của TON

Tác giả:@Web3Mario

Giới thiệu

Với việc Binance ra mắt Notcoin, trò chơi lớn nhất trong hệ sinh thái TON và toàn bộ Do hiệu ứng giàu có to lớn do mô hình kinh tế mã thông báo lưu thông 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 trả giá bằng khả năng tương tác 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

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 là Nó 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ừ 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 có chứa 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 gian đã đến năm 2018. Để có được nguồn lực cần thiết để triển khai TON, Telegram đã triển khai việc bán token Gram (sau đổi tên thành Toncoin) vào quý 1 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à đóng vai trò là môi trường thực thi phi tập trung của Telegram, nên chúng tôi đương nhiên phải đối mặt với hai vấn đề, yêu cầu đồng thời cao và dữ liệu khổng lồ. Chúng tôi biết rằng với sự phát triển của công nghệ cho đến nay, điều đó đã được biết đến. là TPS cao nhất TPS đo được cao nhất của Solana 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ế.

Do đó, để 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 thiết kế hệ thống sử dụng "Mô hình phân mảnh vô hạn", chúng tôi giải quyết vấn đề dư thừa dữ liệu để nó có thể mang dữ liệu lớn và giảm bớt vấn đề thắt cổ chai về hiệu suất;

• 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 Actor, TPS mạng được cải thiện đáng kể;

Xây dựng chuỗi blockchain - thông qua số điểm không giới hạn Khả năng sharding cho phép mỗi tài khoản có một chuỗi tài khoản độc quyề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í. TON đã đưa điều này đến mức tối đa và đề xuất một mô hình sharding vô hạn. Cái 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 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 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 tính nhất quán nhất định,

• Chuỗi tài khoản: Chuỗi lớp này đại diện cho một chuỗi được cấu thành của 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à các quy tắc thực hiện nhất quán, kết quả mà máy trạng thái thu được sau khi nhận được cùng một chuỗi hướng dẫn là nhất quán, do đó, thứ tự giao dịch theo chuỗi là bắt buộc trong tất cả các hệ thống phân tán blockchain và TON cũng không ngoại lệ. 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 Tiếp theo, chuỗi phân đoạn là thực tế đơn vị thành phần trong TON Cái gọi là chuỗi phân đoạn là tập hợp các chuỗi tài khoản.

• WorkChain: Nó cũng có thể được gọi là một nhóm các quy tắc Xác định cho chuỗi bảo vệ, chẳng hạn như tạo chuỗi làm việc dựa trên EVM và chạy các hợp đồng thông minh Solidity trên đó. 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 Chuỗi được gọi là chuỗi chính và chịu trách nhiệm mang lại tính hữu hạn cho tất cả các chuỗi phân đoạn. Sau khi hàm băm của khối của 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 của 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:

• < p>Phân mảnh động: TON có thể tự động phân tách 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 sharding vô hạn, TON có thể hỗ trợ Về mặt lý thuyết, số lượng phân đoạn gần như không giới hạn có thể đạt từ 2 đến lũy thừa thứ 60 của chuỗi công việc.

• Khả năng thích ứng: Khi tải trên một phần nhất định của mạng tăng lên Phân khúc này có thể được chia thành nhiều phân đoạn hơn để xử lý khối lượng giao dịch tăng lên. 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 sharding không giới hạn. Các phân đoạn trong mạng đạt tới Sau một mức nhất định, 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 rằng có 4 nút trong mạng. Mỗi nút chịu trách nhiệm duy trì một 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 giao dịch trong chuỗi công việc của chính 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 cụ thể 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. 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 -> .

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 để nhanh chóng hoàn thành 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ỳ là 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 3D, đỉ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 Trong giao thức định tuyến hypercube, quy trình định tuyến của tin nhắn từ chuỗi làm việc nguồn đến chuỗi làm việc đích được thực hiện bằng cách so sánh biểu diễn nhị phân của địa chỉ của chuỗi làm việc nguồn và chuỗi làm 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 hợp lệ về một đường dẫn định tuyến nhất định, thường là một gốc merkle trie nhất định, tức là. nút có thể trực tiếp nhận ra nó. Độ tin cậy của các tin nhắn do người dùng gửi, còn được gọi là định tuyến siêu khối tức thời.

Vì vậy, chúng ta có thể thấy rằng có sự khác biệt rõ ràng giữa các địa chỉ trong TON và 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 sử dụng hàm băm tương ứng với khóa chung trong khóa chung và khóa riêng được tạo bởi mã hóa hình elip. thuật toán là Địa chỉ, vì địa chỉ chỉ để phân biệt duy nhất và không cần mang chức năng định tuyến và đánh địa chỉ. Địa chỉ trong TON bao gồm hai phần, (workchain_id, account_id), trong đó Workchain_id được mã hóa theo định tuyến hypercube. địa chỉ thuật toán. Ở đây tôi sẽ không đi vào chi tiết.

Có một điểm khác dễ gây nghi ngờ. Bạn có thể đã 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, vậy thì tất cả thông tin xuyên chuỗi vẫn chưa đủ. được chuyển tiếp qua chuỗi chính? , giống như vũ trụ. 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 việc đóng gói khối, hợp đồng quản trị bầu cử của TON sẽ được chọn từ tất cả Người đặt cược theo định kỳ. . Chọn ngẫu nhiên một cụm trình xác minh được đóng gói và nút được chọn được gọi là trình xác minh sẽ đóng gói 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 của nó sẽ bị mất, nếu không 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.

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 điểm khác biệt khác giữa TON và 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 nó. Để vượt qua những hạn chế của giao thức blockchain chính thống TPS, 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, mang lại cho chúng 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 đơn luồng. Lấy Ethereum làm ví dụ, môi trường thực thi EVM của nó là một máy trạng thái với các giao dịch là đầu vào Khi nút tạo khối Sau các giao dịch. được sắp xếp 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 tại một thời điểm nhất định. miễn là nó được xác nhận Trình tự giao dịch và kết quả thực hiện nhất quán trong nhiều cụm phân tán Đồng thời, vì chỉ có một giao dịch được thực hiện tuần tự cùng một lúc, điều này có nghĩa là trong quá trình thực hiện, không thể có giao dịch nào khác. các giao dịch cần được truy cập Dữ liệu trạng thái được sửa đổi, 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 thắt cổ chai của TPS, và nút cổ chai này xuất hiện rất cũ trong các bộ xử lý đa lõi hiện tại, giống như việc bạn sử dụng một chiếc PC mới nhất để chơi một số trò chơi cũ trong trò chơi máy tính , 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 nó bị kẹt. Đây là một vấn đề với kiến ​​trúc phần mềm.

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ọ. Lấy Solana, hiện được cho là có TPS cao nhất, làm ví dụ. thực hiện 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 song song, mô hình Actor, để tái tạo lại môi trường thực thi. 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 Diễn viên có trạng thái và hành vi riêng và không chia sẻ bất kỳ thông tin trạng thái nào với các Diễn viên 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ó khả năng 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 Actor cần có các đặc điểm sau:

• Tính đóng gói và tính độc lập: Mỗi Actor hoàn toàn độc lập khi xử lý các tin nhắn song song mà không cần. can thiệp lẫn nhau.

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

• Cấu trúc động: Tác nhân có thể tạo ra nhiều Tác nhân hơn trong thời gian chạy. Tính chất năng động này làm cho Mô hình tác nhân kích hoạt hệ thống. để được mở rộ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 bộ 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.< strong>Các cuộc gọi không đồng bộ giữa các thông minh. hợp đồng: 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 của TON. Chúng tôi biết rằng trong Solidity, hợp đồng B được gọi trong chức năng1 của hợp đồng A. chức năng2 hoặc truy cập dữ liệu trạng thái nhất định thông qua hợp đồng. chức năng chỉ đọc3 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 thể thực hiện được. Mọi tương tác với các 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 mới. các giao dịch như vậy được thực hiện bởi hợp đồng thông minh cũng đượ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 Nhóm sẽ quản lý độc lập dữ liệu LP liên quan đến một cặp giao dịch nhất định, thì 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 ERC20 cũng phải được thiết kế lại).

2 .Cần xem xét cẩn thận quá trình xử lý các lỗi thực thi khi gọi qua các hợp đồng và thiết kế các hàm thoát tương ứng cho từng 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 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 ở 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 thông báo 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, do đó không thể đặt trước mối quan hệ về 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 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 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 <

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 cho B và một cho C. Mặc dù chúng được tạo theo thứ tự chính xác (msg1 trước, 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 cá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 theo quy tắc mã hóa. đến biểu đồ tuần hoàn có hướng. Biểu đồ kéo dài xuống dưới.Điều này khác với cách tổ chức cấu trúc dựa trên bản đồ băm 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 xử lý dữ liệu khác nhau. Ô càng sâu thì Gas cần thiết để xử lý dữ liệu càng cao, do đó, có 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 Ô nông trong hợp đồng thông minh bằng cách gửi một số lượng lớn tin nhắn rác, điều đó có nghĩa là người dùng trung thực Chi phí lưu trữ 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ó các tính năng ít đặc biệt hơn, chẳng hạn nhưhợp đồng thông minh yêu cầu thanh toán tiền thuê lưu trữ, hợp đồng thông minh có thể nâng cấp tự nhiên trong TON và chức năng tài khoản trừu tượng gốc, tức là tất cả địa chỉ ví trong TON đều là hợp đồng thông minhchỉ chưa được khởi tạo, v.v. Những điều này đòi hỏi các nhà phát triển phải chú ý cẩn thận.