Omniston xử lý các giao dịch hoán đổi EVM-to-EVM trên STON.fi như thế nào
Giao dịch xuyên chuỗi thường được trình bày như thể việc chuyển một tài sản từ blockchain này sang blockchain khác chỉ đơn giản là hoán đổi hai token trên một sàn giao dịch phi tập trung.
Trên thực tế, quy trình phía sau có thể phức tạp hơn nhiều.
Một giao dịch hoán đổi DEX thông thường thường diễn ra trong một blockchain duy nhất. Thanh khoản nằm trên mạng đó, các giao dịch được thực hiện bởi các hợp đồng trên cùng sổ cái và toàn bộ giao dịch theo môi trường thực thi của một chuỗi.
Giao dịch EVM-to-EVM giữa Ethereum, BNB Chain, Base, Polygon và các mạng khác tạo ra một vấn đề khác: các tài sản được trao đổi tồn tại trên các blockchain tách biệt và không chia sẻ một lịch sử giao dịch chung.
Đây là nơi Omniston của STON.fi đi theo một cách tiếp cận khác.
Thay vì ép giao dịch đi theo một chuỗi cầu nối và swap truyền thống, Omniston coi tương tác này như một lệnh xuyên chuỗi. Hệ thống kết hợp mô hình RFQ (Request for Quote), thanh khoản của các resolver cạnh tranh và các Hashed Timelock Contracts (HTLC) ghép cặp để phối hợp việc thanh toán giữa các mạng EVM độc lập.
Kết quả là một trải nghiệm người dùng có thể cảm giác như chỉ là một lần swap, trong khi phần thanh toán thực sự được thực hiện thông qua các cơ chế được phối hợp trên nhiều chuỗi.
Omniston đang làm khác gì?
Về cốt lõi, Omniston được thiết kế để trừu tượng hóa phần lớn sự phức tạp liên quan đến việc thực thi xuyên chuỗi.
Thay vì yêu cầu người dùng tự hoàn tất nhiều hành động trên các mạng khác nhau, giao diện hiển thị một ý định xuyên chuỗi duy nhất: tài sản người dùng muốn bán, tài sản người dùng muốn nhận và các mạng liên quan.
Đằng sau yêu cầu đó, các resolver cạnh tranh để cung cấp thanh khoản phía đích và thực hiện giao dịch theo đúng các điều khoản được báo giá.
Điều này tạo ra một sự khác biệt quan trọng.
Omniston không cần biến TON thành điểm trung gian cho mọi tuyến xuyên chuỗi. Trong kịch bản EVM-to-EVM, tài sản ở chuỗi nguồn và tài sản ở chuỗi đích có thể vẫn nằm trên các mạng EVM tương ứng của chúng, trong khi giao thức phối hợp việc thanh toán giữa hai bên.
Hỗ trợ giai đoạn 1 bao gồm các mạng lớn như Ethereum, BNB Chain, Base và Polygon, tạo nền tảng cho việc trao đổi tài sản đa mạng mà không yêu cầu người dùng tự xây dựng tuyến cầu nối thủ công.
Mô hình RFQ: Thanh khoản cạnh tranh để giành lấy lệnh
Một trong những thành phần quan trọng nhất trong kiến trúc của Omniston là mô hình RFQ của nó.
RFQ là viết tắt của Request for Quote (Yêu cầu báo giá).
Thay vì chỉ dựa hoàn toàn vào một pool thanh khoản duy nhất để xác định giá thực thi, hệ thống cho phép các resolver cạnh tranh bằng cách cung cấp báo giá cho một lệnh xuyên chuỗi.
Một luồng đơn giản trông như sau:
Người giao dịch chỉ định tài sản họ muốn bán và tài sản họ muốn nhận.
Omniston phát quảng bá lệnh tới các resolver đủ điều kiện.
Các resolver đánh giá yêu cầu, thanh khoản ở phía đích, chi phí thực thi, điều kiện mạng và các yếu tố khác.
Họ trả về các báo giá mô tả những gì họ có thể cung cấp.
Sau đó, hệ thống có thể chọn một lộ trình thực thi phù hợp dựa trên các ưu đãi sẵn có.
Mô hình này đặc biệt quan trọng cho giao dịch xuyên chuỗi vì thanh khoản có thể bị phân mảnh giữa các mạng.
Một resolver có thể cung cấp thanh khoản đúng nơi mà người giao dịch cần ở chuỗi đích, đồng thời phối hợp giao dịch phía nguồn một cách riêng biệt.
Đối với người giao dịch, điều này giảm nhu cầu hiểu hạ tầng đứng sau tuyến đó.
Vì sao các HTLC ghép cặp lại quan trọng
Thành phần lớn thứ hai là việc sử dụng Hashed Timelock Contracts, thường được gọi là HTLCs.
Thách thức trong một giao dịch xuyên chuỗi là khá rõ ràng:
Làm sao hai bên có thể trao đổi tài sản tồn tại trên các blockchain khác nhau mà không phải phụ thuộc vào một giao dịch dùng chung?
Câu trả lời là tạo ra các điều kiện mật mã tương ứng trên cả hai mạng.
Trong một ví dụ đơn giản, người giao dịch khóa một tài sản trong một HTLC ở phía nguồn.
Hợp đồng đó bao gồm:
Một hashlock, định nghĩa bí mật cần thiết để nhận tiền.
Một timelock, định nghĩa điều gì xảy ra nếu việc trao đổi không được hoàn tất trong khoảng thời gian cho phép.
Trong khi đó, resolver khóa tài sản tương ứng ở phía đích bằng một điều kiện HTLC tương thích.
Vì vậy, hai phía được nối với cùng một bí mật mật mã nền tảng.
Bí mật phối hợp việc thanh toán
Yếu tố quan trọng trong quy trình là bí mật được dùng bởi hashlock.
Các tài sản không thể đơn giản được nhận một cách tùy ý. Các điều kiện nhúng trong hợp đồng quyết định việc thanh toán có thể diễn ra như thế nào.
Khi bí mật đúng được tiết lộ để nhận một bên của giao dịch, bí mật đó có thể được dùng để thỏa mãn điều kiện tương ứng ở bên còn lại.
Điều này tạo ra một cơ chế thanh toán đồng bộ giữa các blockchain độc lập.
Ý tưởng cốt lõi không phải là việc Ethereum và Base đột nhiên chia sẻ một sổ cái chung.
Họ không phải.
Thay vào đó, các hợp đồng trên các mạng riêng biệt áp dụng các quy tắc tương thích, cho phép việc trao đổi được hoàn tất theo cùng một điều kiện mật mã.
Đó là điều tạo nên đặc tính thanh toán “nguyên tử” của cơ chế này.
Điều gì xảy ra nếu lệnh thất bại?
Hạ tầng xuyên chuỗi cũng phải tính đến khả năng thất bại.
Các mạng có thể bị tắc nghẽn. Giao dịch có thể bị trì hoãn. Một resolver có thể không hoàn tất việc thực thi. Điều kiện thanh toán có thể không được đáp ứng trong khoảng thời gian yêu cầu.
Đây là lúc timelock trở nên then chốt.
Nếu các điều kiện cần thiết cho việc thanh toán không được đáp ứng trước thời điểm hết hạn liên quan, cơ chế HTLC cho phép bên phù hợp hoàn tiền cho các tài sản đã bị khóa theo đúng quy tắc hợp đồng.
Vì vậy, hệ thống không phụ thuộc vào việc mọi giao dịch đều phải thành công hoàn hảo.
Thay vào đó, nó được thiết kế xoay quanh hai kết quả có thể xảy ra:
Thanh toán thành công: điều kiện mật mã được thỏa mãn và các tài sản có thể được nhận.
Hết thời gian: việc thanh toán không hoàn tất trong khung thời gian yêu cầu và cơ chế hoàn tiền sẽ được kích hoạt.
Điều này giúp lệnh xuyên chuỗi có khả năng chống chịu cao hơn so với một quy trình mà người dùng phải tự phối hợp thủ công nhiều giao dịch độc lập.
Vì sao điều này khác so với DEX truyền thống
Một swap DEX thông thường tương đối đơn giản vì cả hai tài sản thường sẵn có trên cùng một blockchain.
Ví dụ: một nhà giao dịch đổi một token sang token khác trên Ethereum có thể tương tác với một pool thanh khoản hoặc hệ thống định tuyến hoạt động hoàn toàn trong môi trường thực thi của Ethereum.
Blockchain đã cung cấp trạng thái dùng chung cần thiết để thực hiện giao dịch.
Các swap EVM-to-EVM là khác.
Ví dụ, Ethereum và Polygon duy trì trạng thái độc lập. Một giao dịch được xác nhận trên một mạng không tự động thực thi tương đương trên mạng còn lại.
Vì vậy Omniston không thể coi một lần swap nhiều chuỗi là một giao dịch blockchain đơn lẻ theo nghĩa đen.
Thay vào đó, nó tạo ra một ý định giao dịch được hỗ trợ bởi nhiều bước thực thi được phối hợp.
Giao diện có thể trông có vẻ thống nhất, nhưng phần thanh toán nền tảng vẫn diễn ra riêng biệt trên từng mạng.
Sự phân biệt đó là quan trọng.
Tính “tính nguyên tử” đến từ các quy tắc của giao thức, các điều kiện mật mã và cơ chế timeout, chứ không phải từ một giao dịch kỳ diệu duy nhất trải qua nhiều blockchain.
Không cần trung gian TON
Một khía cạnh quan trọng khác trong thiết kế EVM-to-EVM của Omniston là TON không cần phải đứng ở giữa giao dịch.
Với một tuyến EVM-to-EVM, người giao dịch không nhất thiết phải chuyển đổi tài sản nguồn sang TON, đi qua hệ sinh thái TON rồi sau đó chuyển đổi trở lại tài sản đích mong muốn.
Thay vào đó, Omniston có thể phối hợp trực tiếp chuỗi nguồn và chuỗi đích thông qua kiến trúc thực thi xuyên chuỗi của mình.
Điều này có thể giảm các bước không cần thiết từ góc nhìn của người dùng và khiến giao dịch đa mạng trở nên gần giống một swap thông thường hơn.
Vì vậy, sự trừu tượng quan trọng là:
một lệnh, nhiều mạng, thanh toán được phối hợp.
Khớp một phần cho các lệnh lớn
Giao dịch xuyên chuỗi cũng có vấn đề thanh khoản, trở nên rõ ràng hơn khi kích thước lệnh tăng lên.
Một lệnh lớn không phải lúc nào cũng có thể được khớp hiệu quả bởi một nguồn hoặc một resolver duy nhất.
Omniston có thể hỗ trợ khớp một phần, cho phép các lệnh lớn được xử lý thông qua nhiều cơ hội thực thi hơn là chỉ phụ thuộc hoàn toàn vào một nguồn thanh khoản.
Điều này có thể hữu ích vì thanh khoản xuyên chuỗi hiếm khi được phân bổ đồng đều.
Một resolver có thể đưa ra mức thực thi hấp dẫn cho một phần của lệnh, trong khi resolver khác lại phù hợp hơn cho phần còn lại.
Vì vậy, một hệ thống có khả năng xử lý thực thi một phần có thể linh hoạt hơn khi đối mặt với thanh khoản bị phân mảnh.
Trải nghiệm người dùng vs. Hạ tầng
Một trong những ý tưởng mạnh nhất đằng sau Omniston là sự tách bạch giữa những gì người dùng nhìn thấy và những gì giao thức thực sự cần phải làm.
Đối với người giao dịch, luồng có thể vẫn tương đối đơn giản:
Chọn tài sản để bán.
Chọn tài sản để nhận.
Xem xét báo giá hiện có.
Phê duyệt giao dịch.
Cho phép quy trình thực thi xuyên chuỗi hoàn tất.
Tuy nhiên, đằng sau giao diện đơn giản đó, có thể đang diễn ra một số việc.
Các resolver cạnh tranh giành lấy lệnh.
Đang đánh giá thanh khoản.
Chi phí gas đang được xem xét.
Các hợp đồng ở chuỗi nguồn và chuỗi đích đang được chuẩn bị.
Các điều kiện HTLC đang được thiết lập.
Các giao dịch được gửi độc lập tới các mạng liên quan.
Việc thanh toán được phối hợp thông qua các điều kiện mật mã.
Sự trừu tượng này rất quan trọng vì người dùng nhìn chung không muốn trở thành chuyên gia về phối hợp giao dịch xuyên chuỗi chỉ để chuyển một tài sản giữa hai mạng EVM.
Vẫn còn quan trọng điều gì: Báo giá, Gas và Thanh khoản
Omniston không loại bỏ mọi thách thức liên quan tới giao dịch xuyên chuỗi.
Chất lượng thực thi vẫn phụ thuộc vào một số yếu tố thực tiễn.
Chất lượng báo giá rất quan trọng. Một tuyến xuyên chuỗi chỉ hữu ích nếu số lượng nhận được có tính cạnh tranh.
Chi phí gas rất quan trọng. Mỗi mạng tham gia có thể tạo ra các khoản phí giao dịch ảnh hưởng tới tổng chi phí thực thi.
Thanh khoản rất quan trọng. Một bộ “resolver” cần đủ thanh khoản ở phía đích để thực hiện lệnh một cách hiệu quả.
Điều kiện mạng rất quan trọng. Tắc nghẽn, thời gian xác nhận và độ tin cậy giao dịch có thể ảnh hưởng tới việc thực thi.
Vì vậy, dù giao diện có thể đơn giản hóa quy trình, thì kinh tế học nền tảng của việc giao dịch không hề biến mất.
Trừu tượng hóa xuyên chuỗi làm trải nghiệm dễ hơn; nó không làm cho thanh khoản, phí hay điều kiện mạng trở nên không còn liên quan.
Bảo mật nhờ phối hợp, không phải tập trung hóa
Một cách hiểu hữu ích khác về kiến trúc là Omniston không yêu cầu một vault xuyên chuỗi dùng chung được điều khiển bởi một bên trung gian duy nhất cho chính bản thân giao dịch swap.
Thay vào đó, chuỗi nguồn và chuỗi đích duy trì các hợp đồng riêng và tự thực thi các điều kiện của chính mình.
Sự phối hợp diễn ra thông qua logic thực thi của giao thức và các đảm bảo bằng mật mã.
Cấu trúc đó có ý nghĩa vì nó thu hẹp khoảng cách nhận thức giữa ý định của người dùng và cơ chế thanh toán thực sự.
Người dùng không chỉ đơn thuần tin rằng một bên trung gian rồi cuối cùng sẽ chuyển tài sản.
Giao dịch được thiết kế sao cho các hợp đồng trên các mạng liên quan xác định việc trao đổi nên diễn ra như thế nào và điều gì xảy ra nếu các điều kiện đó không được đáp ứng.
Bức tranh lớn hơn cho giao dịch xuyên chuỗi
Mô hình EVM-to-EVM của Omniston minh họa cho một sự thay đổi rộng hơn trong giao dịch phi tập trung.
Tương lai của trải nghiệm UX xuyên chuỗi có thể không phụ thuộc vào việc người dùng học cách từng blockchain hoạt động như thế nào.
Thay vì vậy, hạ tầng có thể đảm nhiệm việc định tuyến, khám phá thanh khoản và phối hợp thanh toán bên dưới một trải nghiệm giao dịch thống nhất.
Dưới góc nhìn đó, bài toán xuyên chuỗi trở nên ít liên quan tới việc thủ công di chuyển tài sản giữa các chuỗi và nhiều hơn là diễn đạt một ý định:
“Tôi muốn bán tài sản này ở đây và nhận tài sản đó ở kia.”
Các resolver sẽ cạnh tranh để đáp ứng ý định đó, trong khi các cơ chế thanh toán bằng mật mã đảm bảo việc thực thi tuân theo các quy tắc đã xác định.
Điều này khác căn bản so với việc chỉ thêm một giao diện cầu nối khác.
Một cây cầu chủ yếu tập trung vào việc chuyển tài sản hoặc các đại diện của tài sản giữa các mạng.
Một hệ thống lấy lệnh làm trung tâm tập trung vào việc hoàn tất một giao dịch xuyên qua các mạng.
Sự phân biệt này có thể ngày càng trở nên quan trọng khi số lượng hệ sinh thái blockchain, tài sản và địa điểm thanh khoản tiếp tục tăng lên.
Kết luận cuối cùng
Cách tiếp cận của Omniston đối với các swap EVM-to-EVM được xây dựng dựa trên một ý tưởng đơn giản, với nền tảng hạ tầng tinh vi bên dưới.
Thay vì coi giao dịch xuyên chuỗi là một chuỗi các giao dịch cầu nối và DEX không liên quan, nó coi thao tác này như một lệnh xuyên chuỗi duy nhất.
Các resolver cạnh tranh thông qua mô hình RFQ.
Thanh khoản ở phía đích được cung cấp đúng nơi mà người giao dịch cần.
Các HTLC ghép cặp thiết lập các điều kiện mật mã trên các mạng tham gia.
Hashlock phối hợp việc xác nhận yêu cầu thành công.
Timelock cung cấp cơ chế hoàn tiền khi việc thanh toán không hoàn tất.
Khớp một phần có thể giúp xử lý các lệnh lớn.
Và quan trọng là, giao dịch không yêu cầu TON đóng vai trò là tài sản trung gian hoặc mạng trung gian cho một tuyến EVM-to-EVM.
Kết quả là một hệ thống mà người giao dịch tương tác với một luồng swap thống nhất, trong khi nhiều blockchain độc lập phối hợp bên dưới.
Đó là giá trị thực của hạ tầng xuyên chuỗi: không làm cho các blockchain trở nên giống hệt nhau, mà làm cho những khác biệt của chúng ít hiện ra trước người dùng hơn.
Khi thanh khoản đa chuỗi ngày càng bị phân mảnh, các hệ thống như Omniston có thể đóng vai trò quan trọng trong việc biến sự phân mảnh đó thành một trải nghiệm giao dịch đơn giản hơn—nơi người dùng chỉ tập trung vào tài sản họ muốn giao dịch và tài sản họ muốn nhận, còn hạ tầng bên dưới xử lý độ phức tạp của việc đảm bảo lệnh được thanh toán.
Điểm chính cần nhớ: Omniston kết hợp cạnh tranh thanh khoản dựa trên RFQ với thanh toán xuyên chuỗi dựa trên HTLC, biến một swap EVM-to-EVM từ một quy trình nhiều bước rắc rối thành một lệnh được phối hợp, thiết kế để thực thi hoặc rút lui an toàn theo các quy tắc đã định sẵn.
KHÁM PHÁ THÊM VỀ STON.FI EVM-TO-EVM SWAP: https://app.ston.fi/swap?mode=cross-chain&in=bnb%3AUSDT&out=ethereum%3AUSDT
Bạn có tin tưởng một kiến trúc RFQ + HTLC cho các swap xuyên chuỗi lớn, hay bạn vẫn thích các tuyến đường dựa trên cầu nối truyền thống?