Xem xét các giải pháp Layer 2 dựa trên soft fork /hạn chế

Tác giả: Peter Todd

Nguồn: https://petertodd.org/2024/covenant-depend-layer-2-review

Ví trên chuỗi thực hiện ánh xạ một-một (đại khái) từ giao dịch này sang giao dịch khác: đối với một giao dịch tiết kiệm mà người dùng muốn thực hiện, cần phải có một giao dịch blockchain gần như hoàn chỉnh. Tổng hợp giao dịch, coinjoin, cut-through và các công nghệ khác đều hơi sai lệch một chút, nhưng nhìn chung, tuyên bố của chúng tôi vẫn đúng.

Các kênh Lightning triển khai ánh xạ nhiều-một : điều kỳ diệu của các kênh Lightning là các giao dịch kinh tế hầu như không giới hạn có thể xảy ra trong một kênh và bản thân kênh đó bị ràng buộc với một đầu ra giao dịch chưa được chi tiêu (UTXO). Về cơ bản, chúng tôi đã nắm bắt được chiều “thời gian”—giao dịch—và đạt được quy mô đáng kể bằng cách thu gọn chiều này.

Tuy nhiên, việc để mỗi người dùng tạo một UTXO là chưa đủ (ít nhất là có thể nói như vậy). Do đó, nhiều đề xuất đã xuất hiện, cố gắng cho phép nhiều người dùng chia sẻ UTXO dưới dạng lưu ký tự trị để đạt được hiệu quả mở rộng lớn hơn. Lần này, thứ được thu gọn là thứ nguyên "không gian" - người dùng - thành UTXO.

Mục tiêu của tôi ở đây là xem xét tất cả các đề xuất này, xác định các mẫu kỹ thuật mà chúng chia sẻ, xác định các loại opcode mới hoặc nâng cấp phần mềm mà chúng yêu cầu, sau đó xây dựng một bảng toàn diện để tất cả chúng đều phù hợp với bảng. Trong quá trình này, chúng tôi cũng sẽ xác định “Giao thức lớp 2” là gì, khả năng mở rộng của Lightning Network là gì và hiểu những nâng cấp nào đối với mempool mà chúng tôi cần thực hiện để thực hiện các đề xuất này.

Cảm ơn Fulgur Ventures đã tài trợ cho nghiên cứu này. Họ không có quyền biên tập nội dung của bài viết này và không xem xét nó trước khi xuất bản.

Cảm ơn Daniela Brozzoni , Sarah Cox và những người khác đã xem xét trước khi xuất bản.

1 Định nghĩa

1.1 “Lớp 2” là gì?

Thông thường mọi người sử dụng định nghĩa rộng về "Lớp 2", do đó ngay cả các thực thể như ngân hàng (chẳng hạn như Liquid) cũng có thể được định nghĩa là Lớp 2. Với mục đích của bài viết này, chúng tôi sẽ áp dụng định nghĩa hẹp hơn: Lớp 2 là một hệ thống bằng Bitcoin tồn tại để cho phép BTC được giao dịch giữa các bên liên quan với tần suất cao hơn so với giao dịch trên chuỗi và:

1. Sau khi tính đến các khoản phạt và chi phí trong hệ thống , không ai có thể kiếm lợi từ việc đánh cắp tiền từ hệ thống. Các chi phí và hình phạt bên ngoài hệ thống, chẳng hạn như thiệt hại về danh tiếng, hậu quả pháp lý, v.v., không được xem xét trong định nghĩa của chúng tôi.
2. Chủ sở hữu thực sự của quỹ (ưu tiên) có thể đơn phương rút tiền của mình (trừ phí giao dịch) mà không cần sự hợp tác của bất kỳ bên thứ ba nào.

Mục đầu tiên là cần thiết vì chúng tôi muốn hệ thống L2 của mình có thể biểu thị số tiền và giao dịch quá nhỏ để thể hiện trên chuỗi. Ví dụ: trong các kênh Lightning, HTLC có thể có các mệnh giá quá nhỏ để thể hiện trên chuỗi. Trong trường hợp này, giá trị HTLC sẽ được cộng vào phí giao dịch của giao dịch đã cam kết. Mặc dù các nút sét có thể đóng các kênh theo cách có chủ đích để "đánh cắp" HTLC bụi, nhưng làm như vậy rất tốn kém ^[1] và chi phí vượt quá giá trị của chính HTLC, do đó hành vi trộm cắp là không có lợi.

Mục thứ hai là việc rút đơn phương luôn là mục tiêu thiết kế chính của chúng tôi ^[2] .

Theo định nghĩa này, Lightning Channel sẽ được coi là hệ thống L2. Tuy nhiên, các hệ thống như Liquid, Cashu và Fedemint không phải là L2 vì một bên (hoặc các bên) khác kiểm soát tiền của bạn. Các giải pháp "xác thực phía máy khách" (chẳng hạn như RGB) cũng không phải là L2 theo định nghĩa này, vì chúng không thể tự chuyển BTC một cách đáng tin cậy. Cuối cùng, “ Statechains ” cũng không đáp ứng định nghĩa này ( bản dịch tiếng Trung ), bởi vì nếu thực thể Statechain (nhà cung cấp dịch vụ) cố tình không tuân thủ thỏa thuận, tiền có thể bị đánh cắp.

1.2 “Hạn chế” là gì?

…Vậy tại sao hệ thống L2 lại cần các ràng buộc để đạt được khả năng mở rộng cao hơn?

Trong lập trình tập lệnh Bitcoin, "điều khoản hạn chế" đề cập đến một cơ chế có thể giới hạn cách chi tiêu đầu ra giao dịch (txout) trước, do đó hình thức giao dịch chi tiêu txout này được xác định trước hoặc theo cách A để hạn chế chi phí của nó không phụ thuộc hoàn toàn vào chữ ký điện tử. Các hệ thống L2 chia sẻ UTXO giữa nhiều người tham gia yêu cầu các điều khoản hạn chế vì chúng cần giới hạn cách sử dụng UTXO để thực hiện các quy tắc và ưu đãi của giao thức L2.

1.2.1 Hạn chế đệ quy

Hạn chế đệ quy là các hạn chế có thuộc tính quy định hạn chế cách chi tiêu UTXO có thể được áp dụng đệ quy, mở rộng vô thời hạn cho các UTXO phụ của giao dịch chi tiêu. Các hạn chế đệ quy từ lâu đã được một số người coi là không mong muốn vì chúng có thể dẫn đến việc quỹ bị ràng buộc vĩnh viễn. Hoặc ít nhất là bị mắc kẹt mãi mãi mà không có sự cho phép của bên thứ ba, như chính phủ.

2 bàn thắng

Lightning Channel hiện đang là “người dẫn đầu” trong số các hệ thống Lớp 2. Nhưng nó cũng có những hạn chế, đó là:

1. Khả năng mở rộng - Lightning Channel hiện yêu cầu mỗi người dùng cuối phải có ít nhất một UTXO ^[3] .
2. Tính thanh khoản - Các kênh Lightning yêu cầu phải có tiền trong kênh.
3. Tương tác – Các kênh Lightning yêu cầu người nhận thanh toán phải trực tuyến để nhận thanh toán một cách đáng tin cậy.

Khi đánh giá các hệ thống Lớp 2, mục tiêu của chúng tôi là cải thiện những hạn chế chính này, lý tưởng nhất là không đưa ra những hạn chế mới.

2.1 Hạn chế về khả năng mở rộng của Kênh Lightning

Trong kịch bản thực tế, "mỗi người dùng cuối cần UTXO" nghĩa là gì? Bởi vì các kênh Lightning có thể chạy vô thời hạn nên một cách để phân tích là tìm hiểu xem có thể tạo bao nhiêu kênh mới mỗi năm ^[4] ? Chi phí biên của việc tạo ra đầu ra taproot là $43vB$; nếu việc tạo ra các kênh có thể được khấu hao, tức là nhiều kênh có thể được mở trong một giao dịch thì chi phí giao dịch khác sẽ trở nên không đáng kể và một số lượng lớn các kênh mới có thể được mở hàng năm Nhiều kênh để đáp ứng người dùng mới. Ví dụ: giả sử rằng 90% không gian khối được sử dụng để mở kênh sét taproot mới:
$$
52{\small,}560\frac{\mathrm{blocks}}{\mathrm{year}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm {block}} \times 90% \times 1\frac{\mathrm{channel}}{43\mathrm{vB}} = 1,1,\mathrm{billion}\frac{\mathrm{channels}}{\mathrm{năm }}
$$
(Kết quả là 1,1 tỷ kênh mới có thể được mở mỗi năm)

Người ta ước tính rằng một nửa dân số thế giới sở hữu điện thoại thông minh , tức là 4,3 tỷ người. Vì vậy, trên thực tế, hàng năm chúng tôi có thể đưa một tỷ lệ lớn dân số có khả năng sử dụng Lightning Network vào Lightning Network.

Tuy nhiên, kênh sẽ không bị đóng mãi mãi. Đôi khi, người dùng muốn chuyển đổi ví, tăng giảm dung lượng kênh, v.v. Cách hiệu quả nhất để thay đổi dung lượng kênh là " nối kênh ", đặc biệt là triển khai Phoenix Wallet .

Cũng giống như việc mở các kênh, việc ghép kênh cũng có thể được khấu hao để nâng cao hiệu quả: nhiều hoạt động ghép nối có thể chia sẻ một giao dịch để giảm số lượng đầu vào và đầu ra cần thiết để thêm và bớt tiền ^[5] . Do đó, không gian khối gia tăng cần thiết cho hoạt động ghép nối của mỗi người dùng, giả sử người dùng sử dụng musig , là $43vB$ đầu ra của taproot cộng với $57,5vB$ dữ liệu chứng kiến được chi tiêu trên đường dẫn khóa taproot, với tổng số tiền là $100,5vB$. Nếu chúng ta lại giả định rằng 90% không gian khối được sử dụng cho mục đích này thì:
$$
52{\small,}560\frac{\mathrm{blocks}}{\mathrm{year}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm {block}} \times 90% \times 1\frac{\mathrm{splice}}{100.5\mathrm{vB}} = 470,\mathrm{million}\frac{\mathrm{splices}}{\mathrm{năm }}
$$
(Kết quả là 470 triệu lượt ghép kênh mỗi năm)

Cuối cùng, lưu ý rằng việc chuyển đổi kênh Lightning giữa các ví có thể được thực hiện trong một giao dịch, bằng cách tin cậy vào ví mới và ký giao dịch cam kết sau khi tiền đã được gửi đến địa chỉ cam kết hoặc bằng cách chuyển đổi giữa ví cũ và ví mới. hợp tác xã “đóng và mở kênh mới”.

Tất nhiên, sẽ có những trường hợp sử dụng Bitcoin khác cạnh tranh giành không gian khối bên ngoài Lightning Channel và thật khó để biết điều đó sẽ chuyển thành phí như thế nào. Nhưng những số liệu này cho chúng ta ước tính sơ bộ, cho thấy rằng với công nghệ hiện tại, ít nhất về mặt kỹ thuật, có thể hỗ trợ hàng trăm triệu người dùng Lightning Network tự quản lý.

3 L2 Tổng quan

Theo định nghĩa L2 của chúng tôi, có hai mẫu thiết kế mà cộng đồng nhà phát triển Bitcoin đang thảo luận:

1. lối đi
2. UTXO ảo

Trong mô hình kênh, trong đó các kênh Lightning là một ví dụ điển hình, sự thăng tiến trạng thái đạt được bằng cách những người tham gia trao đổi các giao dịch được ký trước có thể được khai thác (nhưng không đại diện cho một kết thúc "có hậu"). Các giao dịch được ký trước này phân chia giá trị của UTXO giữa những người tham gia; các giao dịch kinh tế được thực hiện bằng cách liên tục sử dụng các giao dịch được ký trước mới để thay đổi kết quả của việc phân chia. Bởi vì sẽ có nhiều giao dịch hợp lệ sử dụng cùng một UTXO, nên cần có một số cơ chế khuyến khích để đảm bảo rằng chỉ những giao dịch chính xác mới thực sự được khối xác nhận.

Trong mẫu thiết kế "Virtual UTXO (V-UTXO)", Ark là ví dụ quan trọng nhất được tạo ra thông qua các điều khoản hoặc thỏa thuận hạn chế giữa nhiều bên; giao dịch đại diện cho giá trị có thể được khai thác, từ đó tích hợp tất cả các bên. -UTXO trở thành UTXO thực sự trên chuỗi, nhưng giao dịch như vậy không có nghĩa là một kết thúc "có hậu". Từ góc độ này, V-UTXO cũng tương tự như một kênh. Nhưng không giống như các kênh, sơ đồ V-UTXO thực hiện các giao dịch bằng cách chi tiêu chính V-UTXO, đây là (về mặt khái niệm) một giao dịch được ký trước ^[6] .

Mẫu thiết kế "mọi người đều thích" là sử dụng đường dẫn tập lệnh mà "tất cả những người tham gia đều đồng ý", chẳng hạn như cài đặt taproot đa chữ ký N-of-N được thiết kế riêng cho khái niệm này, cho phép đường dẫn chính (thông qua musig); ) để trở thành thiết bị đa chữ ký N-of-N. Giả sử tất cả những người tham gia đều đồng ý, con đường này cho phép chi tiêu tiền một cách hiệu quả (và riêng tư).

Điều thú vị là, vì UTXO ảo là "thực" theo nhiều cách, nên rất dễ dàng thiết lập kênh trên UTXO ảo chỉ bằng cách có UTXO ảo, khi được khai thác, sẽ tạo ra UTXO mà kênh yêu cầu. Theo nghĩa này, UTXO ảo ở cấp độ thấp hơn một chút so với các kênh.

3.1 Mạng sét

Cho đến nay, Lightning Network được triển khai trong môi trường sản xuất chủ yếu dựa trên tiêu chuẩn BOLT . Lightning Network là sự kết hợp của các công nghệ, bao gồm Lightning Channels và HTLC, mạng định tuyến P2P, định tuyến củ hành, tiêu chuẩn lập hóa đơn, v.v. Điều quan trọng là Lightning Network không phải là một hệ thống công cộng, do đó, các mô-đun khác nhau của "Lightning System" không cần phải được tất cả người dùng áp dụng theo cách giống hệt nhau. Vì mục đích của bài viết này, khi chúng tôi nói "Lightning Network", chúng tôi đang sử dụng nó một cách rộng rãi để bao gồm các bản nâng cấp dễ dàng dự đoán trước cho (các) giao thức Lightning Network hiện có (điển hình), được sử dụng rộng rãi.

Như đã đề cập trước đây, một tính năng chính của Lightning Network là giới hạn khả năng mở rộng của người dùng cuối, xuất phát từ yêu cầu mỗi người dùng cần ít nhất một UTXO. Điều đó cho thấy, đối với mô-đun định tuyến “cốt lõi” của Lightning Network—các nút Lightning chuyển tiếp giao dịch, công khai—những hạn chế về khả năng mở rộng này sẽ ít gây phiền toái hơn miễn là có nhiều người dùng cuối hơn các nút định tuyến. Nếu mạng lớn hơn nhiều, thì mạng sẽ lớn hơn nhiều. Lightning Network có thể hoạt động tốt và mỗi kênh công cộng để chuyển tiếp thanh toán của người dùng có thể dễ dàng xử lý một số lượng lớn giao dịch ngay lập tức. Đây là lý do tại sao nhiều hệ thống L2 mới được đề xuất dự kiến sẽ tham gia vào Lightning Network. Chúng ta cũng có thể nhận thấy rằng các hệ thống hiện tại không tuân thủ các tiêu chuẩn L2, chẳng hạn như Cashu, phải phụ thuộc rất nhiều vào Lightning Network để thực sự trở nên hữu ích: mục đích sử dụng chính của Cashu có thể là gửi và nhận thanh toán Lightning.

3.1.1 Kênh không tương tác

Cấu trúc này làm giảm yêu cầu tương tác và tối ưu hóa các kênh sét bằng cách sử dụng OP_CTV . Tuy nhiên, nó không tối ưu hóa giới hạn khả năng mở rộng "một UTXO cho mỗi người dùng", vì vậy chúng tôi sẽ không thảo luận thêm về vấn đề này.

Nhà máy 3.2 kênh

Trong cấu trúc này, chúng tôi có thể yêu cầu nhiều bên phối hợp để nhập một địa chỉ có nhiều chữ ký n-trong-n và một giao dịch được ký trước phù hợp sẽ sử dụng địa chỉ nhiều chữ ký này và tạo n UTXO khác nhau để chia tiền. Mỗi trong số n UTXO này sẽ được sử dụng làm kênh thanh toán. Tính bảo mật của các kênh này cũng giống như mở trực tiếp trên chuỗi, vì giao dịch chia tiền có thể được khai thác khi trạng thái kênh cần được công bố lên chuỗi. Điều này có thể tiết kiệm không gian trên chuỗi khi các kênh bị đóng, bởi vì - về lý thuyết - những người tham gia $n$ có thể hợp tác để đóng tất cả các kênh $n$ cùng một lúc.

Bởi vì nhà máy sản xuất kênh là một UTXO phối hợp có thể được khai thác nhưng dự kiến sẽ không thực sự được khai thác trong kết thúc có hậu nên đây là một ví dụ rất sơ khai về V-UTXO.

Việc triển khai nhà máy kênh không yêu cầu bất kỳ phần mềm nào. Tuy nhiên, nhà máy sản xuất kênh đơn giản được mô tả ở trên có thể trở nên không thực tế sau khi có nhiều người tham gia hơn một chút, vì cần có sự hợp tác của người dùng để thực sự nhận ra lợi ích của việc mở rộng quy mô. Do đó, các đề xuất ràng buộc như OP_Evict hoặc CTV (thông qua cây txout) có thể hữu ích, cho phép công bố kết quả chi tiết hơn - các bên đơn lẻ có thể được đưa vào chuỗi mà không buộc mọi người phải tham gia chuỗi cùng một lúc.

3.3 Eltoo/LN-Đối xứng

Vì Eltto là một cái tên xấu và khó hiểu nên chúng tôi sẽ chỉ sử dụng tên cập nhật "LN-Symmetry" bên dưới.

Kênh Poon-Dryja trừng phạt việc xuất bản trạng thái không chính xác để khuyến khích xuất bản trạng thái chính xác, trong khi LN-Symmetry thực hiện ngược lại và cho phép cập nhật trạng thái không chính xác bằng một giao dịch bổ sung. Lợi ích là nó đơn giản hóa Lightning Pass bằng cách loại bỏ sự phức tạp của các hình phạt. Tuy nhiên, nó cũng có thể có những bất lợi trong môi trường không đáng tin cậy, vì các hình phạt được cho là cần thiết để ngăn chặn chúng.

LN-Symmetry yêu cầu một soft fork để kích hoạt SIGHASH_ANYPREVOUT nhằm cho phép các giao dịch trạng thái mới chi tiêu lại các giao dịch trạng thái cũ.

Bản thân LN-Symmetry không mang lại những cải tiến về hiệu suất mở rộng cho các kênh Lightning truyền thống. Nhưng những người ủng hộ nó cho rằng nó sẽ làm cho việc triển khai các nhà máy tiếp cận dễ dàng hơn.

3.4 Con tàu

Ark áp dụng một phương pháp mới để đạt được quy mô giao dịch: UTXO ảo có thể chuyển nhượng hoàn toàn (V-UTXO). Các UTXO ảo này có thể được hợp nhất và phân chia trong các giao dịch ngoài chuỗi nguyên tử ^[7] . Trong Ark, điều phối viên trung tâm "Nhà cung cấp dịch vụ Ark (ASP)" cung cấp cho người dùng V-UTXO với giới hạn thời gian xác định (chẳng hạn như 4 tuần). Những chu kỳ này được gọi là " vòng ". Các V-UTXO này được tạo thông qua đầu ra giao dịch nhóm vốn và được tạo một lần trong mỗi vòng. Thông qua một số cơ chế (chẳng hạn như CTV), một đầu ra giao dịch trên chuỗi duy nhất có thể cam kết với cây V-UTXO. Cơ chế hết hạn vòng là chìa khóa mang lại lợi ích về khả năng mở rộng của Ark: khi kết thúc một vòng, đầu ra của giao dịch nhóm được mở khóa, cho phép ASP đơn phương chi tiêu số tiền đó chỉ bằng một chữ ký trong một giao dịch nhỏ. Bởi vì vòng có thời gian hết hạn, V-UTXO được tạo bởi đầu ra giao dịch nhóm vốn cũng có thời gian hết hạn: người dùng nắm giữ V-UTXO phải chi tiêu V-UTXO này trước khi đầu ra giao dịch nhóm tương ứng hết hạn hoặc được xuất bản lên chuỗi (rút tiền đơn phương).

Để chuyển V-UTXO, điều phối viên Ark đồng ký một giao dịch có giá một hoặc nhiều V-UTXO và làm cho giao dịch chỉ có hiệu lực nếu một hoặc nhiều V-UTXO khác được tạo trong một vòng khác . Kết hợp với một số thời gian chờ được thiết kế cẩn thận - xem tài liệu của Ark để biết chi tiết đầy đủ - sự phụ thuộc này là nguyên nhân khiến việc chi tiêu V-UTXO không đáng tin cậy: trừ khi V-UTXO mới được tạo trong một giao dịch nhóm khác, V-UTXO cũ không thể bị lấy đi khỏi chuỗi (khi đầu ra giao dịch nhóm được chi tiêu). Có một số cách để thực hiện sự phụ thuộc này. Nhưng các chi tiết chính xác không liên quan đến mục đích của bài viết này.

Lưu ý rằng điều này có nghĩa là một ASP sẽ hoạt động đồng thời trên nhiều vòng hoạt động. Các vòng mới thường được tạo để cho phép chuyển tiền từ các vòng hiện có. Nhưng các vòng hiện tại sẽ trùng lặp với vòng mới, vì chúng thường hết hạn sau khi vòng mới (giao dịch nhóm mới) được tạo.

3.4.1 Mô hình kinh tế của Ark

Khi sử dụng V-UTXO, ASP phải cung cấp BTC phù hợp trong đầu ra giao dịch nhóm đại diện cho vòng mới. Tuy nhiên, họ không thể sử dụng giá trị của V-UTXO đã chi cho đến khi kết thúc vòng hiện tại. Do đó, việc chi tiêu V-UTXO có một chi phí: giá trị thời gian của tiền, vì ASP phải ứng trước vốn.

Nói chính xác, chi phí này phát sinh khi sử dụng V-UTXO. Khi một V-UTXO không được sử dụng, nó đại diện cho một UTXO tiềm năng rất thực tế có thể được đưa lên chuỗi để đơn phương rút tiền; Tuy nhiên, để chi tiêu V-UTXO này, ASP phải tạo đầu ra giao dịch nhóm mới , sử dụng số tiền mà ASP thu được từ nơi khác và số tiền trong V-UTXO đã chi không thể được sử dụng cho đến khi vòng của nó hết hạn.

Do đó, việc chi tiêu V-UTXO yêu cầu một khoản vay ngắn hạn để trang trải khoảng thời gian từ nay đến khi hết vòng. Điều này có nghĩa là khi V-UTXO già đi (dần dần đến gần thời gian hết hạn của vòng), chi phí thanh khoản khi chi tiêu một V-UTXO sẽ giảm dần - về mặt lý thuyết - và cuối cùng đạt đến mức 0 (nghĩa là vào cuối vòng) khi hết hạn).

Cuối cùng, hãy nhớ rằng chi phí chi tiêu của V-UTXO liên quan đến tổng kích thước của V-UTXO được chi tiêu chứ không phải số tiền được chuyển cho người nhận. Điều này có nghĩa là một ví quan tâm đến việc chuyển trực tiếp nhiều V-UTXO (trái ngược với ví quản lý một V-UTXO cho (ví dụ) kênh Lightning dựa trên V-UTXO) cần phải đánh đổi: quyết định chia tách a quỹ Có bao nhiêu V-UTXO? Chỉ giữ một V-UTXO có thể giảm chi phí rút tiền đơn phương nhiều nhất có thể, nhưng nó sẽ tối đa hóa phí giao dịch dựa trên tính thanh khoản; việc chia thành nhiều V-UTXO thì ngược lại. Điều này hoàn toàn khác với mô hình kinh tế của các giao dịch Bitcoin và Lightning trên chuỗi.

Chi phí thanh khoản là gì? Theo văn bản này, ví Lightning Network Phoenix tính phí 1% cho tính thanh khoản của kênh kéo dài trong 1 năm, tệ nhất là Phoenix sẽ phải buộc tiền trong 1 năm. Tuy nhiên, giả định là thanh khoản này không được sử dụng. Có thể đối với Phoenix, chi phí cấp vốn trên thực tế cao hơn 1% một năm, nhưng họ cho rằng khách hàng trung bình sẽ sử dụng hết thanh khoản trên sổ sách này trong vòng chưa đầy một năm. Phoenix cũng kiếm được doanh thu từ phí giao dịch nên cũng trợ cấp thanh khoản cho kênh. Cuối cùng, có khả năng Phoenix sẽ không kiếm được tiền!

Lợi tức trái phiếu kho bạc Hoa Kỳ có thể cho chúng ta một ước tính khác. Theo văn bản này, lãi suất trái phiếu kho bạc kỳ hạn ba tháng là khoảng 5% hàng năm. Bởi vì lạm phát của đồng đô la Mỹ sẽ làm cho tỷ suất lợi nhuận này giảm đi nên vì mục đích phân tích, chúng tôi giả định rằng chi phí thanh khoản của các quỹ dựa trên BTC là 3% hàng năm.

Nếu vòng này kéo dài 4 tuần thì chi phí thanh khoản của giao dịch sẽ bắt đầu từ $3% / \frac{52}{4} = 0,23%$ và giảm dần xuống 0. Giả sử rằng người dùng chuyển tiền hai tuần trước khi vòng hiện tại kết thúc, chi phí thanh khoản phải trả để đạt được quyền tự chủ về tiền là khoảng 1,5% hàng năm. Mặt khác, nếu người dùng đợi đến giây phút cuối cùng ^[8] , chi phí thanh khoản này sẽ gần bằng 0 và rủi ro là bỏ lỡ thời gian hết hạn.

Người dùng có thể không nghĩ rằng đây là giá rẻ. Hơn nữa, mức giá này giả định rằng chi phí của mỗi vòng là cố định và phí giao dịch cũng như các chi phí khác đã được phân bổ thông qua một số lượng lớn người tham gia, khiến chúng không đáng kể.

Nhưng nếu chi phí cố định này không nhỏ thì sao? Giả sử rằng một ASP có 1.000 người dùng và trung bình tạo một giao dịch nhóm mỗi giờ. Trong 4 tuần, sẽ có 672 giao dịch trực tuyến. Điều này có nghĩa là, chỉ để giữ tiền của mình, toàn bộ người dùng ASP này phải trả phí cho hầu hết số lượng giao dịch bằng số lượng người dùng! Có thể sẽ rẻ hơn nếu họ mở các kênh Lightning của riêng mình và ASP sẽ khiến họ phải đợi một giờ để xác nhận giao dịch.

3.4.2 Ark khởi động nguội

Một ASP mới chỉ có một số người dùng sẽ phải đối mặt với một vấn đề nan giải: các vòng ASP diễn ra ít thường xuyên hơn, vì vậy người dùng cần phải đợi một thời gian dài cho đến khi vòng tương ứng thu thập đủ V-UTXO để đạt được chức năng hữu ích. Khả năng mở rộng phụ thuộc vào việc giảm phí giao dịch; hoặc, các giao dịch nhóm của ASP diễn ra thường xuyên và sau đó mỗi người dùng phải trả phí giao dịch cao hơn. Như chúng ta đã thảo luận trong phần trước, nó có thể yêu cầu một số lượng lớn người dùng trả dần các vòng diễn ra thường xuyên và các giao dịch nhóm tương ứng.

Vấn đề này thậm chí còn trở nên nghiêm trọng hơn vấn đề mà các kênh Lightning gặp phải do tồn tại thời gian hết hạn: ít nhất một kênh Lightning có thể hữu ích vô thời hạn và sau khi một kênh được mở, nó có thể được khấu hao dần trong vài tháng tới. Thứ hai, do các vòng hết hạn nên không có sự linh hoạt trong thời gian tạo đầu ra giao dịch để hỗ trợ các vòng này: nếu tình trạng phí cao kéo dài trong một hoặc hai tuần, người dùng của đầu ra giao dịch nhóm sắp hết hạn sẽ không có lựa chọn nào khác. (gọi chung) để duy trì việc quản lý quỹ. Ở kênh sét, thời điểm mở kênh sẽ linh hoạt hơn rất nhiều.

Mặc dù các tác giả của Ark ban đầu rất lạc quan và tin rằng sẽ chỉ mất vài giây để tạo một vòng mới, nhưng nếu phí giao dịch không thể được trợ cấp, lần ra mắt đầu tiên của Ark chỉ có thể diễn ra nếu có thể đợi vài giờ để giao dịch được xác nhận. các kịch bản ứng dụng.

3.4.3 Tính tương tác

Akr không giam giữ là một giao thức có yêu cầu tương tác cao: vì V-UTXO của bạn sẽ hết hạn nên bạn cần tương tác với ASP trước khi nó hết hạn, nếu không, ASP có thể lấy đi tiền của bạn. Yêu cầu tương tác này cũng không thể được thuê ngoài: ngược lại, Lightning Channel có " tháp canh " ngăn chặn đối thủ của bạn cố gắng lừa gạt bạn - ngay cả khi nút của bạn ngoại tuyến và chủ sở hữu Ark V-UTXO đang cố gắng tránh lừa gạt bạn. khóa riêng của họ để làm mới tiền. Trong Ark, điều gần gũi nhất với tháp canh là giao dịch chữ ký cho phép tháp canh thay mặt bạn đơn phương rút tiền trước khi hết hạn, đi kèm với chi phí giao dịch cao.

Hãy xem xét điều gì sẽ xảy ra với V-UTXO nếu chủ sở hữu quỹ ngoại tuyến: sau khi vòng đấu hết hạn, ASP cần thu hồi tiền để đáp ứng nhu cầu thanh khoản cho các vòng trong tương lai. Nếu chủ sở hữu V-UTXO ngoại tuyến, việc xuất bản V-UTXO lên chuỗi sẽ phải đối mặt với chi phí giao dịch cao vì ASP cần rút tiền trên cây V-UTXO nhiều lớp. ASP có thể tạo lại V-UTXO chưa được sử dụng trong một vòng mới, nhưng điều này không đáng tin cậy từ quan điểm của những người nắm giữ V-UTXO vì họ sẽ không thể tạo V-UTXO chưa được sử dụng trong một vòng mới ^[9] sử dụng các V-UTXO này vào tiền đề. ASP cũng có thể ghi trực tiếp V-UTXO chưa chi tiêu dưới dạng số dư ký quỹ. Thậm chí có thể có điều khoản tịch thu tiền!

Ý kiến cá nhân của tôi là, vì chi phí lưu ký tự trị trong Ark không hề rẻ, thay vào đó, nhiều người dùng sẽ chọn các ASP có thể tự động chuyển tiền vào các vòng mới, trực tiếp chấp nhận rủi ro gian lận vào cuối mỗi vòng. Điều này rẻ hơn so với chuyển khoản phòng ngừa để giữ an toàn cho tiền (ví dụ: tiền sẽ không được chuyển do không bật điện thoại hoặc kiểm soát ví kịp thời).

3.4.4 Ark cao cấp hơn

Có thể hợp lý khi sử dụng các ràng buộc nâng cao hơn để giảm nhu cầu thanh khoản của Ark nếu kịch bản điển hình là tất cả thanh khoản sẽ được sử dụng hết trong một vòng. Ví dụ: giả sử rằng 50% tổng giá trị của tất cả V-UTXO trong đầu ra của nhóm giao dịch sẽ được chi tiêu. Nếu ASP chỉ có thể tái chế một phần sản lượng của nhóm giao dịch, họ có thể tái chế tiền nhanh hơn và giảm chi phí thanh khoản tổng thể. Mặc dù chưa có đề xuất cụ thể nào được công bố nhưng có vẻ như nó có thể đạt được miễn là có đủ các hạn chế ^TM nâng cao. Rất có thể nó sẽ thông qua một số loại soft fork "Script Revival" nào đó để bổ sung nhiều opcode hữu ích cùng một lúc.

Tương tự, với các điều khoản hạn chế ^TM đủ tiên tiến như vậy, cấu trúc cây đầu ra giao dịch hoàn chỉnh có thể được thay thế bằng một số loại sơ đồ rút tiền luân phiên, do đó tiết kiệm không gian. Chúng ta sẽ thảo luận về chủ đề này trong phần tiếp theo vì kỹ thuật này cũng có thể hữu ích cho các tình huống khác.

Vấn đề giữ an toàn ở cuối vòng là một vấn đề khác mà các ràng buộc ^TM nâng cao hoàn toàn có thể giải quyết: một ràng buộc, đặc biệt là một ràng buộc có thể xác minh các ràng buộc bằng chứng không có kiến thức (ZK-proof), có thể buộc ASP nhập lại vào vòng tiếp theo. Tạo ra tất cả các hạn chế chưa được sử dụng để loại bỏ vấn đề quyền giám hộ được trao cho ASP vào cuối vòng. Mặc dù điều này có thể không đủ để khiến nó trở nên không đáng tin cậy , vì người dùng vẫn có thể cần một số dữ liệu từ ASP để sử dụng V-UTXO của riêng họ trong vòng mới, điều này có thể ngăn ASP thu lợi từ việc lừa gạt người dùng ngoại tuyến.

3.4.5 Thanh toán phí xử lý trên chuỗi khi rút tiền đơn phương

Tương tự như Lightning Channel, nguyên tắc kinh tế của việc thanh toán phí xử lý trên chuỗi và giá trị thực tế của V-UTXO sau khi thanh toán phí xử lý sẽ xác định xem việc sử dụng Ark có tuân thủ định nghĩa L2 của chúng tôi hay không (có thể đơn phương rút tiền, sẽ không cho phép ASP thu lợi từ gian lận). Chúng tôi sẽ thảo luận thêm về vấn đề này bên dưới khi thảo luận về mẫu thiết kế Cây đầu ra giao dịch.

3.5 Bản tổng hợp hiệu lực

Một lớp cấu trúc rộng tương tự như sidechain thường được đề xuất sử dụng một số dạng kỹ thuật chứng minh không có kiến thức để thực thi các quy tắc. Công nghệ chứng minh không có kiến thức như vậy là điểm khác biệt chính giữa "tổng hợp hợp lệ" và các dạng chuỗi bên khác: nếu sơ đồ chứng minh không có kiến thức có liên quan có thể hoạt động, thì tính hợp lệ của giao dịch sẽ được đảm bảo bằng toán học mà không cần phải tin tưởng vào Bên thứ ba các bữa tiệc. Trong cách sử dụng này, bản chất "không có kiến thức" của bằng chứng không có kiến thức là không cần thiết: điều đó hoàn toàn ổn ngay cả khi bằng chứng "tiết lộ" thông tin về những gì nó dự định chứng minh. Điều đó chỉ xảy ra khi hầu hết các sơ đồ toán học này đều là các sơ đồ chứng minh không có kiến thức.

Từ góc độ Bitcoin, sơ đồ tổng hợp hợp lệ yêu cầu một ràng buộc vì chúng tôi muốn có thể tạo UTXO cho một sơ đồ như vậy mà chỉ có thể được sử dụng khi tuân thủ các quy tắc của sơ đồ. Đây không nhất thiết phải là một hệ thống phi tập trung. Nhiều kế hoạch tổng hợp hiệu quả trên thực tế hoàn toàn tập trung; bằng chứng tổng hợp chỉ được sử dụng để chứng minh rằng người đặt hàng giao dịch tập trung đã áp dụng các quy tắc cho một tập hợp các giao dịch được đặt hàng.

Về những hạn chế sử dụng... Công nghệ chứng minh không có kiến thức vẫn là một lĩnh vực rất mới và thường xuyên đạt được nhiều tiến bộ. Do đó, rất khó có khả năng chúng ta sẽ thấy bất kỳ opcode nào xác minh trực tiếp một loại bằng chứng không có kiến thức nhất định được thêm vào Bitcoin. Thay vào đó, người ta thường chấp nhận rằng các giải pháp cụ thể sẽ sử dụng các opcode tổng quát hơn (đặc biệt là OP_CAT ) để xác minh bằng chứng không có kiến thức trong tập lệnh. Ví dụ: StarkWare đang nỗ lực để OP_CAT được thông qua.

Tổng hợp hiệu quả là một lĩnh vực rất rộng lớn với nhiều dự án chất lượng thấp/cường điệu cao. Chúng tôi sẽ không thảo luận thêm về vấn đề này ngoại trừ việc chỉ ra những opcode nào có thể cần thiết để làm cho kiểu thiết kế này trở nên khả thi.

3.6 BitVM

Nói một cách đại khái, BitVM là một phương pháp xây dựng kênh sét giữa hai người tham gia để các quy tắc của kênh sét có thể được thực thi bằng bằng chứng không có kiến thức. Bởi vì nó có thể được triển khai trên Bitcoin ngày nay mà không có điều khoản hạn chế và vì nó không thể được sử dụng trực tiếp để tạo ra hệ thống L2 có khả năng mở rộng cao hơn “1 UTXO cho mỗi người dùng”, nên chúng tôi sẽ không thảo luận thêm về vấn đề này.

3.7 Kênh phân cấp

Các kênh phân cấp ^[10] cam kết thực hiện việc điều chỉnh dung lượng kênh (thay đổi kích thước) nhanh hơn và rẻ hơn: "Các kênh phân cấp tương ứng với dung lượng kênh giống như các kênh Lightning đối với Bitcoin". mỗi người dùng. Nó cũng không yêu cầu bất kỳ thay đổi nào đối với giao thức Bitcoin. Vì thế chúng ta sẽ không thảo luận thêm. Những người ủng hộ kênh phân cấp chỉ nên thực hiện nó! Điều này không cần sự cho phép của chúng tôi.

3.8 CoinPool

Coinpool cho phép nhiều người dùng chia sẻ UTXO, chuyển tiền giữa những người dùng và người dùng có thể rút tiền đơn phương. Đề xuất bằng văn bản của CoinPool yêu cầu ba tính năng soft fork mới: SIGHASH_ANYPREVOUT , SIGHASH_GROUP để cho phép chữ ký chỉ được áp dụng cho một UTXO nhất định và OP_MerkleSub để xác minh rằng một nhánh nhất định đã bị xóa khỏi cây Merkle. Hoặc bạn cũng có thể sử dụng OP_CAT để đạt được điều này.

Hiện tại, quá trình phát triển CoinPool dường như đang bị đình trệ, với bản cập nhật cuối cùng cho trang web mô tả thông số kỹ thuật của nó là hai năm trước.

3.9 Mạng bí ẩn

Mặc dù tôi đã được yêu cầu thảo luận về Mạng Enigma, nhưng dường như không có tài liệu nào về đề xuất này thực sự trông như thế nào. Bài đăng trên blog của Bitfinex đưa ra một loạt khẩu hiệu; trang của MIT trống. Vì bài đăng trên blog này không thực sự giải thích cấu trúc thực tế của nó nên chúng tôi sẽ không thảo luận thêm.

4 Những điều cần cân nhắc đối với nhóm giao dịch

Chiến lược nhóm giao dịch hiện tại của Bitcoin Core không lý tưởng cho các hệ thống L2. Ở đây chúng tôi mô tả một số thách thức chính mà nó phải đối mặt, cũng như những cách tối ưu hóa có thể có.

4.1 Đóng đinh giao dịch

Cuối cùng đó là một sự bùng nổ kinh tế. "Tấn công ghim giao dịch" đề cập đến nhiều tình huống trong đó ai đó có thể cố ý ( hoặc vô ý ) làm cho một giao dịch mục tiêu trở nên khó khai thác vì một giao dịch xung đột khác đã bị chiếm trước và không được khai thác. Đây là một sự bùng nổ kinh tế vì trong kịch bản chốt giao dịch thực, giao dịch mục tiêu là giao dịch mà người khai thác có thể hưởng lợi sau khi khai thác; trong khi giao dịch xung đột không tồn tại trong một thời gian dài (có thể là mãi mãi).

Ví dụ đơn giản nhất về cuộc tấn công đóng đinh xuất phát từ thực tế là nếu không có "RBF đầy đủ" (tức là một nút mặc định cho tất cả các giao dịch có thể thay thế được), tính năng thay thế giao dịch có thể bị tắt. Sau đó, chúng tôi có thể bắt đầu giao dịch với mức phí thấp và tắt tính năng thay thế để giao dịch đó không bị khai thác hay thay thế. Về cơ bản, tất cả các nhà sản xuất khối đã bật RBF đầy đủ, từ đó giải quyết được vấn đề này và theo văn bản này, RBF đầy đủ sẽ được bật theo mặc định trong phiên bản tiếp theo của Bitcoin Core (sau khi làm việc chăm chỉ vào 11 năm sau!) .

Điều này làm cho cuộc tấn công đóng đinh liên quan đến BIP-125 Quy tắc số 3 trở thành cuộc tấn công đóng đinh duy nhất còn lại liên quan đến giao thức L2 nhiều bên (và vẫn chưa được giải quyết trong Bitcoin Core). Trích dẫn Quy tắc BIP-125 số 3 tại đây:

Giao dịch thay thế yêu cầu mức phí tuyệt đối cao hơn (không chỉ là phí); cao hơn tổng phí được trả bởi tất cả các sàn giao dịch được thay thế.

Quy tắc này có thể bị khai thác: một giao dịch cố định lớn nhưng có mức phí thấp (hoặc một nhóm trong số đó) có thể được phát sóng, chi tiêu các kết quả đầu ra liên quan đến thỏa thuận nhiều bên. Vì phí giao dịch quá thấp nên nó sẽ không được khai thác sớm (và có thể là không bao giờ). Tuy nhiên, vì số tiền phí của nó cao hơn nên việc thay thế bằng một giao dịch khác là không kinh tế.

Cuộc tấn công đóng đinh liên quan đến BIP-125 Quy tắc số 3 có thể dễ dàng giải quyết được trong " Thay thế mức phí (RBFR)" và có thể giải quyết được trong mọi trường hợp. Thật không may, không rõ liệu RBFR có sớm được Bitcoin Core áp dụng hay không vì họ đã dành rất nhiều thời gian cho một giải pháp kém, chưa hoàn thiện có tên là " Giao dịch TRUC/V3 " ( bản dịch tiếng Trung Quốc ).

4.2 Phương thức thanh toán phí

RBF, CPFP, SIGHASH_ANYONECANPAY , đầu ra cố định và tài trợ phí

Vì phí xử lý không thể đoán trước nên phí xử lý đáng tin cậy và tiết kiệm rất khó đạt được khi giao dịch được ký trước. Tiêu chuẩn vàng để thanh toán phí là sử dụng RBF (thay thế phí), bắt đầu bằng giá trị "được định giá thấp" và dần dần thay thế bằng phiên bản có phí cao hơn cho đến khi giao dịch được khai thác. Ví dụ: phần mềm lịch OpenTimestamps đã sử dụng phương pháp này trong nhiều năm và LND cũng hỗ trợ " RBF có lưu ý ngày hết hạn " trong v0.18.

RBF là tiêu chuẩn vàng vì nó hiệu quả nhất trong không gian khối trong hầu hết các trường hợp ^[11] : so với giao dịch đoán đúng phí ngay từ đầu, giao dịch thay thế không yêu cầu đầu vào hoặc đầu ra bổ sung.

Hiệu quả là quan trọng, bởi vì sự kém hiệu quả trong việc thanh toán phí sẽ biến việc thanh toán phí hộp đen thành nguồn lợi nhuận cho những người khai thác lớn; trong khi những người khai thác nhỏ và phi tập trung sẽ không thể hưởng lợi từ nó, bởi vì những người khai thác nhỏ được trả tiền. và vô dụng. Các khoản thanh toán ngoài giao thức cũng có thể gây ra các vấn đề về AML/KYC: hiện tại, hầu hết các hệ thống thanh toán thanh toán phí ngoài giao thức đều yêu cầu một số dạng quy trình AML/KYC; một ngoại lệ đáng chú ý là trình tăng tốc mempool.space tại thời điểm viết bài này; Khi nào (tháng 8 năm 2024), thanh toán Lightning sẽ có thể thực hiện được, không cần tài khoản.

Để sử dụng RBF trực tiếp trong bối cảnh các giao dịch được ký trước, bạn cần ký trước các biến thể của cùng một giao dịch có các mức phí khác nhau để trang trải đầy đủ các loại phí có thể có. Mặc dù điều này khá khả thi trong nhiều tình huống, vì số lượng biến thể cần thiết thường ít ^[12] , nhưng hiện tại, giao thức Lightning Network đang được sản xuất - cũng như các giao thức được đề xuất khác - đã chọn thay vào đó là " Con trai cho cha (CPFP)" , thường thông qua "đầu ra neo".

Ý tưởng đằng sau đầu ra cố định là thêm một hoặc nhiều đầu ra nhỏ (hoặc không có giá trị) vào một giao dịch để các giao dịch phụ có thể chi tiêu những đầu ra này khi thêm phí (tức là CPFP). Điều này đương nhiên là rất kém hiệu quả khi áp dụng cho một giao thức như Lightning Channel sử dụng các giao dịch trên chuỗi có khối lượng nhỏ, khiến tổng khối lượng giao dịch đã cam kết sử dụng đầu ra neo tạm thời tăng gần gấp đôi . Điều này ít gặp vấn đề hơn khi áp dụng cho các giao thức sử dụng khối lượng giao dịch lớn hơn - chẳng hạn như sử dụng OP_CAT để triển khai các điều khoản hạn chế.

Một vấn đề ít rõ ràng hơn với đầu ra cố định là các UTXO bổ sung (được sử dụng trong các giao dịch phụ) cần được giữ lại để trả phí. Trong ứng dụng "máy khách" tiêu chuẩn, đây có thể là một gánh nặng chi phí đáng kể, vì khi không sử dụng đầu ra neo, thường không cần lưu trữ nhiều hơn một UTXO. Trên thực tế, trong một số ví Lightning hướng tới người tiêu dùng hiện tại, việc không có khả năng thanh toán phí trong môi trường phí cao có thể khiến họ dễ bị đối thủ tấn công (và bị đánh cắp tiền).

SIGHASH_ANYONECANPAY có thể được sử dụng để thanh toán phí xử lý trong một số trường hợp nhất định. Nó cho phép thêm đầu vào bổ sung vào các giao dịch đã ký; SIGHASH_SINGLE cho phép thêm đầu ra. Giao thức Lightning Network sử dụng chúng trong các giao dịch HTLC. Hiện tại, nếu không được xử lý cẩn thận ^[13] , cách sử dụng này dễ bị tấn công chốt, vì kẻ tấn công có thể thêm nhiều đầu vào và/hoặc đầu ra để tạo ra một giao dịch được chốt với mức phí cao/phí thấp. RBFR giải quyết được vấn đề này; phương pháp được sử dụng trong giao dịch TRUC/V3 thì không. Phương thức thanh toán phí này không hiệu quả bằng RBF, nhưng nó có thể hiệu quả hơn so với đầu ra neo.

Cuối cùng, có nhiều soft fork đề xuất bổ sung hệ thống tài trợ phí vào giao thức Bitcoin. Điều này cho phép các giao dịch khai báo sự phụ thuộc vào các giao dịch khác, do đó các giao dịch cấp vốn chỉ có thể được khai thác khi giao dịch được cấp vốn được khai thác (rất có thể trong cùng một khối). Điều này có thể hiệu quả hơn nhiều so với CPFP truyền thống vì giao dịch cấp vốn có thể khai báo sự phụ thuộc này bằng cách sử dụng ít byte hơn nhiều so với đầu vào giao dịch.

4.3 Tấn công vòng lặp giao dịch thay thế

“Tấn công vòng lặp giao dịch thay thế” ^[14] cố gắng chặn giao dịch L2 mục tiêu bằng một giao dịch thay thế đủ lâu để cho phép khai thác một giao dịch kém tốt hơn. Về cơ bản, đối với kẻ tấn công, tấn công vòng lặp giao dịch thay thế là một giải pháp thay thế cho tấn công ghim giao dịch, vì mục đích của kẻ tấn công là ngăn chặn một giao dịch tốt, trung thực được khai thác đủ lâu. Điều này cho phép một giao dịch không trung thực, ít giá trị hơn bị phát hiện. . Sự khác biệt là cuộc tấn công vòng lặp giao dịch thay thế không thể được kích hoạt một cách ngẫu nhiên.

Một ví dụ điển hình là giao dịch HTLC trong kênh Lightning. Mặc dù người ta có thể coi HTLC như một hợp đồng, nhưng giao dịch sẽ sử dụng nó bằng cách tiết lộ hình ảnh gốc hoặc hết thời gian. Nhưng trên thực tế, do hạn chế của tập lệnh Bitcoin nên cơ hội chi tiêu bằng cách tiết lộ hình ảnh gốc luôn tồn tại. Sau thời gian chờ, một cơ chế chi tiêu hết thời gian bổ sung sẽ được mở ra .

Cuộc tấn công vòng lặp giao dịch thay thế lợi dụng điều này và tiếp tục cố gắng sử dụng giao dịch chi tiêu tiền ảnh sau khi hết thời gian để thay thế giao dịch cố gắng đổi giá trị thông qua cơ chế hết thời gian chờ. Đồng thời, nạn nhân không được thông báo về tiền ảnh. . Một cuộc tấn công vòng lặp giao dịch thay thế thành công kéo dài đủ lâu cho đến khi HTLC ở kênh khác hết thời gian chờ.

Một trong những thách thức trong việc thu lợi nhuận từ chu kỳ giao dịch thay thế là mỗi đợt tấn công đều cần có tiền. Việc triển khai Lightning theo thời hạn sẽ sử dụng mức phí ngày càng cao hơn để cố gắng chi tiêu (đổi) HTLC hiện tại trước khi sản lượng HTLC tiếp theo hết hạn. Thứ hai, khi chu kỳ thay thế kết thúc, bất kỳ ai cũng có thể đánh bại cuộc tấn công này bằng cách phát lại giao dịch được thay thế ^[15] .

Giống như cuộc tấn công đóng đinh, vòng lặp giao dịch thay thế cũng là một vụ nổ kinh tế đối với các thợ mỏ. Vào cuối mỗi chu kỳ, một giao dịch khác sẽ bị xóa khỏi nhóm giao dịch, mặc dù nó hoàn toàn hợp lệ và có thể được khai thác, miễn là người khai thác vẫn giữ nó trong nhóm giao dịch.

5 Chế độ tính năng và Soft Fork

Bây giờ chúng tôi đã cung cấp cái nhìn tổng quan về những thách thức mà các hệ thống L2 và nhóm giao dịch khác nhau dựa trên các điều khoản hạn chế phải đối mặt, tiếp theo chúng tôi muốn trích xuất một loạt các tính năng fork phần mềm nổi tiếng (chủ yếu là các mã hoạt động mới) và các tính năng chung của các hệ thống L2 này Các mẫu thiết kế. Đối với các đề xuất soft fork, chúng tôi cũng thảo luận về các rủi ro kỹ thuật liên quan đến các đề xuất này và những thách thức khi triển khai chúng.

5.1 OP_Expire

Trước tiên hãy nói thẳng điều này. OP_Expire được đề xuất như một cách để loại bỏ trực tiếp các cuộc tấn công vòng lặp giao dịch thay thế ^[16] . Nó đi thẳng vào gốc: HTLC có thể được sử dụng theo hai cách khác nhau cùng một lúc. Trong bối cảnh của hệ thống L2, điều này có liên quan đến tất cả các hệ thống sử dụng HTLC và các cơ chế tương tự cũng như có thể cả các cách sử dụng khác. OP_Expire sẽ làm cho đầu ra giao dịch không còn có thể được chi tiêu sau một thời điểm nhất định, do đó điều kiện chi tiêu của HTLC trở thành OR thực sự độc quyền, không phải là "OR của lập trình viên".

Soft fork OP_Expire thực sự có thể bao gồm hai tính năng, tương tự như OP_CheckLockTimeVerify và OP_CheckSequenceVerify hai bước (Lưu ý của người dịch: Khóa thời gian tuyệt đối và khóa thời gian tương đối ở cấp tập lệnh tương ứng):

1. Trường chiều cao hết hạn của giao dịch rất có thể được triển khai thông qua phụ lục taproot.
2. Mã OP_Expire kiểm tra xem chiều cao hết hạn của giao dịch có thấp hơn chiều cao mục tiêu hay không.

Mặc dù bản thân OP_Expire hầu như không phải là một điều khoản hạn chế, nhưng nó có vẻ hữu ích cho nhiều hệ thống L2 dựa vào các điều khoản hạn chế. Tuy nhiên, các vòng giao dịch thay thế nhất định cũng có thể được giảm thiểu bằng cách phát sóng lại lẫn nhau ^[15] , điều này có thể không đủ hữu ích.

Một thách thức rất rõ ràng trong việc triển khai và sử dụng OP_Expire nằm ở việc tổ chức lại blockchain: trong cộng đồng kỹ thuật Bitcoin, bắt đầu từ cùng một sai lầm ^[17] , họ đã cố gắng đảm bảo rằng giao thức đồng thuận Bitcoin có một đặc điểm như vậy: ngay cả khi điều đó xảy ra Tổ chức lại sâu sắc, các giao dịch đã khai thác trước đó cũng có thể nhập các khối mới. Nguyên tắc thiết kế này cố gắng tránh kịch bản tồi tệ trong đó các UTXO được xác nhận nhiều sẽ trở nên vô hiệu vĩnh viễn chỉ sau một đêm—và những người dựa vào chúng sẽ mất tiền—nếu lỗi đồng thuận gây ra một cuộc tái tổ chức lớn.

Trong trường hợp tổ chức lại quy mô lớn, các giao dịch sử dụng cơ chế hết hạn được mô tả ở trên có thể trở nên không thể khai thác được khi đạt đến mức hết hạn. OP_Expire đề xuất rằng các giao dịch sử dụng cơ chế hết hạn ở trên có thể được coi là giao dịch coinbase, do đó đầu ra của chúng không thể được chi tiêu trong vòng 100 khối, từ đó giảm bớt vấn đề này.

Một gánh nặng đáng kể trong việc triển khai cơ chế hết hạn giao dịch là đạt được sự đồng thuận: liệu sự đánh đổi này có được chấp nhận hay không? Chúng ta thậm chí có cần nó không? Trong các giao dịch mà OP_Expire có thể hoạt động, khóa dài hạn đóng băng tiền của người dùng đã được bao gồm. Việc thêm thời gian chờ dài hơn là không phù hợp. Ngoài ra, sau khi tổ chức lại khối, việc chi tiêu lặp đi lặp lại luôn có thể làm mất hiệu lực một số UTXO nhất định: với sự phổ biến của RBF và sự xuất hiện của "đầu ra neo không cần chìa khóa", liệu cơ chế hết thời gian giao dịch có còn đóng vai trò lớn không?

5.3 SIGHASH_ANYPREVOUT

BIP-118 đề xuất hai chế độ băm chữ ký mới, cả hai chế độ này đều không cam kết sử dụng một UTXO cụ thể. SIGHASH_ANYPREVOUT , (về cơ bản) lần lượt hứa hẹn scriptPubKey (khóa chung của tập lệnh); SIGHASH_ANYPREVOUTANYSCRIPT cho phép bất kỳ tập lệnh nào. Như đã thảo luận trước đó, điều này ban đầu được đề xuất để hỗ trợ LN-Symmetry, nhằm tránh khả năng yêu cầu phản hồi dành riêng cho từng trạng thái kênh đã ký.

SIGHASH_ANYPREVOUT cũng có thể hữu ích khi chúng tôi muốn sử dụng các giao dịch được ký trước với các biến thể phí RBF, vì chữ ký không còn phụ thuộc vào id giao dịch cụ thể, do đó tránh đượcsự bùng nổ tổ hợp của các biến thể phí . Tuy nhiên, BIP-118 hiện tại không chỉ ra trường hợp sử dụng này; nó cũng có thể không tương thích vì SIGHASH_ANYPREVOUT được đề xuất cũng hứa hẹn giá trị của UTXO.

Một phản đối ban đầu đối với SIGHASH_ANYPREVOUT là ví có thể gặp rắc rối do sử dụng không phù hợp. Vấn đề là khi chữ ký SIGHASH_ANYPREVOUT được phát hành, nó có thể được sử dụng để chi tiêu bất kỳ đầu ra giao dịch nào bằng cách sử dụng cùng một tập lệnh. Do đó, SIGHASH_ANYPREVOUT cho phép một cuộc tấn công lặp lại đơn giản có thể dẫn đến đánh cắp tiền bất cứ khi nào đầu ra thứ hai sử dụng cùng một tập lệnh được vô tình tạo ra. Tuy nhiên, mối lo ngại này dường như đã giảm bớt vì có nhiều lĩnh vực mà việc triển khai ví và L2 có thể tự bắn vào chân mình.

Tại thời điểm này, cộng đồng kỹ thuật rộng rãi dường như khá lạc quan về việc triển khai BIP-118. Tuy nhiên, như chúng tôi đã nói khi thảo luận về LN-Symmetry, mọi người cũng đang tranh luận xem liệu kịch bản ứng dụng chính của nó - LN-Symmetry - có phải là một ý tưởng hay hay không.

5.3 OP_CheckTemplateVerify

Đề xuất đầu tiên chúng ta sẽ thảo luận cụ thể về các ràng buộc là OP_CheckTemplateVerify , thường được gọi là "CTV", tập trung vào việc tạo một opcode ràng buộc hạn chế, rất cụ thể, chỉ thực hiện một việc: Băm một giao dịch chi tiêu không chứa UTXO đầu vào cụ thể theo một cách cụ thể, sau đó kiểm tra xem liệu bản tóm tắt băm thu được có bằng phần tử ở đầu ngăn xếp tập lệnh hay không. Điều này cho phép chúng ta hạn chế trước các giao dịch chi tiêu trên một đầu ra mà không tạo ra các ràng buộc đệ quy thực sự.

Tại sao CTV không thể thực hiện các ràng buộc đệ quy? Bởi vì hàm băm: CTV sử dụng giá trị băm mẫu để kiểm tra giao dịch chi tiêu nên không có cách nào ^[18] để tạo một mẫu có thể chứa CTV và giá trị băm của chính nó.

Một lần nữa, đây không hẳn là một hạn chế thực sự: trên các máy tính mới nhất, bạn có thể dễ dàng băm chuỗi mẫu CTV hàng chục triệu giao dịch chỉ trong vài giây. Khóa thời gian tương đối và không gian khối hạn chế của nSeuqunce sẽ cho phép chuỗi này dễ dàng khóa một khoản tiền trong hàng nghìn năm.

Đề xuất CTV hiện tại trong BIP-119 chỉ có một chế độ băm được gọi là DefaultCheckTemplateVerifyHash , về cơ bản cam kết mọi khía cạnh của giao dịch chi tiêu trong hàm băm mẫu. Từ góc độ thực tế, điều này có nghĩa là, trong nhiều trường hợp, CPFP sẽ là phương tiện thanh toán phí duy nhất. Như đã đề cập trước đó, đây có thể là một vấn đề vì nó khiến thanh toán hộp đen trở thành một phương tiện tiết kiệm chi phí đáng kể khi khối lượng giao dịch sử dụng CTV nhỏ hơn.

Công bằng mà nói, CTV cũng nhận được sự ủng hộ rộng rãi trong cộng đồng kỹ thuật xung quanh đề xuất opcode mệnh đề hạn chế vì tính đơn giản và tính linh hoạt tương đối của nó.

5.3.1 LNHANCE

Một đề xuất để triển khai CTV là kết hợp nó với hai opcode bổ sung OP_CheckSigFromStack(Verify) và OP_InternalKey . Vấn đề là, tính đến thời điểm viết bài này, không có đủ tài liệu trong PR và BIP liên quan để hỗ trợ hoặc từ chối đề xuất này. BIP liên quan thiếu bất kỳ phân tích nào, chưa nói đến các kịch bản trường hợp chuyên sâu, về các trường hợp thực tế mà các opcode này dự kiến sẽ hoạt động.

Mặc dù các tác giả của đề xuất này có thể có những lý do chính đáng nhưng họ có trách nhiệm giải thích những lý do đó và đưa ra lời biện minh phù hợp. Vì vậy, chúng tôi sẽ không thảo luận thêm về nó.

5.4 OP_TXHASH

Tương tự như CTV, đề xuất này thực hiện chức năng ràng buộc không đệ quy bằng cách băm dữ liệu từ các giao dịch chi tiêu. Không giống như CTV, đề xuất TXHASH cung cấp cơ chế “chọn trường” cho phép linh hoạt trong việc hạn chế chi tiêu. Tính linh hoạt này đạt được hai mục tiêu chính:

1. Cho phép thêm phí vào các giao dịch mà không vi phạm giao thức xếp tầng nhiều giao dịch.
2. Giao thức nhiều người dùng có thể cho phép người dùng chỉ giới hạn đầu vào và đầu ra cho chính họ.

Vấn đề chính với OP_TXHASH là cơ chế chọn trường cũng có nhiều sự phức tạp, khiến việc xem xét và kiểm tra khó khăn hơn (so với đề xuất CTV đơn giản hơn nhiều). Tính đến thời điểm viết bài này, thậm chí còn chưa có một bản phân tích thiết kế nào về những lợi ích mà cơ chế chọn trường có thể mang lại và cách sử dụng nó. Vì vậy chúng ta sẽ không thảo luận về nó nữa.

5.5 OP_CAT

Đây là một opcode ghép nối hai phần tử ở đầu ngăn xếp và sau đó đẩy kết quả trở lại ngăn xếp. Khi Bitcoin được phát hành lần đầu tiên, OP_CAT đã được kích hoạt. Nhưng Satoshi Nakamoto đã lặng lẽ loại bỏ nó vào năm 2010 vì việc triển khai ban đầu thiếu giới hạn kích thước đối với phần tử kết quả và dễ bị tấn công DoS. Hãy xem một kịch bản như thế này:

 DUP CAT DUP CAT...

Nếu không có giới hạn về kích thước của phần tử ngăn xếp, mỗi lần lặp của DUP CAT sẽ tăng gấp đôi kích thước của phần tử trên cùng của ngăn xếp, cuối cùng sử dụng hết bộ nhớ.

Việc ghép nối là đủ để thực hiện nhiều loại ràng buộc, bao gồm cả các ràng buộc đệ quy, bằng cách:

1. Trong ngăn xếp, sử dụng một hoặc nhiều thiết bị OP_CAT (và bất kỳ logic cụ thể nào được yêu cầu) để tập hợp một giao dịch bị hỏng mà không có dữ liệu chứng kiến .
2. Xác minh trong ngăn xếp rằng giao dịch được tập hợp khớp với giao dịch chi tiêu.

Hóa ra là bằng cách lạm dụng toán học của chữ ký Schnorr , có thể thực hiện bước thứ hai ở trên trong OP_CheckSig với chữ ký được xây dựng cẩn thận. Tuy nhiên, nhiều khả năng soft fork OP_CAT sẽ được kết hợp với OP_CheckSigFromStack , cho phép thực hiện bước thứ hai ở trên bằng cách xác minh rằng chữ ký trong ngăn xếp là chữ ký hợp lệ cho một giao dịch mục tiêu nhất định ^[19] và sau đó Sử dụng OP_CheckSig cho cùng một chữ ký để xác minh rằng giao dịch chi tiêu phù hợp với giao dịch mục tiêu ^[20] .

Việc chúng ta chỉ cần tập hợp các giao dịch mà không có dữ liệu nhân chứng là điểm mấu chốt: ràng buộc chỉ cần xác minh xem giao dịch thực hiện những gì - đầu vào và đầu ra của nó - chứ không phải liệu dữ liệu nhân chứng (nếu có) có thể giúp hoạt động này hiệu quả hay không.

Giới hạn kích thước tập lệnh Modulo, kết hợp với OP_CAT và OP_CheckSigFromStack , là đủ để phát triển nhiều loại ràng buộc, bao gồm cả các ràng buộc đệ quy. Điều này sẽ đắt hơn các giải pháp hiệu quả hơn như CTV. Nhưng sự khác biệt về giá sẽ nhỏ hơn bạn nghĩ!

Nói một cách đại khái, bằng cách sử dụng OP_CAT , bạn sẽ cần đặt tất cả các phần dữ liệu không phải nhân chứng của giao dịch đã chi tiêu vào ngăn xếp thông qua dữ liệu nhân chứng. Đối với các kịch bản ứng dụng CTV tiêu chuẩn, chẳng hạn như cây đầu ra giao dịch, giao dịch chi tiêu hoàn toàn không có dữ liệu chứng kiến. Tuy nhiên, do dữ liệu nhân chứng có thể được chiết khấu 75% nên phí giao dịch thực tế của giao dịch phụ chỉ cao hơn 25%. không tệ!

5.5.1 OP_CAT có quá mạnh không?

Đây có lẽ là sự phản kháng lớn nhất về mặt chính trị và kỹ thuật đối với việc triển khai OP_CAT : thật khó để dự đoán việc sử dụng OP_CAT sẽ mang lại điều gì. Một khi con mèo đã ra khỏi chuồng, việc lấy lại nó không phải là điều dễ dàng.

Một ví dụ điển hình là tuyên bố rằng chỉ cần OP_CAT là cần thiết để đạt được xác minh STARK (Đại diện kiến thức minh bạch có thể mở rộng) khá hiệu quả và an toàn trong các tập lệnh Bitcoin . Vì STARK có thể chứng minh phạm vi tuyên bố khá rộng nên việc triển khai STARK hiệu quả sẽ có tác động rất lớn và không chỉ ảnh hưởng đến các hệ thống L2 mà còn cho phép nhiều hệ thống khác nhau được xây dựng trên Bitcoin. Phản đối mạnh mẽ một điều: những cách sử dụng này có thể không tốt cho tất cả người dùng Bitcoin.

Việc tạo ra “Giá trị có thể trích xuất (MEV) của máy khai thác (MEV) có hại, gây ra sự tập trung”, được Matt Corallo mệnh danh là “ Evil MEV (MEVil) ”, là một vấn đề tiềm ẩn chính ( bản dịch tiếng Trung Quốc ). Tóm lại, MEVil là tình huống mà những người khai thác lớn/nhóm khai thác lớn có thể kiếm thêm thu nhập - không chỉ nhiều phí - bằng cách sử dụng các chiến lược khai thác giao dịch phức tạp, trong khi những người khai thác nhỏ gặp khó khăn khi áp dụng các chiến lược này. Sự phức tạp của các công cụ tài chính mà OP_CAT có thể tạo ra sẽ khiến MEVil khó bị loại bỏ. Trên Bitcoin, MEVil quan trọng đã xuất hiện kể từ khi giao thức đấu giá mã thông báo xuất hiện, may mắn thay, vấn đề này đã được giải quyết với việc áp dụng RBF đầy đủ.

Ngoài MEVil tiềm năng, còn có một số cách sử dụng OP_CAT khác có thể gây hại. Ví dụ: đề xuất Drivechain mà chúng tôi đã xem xét trước đây được nhiều người coi là có hại cho Bitcoin. Một số người nghĩ rằng Drivechain có thể được triển khai bằng OP_CAT . Một ví dụ khác là giao thức mã thông báo như Taproot Assets. Mặc dù về cơ bản không có gì ngăn cản việc sử dụng khái niệm " xác thực phía máy khách " để triển khai chúng, nhưng cũng có những đề xuất triển khai chúng bằng cách sử dụng OP_CAT , điều này có thể hấp dẫn hơn đối với người dùng cuối, nhưng điều này có thể sử dụng nhiều không gian khối hơn, có thể sẽ thu hút nhiều người dùng ra các giao dịch Bitcoin "chính thống". Việc sử dụng này có thể gây ra các vấn đề pháp lý, tùy thuộc vào tần suất sử dụng các giao thức mã thông báo này trong gian lận tài chính.

5.6 Băm lũy tiến

Trong triển khai ràng buộc, công dụng chính của OP_CAT là ghép dữ liệu và sau đó băm chúng. Một cách khác để đạt được mục tiêu tương tự là sử dụng một số loại mã băm tăng dần, lấy một số trạng thái trung gian của thao tác SHA256 và sau đó băm thêm dữ liệu; bản thân SHA256 có kích thước 64 byte. Hoạt động trên các khối dữ liệu. Có rất nhiều thiết kế khả thi cho các mã băm lũy tiến.

Một lựa chọn thiết kế quan trọng là sử dụng một số dạng chuẩn khi hiển thị các byte trạng thái trung gian thực tế trên ngăn xếp hay biểu diễn chúng bằng một số loại mờ (để các giá trị byte thực tế không thể hoạt động trực tiếp). SHA256 được gán một vectơ khởi tạo cố định, cụ thể. Nếu có thể sử dụng bất kỳ vectơ khởi tạo/trạng thái trung gian nào thì không chắc liệu các thuộc tính mật mã của SHA256 có còn được bảo tồn hay không.

Tất nhiên, vì băm lũy tiến có thể làm được nhiều việc mà OP_CAT có thể làm, nhưng hiệu quả hơn nên nó cũng phải đối mặt với mối lo ngại tương tự: nó quá mạnh.

5.7 Hồi sinh tập lệnh

OP_CAT là một trong 15 opcode bị Satoshi Nakamoto cấm. Ngoài việc khôi phục OP_CAT , Rusty Russell đang đề xuất ^[21] khôi phục khả năng viết kịch bản của Bitcoin bằng cách khởi động lại hầu hết các opcode này và thêm các hạn chế DoS (và có thể thêm một vài opcode mới trong cùng một fork mềm) Trở thành "Phiên bản đầu tiên của Satoshi Nakamoto". Cụ thể, OP_CheckSigFromStack có thể được thêm vào.

Mặc dù bản thân OP_CAT đã tạo ra các ràng buộc (đệ quy), nhưng việc "hồi sinh tập lệnh" đầy đủ sẽ tạo ra các ràng buộc phức tạp hơn - và dễ thực hiện hơn nhiều - vì giao dịch chi tiêu có thể được thao tác trực tiếp ở một số phần nhất định. Ví dụ: bạn có thể viết một tập lệnh ràng buộc sử dụng các mã số học để đảm bảo rằng tổng giá trị đầu ra của giao dịch duy trì một số thuộc tính thú vị.

Ngoài ra, Script Revival còn gặp phải mối lo ngại tương tự như OP_CAT , nếu không muốn nói là nhiều hơn, vì nó mạnh hơn OP_CAT .

5.7.1 Tính đơn giản

Tương tự như thời kỳ phục hưng của tập lệnh, Sự đơn giản có liên quan đến L2 và các ràng buộc vì nó có thể làm được mọi thứ. Không giống như thời kỳ phục hưng của tập lệnh, soft fork Simplicity có thể thêm một ngôn ngữ lập trình mới vào hệ thống tập lệnh của Bitcoin, dựa trên 9 mã opcode nguyên thủy được gọi là "bộ kết hợp".

Thực ra, Simplicity vừa quá đơn giản lại vừa không hề đơn giản chút nào. Mã kết hợp ở mức quá thấp, do đó ngay cả các thao tác cơ bản như phép cộng cũng phải được thực hiện từ đầu; mã Đơn giản đơn giản sẽ quá cồng kềnh trong thực tế. Do đó, bất kỳ việc sử dụng Simplicity thực sự nào cũng sẽ tận dụng được hệ thống thay thế mã, tương tự như các lệnh gọi hàm thư viện, được gọi là " jet ". Điều này trở thành một câu hỏi thực tế/chính trị: làm thế nào để quyết định triển khai loại máy bay phản lực nào? Có khả năng các máy bay phản lực sẽ được triển khai trong C++, giống như các opcode khác, do đó mỗi lần bổ sung một máy bay phản lực mới sẽ yêu cầu một nhánh mềm.

5.8 OP_FancyTreeManipulationStuff

Một số opcode tương đối chuyên biệt cũng đã được đề xuất để thao tác các cấu trúc cây theo cách tiết kiệm không gian hơn để sử dụng bởi các hệ thống L2 dựa trên các ràng buộc. Ví dụ: đề xuất Coinpool đã đề xuất TAPLEAF_UPDATE_VERIFY và OP_MERKLESUB . Cả hai opcode đều hoạt động trên cây tập lệnh taproot và cần thiết cho đề xuất Coinpool. Về cơ bản, MATT cũng đề xuất opcode OP_CheckContractVerify .

Vì mục đích của bài viết này, chúng ta không cần đi sâu vào chi tiết của từng đề xuất này. Thay vào đó, chúng ta có thể coi tất cả chúng như một lớp: chúng đều là các giao thức tương đối chuyên biệt được thiết kế để tạo ra một lớp L2 và hy vọng không có tác dụng phụ ngoài ý muốn. Cả hai đều có ưu điểm là hiệu quả: cả hai đều sử dụng ít không gian khối hơn để đạt được cùng một mục tiêu so với việc sử dụng các opcode chung hơn (chẳng hạn như thao tác OP_CAT ). nhưng họ