Hướng tới một nút sét đa chữ ký k-trên-n

Tác giả: ZmnSCPxj

Nguồn: https://delvingbitcoin.org/t/towards-ak-of-n-lightning-network-node/2395

giới thiệu

Gần đây, với việc công bố bài báo " Nested MuSig2 ", chúng tôi bắt đầu suy nghĩ: Liệu chúng ta có thể tạo ra một ví tự quản lý đa chữ ký tích hợp Mạng Lightning hay không?

Cụ thể, điều chúng tôi hy vọng đạt được là, trong "Kênh Taproot đơn giản" ( PR995 ), chúng ta có thể sử dụng "MuSig2 lồng nhau"tạo ra nút Mạng Lightning đa chữ ký liền mạch.

Nhưng trước tiên, hãy xem xét điều này: người dùng cuối thực sự muốn nói gì khi họ nói, "Tôi muốn một ví đa chữ ký k-of-n"?

Tôi cho rằng các nhu cầu cốt lõi của người dùng cuối như sau:

Về vấn đề "chữ ký đa chữ ký k trên n", mong muốn của tôi là nếu tôi sở hữu N thiết bị, tiền của tôi sẽ an toàn miễn là số thiết bị bị chiếm đoạt ít hơn K. Ngay cả khi tôi mất một số thiết bị không thể phục hồi, tôi vẫn có thể sử dụng tiền của mình miễn là số thiết bị bị ảnh hưởng ít hơn (N - K + 1).

Làm thế nào chúng ta có thể hiện thực hóa khát vọng này thành một "ví Lightning Network" (trong bối cảnh thực tế)?

Một ví trong blockchain có thể trực tiếp thể hiện các yêu cầu k-of-n như vậy bằng cách sử dụng các đoạn mã, điều này khá đơn giản, nhưng ví Lightning Network thì không thể. Các kênh Lightning Network có thêm những phức tạp khác. Những phức tạp bổ sung này đòi hỏi phải thay đổi giao thức BOLT của Lightning Network , không chỉ đối với bản thân các ví Lightning Network k-of-n mà còn đối với các kênh tương ứng của chúng (có thể là ví đa chữ ký k-of-n hoặc không).

Điều này có nghĩa là người dùng cuối muốn sử dụng ví Lightning đa chữ ký k-of-n phải:

• Đang chờ đợi giao thức BOLT của Lightning Network được sửa đổi để được áp dụng rộng rãi, hoặc
• Họ chấp nhận các dịch vụ từ nút cổng (những nút đã triển khai giao thức BOLT của Mạng Lightning được sửa đổi "sớm" với cái giá là sự riêng tư bị ảnh hưởng và thu nhập thấp hơn từ phí chuyển tiếp).

Một trường hợp sử dụng chính của nút Lightning Network đa chữ ký K-of-n là cho phép những người nắm giữ (HODLers) có lượng tiền lượng lớn sử dụng khoản tiết kiệm của họ để cung cấp thanh khoản cho mạng Lightning Network, đảm bảo tính an toàn và khả năng phục hồi của mạng này mọi lúc.

(Ghi chú của người dịch: "HODLer" là một thuật ngữ có ý nghĩa văn hóa quan trọng, bắt nguồn từ "holder". Thuật ngữ này sẽ được dịch là "holder" trong toàn bộ văn bản sau.)

Tuy nhiên, cho đến khi giao thức BOLT của Lightning Network được sửa đổi được áp dụng rộng rãi, nút đa chữ ký k-of-n lớn như vậy chỉ có thể kết nối với các cổng, từ đó đóng vai trò cầu nối giữa giao thức được sửa đổi và mạng lưới chưa được nâng cấp. Hiển nhiên, nút cổng này sẽ tính phí, mặc dù phương thức tính phí sẽ khác nhau. Bất kỳ nút cổng nào không tính phí sẽ nhanh chóng thấy thanh khoản khả dụng của mình bị cạn kiệt bởi những người nắm giữ lượng lớn; bản thân họ không có nhiều thanh khoản trừ khi họ cũng là những người nắm giữ lượng lớn; nhưng nếu họ là như vậy, thì (dựa trên giả định của chúng ta) họ sẽ muốn sử dụng thiết bị đa chữ ký, điều này cũng yêu cầu một cổng hỗ trợ giao thức được sửa đổi.

Do đó, để hỗ trợ kịch bản ứng dụng mà chúng ta đang đề cập, giao thức cần được sửa đổi "sớm" để thúc đẩy việc áp dụng giao thức đã sửa đổi, sao cho những người nắm giữ lượng lớn tiền điện tử có thể sử dụng khoản tiết kiệm của họ để cung cấp thanh khoản.

Các đối thủ kênh có mức độ tin cậy tối thiểu

Một số người có thể lập luận rằng "Mạng Lightning thực sự an toàn hơn vì kẻ tấn công kênh cũng phải bị xâm nhập trước khi nạn nhân có thể mất khóa của mình."

Ý kiến ​​này cũng hoàn toàn sai lầm.

Cách suy nghĩ đúng đắn là: "Đối thủ của bạn trong đường hầm đã chiếm được vị trí tốt nhất để phá hoại bạn, vì vậy bạn nên đặc biệt lo lắng về đối thủ đó."

Cụ thể, hãy tưởng tượng tình huống này: Nếu bạn là người nắm giữ một lượng lớn tiền điện tử và muốn cung cấp thanh khoản cho Mạng Lightning (để đổi lấy thu nhập giao dịch), bạn sẽ muốn bất kỳ ai mở kênh giao dịch với bạn. Việc người khác mở kênh giao dịch với bạn đồng nghĩa với việc bạn có nhiều cơ hội kiếm được phí định tuyến hơn!

Nếu bạn không cho phép người lạ trên internet thiết lập kênh liên lạc với nút định tuyến lớn của mình, và chỉ cho phép một số ít thực thể đáng tin cậy thiết lập kênh liên lạc với bạn, thì tôi cá rằng:

Vì lý do này hay lý do khác, những đối tác trung gian "đáng tin cậy" được lựa chọn cẩn thận này sẽ thu lại phí giao dịch mà bạn đã kiếm được dưới dạng tiền thuê thanh khoản; hoặc bạn có thể thấy rằng tỷ lệ sử dụng thanh khoản của mình thấp.

Sự thật là, bạn phải cho phép những người lạ trên internet, như YaiJBOjA (chỉ để bạn biết, chắc chắn không phải tôi!), mở kênh với bạn. Điều này cũng có nghĩa là bạn đang cho phép những kẻ trộm tiềm năng trở thành đối thủ của kênh bạn . Bạn đang cho phép người khác nhắm mục tiêu vào bạn.

Do đó, bạn phải giả định rằng chỉ những người ký tên tại địa phương của bạn mới đáng tin cậy, từ đó loại bỏ nhu cầu sàng lọc các đối thủ kênh phân phối. Hệ thống bảo mật của bạn phải đủ mạnh để ngăn chặn kẻ trộm ngay cả khi ai đó nhắm mục tiêu vào bạn từ phía sau, và bạn không nên dựa vào các đối thủ kênh phân phối, vì họ chính là những tên trộm giỏi nhất .

Ngay cả khi đối thủ chỉ sử dụng tiền của riêng họ để mở kênh giao dịch với bạn, họ vẫn có thể chuyển số dư của mình trong kênh đó (thông qua bạn) đến một nút khác mà họ kiểm soát, và sau đó đánh cắp tiền từ kênh đó (sau khi họ đã sử dụng hết số dư của mình, rõ ràng số tiền trong kênh là của bạn). Nếu họ có thể phá vỡ đủ các trình tạo chữ ký, hoặc khai thác các lỗ hổng trong hệ thống đa chữ ký của bạn, họ có thể đánh cắp tiền của bạn.

Do đó, "Ngã ba Morton" của bạn trông như thế này:

• Nếu bạn không ưu tiên tính bảo mật của trình tạo chữ ký điện tử, người lạ trên internet có thể đánh cắp tài sản của bạn.
• Nếu bạn không cho phép người lạ trên internet tiếp cận tài khoản của mình, thì thanh khoản của bạn sẽ không được sử dụng hiệu quả (trước hết, bạn sẽ không kiếm được tiền, và bạn sẽ chỉ gửi tiền vào ví ảo trên internet mà không mang lại lợi ích gì cho bản thân hoặc người khác).

(Ghi chú của người dịch: "Ngã ba Morton" ám chỉ một tình huống tiến thoái lưỡng nan mà dù chọn con đường nào cũng đều dẫn đến cái chết chắc chắn.)

Do đó, cần có một phương án bảo mật tốt hơn so với việc chỉ "sử dụng một người ký gốc duy nhất trong tất cả các kênh Lightning Network của tôi".

Chữ ký đa chữ ký là một khía cạnh bổ sung.

Bạn có thể nói, "Nhưng trình ký của tôi được đặt trong ' Hoàn cảnh thực thi đáng tin cậy (TEE)'; hoàn cảnh thực thi này chạy trên 'Chip bảo mật (SE)'; và Chip bảo mật này được triển khai bằng cách sử dụng 'Chức năng không thể làm giả vật lý (PUF)'!!!"

Trước hết, PUF chỉ đơn giản là một quy trình tung xúc xắc an toàn được sử dụng để tạo ra một private key được nhúng trong đó . Nếu bạn có quyền truy cập vào giao diện gỡ lỗi của SE — điều mà mọi nhà sản xuất chip đều cung cấp vì quá trình sản xuất chip không bao giờ hoàn hảo và luôn luôn có những khiếm khuyết — thì PUF không cung cấp bất kỳ sự bảo vệ nào. Giao diện gỡ lỗi tương tự, có khả năng phát hiện các khiếm khuyết, cũng có thể được sử dụng để trích xuất các kết quả trung gian từ các phép tính được chạy bằng private key được nhúng; xét cho cùng, các mạch tính toán trung gian này cũng cần được kiểm tra để xác minh rằng chúng đã được sản xuất chính xác. Trên thực tế, bạn không thể tính toán mọi thứ bằng một mạch duy nhất, vì vậy bạn cần "flip-flop" để lưu trữ các kết quả trung gian này (nếu không, bạn sẽ cần một mạch khổng lồ , do đó đắt tiền và chậm , bởi vì các kết quả trung gian được lưu trữ trong flip-flop là thứ cho phép cùng một mạch đa năng, chẳng hạn như bộ nhân hoặc bộ cộng, được sử dụng lại trong các phần khác nhau của phép tính). Các mạch lật này cũng được sử dụng như một phần của giao diện gỡ lỗi (được gọi là "Chuỗi quét", bạn có thể tự tìm hiểu) tại nhà máy sản xuất để kiểm tra lỗi trong các chip đã sản xuất.

Các flip-flop lưu trữ kết quả tính toán trung gian này không thể nằm trong PUF: bởi vì bạn muốn các flip-flop này và mạch điện được viết trong đó phải giống hệt với thiết kế của bạn, nếu không thì đó sẽ là một con chip không đáng tin cậy; và PUF là khu vực mà bạn cố tình tăng tỷ lệ lỗi để người khác không thể sao chép nó một cách thực tế!

Do đó, các phép tính trung gian này có thể được sử dụng để giảm số bit bạn phải đoán khi trích xuất private key trong đó .

Hơn nữa, cần lưu ý rằng các nhà sản xuất có quyền truy cập vào "giao diện gỡ lỗi/ Chuỗi quét của nhà sản xuất" đã đề cập ở trên, nếu không thì thuật ngữ "nhà sản xuất" sẽ không tồn tại. Bạn có thực sự tin rằng các nhà sản xuất thiếu khả năng đọc private key được nhúng trong PUF mà bạn tôn sùng đến vậy? Tốt hơn hết bạn nên sử dụng thiết bị ký Trezor không có "chip bảo mật", bởi vì private key được nhúng trong đó là khóa mà bạn thực sự có thể tạo ra bằng cách tung đồng xu hoặc gieo xúc xắc. Bạn có thể sử dụng đồng xu, xúc xắc và các phần cứng khác mà bạn thực sự có thể kiểm soát để thực hiện các thao tác mà bạn thực sự biết và hiểu.

Một “ hoàn cảnh thực thi đáng tin cậy” chỉ “chặn em gái bạn”, chứ không “chặn các chính phủ độc tài”.

(Nguồn: Tôi đã thiết kế các mạch tích hợp chuyên dụng (ASIC) điều khiển màn hình LCD (Màn hình tinh thể lỏng). Trước đó, tôi đã thực hiện phân tích ngược các ASIC; chúng tôi từng mài từng lớp kim loại (theo đúng nghĩa đen) và chụp ảnh chúng dưới kính hiển vi để hiểu mạch điện. Bạn có biết rằng các nhà sản xuất chip lớn của Đài Loan chỉ chấp nhận các mạch logic điện tử được thiết kế bằng ba phần mềm mô phỏng Verilog hàng đầu (Mentor, Synaptic, và đừng lo lắng về phần mềm thứ ba; nếu bạn thực sự muốn biết, chúng tôi từng làm việc cho Synaptic)? Nếu bạn không cung cấp kết quả mô phỏng từ một trong đó, họ thậm chí sẽ không xem xét yêu cầu sản xuất của bạn. Họ hoàn toàn không tin tưởng Icarus Verilog; nếu bạn đề cập đến tên đó, họ thậm chí sẽ không trả lời.)

Do đó, việc sở hữu phần cứng luôn tương đương với việc sở hữu private key, bất kể đó là "hoàn cảnh thực thi đáng tin cậy", "chip bảo mật" hay "chức năng không thể làm giả vật lý". Điều đó không thay đổi sự thật rằng "sở hữu sẽ thắng chín trên mười vụ kiện". Một khi phần cứng được giải phóng, private key cũng được giải phóng.

Chú thích của người dịch: "Sở hữu là 9/10 của luật" theo nghĩa đen là "sở hữu là 9/10 của luật", ám chỉ xác suất cao người đang sở hữu sẽ thắng kiện trong các tranh chấp về quyền sở hữu. Tác giả sử dụng phép ẩn dụ này để nhấn mạnh tầm quan trọng của việc "sở hữu phần cứng (máy tạo chữ ký)": vì thực tế không có cơ chế nào có thể ngăn chặn hoàn toàn kẻ thù trích xuất trong đó private key sau khi có được máy tạo chữ ký của bạn, điều quan trọng nhất là phải giữ nó an toàn ở một nơi bảo mật, ngăn không cho kẻ thù có được.

Hơn nữa, bất kể hoàn cảnh nào: ngay cả khi bạn có một thiết bị điện tử "hoàn hảo", chẳng hạn như một thiết bị ký điện tử Trezor đơn giản được lắp ráp từ các linh kiện có sẵn (những linh kiện này thực sự có ở khắp mọi nơi và sẽ không gây nghi ngờ vì chúng quá phổ biến đến nỗi không ai nghĩ đến việc thay thế Chuỗi cung ứng của bạn chỉ vì có quá nhiều Chuỗi cũ kỹ và nhàm chán này), việc sử dụng phương thức xác thực đa chữ ký vẫn tốt hơn cho bạn: bởi vì kẻ trộm sẽ cần phải đánh cắp nhiều thiết bị điện tử như vậy để lấy được tiền của bạn.

Chữ ký đa lớp bổ sung thêm một lớp bảo mật cho thiết bị của bạn, cho dù đó là thiết bị "an toàn" dựa trên "hoàn cảnh thực thi đáng tin cậy" (nơi nhà cung cấp cam kết không đánh cắp private key của bạn) hay một thiết bị thực sự hoàn toàn nằm dưới sự kiểm soát của bạn.

Như đã đề cập ở phần đầu bài viết này, đa chữ ký có nghĩa là "để làm cho tiền của tôi không an toàn, tôi phải xâm nhập vào k thiết bị" — với điều kiện là chúng ta có thể thực hiện được điều đó.

Các phương án thay thế với số lượng chữ ký ít hơn

Ngoài việc đòi hỏi những thay đổi sâu rộng đối với Mạng Lightning, còn có những cách khác để đạt được một số lợi ích của chữ ký đa chữ ký.

Ví dụ, mỗi kênh Lightning có một cặp khóa công khai riêng, một ở mỗi đầu.

Bản thân giao thức Lightning Network không quy định một phương pháp cụ thể nào để tạo ra khóa công khai cho mỗi kênh từ khóa "gốc" (hoặc từ ID nút).

Do đó, có thể chuẩn bị N người ký, và bất cứ khi nào một kênh được mở, hãy chọn một trong đó để chỉ định khóa công khai được sử dụng trong kênh đó. Vì khóa công khai bạn sử dụng trong kênh không phụ thuộc vào ID nút của bạn, bạn có thể tự do chọn bất kỳ người ký nào cho mỗi kênh.

Điều này hoàn toàn tương thích với Mạng Lightning hiện tại, không yêu cầu thay đổi giao thức và thậm chí không cần chờ PR995 được hợp nhất.

Với phương pháp này, nếu bạn có N người ký và một trong đó bị chiếm đoạt, chỉ có 1/N kênh của bạn sẽ bị ảnh hưởng. Điều này vẫn tốt hơn so với việc chỉ có một người ký (khiến tất cả các kênh đều gặp rủi ro).

Đây là một ví dụ về cách tiếp cận này: rotating-signer-provider .

Cách tiếp cận này dễ triển khai và thiết thực vì ít nhất nó giúp đa dạng hóa rủi ro. Nó tương tự như việc sử dụng nhiều nút, ngoại trừ việc cho phép bạn hình thành một nút lớn duy nhất với nhiều người ký độc lập quản lý quỹ. Nói chung, nút lớn có lợi thế về hiệu quả định tuyến và được nhiều nút trên mạng ưu tiên, do đó làm tăng lợi nhuận phí định tuyến của bạn.

Thay đổi BOLT: Khóa thu hồi

Để đạt được nút Lightning đa chữ ký k-of-n thực sự, thay đổi hoàn toàn cần thiết đối với BOLT là loại bỏ yêu cầu sử dụng shachain để tạo Key thu hồi cho mỗi giao dịch đã cam kết ở phía bên kia.

Tại sao điều này lại cần thiết?

Hãy nhớ lại cấu trúc thực tế của hợp đồng trên chuỗi liên quan đến số tiền mà bạn đã hứa sẽ kiểm soát thông qua sàn giao dịch:

• Hãy chọn một trong hai:
  • Tất cả các điều kiện đều đã được đáp ứng:
    • Thỏa thuận cam kết che giấu thông tin đã được xác minh độ sâu(thường mất đến hai tuần).
    • Chữ ký của bạn
  • Tất cả các điều kiện đều đã được đáp ứng:
    • Chữ ký của đối thủ
    • Khóa thu hồi

Phần thứ hai ở đây là điểm mấu chốt.

Giao dịch cam kết của bạn là cách duy nhất để bạn lấy lại tiền. Ví dụ, một tên trộm có thể dùng tiền của mình để mở một kênh giao dịch với bạn, chuyển số dư trong kênh đó đến một nút khác mà chúng kiểm soát, rồi đóng nút trộm cắp của chính chúng; lúc này, chúng không còn gì để mất (ngoại trừ khoản tiền bảo đảm 1%, nhưng điều đó có thể được coi là chi phí của vụ trộm). Bạn phải sử dụng giao dịch cam kết của mình ; nếu không, tiền của bạn sẽ không an toàn : chúng sẽ trở nên không thể sử dụng được.

"Thu hồi" là gì?

Nhiều thuật ngữ được sử dụng trong các kênh dẫn điện chống sét có thể gây nhầm lẫn:

• Hình phạt đề cập đến hành động trả đũa mà bạn có thể thực hiện khi đối thủ đơn phương đóng kênh bằng cách sử dụng trạng thái cũ. Điều này phụ thuộc vào việc đối thủ của bạn đã phát sóng và xác nhận giao dịch cam kết, giao dịch này sau đó đã bị thu hồi .
• Việc đóng kênh đơn phương đề cập đến việc phát đi một trạng thái và khẳng định đó là trạng thái mới nhất của kênh. Nếu trước đó bạn đã thu hồi trạng thái này (nghĩa là nó thực sự không phải là trạng thái mới nhất, và do đó khẳng định của bạn là sai), bạn có thể bị phạt .
• Việc thu hồi trạng thái có nghĩa là bạn đồng ý rằng trạng thái đó đã lỗi thời. Điều này cung cấp cho đối phương đủ thông tin để nếu bạn sử dụng trạng thái đã bị thu hồi để đơn phương đóng kênh, đối phương có thể trừng phạt bạn sau này.

Vậy những sự việc này xảy ra vào thời điểm nào ?

• Hủy bỏ :
  • Hiện tượng này xảy ra bất cứ khi nào trạng thái thay đổi, tức là bất cứ khi nào một HTLC được thêm vào hoặc loại bỏ khỏi kênh.
  • Ví dụ, trạng thái hiện tại của bạn được đánh số N. Bạn và đối thủ đều đồng ý di chuyển đến N + 1. Quá trình này được gọi là "luân phiên đổi bài":
    • Trạng thái chữ ký của đối thủ là N+1.
      • Tại thời điểm này, cả trạng thái N và trạng thái N+1 đều hợp lệ và cả hai đều có thể được sử dụng để đơn phương đóng kênh mà không phải chịu bất kỳ hình phạt nào.
      • Sử dụng phép so sánh "luân phiên hai tay", hiện tại bạn đang nắm chặt sợi dây bằng cả hai tay, một tay ở trên và một tay ở dưới, leo lên theo cách này—điều tương tự cũng áp dụng khi tiến về phía trước trong một lối đi hẹp.
    • Bạn hủy bỏ trạng thái cũ N.
      • Thao tác này sẽ khóa bạn vĩnh viễn vào trạng thái N+1, vì đó hiện là trạng thái hợp lệ duy nhất.
      • Nếu dùng phép so sánh "luân phiên hai tay", thì điều đó giống như việc thả tay dưới ra trong quá trình tháo gỡ.
  • Tại bất kỳ thời điểm nào, tối đa chỉ có thể có hai trạng thái chưa bị hủy bỏ; hầu hết thời gian, chỉ có một trạng thái chưa bị hủy bỏ.
• Khâu kín một bên :
  • Điều này xảy ra khi bạn quyết định ký một thỏa thuận cam kết—thêm chữ ký của mình vào chữ ký của đối tác, mà bạn có được trong quá trình ký kết luân phiên thông thường—và công bố nó.
  • Không có cơ chế mã hóa cứng nào để ngăn bạn sử dụng các giao dịch trạng thái cũ (và chữ ký của chúng), chỉ có một khích lệ kinh tế duy nhất: miễn là bạn sử dụng một giao dịch cam kết cũ (mà bạn đã thu hồi), bạn sẽ bị phạt: bạn sẽ mất tất cả tiền trong kênh.
• trừng phạt :
  • Khi bạn nhận thấy đối thủ đóng kênh với trạng thái cũ (chưa hoàn tất).

Vấn đề nằm ở thao tác "hủy bỏ", chứ không phải ở "việc đóng cửa đơn phương" hay "hình phạt".

Việc đảo ngược yêu cầu phải chuyển một thứ gọi là "khóa đảo ngược" cho đối thủ. Sau đó, đối thủ có thể sử dụng chữ ký của riêng họ và khóa đảo ngược này để trừng phạt trạng thái cũ vì hành vi đóng cửa đơn phương.

Bài toán về khóa thu hồi K-trong-N

Bây giờ, hãy suy nghĩ về điều này:

• Giả sử bạn có một thiết bị đa chữ ký k-trên-n.
• Làm thế nào để tạo khóa thu hồi cho mỗi giao dịch đã được xác nhận?
  • Kẻ thù của bạn cần xâm nhập bao nhiêu thiết bị để đánh cắp khóa thu hồi mới nhất?

Câu hỏi lớn đặt ra là: các khóa thu hồi được tạo ra như thế nào ?

Câu trả lời là: hãy tham khảo tài liệu đặc tả BOLT. Tài liệu đặc tả BOLT quy định rằng nên sử dụng shachian.

Vấn đề là, như tên gọi đã gợi ý, shachain sử dụng phương pháp lặp đi lặp lại để áp dụng SHA2 ("sha") ("chain").

Không thể tạo ra hàm SHA2 k-trên-n. SHA2 hoàn toàn không tuyến tính, vì vậy không thể tạo ra hàm SHA2 k-trên-n, ngay cả khi k = n.

Ngay cả khi có thể tạo ra một hàm SHA2 k-trên-n thông qua một số phép thuật mật mã bí ẩn (liên quan đến các mạch ảo mã hóa bit 0 và 1 thành "cam kết đồng hình"), việc nắm giữ kết quả trung gian của chuỗi shachain (tức là đầu ra của SHA2 trong quá trình lặp) cũng tồi tệ không kém, bởi vì chính kết quả trung gian trong quá trình lặp shachian đó mới trở thành khóa thu hồi.

Các mạch ảo như vậy được triển khai thông qua quá trình lặp, cho phép nhiều người tham gia trong mạch ảo biết được các kết quả trung gian; các sơ đồ mạch ảo này chỉ bảo vệ đầu vào gốc, chứ không bảo vệ các kết quả trung gian.

Vấn đề là các kết quả trung gian của chuỗi băm (shachain) chính là các khóa thu hồi! Mạch ảo sử dụng crypto đồng hình của các bit 0 và 1 để bảo vệ gốc của chuỗi khóa thu hồi, điều này không liên quan vì các kết quả trung gian của các lần lặp phải được tiết lộ; các kết quả này tạo thành chuỗi khóa thu hồi. Là một chuỗi, một trong đó các khóa là khóa thu hồi cho trạng thái mới nhất .

Để bảo vệ các kết quả trung gian này, bạn cần phải mở rộng toàn bộ vòng lặp shachain và triển khai nó như một mạch ảo khổng lồ. Tệ hơn nữa, mỗi khi bạn phải tính toán một kết quả trung gian từ shachain, bạn phải mở rộng một mạch ảo khác; và số lượng các phép tính như vậy, theo đặc tả BOLT, ít nhất là 2 (2 lần 1) lần và có thể lên tới 2 lần 48.

Do đó, một sơ đồ mạch ảo liên quan đến tính toán bên long có thể không khả thi.

(Cảnh báo: Tôi không phải là chuyên gia mật mã. Vui lòng tham khảo ý kiến ​​của một chuyên gia mật mã thực sự am hiểu về mật mã đồng hình và tính toán bên long quan đến vấn đề trên. Ngay cả như vậy, tôi cũng không sử dụng tính toán bên long trong Shachain vì tôi cho rằng nó sẽ không hoạt động, và kiến ​​thức chuyên môn về mật mã của tôi không đủ để tìm ra một giải pháp khả thi.)

Chúng ta cùng xem lại một lần nữa:

Về vấn đề "chữ ký đa chữ ký k trên n", mong muốn của tôi là nếu tôi sở hữu N thiết bị, tiền của tôi sẽ an toàn miễn là không có thiết bị nào trong số K bị chiếm đoạt.

Nếu giá trị gốc của chuỗi băm được tất cả người ký biết, thì nếu bất kỳ ai trong đó bị xâm phạm—thậm chí chỉ cần một người bị xâm phạm—kẻ tấn công kênh có thể trực tiếp đánh cắp toàn bộ tiền trong kênh, do đó phá vỡ kỳ vọng đã nêu ở trên.

Nếu giá trị gốc của quá trình lặp shachain không được tất cả người ký biết đến, mà được phân bổ cho k người ký, thì: thiết bị nào sẽ thực hiện các quá trình lặp shachain liên tiếp và cung cấp khóa thu hồi cho kẻ thù? Chỉ cần thiết bị nắm giữ khóa gốc (hoặc thậm chí là trạng thái trung gian) bị xâm phạm, điều đó tương đương với việc nắm giữ khóa thu hồi mới nhất, cho phép đánh cắp tiền.

Tóm lại, ý nghĩa của "k-of-n" nằm ở việc đảm bảo kẻ trộm phải xâm nhập ít nhất k thiết bị. Ngay cả khi chỉ có một thiết bị nắm giữ khóa thu hồi, dù chỉ tạm thời, việc xâm nhập thiết bị đó cũng sẽ cho phép đánh cắp thông tin. Do đó, xét về mặt đạo đức, chúng ta không thể gọi đây là "chữ ký đa lớp k-of-n" vì nó không phải là điều người dùng cuối mong đợi khi họ nghe thấy cụm từ "k-of-n".

Do đó, shachain phải được loại bỏ khỏi đặc tả BOLT.

Đề xuất sửa đổi BOLT

Tôi đề xuất thêm một cặp "bit tính năng " có tên là " no_more_shachains ", có thể là các tính năng globalfeatures hoặc tính năng localfeatures :

• Những điểm khác biệt: Tôi sẽ không thực hiện xác minh shachain trên đối thủ, nhưng tôi vẫn sẽ cung cấp cho đối thủ một khóa thu hồi shachain hợp lệ.
  • Điều này đảm bảo khả năng tương thích ngược nút vẫn mong đợi shachain truyền thống và không nâng cấp .
  • Điều này có nghĩa là tôi sẽ lưu trữ tất cả các khóa thu hồi thay vì sử dụng cấu trúc tăng tốc shachain để nén không gian lưu trữ xuống mức O(1).
  • Điều này cho phép nút không sử dụng ShaChain mở kênh liên lạc với tôi, đồng thời cho phép tôi kết nối chúng với nút yêu cầu ShaChain.
• Chẵn lẻ: Tôi sẽ không cung cấp khóa thu hồi shachian hợp lệ, cũng như sẽ không xác minh tính hợp lệ của khóa thu hồi shachian do kẻ thù cung cấp.

Bit globalfeatures này cho phép nút đa chữ ký k-of-n xác định nút khác mà chúng có thể thiết lập kênh một cách an toàn. Lưu ý rằng "tạo kết nối BOLT8 " không có nghĩa là "tạo kênh", mà là một nút k-of-n có thể thiết lập kết nối BOLT8, tải xuống đồ thị gossip , và sau đó tìm kiếm globalfeatures cho no_more_shachains .

Sau đó, một nút Lightning k-of-n có thể kích hoạt các bit chẵn, trong khi một nút cổng có thể kích hoạt các bit lẻ. Cuối cùng, chúng ta muốn tất cả nút kích hoạt ít nhất các bit lẻ và chúng ta sử dụng các bit chẵn ở giữa, ngay cả đối với nút Lightning 1-of-1.

Thiết kế trên tuân thủ triết lý "giữ lại các bit lẻ", nghĩa là nút truyền thống vẫn có thể tương tác với nút đã bật các bit lẻ nhưng không bật các bit chẵn. Nút đã bật các bit lẻ cũng có thể tương tác với nút yêu cầu các bit chẵn. Nút k-of-n yêu cầu bật các bit chẵn, nhưng có thể tương tác với nút đã bật các bit lẻ.

Xin lưu ý rằng ngay cả khi chỉ bật các bit lẻ cũng sẽ làm tăng gấp ba dung lượng lưu trữ của các kênh có lịch sử dài hơn, mặc dù việc ghép kênh cho phép bạn cắt bớt dữ liệu này.

Lý do diện tích chiếm dụng tăng gấp ba lần là:

• Với các giao dịch cam kết neo, hình thức thay đổi trạng thái duy nhất là thêm và xóa HTLC.
  • Do đó, mỗi HTLC kích hoạt lần sự thay đổi trạng thái.
• Mỗi HTLC lịch sử chứa khoảng 32 byte dữ liệu băm.
• Mỗi lần thay đổi trạng thái đều yêu cầu một khóa thu hồi bổ sung.
  • Giải pháp shachain chỉ yêu cầu một lượng không gian lưu trữ cố định, nhưng nếu chúng ta từ bỏ nó, chúng ta sẽ cần không gian lưu trữ tăng trưởng tuyến tính.
  • Mỗi khóa thu hồi có kích thước xấp xỉ 32 byte dữ liệu(ban đầu là khóa công khai, nhưng sau khi thu hồi, chúng ta có thể thay thế khóa công khai bằng private key).
• Do đó, một HTLC sẽ cần 32 byte để lưu trữ giá trị băm, 32 byte để lưu trữ khóa thu hồi cho giao dịch cam kết thêm HTLC này, và thêm 32 byte nữa để lưu trữ khóa thu hồi cho giao dịch cam kết xóa HTLC này.
  • Trước đây, khi sử dụng shachain, chúng ta chỉ cần 32 byte để lưu trữ giá trị băm này; do đó, dung lượng lưu trữ cho lịch sử kênh cuối cùng sẽ tăng lên gấp 3 lần .

Không vấn đề gì: Thông báo Nonce của MuSig2

MuSig2 là một phác đồ gồm hai vòng:

• Trong vòng đầu tiên, khoản đầu tư vào R đã được hoán đổi.
• Sau đó, trao đổi s phân mảnh.

Cụ thể, trong kênh Taproot, quá trình "trao đổi chữ ký phân mảnh s " thực chất chỉ là một bên gửi chữ ký phân mảnh s cho bên kia; bên kia lưu trữ chữ ký phân mảnh s này trên ổ cứng của mình. Nếu bên kia quyết định đơn phương đóng kênh bằng trạng thái này, nó sẽ tạo ra s của riêng mình, cộng hai chữ ký lại với nhau để tạo ra chữ ký cuối cùng R, s , và sau đó phát tán chữ ký và giao dịch lên blockchain.

Giao thức Nested MuSig2 cũng về cơ bản là cùng một giao thức hai vòng, trong đó các bên ký lồng nhau hoàn thành từng vòng nội bộ, tổng hợp và kết hợp kết quả của họ, sau đó thực hiện trao đổi thông tin ở cấp độ cao hơn.

Vì có hai vòng, PR995 quy định khi nào sử dụng trao s hiện tại để gửi đầu vào nonce cho R trong phiên ký tiếp theo . Điều này làm giảm số lượng vòng truyền thông, điều quan trọng đối với các đồng nghiệp của chúng tôi ở Úc, xét đến độ trễ trong đó.

MuSig2 của K-of-N?

Mặc dù MuSig2 (và "MuSig2 lồng nhau") được thiết kế như các giao thức chữ ký n-trên-n, tôi muốn chỉ ra rằng giao thức FROST "k-trên-n" thực chất là một lược đồ phân vùng bí mật Shamir có thể kiểm chứng, sử dụng nhiều phần của giao thức chữ ký MuSig2 trong quá trình ký thực tế. Nghĩa là, thay vì sử dụng hàm kết hợp khóa MuSig/MuSig2 (không giống như giao thức chữ ký MuSig2), FROST sử dụng lược đồ tính toán bên long riêng của nó để tạo ra một tập hợp các "mảnh" mà bạn phải lưu trữ, mỗi mảnh tương ứng với một trong những người đồng ký của bạn, cộng với mảnh khóa của riêng bạn và một khóa công khai chung.

Khi ký điện tử, FROST về cơ bản sử dụng một cái gì đó rất giống với MuSig2 (và do đó, từ nhìn lên cơ chế, việc kết hợp FROST và "MuSig2 lồng nhau" là khả thi; tuy nhiên, không thể đảm bảo rằng bằng chứng bảo mật của "MuSig2 lồng nhau" có thể được mở rộng sang FROST-trong-MuSig2!).

Khi ký, bạn cần tìm những người ký trực tuyến (tạo ra k người ký chung), sau đó tất cả những người ký trực tuyến sẽ tạo ra vòng đầu tiên của dữ liệu đầu vào cho R theo lược đồ chữ ký MuSig2, trao đổi với nhau, và sau đó tạo ra vòng thứ hai của các chữ ký phân mảnh s .

Vấn đề là, trong đề xuất PR995, lần chúng ta gửi vòng chữ s phân mảnh thứ hai cho phiên ký lần , chúng ta cũng cần gửi một đầu vào cho R để chuẩn bị cho phiên ký tiếp theo .

Ví dụ, giả sử:

• Chúng tôi có ba người ký tên là Alice, Bob và Carol, tạo thành một nút Lightning 2/3.
• Trong phiên ký kết hiện tại, Alice và Bob đang trực tuyến. Họ tạo ra các dữ liệu đầu vào cho R , xử lý chúng, và sau đó gửi kết quả tổng hợp cho kẻ thù.
• Tuy nhiên, trước buổi ký tặng tiếp theo , Alice đã chết vì một viên đạn lạc trong cuộc nổi dậy của robot cuối cùng cũng nổ ra.
• Bob đánh thức Carol dậy.
• Carol không biết giá trị nonce bí mật mà Alice sử dụng, và do đó không thể sử dụng giá trị nonce kết hợp của Alice và Bob để ký.

May mắn thay, mặc dù đề xuất PR995 quy định rằng bên đối tác nên ghi nhớ giá trị nonce đã nhập cho đến khi chữ ký tiếp theo biến mất, nhưng giá trị nonce này sẽ bị loại bỏ nếu kết nối BOLT8 bị mất. Khi kết nối lại, một giá trị nonce mới có thể được gửi bằng cách gửi thông báo channel_reestablish .

Do đó, trong kịch bản trên, Bob và Carol có thể phớt lờ cuộc nổi dậy của robot và tiếp tục ký kết: kết nối trực tiếp với phía đối lập và sau đó buộc phải sử dụng một mã số tạm thời Bob+Carol mới, đã được kết hợp sẵn.

Do đó, các vòng nhập nonce không phải là vấn đề đối với các chữ ký đa chữ ký k-trên-n của chúng tôi.