Việc chuyển tài sản giữa các mạng blockchain phức tạp hơn so với trao đổi hai token trên cùng một mạng. Mỗi blockchain duy trì sổ cái riêng, thực thi giao dịch riêng và tuân theo các quy tắc riêng.
Do đó, một giao dịch trên mạng này không tự động hoàn tất giao dịch tương ứng trên mạng khác.
Đây là vấn đề mà cơ sở hạ tầng thực thi xuyên chuỗi hướng đến giải quyết.
STON.fi giải quyết thách thức này thông qua Omniston, một lớp thực thi xuyên chuỗi được thiết kế để điều phối việc trao đổi tài sản giữa các mạng blockchain được hỗ trợ.

Thay vì yêu cầu người dùng tự điều phối thủ công các giao dịch riêng lẻ, Omniston kết hợp việc tìm báo giá, nhà cung cấp thanh khoản, thực thi giao dịch và thanh toán trong một quy trình được điều phối.
Hiểu cách các thành phần này phối hợp với nhau sẽ giúp giải thích cả lợi ích lẫn rủi ro của giao dịch hoán đổi xuyên chuỗi.
1. Yêu cầu báo giá: Tìm tuyến có thể thực thi
Quy trình bắt đầu khi người dùng chọn tài sản nguồn, tài sản đích và số lượng muốn hoán đổi.
Ví dụ, hãy xét một người dùng muốn hoán đổi USDT trên TON lấy USDG trên Robinhood Chain.
Ứng dụng yêu cầu báo giá cho giao dịch dự kiến.
Omniston sử dụng cơ chế Yêu cầu báo giá (RFQ) để nhận các đề nghị có thể thực thi từ những nhà cung cấp thanh khoản tham gia, được gọi là resolver.
Các resolver này đánh giá giao dịch hoán đổi được yêu cầu và có thể trả về báo giá dựa trên thanh khoản sẵn có, giá cả và điều kiện thực thi của họ.
Sau đó, người dùng có thể xem xét các đề nghị hiện có thông qua ứng dụng.
Điều này quan trọng vì mức giá hiển thị gắn với một đề xuất thực thi, chứ không chỉ là giá thị trường tham khảo.
Báo giá và tuyến hiện có phụ thuộc vào các resolver tham gia, tài sản được hỗ trợ và điều kiện thị trường hiện tại.
2. Cạnh tranh giữa các resolver: Cung cấp thanh khoản phía đích
Resolver là các nhà cung cấp thanh khoản độc lập cạnh tranh để thực hiện những yêu cầu hoán đổi đủ điều kiện.
Mỗi resolver xác định mức giá và điều kiện có thể đưa ra dựa trên các yếu tố như lượng tài sản họ nắm giữ, chi phí vận hành và cặp tài sản được yêu cầu. Đối với giao dịch xuyên chuỗi, resolver có thể cung cấp tài sản phía đích cần thiết để hoàn tất lệnh.
Điều này có nghĩa là ứng dụng không nhất thiết phải tự duy trì lượng dự trữ của mọi tài sản được hỗ trợ trên mọi blockchain.
Thay vào đó, các resolver tham gia có thể cung cấp thanh khoản phía đích khi có lệnh phù hợp.
Sự cạnh tranh giữa các resolver có thể cải thiện giá cả và các lựa chọn thực thi, dù đề nghị tốt nhất hiện có còn tùy thuộc vào những báo giá thực tế nhận được.
Một tuyến cũng có thể không khả dụng nếu không có resolver nào sẵn lòng hoặc có khả năng thực hiện tuyến đó trong những điều kiện chấp nhận được.
3. Điều phối thực thi: Liên kết giao dịch giữa các mạng
Tìm báo giá chỉ là một phần của quy trình. Giao dịch cũng phải được thực hiện trên cả mạng nguồn và mạng đích.
STON.fi mô tả kiến trúc thanh toán xuyên chuỗi của Omniston bằng các Hợp đồng Khóa thời gian Băm (HTLC) được liên kết với nhau.
HTLC là một cơ chế hợp đồng thông minh kết hợp điều kiện mật mã với giới hạn thời gian.

Nói một cách đơn giản, các hợp đồng thiết lập điều kiện để mỗi bên có thể nhận tài sản tương ứng của mình.
Với một giao dịch hoán đổi xuyên chuỗi được hỗ trợ, quy trình có thể bao gồm hai hợp đồng được liên kết:
- Hợp đồng phía nguồn gắn với tài sản của người dùng.
- Hợp đồng phía đích gắn với tài sản của resolver.
Cả hai hợp đồng đều sử dụng cùng một điều kiện băm mật mã và các giới hạn thời gian tương thích.
Điều này liên kết hai phía của giao dịch mà không yêu cầu các blockchain dùng chung một sổ cái.
Các hợp đồng thực thi những điều kiện thanh toán đã quy định trên mạng tương ứng của chúng.
Điểm khác biệt quan trọng: Omniston điều phối giao dịch, trong khi các giao dịch blockchain và hợp đồng thông minh nền tảng thực thi các điều kiện liên quan đến việc thực hiện và thanh toán.
4. Thanh toán nguyên tử: Điều gì xảy ra khi giao dịch hoán đổi hoàn tất?
Thanh toán nguyên tử là trọng tâm trong thiết kế xuyên chuỗi mà Omniston mô tả.
Trong ngữ cảnh này, tính nguyên tử nghĩa là giao dịch được cấu trúc dựa trên các điều kiện liên kết, để việc chuyển tài sản dự kiến có thể hoàn tất ở cả hai phía hoặc các tài sản bị khóa liên quan có thể được hoàn trả.
Quy trình sử dụng một bí mật mật mã có giá trị băm được đưa vào các hợp đồng liên kết.
Khi bí mật cần thiết được tiết lộ và các điều kiện hợp đồng được đáp ứng, bí mật đó cho phép thực hiện các yêu cầu nhận tài sản tương ứng.
Người dùng có thể nhận tài sản ở mạng đích, còn resolver có thể dùng bí mật được tiết lộ để nhận tài sản ở mạng nguồn.
Điều kiện mật mã dùng chung liên kết hai yêu cầu nhận tài sản.
Nếu điều kiện thanh toán cần thiết không được đáp ứng trong khoảng thời gian tương ứng, các hợp đồng sẽ cung cấp phương án hoàn tiền theo quy tắc của chúng.
Thiết kế này nhằm giảm rủi ro một bên đã chuyển tài sản nhưng không nhận được tài sản đối ứng như thỏa thuận.
Tuy nhiên, không nên hiểu thanh toán nguyên tử là sự bảo đảm chống lại mọi tổn thất có thể xảy ra. Lỗ hổng hợp đồng thông minh, lỗi triển khai, gián đoạn mạng và các rủi ro kỹ thuật khác vẫn có thể ảnh hưởng.
Người dùng nên tìm hiểu cách triển khai thực tế của giao thức và trạng thái giao dịch thay vì chỉ dựa vào từ "nguyên tử".
5. Ví dụ thực tế: USDT trên TON sang USDG trên Robinhood Chain
Hãy xét một người dùng đang nắm giữ USDT trên TON và muốn nhận USDG trên Robinhood Chain.
Quy trình dự kiến minh họa cách các thành phần khác nhau kết hợp với nhau.
Bước 1: Chọn tài sản.
Người dùng chọn USDT trên TON làm tài sản nguồn và USDG trên Robinhood Chain làm tài sản đích, với điều kiện ứng dụng đang hoạt động hỗ trợ chính xác tuyến này.
Bước 2: Yêu cầu báo giá.
Ứng dụng yêu cầu một đề nghị có thể thực thi cho tài sản và số lượng đã chọn.
Bước 3: Xem xét đề nghị.
Người dùng xem xét số lượng dự kiến nhận, các khoản phí áp dụng và điều kiện thực thi trước khi cho phép giao dịch.
Bước 4: Điều phối thực thi.
Nếu người dùng tiếp tục và tuyến được chấp nhận, quy trình thực thi liên quan sẽ điều phối phía nguồn và phía đích theo cơ chế thanh toán của giao thức.
Bước 5: Hoàn tất hoặc khôi phục tài sản.
Nếu giao dịch hoán đổi được thanh toán thành công, người dùng sẽ nhận tài sản đích theo các điều kiện đã thỏa thuận. Nếu quá trình thực thi không hoàn tất, cơ chế hoàn tiền áp dụng của giao thức sẽ xác định cách khôi phục các tài sản bị khóa.
Quy trình cụ thể phụ thuộc vào tuyến được chọn và cách triển khai.

Ví dụ USDT sang USDG chỉ nhằm minh họa: người dùng phải xác minh cặp tài sản cụ thể này hiện có trên giao diện STON.fi đang hoạt động trước khi thử hoán đổi.
6. Vì sao kiến trúc này quan trọng
Phương pháp của Omniston phân tách một số trách nhiệm vốn thường do các hệ thống khác nhau đảm nhiệm.
Việc tìm báo giá giúp xác định các đề nghị thực thi hiện có.
Sự cạnh tranh giữa các resolver đưa các nhà cung cấp thanh khoản vào quy trình.
Điều phối thực thi kết nối hai phía nguồn và đích của giao dịch.
Thanh toán bằng hợp đồng thông minh thực thi các điều kiện để tài sản có thể được nhận hoặc hoàn trả.
Việc kết hợp các chức năng này có thể đơn giản hóa trải nghiệm của người dùng và giảm nhu cầu để ứng dụng xây dựng hạ tầng riêng cho từng tuyến được hỗ trợ.
Điều này cũng có thể giúp các bên tích hợp cung cấp chức năng xuyên chuỗi mà không phải tự duy trì thanh khoản phía đích cho từng giao dịch.
Lợi ích phụ thuộc vào việc tuyến có thực sự được hỗ trợ hay không, sự tham gia của resolver và độ tin cậy của các hợp đồng nền tảng.
7. Rủi ro và hạn chế
Dù Omniston được thiết kế để điều phối việc thực thi xuyên chuỗi, người dùng vẫn cần hiểu các rủi ro.
Thanh khoản và giá: Sự cạnh tranh giữa các resolver không đảm bảo mức giá thị trường tốt nhất có thể trong mọi trường hợp. Các đề nghị hiện có phụ thuộc vào nhà cung cấp tham gia và điều kiện hiện tại.
Tính khả dụng của tuyến: Không phải cặp tài sản hay tổ hợp mạng nào cũng được hỗ trợ. Tuyến có thể không khả dụng khi thanh khoản hoặc năng lực thực thi không đủ.
Rủi ro hợp đồng thông minh: Các hợp đồng được liên kết có thể giảm một số rủi ro thanh toán, nhưng không loại bỏ được lỗ hổng hay lỗi triển khai.
Điều kiện mạng: Tắc nghẽn, sự cố ngừng hoạt động và giao dịch bị trì hoãn có thể ảnh hưởng đến việc thực thi cũng như thời gian cần thiết để xử lý một giao dịch hoán đổi chưa hoàn tất.
Điều kiện báo giá: Người dùng nên xem xét báo giá thực tế, các khoản phí và điều kiện thực thi áp dụng trước khi ký.
Điều kiện khôi phục: Việc hoàn tiền phụ thuộc vào quy tắc của hợp đồng, giới hạn thời gian và trạng thái giao dịch.
Người dùng nên hiểu rõ các điều kiện này thay vì cho rằng mọi giao dịch thất bại đều được hoàn tiền ngay lập tức.
Hiểu rõ những hạn chế này là điều thiết yếu khi đánh giá bất kỳ hệ thống thực thi xuyên chuỗi nào.
Omniston điều phối các giao dịch hoán đổi xuyên chuỗi bằng cách kết hợp việc tìm báo giá, thanh khoản do resolver cung cấp, điều phối thực thi và thanh toán bằng hợp đồng thông minh.

Cơ chế RFQ cho phép các resolver tham gia đề xuất những giao dịch có thể thực thi. Kiến trúc xuyên chuỗi của Omniston sử dụng các HTLC được liên kết để thiết lập điều kiện thanh toán hoặc khôi phục tài sản trên các mạng tham gia. Với người dùng, mục tiêu rất đơn giản: đổi tài sản trên một blockchain được hỗ trợ lấy tài sản trên một blockchain khác mà không cần tự điều phối mọi thao tác nền tảng. Với nhà phát triển, kiến trúc này cung cấp cách tích hợp việc thực thi xuyên chuỗi mà không cần tự xây dựng từng thành phần của quy trình định tuyến và thanh toán.
Bài học rộng hơn là hạ tầng xuyên chuỗi không chỉ đơn thuần là chuyển token giữa các mạng. Hạ tầng này đòi hỏi phải điều phối thanh khoản, giá cả, việc thực thi giao dịch và các điều kiện khôi phục giữa những hệ thống hoạt động độc lập.
Tìm hiểu thêm tại: https://ston.fi/cross-chain-swap-from-ton-to-base
Tìm hiểu cơ chế.
Xác minh tuyến.
Hiểu rõ các rủi ro trước khi giao dịch.
Tài liệu chính thức:
“Tổng quan về thực thi xuyên chuỗi” của Omniston (https://ston.fi/omniston)
“Tài liệu kỹ thuật về Omniston” của STON.fi (https://docs.ston.fi/developer-section/omniston)
“Giải thích về thực thi xuyên chuỗi” của STON.fi (https://blog.ston.fi/omniston-explained-how-cross-chain-swaps-on-ton-work-without-a-bridge/)
