⏳ Khóa thời gian HTLC trong thiết kế hoán đổi liên chuỗi: Nghiên cứu điển hình STON.fi/Omniston
Hầu hết các giải thích về hoán đổi nguyên tử chỉ dừng lại ở câu: "tiền bị khóa sau một hàm băm và bộ hẹn giờ, nên hoặc cả hai bên hoàn tất, hoặc cả hai bên hoàn tiền." Câu đó đúng và gần như vô dụng để hiểu vì sao thiết kế hoạt động, nó tốn chi phí gì, hoặc một hệ thống sản xuất xây dựng sản phẩm thực tế trên nền tảng đó như thế nào.
Phần thú vị không phải là khóa băm. Khóa băm rất đơn giản — một hàm một chiều, một tiền ảnh, và một phép so sánh. Phần thú vị nằm ở khóa thời gian, và cụ thể là mối quan hệ giữa hai khóa thời gian trên hai chuỗi không hề biết đến sự tồn tại của nhau. Nếu bạn hiểu ngược mối quan hệ đó, bảo đảm tính nguyên tử sẽ biến thành một “lựa chọn miễn phí” có thể khai thác. Làm đúng thì sẽ có được cơ chế thanh toán không cần cầu nối, không cần bên giám hộ và không cần can thiệp quản trị khi mọi thứ có trục trặc.
"Hashlock là phần mà ai cũng giải thích. Còn thứ tự timelock mới là phần thực sự ngăn bạn khỏi mất tiền."
🔐 Mục 1: Nguyên Thủy — Hai Cánh Cửa, Không Bao Giờ Mở Đồng Thời Cả Hai
Một HTLC giữ tiền phía sau đúng hai điều kiện giải phóng, và kỷ luật thiết kế ở đây là hai lối đi đó không bao giờ có thể mở đồng thời.
Một dạng tối giản, biểu đạt như trạng thái mà hợp đồng thực sự lưu trữ:
interface HtlcState { hashlock: Uint8Array; // sha256(secret) — public ngay từ đầu deadline: number; // unix timestamp, sau đó việc refund mở ra sender: Address; // nhận lại funds thông qua refund() receiver: Address; // nhận funds thông qua claim(secret) amount: bigint; }
Hai phương pháp, và điều quan trọng là cơ chế bảo vệ (guard) cho mỗi phương pháp:
function claim(secret: Uint8Array) { require(now() < state.deadline, "claim window closed"); require(sha256(secret) === state.hashlock, "wrong preimage"); transfer(state.receiver, state.amount); } function refund() { require(now() >= state.deadline, "too early to refund"); require(caller() === state.sender, "not the sender"); transfer(state.sender, state.amount); }
Xem hai lần kiểm tra now() bây giờ. claim yêu cầu trước hạn (before the deadline); refund yêu cầu ở hoặc sau thời điểm đó (at or after it). Chúng là hai mệnh đề bù trừ chính xác — không có timestamp nào mà cả hai thành công, và cũng không có timestamp nào mà cả hai thất bại. Trước hạn, chính xác một bên có thể hành động (bên nhận, nếu họ có preimage). Sau hạn, chính xác một bên có thể hành động (bên gửi). Không có trạng thái thứ ba và không có khoảng trống.
Cách đóng khung theo kiểu học thuật mô tả điều này như một bộ ba thuật toán — Lock, Unlock, Refund — và cách đóng khung đó đáng để nắm vững, vì nó làm rõ rằng “thất bại” ở đây là một kết quả được thiết kế lành mạnh (first-class), chứ không phải nhánh ngoại lệ được gắn thêm sau. Hoàn tiền không phải là việc giao thức bị hỏng. Đó là giao thức đang hoạt động.
Vì sao lựa chọn hàm băm thực sự quan trọng. Preimage phải không thể đoán trước (unguessable) và hàm băm phải được tính ra giống hệt trên cả hai chuỗi. Điều kiện thứ hai này còn ràng buộc hơn nghe có vẻ — nó loại bỏ mọi cặp chuỗi không chia sẻ cùng một nguyên thủy hàm băm, và vì thế SHA-256 chiếm ưu thế trong thực tế thay vì bất kỳ thứ gì “quái” hơn:
// Bí mật phải được tạo với entropy thật, không suy ra // từ bất cứ thứ gì có thể dự đoán — một timestamp, một nonce, một bộ đếm. const secret = crypto.randomBytes(32); const hashlock = sha256(secret); // hashlock được công bố ngay lập tức và công khai. // secret vẫn được giữ riêng tư cho đến khoảnh khắc claim.
Một bí mật suy ra từ bất cứ thứ gì đoán được — hash của một block, số thứ tự (sequence number), timestamp — sẽ cho đối tác khả năng claim mà không cần chờ. Sự ngẫu nhiên không phải là chi tiết; nó là phần chịu lực (load-bearing).
Cũng có một điểm tinh tế về thời điểm bí mật trở nên công khai. Nó không được tiết lộ bởi bất kỳ tin nhắn ngoài băng (out-of-band) nào hay bất kỳ relay được tin cậy nào. Nó trở thành công khai như một hệ quả phụ của việc được sử dụng — giao dịch claim mang nó theo, và một khi giao dịch đó đã nằm trong một block, thì preimage chỉ đơn giản là trạng thái có thể đọc được trên chuỗi mà bất kỳ ai cũng quan sát được. Chính điều này làm cho nhánh thứ hai không cần tin cậy (trustless): không ai phải gửi cho đối tác bất cứ thứ gì.
Đây là chỗ mà một HTLC không còn đủ: cấu trúc này cho bạn một khoản thanh toán có điều kiện (conditional payment), chứ không phải swap. Alice có thể trả Bob một cách có điều kiện. Không có gì ở trên làm cho Bob phải trả Alice. Một swap xuyên chuỗi cần hai cấu trúc như vậy, một cho mỗi chuỗi, và việc phối hợp các hạn (deadlines) của chúng mới là bài toán thực sự khó.
⚖️ Mục 2: Sự Bất Đối Xứng Tạo Nên Tính Atomicity
Hai HTLC, hai chuỗi, cùng hashlock. Alice khóa trên chuỗi nguồn, Bob khóa trên chuỗi đích. Alice đã tạo bí mật, nên ban đầu chỉ Alice mới có thể mở khóa bất cứ thứ gì.
Câu hỏi quyết định liệu việc này an toàn hay đã bị hỏng thảm họa:
┌─────────────────────────────────────────┐ SOURCE │ Hạn khóa của Alice: ??? │ └─────────────────────────────────────────┘ ┌─────────────────────────────────────────┐ DEST │ Hạn khóa của Bob: ??? │ └─────────────────────────────────────────┘ Hạn nào đến trước?
Câu trả lời: chúng phải được xếp so le, không đồng bộ, và hướng không phải là tùy ý. Bên nắm giữ bí mật phải có hạn muộn hơn.
// Bất biến (invariant) duy nhất mà toàn bộ giao thức dựa vào: assert(takerDeadline < originatorDeadline);
Tại sao hướng này, cụ thể? Chạy thứ tự bị lỗi và quan sát nó thất bại.
Giả sử hạn (deadline) của Bob đến sau hạn của Alice. Alice, khi đã nắm bí mật, chỉ cần không làm gì. Khóa của chính cô ấy hết hạn trước và cô ấy hoàn tiền — cô ấy nhận lại tiền ban đầu của mình, miễn phí và rõ ràng. Nhưng khóa của Bob vẫn đang còn hiệu lực, vẫn nằm sau cùng hash đó, và Alice vẫn biết preimage. Cô ấy tiết lộ, claim tài sản của Bob, và bỏ đi khi đang nắm giữ cả hai phía. Hashlock đã hoạt động hoàn hảo. Thứ tự deadline đã phá hỏng thương vụ.
Bây giờ là thứ tự đúng. Alice muốn tài sản ở phía đích, nên cô ấy phải tiết lộ bí mật trên chuỗi đích — và phải làm trước hạn sớm hơn. Ngay khoảnh khắc cô ấy làm vậy, preimage trở thành trạng thái công khai trên chuỗi. Bob đọc được và claim trên chuỗi nguồn, và anh ấy được đảm bảo một khoảng thời gian để làm việc đó, vì hạn của phía nguồn muộn hơn nghiêm ngặt:
t₀ ─────────────────────────────────────────────────────▶ time DEST [ Bob's lock ────────────────── ✕ takerDeadline ] ▲ │ Alice reveals secret here │ (must be before ✕) ▼ SOURCE [ Alice's lock ─────────────────────── ✕ originatorDeadline ] └──── Bob's safety window ────┘
Khoảng gap đó — khoảng cách giữa hai hạn — là sự bảo vệ của Bob. Nó không phải độ dư (slack) hay phần đệm (padding). Chính là lý do khiến Bob có thể an toàn đi sau.
Tài liệu học thuật nêu chặt chẽ điều này: HTLC thực hiện các swap atomic xuyên chuỗi bằng cách phối hợp hai hợp đồng trên hai chuỗi khác nhau với hashlock được đồng bộ và timelock được xếp so le (staggered). Tính atomicity đúng theo nghĩa: hoặc cả hai tài sản được chuyển, hoặc cả hai bên hoàn tiền. Hash được đồng bộ, thời gian xếp so le. Bốn từ đó là giao thức.
Liệt kê mọi nhánh và đều đúng:
Điều gì xảy ra | Nhánh Nguồn | Nhánh Đích Alice tiết lộ và claim | Bob claim với bí mật đã được tiết lộ | Alice claim | Alice không bao giờ tiết lộ | Hoàn tiền ở hạn muộn hơn | Hoàn tiền ở hạn sớm hơn | Alice tiết lộ vào đúng khoảnh khắc cuối | Bob vẫn còn toàn bộ khoảng trống để hành động | Alice claim | Bob không khóa gì cả | Khóa của Alice hết hạn, hoàn tiền | Chưa từng tồn tại
Không có cách sắp xếp các sự kiện nào mà một bên yêu cầu nhận (claim) trong khi bên còn lại không thể hoặc không kịp yêu cầu nhận hoặc hoàn tiền (refund). Và hãy để ý những gì vắng mặt trong bảng đó: không có hàng nào đòi hỏi một con người phải can thiệp. Không có ủy ban multisig, không có khóa admin, không có người vận hành cầu (bridge operator) phán quyết yêu cầu nào là hợp lệ. Việc khôi phục (recovery) được mã hóa trong hợp đồng và tự kích hoạt theo thời gian cho dù có ai đang theo dõi hay không.
Việc định cỡ gap đó là một quyết định kỹ thuật riêng. Nó không thể chặt một cách tùy tiện, vì bên thứ hai cần thời gian “thực” theo đồng hồ tường (wall-clock time) để quan sát bí mật đã được tiết lộ, xây dựng một giao dịch, phát (broadcast) nó, và nhận nó được xác nhận — dưới bất kỳ mức nghẽn nào tồn tại vào thời điểm đó:
const takerDeadline = now + destinationChainFinality * SAFETY_FACTOR; const originatorDeadline = takerDeadline + reactionWindow; // reactionWindow must exceed: // worst-case source-chain confirmation time // + realistic reorg depth // + the counterparty's own detection latency
Nếu quá chặt, thì một đợt nghẽn tăng vọt (congestion spike) hoặc reorg thực sự sẽ khiến ai đó mất cơ hội giao dịch. Nếu quá rộng, thì vốn bị khóa lâu hơn cần thiết trong trường hợp thất bại. Mọi hệ thống HTLC sản xuất đều đang đưa ra một tuyên bố về độ trễ tệ nhất của chuỗi chậm hơn và mã hóa tuyên bố đó thành một con số.
🔄 Mục 3: Omniston Thêm Gì — Discovery Trước Settlement
Bài toán “atomic swap” trong sách giáo khoa có một vấn đề khiến nó không thể dùng như sản phẩm cho người tiêu dùng: nó giả định rằng Alice và Bob đã tìm thấy nhau và đã thỏa thuận giá trước. Thực tế, việc tìm được đối tác sẵn sàng đứng về phía bên kia của một giao dịch xuyên chuỗi — cạnh tranh ngay lúc này, đúng với quy mô của bạn — mới là phần khó. HTLC giải quyết vấn đề thanh toán (settlement). Nó không giải quyết gì cho phần khám phá (discovery).
Kiến trúc của Omniston đặt một lớp báo giá cạnh tranh trước lớp settlement, và thứ tự là điểm mấu chốt:
GIAI ĐOẠN 1 — ngoài chuỗi, miễn phí, có thể đảo ngược ─────────────────────────────────────────────────────────────────── user intent └─▶ RFQ broadcast ──▶ resolver A ─┐ ──▶ resolver B ─┼─▶ best quote wins ──▶ resolver C ─┘ ──▶ AMM pool reads ⚠️ NO HTLC EXISTS YET. Chưa có gì chạm vào bất kỳ chuỗi nào. GIAI ĐOẠN 2 — trên chuỗi, đã cam kết, timelocked ───────────────────────────────────────────────────────────────── winning quote └─▶ user locks source side (later deadline) └─▶ resolver locks dest side (earlier deadline) └─▶ reveal ──▶ claim ──▶ claim
Giai đoạn một không tốn gì. Resolver — các market maker độc lập chạy dịch vụ định giá của riêng họ trên các luồng gRPC bền vững — mỗi bên tự quyết định sẽ đưa gì cho quy mô và cặp đó. Báo giá quay về, được so sánh với tính thanh khoản của AMM pool, và điều kiện tốt nhất sẽ thắng.
Nếu không nhận được một báo giá chấp nhận được, RFQ chỉ đơn giản hết hạn. Không hề tạo HTLC. Không có gì để hoàn tiền và cũng chẳng có gì để tháo gỡ. Đây chính là đúng chỗ để đặt lỗi “không tìm thấy đối tác”: miễn phí, ngoài chuỗi, và tức thì.
Giai đoạn hai hiện thực đúng “bộ đôi” hai hợp đồng đó — nhưng chỉ sau khi một resolver cụ thể đã thắng ở một mức giá cụ thể.
Ranh giới giữa hai giai đoạn đó xứng đáng được chú ý, vì đó là nơi phần lớn “an toàn thực tế” tồn tại. Một báo giá không phải là đề nghị thường trực (standing offer) — nó có riêng “deadline” hiệu lực của mình, hoàn toàn tách biệt và ngắn hơn rất nhiều so với các timelock của HTLC diễn ra sau:
// Ba đồng hồ (clocks) khác nhau, dễ nhầm lẫn, làm các việc khác nhau: quoteValidUntil // seconds — trong bao lâu giá này được tôn trọng takerDeadline // minutes — HTLC phía đích hết hạn originatorDeadline // minutes — HTLC phía nguồn hết hạn, muộn hơn nghiêm ngặt
Gộp nhầm những thứ đó là một nguồn gây nhầm lẫn thật sự. Một người dùng do dự quá hạn quoteValidUntil thì không mất gì — vì chưa hề tồn tại HTLC. Việc gửi lại yêu cầu chỉ tạo ra một mức giá mới. Còn một người dùng do dự sau khi đã khóa thì đang ở một “chế độ” hoàn toàn khác, nơi các đồng hồ liên quan là timelocks và kết quả là hoàn tiền, chứ không phải báo giá lại (re-quote).
Chi tiết cấu trúc đáng nêu bật: ai là người tài trợ phía bên đích. Không phải một hợp đồng bridge giữ các khoản tiền gửi người dùng được gom lại. Không phải quỹ (treasury) của giao thức. Người giải (resolver) — một market maker vừa thắng một cuộc đấu giá cạnh tranh và bây giờ đang đưa chính vốn của nó làm hậu thuẫn cho báo giá mà nó đã đưa.
// Bridge model — tập trung, vĩnh viễn, đích lớn dần bridgeContract.lockedValue += everyUserDeposit; // Resolver model — theo từng giao dịch, từng đối tác, giới hạn theo thời gian resolverCapital.commit(thisTradeOnly, releasesAt: takerDeadline);
Đó là dạng rủi ro hoàn toàn khác. Mức phơi nhiễm được giới hạn theo từng giao dịch và hết hạn theo timer, thay vì tích lũy trong một hợp đồng duy nhất trở thành mục tiêu lớn hơn mỗi ngày.
Điều này cũng giải thích một thứ mà người dùng thường hiểu nhầm: vì sao các swap xuyên chuỗi mất thời gian đáng kể hơn so với các swap cùng chuỗi trên STON.fi. Một swap cùng chuỗi TON kế thừa tính atomicity từ mô hình giao dịch của TON — hoặc là hoàn tất hoặc hoàn tác (revert), và được “settle” nhanh như tốc độ chuỗi đưa nó vào. Một swap xuyên chuỗi thì không thể kế thừa gì cả, vì hai blockchain độc lập chẳng cung cấp cho nhau bất kỳ đảm bảo nào. Thời gian thêm không phải là do chờ độ trễ vì kỹ thuật tốt hơn. Đó là “cửa sổ timelock” — một đảm bảo đúng đắn (correctness guarantee), được mua trong vài giây.
Việc thực thi bất đồng bộ (async execution) của TON tạo ra một “vết gấp” mà các bài báo kinh điển không dự đoán. Tài liệu về atomic swap kinh điển giả định thực thi đồng bộ: gọi một hợp đồng, nó thành công hoặc revert, và bạn biết ngay. TON truyền thông điệp — một message gửi trong một block sẽ được phân giải trong block sau. Một swap trên STON.fi đã đi qua một chuỗi message thực sự:
ví của jetton của người dùng └─▶ ví jetton của Router (transfer_notification) └─▶ Router (giải mã payload, điều phối) └─▶ Pool (thực thi toán AMM) └─▶ thanh toán
Việc chồng HTLC settlement lên trên đó có nghĩa “claim có thành công không?” không thể trả lời đồng bộ — và chính vì vậy việc theo dõi giao dịch là một subscription kiểu streaming thay vì một giá trị trả về:
omniston.trackTrade({ rfqId }).subscribe(({ state }) => { // 'filled' | 'partiallyFilled' | 'aborted' // async settlement means you observe, you don't await });
💸 Mục 4: Chi phí Thực Sự Của Tính Atomicity
Một bài viết kỹ thuật chỉ liệt kê lợi thế không phải là bài viết kỹ thuật. Cam kết đảm bảo này được trả bằng bốn “đồng tiền” khác nhau.
⏱️ Độ trễ (Latency) — do người dùng trả. Cửa sổ timelock không thể nén nhỏ hơn thời gian xác nhận tệ nhất của chuỗi chậm hơn cộng thêm phần đệm. Mức đánh đổi được nêu rõ trong tài liệu: HTLC đổi lấy một chút độ trễ — bạn trả cho cửa sổ timelock — để lấy đảm bảo rằng tại không thời điểm nào bất kỳ bên nào nắm giữ tài sản của bên kia mà không có lý do bắt buộc có thể thực thi để giải phóng nó. Vài giây để chắc chắn thường là một mức đổi tốt. Đây vẫn là một mức đổi.
🔒 Đóng băng vốn — do resolver trả. Từ lúc tài trợ nhánh của nó cho tới khi thanh toán xong, số vốn đó được cam kết và không dùng được. Nếu swap hoàn tiền, resolver thu hồi lại principal nhưng không kiếm được gì cho khoảng thời gian nó bị immobilized. Chi phí cơ hội thuần túy — và cũng là một phần lý do vì sao báo giá xuyên chuỗi thường “rộng” về mặt cấu trúc hơn so với định giá AMM cùng chuỗi. Bạn đang trả một phần cho việc vốn của giao dịch bạn bị đóng băng.
⛽ Gas trên nhánh thất bại — do bên nào hoàn tiền. Hoàn tiền là một giao dịch và tốn gas. Một swap hoàn trả đúng toàn bộ tiền cho mọi người là kết quả thành công theo thiết kế, nhưng cả hai bên vẫn hơi “lệch” về túi tiền trong một giao dịch không tạo ra gì. Nhỏ, nhưng đáng gọi tên vì đó là chi phí mà người dùng ít ngờ tới nhất.
🎣 Bề mặt bị griefing — trả bằng giá trị kỳ vọng (expected value). Một đối tác khóa rồi không tiết lộ thì không làm bên kia mất gì về principal — vì phần hoàn tiền lo liệu — nhưng lại khiến họ mất khoảng thời gian trong đó vốn bị đóng băng. Việc lặp lại thao tác khởi tạo rồi bỏ swap là một kiểu từ chối dịch vụ (denial-of-service) nhắm vào vốn hoạt động của resolver. Tài liệu thẳng thắn rằng các HTLC cơ bản không đủ biểu đạt cho mọi kịch bản nhiều bên, và tồn tại các mô hình nâng cao đặc biệt để cải thiện khả năng tương thích động lực và chống lại việc hối lộ và cấu kết. Hệ thống sản xuất thường giảm điều này ở lớp danh tiếng (reputation) — một resolver thấy việc bỏ cuộc lặp lại chỉ đơn giản là ngừng báo giá cho nguồn đó — thay vì phải làm điều gì đó mang tính mật mã.
Không cái nào trong số này làm vô hiệu thiết kế. Chúng chỉ xác định phạm vi áp dụng của thiết kế. Với một swap cùng chuỗi tần suất cao và giá trị thấp, điều này sẽ là một chi phí/overhead vô lý. Còn khi chuyển một quy mô đáng kể qua ranh giới chuỗi — nơi phương án thay thế là tin một bên giữ hộ (custodian) hoặc một bridge đang nắm giá trị tập trung — thì đây là một mức đổi hợp lý.
🧭 Mục 5: Duyệt Qua Mọi Chế Độ Thất Bại
Hiểu một thiết kế settlement nghĩa là phải trả lời “điều gì xảy ra nếu” cho mọi nhánh. Dưới đây là từng lỗi thực tế và chính xác phần xây dựng sẽ làm gì.
📭 Không có resolver nào báo giá cho giao dịch đó. RFQ hết hạn. Không chạm vào bất kỳ chuỗi nào, không tồn tại HTLC, và không có gì để hoàn tiền. Chỉ cần chỉnh quy mô (size) hoặc độ trượt (slippage) rồi nộp lại. Đây là kiểu thất bại rẻ nhất có thể, và được đặt đúng vị trí đầu tiên.
🚪 Người dùng nhận báo giá nhưng không bao giờ xác nhận. Kết cục tương tự — báo giá tự mang “deadline” hiệu lực của nó. Người bỏ cuộc giữa luồng thì không mất gì ngoài thời gian.
🔇 Resolver khóa vốn, người dùng bỏ trước khi tiết lộ. Nhánh phía nguồn hoàn tiền ở hạn muộn hơn, nhánh phía đích hoàn tiền ở hạn sớm hơn. Cả hai đều thu hồi được principal; cả hai đều không tốn gas cho hoàn tiền; resolver đã “ăn” chi phí cơ hội của số vốn bị đóng băng. Giao dịch đơn giản là chưa từng xảy ra.
🐌 Người dùng tiết lộ, chuỗi đích bị nghẽn nghiêm trọng. Đây chính là kịch bản mà “gap” tồn tại cho. Bí mật giờ đã công khai. Resolver có toàn bộ khoảng thời gian giữa các hạn để dùng nó ở phía nguồn. Nếu đặt kích thước theo trường hợp xấu nhất thực tế, claim vẫn thành công dù bị nghẽn. Nếu đặt quá lạc quan, đây là nơi thiết kế thất bại — vì vậy “gap sizing” là một tham số quan trọng, chứ không phải ý nghĩ thêm cấu hình.
🔀 Tái tổ chức chuỗi (chain reorganization) đảo ngược một claim. Về mặt chức năng, tương tự: phát lại, xác nhận lại (re-confirm), và khả năng sống sót phụ thuộc vào việc gap có lớn hơn độ sâu reorg thực tế hay không. Mọi thiết kế xuyên chuỗi đều đưa ra giả định về “finality” ở đây; một hệ thống HTLC chỉ làm giả định đó trở nên “đọc được” dưới dạng một con số thay vì chôn trong tập hợp validator.
✅ Mọi thứ hoạt động. Người dùng tiết lộ trên chuỗi đích và nhận được tài sản của mình. Resolver đọc bí mật từ trạng thái công khai trên chuỗi và claim trên chuỗi nguồn. Hai nhánh đều được thanh toán xong. Thời gian trôi qua xấp xỉ tổng độ trễ xác nhận của hai chuỗi cộng với thời gian phản ứng — chậm hơn rõ rệt so với swap cùng chuỗi, và đúng theo thiết kế (by construction) chứ không phải nhờ tin cậy.
Tính chất đáng nhắc lại: trên mọi nhánh ở trên, không có kết quả nào cần can thiệp thủ công. Không có ticket hỗ trợ nào giải quyết một HTLC bị kẹt, vì không có trạng thái bị kẹt. Việc hoàn tiền không phải là quy trình chăm sóc khách hàng — nó là một timer tự kích hoạt dù có ai đang chú ý hay không.
🏁 Kết Luận
Settlement xuyên chuỗi dựa trên HTLC là một trong những thiết kế hiếm hoi mà lập luận về bảo mật thực sự hoàn chỉnh — bạn có thể liệt kê mọi nhánh và kiểm chứng rằng mỗi nhánh đều kết thúc một cách công bằng, mà không cần dựa vào sự trung thực của bất kỳ ai hay sự siêng năng của bất kỳ ủy ban nào. Hashlock cung cấp cơ chế giải phóng có điều kiện. Các timelock được xếp so le, với nhánh người nắm giữ bí mật hết hạn nghiêm ngặt sau, cung cấp tính atomicity. Đảo thứ tự của phần xếp so le đó, bạn biến một swap an toàn thành một “tùy chọn miễn phí” (free option) cho bất kỳ ai đang nắm preimage.
Phần Omniston đóng góp thêm, mà HTLC đơn lẻ không làm được, là discovery. Chạy một cuộc đấu giá RFQ cạnh tranh giữa các resolver độc lập trước khi bất kỳ quỹ nào chạm vào chuỗi nào sẽ tách bạch được “liệu tôi có lấy được một mức giá tốt không” — thứ này nên miễn phí và ngoài chuỗi — khỏi “liệu nó có được thanh toán an toàn không”, thứ thuộc về nơi có mật mã. Resolver tài trợ phía đích bằng vốn riêng giúp giới hạn mức phơi nhiễm theo từng giao dịch và theo thời gian (time-bounded) thay vì dồn lại và tồn tại mãi mãi.
Chi phí là có thật: người dùng trả bằng độ trễ, resolver trả bằng vốn bị immobilized, và cả hai đều trả gas ở nhánh thất bại. Đổi lại, không có bên giữ hộ (custodian), không có tập hợp validator của bridge, và không có trạng thái nào mà tiền bị mắc kẹt chờ quyết định của con người. Với bất kỳ ai đánh giá nghiêm túc thiết kế xuyên chuỗi, tính chất cuối cùng đó — một chế độ thất bại tự giải quyết theo timer thay vì thông qua quản trị (governance) — là thứ đáng cân nhắc nặng nhất.
$SOL
