Cách STONfi Xử Lý Địa Chỉ Bounceable và Non-Bounceable Trên TON
Địa chỉ TON có thể trông khác nhau nhưng vẫn trỏ đến đúng cùng một tài khoản trên chuỗi khối.
Một ví dụ phổ biến là sự khác biệt giữa một địa chỉ bắt đầu bằng EQ... và một địa chỉ bắt đầu bằng UQ.... Loại đầu tiên là cách biểu diễn quen thuộc dạng thân thiện có thể bounce, trong khi loại thứ hai là cách biểu diễn không thể bounce. Mặc dù có khác biệt về tiền tố, cả hai vẫn có thể xác định cùng một tài khoản TON cơ sở vì chính tài khoản được xác định bởi workchain và mã định danh tài khoản 256-bit. Sự phân biệt “bounceable” hay “non-bounceable” được mã hóa dưới dạng siêu dữ liệu trong biểu diễn dạng thân thiện với người dùng, thay vì tạo ra một tài khoản khác.
Sự khác biệt này đặc biệt quan trọng khi tương tác với các giao thức DeFi như STONfi, nơi một giao dịch swap đơn lẻ có thể liên quan đến nhiều địa chỉ TON và nhiều lớp tin nhắn hợp đồng.
Hiểu chính xác tiền tố địa chỉ có ý nghĩa gì sẽ giúp bạn hiểu dễ hơn vì sao STONfi có thể làm việc với nhiều biểu diễn địa chỉ khác nhau mà không coi chúng là các đích đến khác nhau.
Phân biệt quan trọng đầu tiên: Danh tính địa chỉ vs. Hành vi của tin nhắn
Cách dễ nhất để hiểu địa chỉ TON là tách bạch “đích đến là ai” khỏi “tin nhắn sẽ cư xử thế nào khi được gửi tới đó”.
Một địa chỉ thân thiện với người dùng trên TON chứa nhiều phần thông tin. Trong đó có mã định danh workchain, mã định danh tài khoản, và các cờ mô tả cách địa chỉ dự định được xử lý. Cụ thể, các cờ mã hóa việc một tin nhắn nên được gửi theo dạng bounceable hay non-bounceable.
Điều đó có nghĩa là tiền tố hiển thị không chỉ đơn thuần là một định danh tài khoản thay thế.
Ví dụ:
EQ... → biểu diễn thân thiện bounceable
UQ... → biểu diễn thân thiện non-bounceable
Khi workchain nền tảng và ID tài khoản giống nhau, đây là hai cách biểu diễn của cùng một tài khoản.
Các tiện ích địa chỉ của TON có thể chuyển đổi một địa chỉ sang dạng thô (raw), dạng bounceable và dạng non-bounceable, đây cũng là một cách khác để chứng minh rằng đây là các cách biểu diễn khác nhau của cùng một đích đến nền tảng chứ không phải hai ví riêng biệt.
Đây là một trong những khái niệm quan trọng nhất cho nhà phát triển xây dựng trên TON:
Đừng so sánh tiền tố hiển thị khi bạn cố xác định xem hai địa chỉ có trỏ tới cùng một tài khoản hay không. Hãy phân tích địa chỉ và so sánh các thành phần địa chỉ nền tảng.
“Bounceable” Thực Sự Có Nghĩa Là Gì?
Bounceability về bản chất là vấn đề cách xử lý tin nhắn.
Các tin nhắn nội bộ của TON chứa một cờ bounce. Khi một tin nhắn bounceable được chuyển tới đích đến và quá trình xử lý thất bại trong các điều kiện mà việc bounce được hỗ trợ, giá trị còn lại có thể được trả lại về phía người gửi. Hướng dẫn hợp đồng thông minh của TON khuyến nghị dùng tin nhắn bounceable cho hầu hết các tương tác vì chúng cung cấp sự bảo vệ trước một số lỗi của đích đến hoặc lỗi thực thi.
Điểm quan trọng là một tài khoản không vĩnh viễn trở thành “tài khoản bounceable” hay “tài khoản non-bounceable”.
Thay vào đó, biểu diễn địa chỉ thân thiện với người dùng chứa một cờ mà phần mềm có thể dùng khi tạo tin nhắn gửi đi.
Tài liệu TON liệt kê các định dạng thân thiện của mainnet như:
E... cho các địa chỉ bounceable
U... cho các địa chỉ non-bounceable
Vì vậy, cùng một tài khoản có thể được biểu diễn dưới cả hai dạng.
Vì vậy, khi ai đó đổi một địa chỉ từ EQ... sang UQ..., họ không hề chuyển tiền, không tạo ví thứ hai, và cũng không thay đổi chính tài khoản.
Chúng đã thay đổi biểu diễn thân thiện và ưu tiên bounce đi kèm.
Vì sao TON cần các địa chỉ non-bounceable?
Câu trả lời sẽ rõ ràng hơn khi ta xem xét việc khởi tạo tài khoản.
TON hỗ trợ các tài khoản hợp đồng mà địa chỉ của chúng có thể được xác định trước khi hợp đồng tương ứng được triển khai. Ví dụ, một hợp đồng ví có thể có một địa chỉ xác định (deterministic) được suy ra từ các tham số khởi tạo của nó, ngay cả trước khi tài khoản được kích hoạt trên chuỗi. Tài liệu TON mô tả rõ các trường hợp nơi một địa chỉ tồn tại như một giá trị tất định trong khi bản thân tài khoản vẫn ở trạng thái “không tồn tại” (nonexist).
Điều này tạo ra một vấn đề cấp vốn quan trọng.
Giả sử bạn muốn gửi TON tới một ví mà địa chỉ của ví đó đã biết nhưng tài khoản của nó vẫn chưa được khởi tạo. Có thể dùng một tin nhắn non-bounceable để cấp vốn cho đích đến đó mà không bị giá trị bị “bounce” trả về, đơn giản vì tài khoản vẫn chưa được khởi tạo.
Vì vậy, các biểu diễn non-bounceable đặc biệt gắn với việc cấp vốn hoặc khởi tạo ví.
Tài liệu của TON khuyến nghị dùng các địa chỉ non-bounceable cho các hợp đồng ví trong các tình huống mà đích đến có thể chưa được khởi tạo, trong khi các tin nhắn bounceable thường được ưu tiên cho các tương tác hợp đồng thông minh khi lần thực thi thất bại cần làm cho giá trị được trả lại.
Ví trên TON là các hợp đồng thông minh
Một khái niệm khác đôi khi gây nhầm lẫn là từ “wallet (ví)”.
Trên TON, một ví không chỉ đơn thuần là một nhãn tài khoản theo nghĩa như tài khoản trên sàn giao dịch tập trung truyền thống. Các ví là các hợp đồng thông minh, và địa chỉ của chúng có thể được suy ra trước khi triển khai.
Đó là lý do có thể biết một ví sẽ tồn tại ở đâu trước khi hợp đồng ví đó thực sự được khởi tạo trên chuỗi.
Quy trình địa chỉ của TON phản ánh sự khác biệt này. Khi ứng dụng ví chuẩn bị thực hiện một thao tác chuyển, nó có thể kiểm tra trạng thái tài khoản của đích đến. Tài liệu TON lưu ý rằng khi đích đến vẫn chưa được khởi tạo, phần mềm ví có thể ép trường bounce của tin nhắn gửi đi về false, về cơ bản ưu tiên giao hàng non-bounceable cho các tình huống khởi tạo. Đối với các đích đến đã được khởi tạo, ví có thể dùng ưu tiên bounce được biểu diễn bởi địa chỉ.
Vì vậy, hành vi thực tế còn tinh vi hơn việc chỉ nói:
“EQ luôn bounce.”
hoặc
“UQ không bounce.”
Tiền tố cung cấp một ưu tiên xử lý tin nhắn, trong khi ứng dụng ví và trạng thái đích đến cũng có thể ảnh hưởng đến cách giao dịch được xây dựng.
STONfi nằm ở đâu trong mô hình này
Một giao dịch swap của STONfi không chỉ đơn giản là một lần chuyển từ ví này sang ví khác.
Một giao dịch swap điển hình có thể liên quan đến nhiều địa chỉ và nhiều tin nhắn:
Ví của bạn → hợp đồng/bộ định tuyến STONfi → hợp đồng token hoặc pool → các đích đến người nhận/hoàn tiền/phần thừa
Tùy thuộc vào thao tác, giao dịch có thể liên quan đến các địa chỉ cho:
Ví của bạn đã được kết nối
Hợp đồng master Jetton
Hợp đồng ví Jetton
Bộ định tuyến STONfi
Hợp đồng pool
Địa chỉ người nhận
Địa chỉ hoàn tiền
Điểm đến địa chỉ thừa
Mỗi địa chỉ có thể xuất hiện ở một lớp khác nhau trong giao dịch.
Điều này quan trọng vì địa chỉ được dùng làm đích nhắm mục tiêu ban đầu của giao dịch không nhất thiết giống với mọi địa chỉ được mang bên trong payload của hợp đồng.
Khi một ví gửi một giao dịch TON Connect chẳng hạn, chính tin nhắn đó có một địa chỉ đích và có thể chứa một payload tùy ý. Sau đó, tương tác hợp đồng có thể mã hóa các giá trị MsgAddress bổ sung bên trong payload đó. Các ví dụ của TON cho thấy mô hình này cho tương tác token và NFT, nơi một tin nhắn hợp đồng có thể chứa các địa chỉ như người sở hữu mới hoặc một đích đến phần thừa.
Chính là kiến trúc này khiến việc xử lý địa chỉ trong một giao dịch swap của STONfi thú vị hơn một cách “chỉ cần gửi từ A tới B”.
Đích nhắm mục tiêu ban đầu chỉ là một phần của giao dịch
Hãy xem phần bắt đầu của một giao dịch swap.
Ví của bạn tạo một tin nhắn ra (outbound) với đích đến ban đầu là hợp đồng STONfi cần nhận và xử lý yêu cầu.
Vì vậy, ví cần có một địa chỉ đích hợp lệ cho hợp đồng đó.
Tuy nhiên, bên trong payload của yêu cầu, giao thức cũng có thể cần biết nơi các tài sản thu được phải được giao, nơi giá trị thừa cần được trả về, hoặc nơi hoàn tiền sẽ được gửi nếu một thao tác cụ thể yêu cầu điều đó.
Những địa chỉ đó được biểu diễn dưới dạng các giá trị địa chỉ TON thông thường trong dữ liệu hợp đồng.
Chúng không nhất thiết được diễn giải theo đúng tiền tố hiển thị mà một người tình cờ thấy trong giao diện ví.
Ở cấp độ giao thức, thông tin quan trọng là chính địa chỉ TON đã được phân tích (parsed) và ngữ nghĩa của tin nhắn gắn với cách địa chỉ đó được sử dụng.
Vì sao STONfi có thể coi EQ... và UQ... là cùng một đích đến
Hãy tưởng tượng tình huống đơn giản sau:
EQxxxxxxxx... và UQxxxxxxxx...
có thể trông như hai chuỗi khác nhau.
Một ứng dụng ngây thơ có thể so sánh chúng như văn bản thô và kết luận rằng chúng mô tả hai ví khác nhau.
Một ứng dụng hiểu TON nên phân tích chúng thành cấu trúc địa chỉ nền tảng của chúng.
Sau khi đã phân tích, ứng dụng có thể nhận diện workchain chung và mã định danh tài khoản.
Vì vậy, mô hình tư duy đúng đắn là:
Biểu diễn thân thiện khác ≠ tài khoản khác.
Nguyên tắc này đặc biệt quan trọng đối với STONfi vì một ứng dụng DeFi có thể nhận địa chỉ từ nhiều ví, SDK, sàn giao dịch, trình khám phá (explorers), hoặc nhà phát triển khác nhau. Các công cụ khác nhau có thể hiển thị cùng một tài khoản bằng các biểu diễn thân thiện khác nhau.
TON thậm chí cung cấp các tiện ích chính thức để phát hiện và giải mã các dạng này thành các thành phần nền tảng.
Điều gì xảy ra với các tham số “to” của STONfi?
Theo hành vi được mô tả cho SDK của STONfi bắt đầu từ v0.5.0, các tham số sinh ra (generated to parameters) sử dụng các biểu diễn bounceable vì các đích đến của giao thức này được kỳ vọng là các hợp đồng đã được khởi tạo, nhằm nhận và thực thi logic.
Thiết kế này phù hợp với hướng dẫn tổng thể về hợp đồng thông minh của TON.
TON khuyến nghị các tin nhắn bounceable cho tương tác hợp đồng thông minh vì, khi phù hợp, tương tác hợp đồng thất bại có thể khiến giá trị của tin nhắn còn lại được trả về thay vì tự biến mất vào một đích đến không dùng được.
Điều này không có nghĩa là mọi địa chỉ liên quan trong một giao dịch STONfi đều phải bắt đầu bằng EQ một cách trực quan.
Điều đó có nghĩa là tin nhắn và tương tác hợp đồng phải dùng hành vi bounce phù hợp cho vai trò mà địa chỉ đó đảm nhận.
Sự khác biệt đó là then chốt.
Một hợp đồng giao thức nhận một thao tác khác với việc một tài khoản ví được khởi tạo lần đầu.
Địa chỉ Người nhận, Hoàn tiền và Phần thừa
Một trong những sai lầm dễ mắc nhất của nhà phát triển là cho rằng mọi địa chỉ trong một giao dịch swap đều là cùng một kiểu đích đến.
Không phải.
Một giao dịch swap có thể liên quan đến các vai trò địa chỉ khác nhau với mục đích khác nhau.
Người nhận
Người nhận xác định nơi cuối cùng tài sản thu được sẽ được giao tới.
Hoàn tiền
Địa chỉ hoàn tiền có thể được dùng khi một thao tác cần trả giá trị về người dùng khởi phát hoặc một đích đến được chỉ định khác.
Phần thừa
Đích đến phần thừa được dùng cho phần giá trị còn lại sau khi chi phí hoặc số lượng thực thi yêu cầu đã được xử lý.
Các địa chỉ này có thể đi qua giao thức dưới dạng các giá trị TON MsgAddress được nhúng trong payload.
Đó là lý do việc chỉ nhìn địa chỉ đầu tiên trong giao dịch ví không cho bạn biết hết những gì đang diễn ra bên trong giao dịch swap.
Vì sao nhà xây dựng nên phân tích địa chỉ thay vì so sánh chuỗi
Đối với nhà phát triển, đây có thể là bài học thực tế nhất trong tất cả.
Đừng xây dựng logic như:
nếu (addressA === addressB)
khi các giá trị đó có thể là những cách biểu diễn thân thiện khác nhau của cùng một người dùng.
Thay vào đó, hãy phân tích cả hai giá trị thành các đối tượng TON Address đúng chuẩn và so sánh danh tính nền tảng của chúng.
Các thư viện trong hệ sinh thái TON được thiết kế để chuyển đổi giữa các biểu diễn thô và thân thiện. Tài liệu của TON mô tả rõ việc chuyển đổi giữa các dạng raw, bounceable và non-bounceable, trong khi hướng dẫn bảo mật cảnh báo nhà phát triển phải xử lý đúng nhiều biểu diễn địa chỉ của TON.
Ứng dụng cần quan tâm đến:
workchain + định danh tài khoản
thay vì:
EQ vs UQ
như một tiền tố văn bản.
Điều này đặc biệt quan trọng cho lập chỉ mục, cache, lưu trữ cơ sở dữ liệu, theo dõi danh mục, xác thực người nhận, phân tích, và tích hợp giao thức.
Một Mô hình Tư duy Hữu ích
Cách dễ nhất để ghi nhớ toàn bộ hệ thống là nghĩ rằng địa chỉ TON có hai lớp.
Lớp 1: Tài khoản
Đây là danh tính nền tảng:
Workchain + ID tài khoản 256-bit
Điều đó xác định đích đến tài khoản.
Lớp 2: Biểu diễn thân thiện với người dùng
Đây là cách tài khoản đó được mã hóa cho con người và phần mềm:
Các biến thể Raw / Bounceable / Non-bounceable / Testnet
Biểu diễn thân thiện bổ sung siêu dữ liệu, bao gồm bounceability và thông tin testnet, cùng với một mã kiểm tra (checksum).
Vì vậy, hai chuỗi thân thiện có thể mô tả cùng một tài khoản nền tảng.
Đó chính là lý do tại sao một biểu diễn EQ... và một biểu diễn UQ... không nên tự động được xem như hai ví khác nhau.
Người dùng nên làm gì trước một giao dịch swap STONfi
Đối với người dùng STONfi hằng ngày, cách an toàn nhất lại đơn giản một cách đáng ngạc nhiên.
Hãy dùng địa chỉ được cung cấp bởi ví của bạn hoặc công cụ TON bạn tin cậy, thay vì tự chỉnh sửa thủ công các tiền tố.
Đừng đổi EQ sang UQ, hoặc UQ sang EQ, chỉ vì một ứng dụng khác hiển thị địa chỉ theo cách khác.
Quan trọng hơn, luôn xác minh đích đến thực tế, mạng, số lượng và chi tiết giao dịch trước khi ký.
Các ví TON và ứng dụng TON Connect đã hiểu các địa chỉ thân thiện với người dùng và hành vi đi kèm. Ví dụ, tài liệu TON Connect mong đợi các địa chỉ thân thiện cho các tin nhắn giao dịch và cung cấp các tiện ích để hiển thị địa chỉ ví đã kết nối.
Nói cách khác, người dùng thường không cần tự quản lý các cờ bounce khi dùng một ví tích hợp đúng cách và giao diện giao thức phù hợp.
Những điều nhà xây dựng cần rút ra
Đối với nhà phát triển tích hợp STONfi hoặc xây dựng ứng dụng trên TON, việc chuẩn hóa địa chỉ nên được xem là một phần cốt lõi của quá trình tích hợp, thay vì là một trường hợp biên (edge case).
Một triển khai bền vững nên:
Phân tích địa chỉ trước khi so sánh chúng.
Không bao giờ cho rằng hai chuỗi khác nhau thì tương ứng với hai tài khoản khác nhau.
Giữ thông tin workchain.
Mã định danh tài khoản phải được hiểu cùng với workchain đúng. Hướng dẫn bảo mật của TON đặc biệt khuyến nghị xác thực chuỗi địa chỉ khi xử lý địa chỉ.
Hiểu sự khác nhau giữa một tài khoản và một tin nhắn.
Bounceability mô tả cách một tin nhắn nên cư xử; nó không phải là một thuộc tính vĩnh viễn tạo ra tài khoản thứ hai.
Sử dụng tin nhắn bounceable cho các tương tác hợp đồng phù hợp.
Các thao tác hợp đồng thông minh nhìn chung sẽ được hưởng lợi từ việc giao hàng bounceable khi lần thực thi thất bại cần trả lại phần giá trị còn lại.
Sử dụng giao hàng non-bounceable khi việc khởi tạo hoặc cấp vốn cần đến nó.
Ví mới hoặc hợp đồng ví chưa được khởi tạo là trường hợp kinh điển.
Hãy để các SDK đáng tin cậy xử lý các chi tiết biểu diễn.
Mục đích của một SDK không chỉ là làm cho việc gọi hợp đồng dễ hơn, mà còn là giảm số lượng những sai lầm xử lý địa chỉ ở mức thấp mà nhà phát triển có thể mắc phải.
Bức tranh tổng thể cho STONfi
Khi TON DeFi ngày càng tinh vi hơn, các giao dịch ngày càng liên quan đến nhiều hợp đồng thay vì chỉ là chuyển khoản đơn giản từ ví này sang ví khác.
Các giao dịch swap của STONfi là một ví dụ tốt.
Người dùng có thể chỉ thấy:
“Swap token A lấy token B.”
Chỉ đằng sau một giao diện đơn giản như vậy, blockchain có thể đang phối hợp các tin nhắn của ví, bộ định tuyến, ví Jetton, hợp đồng pool, các điểm đến người nhận và cơ chế trả lại giá trị.
Vì vậy, việc xử lý địa chỉ đúng đắn trở thành một phần của độ tin cậy của giao thức.
Sự khác biệt giữa EQ... và UQ... có thể trông có vẻ mang tính thẩm mỹ đối với người dùng, nhưng ở cấp độ giao thức nó thể hiện một khác biệt có ý nghĩa trong cách xây dựng tin nhắn.
Trong khi đó, sự khác biệt này không bao giờ được che khuất sự thật nền tảng:
Tiền tố không tự động có nghĩa là có hai tài khoản khác nhau.
Cùng một tài khoản TON có thể có nhiều cách biểu diễn thân thiện khác nhau, trong khi tin nhắn gửi tới tài khoản đó có thể mang các hành vi bounce khác nhau tùy thuộc vào cách địa chỉ được mã hóa và cách giao dịch được xây dựng.
Kết luận cuối cùng
Hệ thống địa chỉ của TON mạnh mẽ chính vì nó tách bạch danh tính tài khoản khỏi biểu diễn hướng tới người dùng.
Một địa chỉ EQ... và một địa chỉ UQ... có thể cùng trỏ tới một tài khoản nền tảng. Danh tính quan trọng là workchain cộng với mã định danh tài khoản; tiền tố thân thiện bổ sung thông tin xử lý như bounceability.
Đối với người dùng STONfi, điều này có nghĩa là bạn không cần lo lắng nếu một ví hoặc ứng dụng đáng tin cậy hiển thị địa chỉ của bạn ở một dạng hợp lệ khác.
Đối với nhà xây dựng, bài học còn quan trọng hơn:
Phân tích địa chỉ TON. Chuẩn hóa chúng. So sánh danh tính nền tảng của chúng. Và chọn hành vi bounce theo vai trò của đích đến cũng như mục đích của tin nhắn.
Khi mô hình đó đã rõ, việc xử lý địa chỉ của STONfi sẽ dễ hiểu hơn rất nhiều.
Lần tới khi bạn thấy một địa chỉ EQ... và UQ..., đừng lập tức nghĩ “hai ví”.
Hãy nghĩ:
cùng là có thể tới một đích đến, nhưng biểu diễn khác nhau, ưu tiên xử lý tin nhắn khác nhau.
Sự khác biệt đó nhỏ ở cấp độ giao diện, nhưng lại là nền tảng khi xây dựng các ứng dụng đáng tin cậy trên TON.
Khám phá thêm trên STON.FI app.ston.fi
Xem thêm về STONfi tại BLOG.STON.FI