Tác giả gốc: @Web3 Mario
Giới thiệu: Với sự ra mắt của Notcoin, trò chơi lớn nhất trong hệ sinh thái TON, trên Binance và 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 hoàn toàn mang lại, 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
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ừ 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ì vậy, vì nó được thiết kế như một môi trường thực thi phi tập trung cho Telegram, nên đương nhiên 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, Solana, được coi là TPS cao nhất, có TPS đo được cao nhất là 65.000, rõ ràng là không đủ để hỗ trợ hệ sinh thái Telegram đò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 sử dụng "Mô hình phân chia vô hạn" để thiết kế hệ thống, 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 đề tắc nghẽn 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ể;
Tạo chuỗi blockchain - thông qua khả năng phân chia không giới hạn, mỗi tài khoản có một chuỗi tài khoản độc quyền
Bây 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 nhằm 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 sharding vô hạn, cái gọi là mô hình sharding vô hạn Đề cập đến việc cho phép blockchain thực hiện. 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 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.
Để hiểu nó một cách trừu tượng, có bốn cấp độ cấu trúc chuỗi trong TON:
Chuỗi tài khoản: Chuỗi lớp này đại diện cho một chuỗi bao gồm một loạt 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 thi nhất quán, máy trạng thái sẽ The. kết quả 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 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.
Chuỗi phân đoạn: 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à tập hợp các 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 phân mảnh với các quy tắc tùy chỉnh, chẳng hạn như tạo chuỗi công 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 từ những người xác thực để phê duyệt việc tạo chuỗi làm việc của bạn.
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 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:
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 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à về mặt lý thuyết có thể đạt tới lũy thừa thứ 2 đến thứ 60 của chuỗi công việc.
Khả năng thích ứng: Khi tải tăng trên một phần của mạng, phần đó 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ả.
Sau đó, đ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 đề liên lạc 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, thông tin sẽ được định tuyến giữa các chuỗi. sẽ trở thành một việc khó thực hiệ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 cụ thể trong TON bằng cách giám sát các thông báo 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ế bài toá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-> chuỗi công việc 3 và chuỗi công việc 1 -> chuỗi công việc 4 -> chuỗi công việc 3.
Khi đối mặt với các 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 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 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 hợp lệ về một đường dẫn định tuyến nhất định, thường là gốc trie merkle, nút có thể trực tiếp nhận ra độ tin cậy của đường dẫn đó. thông báo do người dùng gửi, điều này còn được gọi là định tuyến hypercube tức thời.
Do đó, 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 thuật toán mã hóa hình elip làm địa chỉ, bởi vì. địa chỉ chỉ được sử dụng làm địa chỉ duy nhất. Nó không cần mang chức năng đánh địa chỉ định tuyến và địa chỉ trong TON bao gồm hai phần, (workchain_id, account_id), trong đó Workchain_id được mã hóa theo địa chỉ thuật toán định tuyến hypercube. sẽ không được trình bày chi tiết ở đây.
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 có mối quan hệ liên kết với từng chuỗi hoạt động, do đó, sẽ không đủ nếu tất cả thông tin chuỗi chéo được chuyển tiếp qua chuỗi chính. 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ẽ chọn ngẫu nhiên một người xác minh đóng gói từ tất cả các Staker trong các khoảng thời gian đều đặn. cluster, các nút được chọn làm trình xác thực sẽ đóng gói và tạo các khối thông qua thuật toán BFT. Nếu họ đóng gói thông tin không chính xác hoặc làm điều xấu, mã thông báo cổ phần của họ sẽ bị mất và nếu không, họ 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 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 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 đơ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àm đầu vào khi nút tạo khối hoàn thành giao dịch bằng cách đóng gói khối Sau khi sắp xếp. , 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. đã xác nhận, kết quả thực hiện sẽ có tính 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, các giao dịch khác không thể thực hiện được. sửa đổi một dữ liệu trạng thái nhất định sẽ được truy cập, để đạ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ư khi bạn sử dụng chiếc 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, When the. số lượng đơn vị chiến đấu đạt đến một mức 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ụ, 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 song song, mô hình Actor, để tái cấu trúc 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 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ó 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:
Đóng gói và độc lập: Mỗi tác nhân hoàn toàn độc lập khi xử lý tin nhắn và có thể xử lý tin nhắn song song mà không can thiệp 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 và việc truyền tin nhắn là không đồng bộ.
Cấu trúc động: Các 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 động này cho phép mô hình Tác nhân mở rộng quy mô 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, sơ đồ 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. Cuộc 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 hợp đồng thông minh của TON. Chúng tôi biết rằng trong Solidity, chức năng 1 của hợp đồng A gọi chức năng 2 của hợp đồng B. Hoặc truy cập dữ liệu trạng thái nhất định. thông qua chức năng chỉ đọc n3 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. 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 đượ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 được sử dụng để quản lý định tuyến giao dịch và mỗi Nhóm quản lý độc lập dữ liệu LP liên quan đến một cặp giao dịch nhất định. hiện tại có hai Pool 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. Cần phải nghĩ đến một mô hình phát triển mới. Nếu mô hình này vẫn được sử dụng lại, luồng thông tin có thể giống như thế này. người dùng và ba tin nhắn nội bộ đã 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 ERC 20 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ế 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 sự kiện nhất định trong hợp đồng bằng cách kích hoạt thông báo trả lại. chức năng được bảo lưu theo hợp đồng. 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 đó mối quan hệ về thời gian này không thể được đặt trước. 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 là nếu tin nhắn 1 _lt < tin nhắn 2 _lt, thì tx 1 _lt < tx 2 _lt.
Tuy nhiên, trong những tình huống phức tạp hơn, quy tắc này 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ộ, tin nhắn 1 và tin nhắn 2: một cho B và một cho C. Mặc dù chúng được tạo theo thứ tự chính xác (đầu tiên là tin nhắn 1 , sau đó là tin nhắn 2 ), chúng tôi không thể chắc chắn rằng tin nhắn 1 sẽ được xử lý trước tin nhắn 2 . Đ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 thành Ô theo quy tắc mã hóa, đồng thời theo quy tắc mã hóa. biểu đồ tuần hoàn có hướng. Cách này kéo dài xuống dưới, khác với cách tổ chức dữ liệu trạng thái dựa trên hashmap. Do các thuật toán yêu cầu dữ liệu khác nhau, TON đặt các mức Gas khác nhau cho các độ sâu xử lý dữ liệu khác nhau. , càng yêu cầu nhiều Gas thì 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 tất cả các ô 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, điều đó có nghĩa là chi phí lưu trữ của người dùng trung thực sẽ ngày càng đắt 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, chẳng hạn như hợp đồng thông minh cần trả tiền thuê kho lưu trữ, hợp đồng thông minh trong TON có thể nâng cấp tự nhiên và các chức năng tài khoản trừu tượng gốc, tức là tất cả các địa chỉ ví trong TON đều là hợp đồng thông minh, chỉ 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.
Trên đây là một số kinh nghiệm của tôi trong việc 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 lỗi cho tôi nếu tôi mắc phải bất kỳ sai sót nào. Đồng thời, tôi nghĩ 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ẽ đóng vai trò là nền tảng cho Web3. Mang đến một số ứng dụng hoàn toàn mới, 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 và thảo luận với chúng tôi.
Liên kết X: https://x.com/web3_mario
Người xử lý Telegram: @MarioChin Web3
