Tác giả: AdamISZ
Nguồn: https://reyify.com/blog/lightning-unchained/
Bài báo gốc được xuất bản vào tháng 2 năm 2025.
Có một vấn đề với Mạng Lightning mà hầu hết các kỹ sư đều biết, nhưng người dùng và các nhà phát triển ví có lẽ chưa từng xem xét đến (có thể họ đã xem xét rồi, và tôi hy vọng mình sai!): Người dùng Mạng Lightning bị buộc phải công khai các UTXO mà họ sử dụng để mở kênh. Hãy tưởng tượng quyền riêng tư của bạn sẽ tốt hơn biết bao nếu bạn không phải làm điều đó.
Những điểm yếu trên Chuỗi của Mạng Lightning
Để giải thích điều này rõ ràng hơn, tôi cần phải nói thêm một chút về một khía cạnh quan trọng trong cách hoạt động của Mạng Lightning. Chúng ta hãy bắt đầu với một thứ gọi là short-channel-id .
" Mã định danh kênh ngắn " là một chuỗi 8 byte mã hóa một UTXO. Trong giao thức Bitcoin, một UTXO có thể được biểu diễn bằng một bộ (outpoint, index) , trong đó"outpoint" là mã định danh (txid) của giao dịch đã tạo ra UTXO, và "index" là vị trí của UTXO trong đầu ra của giao dịch đó. Mặc dù phương pháp này tránh được sự mơ hồ, nhưng nó sử dụng 36 byte (32 + 4; mặc dù việc sử dụng 4 byte để biểu diễn một index có phần hơi dư thừa, nhưng đó là thông lệ đã được thiết lập). Chúng ta sẽ thấy sau này rằng các nhà thiết kế của giao thức Mạng Lightning đã tạo ra một phương pháp mã hóa hiệu quả hơn (chỉ sử dụng 8 byte, chứ không phải 36 byte). Nếu bạn đang thắc mắc tại sao chỉ cần 8 byte, hãy xem xét những gì bạn chỉ cần chỉ định để xác định một UTXO: số khối (từ trong đó nó được tạo ra), số giao dịch (vì một khối chứa một danh sách các giao dịch được sắp xếp ), và cuối cùng, một trong các đầu ra của giao dịch. Mỗi trong ba số nguyên này đều có giá trị tối đa, vì vậy bạn có thể sử dụng mã hóa phù hợp cho từng số nguyên (lần lượt sử dụng 3, 3 và 2 byte).
Mục đích của việc này là gì? Hãy nhớ lại. "Mạng Lightning", như tôi thường nói, có hai phần. Phần đầu tiên là "kênh Lightning", nghĩa là kênh thanh toán kiểu Poon-Dryja giữa hai bên; phần thứ hai là "mạng lưới", nghĩa là các Hợp đồng Khóa Thời gian Băm (HTLC) được thực thi trên nhiều kênh liên kết (kênh tiền tệ). Phần thứ hai này—"mạng lưới"—rất quan trọng. Để xây dựng các kênh, bạn cần biết các kênh này tồn tại (và thậm chí khó hơn nữa, bạn phải biết hoặc đoán được số dư hiện có trong các kênh này, theo hướng bạn cần!). Để làm được điều này , bạn phải nhờ ai đó cho bạn biết chúng tồn tại. Đó là lý do tại sao chúng ta có " giao thức lan truyền thông tin của Mạng Lightning ", nơi phần lớn các thông điệp này cho nút ngang hàng biết: các kênh nhất định tồn tại.
Vấn đề ở đây là: trong hoàn cảnh thiếu tin tưởng lẫn nhau, mọi người có thể nói dối – tôi hoàn toàn có thể bịa đặt. Tôi đã tìm thấy 10.000 kênh, mỗi kênh có dung lượng 1 BTC, đây là danh sách đầy đủ, hãy tự tìm đi… Điều này có thể dễ dàng làm lãng phí thời gian của bạn và khiến CPU phải làm việc vô ích; và cuối cùng, bạn có thể nhận được một bản đồ kênh hoàn toàn vô dụng, nơi mỗi khi bạn cố gắng chuyển tiền trong "mạng lưới" theo bản đồ này, nó luôn thất bại.
Do đó, chúng tôi đã sử dụng ID kênh rút gọn; như đã đề cập trước đó, đây là cách biểu diễn cô đọng của UTXO. Việc tạo UTXO không phải là miễn phí. Mặc dù việc tạo một UTXO rất rẻ (khi phí giao dịch trong blockchain cực kỳ thấp, chỉ tốn từ 1 đến 2 satoshi/vB để gửi một giao dịch và tạo một UTXO, tương đương khoảng 10 đến 30 xu theo tỷ giá hiện tại), nhưng chi phí tăng trưởng tuyến tính với số lượng được tạo ra; hơn nữa, nếu bạn muốn tạo 100.000 UTXO một cách nhanh chóng , chi phí thậm chí có thể là vô hạn.
Tôi cho rằng đây là một điểm hiếm khi được thảo luận nhưng rất quan trọng: Tốc độ băm cực cao của Bitcoin tự nhiên làm chậm tốc độ tạo UTXO (số lượng đầu ra UTXO có thể được tạo mỗi giây), khiến chi phí tạo UTXO không chỉ phi tuyến tính mà còn gần như bị giới hạn bởi điểm kỳ dị – đây chính xác là loại bảo vệ chống tấn công từ chối dịch vụ (DoS) mạnh mẽ mà bạn cần khi xây dựng các dịch vụ công cộng.
Giờ chúng ta có thể trả lời câu hỏi: Các UTXO cần được mã hóa một cách nhỏ gọn vì các mã hóa này cần được phát sóng. Nếu có 10.000 hoặc thậm chí 100.000 kênh, sẽ có một lượng dữ liệu UTXO khổng lồ cần được truyền tải, và nếu mỗi UTXO yêu cầu 36 byte, tình hình sẽ tồi tệ hơn nhiều so với hiện tại (sử dụng ID kênh ngắn).
Chi tiết vấn đề
Vấn đề có thể được tóm gọn trong một từ: quyền riêng tư. Việc công khai số lượng UTXO bạn đang nắm giữ cho toàn bộ mạng lưới tương đương với việc công khai cho cả thế giới—đặc biệt là khi bạn gửi thông báo thông qua địa chỉ mạng IPv4/6 công khai, dạng văn bản thuần (nhiều nút"nghiêm túc" cũng làm điều này); về cơ bản, điều này giống như đang mời gọi gián điệp phân tích hoạt động của bạn trong blockchain. Điều này có thể không phải là rủi ro kinh doanh, nhưng chắc chắn là rủi ro bảo mật. Thông tin này có thể được đối chiếu với các thông tin khác, chẳng hạn như kết nối với địa chỉ IP của bạn, từ đó bắt đầu tìm ra bạn là ai, bạn sống ở đâu, bạn nắm giữ bao nhiêu Bitcoin, v.v.
Về cơ bản, đây chỉ là một biểu hiện khác của xung đột điển hình trong các mạng P2P. Vậy "xung đột điển hình" là gì? Rất đơn giản:
Trong các mạng ngang hàng mở, việc bảo vệ tài nguyên đòi hỏi phải chống lại các cuộc tấn công Sybil, điều này mâu thuẫn với mong muốn nặc danh của người dùng.
(Ghi chú của người dịch: "Tấn công Sybil" ám chỉ việc kẻ tấn công có thể dễ dàng ngụy tạo nhiều danh tính để làm cạn kiệt nguồn lực của nạn nhân; bản dịch cũ theo nghĩa đen là "cuộc tấn công Phù thủy".)
Theo quan điểm của tôi, nếu có một "giải pháp điển hình" cho loại "xung đột điển hình" này, thì đó là yêu cầu người dùng sử dụng một nguồn tài nguyên khan hiếm để tham gia vào các mạng ngang hàng. (Một "giải pháp" khác là bắt buộc người dùng không nặc danh, nhưng đây là một phương pháp dễ đổ vỡ và cuối cùng sẽ thất bại. — Đây là quan điểm cá nhân của tôi, nhưng chính vì nó hoàn toàn mang quan điểm, nên bạn cứ thoải mái chia sẻ.)
Xung đột và cách giải quyết này cũng diễn ra trong sự cố ngừng hoạt động dịch vụ mạng Tor gần đây — các bản sao đã tiêu thụ lượng lớn tài nguyên, và phương pháp là Bằng chứng công việc). Liệu Bằng chứng công việc dựa trên các vòng lặp tính toán có thực sự giải quyết được vấn đề này hay không là điều tôi sẽ thảo luận vào một dịp khác, vì tôi muốn quay lại vấn đề tin đồn trên Mạng Lightning!
Được rồi, ID kênh rút gọn sẽ trực tiếp tiết lộ UTXO. Chúng ta đều biết điều này là không tốt. Vậy chúng ta có thể làm gì? Ít nhất chúng ta có thể thử cách này:
Tôi có một kênh. Tôi sẵn sàng chứng minh rằng giá trị của UTXO mà tôi sử dụng để mở kênh là X Satoshi (hoặc ít nhất là X Satoshi), nhưng tôi không có ý định tiết lộ kênh nào có số Satoshi đó là của tôi.
Trước hết, ý tưởng này rất hấp dẫn, nhưng nghe có vẻ hơi điên rồ — nếu bạn không phải là người hâm mộ Chứng minh Không Kiến thức (Bằng chứng không tri thức- ZKP). Trước khi đi sâu vào ZKP, hãy cùng giải một bài toán logic khá thông minh:
Liệu việc một UTXO có thực sự được sử dụng để mở kênh hay không có phải là thông tin công khai? Trong kịch bản hiện tại, khi đầu ra của P2WSH được sử dụng để mở kênh, về mặt kỹ thuật, thông tin này sẽ không được tiết lộ ngay cả khi đóng kênh, bất chấp những dấu hiệu rõ ràng (các kỹ sư của Lightning Network, xin vui lòng chỉnh sửa nếu tôi sai). Đối với các kênh taproot, ít nhất với sự phát triển của MuSig2, chúng ta có thể kỳ vọng hoặc dự đoán rằng các kênh sẽ không bao giờ tiết lộ rằng chúng là đa chữ ký 2-2, chứ đừng nói đến việc chúng là một kênh. Xin nhắc lại, cuộc thảo luận này là về việc áp đặt chi phí để ngăn chặn các cuộc tấn công DoS, vì vậy tôi khẳng định rằng việc cố gắng chứng minh "đây là một kênh" là một sự đánh lạc hướng. Chứng minh quyền sở hữu UTXO là đủ.
(Không đồng ý? Không sao, hãy cùng suy nghĩ kỹ hơn. Tôi khẳng định sự tồn tại của một kênh và công bố nó (hoặc lan truyền thông tin về nó). Để chứng minh điều này, tôi cung cấp một ID kênh ngắn; ID kênh ngắn này trỏ đến một UTXO thực sự trong blockchain, nhưng làm sao bạn biết UTXO này thực sự trỏ đến một kênh? Nếu tôi nói dối, tôi chỉ cần làm cho UTXO này "trông giống như một kênh". Như chúng ta đã đề cập trước đó, trong một số trường hợp, tất cả các UTXO đều có thể trông giống như các kênh (sử dụng đầu ra taproot, việc áp dụng rộng rãi MuSig2). Thậm chí, với tư cách là một kẻ tấn công, tôi thực sự có thể tạo ra một kênh thực và sau đó làm cho nó hoàn toàn không hoạt động được mà không vi phạm các yêu cầu của giao thức. Ý nghĩa cuối cùng của việc sử dụng ID kênh ngắn trong một tin nhắn lan truyền để "chứng minh một kênh" chỉ đơn giản là "chứng minh rằng tôi đã tạo ra một UTXO.")
Nhưng chúng ta có thể thảo luận chi tiết hơn về điều này. Bạn muốn ai chịu chi phí, và bạn muốn hành vi nào phải chịu chi phí đó? Trong bài viết cũ này , Rusty Russell đề xuất áp đặt chi phí ở cấp độ nút, thay vì cấp độ kênh. Bất kể những khó khăn kỹ thuật trong đó(mà tôi có thể nói là tôi hầu như không biết gì về chúng), lý do chính khiến tôi đồng ý với quan điểm này là việc tách rời chi phí khỏi các tài nguyên mang lại lợi ích cho bạn có thể cải thiện hơn nữa tính riêng tư thực tế của mỗi kênh (ví dụ: giả sử bạn tạo một kênh có dung lượng rất lớn và sau đó ngay lập tức công bố bằng chứng không tiết lộ thông tin để chứng minh sự tồn tại của nó, có nghĩa là "Tôi chứng minh tôi sở hữu một kênh có dung lượng ít nhất 2 BTC", nhưng ngay sau đó một UTXO trị giá 2,2 BTC xuất hiện trên Chuỗi; đây chỉ là một ví dụ, và bạn nên hiểu ý tôi).
Nhưng câu chuyện chưa kết thúc ở đó: "Đây có phải là kênh UTXO hay không?" Bạn có thể tìm hiểu thêm trong phần bình luận của bài viết này.
Được rồi, tôi thừa nhận nó hữu ích, nhưng liệu điều đó có khả thi không? Với một thứ như ZKP thì sao?
Vậy, điều đó có thực sự khả thi không? Tóm lại, điều chúng ta cần chứng minh là:
Trong số các UTXO hiện có với tên gọi nằm trong một phạm vi nhất định, có một UTXO là của tôi; chúng ta có thể giả định đó là kênh gốc, nhưng điều đó không giới hạn "loại kênh" (lý tưởng nhất là bạn thậm chí không biết loại kênh đó là gì); tuy nhiên, tôi sẽ không nói chính xác đó là kênh nào.
Tuy nhiên, trong một phạm vi hợp lý, có thể có hàng trăm nghìn đến hàng chục triệu UTXO. Điều này liệu có khả thi? Rõ ràng, mọi chuyện không đơn giản như vậy.
Tôi đã nghiên cứu vấn đề này trong ba năm, đi đi lại lại nhiều lần (mặc dù, để làm rõ, tôi không chỉ tập trung vào Mạng Lightning; tôi đang tập trung vào các giải pháp chống giả mạo bảo vệ quyền riêng tư nói chung). Ban đầu, tôi tập trung vào "chữ ký vòng", nhận ra rằng các cấu trúc như vậy tồn tại, nhưng dung lượng (bằng chứng) có thể là O(log N) (tính bằng byte). Vấn đề là cả thời gian xác minh và tính toán bằng chứng đều là O(N). Bulletproofs cũng gặp vấn đề này. Vấn đề duy nhất là Merkle trees—một hiểu biết mà Andrew Poelstra đã cho tôi—trong đó thời gian xác minh bằng chứng Merkle là O(log N); cùng thời điểm đó (năm 2022), " cây đường cong" xuất hiện, kết hợp cả hai: bạn có thể sử dụng bulletproofs để tạo ra bằng chứng nhỏ gọn và sau đó sử dụng phiên bản đại số của Merkle trees(sử dụng vòng lặp đường cong secp-secq rất đặc biệt) để đạt được khả năng mở rộng logarit cho việc xác minh. Kết quả thực tế là với một tập hợp 1 triệu UTXO, bạn có thể xác minh bằng chứng trong vòng 50 đến 100 mili giây (điều này có thể thực hiện được với mã của tôi , và thậm chí còn tốt hơn nữa!), và tạo bằng chứng trong vòng 1 đến 2 giây, với kích thước từ 2 đến 3 kB. Một lần nữa, bằng chứng này chứng minh " Tôi đang nắm giữ trong đó 1 triệu UTXO này, nhưng tôi sẽ không nói cho bạn biết chính xác đó là UTXO nào ." Để có một phiên bản đầy đủ hơn về ý tưởng tương tự, hãy xem dự án FCMP++ , mặc dù đó là trên blockchain Monero .
Gần đây, JT Halseth đã phát hành output-zero , một cách tiếp cận hoàn toàn khác để giải quyết cùng một vấn đề. Nó sử dụng một ZKP khác, cụ thể là zkSTARKs, thay vì Bulletproofs (xem risc0 để biết chi tiết triển khai), và sau đó sử dụng trình bao bọc Groth16 để tạo ra các bằng chứng nhỏ gọn.
Nếu bạn quan tâm, tôi rất khuyến khích bạn tham gia thảo luận về các dự án/ý tưởng của anh ấy trên diễn đàn Delving Bitcoin .
我目前的总结如下（不确定是否准确）：output-zero 的主要优势在于，它产生的证据的大小是O(1) 级别（也即是恒定的）（得益于Groth16），我记得大概是260 字节。这显然比我的phương pháp（证据体积在3kB 左右）要好得多。但另一方面，从我自己测试它的结果（在此处）以及作者提供的概述来看，我并不相信它的证据生成时间是可以接受的。作者的论证是这样的：路由nút的设备通常配置很高，而且，更重要的是，证明并不是一个实时的操作，所以哪怕花上几分钟也无妨（似乎如果有GPU 加速的话，那会快得多，但也许是我太老派了，我不觉得这种优势应该考虑在内（为什么呢？））；至于验证，两种ZKP 都要花上50 到200 毫秒。我怀疑在实践中，超过10 秒的证据生成时间，就已经有点“落伍” 了。也许我是错的。
Cuối cùng, tôi muốn nói rằng điều tôi cho rằng thuyết phục nhất ở đây là những ý kiến khác nhau về việc liệu các bằng chứng không tiết lộ thông tin (zero-knowledge proofs - ZKP) này có nên được gắn với các UTXO kênh cụ thể hay không. Nếu bạn đã đọc cuộc thảo luận trên diễn đàn Delving Bitcoin ở trên, bạn sẽ thấy rằng tôi cũng đang phân vân về điểm này. Tôi cho rằng rằng việc tránh sử dụng UTXO kênh sẽ tốt hơn nhiều cho quyền riêng tư; tuy nhiên, từ một góc nhìn khác, tại sao bạn lại muốn sử dụng một UTXO không phải là kênh (bạn đã bơm thanh khoản vào kênh rồi, tại sao không sử dụng nó)? Hơn nữa, nếu bạn muốn sử dụng UTXO kênh trong ZKP, thì bạn nên/phải ủng hộ ý tưởng rằng bằng chứng được tạo ra từ UTXO MuSig2. Điều này không chỉ cần được xem xét trong thiết kế của ZKP (rõ ràng, nó phức tạp hơn nếu UTXO không có chủ sở hữu duy nhất), mà còn đặt ra câu hỏi: ai có thể/nên sử dụng ZKP này như một chứng chỉ tài nguyên? Về việc ZKP sẽ bị ảnh hưởng như thế nào trong trường hợp này, hãy xem xét, ví dụ, thiết kế hiện tại của đầu ra số không, sử dụng...
hash(bitcoin-pubkey-1||bitcoin-pubkey-2)Với vai trò là "bản sao khóa" (một thứ được sử dụng để ngăn bạn sử dụng lại cùng một UTXO nhiều lần, khá khác so với thiết kế thông thường: "bản sao khóa là một hàm băm không thể đảo ngược của private key"), tôi biết điều này quá phức tạp đối với hầu hết người đọc, nhưng nó chỉ nhằm mục đích minh họa sự không chắc chắn trong đó.
(qua)
