hình ảnh

Trong bài viết trước, chúng tôi đã giải thích chi tiết cách thức hoạt động của các kênh thanh toán và nhiều cách khác nhau để đảm bảo rằng các khoản thanh toán diễn ra an toàn. Tuy nhiên, các chức năng này không đủ để hỗ trợ mạng kênh thanh toán có thể sử dụng: ngay cả khi chúng tôi chắc chắn rằng mọi người tham gia trong mỗi kênh đều trung thực và đáng tin cậy, không có gì đảm bảo rằng thanh toán qua nhiều kênh cũng an toàn. Đó là lý do tại sao chúng ta cần hợp đồng thông minh "HTLC (Hash-Time Lock-Contract)". Trong bài viết này, chúng tôi giải thích cách thức hoạt động của HTLC và sử dụng một ví dụ để cho thấy cách thức thanh toán nhiều chặng được triển khai trong Lightning Network.

Hợp đồng khóa thời gian băm (HTLC)

Cấu trúc của HTLC không phức tạp nhưng rất hiệu quả. Nó cho phép chúng tôi tạo các khoản thanh toán với "thời gian hết hạn" rõ ràng. Như bạn có thể đoán, hợp đồng HTLC bao gồm hai phần: xác minh hàm băm và xác minh hết hạn.

H = Hash(R)

Hãy bắt đầu với giá trị băm (hash). Để tạo giao dịch thanh toán bằng HTLC, trước tiên bạn tạo một giá trị bí mật R rồi tính giá trị băm của nó. Bất kỳ từ nào, bất kỳ số nào cũng có thể đóng vai trò là giá trị bí mật này, bởi vì, đối với hàm băm, chúng đều là sự kết hợp của một loạt dữ liệu và không có sự khác biệt.

Giá trị băm H này sẽ được đặt trong tập lệnh khóa của đầu ra giao dịch. Theo cách này, chỉ những người biết giá trị bí mật tương ứng với H mới có thể sử dụng đầu ra này. Và R được gọi là "preimage".

Phần thứ hai của HTLC là xác minh thời gian hết hạn. Nếu giá trị bí mật không được tiết lộ kịp thời, khoản thanh toán sẽ không được chi tiêu và người gửi sẽ nhận lại được toàn bộ số tiền.

1. Hãy xem xét một giao dịch thanh toán HLTC cho ai đó:

2. HASH160 EQUAL

3. IF    

4. # Kiểm tra xem R được cung cấp có phải là tiền ảnh của H không

5.         CHECKSIG

6. ELSE    

7. # Kiểm tra xem người tiết lộ R có phải là người nhận giao dịch ban đầu không

8.       CHECKLOCKTIMEVERIFY    

9. # Kiểm tra xem khóa thời gian đã hết chưa

10.       CHECKSIG

11. ENDIF

Sau khi R chính xác (hình ảnh trước của giá trị băm H) được tiết lộ, chúng tôi sẽ tham gia quy trình IF để xác minh thêm liệu người cung cấp R có phải là đối tượng thanh toán khi bắt đầu giao dịch thanh toán hay không. Khi sử dụng đầu ra này, người nhận chỉ cần cung cấp một tập lệnh mở khóa rất đơn giản:

Nếu R do tập lệnh mở khóa cung cấp là sai, chúng tôi sẽ chuyển sang quy trình KHÁC và trước tiên hãy xác minh xem khóa thời gian có được mở khóa hay không. Nếu khóa thời gian đã được mở khóa, người gửi có thể lấy lại tất cả số tiền. Kịch bản mở khóa để rút tiền cũng tương tự, điểm khác biệt duy nhất là để tham gia quy trình ELSE, cần cung cấp một giá trị bí mật sai:

Tất nhiên, đây chỉ là một triển khai rất cơ bản của HTLC, đại diện cho một khoản thanh toán có thời hạn thông thường. Bạn có thể thêm bất kỳ số điều kiện nào khác vào tập lệnh, ví dụ: xóa xác minh khóa chung trong quy trình IF, để bất kỳ ai biết giá trị bí mật R đều có thể sử dụng đầu ra này; bạn cũng có thể thêm các hạn chế đa chữ ký để yêu cầu The chữ ký của nhiều khóa riêng đặt trước có thể được mở khóa.CHECKLOCKTIMEVERIFYNgoài ra, trong trường hợp này, opcode chúng tôi sử dụng làCHECKSEQUENCEVERIFY, mã lệnh này sử dụng một giá trị tuyệt đối để xác định khóa thời gian, có nghĩa là: "không thể khai thác đầu ra này cho đến khối #546212". Trong Lightning Network, một khóa thời gian khác được sử dụng, một khóa "linh hoạt" hơn:

, sử dụng các giá trị tương đối, nghĩa là gần với: "Đầu ra này không sử dụng được cho 1000 khối sau khi giao dịch sử dụng nó trên chuỗi" (Ghi chú của người dịch: Các giá trị ở đây là ví dụ, thực tế là các giá trị khác có thể được dùng).

Trường hợp mạng Lightning

hình ảnh

Mô tả hình ảnh

hình ảnh

Mô tả hình ảnh

1. - Từng bước phân tích định tuyến thanh toán trong Lightning Network -

2. Eric tạo một giá trị bí mật R và gửi hàm băm của nó cho Alice (anh ấy sẽ không tiết lộ R cho bất kỳ ai khác)

3. Alice sử dụng giá trị băm này để tạo HTLC và khóa thời gian được đặt thành 10 khối tiếp theo và số tiền đầu ra là 1,003 btc. 0,003 btc bổ sung này là phí cho bên trung gian của chuỗi kênh thanh toán. Vì vậy, Alice hiện khóa 1,003 btc bằng HTLC và các điều kiện cụ thể của HTCL được thể hiện bằng ngôn ngữ đơn giản như sau: "Alice sẽ trả cho Bob 1,003 btc, miễn là anh ấy có thể chuyển giao giá trị bí mật R trong vòng 10 khối, nếu không thì tiền sẽ được trả lại cho Alice". Số dư của kênh giữa họ cũng sẽ thay đổi do giao dịch cam kết này. Bây giờ Bob có 2 btc trong kênh, Alice có 0,997 btc và 1,003 btc bị khóa trong HTLC

4. Khi Bob đến đây, anh ta có thể định đoạt giao dịch cam kết của Alice theo ý muốn (giao dịch HTLC này được gửi qua kênh giữa họ). Anh ấy tạo đầu ra HTLC trong kênh giữa anh ấy và Carol, số lượng là 1,002, khóa thời gian được đặt thành 9 khối và sử dụng giá trị băm do Alice cung cấp. Bob biết rằng nếu Carol muốn lấy tiền, anh ấy phải tìm ra giá trị bí mật R để mở khóa HTLC này và khi cô ấy làm vậy, anh ấy sẽ biết R này, vì vậy anh ấy cũng có thể mở khóa HTLC của Alice và nhận được 1,003 btc. Nếu Carol không thể tìm thấy giá trị R bí mật này, cả Bob và Alice đều có thể lấy lại tiền sau khi khóa thời gian được mở khóa. Lưu ý rằng số tiền mà Bob đã gửi ít hơn 0,001 btc so với số tiền anh ấy có thể nhận được, đây là số tiền phí mà anh ấy đã tính. Số dư của Bob và Carol trong kênh trở thành: Carol sở hữu 2 btc, Bob sở hữu 0,998 btc và 1,002 btc bị khóa trong HTLC

5. Sau khi Carol nhận được giao dịch cam kết do Bob gửi, cô ấy cũng làm như vậy và tạo một HTLC trong kênh với Diana, sử dụng cùng giá trị băm mà Bob đã cung cấp, đặt khóa thời gian thành 8 khối và số tiền là 1,001 btc. Nếu Diana có thể tiết lộ giá trị bí mật R trong vòng 8 khối, cô ấy có thể mở khóa HTLC và nhận được 1,001 btc. Tương ứng, Carol cũng sẽ biết giá trị bí mật, mở khóa HTLC mà Bob đã đưa cho cô ấy, nhận được 1,002 btc và kiếm được 0,001 btc. Số dư trong kênh của Carol và Diana trở thành: Diana sở hữu 2 btc, Carol sở hữu 0,999 btc và 1,001 btc bị khóa trong HTLC

6. Cuối cùng, khi Diana gửi HTLC (sử dụng cùng giá trị băm làm khóa) cho Eric thông qua kênh, cô ấy đặt giá trị thành 1 btc và khóa thời gian thành 7 khối. Số dư kênh của Diana và Eric trở thành: Eric sở hữu 2 btc, Diana sở hữu 1 btc và 1 btc bị khóa trong HTLC

7. Bây giờ, chúng ta đã đi đến cuối chuỗi thanh toán này. Eric sở hữu giá trị bí mật R này và giá trị băm của R này được sử dụng trong tất cả các giao dịch cam kết HTLC. Eric có thể mở khóa HTLC do Diana gửi cho anh ấy và nhận được 1 btc; và sau khi Eric lấy lại được tiền, Diana cũng sẽ biết R này. Số dư kênh giữa Diana và Eric sẽ trở thành: Eric sở hữu 3 btc và Diana sở hữu 1 btc.

8. Sau khi Diana nhận được bí mật, cô ấy cũng đã sử dụng nó để mở khóa HTLC do Carol gửi cho cô ấy, nhận được 1,001 btc và tiết lộ giá trị bí mật cho Carol. Số dư trong kênh của họ trở thành: Diana có 3,001 btc và Carol có 0,999 btc.

9. Sau khi Carol nhận được giá trị bí mật R, cô ấy đã mở khóa 1,001 btc do Bob gửi, vì vậy Bob cũng biết giá trị bí mật. Số dư trong kênh của họ trở thành: Carol có 3,002 btc và Bob có 0,998 btc

Cuối cùng, Bob sử dụng giá trị bí mật R để nhận được 1,003 btc trong kênh với Alice. Vì vậy, số dư trong kênh trở thành: Bob sở hữu 3,003 btc, Alice sở hữu 0,997.

Sau quá trình như vậy, Alice đã trả cho Eric 1 btc mà không mở một kênh kết nối trực tiếp nào khác giữa họ. Trong toàn bộ chuỗi thanh toán, không ai cần phải tin tưởng người khác và họ cũng kiếm được 0,001 btc nhờ các dịch vụ trung gian. Ngay cả khi thanh toán bị kẹt tại một thời điểm nào đó, sẽ không ai bị lỗ vì tiền vẫn bị khóa ở đó và có thể lấy lại được sau một thời gian.

lỗi rõ ràng

Trong ví dụ của chúng tôi, toàn bộ quá trình diễn ra suôn sẻ và không bị cản trở, nhưng trong cuộc sống thực, nó giống như cái gọi là "Định luật Murphy": Nếu điều gì đó tồi tệ có thể xảy ra, thì điều tồi tệ này sẽ xảy ra. Vì vậy, chúng ta phải xem xét cơ chế "bảo vệ" của Lightning Network.

Từ quan điểm thực tế, chuỗi thanh toán càng dài thì khả năng tiền cuối cùng sẽ không được chuyển đến càng lớn: một số người tham gia có thể đóng kênh hoặc một số nút sẽ ngoại tuyến. Hãy xem xét hai kịch bản lỗi có thể xảy ra.

hình ảnh

Mô tả hình ảnh

- Tiền không thể được gửi vì một kênh bị đóng -

Khi Diana nhận được giá trị bí mật, cô ấy ngay lập tức rút tiền và tiết lộ giá trị bí mật cho Carol. Carol cũng muốn lấy lại tiền từ HTLC do Bob gửi, nhưng Bob không trả lời, để tránh rủi ro, cô ấy đóng kênh và gửi giao dịch cam kết cuối cùng trong tay (tức là đầu ra HTCL do Bob gửi trước khi giao dịch) được phát lên mạng Bitcoin và vì cô ấy biết giá trị bí mật nên cô ấy có thể lấy lại tiền của mình. Tại thời điểm này, Bob vẫn còn ba ngày để lấy lại tiền từ Alice (vì giao dịch của Carol đã được thực hiện trực tuyến, Bob có thể dễ dàng biết được giá trị của R). Nếu không, Alice có thể rút tiền ngay khi khóa thời gian được mở khóa.

Có thể thấy rằng ngay cả khi một người tham gia rời khỏi mạng vì một lý do nào đó, thì bản thân TA là người duy nhất có thể bị mất tiền, trong khi tiền của những người khác vẫn an toàn.

định tuyến lại

hình ảnh

Mô tả hình ảnh

hình ảnh

Mô tả hình ảnh

- Alice nếu sử dụng đường dẫn khác -

hình ảnh

Mô tả hình ảnh

- Alice đã "hủy" khoản thanh toán cũ, khoản thanh toán mới hiện có thể được gửi một cách an toàn -

Số tiền thanh toán

Bạn cũng có thể nhận thấy rằng khi Alice "hủy" khoản thanh toán đầu tiên của mình, bây giờ có thể an toàn để bắt đầu một khoản thanh toán mới, nhưng điều này không thay đổi thực tế là số tiền từ khoản thanh toán đầu tiên của cô ấy vẫn bị khóa và cô ấy có thể không có đủ tiền để bắt đầu thanh toán lần thứ hai. Đây là lý do tại sao khi sử dụng Lightning Network, số tiền phải nhỏ hơn khi thanh toán bằng HTLC. Vì giao dịch cam kết sẽ không bị xâu chuỗi nên số tiền có thể được chia thành nhiều khoản nhỏ. Bằng cách này, bất cứ khi nào một đường dẫn bị lỗi, chỉ một phần nhỏ số tiền sẽ bị đóng băng (nghĩa là phần cuối cùng được gửi).

Giao thức chuyển giao

Một tính năng rất quan trọng khác của Lightning Network: tất cả thông tin về đường dẫn này là hoàn toàn ẩn danh. Có nghĩa là đối với bất kỳ người tham gia nào thì TA cũng chỉ biết phần liên quan đến mình, ví dụ Carol thanh toán giống như Bob chuyển tiền cho Diana và cô ấy không biết rằng Bob sẽ chuyển tiền từ Alice. và người ta không biết rằng Diana sẽ tiếp tục chuyển tiền cho Eric.

Lightning Network sử dụng giao thức đa mã hóa Sphinx. Khi sử dụng Lightning Network, Alice áp dụng một lớp mã hóa cho mọi phần của mạng, bắt đầu từ cuối đường dẫn thanh toán. Cô ấy mã hóa tin nhắn cho Eric bằng khóa chung của Eric. Tin nhắn được mã hóa này sẽ được nhúng trong tin nhắn gửi cho Diana và toàn bộ tin nhắn sẽ được mã hóa lại bằng khóa công khai của Diana. Sau đó, tin nhắn cho Diana sẽ được lồng trong tin nhắn cho Carol, và toàn bộ tin nhắn sẽ được mã hóa lại bằng khóa chung của Carol. Lặp đi lặp lại thao tác này nhiều lần để lấy tin tức có thể chuyển cho người tiếp theo. Theo cách này, Bob chỉ có thể giải mã lớp ngoài cùng của tin nhắn, lấy nội dung dành cho anh ấy; sau đó chuyển tiếp tin nhắn tới Carol; Carol cũng làm như vậy. Đối với mỗi người đi qua, chỉ những thông tin thực sự cần thiết mới được tiết lộ: số tiền đã thanh toán, số tiền hoa hồng, nội dung của khóa thời gian, v.v.

Để mọi người không suy ra độ dài của chuỗi từ độ dài của tin nhắn, độ dài của tin nhắn luôn giống nhau, luôn như thể có 20 người tham gia vào chuỗi. Tất cả mọi người, kể cả người cuối cùng, đều nhận được hình ảnh có cùng kích thước, nghĩ rằng có 20 người khác ngoài họ.

Lợi ích và kịch bản ứng dụng của Lightning Network

• Tất nhiên, lợi ích của Lightning Network không chỉ là khả năng mở rộng như nhiều người vẫn nghĩ. Hãy nghĩ về những khả năng mà Lightning Network mang lại.

• Giao dịch tức thời. Khi sử dụng Lightning Network, các giao dịch gần như diễn ra ngay lập tức. Vì vậy, việc mua cà phê bằng bitcoin trở nên khả thi

• Trao đổi chênh lệch giá. Hiện tại, việc chuyển tiền từ một sàn giao dịch này sang một sàn giao dịch khác là bất tiện, phải chờ từ 3 đến 6 khối để giao dịch được xác nhận. Nếu các sàn giao dịch có thể sử dụng Lightning Network, người dùng có thể chuyển tiền ngay lập tức và tham gia kinh doanh chênh lệch giá. Các sàn giao dịch cũng không còn cần ví lạnh để lưu trữ tiền, giúp giảm đáng kể nguy cơ bị đánh cắp.

• thanh toán nhỏ. Phí chuỗi khối bitcoin quá cao đối với các khoản thanh toán nhỏ. Thật khó để tưởng tượng bất cứ ai sẵn sàng trả 0,001 btc chỉ để chuyển số tiền tương tự hoặc thậm chí ít hơn. Với Lightning Network, bạn có thể chuyển ngay bất kỳ số tiền nào, ví dụ: bạn có thể thanh toán phí mạng của mình bằng MB.

• Hợp đồng và giao dịch tài chính thông minh. Các hợp đồng tài chính cực kỳ nhạy cảm với độ trễ và thường yêu cầu nhiều tính toán. Bằng cách chuyển phần lớn gánh nặng ra khỏi chuỗi khối, chúng tôi có cơ hội tạo các giao dịch và hợp đồng rất phức tạp mà không cần ghi lại tất cả chúng trên chuỗi khối.

• sự riêng tư. Trong Lightning Network, các giao dịch riêng tư hơn so với trên chuỗi khối Bitcoin, vì những người tham gia chuỗi thanh toán không biết nguồn gốc và đích đến của giao dịch.

Tóm lại là

(qua)

liên kết

• Lightning network in depth, part 1: Payment channels

• “Mastering bitcoin” — Andreas M. Antonopoulos

• Lightning network whitepaper

• Segregated witness for dummies

(qua)

Liên kết gốc:

https://medium.com/softblocks/lightning-network-in-depth-part-2-htlc-and-payment-routing-db46aea445a8

Tác giả: Magomed Aliev

Bản dịch: A Jian