Tác giả: condition
Nguồn: https://conduition.io/scriptless/multi-party-submarine-swaps/
" Giao dịch hoán đổi ngầm " cho phép người dùng trên Mạng Lightning hoán đổi các UTXO Chuỗi để số dư trong các kênh Lightning mà không cần tin tưởng lẫn nhau. Về cơ bản, đây là một giao dịch hoán đổi nguyên tử đối với Mạng Lightning và cực kỳ hữu ích cho các nhà điều hành nút Lightning (để cân bằng lại các kênh của họ, cùng nhiều việc khác).
Khi các giao dịch hoán đổi ngầm (submarine swaps) ngày càng trở nên quan trọng và phổ biến, có lẽ đã đến lúc cần xem xét cách thức để mở rộng quy mô thông lượng của các giao dịch hoán đổi ngầm này – giờ đây khi đã có nút ngang hàng và nhà cung cấp thanh khoản tham gia vào các giao dịch hoán đổi hơn.
ôn tập
Các giao dịch hoán đổi ngầm truyền thống là các giao dịch hoán đổi nguyên tử giữa hai bên, sử dụng hai Hợp đồng Khóa Thời gian Băm (HTLC): một được triển khai trên Chuỗi Bitcoin và một được triển khai trên Mạng Lightning.
Giả sử Alice muốn bán Bitcoin trên Chuỗi của mình để đổi lấy một khoản thanh toán Lightning; và Bob muốn sử dụng số dư kênh Lightning của mình để mua lại số tiền Chuỗi của Alice.
Đầu tiên, Alice cần tạo ra một giá trị bí mật ngẫu nhiên $s$ mà chỉ mình cô ấy biết.
Alice và Bob cùng nhau xây dựng một địa chỉ được quản lý 2-trên-2: nếu Bob biết $s$, anh ta sẽ có toàn quyền chi tiêu vào địa chỉ này, được thể hiện bằng điều kiện khóa băm; hơn nữa, sau khi mạng đạt đến Block Height nhất định $B$, Alice sẽ có được toàn quyền chi tiêu vào địa chỉ này.
Đây là một ví dụ được thể hiện bằng cách sử dụng các từ mô tả:
tr( musig(<alice_pubkey>, <bob_pubkey>), { and(sha256(<hash>), pk(<bob_pubkey>)), and(after(<B>), pk(<alice_pubkey>)) })Alice gửi tiền xu của mình vào hợp đồng ký quỹ 2/2 này, tự tin rằng cô có thể lấy lại tiền của mình sau Block Height$B$, và rằng Bob hiện không thể rút trong đó vì chỉ cô ấy biết $s$.
Sau đó, Alice gửi cho Bob một hóa đơn Lightning, yêu cầu thanh toán bằng mệnh giá của loại tiền tệ, sử dụng $SHA256(s)$ làm mã băm thanh toán. Bob có thể thanh toán hóa đơn này, nhưng (thông qua khóa thời gian của HTLC) yêu cầu Alice phải giải phóng ảnh gốc ( lĩnh nhận thanh toán) không muộn hơn Block Height $B - \Delta$, trong đó $\Delta$ là độ trễ thời gian hợp lý. Nếu Alice lĩnh nhận HTLC thanh toán Lightning của Bob (bằng cách đàm phán với đối tác kênh của mình để giải phóng ảnh gốc ngoài Chuỗi và lĩnh nhận tiền, hoặc bằng cách buộc đóng kênh và Alice công khai ảnh gốc trên Chuỗi để lĩnh nhận ), Bob sẽ biết ảnh gốc giá trị bí mật $s$ của Alice, và sau đó anh ta có thể chuyển tiền trong hợp đồng ký quỹ đã đề cập ở trên. Nếu Alice xảo quyệt và chỉ lĩnh nhận thanh toán vào phút cuối cùng, tức là ở Block Height $B - \Delta$, Bob cũng sẽ có $\Delta$ khối để biết $s$ và sử dụng nó để lĩnh nhận HTLC của Alice trong Chuỗi (tức là hợp đồng đã đề cập ở trên).
Vậy là xong! Bob và Alice có thể trao đổi tiền điện tử cả trong và ngoài Chuỗi Chuỗi ai trong số họ có cơ hội gian lận người kia. Để cải thiện tính riêng tư và hiệu quả, Alice và Bob có thể hợp tác: sau khi Bob thanh toán Hóa đơn Lightning, họ sử dụng MuSig để cùng ký giao dịch chi tiêu hợp đồng đã đề cập và chuyển tiền cho Bob (để người ngoài không thể biết đây là giao dịch trao đổi HTLC/Submarine).
hiệu quả
Một số nhà cung cấp dịch vụ hoán đổi ngầm (submarine swap), chẳng hạn như dịch vụ Loop của Lightning Labs , xử lý các giao dịch Chuỗi theo lô. Khi thu gom các đồng tiền Chuỗi nhận được, việc thu gom nhiều hợp đồng cùng một lúc cho phép tập hợp tốt hơn một lượng lớn tiền vào một số lượng UTXO nhỏ hơn. Điều này cũng có thể được thực hiện khi cấp vốn cho các địa chỉ hợp đồng ký quỹ cho các giao dịch hoán đổi ngầm, với mỗi đầu ra cấp vốn cho một hợp đồng hoán đổi ngầm riêng biệt.
Tuy nhiên, vẫn còn một nút thắt về hiệu quả xuất phát từ cấu trúc mạng của giao thức hoán đổi ngầm. Chúng ta có nhiều nút nhỏ (người dùng), tất cả đều tương tác với một nhà cung cấp dịch vụ hoán đổi ngầm duy nhất (như Loop hoặc Boltz). Người dùng hoàn toàn không biết về các giao dịch của nhau, vì vậy mỗi giao dịch hoán đổi ngầm là một hợp đồng hoàn toàn độc lập giữa một người dùng và một nhà cung cấp dịch vụ hoán đổi. Điều này dẫn đến sự lãng phí.
Mỗi giao dịch hoán đổi ngầm (submarine swap), từ tiền tệ Chuỗi sang thanh toán ngoài Chuỗi, yêu cầu người dùng phải khởi tạo một giao dịch cấp vốn riêng biệt. Vì người dùng không biết về nhau, họ không thể xử lý hàng loạt các giao dịch chủ-tớ của mình cùng nhau. Hơn nữa, mỗi giao dịch hoán đổi ngầm tạo ra một đầu ra giao dịch cấp vốn riêng biệt. Do đó, ngay cả khi các giao dịch cấp vốn được xử lý hàng loạt (tương tự như giao thức Chuỗi sang Chuỗi trong Loop), chúng ta vẫn có $n$ địa chỉ HTLC riêng lẻ với số tiền được bơm vào, có khả năng yêu cầu thêm $n$ giao dịch nữa để hoàn tất.
Mở rộng
Chúng ta có thể nâng cao hiệu quả bằng cách chuyển đổi các giao dịch hoán đổi dưới nước từ giao thức một người tham gia sang giao thức n người tham gia. Thay vì giả định một người tạo và một người nhận trong lần giao dịch hoán đổi, chúng ta giả định một người tạo và n người nhận có khả năng giao tiếp được xác thực, cho dù thông qua giao tiếp ngang hàng hay thông qua một máy chủ trung gian (như người tạo). Những người tham gia này sẽ tổng hợp n hợp đồng hoán đổi dưới nước của họ thành một UTXO được chèn duy nhất để thực hiện một giao dịch hoán đổi nguyên tử, không cần tin tưởng lẫn nhau.
Điều này làm tăng độ phức tạp và tính phân mảnh của giao thức, nhưng đồng thời cũng cải thiện đáng kể hiệu quả hoạt động Chuỗi. Chúng ta hãy xem điều này được thực hiện như thế nào.
Người ăn thường xuyên chuyển đổi giữa trạng Chuỗi" và "không có Chuỗi".
Trước tiên, hãy xem xét kịch bản trong đó $n$ người dùng tham gia vào việc trao đổi tiền từ Chuỗi sang Chuỗi. Trong trường hợp này, hai bên tham gia giao dịch là:
- Người dùng đơn lẻ : Một nhóm gồm $n$ người dùng đơn lẻ muốn trao đổi một lượng nhỏ UTXO Chuỗi số dư Kênh Lightning ngoài Chuỗi .
- Người đặt lệnh : Một cá nhân hoặc doanh nghiệp muốn chuyển đổi số dư Lightning của họ thành tiền Chuỗi.
Không giống như các giao dịch hoán đổi ngầm truyền thống, nơi các bên tham gia đóng góp vào n địa chỉ Chuỗi riêng biệt Chuỗi, giao dịch này liên quan đến việc cùng nhau đóng góp vào một hợp đồng ký quỹ duy nhất, với số tiền được chuyển trong một giao dịch duy nhất. Hợp đồng ký quỹ này sẽ được người đặt lệnh sử dụng (nếu hợp đồng được thực hiện thành công) hoặc được trả lại cho các bên tham gia (nếu hợp đồng không được thực hiện thành công).
- Người đặt hàng sẽ tạo ra $n$ giá trị bí mật ngẫu nhiên ${s_1, s_2, …, s_n}$ (mỗi giá trị tương ứng với một người nhận đơn hàng).
- Người nhận lệnh và người đặt lệnh cùng nhau tạo ra một địa chỉ khóa băm gốc n-trên-n. Nếu người đặt lệnh có thể tiết lộ ${s_1, s_2, …, s_n}$, họ có thể chuyển tiền từ địa chỉ này.
Sau đây là một ví dụ về khóa băm ba lần được biểu diễn bằng một mô tả:
tr( musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>, <maker_pubkey> ), and( hash160(<hash1>), hash160(<hash2>), hash160(<hash3>), pk(<maker_pubkey>) )) Sử dụng tập lệnh taproot, chúng ta có thể sử dụng khóa công khai nội bộ 4-trên-4 (thông qua giao thức khóa công khai tổng hợp), nhờ đó che giấu hoàn toàn khóa băm cồng kềnh với sự hợp tác của tất cả các bên. Chúng ta sử dụng hash160 thay vì SHA256 để tiết kiệm không gian khối trong khi vẫn giữ tùy chọn sử dụng HTLC với cùng giá trị bí mật (preimage) trong Mạng Lightning.
- Các bên tham gia xây dựng một giao dịch cấp vốn , thanh toán các UTXO của mọi người vào địa chỉ đa chữ ký đã đề cập ở trên (có thể có tiền thừa). Các bên tham gia không ký vào giao dịch cấp vốn tại thời điểm này.
- Các bên tham gia tạo ra một giao dịch hết thời gian chờ , về cơ bản là một giao dịch hoàn tiền. Giao dịch hết thời gian chờ này trả lại số tiền từ đầu ra của giao dịch cấp vốn cho mỗi bên tham gia. Giao dịch hết thời gian chờ phải bao gồm một khóa thời gian tuyệt đối với thời gian mở khóa là Block Height$B$.
- Cả bên nhận lệnh và bên đặt lệnh đều ký xác nhận giao dịch hết thời gian chờ . Bên đặt lệnh đương nhiên không phản đối vì họ có quyền kiểm soát thời gian tuyệt đối.
- Người đặt lệnh tạo ra $n$ HTLC Mạng Lightning, mỗi HTLC trả một khoản phí hoán đổi tương ứng cho một trong đó những người nhận lệnh. HTLC dành cho người nhận lệnh $i$ sử dụng $SHA256(s_i)$ làm hàm băm thanh toán. Số tiền phí hoán đổi cho mỗi người nhận lệnh có thể khác nhau. Những người nhận lệnh chưa thể yêu cầu các HTLC này vì chỉ người đặt lệnh mới biết ảnh ngược ${s_1, s_2, …, s_n}$ của mỗi HTLC. Thời gian khóa tuyệt đối của các HTLC này phải ít nhất là $B + \Delta$, trong đó$\Delta$ là độ trễ hợp lý (tính bằng khối).
- Sau khi tất cả những người nhận lệnh đều nhận được HTLC qua các kênh tương ứng, họ đã cùng nhau ký tên và đăng tải giao dịch đầu tư .
- Mọi người đang chờ đợi giao dịch đầu tư được xác nhận bởi blockchain.
Người đặt hàng có ba lựa chọn.
1. Thi hành (Chuỗi)
Người đặt lệnh có thể sử dụng ảnh ngược ${s_1, s_2, …, s_n}$ lĩnh nhận đầu ra giao dịch tài trợ trong đường dẫn chi tiêu khóa băm. Giao dịch yêu cầu như vậy sẽ tiết lộ tất cả các ảnh ngược trong mạng, để người nhận lệnh có thể sử dụng các ảnh ngược này để lĩnh nhận số tiền họ đã nhận được trong HTLC của mình.
Ngay cả khi người đặt lệnh trì hoãn việc đăng giao dịch để nhận tiền cho đến phút cuối cùng, người nhận lệnh vẫn có một khoảng thời gian $\Delta$ để lĩnh nhận tiền trong HTLC của kênh tương ứng của họ.
2. Hợp tác (ngoài Chuỗi)
Bên đặt lệnh có thể chỉ định từng phần tử trong ${s_1, s_2, …, s_n}$ cho bên nhận lệnh tương ứng. Bên nhận lệnh có thể sử dụng các tiền ảnh này để lĩnh nhận HTLC trong kênh của họ. Đổi lại, các bên nhận lệnh phải hợp tác với bên đặt lệnh để ký kết giao dịch, từ đó giải phóng số tiền trong đầu ra giao dịch tiêm vào cho bên đặt lệnh.
Ngay cả khi ai đó đổi ảnh gốc lấy HTLC rồi từ chối giao chữ ký, người đặt hàng vẫn có thể thực thi giao dịch và lấy lại tiền từ kết quả giao dịch đầu tư trong Chuỗi.
Xin lưu ý rằng việc người đặt lệnh chỉ giao một phần của tiền ảnh (thay vì toàn bộ tiền ảnh) là không hợp lý, bởi vì về bản chất, mỗi tiền ảnh đại diện cho quyền lĩnh nhận một số tiền từ người đặt lệnh. Nếu người đặt lệnh muốn rút tiền trên Chuỗi, họ phải tiết lộ toàn bộ tiền ảnh, chứ không chỉ một phần.
3. Hết thời gian
Người đặt lệnh có thể chọn không tiết lộ bất kỳ ảnh trước nào. Do đó, người nhận lệnh sẽ không thể lĩnh nhận HTLC trong các kênh tương ứng của họ. Khi mạng đạt đến Block Height$B$, bất kỳ người nhận lệnh nào cũng có thể đăng giao dịch hết thời gian chờ , cho phép hoàn trả tiền cho tất cả người nhận lệnh. Sau $Delta$ khối nữa, HTLC trong các kênh tương ứng của họ cũng sẽ hết hạn.
hiệu suất
Nếu chúng ta sử dụng $n $ giao dịch hoán đổi tàu ngầm truyền thống, dấu vết tối thiểu trong Chuỗi sẽ là:
- Có $n$ giao dịch đầu tư khác nhau, mỗi giao dịch bao gồm ít nhất một đầu vào và một đầu ra.
- Với $n$ đầu vào khác nhau, hãy rút tiền từ mỗi địa chỉ ký quỹ (có thể gộp việc này thành một giao dịch duy nhất).
Về lý tưởng, phương pháp hoán đổi bên long của chúng tôi ở đây có thể giảm thiểu lần Chuỗi của ($n$ hoán đổi) xuống còn:
- Một giao dịch tài trợ sẽ có ít nhất $n$ đầu vào và ít nhất 1 đầu ra (có thể có nhiều hơn, vì có các đầu ra thay đổi).
- Một đầu vào lĩnh nhận đầu ra của giao dịch biên nhận đầu tư (có thể xử lý hàng loạt cùng với các giao dịch lĩnh nhận khác).
Cần lưu ý rằng nếu $n$ lớn, một số người nhận lệnh có thể không hợp tác. Để lĩnh nhận kết quả giao dịch tài trợ trên Chuỗi , người đặt lệnh có thể cần phải công bố lượng lớn mã băm RMD160 và một đoạn mã lớn trong kết quả chứng thực của giao dịch. Điều này có thể ảnh hưởng đến phân tích hiệu suất và việc lựa chọn $n$.
Trao đổi Chuỗi giữa người dùng đơn lẻ từ Chuỗi.
Bây giờ, chúng ta hãy xem phương pháp của chúng ta hoạt động như thế nào trong trường hợp ngược lại.
Tại thời điểm này, hai nhân vật tham gia vào giao dịch là:
- Các bên tham gia đơn lẻ : Nhiều bên tham gia nhỏ muốn trao đổi số dư trong Kênh Lightning để lấy một lượng nhỏ UTXO Chuỗi.
- Người đặt lệnh : Một cá nhân hoặc doanh nghiệp muốn trao đổi một lượng lớn UTXO Chuỗi lấy số dư trong Kênh Lightning.
Tại thời điểm này, thay vì tạo ra $n$ địa chỉ ký quỹ riêng biệt trên Chuỗi như trong các giao dịch hoán đổi ngầm truyền thống, bên đặt lệnh sẽ chuyển tiền vào một địa chỉ ký quỹ duy nhất, dự kiến sẽ được sử dụng trong một giao dịch duy nhất — bằng cách gửi tiền cho bên nhận (nếu giao dịch diễn ra suôn sẻ) hoặc trả lại tiền cho bên đặt lệnh (nếu giao dịch không diễn ra suôn sẻ).
- Người đặt hàng sẽ tạo ra $n$ giá trị bí mật ngẫu nhiên ${s_1, s_2, …, s_n}$ (mỗi giá trị tương ứng với một người nhận đơn hàng).
- Bên nhận lệnh và bên nắm giữ lệnh cùng nhau tạo ra một địa chỉ khóa băm gốc 1 trong n.
Đây là trường hợp số người ăn cùng một món ăn là 3, được biểu thị bằng một thuộc tính:
taker_joint_pubkey = musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>);tr( musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>, <maker_pubkey> ), { { and( hash160(<hash1>), pk(taker_joint_pubkey) ), and( hash160(<hash2>), pk(taker_joint_pubkey) ) }, and( hash160(<hash3>), pk(taker_joint_pubkey) ) }) Lưu ý rằng trong kịch bản này, "kẻ ăn" là người nhận chung tiền từ ba điều kiện chi tiêu khóa băm khác nhau. Nghĩa là, bất kỳ một trong ba tiền ảnh, <hash1> , <hash2> và <hash3> , đều có thể được kẻ ăn sử dụng để lĩnh nhận tiền trong đó.
- Bên đặt lệnh tạo một giao dịch cấp vốn , sử dụng UTXO của chính mình và thanh toán số tiền đó vào địa chỉ taproot đã đề cập ở trên (giao dịch có thể bao gồm đầu ra sắc lệnh). Bên đặt lệnh không ký giao dịch cấp vốn vào thời điểm này.
- Bên nắm giữ lệnh tạo ra một giao dịch hết thời gian chờ , tiêu thụ đầu ra của giao dịch cấp vốn và trả lại tiền cho bên nắm giữ lệnh. Giao dịch này bao gồm một khóa thời gian tuyệt đối với thời gian mở khóa là Block Height$B$.
- Bên nhận đơn hàng và bên đặt đơn hàng đều ký xác nhận giao dịch hết thời gian chờ . Bên nhận đơn hàng đồng ý chấp nhận vì giao dịch hết thời gian chờ có khóa thời gian tuyệt đối.
- Các thành viên tham gia cùng nhau tạo ra $n$ giao dịch yêu cầu bồi thường . Mỗi giao dịch lĩnh nhận sử dụng một nhánh chi tiêu khóa băm khác nhau từ giao dịch cấp vốn để chi tiêu số tiền và chia chúng cho các thành viên. Các thành viên cùng nhau ký tất cả $n$ giao dịch yêu cầu bồi thường ; không giao dịch nào được công khai cho đến khi một trong số ${s_1, s_2, …, s_n}$ được tiết lộ. Các thành viên sẵn sàng ký các giao dịch này vì họ không biển thủ tiền của chính mình. Mỗi thành viên $i$ phải có được một giao dịch lĩnh nhận đã được ký đầy đủ tương ứng với giá trị băm của riêng họ $RMD160(SHA256(s_i))$, do đó cho phép họ công bố lĩnh nhận sau khi họ biết $s_i$.
- Người đặt lệnh ký tên và công bố giao dịch đầu tư .
- Mọi người đang chờ đợi giao dịch đầu tư được xác nhận bởi blockchain.
- Các Eater tạo ra $n$ HTLC và thanh toán cho người giữ lệnh thông qua Mạng Lightning, trả số tiền cho giao dịch hoán đổi và sử dụng $SHA256(s_i)$ tương ứng của họ làm mã băm thanh toán. Các Eater có thể sử dụng các số tiền khác nhau. Thời gian chờ cho mỗi HTLC có thể tối đa là $B - \Delta$, trong đó $\Delta$ là độ trễ thời gian hợp lý (tính bằng khối). Người giữ lệnh phải đợi cho đến khi tất cả các HTLC đã được giao trước khi quyết toán bất kỳ trong đó.
- Người đặt lệnh có thể sử dụng ảnh ngược ${s_1, s_2, …, s_n}$ để quyết toán bất kỳ HTLC nào (hoặc quyết toán tất cả). Tức là, bất kỳ người nhận lệnh nào cũng sẽ nhận được ít nhất một ảnh ngược $s_i$. Lưu ý rằng một người đặt lệnh hợp lý sẽ hoặc lĩnh nhậntất cả HTLC hoặc không yêu cầu gì cả . Điều này là bởi vì việc tiết lộ dù chỉ một $s_i$ cũng sẽ cho phép người nhận lệnh rút tiền từ kết quả của giao dịch đầu tư.
1. Thi hành (Chuỗi)
Bất kỳ người mua nào $i$, sau khi biết ảnh ngược $s_i$, đều có thể công bố một giao dịch yêu cầu (đã được tất cả những người mua ký trước đó). Giao dịch nguyên tử này sẽ phân phối công bằng số tiền của người đặt lệnh cho những người mua.
Ngay cả khi bên đặt lệnh muốn đợi đến giây phút cuối cùng trước khi HTLC (về cơ bản là từ bên nhận lệnh) trong Kênh Lightning của họ hết hạn trước khi tiết lộ tất cả các tiền ảnh ${s_1, s_2, …, s_n}$, nghĩa là trong trường hợp xấu nhất, bên nhận lệnh vẫn sẽ có một khoảng thời gian khối $\Delta$ để công bố và xác nhận giao dịch yêu cầu .
2. Hợp tác (ngoài Chuỗi)
Khi bên đặt lệnh lĩnh nhận tất cả các HTLC trong Kênh Lightning của họ—nghĩa là tất cả các tiền ảnh ${s_1, s_2, …, s_n}$ đã được công khai—bên đặt lệnh có thể hợp tác với bên nhận lệnh để ký một phiên bản mới của giao dịch lĩnh nhận, sử dụng khóa công khai nội bộ 4-of-4. Điều này cho phép họ ẩn nhánh chi tiêu khóa băm trong hợp đồng, cải thiện quyền riêng tư và hiệu quả trên Chuỗi.
Nếu ai đó không ký vào phiên bản giao dịch lĩnh nhận mới này, người nhận có thể quay lại công bố giao dịch yêu cầu của riêng họ, miễn là việc đó diễn ra trước Block Height$B$ (trước khi giao dịch hết hạn trở thành giao dịch hợp lệ).
hết giờ
Nếu bên đặt lệnh không làm gì (không giải phóng ảnh trước), HTLC từ bên nhận lệnh sẽ hết hạn ở Block Height$B - \Delta$, do đó trả lại số dư Kênh Lightning cho bên nhận lệnh. Sau đó, ở Block Height$B$, bên đặt lệnh có thể sử dụng giao dịch hết thời gian chờ để dọn dẹp đầu ra giao dịch cấp vốn.
Nếu bên nhận lệnh không phản hồi sau khi bên đặt lệnh công bố giao dịch đầu tư , bên đặt lệnh không cần làm gì cả, chỉ cần đợi đến Block Height$B$ rồi mới công bố giao dịch hết thời gian chờ.
hiệu suất
Nếu chúng ta sử dụng $n $ giao dịch hoán đổi tàu ngầm truyền thống, dấu vết tối thiểu trong Chuỗi sẽ là:
- $n$ kết quả ký quỹ riêng biệt (có thể được gộp lại thành một giao dịch đầu tư duy nhất).
- $n$ giao dịch khác nhau được sử dụng để lĩnh nhận khoản tiền ký quỹ nêu trên, mỗi giao dịch chứa ít nhất một đầu vào và một đầu ra (không thể xử lý theo lô).
Về lý tưởng, phương pháp hoán đổi bên long của chúng tôi ở đây có thể giảm thiểu lần Chuỗi của ($n$ hoán đổi) xuống còn:
- Một khoản tiền ký quỹ (có thể được gộp vào một giao dịch cấp vốn lớn hơn).
- Một giao dịch lĩnh nhận với 1 đầu vào và $n$ đầu ra (phân bổ tiền cho người nhận).
Trong trường hợp một số người nhận lệnh hoặc người đặt lệnh không hợp tác, người nhận lệnh cần sử dụng một trong đó các nhánh khóa băm để lĩnh nhận tiền trong Chuỗi.
Giảm quấy rối
Mặc dù rõ ràng là có thể mở rộng các giao dịch hoán đổi ngầm (submarine swaps) thành các thỏa thuận bên long, nhưng hiệu quả cụ thể đạt được vẫn còn gây tranh cãi, vì điều này phụ thuộc rất nhiều vào sự hợp tác của các bên liên quan. Điều này đặc biệt đúng đối với các giao dịch hoán đổi từ Chuỗi) sang Chuỗi), nơi một bên nhận lệnh không hợp tác có thể buộc bên đặt lệnh phải trả thêm phí (bằng cách công bố một loạt các mã băm và tiền ảnh dường như không cần thiết) lĩnh nhận tiền.
Các cuộc tấn công quấy rối tương tự cũng tồn tại trong các thỏa thuận trao đổi tàu ngầm truyền thống, nhưng chúng có tác động lớn hơn trong hoàn cảnh bên long bên vì một con sâu làm rầu nồi canh (làm cho việc trao đổi trở nên tốn kém hơn cho tất cả mọi người).
Để hạn chế hành vi gây rối của những kẻ cố gắng đánh cắp đơn hàng, người đặt hàng có thể áp dụng các kỹ thuật sau:
- Phí giao dịch. Bên đặt lệnh có thể bao gồm phí giao dịch trong số tiền Hóa đơn Lightning, yêu cầu bên nhận lệnh phải trả phí này (trong các giao dịch hoán đổi từ Chuỗi trong Chuỗi); hoặc, họ có thể giảm số tiền trả cho bên nhận lệnh bằng HTLC (trong các giao dịch hoán đổi từ Chuỗi ngoài Chuỗi). Điều này sẽ khích lệ bên đặt lệnh cung cấp dịch vụ hoán đổi và làm cho các cuộc tấn công quấy rối trở nên tốn kém hơn.
- Hệ thống đặt cọc trước. Bên đặt lệnh có thể buộc bên nhận lệnh phải đặt cọc trước một tỷ lệ nhỏ số tiền hoán đổi bằng HTLC (sử dụng "hóa đơn HODL"). Nếu bên nhận lệnh chấp thuận giao dịch trong quá trình này, bên đặt lệnh có thể hủy hóa đơn và hoàn trả tiền đặt cọc. Nếu bên nhận lệnh không hợp tác, bên đặt lệnh có thể quyết toán hóa đơn và rút tiền đặt cọc như một khoản phạt. Khoản tiền đặt cọc này không phải là không cần tin tưởng – bên đặt lệnh có thể rút lại vô điều kiện; do đó, cần có một mức độ tin tưởng, trách nhiệm và uy tín nhất định.
- Nặc danh. Người tham gia đấu thầu có thể mua một số token eCash từ người đặt giá thầu, và sau đó đổi chúng lấy tư cách tham gia vào một giao dịch hoán đổi ngầm bên long với người đặt giá thầu.
- Trái phiếu trung thành. Điều này sẽ cho phép những người đặt hoặc nhận lệnh ẩn danh đổi một lượng Bitcoin nặc danh để có được danh tính người đặt/nhận lệnh vĩnh viễn, chứng minh sự tham gia trung thực của họ vào giao dịch.
Đối với công việc
- Hợp đồng khóa tại một thời điểm cụ thể (PTLC) trên mạng Lightning sẽ cho phép cải thiện đáng kể quyền riêng tư Chuỗi và hiệu quả trong các giao dịch hoán đổi ngầm bên long theo cả hai chiều. Vậy, các giao dịch hoán đổi ngầm bên long dựa trên PTLC sẽ trông như thế nào? Và chúng sẽ thực sự mang lại sự cải thiện hiệu quả đến mức nào?
- Liệu có thể thực hiện một giao dịch hoán đổi tàu ngầm n-to-m, trong đó n người bán UTXO trong Chuỗi giao dịch với m người mua chúng thông qua Lightning Payment?
(qua)
