Tác giả: Anony
Trong bài viết thứ hai của sê-ri này, chúng tôi đã chỉ ra rằng phương pháp xây dựng và hiệu ứng cuối cùng của kênh sét có thể được cải thiện bằng cách cải thiện giao thức Bitcoin . Tuy nhiên, trên thực tế, trong một lĩnh vực ít được chú ý nhưng lại liên quan chặt chẽ đến việc xây dựng kênh, các kênh sét liên tục được tối ưu hóa mà không nâng cấp các quy tắc đồng thuận của giao thức Bitcoin , tức là thanh toán phí giao dịch.
Trong kênh sét, trạng thái kênh được thể hiện bằng các giao dịch cam kết và mỗi giao dịch cam kết có thể được gửi đến Chuỗi, do đó phải xem xét phí giao dịch cho các giao dịch này. Đổi lại, phương pháp thanh toán phí sẽ ảnh hưởng đến số dư khả dụng trong kênh và khả năng xử lý giao dịch theo lô, từ đó ảnh hưởng đến trải nghiệm của người dùng.
Trong bài viết này, chúng ta sẽ xem xét cách thiết kế thanh toán phí của Lightning Channels được tối ưu hóa dần dần như thế nào và những tối ưu hóa này đã cải thiện trải nghiệm của người dùng ra sao. Người đọc trước tiên cần hiểu nguyên lý hoạt động và yêu cầu bảo mật của Lightning Network.
Trước khi bắt đầu, hãy nghĩ về một câu hỏi "đơn giản": một kênh do hai bên cùng sở hữu và cả hai bên đều có thể nắm giữ số dư trong trong đó . Vậy, khi giao dịch cần được gửi đến Chuỗi, ai sẽ phải trả phí xử lý? Điều này được thực hiện như thế nào trong giao dịch Bitcoin ?
Được rồi, chúng ta hãy bắt đầu với phương pháp thanh toán phí giao dịch Bitcoin .
Thanh toán và cộng thêm phí xử lý
Khi một giao dịch Bitcoin được một khối xác nhận, sự khác biệt giữa tổng số tiền đầu vào và tổng số tiền đầu ra có thể được thu thập thợ đào đào khối đó. Sự chênh lệch này được gọi là "phí xử lý" và là khích lệ chính để thợ đào đưa giao dịch vào khối.
Khi thực hiện giao dịch, người dùng chọn đầu vào và đầu ra cho giao dịch, điều này cũng quyết định quy mô của phí giao dịch. Tuy nhiên, thị trường phí có thể thay đổi đáng kể và mức phí do người dùng lựa chọn sau đó có thể không đủ để giao dịch được xác nhận trong thời gian người dùng mong muốn. Do đó, chúng ta cần cân nhắc đến việc "thêm" phí. Điều này là cần thiết để cải thiện trải nghiệm của người dùng.
RBF
Một trong đó phương pháp được gọi là "Thay thế bằng phí", dựa trên nguyên tắc sử dụng một phần hoặc toàn bộ dữ liệu đầu vào của giao dịch gốc để khởi tạo một giao dịch mới và để giao dịch mới (giao dịch thay thế) có mức phí cao hơn giao dịch gốc, do đó thu hút thợ đào đóng gói giao dịch thay thế. Như thể hiện trong hình bên dưới (lưu ý số lượng):
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} U1 --> T1[Tx #1] T1 -.-> P1(Payment #1, 300 sats) T1 -.-> C1(Change #1, 100 sats) T1 -.-> F1{{Fee #1, 100 sats}}Bạn cũng có thể cho rằng Tx #1 như là cố gắng chi tiêu gấp đôi UTXO #0 và hai giao dịch đang “đua nhau”. Nhưng vì Tx #1 cung cấp mức phí cao hơn nên rõ ràng thợ đào sẽ thích giao dịch này hơn. Điều này có tác dụng như chúng ta gọi là "thêm phí giao dịch" và thu hút thợ đào đóng gói giao dịch trước.
CPFP
Một phương pháp khác là sử dụng đầu ra của giao dịch gốc để khởi tạo một giao dịch mới và để giao dịch mới có mức phí cao hơn, do đó, nếu thợ đào muốn đóng gói giao dịch mới, họ phải đóng gói giao dịch gốc (nói cách khác, giao dịch cũ và giao dịch mới sẽ được coi là một tổng thể - một "gói giao dịch" - để cạnh tranh với các giao dịch khác trong nhóm giao dịch); điều này được gọi là "Con trả thay cho cha (CPFP)". Như thể hiện trong hình sau:
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} C0 --> T1[Tx #1] T1 -.-> C1(Change #1, 50 sats) T1 -.-> F1{{Fee #1, 100 sats}}So với RBF, CPFP có một nhược điểm: các giao dịch mới cần phải chiếm thêm không gian khối (có nghĩa là một phần phí giao dịch do sàn giao dịch mới mang lại sẽ được sử dụng để xác nhận chính nó, thay vì cộng vào giao dịch ban đầu), trong khi RBF về cơ bản không yêu cầu điều này. Điều này có nghĩa là trong những trường hợp có thể sử dụng cả hai phương pháp, RBF hiệu quả và tiết kiệm hơn.
Với những khái niệm cơ bản này, chúng ta hãy cùng xem xét thiết kế của kênh sét.
Kênh cũ
graph LR Channel(The Chennel, 2-of-2 Multi-sig) --> TC1[Commit #1] TC1 -.-> TR(To Remote) TC1 -.-> TC(To Local) TC1 -.-> OH(An Offered HTLC) TC1 -.-> RH(A Received HTLC) OH --> HT[HTLC-Timeout tx] RH --> HS[HTLC-Success tx]Hình trên hiển thị các giao dịch liên quan đến trạng thái kênh cho một bên tham gia kênh: HTLC được cung cấp và HTLC đã nhận lần lượt đại diện cho HTLC do bên tham gia này cung cấp cho bên kia và HTLC nhận được từ bên kia. Để áp dụng nhất quán các quy tắc bảo mật kênh sét dựa trên hình phạt (LN-Penalty), cả hai loại đầu ra đều phải là giao dịch được ký trước (và một nhánh hình phạt được đặt trong đầu ra của giao dịch, không được vẽ trong hình trên) [2] . Cả hai loại giao dịch được nêu trong hình trên (giao dịch cam kết và giao dịch liên quan đến HTLC) đều phải xem xét vấn đề thanh toán và cộng phí.
Đặc tả ban đầu của Lightning Network đã thiết kế như sau để thanh toán phí: (1) Người khởi tạo kênh luôn trả phí cho giao dịch cam kết (điều này gắn chặt với thiết kế “ tài trợ một chiều ” được đề cập trong bài viết thứ năm của sê-ri này); (2) Trong giao dịch HTLC, bên thụ hưởng giao dịch phải trả phí. Ngoài ra, mặc dù bản chất đặc biệt của các giao dịch cam kết khiến RBF hầu như không sử dụng được (hãy tưởng tượng một kịch bản đóng bắt buộc khi một bên muốn đưa một giao dịch cam kết vào Chuỗi, nhưng bên kia không hợp tác và họ không thể tạo một giao dịch mới để thay thế giao dịch cam kết đã ký trước đó), các giao dịch cam kết không được thiết kế để tạo điều kiện thuận lợi cho việc sử dụng CPFP - mặc dù đầu ra To Local được cung cấp cho chính người phát sóng giao dịch, đầu ra này có khóa thời gian và không thể sử dụng ngay lập tức, do đó không thể sử dụng ngay để khởi tạo các giao dịch phụ; Bản thân giao dịch HTLC cũng yêu cầu chữ ký của bên kia và đầu ra của nó cũng có nhánh khóa thời gian.
Thiết kế này ảnh hưởng đến trải nghiệm của người dùng ở những khía cạnh sau:
- Việc luôn yêu cầu một bên trả phí xử lý là không công bằng;
- Các giao dịch cam kết không thể sử dụng RBF và không được thiết kế cho CPFP, do đó phải đảm bảo chúng có mức phí đủ cao để được xác nhận trong giai đoạn xây dựng. Tuy nhiên, vì thời điểm các giao dịch cam kết được đưa vào Chuỗi trong tương lai vẫn chưa chắc chắn nên đây trở thành một vấn đề gần như không thể giải quyết được. Giải pháp thực tế duy nhất là ước tính mức phí một cách rất thận trọng [3] . Tuy nhiên, các khoản phí này sẽ chiếm một phần quỹ của kênh, làm giảm tính hữu ích của kênh.
- Ngoài ra, thị trường phí cũng sẽ có biến động, sự biến động về phí ước tính cũng sẽ gây ra biến động về số dư khả dụng của những người tham gia kênh, điều này sẽ gây nhầm lẫn cho người dùng; hơn nữa, trong thời gian phí Chuỗi cao (cũng là thời gian mọi người muốn sử dụng Lightning Network nhất để tiết kiệm phí), điều này sẽ làm giảm đáng kể dung lượng kênh khả dụng và làm suy yếu tiện ích của Lightning Network [4] .
Vậy làm sao để tối ưu hóa nó?
Kênh neo
Ý tưởng của "Kênh neo" là sắp xếp một đầu ra có giá trị thấp nhưng có sẵn ngay lập tức cho mỗi bên trong Giao dịch cam kết (đồng thời thêm khóa thời gian tương đối lên đến 1 khối cho tất cả các đầu ra khác) để cho phép mỗi bên sử dụng đầu ra neo để khởi tạo CPFP sau khi phát Giao dịch cam kết. Tất nhiên, vì giá trị đầu ra của neo có giá trị thấp hơn nên người dùng phải bơm thêm tiền vào giao dịch phụ để có thể thêm phí giao dịch thành công.
Ngoài ra, các kênh neo áp dụng một thủ thuật táo bạo cho các giao dịch HTLC: khi một bên ký giao dịch HTLC của bên kia, bên đó sử dụng thẻ bắt đầu bằng dấu thăng “SIGHASH_SINGLE | ANYONECANPAY” [5] ; thẻ này làm cho chữ ký chỉ bao gồm một cặp đầu vào (tức là HTLC mục tiêu) và đầu ra, và cho phép kết hợp cặp đầu vào và đầu ra này thành các giao dịch hợp lệ khác. Tính năng này cho phép người dùng kết hợp nhiều giao dịch HTLC đã ký trước thành một. Hơn nữa, thông số kỹ thuật của Lightning Network cũng quy định cụ thể rằng giao dịch HTLC của kênh neo không phải chịu bất kỳ khoản phí xử lý nào; nghĩa là người dùng phải kết hợp (gộp) tất cả các giao dịch HTLC mà họ xứng đáng thành một giao dịch, sau đó trả phí xử lý bằng cách thêm đầu vào và thay đổi đầu ra cho giao dịch đó.
Với sự kết hợp của hai thiết kế này, việc triển khai các kênh sét đã được đơn giản hóa và vấn đề phí giao dịch chiếm dụng số dư đã được tối ưu hóa:
- Trong giao dịch cam kết, không nhất thiết phải dựa hoàn toàn vào giao dịch cam kết đó để thanh toán phí xử lý. Thay vào đó, có thể thiết lập mức phí xử lý tương đối ổn định và vấn đề về phí xử lý bổ sung có thể được giải quyết cho các giao dịch phụ được khởi tạo dựa trên đầu ra neo; theo cách này, vấn đề phí xử lý chiếm dụng số dư khả dụng của kênh được giảm bớt;
- Lưu ý rằng điều này không giải quyết hoàn toàn vấn đề cần ước tính phí giao dịch. Do sự biến động của thị trường phí, ngưỡng giá trị của mức phí cho một giao dịch được chuyển tiếp nút cũng sẽ biến động. Mặc dù các giao dịch đã cam kết không còn phải đảm bảo rằng chúng có thể được xác nhận bất cứ lúc nào, nhưng chúng vẫn cần đảm bảo rằng phí của chúng đủ cao để thu hút sự lan truyền của nút; nếu chúng không thể được phổ biến thì phương pháp CPFP sẽ không hiệu quả. Nhưng độ khó đã được giảm bớt.
- Trong các giao dịch HTLC, phí giao dịch không còn được thanh toán bởi đầu vào giao dịch (tức là HTLC), do đó không cần phải xem xét mức phí ảnh hưởng như thế nào đến việc xây dựng và tính mong muốn của các giao dịch HTLC.
Chi phí là khi sử dụng kênh neo, người dùng phải đảm bảo rằng họ có sẵn tiền trên Chuỗi trong ví của mình để thanh toán phí giao dịch.
Sự thật phức tạp
Bạn có thể cho rằng rằng xét theo cấu trúc giao dịch Bitcoin và phương pháp tính phí thì việc áp dụng những cải tiến trên là điều tự nhiên và đơn giản. Tuy nhiên, thực tế là, mặc dù có thể coi đây là sự tiến triển tự nhiên, nhưng nó không hề dễ dàng như vậy. Điều này là do các mối quan hệ tuần tự (cấu trúc) có thể được hình thành bởi nhiều sàn giao dịch rất đa dạng. Bất kể là RBF hay CPFP, việc cho phép hành vi này tương đương với việc cho phép người khởi tạo giao dịch chiếm một phần tài nguyên của nút truyền bá giao dịch. Việc chiếm dụng này phải được hạn chế, nếu không kẻ tấn công có thể phát động các cuộc tấn công DoS vào nút truyền bá giao dịch bằng cách thay thế các giao dịch và xây dựng các gói giao dịch. Mặt khác, những quy tắc được sử dụng để hạn chế hành vi cũng có thể được sử dụng để phát động các cuộc tấn công.
Ví dụ. Để hạn chế hành vi CPFP, các quy tắc về nhóm giao dịch của Bitcoin Core yêu cầu một giao dịch chưa được xác nhận chỉ có thể có 24 giao dịch con. Vâng, trong giao dịch cam kết của kênh neo ở trên, vì cả hai bên đều có đầu ra neo nên một bên có thể thêm 24 giao dịch phụ vào giao dịch cam kết bằng cách sử dụng đầu ra neo của riêng mình, do đó ngăn cản bên kia khởi tạo CPFP. Do rủi ro của cuộc tấn công này (được gọi là "cuộc tấn công ghim giao dịch"), các quy tắc Bitcoin Core ở trên cho phép một ngoại lệ: khi một giao dịch con có trọng lượng nhỏ hơn 1000 vB và chỉ có một giao dịch tổ tiên chưa được xác nhận, thì giao dịch đó có thể trở thành giao dịch con thứ 25 của giao dịch tổ tiên chưa được xác nhận. Quy tắc ngoại lệ này (gọi là “Carve Out”) cho phép kênh neo được đề cập ở trên hoạt động an toàn (nhưng vẫn không thể loại bỏ rủi ro bị đối thủ tác động) [6] .
Cuối cùng, mạng lưới bao gồm nút đầy đủ Bitcoin và các quy tắc nhóm giao dịch được áp dụng bởi mỗi nút tạo nên sự phụ thuộc bảo mật của các giao thức hợp đồng như Lightning Channels (chúng thường yêu cầu các giao dịch phải được xác nhận ngay lập tức để đảm bảo an toàn cho tiền của người dùng), nhưng các quy tắc nhóm giao dịch này có thể không hoàn hảo. Không dễ để thiết kế các quy tắc giao dịch đáng tin cậy và chống lạm dụng.
Kể từ năm 2022, các nhà phát triển Bitcoin đã bắt đầu hình thành những ý tưởng mới về các quy tắc nhóm giao dịch, trong đó nổi tiếng nhất là "giao dịch v3 [7] " và "nhóm giao dịch gia tộc [8] "; phương pháp trước hỗ trợ thiết kế các quy tắc phức tạp hơn bằng cách hạn chế cấu trúc giữa các giao dịch, trong khi phương pháp sau hy vọng thiết kế lại sắp xếp nội bộ của nhóm giao dịch để hỗ trợ các quy tắc RBF tốt hơn. Điều thú vị là vì nhóm giao dịch của bộ lạc không cho phép CPFP-Carve Out nên các giao dịch v3 (hiện được đổi tên thành "giao dịch TRUC") sẽ là cầu nối của chúng ta với nhóm giao dịch của bộ lạc.
Trong phần tiếp theo, chúng tôi sẽ giới thiệu cách triển khai những ý tưởng này trong Bitcoin Core 28.0 (xem hướng dẫn này [9] để biết chi tiết) và cách các kênh Lightning có thể sử dụng chúng để cải thiện trải nghiệm của người dùng.
Một mô hình mới dựa trên gói giao dịch 1P1C
Trước hết, Bitcoin Core 28.0 giới thiệu một đơn vị nhóm giao dịch mới có tên là "gói giao dịch 1P1C". Đúng như tên gọi, đây là một gói giao dịch chỉ bao gồm hai giao dịch cha-con. Họ sẽ cạnh tranh để xác nhận khối với các đơn vị nhóm giao dịch khác (chẳng hạn như đơn vị giao dịch hoặc các gói giao dịch 1P1C khác). Trong đó, tỷ lệ phí xử lý của giao dịch mẹ chỉ cần đạt ngưỡng thấp nhất là 1 satoshi/vB và không cần phải cân nhắc đến ngưỡng tỷ lệ phí xử lý khi tham gia nhóm giao dịch có thể thay đổi nút lúc nào.
Thứ hai, căn cứ vào gói giao dịch 1P1C, nếu tất cả các giao dịch trong đó sử dụng số phiên bản là “3” thì sẽ tuân theo quy tắc của “giao dịch TRUC”: khối trong đó đơn vị giao dịch không được vượt quá 10 kvB, khối lượng giao dịch phụ không được vượt quá 1kvB; không còn yêu cầu nào về tỷ giá giao dịch gốc (có thể là tỷ giá bằng 0); quan trọng nhất là khi một giao dịch phụ khác được thêm vào cùng một giao dịch cha, bất kể nó có sử dụng cùng đầu vào với giao dịch phụ ban đầu hay không, thì nó sẽ được coi là xung đột giữa hai giao dịch và quy tắc thay thế RBF sẽ được áp dụng.
Nghĩa là, mặc dù 28.0 cho phép chuyển tiếp các gói giao dịch, nhưng hình thức của gói giao dịch chỉ giới hạn ở hai giao dịch và các xung đột và cạnh tranh trực tiếp ở cấp độ giao dịch phụ không thể phá hủy hình thức này. Ràng buộc này làm giảm đáng kể khó khăn trong việc phân tích và thiết kế các quy tắc thay thế.
Quay lại kênh sét:
- Khi giao dịch cam kết của kênh Lightning áp dụng giao dịch v3, giao dịch đó không cần phải chịu bất kỳ phí giao dịch nào. Điều này giải quyết hoàn toàn vấn đề ước tính phí giao dịch và vấn đề phí giao dịch chiếm dụng dung lượng kênh!
- Không còn phải cân nhắc thay đổi phí, không còn phải đàm phán phí và không còn phải đóng kênh gây phiền nhiễu do bất đồng về phí nữa!
- Vì chúng ta không còn dựa vào Carve-Out nữa nên không cần phải thiết lập điểm neo cho mỗi bên nữa, chúng ta chỉ cần thiết lập một điểm neo đầu ra duy nhất mà cả hai bên đều có thể sử dụng. Điều này có thể làm giảm quy mô giao dịch cam kết và cải thiện đôi chút hiệu quả kinh tế. Thậm chí có thể sử dụng các đầu ra neo có thể được chi tiêu mà không cần khóa [10] .
Phần kết luận
Quay trở lại câu hỏi ở đầu bài viết: Ai phải trả phí giao dịch cho giao dịch cam kết? Tất nhiên, lý tưởng nhất là bất kỳ ai muốn giao dịch được đưa vào Chuỗi đều phải trả phí giao dịch. Ngày nay, với sự hỗ trợ của gói giao dịch 1P1C và giao dịch TRUC, cuối cùng chúng ta cũng có thể hiện thực hóa lý tưởng này.
chú thích
1. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-etablishment-v1 ↩
2. https://ellemouton.com/posts/htlc-deep-dive/ ↩
3. Có một ý tưởng thú vị từ Peter Todd, đó là cho phép những người tham gia kênh ký nhiều bộ giao dịch cam kết cho cùng một trạng thái kênh ở các mức phí khác nhau khi cập nhật trạng thái, do đó cho phép những người tham gia phát các giao dịch cam kết với mức phí phù hợp dựa trên các trường hợp cụ thể khi đi vào Chuỗi, bao gồm cả việc khởi tạo RBF tại thời điểm đó. Nhưng như bạn có thể thấy, phiên bản này có thể không phù hợp với tất cả mọi loại người tham gia kênh. Để biết thêm chi tiết, vui lòng xem: https://www.btcstudy.org/2024/01/07/v3-transactions-review-by-peter-todd/#%E6%89%8B%E7%BB%AD%E8%B4%B9%E6%9B%BF%E6%8D%A2 ↩
4. https://www.btcstudy.org/2024/01/12/rethinking-lightning-by-benthecarman/ ↩
5. Khi tạo chữ ký cho giao dịch đầu vào Bitcoin, một thẻ gọi là sighash có thể được sử dụng để chỉ ra phần giao dịch được chữ ký bao hàm (tức là việc sử dụng số tiền mà chủ sở hữu số tiền đã đồng ý); chỉ những thay đổi đối với phần được chữ ký bao phủ mới làm mất hiệu lực chữ ký (khiến quá trình xác minh tập lệnh Bitcoin không thể vượt qua). Thẻ phổ biến là "SIGHASH_ALL", có nghĩa là chữ ký bao gồm tất cả các đầu vào và đầu ra của giao dịch - việc thêm, xóa hoặc thay đổi bất kỳ phần nào của đầu vào và đầu ra của giao dịch sẽ làm mất hiệu lực chữ ký. Để biết thêm chi tiết, vui lòng xem: https://www.btcstudy.org/2021/11/09/bitcoin-signature-types-sighash/ ↩
6. https://www.btcstudy.org/2022/08/08/anchor-outputs/ ↩
7. https://bitcoinops.org/en/topics/version-3-transaction-relay/ ↩
8. https://www.btcstudy.org/2024/01/16/an-overview-of-the-cluster-mempool-proposal/ ↩
9. https://www.btcstudy.org/2025/01/07/bitcoin-core-28-wallet-integration-guide/ ↩
10. https://delvingbitcoin.org/t/which-ephemeral-anchor-script- Should-lightning- use/1412 ↩
