Bởi Alex Myers
Nguồn: https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip
Bài viết này là bản ghi chép bài phát biểu của tác giả tại hội nghị Bitcoin++ 2022, do Michael Folkson biên soạn. Các slide bài phát biểu có tại đây: https://endothermic.dev/presentations/magical-minisketch
Kho lưu trữ Minisketch: https://github.com/sipa/minisketch
Rusty Russell chia sẻ về việc sử dụng Minisketch để đưa tin về Lightning Network: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html
Ba cuộc thảo luận về Minisketch trong Câu lạc bộ đánh giá quan hệ công chúng Bitcoin Core:
giới thiệu
Tôi là người mới hoàn toàn trong lĩnh vực phát triển Lightning và vừa mới gia nhập đội ngũ Core Lightning. Tôi sẽ nói về Minisketch và những gì tôi học được từ các trang mạng xã hội.
đề tài
Tôi sẽ bắt đầu bằng việc nói về vai trò của giao thức tin đồn trong Lightning Network. Chắc hẳn các bạn đều quen thuộc với Lightning Network, hoặc ít nhất là đã tìm hiểu đôi chút, phải không? Tôi sẽ không đi sâu vào bối cảnh hoạt động của Lightning Network. Tuy nhiên, tôi sẽ giải thích cách tin đồn được lồng ghép vào hoạt động của Lightning Network. Sau đó, tôi cũng sẽ giới thiệu tổng quan về cách thức hoạt động của Minisketch, phân tích một trường hợp điển hình, và hướng dẫn cách chúng ta có thể sử dụng nó để tối ưu hóa tin đồn cho Lightning Network.
Vai trò của việc buôn chuyện
Tôi nghĩ sẽ rất thú vị khi giải thích vai trò của tin đồn trong Lightning Network thông qua một ví dụ, vậy chúng ta hãy bắt đầu với một giao dịch Lightning Network đơn giản.
Gửi thanh toán sét
Từ góc nhìn của người dùng thông thường, cái gọi là "thanh toán chớp nhoáng" có thể là mở ứng dụng ví trên điện thoại trước, sau đó hướng camera vào mã QR hoặc văn bản có thể quét được (hóa đơn). Sau đó, ứng dụng sẽ hiển thị cho bạn biên lai giao dịch và ghi chú, và sau khi bạn xác nhận số tiền gần đúng, nhấn"Gửi". Chỉ cần bạn không quá xui xẻo, chỉ trong giây lát, một dấu kiểm màu xanh lá cây sẽ xuất hiện trên màn hình điện thoại, báo hiệu khoản thanh toán đã được gửi thành công.
Nhưng những người có mặt đều là những người đam mê, nên tôi cho rằng chúng ta có thể đi sâu hơn một chút - Điều gì thực sự đang diễn ra đằng sau màn hình điện thoại?
Thanh toán Lightning - Nâng cao
Trong Core Lightning Máy trạm, có nhiều lệnh dòng lệnh có thể được sử dụng để lấy thêm thông tin.
lightning-cli listpays <BOLT 11>Sau khi nhập lệnh này, chúng ta có thể thấy điều gì thực sự xảy ra. Khi thanh toán hoàn tất, preimage sẽ xuất hiện, khá giống với biên lai chúng ta nhận được khi thanh toán trên Lightning Network. Điều thú vị là chúng ta có thể thấy khoản thanh toán này được chia thành 12 phần nhỏ hơn. 12 đường dẫn thanh toán này đều được tính toán để hoàn tất khoản thanh toán.
lightning-cli listpaystatus <BOLT 11> Hãy xem xét kỹ hơn vấn đề này. Ta có thể thấy rằng máy trạm không chỉ thử 12 đường dẫn, mà thực tế đã thử Lần. Điều này được gọi là "thanh toán đa đường dẫn". Một số đường dẫn bị lỗi do hết thời gian chờ. Trước khi thanh toán thành công, chúng ta đã nhận được một số thông tin lỗi. Lệnh CLI này in dữ liệu này. Nhưng thực tế, chúng ta có thể biết có bao nhiêu bước nhảy (chuyển tiếp) được thực hiện trong mỗi lần thử không thành công; và chúng ta nhận được các chuỗi được mã hóa văn bản ( 0x1007... ). Nếu chúng ta truyền các chuỗi này vào một công cụ khác (devtools/decodemsg), chúng ta có thể giải mã chúng. Đây là một phần của BOLT4, và thông số kỹ thuật nêu rõ rằng 1007 nghĩa là chúng ta có temporary_channel_failure .
Ngoài ra còn có lỗi "lỗi cập nhật kênh bị bỏ lỡ" (cập nhật kênh mới 0x1000 kèm theo), nghĩa là chúng ta đã bỏ lỡ thay đổi trong yêu cầu chuyển tiếp thanh toán do nút này thông báo. Nút trung gian này không biết chúng ta là ai hoặc khoản thanh toán sẽ đến đâu, vì tất cả các tin nhắn đều được định tuyến theo kiểu onion-routed. Vì vậy, nó nói rằng: "Dù bạn là ai, tôi nghĩ bạn đang nói chuyện với nhầm người. Một số thông tin bạn có đã lỗi thời, và tôi cho rằng bạn cần xem xét điều này." Trong trường hợp này, chúng ta có thể thấy rằng chúng ta nhận được thông tin về khoản phí mà kênh này sẽ tính, giá trị cltv_expiry_delta của nó và số khối chúng ta muốn thêm vào thời gian chờ. Điều quan trọng là: channel_flags=1 . Nó trông không ấn tượng, nhưng nếu bạn xem xét thông số kỹ thuật giao thức, bạn sẽ thấy rằng nó chỉ ra rằng kênh đã bị vô hiệu hóa. Rõ ràng, khi chúng ta tính toán đường dẫn chuyển tiếp, chúng ta không có thông tin này; đó là lý do tại sao đường dẫn này không hoạt động.
Thanh toán Lightning - Tóm tắt
Chúng tôi đã học được gì từ trường hợp cơ bản này? Ngay cả trong trường hợp đơn giản này, chúng tôi đã sử dụng 70 kênh khác nhau để thực hiện khoản thanh toán này. Thông tin của chúng tôi về một trong đó đã lỗi thời, nhưng chúng tôi đã có thể lấy lại một số tin nhắn rác mới và cập nhật biểu đồ định tuyến — giống như bản đồ địa hình của mạng. Sử dụng thông tin mới, chúng tôi đã có thể tính toán lại đường đi và thực hiện thanh toán.
Vai trò của việc buôn chuyện
Quay lại câu hỏi chúng ta đã đặt ra lúc đầu: vai trò của tin đồn trong Mạng Lightning nói chung là gì? Cũng giống như tin đồn trong cuộc sống. Tin đồn là thông tin gián tiếp mà bạn chia sẻ về nút mà bạn không giao tiếp trực tiếp. Trong Mạng Lightning, nhiều nút được kết nối với nhau. Chúng ta có thể được kết nối trực tiếp với nhiều nút, nhưng, ví dụ, chúng ta đang ở góc dưới bên trái, chúng ta cần thu thập thông tin về nút khác không nằm trong khu vực này. Việc này được thực hiện thông qua tin nhắn tin đồn gọi là node_announcement .
Việc này được thực hiện thông qua một tin nhắn thông báo gọi nútnode_announcement . Tin nhắn node_announcement cung cấp khóa công khai của một nút, cũng như địa chỉ mạng để kết nối đến nút đó (trong trường hợp bạn muốn thiết lập kết nối trực tiếp với nút đó). Ví dụ: địa chỉ IP, địa chỉ onion, web socket, nút
Điều tiếp theo chúng ta muốn biết là các kênh nằm ở đâu. Vì vậy, chúng ta có thông báo channel_announcement . Thông báo này chỉ ra rằng có một kênh giữa nút A và nút B, và có một giao dịch trên blockchain đã tài trợ cho kênh đó. Thông báo này liệt kê "ID kênh ngắn", đây là thông tin bạn cần để tìm kiếm kênh và kiểm tra UTXO nào trên blockchain tài trợ cho kênh đó. Thông tin này không tốt cho quyền riêng tư, nhưng lại hữu ích để ngăn chặn các cuộc tấn công từ chối dịch vụ (DoS) - người gửi thông báo cần chứng minh rằng họ có UTXO đã mở kênh.
Giờ chúng ta đã biết cấu trúc mạng cơ bản, chúng ta có thể tìm ra đường đi qua nó. Nhưng sẽ tốt hơn nếu có thêm thông tin. Vì vậy, chúng ta có thông điệp channel_update . Thông điệp này chứa các thông tin như phí xử lý, số lượng HTLC tối đa mà kênh có thể chuyển tiếp, kênh đã bị vô hiệu hóa hay chưa, v.v., như chúng ta đã thấy trong ví dụ trên. Tất cả thông tin này giúp chúng ta loại bỏ các đường dẫn không phù hợp khi tính toán đường đi.
Bây giờ chúng ta đã có tất cả thông tin cần thiết để xây dựng một đường dẫn. Nhưng tại sao bài nói chuyện của tôi lại có tiêu đề là "Mạng lưới tin đồn Lightning"? Đó không phải là những gì chúng ta vừa nói về Mạng lưới Lightning sao? Câu trả lời ngắn gọn là hai khái niệm này không hoàn toàn giống nhau. Sự khác biệt là các kết nối giữa nút này mà chúng ta thấy là các kênh (thanh toán) trong Mạng lưới Lightning. Nhưng khi tham gia vào tin đồn, chúng ta chỉ giao tiếp với một tập hợp nút. Con số chính xác phụ thuộc vào cách triển khai, tôi nhớ rằng Core Lightning sử dụng 5 nút ngang hàng và bạn giao tiếp với 3 đến 5 nút nút kết nối đến. Đối tượng tin đồn của bạn không cần phải là nút ngang hàng của bạn. Bạn có thể giao tiếp với bất kỳ nút nào. Thậm chí không cần phải là một nút, miễn là nó hiểu giao thức và có thể cung cấp thông tin mà bạn chưa biết. Miễn là có thể thu thập thông tin mới về trạng thái của mạng, thì việc giao tiếp qua lại được hoan nghênh. Chi tiết quan trọng nhất là giao thức tin đồn hoạt động ở chế độ lan truyền lũ. Ví dụ, nếu bạn kết nối với 5 nút gossip, khi nhận được tin nhắn từ một trong đó nút gossip, bạn sẽ phát nó đến 4 nút còn lại. Điều này rất hiệu quả trong giai đoạn đầu của việc truyền tải thông tin, vì bạn có thể nhanh chóng truyền thông tin đến tất cả các nút đối tác. Tuy nhiên, sau khi thông tin được truyền đi vài bước, hiệu quả của nó bắt đầu giảm - bạn bắt đầu nhận được cùng một dữ liệu ở nhiều nút , đây là biểu hiện của việc hiệu quả giảm.
Thống kê dữ liệu
Sau đây là một số dữ liệu cơ bản về trạng thái của Mạng Lightning. Hiện tại, có 80.000 kênh và 17.000 nút công khai trong toàn bộ Mạng Lightning. Quay trở lại mô hình lan truyền lũ ở trên, nếu chúng ta ở trong một nhóm có kích thước tối thiểu (ba nút gossip được kết nối với nhau), điều đó có nghĩa là để một tin nhắn lan truyền khắp mạng, chúng ta cần ít nhất 14 bước nhảy. Và việc lan truyền gossip có những hạn chế cố hữu. Trong thực tế, bạn nhóm tất cả các tin nhắn gossip mà bạn nhận được và sau đó đợi từ 60 đến 90 giây. Core Lightning sử dụng giá trị 60 giây, nhưng tôi nghĩ LND sử dụng vòng lặp 90 giây. Bạn định kì phát tất cả các tin nhắn gossip mới mà bạn nhận được tới tất cả nút gossip của mình. 14 bước nhảy, với 60 đến 90 giây giữa mỗi bước nhảy, là một khoảng thời gian dài. Trong thực tế, chúng tôi thấy rằng 95% nút trong mạng nhận được tin nhắn mới trong vòng 13 phút. Bạn có thể phải đợi 20 phút trước khi mong đợi mọi người đều thấy thông tin mới - ít nhất thì đây cũng là nguyên tắc hữu ích.
"Minisketch" là gì?
Chuyển sang chủ đề khác, bây giờ chúng ta sẽ giới thiệu "Minisketch". Tôi sẽ cố gắng hết sức.
Minisketch là một giao thức đối chiếu tập hợp. "Đối chiếu tập hợp" là gì? Chúng ta có hai tập dữ liệu, và bạn có thể thấy từ biểu đồ Venn này rằng chúng phần lớn chồng chéo lên nhau. Trong trường hợp này, cả hai dữ liệu của chúng ta đều hợp lệ, và chúng ta muốn đảm bảo cả hai đều nhận được một phần dữ liệu mới để cả hai tập đều được cập nhật. Lúc này, chúng ta quan tâm đến "sự khác biệt đối xứng" giữa hai tập hợp. Đây chính là điểm mà Minisketch hỗ trợ chúng ta. Nếu bạn giống tôi vài tháng trước, thì bạn có thể cho rằng rằng đây là một vấn đề rất khó giải quyết, và việc cố gắng đối chiếu hai tập hợp này trả giá tốn rất nhiều chi phí. Bạn có thể gửi nhiều thông tin hơn mức cần thiết vì bạn không biết nút đang thiếu thông tin gì. Nhưng giống như tôi, bạn có thể đã nhầm. Minisketch có một số tính năng rất thú vị.
bối cảnh
Minisketch thực ra thuộc họ mã sửa lỗi gọi là "mã sửa lỗi BCH". Nó sử dụng một bản đồ, giống như thuật toán Berlekamp-Massey. Tôi sẽ cho bạn một ví dụ rất đơn giản và trừu tượng.
Ví dụ về BCH
Giả sử chúng ta có hai tập dữ liệu, bao gồm các phần tử (1, 2, 3) và (1, 2, 3, 4) tương ứng.
Nếu chúng ta muốn đối chiếu hai tập hợp này, một mẹo hay là đảm bảo cả hai đều có đầy đủ dữ liệu. Chúng ta tính tổng của tất cả các phần tử trong mỗi tập hợp, một tập hợp bằng 6 và tập hợp còn lại bằng 10. Nếu chúng ta ở tập hợp bên trái và muốn đồng bộ với tập hợp bên phải, chúng ta nói: "Đây là tổng các phần tử trong tập hợp của tôi, bằng 6. Hãy lấy hiệu số giữa hai tập hợp, là 10 - 6 = 4 , và đó là phần tử tôi còn thiếu." Cách này rất hay, và về cơ bản nó chỉ là phép trừ. Nhưng cách này chỉ hiệu quả nếu hiệu số là một phần tử. Nếu hiệu số là nhiều hơn một phần tử, thì không hiệu quả. Nhưng đây là một mẹo khác.
Giả sử chúng ta muốn mã hóa hai phép tính hiệu số, và chúng ta có thể làm điều này bằng cách đặt tổng đơn giản của tất cả các phần tử vào một mảng - đó chính là mảng của chúng ta, và phần tử đầu tiên của mảng là tổng đơn giản của tất cả các phần tử trong tập hợp, và phần tử thứ hai là tổng bình phương của tất cả các phần tử trong tập hợp. Đây là tất cả những kiến thức toán học cơ bản. Mảng này là thứ chúng ta sẽ truyền đạt cho những người khác. Bây giờ, chúng ta muốn so sánh hai phép tính hiệu số, vốn đã gấp đôi so với trước. Chúng ta có thể ghép hai phép tính hiệu số này lại với nhau: "Phép tính hiệu số đầu tiên là hiệu của tổng đơn giản các phần tử, và phép tính hiệu số thứ hai là hiệu của tổng bình phương các phần tử." Hãy nhớ lại bài toán đại số của chúng ta: có hai phương trình ở đây, và có hai ẩn số. Điều đó có nghĩa là chúng ta có thể giải chúng!
Khi số lượng các phép tính tăng lên (và thứ tự cũng tăng lên), bài toán sẽ ngày càng khó hơn. Đây chính là lúc thuật toán Berlekamp-Massey phát huy tác dụng, và đây là một giải pháp rất hiệu quả.
Xây dựng một bản phác thảo lớn
Ta có thể làm phương pháp với bất kỳ tập hợp nào. Ta có thể đi tăng cấp n. Rõ ràng, cấp càng lớn thì thời gian giải càng lâu. Bạn phải mã hóa từng phần tử cho đến khi tăng đến cấp n. Nhưng cách này hiệu quả, và ta có thể tìm ra hiệu số giữa hai tập hợp, bất kể có bao nhiêu phần tử.
Bản phác thảo nhỏ
Kho lưu trữ Minisketch: https://github.com/sipa/minisketch
Đây là một thư viện C++ do Pieter Wuille phát triển. Nó triển khai thuật toán PinSketch. Nó hoạt động trên nhiều kiến trúc và phần cứng khác nhau. Nó sử dụng bảng để tối ưu hóa quá trình tìm nghiệm và tiết kiệm thời gian. Pieter cũng đã nghĩ ra một triển khai Python thuần túy, bản thân nó đã rất tuyệt vời. Chỉ cần 500 dòng mã để chạy đủ loại phép tính khiến tôi phải kinh ngạc. Mã cũng rất dễ đọc, tôi khuyên bạn nên tự mình xem qua trang GitHub.
Sử dụng Minisketch
Nhưng giả sử bạn chỉ là một kỹ sư, giống như tôi, bạn sẽ áp dụng phép toán thú vị này vào thực tế như thế nào? Ví dụ như thế này:
Đầu tiên, chúng ta khởi tạo một bản phác thảo, và để làm điều này, chúng ta cần biết chiều rộng của dữ liệu muốn mã hóa. Ở đây chúng ta đang nói về 64 bit. Trước tiên, chúng ta điền chiều rộng của dữ liệu, sau đó điền dung lượng. Dung lượng là số phần tử chênh lệch mà chúng ta muốn có thể điều hòa giữa hai tập hợp. Nếu chúng ta cho rằng hai tập hợp có thể khác nhau 5 phần tử, thì chúng ta có thể chọn giá trị là 8, chỉ để đảm bảo chúng ta vượt quá nó một chút. Nhưng chúng ta không muốn vượt quá nó quá nhiều. Sau đó, chúng ta nhập dữ liệu tập hợp và tính toán giá trị hợp thành. Quá trình này hoàn toàn giống với những gì chúng ta đã nói trong phần "Xây dựng một bản phác thảo lớn". Sau đó, chúng ta tuần tự hóa kết quả và truyền nó từ Alice đến Bob.
Bob cũng trải qua quy trình tương tự. Anh ấy xây dựng bản phác thảo của mình, rồi hợp nhất hai bản phác thảo. Điều này thực sự thú vị, anh ấy phải chọn cùng một dữ liệu, nhưng dung lượng có thể khác nhau. Thuật toán cho phép bạn luôn có thể cắt bớt mảng sao cho hai mảng bằng nhau, rồi hợp nhất hai bản phác thảo. Dung lượng có phần lỏng lẻo hơn một chút (không bằng số phần tử khác nhau), nhưng vẫn hoạt động khá tốt. Sau đó, bạn sử dụng thuật toán Berlekamp-Massey, và kết quả là hiệu số giữa hai tập hợp.
Đặc điểm hộp đen
Phép toán này có những đặc tính gì khi sử dụng? Nó hỗ trợ dữ liệu từ 2 bit đến 64 bit. Điều thực sự thú vị là kích thước của bản phác thảo sau khi tuần tự hóa, tức là kích thước của dữ liệu cần truyền giữa nút , bằng dung lượng của bản phác thảo (tức là số phần tử hiệu bạn muốn giải) nhân với chiều rộng của dữ liệu. Nếu bạn chọn đúng dung lượng bản phác thảo, bạn có thể đạt được hiệu suất 100% từ dữ liệu(thể tích của số phần tử được truyền chính xác bằng thể tích của các phần tử bị thiếu mà bạn trích xuất).
草图序列化体积= 草图容量* 数据宽度Điều này làm tôi kinh ngạc. Nhưng vẫn còn một số điều khác cần lưu ý. Khi bạn tăng kích thước bản phác thảo, thời gian để đối chiếu sẽ tăng tăng(theo tuyến tính). Tùy thuộc vào số lượng phần tử bạn thực sự muốn tạo ra sự khác biệt, thời gian để đối chiếu tăng cấp số nhân. Vì vậy, tất cả chúng ta đều muốn giới hạn số lượng phần tử cần tạo ra sự khác biệt. Bạn không muốn bị choáng ngợp bởi sự khác biệt quá lớn giữa các tập hợp.
hạn chế
Có một vài điều cơ bản cần nhớ. Khi khởi tạo một sketch, bạn không thể mã hóa số phần tử bằng 0. Bất kỳ số nào khác cũng được, miễn là không phải là 0. Một điều nữa là, việc đảm bảo số lượng phần tử trong mỗi sketch, tức là chênh lệch giữa hai tập hợp, không quá lớn (không vượt quá dung lượng của sketch) cũng rất hữu ích. Nhìn chung, điều này sẽ không thành vấn đề, nhưng giả sử bạn có 50 phần tử trong một sketch và 100 phần tử trong một sketch khác, nhưng dung lượng sketch của bạn chỉ có 10. Sketch sẽ không thể giải được vì dung lượng không đủ. Nhưng điều tốt là nếu không giải được, nó sẽ đưa ra cảnh báo và nói rằng "Tôi không tìm thấy bất kỳ đa thức nào thỏa mãn phương trình này". Trong hầu hết trường hợp, cách này hiệu quả.
Erlay
Sau đây là một số bối cảnh về cách chúng ta có thể sử dụng công nghệ này trong tương lai. Mạng lưới Bitcoin đang gặp phải những vấn đề rất giống với mạng lưới tin đồn Lightning - giao dịch tràn lan không có khả năng mở rộng tốt. Nếu bạn đã nghe nói về giao thức Erlay, có lẽ bạn đã biết Minisketch được phát triển để làm điều đó. Erlay sử dụng Minisketch để mã hóa mọi giao dịch trong một nhóm giao dịch. Sau đó, bạn có thể chia sẻ bản phác thảo với nút trong mạng lưới Bitcoin . ID giao dịch có độ dài 32 byte, nhưng trong Minisketch, chúng ta chỉ có 8 byte dữ liệu. Vì vậy, chúng ta cần nén ID giao dịch thành một dấu vân tay nhỏ hơn để biết sự khác biệt mà chúng ta tìm thấy đại diện cho giao dịch nào. Có một hàm băm có thể thực hiện việc này.
Nút cũng đối chiếu các tập hợp hàng tồn kho. Đây là một yếu tố khác khiến mọi thứ phức tạp hơn một chút. Giả sử chúng ta có một nhóm giao dịch, một cách để làm điều này là mã hóa mọi giao dịch trong một bản phác thảo, tất cả nút phải làm điều này, và sau đó tất cả đều phải giải quyết để xem có bất kỳ sự khác biệt nào trong nhóm giao dịch của nhau hay không. Nhưng điều này không phù hợp với cách thức hoạt động của Erlay. Nút theo dõi mọi nút mà nó giao tiếp, và nút nói, "Đã 15 giây trôi qua kể từ lần giao tiếp cuối cùng của chúng ta, và tôi đã lập một danh sách những điều tôi muốn nói với bạn mà tôi chưa nói. Đây là năm điều tôi muốn nói với bạn." Cùng lúc đó, nút Bob của bạn cũng làm điều tương tự, nhưng có thể anh ấy đã thu thập được bảy thứ. Erlay không yêu cầu mã hóa các giao dịch trong nhóm giao dịch (có thể lên tới hàng nghìn giao dịch), nó chỉ yêu cầu mã hóa năm giao dịch này và bảy giao dịch. Chúng ta đối chiếu hai giao dịch và có thể thấy rằng chỉ có ba điểm khác biệt giữa chúng. Sau khi hoàn tất việc đối chiếu, các tập hợp hàng tồn kho này sẽ được xóa và hai nút sẽ chuyển sang lần tiếp theo: ghi lại những điều mới xảy ra trong 15 giây tiếp theo.
Tin đồn về Lightning Network so với Chuyển tiếp giao dịch Bitcoin
Các vấn đề mà mạng Bitcoin gặp phải trong việc chuyển tiếp giao dịch rất giống với các vấn đề của Lightning Network Gossip, nhưng cũng có một số khác biệt. Đầu tiên, bất cứ khi nào bạn muốn sử dụng hàm băm ngắn để tạo dấu vân tay 64 bit, bạn phải lo lắng về xung đột. Ai đó có thể lợi dụng điều này và thử đi thử lại để tìm ID giao dịch (là giá trị băm) sẽ tạo ra cùng một dấu vân tay. Điều này trở thành giao diện tấn công từ chối dịch vụ. Điều này thực sự đáng lo ngại. Ngoài ra, còn có phân tích thời gian của các giao dịch riêng tư. Trong Gossip, không cần phải ẩn bất cứ điều gì vì mọi thông tin đều công khai. Ngoài ra, chúng ta có một mẹo nhỏ cho phép chúng ta không sử dụng hàm băm. Chúng ta không chỉ có một kiểu dữ liệu, có 3 loại tin nhắn mà chúng ta muốn chuyển tiếp.
Ứng dụng trong Gossip
Có ba loại tin nhắn này: channel_update , node_announcement và channel_announcement . channel_announcement chứa thông tin về phí giao dịch, trạng thái sử dụng kênh (đã kích hoạt hoặc đã tắt), số lượng HTLC tối đa được hỗ trợ, v.v. Thông tin này có lẽ chiếm tới 97% lưu lượng mạng lưới tin đồn, một con số khá lớn, vì vậy chúng tôi muốn hiệu quả hơn. Hai tin nhắn đầu tiên ( channel_update , node_announcement ) chỉ có hiệu lực trong hai tuần, vì vậy chúng sẽ được phát đi phát lại nhiều lần.
thử thách
Thách thức của chúng tôi là phải mã hóa cả 3 loại thông điệp. Chúng tôi chỉ có thể sử dụng 8 byte, nhưng chúng tôi có một công cụ gọi là "ID Kênh Ngắn (SCID)". Đây là thông tin liên kết một kênh với giao dịch tài trợ trên blockchain. Mỗi giao dịch trên blockchain là duy nhất. Đây là một lối tắt tuyệt vời mà chúng tôi có thể sử dụng. Trong node_announcement , không có kênh nào được liên kết với nút này, vì vậy rất khó để sử dụng ID kênh ngắn. Lý tưởng nhất, chúng tôi sẽ tham chiếu đến ID nút, tức là khóa công khai của nút. Nhưng khóa công khai cũng rộng 32 byte, vì vậy chúng tôi phải băm nó hoặc làm điều gì đó khác.
Sơ đồ mã hóa
Trên thực tế, chúng ta có thể sử dụng dữ liệu này khi mã hóa thông tin: Block Height , chỉ số giao dịch, chỉ số đầu ra, tức là ID kênh ngắn. Chúng ta có thể tham chiếu đến thông báo của một nút bằng cách nói "kênh cũ nhất cho nút này" và nút này nằm ở phía nào của kênh. Vì vậy, chúng ta có một phương pháp để xác định chính xác nút nào chúng ta đang nói đến. Thông thường, dữ liệu này là 8 byte, và chúng ta đang cố gắng nén nó vào 8 byte. Tất cả những gì chúng ta đang làm là loại bỏ một vài bit không cần thiết. Nếu một khối chỉ chứa 32.000 giao dịch, thì điều này có thể là đủ. Nếu bạn đang tài trợ cho một kênh Lightning, giao dịch tài trợ khó có thể có 1.000 đầu ra. Chúng ta đã tiết kiệm được một vài byte, vì vậy vẫn còn chỗ cho các thông tin khác, chẳng hạn như loại tin nhắn và nút này nằm ở phía nào của kênh. Đây là phương pháp chúng ta có thể xác định tin nhắn tin đồn nào đang được phát sóng với chính xác 64 bit. Cuối cùng, chúng ta có dấu thời gian. Đối với các tin nhắn được gửi định kì, chúng ta cần biết tin nhắn nào mới hơn và tin nhắn nào cũ hơn. Sẽ hữu ích nếu có một vài chi tiết để phân biệt chúng.
Lợi ích của hòa giải tập thể
Điều này có gì hấp dẫn? Câu trả lời ngắn gọn là: chúng ta có thể tiết kiệm ít nhất 60% băng thông tin đồn. Sau khi thực hiện xong, chúng ta có thể nói chuyện với nhiều nút hơn. Nói chuyện với nút hơn là một điều rất tốt, vì nó cải thiện độ tin cậy của tin đồn. Đặc biệt, các tin nhắn thông báo nút đã gặp khó khăn trong quá khứ, vì đối với hai tin nhắn kia, có một số phương pháp đơn giản để biết liệu bạn có bỏ lỡ chúng hay không. Đối với các tin nhắn cập nhật kênh, chúng ta đã thấy trong ví dụ mở đầu rằng trong trường hợp xấu nhất, đường dẫn thanh toán của chúng ta sẽ không thành công và gói tin lỗi sẽ mang theo bản cập nhật và chúng ta có thể nhận được phản hồi. Nhưng còn tin nhắn thông báo nút thì sao, nó cho bạn biết địa chỉ IP của nút. Nếu địa chỉ IP của nút thay đổi và bạn không thấy nó, bạn có thể không thể kết nối với nút đó nữa. Điều này rất tệ và hy vọng rằng sẽ có những lợi ích thực sự từ độ tin cậy được tăng lên.
Tiếp theo là gì?
Tôi có một vài câu hỏi chưa có lời giải. Một trong đó số đó là chúng ta có thể duy trì một bản phác thảo toàn cục hoặc thiết lập một kho lưu trữ cho mỗi nút. Có những lập luận cho cả hai phương pháp.
Một điều nữa là chúng tôi cũng có giới hạn tốc độ cho các tin nhắn tán gẫu mà chúng tôi nhận được. Nếu chúng tôi giới hạn tốc độ cho các tin nhắn tán gẫu một cách rất nghiêm ngặt, điều đó có thể làm giảm đáng kể dung lượng bản phác thảo của chúng tôi. Đối với các triển khai lựa chọn tính năng trung gian tập thể này, sẽ rất tốt nếu mọi người có thể thống nhất về khung thời gian để giới hạn tốc độ. Tôi đang nghiêng về việc sử dụng Block Height. Tôi đang cố gắng thuyết phục mọi người. Nếu tôi có thể liên kết mọi tin nhắn tán gẫu với Block Height hiện tại; chẳng hạn, một tin nhắn tán gẫu cho mỗi khối, hoặc một tin nhắn sau mỗi 100 khối, v.v. Điều này rất dễ xác minh vì bạn đã chạy một full nút.
Cuối cùng, về lâu dài, chúng tôi thực sự muốn loại bỏ ID kênh ngắn trong tin đồn, vì nó làm rò rỉ quyền riêng tư. Bạn không muốn công khai tất cả các giao dịch đầu ra chưa sử dụng. Chúng tôi chưa hoàn toàn sẵn sàng cho việc đó, nhưng một khi bắt đầu, chúng tôi sẽ chuyển sang các chương trình thu thập hàng tồn kho tương ứng với nút ngang hàng khác nhau. Điều này có thể đã chỉ ra những gì chúng ta nên lựa chọn ngay bây giờ.
kết luận
Gossip cho phép chúng ta xây dựng cái nhìn tổng quan về toàn bộ Lightning Network và tìm ra các đường dẫn. Minisketch thực sự rất tuyệt vời và mọi người nên thử. Hy vọng chúng ta có thể sử dụng nó để cải thiện độ tin cậy của tin đồn trên Lightning Network.
(qua)
