Nạo vét các kênh thu sét: Phương pháp có hệ thống

Tác giả: Clara & Sergei

Nguồn: https://raw.githubusercontent.com/s-tikhomirov/ln-jamming-simulator/master/unjamming-lightning.pdf

Bài viết gốc được xuất bản vào năm 2022 và đề xuất một phương pháp hiện được gọi là " chứng thực HTLC " để giải quyết cuộc tấn công chặn kênh Lightning.

bản tóm tắt

Người dùng mạng tài chính phi tập trung sẽ gặp phải các hình thức vi phạm an ninh mới. Trong một mạng như vậy, không thể áp dụng phương pháp ngăn chặn gian lận dựa trên danh tính, điều này mâu thuẫn với triết lý thiết kế hướng tới quyền riêng tư của nó. Do đó, các chiến lược giảm thiểu mới là cần thiết. Tuy nhiên, việc giới thiệu phương pháp mới có thể gây tổn hại đến các thuộc tính hữu ích khác của mạng.

Trong bài viết này, chúng tôi đề xuất một khuôn khổ đánh giá các chiến lược giảm nhẹ để sử dụng trong các mạng tài chính phi tập trung . Khung này cho phép các nhà nghiên cứu và nhà phát triển kiểm tra và so sánh các sửa đổi giao thức được đề xuất trên nhiều khía cạnh, chẳng hạn như quyền riêng tư, bảo mật và trải nghiệm người dùng.

Ví dụ: chúng tôi phân tích "cuộc tấn công gây nhiễu" trong Lightning Network. Lightning Network là mạng kênh thanh toán ngang hàng được xây dựng trên giao thức Bitcoin. Tấn công chặn là một cuộc tấn công từ chối dịch vụ rẻ tiền, cho phép kẻ thù tạm thời vô hiệu hóa một số kênh Lightning bằng cách làm ngập chúng bằng các khoản thanh toán không thành công.

Chúng tôi đề xuất một giải pháp thiết thực để ngăn chặn các cuộc tấn công kết hợp việc thanh toán phí vô điều kiện và danh tiếng nút. Theo chỉ dẫn của khung này, chúng tôi chứng minh rằng giải pháp của chúng tôi duy trì khả năng tương thích khích lệ của giao thức trong khi ngăn chặn các cuộc tấn công. Giải pháp này cũng duy trì tính bảo mật, quyền riêng tư và trải nghiệm người dùng và dễ triển khai. Chúng tôi hỗ trợ kết luận của mình bằng phân tích và mô phỏng. Hơn nữa, các giải pháp chống chặn của chúng tôi có thể giúp giảm thiểu các vấn đề khác, chẳng hạn như phát hiện số dư kênh độc hại.

1 Giới thiệu

Các giao thức blockchain phi tập trung , chẳng hạn như Bitcoin, đại diện cho một mô hình mới cho mạng tài chính. Nguyên tắc thiết kế cốt lõi của họ là ^{quyền truy cập} không đáng tin cậy1 và quyền riêng tư của người dùng. Với mục đích này, người dùng được xác định bằng khóa chung và có thể tạo số lượng khóa chung gần như không giới hạn. Bất kỳ ai cũng có thể tham gia mạng lưới như vậy mà không cần nhận dạng chính thức. Tính năng này làm cho phương pháp chống gian lận dựa trên danh tính truyền thống không thể thực hiện được ở cấp độ giao thức.

Đồng thời, các mạng tài chính phi tập trung lại bị những kẻ tấn công thèm muốn. Khi bị tấn công, người dùng và nhà cung cấp dịch vụ có thể bị mất tiền hoặc bị lộ quyền riêng tư.

Chú thích cuối trang 1: Mặt khác, các mạng dựa trên tuyển sinh được điều hành bởi một nhóm người tham gia đã biết. Những hệ thống như vậy nằm ngoài phạm vi của bài viết này.

Trong hoàn cảnh này, danh tiếng và khích lệ tài chính trở thành công cụ chính của các chiến lược giảm nhẹ. Chức năng của cái trước là xác định những kẻ xấu từ những người dùng trung thực và sau đó chặn chúng một cách có chọn lọc. Sau này áp đặt chi phí cho hành vi không mong muốn và cũng có thể bồi thường cho nạn nhân.

Khi đề xuất thay đổi giao thức, chúng tôi cần phân tích tác động của nó bằng cách xem xét toàn bộ mạng. Đề án mới không thể tạo ra các bề mặt tấn công mới, hy sinh trải nghiệm người dùng hoặc xâm phạm quyền riêng tư và bảo mật. Việc không nhận ra và giải quyết những đánh đổi không thể tránh khỏi có thể khiến các biện pháp giảm thiểu hoàn toàn vô dụng. Ngoài ra, độ khó khi thực hiện cũng phải được xem xét.

Bài viết này tập trung vào các chiến lược giảm thiểu các cuộc tấn công vào mạng tài chính không được phép. Một trong những mối quan tâm chính của chúng tôi là liệu một giải pháp được đề xuất, giả sử nó giải quyết được cuộc tấn công, có làm tổn hại đáng kể đến các khía cạnh khác của giao thức hay không. Để tránh việc “vứt trẻ cùng với nước tắm”, chúng tôi đề xuất một khuôn khổ chung để thiết kế và đánh giá các biện pháp giảm nhẹ. Ví dụ: chúng tôi xem xét các chiến lược giảm thiểu các cuộc tấn công chặn kênh trong Lightning Network (LN).

Lightning Network là mạng thanh toán được xây dựng trên Bitcoin và được thiết kế để giải quyết các hạn chế về thông lượng giao dịch vốn có trong giao thức blockchain Bitcoin . Các cuộc tấn công chặn kênh là một bề mặt tấn công DoS đã có từ lâu [47] nhưng chưa được giải quyết trong Lightning Network. Nó cho phép kẻ tấn công vô hiệu hóa kênh của nạn nhân một cách rẻ tiền và hiệu quả. Việc chặn các cuộc tấn công ngăn người dùng sử dụng chức năng cốt lõi của mạng và giảm lợi nhuận phí chuyển tiếp của họ. Cộng đồng Lightning Network đã thảo luận về nhiều biện pháp để giảm thiểu các cuộc tấn công chặn kênh [16], nhưng chưa có biện pháp nào được thực hiện.

Ghi chú của người dịch: “[]” là số tham khảo.

Để chứng minh sức mạnh của khuôn khổ của chúng tôi, chúng tôi sử dụng nó để chắt lọc một giải pháp hiệu quả để chặn kênh mà không có sai sót cơ bản.

đóng góp của chúng tôi

• Chúng tôi đề xuất một khuôn khổ chung để đánh giá các biện pháp giảm thiểu tấn công . Khung này giúp đảm bảo rằng những thay đổi được đề xuất không làm suy yếu đáng kể sức mạnh của giao thức hiện có.
• Chúng tôi đề xuất chiến lược giảm thiểu tình trạng tắc nghẽn kênh . Giải pháp của chúng tôi kết hợp các khoản phí được thanh toán vô điều kiện với hệ thống danh tiếng địa phương dựa trên hành vi trong quá khứ của nút. Chúng tôi đánh giá các giải pháp của mình thông qua lăng kính của khuôn khổ được xác định ở trên để biện minh cho các lựa chọn thiết kế của họ.

Sự sắp xếp cấu trúc sau đây như sau. Đầu tiên, chúng tôi trình bày khung đánh giá(Chương 2). Sau đó, chúng tôi cung cấp bối cảnh về Lightning Network và việc chặn kênh nói riêng (Phần 3). Chúng tôi sẽ áp dụng khung đánh giá trên để thiết kế các quyết định liên quan đến các biện pháp giảm thiểu tắc nghẽn kênh (Phần 4), sau đó đề xuất giải pháp giải quyết tắc nghẽn kênh (Phần 5), kết hợp phí vô điều kiện (Phần 5.1) và hệ thống Danh tiếng địa phương (Phần 5.2) . Sau đó chúng tôi thảo luận về kết quả mô phỏng (Phần 6) và xem xét các công việc liên quan (Phần 7). Cuối cùng, chúng tôi liệt kê các hướng công việc trong tương lai (Phần 8) và đưa ra kết luận (Phần 9).

2 Khung đánh giá các chiến lược giảm nhẹ

Chúng tôi khuyên đánh giá các biện pháp giảm thiểu từ các quan điểm sau.

hiệu quả . Các biện pháp giảm thiểu nên ngăn chặn hoặc ngăn chặn các cuộc tấn công. Đối thủ phải trả giá giá, có thể là tiền tệ (trả giá phí xử lý hoặc chịu phạt), thời gian (đòi hỏi danh tiếng trước khi tấn công) hoặc kết hợp cả hai. Lưu ý rằng động cơ của kẻ tấn công không nhất thiết chỉ đơn thuần là tiền bạc (ví dụ: muốn phá hoại mạng một cách ác ý).

Khích lệ khả năng tương thích . Các biện pháp giảm thiểu cần duy trì tính tương thích khích lệ của giao thức. Mạng phi phi tập trung dựa vào tính hợp lý của người tham gia: việc tuân theo các quy tắc phải phù hợp với lợi ích tốt nhất của họ. Mạng thanh toán nên khích lệ nút chuyển tiếp thanh toán và báo cáo lỗi một cách trung thực.

Trải nghiệm người dùng . Các biện pháp giảm thiểu không thể phá hủy trải nghiệm người dùng. Các thay đổi về giao diện phải trực quan và dễ giải thích. Trải nghiệm người dùng nên đánh giá từ cả góc độ của người dùng cuối và nhà cung cấp dịch vụ chuyên nghiệp.

Quyền riêng tư và bảo mật . Các biện pháp giảm thiểu không được hy sinh đáng kể quyền riêng tư của người dùng. Về vấn đề bảo mật, chúng tôi phải đảm bảo rằng những thay đổi được đề xuất đối với giao thức không tạo ra các bề mặt tấn công mới. Những tác động tiêu cực của các biện pháp giảm thiểu phải được cân nhắc cẩn thận với lợi ích tiềm năng của chúng.

Khó khăn trong việc thực hiện . Các biện pháp giảm thiểu phải dễ thực hiện. Những thay đổi về giao thức đòi hỏi sự đồng thuận mạnh mẽ giữa cộng đồng (đặc biệt là các nhà phát triển) [46]. Những đề xuất dễ thực hiện có nhiều khả năng được thông qua hơn là bị trì hoãn vĩnh viễn.

Khung trên có thể được sử dụng như thế này. Đầu tiên, hãy xem xét tất cả các cách phân loại có thể có của các biện pháp giảm nhẹ. Thứ hai, loại trừ các chiến lược rõ ràng không tương thích với ít nhất một trong các tiêu chí trên. Cuối cùng, so sánh chi phí và lợi ích của các phương án còn lại trong bối cảnh mạng cụ thể.

Chúng tôi muốn chỉ ra rằng hai tiêu chí đầu tiên (tính hiệu quả và khả năng tương thích khích lệ) là tiêu chí cứng cho một giải pháp hữu ích. Ba mục cuối cùng thường đòi hỏi sự đánh đổi. Đôi khi, việc sử dụng kiến ​​trúc tập trung hơn hoặc tích lũy nhiều dữ liệu người dùng hơn có thể cải thiện trải nghiệm người dùng nhưng điều này sẽ ảnh hưởng đến quyền riêng tư. Tương tự, các chính sách dễ thực hiện hơn có thể yêu cầu người dùng tin tưởng thêm vào một số bên thứ ba được cài đặt sẵn.

Lưu ý rằng một số tiêu chí trên (ít nhất ở một mức độ nào đó) là khách quan và có thể định lượng được, trong khi những tiêu chí khác phần lớn mang tính chủ quan. Việc bỏ qua những sự đánh đổi này phụ thuộc vào mạng và cuộc tấn công cụ thể.

3 Tổng quan về Lightning Network và Chặn kênh

Các mạng blockchain không có quyền phải đối mặt với những thách thức về khả năng mở rộng vốn có, đó chính xác là những gì các giao thức Lớp 2 (L2) đang cố gắng giải quyết [19]. Họ hy vọng sẽ tăng thông lượng giao dịch đồng thời tận dụng sự đảm bảo an ninh của mạng blockchain cơ bản.

Lightning Network là giao thức L2 dựa trên Bitcoin chính [38]. Các cặp nút Lightning mở các kênh thanh toán bằng cách khóa tiền trong một địa chỉ cấp vốn thuộc sở hữu chung. Sau đó, họ thực hiện thanh toán bằng cách phản ánh việc phân bổ vốn mới nhất trong trạng thái kênh . Các khoản thanh toán diễn ra ngoài chuỗi và chỉ được giải quyết trên chuỗi khi cần thiết. Cơ chế phạt đảm bảo an ninh kinh tế cho việc cập nhật số dư.

Để bắt đầu thanh toán nhiều bước, trước tiên người gửi sẽ tìm một đường dẫn phù hợp được kết nối bằng các kênh ^có thể dẫn đến người nhận2. Giả sử có một nút($U_i, 0 <= i <= m$) trên đường dẫn $U_0, … , U_m$. Đường dẫn đến người gửi ($U_j, 0 <= j <= i$) được gọi là "ngược dòng" và đường dẫn đến người nhận ($U_j, i < j <= m$) được gọi là "hạ lưu". Các nút ngang hàng của U _i trên đường dẫn ($U_{i-1}$ và $U_{i+1}$) lần lượt được gọi là nút ngược dòng và nút xuôi dòng của nút .

Mỗi nút định tuyến , sau khi nhận được yêu cầu chuyển tiếp, sẽ chuyển tiếp khoản thanh toán hoặc để nó thất bại . Nếu một nút chuyển tiếp hủy bỏ một giao dịch, nó sẽ thông báo cho người gửi, người này có thể cố gắng bỏ qua nút bị lỗi. Người nhận, sau khi nhận được khoản thanh toán, cũng có thể yêu cầu số tiền hoặc chấm dứt khoản tiền đó. Khi lĩnh nhận thanh toán từ nút định tuyến cuối cùng, người nhận phải tiết lộ một giá trị bí mật để nút chuyển tiếp có thể lĩnh nhận tiền từ nút ngang hàng ngược dòng của nó, v.v.

Nút nhận cũng phải cập nhật trạng thái kênh với nút ngược dòng khi từ chối các khoản thanh toán đến. Nút dự kiến ​​sẽ chỉ chấm dứt thanh toán khi chúng thiếu tài nguyên (ví dụ: tính thanh khoản) để chuyển tiếp thanh toán. Nút thường không giới hạn lượng thanh khoản có thể được sử dụng cho khoản thanh toán ^đến3 .

Một khoản thanh toán, dù bị thu hồi hay chấm dứt, đều được gọi là một khoản thanh toán . Các khoản thanh toán không thể giải quyết trong một khoảng thời gian sẽ bị hủy và kênh sẽ bị đóng ⁴ .

Các khoản thanh toán chưa được giải quyết sẽ khóa một số thanh khoản ở mọi kênh trong quá trình thực hiện. Các quỹ thanh khoản này sẽ không được sử dụng để chuyển tiếp các khoản thanh toán khác. Hơn nữa, một kênh chỉ có thể giữ một số khoản thanh toán đang chờ xử lý nhất định cùng một lúc. Hạn chế này xuất phát từ các quy tắc giao thức Bitcoin: việc đóng kênh gian lận với quá nhiều khoản thanh toán đang chờ xử lý sẽ không bị xét xử trên ^- Chuỗi. Do đó, chúng tôi nói rằng mỗi kênh có số lượng khe thanh toán giới hạn . Mỗi khoản thanh toán đang chờ xử lý chiếm một vị trí thanh toán và một tỷ lệ thanh khoản.

Để bảo mật, thanh toán Lightning sử dụng định tuyến củ hành. Một nút định tuyến biết nút trực tiếp của nó trên đường đi nhưng không có cách nào biết được người gửi ban đầu và ^{người nhận} cuối cùng6.

Chú thích cuối trang 2: Một khoản thanh toán có thể được chia nhỏ và gửi theo nhiều đường dẫn khác nhau [40].

Chú thích 3: Các phương pháp kiểm soát dòng chảy dựa trên van gần đây đã được đề xuất [36].

Chú thích cuối trang 4: Có thể tìm thấy mô tả giao thức toàn diện, ví dụ: [8].

Chú thích cuối trang 5: Tại bất kỳ thời điểm nào, một kênh chỉ có thể duy trì tối đa 483 khoản thanh toán đang chờ xử lý. Người dùng cũng có thể đặt giới hạn thấp hơn cho các kênh của riêng họ.

Chú thích 6: Giả định này có thể bị phá vỡ trong các cuộc tấn công tính thời gian [43].

Chặn kênh

Chặn là một cuộc tấn công từ chối dịch vụ trên các kênh Lightning. Kẻ tấn công kiểm soát cả hai đầu của đường dẫn mục tiêu, gửi thanh toán ở một đầu và từ chối yêu cầu ở đầu kia, do đó chặn thanh khoản và khe thanh toán ở tất cả các kênh dọc theo toàn bộ đường dẫn. Mục tiêu của cuộc tấn công chặn có thể là vô hiệu hóa một nhóm kênh nhất định (ví dụ: các kênh thuộc về đối thủ thương mại) hoặc thậm chí toàn bộ mạng.

Chúng ta cần phân biệt giữa chặn dựa trên thanh khoản và chặn dựa trên vị trí thanh toán . Cái trước chủ yếu là để khóa tính thanh khoản của kênh của nạn nhân, trong khi cái sau muốn chiếm tất cả các vị trí thanh toán. Nhìn chung, việc chặn dựa trên thanh khoản trả giá tốn kém hơn. Để chiếm một vị trí thanh toán, chỉ cần yêu cầu chuyển tiếp vượt quá kích thước thanh toán tối thiểu là ⁷ mà nút mục tiêu sẵn sàng chuyển tiếp. Việc chặn dựa trên các vị trí thanh toán được cho là "hiệu quả" hơn vì cho dù công suất của kênh nạn nhân có lớn đến đâu thì việc chặn kênh đó cũng chỉ trả giá một số tiền tương đương.

Chúng ta cũng cần phân biệt giữa chặn nhanh và chặn chậm . Trong một cuộc tấn công chặn nhanh, kẻ tấn công gửi một loạt khối được giải quyết trong vòng vài giây, do đó mô phỏng một khoản thanh toán trung thực không thành công. Ngược lại, tình trạng tắc nghẽn chậm sẽ được giải quyết sau một thời gian dài trì hoãn (tính bằng giờ hoặc thậm chí vài ngày), cho phép nạn nhân phát hiện cuộc tấn công. Ranh giới giữa hai điều này phụ thuộc vào định nghĩa chủ quan về độ trễ giải quyết tối đa đối với một khoản thanh toán trung thực.

Những kẻ tấn công có thể theo đuổi nhiều mục tiêu khác nhau. Chúng tôi muốn chỉ ra rằng người dùng tham gia mạng thường có hai mục tiêu chính: gửi và nhận thanh toán; và kiếm phí từ việc chuyển tiếp thanh toán. Do đó, kẻ tấn công có thể muốn ngăn người dùng trao đổi thanh toán hoặc có thể muốn ngăn nhà cung cấp dịch vụ chuyển tiếp nhận lợi nhuận hoa hồng.

Chặn các cuộc tấn công hoàn toàn miễn phí. Kẻ tấn công không cần phải trả phí vì nút định tuyến không tính phí cho các khoản thanh toán bị chấm dứt. Chi phí duy nhất đối với kẻ tấn công là ^{chi phí} cơ hội9 của số tiền bị khóa trong cuộc tấn công và chi phí mở kênh. Định tuyến kiểu củ hành làm cho việc thiết kế giảm thiểu tắc nghẽn trở nên khó khăn hơn vì danh tính của người gửi không thể xác định được đối với nút định tuyến.

Chú thích cuối trang 7: Kích thước chặn thanh toán dựa trên khe thanh toán cũng lớn hơn giới hạn bụi - là số lượng tối thiểu chiếm một khe thanh toán trong kênh chuyển tiếp. Các khoản thanh toán nhỏ hơn giới hạn bụi được cho phép (mặc dù đảm bảo bảo mật của chúng sẽ yếu hơn), nhưng chúng không thể được sử dụng trong các cuộc tấn công chặn (dựa trên vị trí thanh toán) vì chúng không chiếm vị trí thanh toán. Hơn nữa, vì giá trị của nó quá nhỏ nên việc tiến hành các cuộc tấn công chặn thanh khoản là không thực tế.

Chú thích cuối trang 8: Về mặt kỹ thuật, kẻ tấn công cũng có thể ngụy trang việc phong tỏa thành một khoản thanh toán thành công, trong trường hợp đó sẽ trả giá phí xử lý . Nhưng trong phần tiếp theo, chúng tôi luôn cho rằng việc chặn thanh toán sẽ chấm dứt thay vì thành công.

Chú thích 9: Để biết thêm chi tiết về chi phí kênh, xem [18].

4 Lựa chọn thiết kế cho các biện pháp giảm thiểu ùn tắc

Và hàng loạt đề xuất chiến lược giảm ùn tắc đã xuất hiện [16, 33]. Chúng có thể được phân loại là dựa trên chi phí tiền tệ cũng như dựa trên danh tiếng. Để phân tích một cách có hệ thống không gian thiết kế giải pháp, trước tiên chúng tôi liệt kê các lựa chọn thiết kế có sẵn và sau đó đánh giá các lựa chọn này dựa trên khuôn khổ được mô tả trong Chương 2.

4.1 Kế hoạch tiền tệ

Mục tiêu của kế hoạch tiền tệ là làm cho các cuộc tấn công trở nên đắt đỏ hơn. Những chiến lược này cũng có thể bồi thường cho nạn nhân. Trong bối cảnh một cuộc tấn công chặn, ý tưởng của sơ đồ tiền tệ là tính phí xử lý các khoản thanh toán bị chấm dứt ngoài phí xử lý hiện tại ( phí xử lý chỉ được tính cho các khoản thanh toán thành công ). Chúng tôi xem xét các lựa chọn thiết kế sau đây.

• Ai nhận được phí xử lý này? Người nhận có thể là: nút hạ lưu, bên thứ ba đã được thỏa thuận hoặc đơn giản là không có ai (có thể đốt phần phí này).
• Nên sử dụng loại tiền tệ nào để thanh toán khoản phí này? Phí xử lý có thể được thanh toán bằng tài sản gốc của mạng (trong trường hợp Lightning Network, Bitcoin) hoặc tài sản khác. Trong kế hoạch đốt phí xử lý, phí xử lý có thể được thu bằng cách giải bài toán khối lượng công việc.
• Tôi có cần thanh toán phần phí xử lý này vô điều kiện không? Thiết kế phí xử lý đơn giản nhất là phí xử lý được trả trước vô điều kiện (nghĩa là khi thanh toán được thực hiện). Một cách khác là trả lại phần phí trả trước này (đối với các trường hợp chấm dứt) khi thanh toán thành công. Bạn cũng có thể xem xét các lĩnh vực khác.
• Làm thế nào để tính số tiền của phần phí xử lý này? Hiện tại, phí Lightning Network bao gồm hai phần: phí cơ bản không đổi và phí tỷ lệ tuyến tính với số tiền thanh toán. Các thuật toán phí phức tạp hơn có thể phụ thuộc vào các tham số khác.

Việc trả phí cho một nút đơn giản hơn việc trả phí cho bên thứ ba vì việc giới thiệu bên thứ ba sẽ làm phức tạp thêm khích lệ kinh tế. Bản thân Lightning Network không cung cấp giải pháp rõ ràng để đốt^tiền một cách có thể chứng minh được10, vì vậy giải pháp dựa trên bằng chứng về đốt rất khó thực hiện. Do đó, chúng tôi thu hẹp không gian thiết kế thanh toán phí cho nút ngang hàng ở hạ lưu.

Phí xử lý vô điều kiện không hoàn trả sẽ dễ thực hiện hơn. Ít nhất, cơ chế hoàn trả yêu cầu chuyển giao giá trị lần giá trị.

Đối với việc tính toán số tiền phí xử lý, để đơn giản, chúng tôi áp dụng cấu trúc tương tự như phí thành công hiện tại (tức là phí xử lý cơ sở cộng với phí xử lý theo tỷ lệ). Chúng tôi giả định rằng số tiền phí luôn dương ¹¹ (tức là luôn được trả cho nút dưới , không phải nút cấp trên ). Sẽ rất tốt nếu gắn số tiền phí với thời gian giải quyết thanh toán thực tế, nhưng hiện tại chúng tôi không biết cách nào đáng tin cậy để thực hiện ý tưởng này.

Về trải nghiệm người dùng, quyền riêng tư và bảo mật, lợi ích và hạn chế của các thiết kế tùy chọn là tương tự nhau.

Chú thích cuối trang 10: Ngược lại, Bitcoin lớp cơ sở có thể được gửi đến các địa chỉ được chứng minh là không thể sử dụng được.

Chú thích 11: Phí hai chiều (bao gồm phí trả cho nút ngược dòng) được thảo luận trong [16]. Bởi vì phí quảng cáo âm có thể tạo ra những luồng không mong muốn nên đề xuất này cần được đánh giá thêm.

4.2 Sơ đồ danh tiếng

Trong chiến lược dựa trên danh tiếng, nút theo dõi mức độ tin cậy của chúng đối với nút khác. Trong bối cảnh ngăn chặn các cuộc tấn công, điểm danh tiếng giúp nút định tuyến phân biệt giữa nút tốt và nút hàng xấu, sau đó chấm dứt thanh toán từ nút sau hoặc ngắt kết nối hoàn toàn với chúng. Khi thiết kế một chương trình danh tiếng, chúng tôi muốn xem xét các lựa chọn thiết kế sau.

• Danh tiếng của ai ảnh hưởng đến việc chuyển tiếp thanh toán? Một mẫu thiết kế phổ biến trong mạng P2P [28] là nút định tuyến chỉ xem xét danh tiếng của nút dòng của nó. Ngoài mô hình này, danh tiếng của người gửi ban đầu cũng có thể được gắn liền với khoản thanh toán. Chúng tôi gọi chương trình chỉ chấm điểm nút là chương trình danh tiếng địa phương và ngược lại là chương trình toàn cầu .
• Cơ chế danh tiếng có cần sự đồng thuận? Nút có thể ghi điểm một cách độc lập hoặc chúng có thể cố gắng đạt được sự đồng thuận về danh tiếng của tất cả nút ở cấp độ mạng.
• Danh tiếng có đồng nhất không? Điểm danh tiếng đồng nhất ở dạng mã thông báo, có thể được chuyển giữa nút. Mặt khác, điểm danh tiếng không đồng nhất không thể tách rời khỏi nút nơi điểm được chỉ định ban đầu.
• Làm thế nào để ghi điểm? Một cách tiếp cận dựa trên hành vi trong quá khứ của nút. Một phương pháp khác dựa trên cam kết đối với một số tài nguyên khan hiếm, chẳng hạn như Bằng chứng công việc hoặc bằng chứng về quyền sở hữu Bitcoin( Chứng chỉ cổ phần [34]).

Việc gắn danh tiếng của người gửi vào các khoản thanh toán vi phạm mục tiêu bảo mật của Lightning Network.

Vì nút chỉ có thể trải nghiệm một cách khách quan hành vi của nút nên điểm danh tiếng phải mang tính cục bộ.

Trước cuộc tấn công Phù thủy, chúng tôi thích tính điểm độc lập hơn là hệ thống danh tiếng dựa trên sự đồng thuận.

Chúng tôi thích giải pháp không thể thay thế được vì thị trường thứ cấp dành cho mã thông báo danh tiếng đặt ra thách thức lớn đối với tính bảo mật của ^{thiết kế12} .

Cuối cùng, chúng tôi chọn cách tính điểm dựa trên hành vi trong quá khứ thay vì cam kết về nguồn lực khan hiếm. Đánh giá sự thất bại của nó như một biện pháp ngăn chặn bom [25], Bằng chứng công việc nhìn lên vô dụng từ góc độ này. Đặc biệt, độ khó của khối lượng công việc nhằm ngăn chặn một cuộc tấn công sẽ cao đến mức không thể chấp nhận được đối với những người dùng trung thực. Chúng tôi để đánh giá các chương trình danh tiếng khác dựa trên nguồn lực khan hiếm cho công việc trong tương lai.

Chú thích cuối trang 12: Nghiên cứu trước đây đã chứng minh rằng việc thiết kế thị trường lần cho mã thông báo ứng dụng là một nhiệm vụ khó khăn [10, 14, 51]. Ví dụ: các tổ chức lớn có thể có được lượng lớn token như vậy để thao túng thị trường.

5 Giải pháp ngăn chặn các cuộc tấn công của chúng tôi

Dựa trên các lập luận trong Phần 4, chúng tôi đề xuất chiến lược hai hướng để giảm thiểu các cuộc tấn công chặn.

1. Phí vô điều kiện , được trả cho nút hạ lưu, giải quyết tắc nghẽn kênh nhanh chóng bằng cách áp dụng một mức giá nhỏ cho mỗi khoản thanh toán.
2. Danh tiếng địa phương , dựa trên hành vi trong quá khứ, giải quyết các cuộc tấn công chặn chậm bằng cách trừng phạt nút chuyển tiếp các khoản thanh toán mất quá nhiều thời gian để giải quyết.

Trong Phần 5.1 và 5.2, chúng tôi cung cấp thêm chi tiết về phí vô điều kiện và hệ thống danh tiếng địa phương. Chúng tôi kiểm tra hai phần này trong giải pháp của mình thông qua khuôn khổ được đề xuất trong Phần 2, sau đó thảo luận về các phương pháp hay nhất để lựa chọn tham số.

5.1 Phí xử lý vô điều kiện

Hãy xem xét đường dẫn thanh toán $U_0, … , U_m$. Đặt $f_{i, i+1}$ biểu thị phí xử lý được $U_i$ trả cho $U_i+1$, trong đó$i \in [0, m-1]$ . Chúng tôi ghi lại khoản phí phải trả trong trường hợp thành công là $f^S$ và phí xử lý được thanh toán vô điều kiện là $f^N$. Đối với $X \in {S, N}$ , lợi nhuận từ phí thuộc loại $X$ là chênh lệch giữa số tiền $U_i$ đã trả và số tiền nhận được:

$$F_i^X = f_{i-1}^X - f_{i, i+1}^X$$......(1)

Đối với nút định tuyến $U_i$, gói phí tích hợp của chúng tôi như sau (xem Hình 1).

- Hình 1. Cây quyết định của nút định tuyến U _i . Các giá trị số trên lá biểu thị tổng thu nhập-

1. $U_{i-1}$ trả $f_{i-1, i}^N$ cho $U_{i}$.
2. $U_{i}$ quyết định chấm dứt hay chuyển tiếp khoản thanh toán. Nếu $U_{i}$ chấm dứt thanh toán, nó sẽ không nhận thêm bất kỳ khoản phí nào.
3. Nếu $U_{i}$ quyết định chuyển tiếp, $f_{i1, i+1}^N$ sẽ được thanh toán cho $U_{i+1}$.
4. Quá trình trên tiếp tục cho đến khi thanh toán kết thúc ở một bước nhảy nhất định hoặc thành công. Nếu thanh toán thành công, $U_{i}$ sẽ nhận được $f_{i-1, i}^S$ và trả giá$f_{i, i+1}^S$.

Nếu $U_{i}$ chấm dứt khoản thanh toán này (thay vì tiếp tục chuyển tiếp), lợi nhuận từ phí của nó là $f_{i-1, i}^N$. Trong trường hợp chuyển tiếp nhưng việc thanh toán bị chấm dứt xuôi dòng là $F_{i}^S$; trong trường hợp chuyển tiếp và thanh toán thành công là $F_i^S + F_i^N$.

Lưu ý rằng mỗi khoản thanh toán $f$ không chỉ bao gồm phí xử lý được trả cho nút ngang hàng xuôi dòng mà còn bao gồm phí xử lý cho tất cả nút định tuyến trong tương lai. Ví dụ: hãy tưởng tượng đường dẫn bốn nút$(U_1, U_2, U_3, U_4)$ trong đó $U_2$ và $U_3$ tính phí cố định 1 satoshi cho mỗi lần ^{thanh toán13} . Khi người gửi $U_1$ chuyển tiếp khoản thanh toán đến $U_2$, khoản thanh toán đó sẽ đi kèm với phí xử lý là 2 satoshi: $f_{1, 2} = 2$ nhưng $f_{2, 3} = 1$. Do đó, lợi nhuận từ phí của hai nút lần lượt bằng: $F^2 = f_{1, 2} - f_{2, 3} = 2 -1 = 1$, $F^3 = f_{2, 3 } - f_{3, 4} = 1 - 0 = 1$. Điều này đúng cho dù thanh toán thành công hay thất bại.

Chú thích cuối trang 13: “Satoshi” là đơn vị nhỏ nhất của Bitcoin. 1 BTC tương đương 100 triệu satoshi.

hiệu quả

Với phí vô điều kiện, việc chặn các cuộc tấn công không còn miễn phí nữa. Hơn nữa, hai phần của phí vô điều kiện (phí cơ bản và phí tỷ lệ) tương ứng giải quyết các cuộc tấn công chặn dựa trên phần giữ chỗ và dựa trên thanh khoản. Các khoản thanh toán chặn giá trị thấp nhằm mục đích chiếm chỗ thanh toán, nhưng hiện trả giá phí xử lý cơ bản; phí xử lý theo tỷ lệ có thể ngăn chặn tốt hơn việc chặn giá trị cao nhằm mục đích khóa thanh khoản.

Sử dụng Hệ số phí được thiết lập hợp lý, phí vô điều kiện có thể cho phép nút định tuyến kiếm được lợi nhuận từ tắc nghẽn tương tự như ^{các khoản thanh toán} trung thực14, từ đó bù đắp cho những tổn thất kinh tế mà họ phải gánh chịu khi chặn các cuộc tấn công. Hiệu ứng này có thể đạt được bằng cách đặt mức phí vô điều kiện tương đối thấp, vì kẻ tấn công phải tiếp tục gửi các khoản thanh toán chặn để duy trì hiệu quả của cuộc tấn công, trong khi các khoản thanh toán trung thực thường chỉ chiếm một tỷ lệ nhỏ tài nguyên kênh. Mô phỏng cũng xác nhận trực giác này (xem Chương 6).

Chú thích cuối trang 14: Lợi nhuận phí mà một nút kiếm được từ các khoản thanh toán trung thực phụ thuộc vào vị trí của nó trong mạng, thói quen quản lý thanh khoản của nó (ví dụ: tái cân bằng) và các yếu tố khác.

Khả năng tương thích khích lệ

Để chuyển tiếp thanh toán, nút định tuyến sẽ phân bổ một vị trí thanh toán và một số thanh khoản trong một trong đó các kênh của nó cho nút hàng phía dưới của nó. Những tài nguyên này không được sử dụng cho các mục đích khác trong khi thanh toán đang chờ xử lý. Do đó, chúng tôi phải đối mặt với thách thức về khả năng tương thích khích lệ: nút định tuyến trước tiên có thể nhận khoản phí vô điều kiện và sau đó cố tình chấm dứt thanh toán. Để đảm bảo khả năng tương thích khích lệ, lợi nhuận từ phí từ thanh toán thành công phải bù đắp cho nút định tuyến về rủi ro của họ trong hoạt động chuyển tiếp.

Đặt $\theta$ là xác suất chấm dứt thanh toán ¹⁵ . Nếu $U_i$ quyết định chuyển tiếp khoản thanh toán, lợi nhuận phí dự kiến ​​của nó là:

$$\mathbb{E}(F_i|Forward)=(1-\theta)(F_i^S + F_i^N) + \theta*F_i^N$$ ……(2)

$$=F_i^N + (1-\theta)F_i^S = (f_{i-1, i}^N + (1-\theta)F^S)$$ ……(3)

Nếu $U_i$ hoàn toàn ngừng thanh toán thì lợi nhuận chỉ là $f_{i-1, i}^N$. Để đảm bảo rằng $U_i$ thích thanh toán chuyển tiếp hơn, lợi nhuận dự kiến ​​của các khoản thanh toán chuyển tiếp phải cao hơn lợi nhuận khi chấm dứt ngay lập tức:

$$f_{i-1, i}^N - f_{i, i+1}^N + (1-\theta)F^S > f_{i-1, i}^N$$ ……(4 )

$$(1-\theta)F^S > f_{i, i+1}^N$$......(5)

Nói cách khác, lợi nhuận dự kiến ​​bổ sung từ các khoản thanh toán chuyển tiếp phải có khả năng bù đắp phí xử lý vô điều kiện mà nút chuyển tiếp thanh toán cho nút hạ lưu. Người gửi cũng nên tránh sử dụng các kênh liên tục chấm dứt thanh toán, ngay cả khi các kênh này tuyên bố rằng họ chỉ tính phí thấp: đây có thể là một chiến lược độc hại nhằm tập trung vào các khoản phí vô điều kiện và không chuyển tiếp thanh toán.

Chú thích cuối trang 15: Chúng tôi sử dụng phương pháp tương tự như [37] (Phần 4.2).

trải nghiệm người dùng

Mối lo ngại chính về trải nghiệm người dùng là việc tính phí đối với các khoản thanh toán không thành công có thể khiến người dùng nản lòng. Ví trừu tượng hóa những chi tiết này một cách thích hợp. Trên thực tế, số lần thử dự kiến ​​lần lần thanh toán thấp tới ¹⁶ , mặc dù xác suất chấm dứt $\theta$ nhìn chung là cao. Để thanh toán thành công ở nhiều nhất $K$ bước nhảy với xác suất ít nhất là $p$, cần phải đáp ứng các điều kiện sau:

$$1 - \theta^K > p$$......(6)

Điều này tương đương với:

$$log(1 - p) > K log \theta$$......(7)

Vì $log \theta < 0$ nên:

$$\frac{log(1 - p)}{log \theta} < K$$......(8)

- Hình 2. Số lần thử dự kiến ​​là hàm của xác suất thành công cần thiết p theo các xác suất chấm dứt thanh toán khác nhau θ. -

Số lần thử cần thiết chỉ tăng trưởng chậm (logarit với xác suất thành công cần thiết $p$). Ngay cả khi giả sử $\theta = 20%$, xác suất thành công sẽ lần lượt đạt 80%, 96% và 99% sau một, lần và ba lần thử. Chúng tôi kết luận rằng tác động tiêu cực đến trải nghiệm người dùng là rất nhỏ vì mỗi khoản thanh toán chỉ yêu cầu lần thử và do đó mức phí vô điều kiện thấp (xem Hình 2).

Quyền riêng tư và bảo mật

Nút định tuyến sẽ không thể biết vị trí của chúng trên đường chuyển tiếp. Các khoản phí vô điều kiện sẽ làm suy yếu thuộc tính này: nút định tuyến có thể suy đoán khoảng cách của chúng đến người nhận cuối cùng từ số tiền phí và chính sách phí được mỗi nút tiết lộ17 ^. Vấn đề này có thể được giải quyết bằng cách yêu cầu người gửi phân bổ một phần thanh toán dưới dạng phí vô điều kiện cho bước nhảy cuối cùng (mà người nhận dự kiến ​​sẽ nhận được), làm cho nó có vẻ như đường dẫn sẽ mở rộng hơn nữa. Nhược điểm của phương pháp này là mức phí vô điều kiện cao hơn có thể dẫn đến khích lệ không nhất quán đối với nút định tuyến. Chúng tôi không cho rằng vấn đề này sẽ trở nên nghiêm trọng vì số tiền phí vô điều kiện rất thấp.

Chú thích cuối trang 17: Từ góc độ này, phí xử lý được tính cho các khoản thanh toán thành công ít gặp vấn đề hơn vì nút định tuyến không biết tỷ lệ nào trong số tiền thanh toán thể hiện phí xử lý. Ngược lại, phí vô điều kiện không phụ thuộc vào số tiền thanh toán.

Khó khăn trong việc thực hiện

Phí vô điều kiện rất dễ thực hiện. Một phương pháp là trả tiền trước. Một phương pháp khác là nút hạ lưu $U_i$ trước tiên giữ lại phí xử lý $f_{i-1, i}^N$ khi trả lại tiền về $U_{i-1}$ khi thanh toán bị chấm dứt, giống như một bằng chứng của khái niệm Thực hiện chỉ làm điều đó [48]. Nhiệm vụ triển khai khác bao gồm quảng cáo các chính sách phí bổ sung trong các tin nhắn buôn chuyện và xem xét các khoản phí vô điều kiện trong việc lựa chọn định tuyến.

5.2 Điểm danh tiếng địa phương

Bản thân các khoản phí vô điều kiện không đủ để giải quyết các cuộc tấn công chặn. Vì vậy, chúng ta cũng cần một chiến lược giảm thiểu dựa trên danh tiếng. Theo định nghĩa, sơ đồ danh tiếng bao gồm ba phần: khởi tạo, cập nhật danh tiếng và đưa ra lựa chọn dựa trên điểm danh tiếng.

khởi tạo

Trong giai đoạn khởi tạo, nút cần thiết lập các tham số sau:

• τ (giây) - thời gian giải quyết tối đa để phân biệt các khoản thanh toán trung thực với các khoản thanh toán không trung thực;
• t (giây), T​ (giây), ​A​ (satoshi/giây) – thông số cập nhật danh tiếng (xem bên dưới);
• K​ (số nguyên), L (satoshi) - hạn mức rủi ro cao đối với các vị trí thanh toán và thanh khoản .

Giá trị cụ thể của các tham số trên phụ thuộc vào mức độ rủi ro của nút . Ví dụ: giá trị K và L cao hơn phản ánh mức độ chấp nhận rủi ro cao hơn. Nút định tuyến phải cân nhắc lợi nhuận tăng lên từ các khoản thanh toán trung thực nhưng rủi ro(ví dụ: từ nút mới) với rủi ro chặn các cuộc tấn công tương ứng. Các giá trị của t, T và A có thể phụ thuộc vào chi phí mở các kênh mới để xử lý các khoản thanh toán trung thực trong khi các kênh hiện tại vẫn bị chặn.

Cập nhật điểm danh tiếng

Chúng tôi xem xét hai giá trị có thể có cho điểm danh tiếng: cao và thấp (cũng có thể có các sơ đồ chi tiết hơn). Ban đầu, tất cả nút chỉ có điểm thấp. Một khoản thanh toán được coi là trung thực nếu nó được thanh toán trong vòng τ giây. Nếu không, nó được coi là một khối. Một nút được coi là tốt nếu nó chỉ chuyển tiếp các khoản thanh toán trung thực. Hơn nữa, các khoản thanh toán này chỉ yêu cầu phí xử lý A satoshi mỗi giây cho nút định tuyến. Nếu một nút hoạt động tốt trong một khoảng thời gian đủ dài thì điểm của nó sẽ được nâng cấp.

Cụ thể hơn, điểm danh tiếng được cập nhật như sau:

• Nếu một nút duy trì hành vi tốt trong khoảng thời gian t, hãy thay đổi điểm của nó thành cao ;
• Chuyển sang mức thấp nếu hành vi tốt không thể được duy trì trong t giây trong khoảng thời gian T giây.

Thuật toán cập nhật danh tiếng dựa trên cửa sổ thời gian trượt có thể chấp nhận các lỗi không thường xuyên trong khi trừng phạt hành vi sai trái dai dẳng. Phương pháp tương tự được sử dụng trong các hệ thống P2P trước đây [13].

Nếu nút đồng ý trước cho phép chấp nhận các khoản thanh toán cố tình trì hoãn việc giải ^quyết thì các khoản thanh toán đó sẽ không ảnh hưởng đến danh tiếng của nút chuyển tiếp khoản thanh toán.

Chú thích cuối trang 18: Điều này hữu ích cho một số giao thức L2, chẳng hạn như hoán đổi nguyên tử [55] (ví dụ: hoán đổi tàu ngầm [6]) và "hợp đồng nhật ký thận trọng" [26]. Cần nhiều nghiên cứu hơn để phân tích tính hiệu quả của các giao thức như vậy trong hoàn cảnh nhiều bước nhảy.

Phía trước

Nútđề xuất thanh toán có thể (nhưng không bắt buộc) đánh dấu thanh toán là có rủi ro thấp , nghĩa là xác nhận ^nó19 . Rủi ro thấp đối với nút hạ nguồn ( nút chấp nhận yêu cầu ) đồng ý thanh toán khi và chỉ khi họ xác minh rằng sự chứng thực đến từ một nút có uy tín cao. Các khoản thanh toán rủi ro thấp có thể được chuyển tiếp trên cơ sở nỗ lực hết sức, trong khi các khoản thanh toán rủi ro cao chỉ có thể sử dụng K khe thanh toán và hạn mức thanh khoản là L satoshi. Nói tóm lại, hạn ngạch được áp dụng cho nút hạ nguồn và danh tiếng được áp dụng cho nút thượng nguồn.

Chú thích cuối trang 19: Điều này giúp phân biệt đề xuất của chúng tôi với các kế hoạch dựa trên danh tiếng của người gửi (mà chúng tôi đã từ chối giữa chúng tôi): điểm rủi ro được gắn với khoản thanh toán, độc lập với người gửi ban đầu.

hiệu quả

Kẻ tấn công có uy tín thấp không còn có thể chặn hoàn toàn một kênh vì kênh đó sẽ để lại một số tài nguyên cho các khoản thanh toán rủi ro thấp. Để vượt qua các biện pháp đối phó như vậy, những kẻ tấn công cần phải xây dựng danh tiếng từ trước, điều này đòi hỏi nỗ lực và nguồn lực. Lưu ý rằng để đạt được điểm danh tiếng cao, nút phải chuyển tiếp các khoản thanh toán, trả A satoshi mỗi giây dưới dạng phí trong ít nhất t giây.

Một nhược điểm của sơ đồ danh tiếng mà chúng tôi đề xuất ở đây là nó có thể khiến tài nguyên kênh ở trạng thái sử dụng kém hiệu quả. Trong các khoản thanh toán lớn, một số khoản thanh toán trung thực có rủi ro cao có thể bị chấm dứt do thiếu hạn mức rủi ro cao. Một mối lo ngại khác là một cuộc tấn công chặn không hoàn chỉnh, chỉ có thể nhắm mục tiêu vào các khe thanh toán và thanh khoản hạn ngạch rủi ro cao, sẽ rẻ hơn so với một cuộc tấn công chặn hoàn toàn.

Khả năng tương thích khích lệ

Nút định tuyến nên được khích lệ xác nhận các khoản thanh toán theo hiểu biết tốt nhất của họ và hai chiến lược khởi hành khả thi là xác nhận các khoản thanh toán rủi ro cao và không xác nhận các khoản thanh toán rủi ro thấp. Việc không xác nhận các khoản thanh toán rủi ro thấp rõ ràng sẽ làm giảm lợi nhuận phí của chính nút . Điều thú vị hơn là khi xác nhận một khoản thanh toán rủi ro cao, nếu thanh toán thành công, nó có thể làm tăng lợi nhuận kỳ vọng của nút xác nhận. Rủi ro là mất danh tiếng trên nút hạ lưu của chính nó (nếu khoản thanh toán hóa ra là một. tắc nghẽn). Bằng cách thiết lập các tham số hệ thống danh tiếng hợp lý, chiến lược này có thể không mang lại lợi nhuận. Nếu việc xây dựng lại danh tiếng là tốn kém thì lợi nhuận từ phí bổ sung có thể không đủ để bù đắp cho rủi ro chứng thực sai.

trải nghiệm người dùng

Trải nghiệm người dùng không hài lòng với đề xuất này chủ yếu là ở những người dùng mới, những người có thể gặp phải xác suất thất bại cao hơn vì họ bắt đầu với danh tiếng thấp. Đối với người dùng nhàn rỗi, đây có thể không phải là vấn đề nghiêm trọng vì hạn mức rủi ro cao của nút ngang hàng của họ đủ để xử lý khối lượng thanh toán thấp của họ. Hơn nữa, các nhà cung cấp dịch vụ Lightning Network chuyên nghiệp có thể cung cấp cho khách hàng những chính sách danh tiếng thoải mái hơn.

Quyền riêng tư và bảo mật

Bất kể họ có xác nhận thanh toán hay không, nút sẽ tiết lộ thông tin về nguồn thanh toán có thể có. Để bảo vệ quyền riêng tư của người gửi ban đầu, nút có thể chọn không xác nhận một số khoản thanh toán rủi ro thấp(với chi phí mất một lượng nhỏ lợi nhuận phí).

Rủi ro bảo mật của cơ chế danh tiếng là một cuộc tấn công xếp tầng, cho phép chặn các giao dịch đi qua một đường dẫn chuyển tiếp dài, do đó làm giảm điểm danh tiếng của nút theo đường dẫn. Điều này sẽ ảnh hưởng đến hiệu suất của toàn bộ mạng vì nút sẽ chấm dứt không chính xác nhiều khoản thanh toán rủi ro thấp. Mặc dù việc hạ thấp điểm danh tiếng của nút định tuyến khiến các khoản thanh toán có nhiều khả năng thất bại hơn nhưng nó không thể chặn hoàn toàn luồng thanh toán.

Nguyên tắc tấn công xếp tầng đã được nghiên cứu trong nhiều bối cảnh khác nhau, chẳng hạn như ngành tài chính [32], Internet of Things [17] và sự phát triển của virus. Các bài viết này đã giải quyết rủi ro dựa trên kết quả lý thuyết (ví dụ [7, 11, 39]). Lấy cảm hứng từ những nghiên cứu này và các đặc tính của Lightning Network [29], chúng tôi suy đoán rằng các cuộc tấn công xếp tầng rất khó thực hiện. Cần nghiên cứu thêm về lựa chọn tham số và chiến lược tấn công.

Lưu ý của người dịch: Theo thử nghiệm mô phỏng của Carla Kirk-Cohen và những người khác vào tháng 9 năm 2024 , sau khi áp dụng giải pháp của tác giả, cuộc tấn công duy nhất có thể chặn kênh trong thời gian dài là phương pháp được gọi là "tấn công theo tầng" ở đây. Điều này có thể được giải quyết bằng cách cải thiện hệ thống danh tiếng.

Khó khăn trong việc thực hiện

Hệ thống danh tiếng được đề xuất của chúng tôi tương đối dễ thực hiện. Phát triển bổ sung bao gồm việc thêm các trường được mã hóa xác nhận vào cấu trúc dữ liệu thanh toán. Nút cũng có thể ghi lại điểm danh tiếng của nút trong cơ sở dữ liệu cục bộ.

6 Mô phỏng

(nhẹ nhàng)

7 công việc liên quan

Các cuộc thảo luận về việc ngăn chặn các cuộc tấn công đã có từ năm 2015 [1, 47]. Bản tóm tắt các giải pháp tiên tiến có thể được tìm thấy trong [16, 33, 41].

Tác động của việc ngăn chặn các cuộc tấn công cũng như những cải tiến đối với các cuộc tấn công và các biện pháp đối phó tiềm năng đã được nghiên cứu kỹ lưỡng [15, 30, 31, 35, 42, 52]. Trả trước như một biện pháp đối phó đã được thảo luận trước đây [45, 22]. Phương pháp liên quan bao gồm chứng chỉ vốn chủ sở hữu [34] và các biện pháp bảo vệ cấp nút[2, 36]. Việc tính điểm nút toàn cầu tập trung cũng là tùy chọn, nhưng hiếm khi được sử dụng trong thực tế [5].

Các cuộc tấn công như "lũ lụt và cướp bóc" [20] và "thoát hàng loạt" [50] có thể phá vỡ giao thức L2 bằng cách tạo ra tắc nghẽn ở lớp cơ sở. Các cuộc tấn công quyền riêng tư trên Lightning Network bao gồm phát hiện số dư[12, 21], tấn công thời gian [43] và nặc danh nhiều lớp [23, 44]. Tính đến hôm nay, không có chiến lược giảm nhẹ nào được áp dụng.

8 Tương lai việc làm

Hướng công việc trong tương lai bao gồm mô phỏng nhiều kịch bản tấn công hơn và chiến lược phòng ngừa dựa trên danh tiếng. Nói rộng hơn, có thể xem xét tính khả thi của các phương án thiết kế khác. Các kế hoạch xem xét thời gian giải quyết thanh toán và bảo vệ danh tiếng của người gửi về số tiền phí là những hướng đặc biệt thú vị, mặc dù những ý tưởng này còn có những khó khăn về mặt lý thuyết và thực tiễn chưa được giải quyết. Hơn nữa, chi phí và hiệu quả của việc ngăn chặn các cuộc tấn công có thể được nghiên cứu theo các mục tiêu tấn công và tiêu chí thành công khác nhau.

Các biện pháp đối phó hiệu quả có thể giảm thiểu các sự cố khác của Lightning Network. Đầu tiên, nó ngăn chặn các cuộc tấn công phát hiện [21] vì việc phát hiện tương tự như chặn ở chỗ nó yêu cầu gửi nhiều khoản thanh toán cố ý không thành công. Thứ hai, cơ chế tính phí của chúng tôi cũng có thể hữu ích trong việc khích lệ các tháp canh không đáng tin cậy [9, 24, 29] – tháp canh là dịch vụ của bên thứ ba giúp đánh bại việc đóng kênh gian lận thay mặt cho người dùng.

9 Kết luận

Trong bài viết này, chúng tôi thiết lập một khung đánh giá cho các chiến lược giảm thiểu tấn công cho các mạng tài chính phi tập trung . Ví dụ: chúng tôi xem xét việc chặn các cuộc tấn công—một bề mặt tấn công từ chối dịch vụ lâu đời trên Lightning Network, giao thức L2 thống trị trên Bitcoin. Sau khi xem xét các lựa chọn thiết kế khác nhau trong khuôn khổ đề xuất, chúng tôi đề xuất một giải pháp hiệu quả giúp giảm thiểu các cuộc tấn công bằng cách kết hợp các khoản phí vô điều kiện và điểm danh tiếng địa phương dựa trên hành vi trong quá khứ. Chúng tôi chứng minh tính khả thi của đề xuất của mình bằng cách sử dụng mô phỏng và tính toán phân tích.

Lời cảm ơn

Chúng tôi cảm ơn Sergi Delgado Segura vì tạo ra cách triển khai bằng chứng khái niệm về phí vô điều kiện. Cảm ơn Carla Kirk-Cohen, Thomas Huet, Joost Jager, Gleb Naumenko, René Pickhardt, Antoine Riard, Bastien Teinturier và cộng đồng nhà phát triển Lightning Network rộng lớn hơn đã thảo luận kỹ lưỡng.

Tham khảo

(nhẹ nhàng)