Các máy tính trong mạng giao tiếp với nhau theo các giao thức. Ở đây, "giao thức" đề cập đến một hệ thống các quy tắc chỉ định cách truyền và giải thích thông điệp. Phần truyền thông báo thanh toán của giao thức mạng sét được mô tả bởi BOLT#4, còn được gọi là "Giao thức định tuyến hành tây (Giao thức định tuyến hành tây)".
Onion Routing là một công nghệ có trước Lightning Network 25 năm. Nó cũng được sử dụng trong Tor, đó là nguồn gốc của cái tên "Tor" ("Bộ định tuyến hành tây") Lightning Network sử dụng một phiên bản được sửa đổi một chút có tên là "định tuyến củ hành dựa trên nguồn gốc", viết tắt là "SPHINX". Trong bài viết này, chúng ta sẽ nói về cách hoạt động của định tuyến hành tây.
Tại sao sử dụng định tuyến củ hành?
Nhiều giao thức liên lạc khác nhau tồn tại trên thế giới, nhưng vì Lightning Network là một mạng thanh toán, nên chọn một giao thức tiết lộ càng ít thông tin càng tốt về khoản thanh toán được chuyển tiếp.
Nếu Lightning Network sử dụng cùng một giao thức như Internet, thì mọi bên trung gian sẽ biết ai là người gửi thanh toán, ai là người nhận và những bên trung gian khác trên đường đi là ai. Định tuyến củ hành là một lựa chọn tốt vì đặc điểm của nó đảm bảo các nút trung gian:
Chỉ biết nút trước đó của bạn (người đã gửi tin nhắn cho bạn) và nút tiếp theo (nơi bạn muốn chuyển tiếp tin nhắn).
không biết độ dài của toàn bộ đường dẫn;
Không biết mình đang ở đâu trên đường đi.
Tổng quan về định tuyến hành tây
Hãy sử dụng một bưu kiện như một phép loại suy để giải thích cách thức hoạt động của định tuyến củ hành.
Giả sử Alice muốn trả tiền cho Dina. Đầu tiên, Alice cần tìm một con đường khả thi cho khoản thanh toán của mình:
Alice→Bob→Chan→Dina
Sau đó, cô ấy xây dựng một "củ hành tây". Cô ấy bắt đầu với Dina (từ cuối con đường). Cô ấy đặt một tin nhắn bí mật (nội dung thanh toán) trong một gói gửi cho Dina và khóa nó bằng một chiếc chìa khóa mà chỉ cô ấy và Dina biết. Bây giờ, cô ấy đặt gói hàng này vào một gói hàng khác để gửi cho Chan, và khóa gói hàng cho Chan bằng một chiếc chìa khóa mà chỉ cô ấy và Chan biết. Đúng và vân vân.
Alice gửi hành (gói) cuối cùng cho người trung gian đầu tiên trên đường đi, Bob. Bob mở gói hàng của mình bằng chìa khóa của chính mình và thấy rằng gói hàng tiếp theo là dành cho Chan. Vì vậy, anh ấy đã chuyển gói hàng cho Chan. Chan cũng vậy, sau khi mở gói hàng, anh ấy đã chuyển gói hàng bên trong cho Dina. Cuối cùng, Dina mở gói hàng của mình và tìm thấy thông báo thanh toán bên trong.
Trong định tuyến củ hành, những người trung gian như Bob và Chan không biết nội dung của tin nhắn tới Dina, cũng như độ dài của toàn bộ đường dẫn thanh toán. Điều duy nhất họ biết là ai đã chuyển tiếp gói hàng cho họ và ai sẽ nhận nó tiếp theo. Điều này đảm bảo tính riêng tư của tin nhắn và tính bảo mật của đường dẫn. Mỗi người trung gian chỉ có thể chạm vào lớp tin nhắn được tạo riêng cho TA.
Trong định tuyến củ hành dựa trên nguồn của Lightning Network, người gửi chọn đường dẫn thanh toán và xây dựng một củ hành hoàn chỉnh cho đường dẫn đó, có thể được xem như một lỗ hổng bảo mật (Ghi chú của người dịch: Vị trí mạng của người nhận phải được hiển thị cho người gửi). Các sơ đồ định tuyến khác, chẳng hạn như "định tuyến mù" (bản dịch tiếng Trung), giải quyết vấn đề này bằng cách làm xáo trộn một phần đường dẫn thanh toán tới người gửi. Tuy nhiên, trong bài viết này, chúng tôi chỉ tập trung vào SPHINX.
Lắp ráp hành tây
Bây giờ, chúng ta hãy xem đặc điểm kỹ thuật của hành tây định tuyến. Lúc đầu, chúng ta cần xác định những điều này:
Người gửi là "nút ban đầu" (Alice);
Người nhận là "nút cuối cùng" (Dina);
Mỗi nút trung gian trên đường dẫn thanh toán là một "hop" (Bob và Chan);
Thông tin liên lạc giữa mỗi hop được gọi là "hop tải".
Cấu tạo nhảy tải
Khi Alice đã chọn một đường dẫn thanh toán, cô ấy sẽ lấy thông tin cho từng kênh thanh toán từ giao thức tin đồn để tạo tải trọng cho mỗi bước nhảy, về cơ bản là cho mỗi bước nhảy biết cách tạo HTLC cho khoản thanh toán được chuyển tiếp (hợp đồng khóa thời gian băm).
Để thiết lập một HTLC phù hợp, mỗi bước nhảy cần:
Số tiền cần chuyển;
giá trị bí mật được thanh toán;
ID của kênh thanh toán tiếp tục gửi hành;
Độ dài của khóa thời gian.
Hầu hết dữ liệu này đến từ thông báo "cập nhật kênh", chứa thông tin về phí định tuyến, yêu cầu sự kiện và ID kênh thanh toán. Tổng số tiền cần chuyển tiếp là tổng của số tiền đã thanh toán cộng với phí tính cho mỗi lần nhảy tiếp theo; trong khi giá trị bí mật của khoản thanh toán được Dina tính toán và nhúng vào hóa đơn thanh toán (được thông báo bằng tin nhắn hành động cho từng người nhảy lò cò).
Alice bắt đầu với nút cuối cùng Dina. Cô ấy bao gồm số tiền chuyển tiếp, giá trị thời lượng khóa thời gian, giá trị bí mật thanh toán và số tiền thanh toán trong gói. Lưu ý rằng cô ấy không cần thêm ID kênh vì Dina là nút cuối cùng và không cần chuyển tiếp khoản thanh toán cho người khác.
Thoạt nhìn, việc cung cấp số tiền chuyển tiếp có vẻ dư thừa vì số tiền này giống với số tiền thanh toán. Tuy nhiên, thanh toán nhiều đường sẽ gửi số tiền thanh toán qua nhiều đường dẫn và khi đó hai giá trị sẽ không khớp.
Trong tải trọng của Chan, Alice thêm ID kênh của Chan và Dina. Cô ấy cũng đã thêm số tiền chuyển tiếp và giá trị khóa thời gian. Cuối cùng, Alice tạo một tải trọng cho Bob. Chan tính phí 100 Satoshi cho khoản thanh toán qua kênh giữa cô ấy và Dina, vì vậy Alice cần nói với Bob rằng số tiền chuyển tiếp là khoản thanh toán cộng với phí xử lý. Theo thông báo cập nhật kênh của Chan, giá trị khóa thời gian cũng đã được tăng thêm 20 (tính theo khối). Cuối cùng, Alice cũng xem xét các yêu cầu về phí xử lý và khóa thời gian của Bob, đồng thời đưa cho anh ta một HTLC có thời lượng khóa là 700040 và giá trị là 100200 Satoshi.
Giá trị bí mật được chia sẻ và tạo khóa
Tiếp theo, Alice chuẩn bị hành tây bằng cách tạo một bí mật chung cho mỗi bước nhảy (bao gồm cả nút cuối cùng). Giá trị bí mật được chia sẻ này có thể được tạo ra bởi Alice và bước nhảy mục tiêu tương ứng bằng cách nhân khóa riêng của cô ấy với khóa chung của bên kia.
Một giá trị bí mật được chia sẻ là cần thiết cho định tuyến hành tây, cho phép Alice và mỗi bước nhảy lấy cùng một khóa. Sau đó, Alice sử dụng các phím đó để làm xáo trộn từng lớp của củ hành và bước nhảy đó sử dụng các phím đó để giải mã.
Để bảo vệ quyền riêng tư của Alice, cô ấy tạo khóa phiên một lần cho một củ hành, thay vì sử dụng khóa công khai của nút riêng, để lấy giá trị bí mật được chia sẻ. Cô ấy sử dụng khóa phiên này cho bước nhảy đầu tiên và sau đó, với mỗi bước nhảy tiếp theo, Alice ngẫu nhiên hóa khóa một cách xác định bằng cách nhân khóa mới nhất với một hệ số mù. Chúng được sử dụng để tạo khóa giá trị bí mật được chia sẻ mà chúng tôi gọi là "khóa tạm thời".
Bob, Chan và Dina, tất cả đều cần nhận được cùng một giá trị bí mật như Alice, vì vậy họ cần biết khóa tạm thời để sử dụng trong phiên của mình. Alice chỉ đặt khóa đầu tiên trong củ hành để tiết kiệm kích thước tin nhắn. Mỗi bước nhảy tính toán khóa phù du tiếp theo và nhúng nó vào hành tây cho nút tiếp theo. Mỗi bước nhảy có thể sử dụng khóa công khai và giá trị bí mật được chia sẻ của riêng mình để tính hệ số mù được Alice sử dụng để xác định khóa phù du tiếp theo.
Như đã đề cập trước đó, giá trị bí mật được chia sẻ sẽ được sử dụng để tạo một số khóa và Alice và bước nhảy tương ứng có thể sử dụng các khóa này để thực hiện một số thao tác trên hành. Chúng ta hãy xem những gì mỗi phím làm.
Chìa khóa Rho
Khóa Rho được Alice sử dụng để mã hóa một lớp hành tây; điều này sẽ làm xáo trộn nội dung của tải trọng để người bên ngoài không thể giải mã được. Chỉ chủ sở hữu của khóa rho mới có thể giải mã tải trọng. Đó là những gì nút nhận được hành tây phải làm: sử dụng giá trị bí mật được chia sẻ với Alice để lấy khóa rho, sau đó giải mã hành tây và đọc nội dung.
Mukey
Alice sử dụng phím mu để tạo tổng kiểm tra cho mỗi tải trọng. Cô ấy cũng chuyển tổng kiểm tra cho bước nhảy nhận được củ hành. Lần lượt, bước nhảy này sử dụng phím mu để tạo tổng kiểm tra của tải trọng nhận được, kiểm tra xem nó có khớp với tải trọng do Alice cung cấp hay không. Điều này là để kiểm tra tính toàn vẹn của tải trọng, xác minh rằng nó không bị giả mạo.
Phím bàn phím
Khóa này chỉ được Alice sử dụng để tạo dữ liệu "rác" ngẫu nhiên. Những dữ liệu này cũng là một phần của củ hành và nó không liên quan gì đến độ dài của đường dẫn thanh toán, số bước nhảy mà củ hành đã đi qua và nó giữ cho củ hành luôn có cùng kích thước, ngay cả khi một số nội dung của nó không liên quan. Đây là cách định tuyến củ hành che giấu độ dài đường dẫn, thực tế là bảo vệ quyền riêng tư của người gửi và người nhận.
Một chìa khóa
Khóa này cũng được sử dụng để kiểm tra tính toàn vẹn của dữ liệu chứa trong hành tây, nhưng chỉ khi một lỗi được trả về. Vâng, nó được gọi là "um" bởi vì đó là "mu" được viết ngược. Trong trường hợp xảy ra lỗi thanh toán, bước nhảy tìm thấy lỗi sẽ sử dụng phím um để tạo tổng kiểm tra và khi nút trước đó nhận được báo cáo lỗi, nó cũng sẽ sử dụng phím um để xác minh tính toàn vẹn của thông báo.
Đóng gói lớp hành tây
Gói hành tây cuối cùng trông như thế này:
Alice hiện có tải trọng cho mỗi bước nhảy và giá trị bí mật được chia sẻ cho mỗi bước nhảy. Hãy xem cách Alice biến thông tin này thành củ hành cuối cùng. Cô ấy bắt đầu với nút cuối cùng và quay trở lại từng bước một.
Trước tiên, cô ấy tạo một trường trống có độ dài 1300 byte, là tổng độ dài của tất cả các tải trọng của củ hành. Sau đó, cô ấy sử dụng phím pad để tạo một chuỗi ngẫu nhiên dài 1300 byte, đây là chuỗi rác vô dụng đối với bất kỳ bước nhảy nào. Bước này được thực hiện để đảm bảo rằng mỗi lớp của hành tây trông giống nhau, vì vậy bạn không thể nhìn thấy tổng chiều dài của đường dẫn (có bao nhiêu bước nhảy), cũng như ai là người gửi và ai là người nhận.
Sau đó, cô ấy tạo một tổng kiểm tra tải trọng cần được sử dụng và đặt nó ở cuối tải trọng. Trong thông báo đến nút cuối cùng, tổng kiểm tra là tất cả 0 để thông báo cho Dina rằng cô ấy là người nhận cuối cùng của củ hành này. Sau khi thêm tổng kiểm tra vào cuối tải trọng, Alice đặt tải trọng (và tổng kiểm tra) vào đầu thùng rác và xóa phần của toàn bộ thư vượt quá 1300 byte để toàn bộ thư dài 1300 byte.
Sau đó, Alice sử dụng khóa rho để tạo chuỗi byte ngẫu nhiên và sử dụng thao tác loại trừ hoặc (XOR) trên tải trọng hành thu được ở bước trước đó để tải trọng tải bị xáo trộn. Văn bản gốc của tải trọng có thể thu được bằng cách sử dụng thao tác XOR của chuỗi byte ngẫu nhiên này trên văn bản bị xáo trộn (Ghi chú của người dịch: Nói cách khác, XOR ở đây là thuật toán mã hóa đối xứng và chuỗi byte ngẫu nhiên là chìa khóa). Thao tác XOR so sánh tải trọng của hành tây với chuỗi byte ngẫu nhiên (được tạo bởi khóa rho) từng chút một, chỉ xuất ra 1 nếu một trong các bit dữ liệu là 1; điều này dẫn đến tải trọng bị xáo trộn. Điều thông minh về hoạt động XOR là miễn là bạn nhận được đúng chuỗi byte ngẫu nhiên và tải trọng bị xáo trộn, bạn chỉ cần chạy lại thao tác XOR với cả hai để nhận được tải trọng bị xáo trộn.
Vì các nút nhận hành có thể lấy được cùng một khóa rho nên chúng có thể tạo chuỗi byte ngẫu nhiên giống như Alice. Đây là cách mỗi nút trên đường đi có thể gỡ rối và đọc nội dung.
Sau khi chuẩn bị hành rối loạn cho một bước nhảy, Alice lặp lại các bước tương tự cho nút tiếp theo. Điểm khác biệt chính là một khi hành của Dina đã hoàn thành, cô ấy không cần phải tạo ra rác nữa. Cô ấy chỉ nối thêm củ hành bị xáo trộn từ bước trước vào sau phần tải trọng và tổng kiểm tra hữu ích, đồng thời cắt bỏ bất kỳ nội dung nào trên 1300 byte.
Cuối cùng, Alice lấy củ hành tây bị xáo trộn cuối cùng và thêm tổng kiểm tra để Bob có thể xác minh tính toàn vẹn của củ hành tây. Alice sau đó thêm khóa công khai của phiên để Bob có thể sử dụng khóa chung này để tính giá trị bí mật được chia sẻ. Cuối cùng, cô ấy cũng thêm một byte đại diện cho phiên bản, báo cho các nút khác biết cách diễn giải dữ liệu trong đó. Đối với phiên bản được mô tả bởi BOLT #4, byte phiên bản sẽ là 0.
** chuyển tiếp hành tây **
Để gửi gói hành tây này, người gửi tạo một thông báo update_add_htlc với các trường sau:
ID kênh: Kênh cụ thể mà thông báo này liên quan.
ID: Định danh của HTLC này.
Số tiền: Giá trị của HTLC này.
Thanh toán Hash: Được tạo bởi người nhận thanh toán.
Thời gian hết hạn: HTLC này sẽ hết hạn sau một khối nhất định.
Bưu kiện hành tây: Hành tây được tạo cho khoản thanh toán này, đó là những gì đã được đề cập ở trên.
Dữ liệu bổ sung: được sử dụng để chỉ định dữ liệu bổ sung.
Sau khi chuẩn bị tin nhắn, Alice gửi tin nhắn cho Bob. Sau khi nhận được tin nhắn, Bob có thể bắt đầu giải mã củ hành của chính mình. Trước tiên, anh ta lấy khóa phiên từ trình bao bọc củ hành và sử dụng nó để lấy giá trị của bí mật được chia sẻ với Alice.
Được trang bị giá trị bí mật được chia sẻ, Bob tạo khóa mu để xác minh tổng kiểm tra của tải trọng được nhúng trong gói hành tây. Nếu tải trọng không bị giả mạo, tổng kiểm tra phải khớp.
Để ngăn các nút khác trong đường dẫn biết đường dẫn dài bao nhiêu, Bob thêm trường 1300 byte chứa đầy số 0 vào gói hành tây. Bob sau đó tạo một chuỗi byte ngẫu nhiên dài 2600 byte từ khóa rho. Bob sử dụng chuỗi byte ngẫu nhiên này để XOR tải trọng hành tây được lấp đầy bằng không.
Hãy nhớ làm thế nào tôi đã nói với bạn về tải hành khó hiểu? Sử dụng tải trọng hành tây bị xáo trộn làm đầu vào và chạy thao tác "XOR" với cùng một chuỗi byte để lấy tải trọng hành tây trước khi làm rối loạn. Bởi vì Alice và Bob sử dụng cùng một giá trị bí mật được chia sẻ, tạo ra cùng một khóa rho, Bob có thể giải mã. Điều này có thêm phần thưởng là nó biến các ký tự đệm dài 1300 byte thành các byte ngẫu nhiên.
Tải trọng không bị che khuất của Bob bao gồm dữ liệu tải trọng cho bước nhảy của anh ấy cùng với dấu vân tay. Bob lưu dấu vân tay này để anh ấy có thể thêm nó vào gói hành tây mà anh ấy gửi cho Chan. Sau khi Bob tách tải trọng của chính mình khỏi thông báo của hành tây, anh ta chuyển đổi gói hành tây trở lại kích thước ban đầu là 1300 byte và ngẫu nhiên hóa khóa phiên của mình như Alice đã làm. Cuối cùng, Bob thêm byte phiên bản, khóa phiên và dấu vân tay mà anh ấy dự định đặt vào tải trọng của hành tây và chuyển tiếp gói hành tây tới Chan qua thông báo update_add_htlc.
Quá trình này sẽ tiếp tục cho đến khi tin nhắn được gửi đến nút cuối cùng, Dina. Khi Dina nhận được thông báo update_add_htlc, cô ấy có thể nhập giá trị băm của giá trị bí mật do chính cô ấy tạo ra, điều đó có nghĩa là HTLC này dành cho cô ấy. Vì vậy, Dina chỉ cần kiểm tra dấu vân tay, làm sáng tỏ các thông điệp của củ hành và tiết lộ trọng tải của chính mình.
Xử lý sự cố
Chúng ta đang nói về một câu chuyện thành công, một trường hợp mọi thứ diễn ra theo đúng kế hoạch, nhưng nếu có gì đó không ổn trong quá trình thực hiện, bạn phải gửi lại một tin nhắn để thông báo cho tất cả các nút rằng đã xảy ra sự cố. Quá trình này tương tự như định tuyến củ hành thông thường. Phát hiện một nút bị lỗi yêu cầu lấy khóa um từ giá trị bí mật được chia sẻ, sử dụng nó để tạo chuỗi byte ngẫu nhiên và sử dụng thao tác XOR để xáo trộn gói hành tây được trả về.
Một nút tìm thấy lỗi sẽ gửi thông báo trở lại nút trước đó trong đường dẫn thanh toán. Mỗi bước nhảy sử dụng phím um và phím ammag để thực hiện thao tác tương tự cho đến khi người gửi nhận được gói. Cuối cùng, người gửi sử dụng khóa ammag và khóa um để giải mã và xác minh gói.
Lỗi có thể do các gói, nút hoặc kênh hành tây gây ra. Nếu sử dụng Lightning Network nhiều, bạn có thể đã gặp phải các lỗi như "kênh không khả dụng" hoặc "không đủ phí".
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
"Định tuyến hành tây" trong Lightning Network và cách thức hoạt động của nó
Tác giả: LORENZO
Các máy tính trong mạng giao tiếp với nhau theo các giao thức. Ở đây, "giao thức" đề cập đến một hệ thống các quy tắc chỉ định cách truyền và giải thích thông điệp. Phần truyền thông báo thanh toán của giao thức mạng sét được mô tả bởi BOLT#4, còn được gọi là "Giao thức định tuyến hành tây (Giao thức định tuyến hành tây)".
Onion Routing là một công nghệ có trước Lightning Network 25 năm. Nó cũng được sử dụng trong Tor, đó là nguồn gốc của cái tên "Tor" ("Bộ định tuyến hành tây") Lightning Network sử dụng một phiên bản được sửa đổi một chút có tên là "định tuyến củ hành dựa trên nguồn gốc", viết tắt là "SPHINX". Trong bài viết này, chúng ta sẽ nói về cách hoạt động của định tuyến hành tây.
Tại sao sử dụng định tuyến củ hành?
Nhiều giao thức liên lạc khác nhau tồn tại trên thế giới, nhưng vì Lightning Network là một mạng thanh toán, nên chọn một giao thức tiết lộ càng ít thông tin càng tốt về khoản thanh toán được chuyển tiếp.
Nếu Lightning Network sử dụng cùng một giao thức như Internet, thì mọi bên trung gian sẽ biết ai là người gửi thanh toán, ai là người nhận và những bên trung gian khác trên đường đi là ai. Định tuyến củ hành là một lựa chọn tốt vì đặc điểm của nó đảm bảo các nút trung gian:
Tổng quan về định tuyến hành tây
Hãy sử dụng một bưu kiện như một phép loại suy để giải thích cách thức hoạt động của định tuyến củ hành.
Giả sử Alice muốn trả tiền cho Dina. Đầu tiên, Alice cần tìm một con đường khả thi cho khoản thanh toán của mình:
Alice→Bob→Chan→Dina
Sau đó, cô ấy xây dựng một "củ hành tây". Cô ấy bắt đầu với Dina (từ cuối con đường). Cô ấy đặt một tin nhắn bí mật (nội dung thanh toán) trong một gói gửi cho Dina và khóa nó bằng một chiếc chìa khóa mà chỉ cô ấy và Dina biết. Bây giờ, cô ấy đặt gói hàng này vào một gói hàng khác để gửi cho Chan, và khóa gói hàng cho Chan bằng một chiếc chìa khóa mà chỉ cô ấy và Chan biết. Đúng và vân vân.
Alice gửi hành (gói) cuối cùng cho người trung gian đầu tiên trên đường đi, Bob. Bob mở gói hàng của mình bằng chìa khóa của chính mình và thấy rằng gói hàng tiếp theo là dành cho Chan. Vì vậy, anh ấy đã chuyển gói hàng cho Chan. Chan cũng vậy, sau khi mở gói hàng, anh ấy đã chuyển gói hàng bên trong cho Dina. Cuối cùng, Dina mở gói hàng của mình và tìm thấy thông báo thanh toán bên trong.
Trong định tuyến củ hành, những người trung gian như Bob và Chan không biết nội dung của tin nhắn tới Dina, cũng như độ dài của toàn bộ đường dẫn thanh toán. Điều duy nhất họ biết là ai đã chuyển tiếp gói hàng cho họ và ai sẽ nhận nó tiếp theo. Điều này đảm bảo tính riêng tư của tin nhắn và tính bảo mật của đường dẫn. Mỗi người trung gian chỉ có thể chạm vào lớp tin nhắn được tạo riêng cho TA.
Trong định tuyến củ hành dựa trên nguồn của Lightning Network, người gửi chọn đường dẫn thanh toán và xây dựng một củ hành hoàn chỉnh cho đường dẫn đó, có thể được xem như một lỗ hổng bảo mật (Ghi chú của người dịch: Vị trí mạng của người nhận phải được hiển thị cho người gửi). Các sơ đồ định tuyến khác, chẳng hạn như "định tuyến mù" (bản dịch tiếng Trung), giải quyết vấn đề này bằng cách làm xáo trộn một phần đường dẫn thanh toán tới người gửi. Tuy nhiên, trong bài viết này, chúng tôi chỉ tập trung vào SPHINX.
Lắp ráp hành tây
Bây giờ, chúng ta hãy xem đặc điểm kỹ thuật của hành tây định tuyến. Lúc đầu, chúng ta cần xác định những điều này:
Cấu tạo nhảy tải
Khi Alice đã chọn một đường dẫn thanh toán, cô ấy sẽ lấy thông tin cho từng kênh thanh toán từ giao thức tin đồn để tạo tải trọng cho mỗi bước nhảy, về cơ bản là cho mỗi bước nhảy biết cách tạo HTLC cho khoản thanh toán được chuyển tiếp (hợp đồng khóa thời gian băm).
Để thiết lập một HTLC phù hợp, mỗi bước nhảy cần:
Hầu hết dữ liệu này đến từ thông báo "cập nhật kênh", chứa thông tin về phí định tuyến, yêu cầu sự kiện và ID kênh thanh toán. Tổng số tiền cần chuyển tiếp là tổng của số tiền đã thanh toán cộng với phí tính cho mỗi lần nhảy tiếp theo; trong khi giá trị bí mật của khoản thanh toán được Dina tính toán và nhúng vào hóa đơn thanh toán (được thông báo bằng tin nhắn hành động cho từng người nhảy lò cò).
Alice bắt đầu với nút cuối cùng Dina. Cô ấy bao gồm số tiền chuyển tiếp, giá trị thời lượng khóa thời gian, giá trị bí mật thanh toán và số tiền thanh toán trong gói. Lưu ý rằng cô ấy không cần thêm ID kênh vì Dina là nút cuối cùng và không cần chuyển tiếp khoản thanh toán cho người khác.
Thoạt nhìn, việc cung cấp số tiền chuyển tiếp có vẻ dư thừa vì số tiền này giống với số tiền thanh toán. Tuy nhiên, thanh toán nhiều đường sẽ gửi số tiền thanh toán qua nhiều đường dẫn và khi đó hai giá trị sẽ không khớp.
Trong tải trọng của Chan, Alice thêm ID kênh của Chan và Dina. Cô ấy cũng đã thêm số tiền chuyển tiếp và giá trị khóa thời gian. Cuối cùng, Alice tạo một tải trọng cho Bob. Chan tính phí 100 Satoshi cho khoản thanh toán qua kênh giữa cô ấy và Dina, vì vậy Alice cần nói với Bob rằng số tiền chuyển tiếp là khoản thanh toán cộng với phí xử lý. Theo thông báo cập nhật kênh của Chan, giá trị khóa thời gian cũng đã được tăng thêm 20 (tính theo khối). Cuối cùng, Alice cũng xem xét các yêu cầu về phí xử lý và khóa thời gian của Bob, đồng thời đưa cho anh ta một HTLC có thời lượng khóa là 700040 và giá trị là 100200 Satoshi.
Giá trị bí mật được chia sẻ và tạo khóa
Tiếp theo, Alice chuẩn bị hành tây bằng cách tạo một bí mật chung cho mỗi bước nhảy (bao gồm cả nút cuối cùng). Giá trị bí mật được chia sẻ này có thể được tạo ra bởi Alice và bước nhảy mục tiêu tương ứng bằng cách nhân khóa riêng của cô ấy với khóa chung của bên kia.
Một giá trị bí mật được chia sẻ là cần thiết cho định tuyến hành tây, cho phép Alice và mỗi bước nhảy lấy cùng một khóa. Sau đó, Alice sử dụng các phím đó để làm xáo trộn từng lớp của củ hành và bước nhảy đó sử dụng các phím đó để giải mã.
Để bảo vệ quyền riêng tư của Alice, cô ấy tạo khóa phiên một lần cho một củ hành, thay vì sử dụng khóa công khai của nút riêng, để lấy giá trị bí mật được chia sẻ. Cô ấy sử dụng khóa phiên này cho bước nhảy đầu tiên và sau đó, với mỗi bước nhảy tiếp theo, Alice ngẫu nhiên hóa khóa một cách xác định bằng cách nhân khóa mới nhất với một hệ số mù. Chúng được sử dụng để tạo khóa giá trị bí mật được chia sẻ mà chúng tôi gọi là "khóa tạm thời".
Bob, Chan và Dina, tất cả đều cần nhận được cùng một giá trị bí mật như Alice, vì vậy họ cần biết khóa tạm thời để sử dụng trong phiên của mình. Alice chỉ đặt khóa đầu tiên trong củ hành để tiết kiệm kích thước tin nhắn. Mỗi bước nhảy tính toán khóa phù du tiếp theo và nhúng nó vào hành tây cho nút tiếp theo. Mỗi bước nhảy có thể sử dụng khóa công khai và giá trị bí mật được chia sẻ của riêng mình để tính hệ số mù được Alice sử dụng để xác định khóa phù du tiếp theo.
Như đã đề cập trước đó, giá trị bí mật được chia sẻ sẽ được sử dụng để tạo một số khóa và Alice và bước nhảy tương ứng có thể sử dụng các khóa này để thực hiện một số thao tác trên hành. Chúng ta hãy xem những gì mỗi phím làm.
Chìa khóa Rho
Khóa Rho được Alice sử dụng để mã hóa một lớp hành tây; điều này sẽ làm xáo trộn nội dung của tải trọng để người bên ngoài không thể giải mã được. Chỉ chủ sở hữu của khóa rho mới có thể giải mã tải trọng. Đó là những gì nút nhận được hành tây phải làm: sử dụng giá trị bí mật được chia sẻ với Alice để lấy khóa rho, sau đó giải mã hành tây và đọc nội dung.
Mukey
Alice sử dụng phím mu để tạo tổng kiểm tra cho mỗi tải trọng. Cô ấy cũng chuyển tổng kiểm tra cho bước nhảy nhận được củ hành. Lần lượt, bước nhảy này sử dụng phím mu để tạo tổng kiểm tra của tải trọng nhận được, kiểm tra xem nó có khớp với tải trọng do Alice cung cấp hay không. Điều này là để kiểm tra tính toàn vẹn của tải trọng, xác minh rằng nó không bị giả mạo.
Phím bàn phím
Khóa này chỉ được Alice sử dụng để tạo dữ liệu "rác" ngẫu nhiên. Những dữ liệu này cũng là một phần của củ hành và nó không liên quan gì đến độ dài của đường dẫn thanh toán, số bước nhảy mà củ hành đã đi qua và nó giữ cho củ hành luôn có cùng kích thước, ngay cả khi một số nội dung của nó không liên quan. Đây là cách định tuyến củ hành che giấu độ dài đường dẫn, thực tế là bảo vệ quyền riêng tư của người gửi và người nhận.
Một chìa khóa
Khóa này cũng được sử dụng để kiểm tra tính toàn vẹn của dữ liệu chứa trong hành tây, nhưng chỉ khi một lỗi được trả về. Vâng, nó được gọi là "um" bởi vì đó là "mu" được viết ngược. Trong trường hợp xảy ra lỗi thanh toán, bước nhảy tìm thấy lỗi sẽ sử dụng phím um để tạo tổng kiểm tra và khi nút trước đó nhận được báo cáo lỗi, nó cũng sẽ sử dụng phím um để xác minh tính toàn vẹn của thông báo.
Đóng gói lớp hành tây
Gói hành tây cuối cùng trông như thế này:
Alice hiện có tải trọng cho mỗi bước nhảy và giá trị bí mật được chia sẻ cho mỗi bước nhảy. Hãy xem cách Alice biến thông tin này thành củ hành cuối cùng. Cô ấy bắt đầu với nút cuối cùng và quay trở lại từng bước một.
Trước tiên, cô ấy tạo một trường trống có độ dài 1300 byte, là tổng độ dài của tất cả các tải trọng của củ hành. Sau đó, cô ấy sử dụng phím pad để tạo một chuỗi ngẫu nhiên dài 1300 byte, đây là chuỗi rác vô dụng đối với bất kỳ bước nhảy nào. Bước này được thực hiện để đảm bảo rằng mỗi lớp của hành tây trông giống nhau, vì vậy bạn không thể nhìn thấy tổng chiều dài của đường dẫn (có bao nhiêu bước nhảy), cũng như ai là người gửi và ai là người nhận.
Sau đó, cô ấy tạo một tổng kiểm tra tải trọng cần được sử dụng và đặt nó ở cuối tải trọng. Trong thông báo đến nút cuối cùng, tổng kiểm tra là tất cả 0 để thông báo cho Dina rằng cô ấy là người nhận cuối cùng của củ hành này. Sau khi thêm tổng kiểm tra vào cuối tải trọng, Alice đặt tải trọng (và tổng kiểm tra) vào đầu thùng rác và xóa phần của toàn bộ thư vượt quá 1300 byte để toàn bộ thư dài 1300 byte.
Sau đó, Alice sử dụng khóa rho để tạo chuỗi byte ngẫu nhiên và sử dụng thao tác loại trừ hoặc (XOR) trên tải trọng hành thu được ở bước trước đó để tải trọng tải bị xáo trộn. Văn bản gốc của tải trọng có thể thu được bằng cách sử dụng thao tác XOR của chuỗi byte ngẫu nhiên này trên văn bản bị xáo trộn (Ghi chú của người dịch: Nói cách khác, XOR ở đây là thuật toán mã hóa đối xứng và chuỗi byte ngẫu nhiên là chìa khóa). Thao tác XOR so sánh tải trọng của hành tây với chuỗi byte ngẫu nhiên (được tạo bởi khóa rho) từng chút một, chỉ xuất ra 1 nếu một trong các bit dữ liệu là 1; điều này dẫn đến tải trọng bị xáo trộn. Điều thông minh về hoạt động XOR là miễn là bạn nhận được đúng chuỗi byte ngẫu nhiên và tải trọng bị xáo trộn, bạn chỉ cần chạy lại thao tác XOR với cả hai để nhận được tải trọng bị xáo trộn.
Vì các nút nhận hành có thể lấy được cùng một khóa rho nên chúng có thể tạo chuỗi byte ngẫu nhiên giống như Alice. Đây là cách mỗi nút trên đường đi có thể gỡ rối và đọc nội dung.
Sau khi chuẩn bị hành rối loạn cho một bước nhảy, Alice lặp lại các bước tương tự cho nút tiếp theo. Điểm khác biệt chính là một khi hành của Dina đã hoàn thành, cô ấy không cần phải tạo ra rác nữa. Cô ấy chỉ nối thêm củ hành bị xáo trộn từ bước trước vào sau phần tải trọng và tổng kiểm tra hữu ích, đồng thời cắt bỏ bất kỳ nội dung nào trên 1300 byte.
Cuối cùng, Alice lấy củ hành tây bị xáo trộn cuối cùng và thêm tổng kiểm tra để Bob có thể xác minh tính toàn vẹn của củ hành tây. Alice sau đó thêm khóa công khai của phiên để Bob có thể sử dụng khóa chung này để tính giá trị bí mật được chia sẻ. Cuối cùng, cô ấy cũng thêm một byte đại diện cho phiên bản, báo cho các nút khác biết cách diễn giải dữ liệu trong đó. Đối với phiên bản được mô tả bởi BOLT #4, byte phiên bản sẽ là 0.
** chuyển tiếp hành tây **
Để gửi gói hành tây này, người gửi tạo một thông báo update_add_htlc với các trường sau:
Sau khi chuẩn bị tin nhắn, Alice gửi tin nhắn cho Bob. Sau khi nhận được tin nhắn, Bob có thể bắt đầu giải mã củ hành của chính mình. Trước tiên, anh ta lấy khóa phiên từ trình bao bọc củ hành và sử dụng nó để lấy giá trị của bí mật được chia sẻ với Alice.
Được trang bị giá trị bí mật được chia sẻ, Bob tạo khóa mu để xác minh tổng kiểm tra của tải trọng được nhúng trong gói hành tây. Nếu tải trọng không bị giả mạo, tổng kiểm tra phải khớp.
Để ngăn các nút khác trong đường dẫn biết đường dẫn dài bao nhiêu, Bob thêm trường 1300 byte chứa đầy số 0 vào gói hành tây. Bob sau đó tạo một chuỗi byte ngẫu nhiên dài 2600 byte từ khóa rho. Bob sử dụng chuỗi byte ngẫu nhiên này để XOR tải trọng hành tây được lấp đầy bằng không.
Hãy nhớ làm thế nào tôi đã nói với bạn về tải hành khó hiểu? Sử dụng tải trọng hành tây bị xáo trộn làm đầu vào và chạy thao tác "XOR" với cùng một chuỗi byte để lấy tải trọng hành tây trước khi làm rối loạn. Bởi vì Alice và Bob sử dụng cùng một giá trị bí mật được chia sẻ, tạo ra cùng một khóa rho, Bob có thể giải mã. Điều này có thêm phần thưởng là nó biến các ký tự đệm dài 1300 byte thành các byte ngẫu nhiên.
Tải trọng không bị che khuất của Bob bao gồm dữ liệu tải trọng cho bước nhảy của anh ấy cùng với dấu vân tay. Bob lưu dấu vân tay này để anh ấy có thể thêm nó vào gói hành tây mà anh ấy gửi cho Chan. Sau khi Bob tách tải trọng của chính mình khỏi thông báo của hành tây, anh ta chuyển đổi gói hành tây trở lại kích thước ban đầu là 1300 byte và ngẫu nhiên hóa khóa phiên của mình như Alice đã làm. Cuối cùng, Bob thêm byte phiên bản, khóa phiên và dấu vân tay mà anh ấy dự định đặt vào tải trọng của hành tây và chuyển tiếp gói hành tây tới Chan qua thông báo update_add_htlc.
Quá trình này sẽ tiếp tục cho đến khi tin nhắn được gửi đến nút cuối cùng, Dina. Khi Dina nhận được thông báo update_add_htlc, cô ấy có thể nhập giá trị băm của giá trị bí mật do chính cô ấy tạo ra, điều đó có nghĩa là HTLC này dành cho cô ấy. Vì vậy, Dina chỉ cần kiểm tra dấu vân tay, làm sáng tỏ các thông điệp của củ hành và tiết lộ trọng tải của chính mình.
Xử lý sự cố
Chúng ta đang nói về một câu chuyện thành công, một trường hợp mọi thứ diễn ra theo đúng kế hoạch, nhưng nếu có gì đó không ổn trong quá trình thực hiện, bạn phải gửi lại một tin nhắn để thông báo cho tất cả các nút rằng đã xảy ra sự cố. Quá trình này tương tự như định tuyến củ hành thông thường. Phát hiện một nút bị lỗi yêu cầu lấy khóa um từ giá trị bí mật được chia sẻ, sử dụng nó để tạo chuỗi byte ngẫu nhiên và sử dụng thao tác XOR để xáo trộn gói hành tây được trả về.
Một nút tìm thấy lỗi sẽ gửi thông báo trở lại nút trước đó trong đường dẫn thanh toán. Mỗi bước nhảy sử dụng phím um và phím ammag để thực hiện thao tác tương tự cho đến khi người gửi nhận được gói. Cuối cùng, người gửi sử dụng khóa ammag và khóa um để giải mã và xác minh gói.
Lỗi có thể do các gói, nút hoặc kênh hành tây gây ra. Nếu sử dụng Lightning Network nhiều, bạn có thể đã gặp phải các lỗi như "kênh không khả dụng" hoặc "không đủ phí".