Ví trên chuỗi chính xác đạt tỷ lệ gần 1-1 của giao dịch đến giao dịch: đối với mỗi giao dịch kinh tế mà người dùng thực hiện, đều cần khoảng một giao dịch chuỗi khối. Tích hợp, coinjoin, thanh toán cắt qua, v.v. làm thay đổi một chút tuyên bố này. Nhưng nó gần đúng.

Lightning đã đạt được ánh xạ nhiều giao dịch với các giao dịch: điều kỳ diệu của Lightning là số lượng giao dịch kinh tế vô hạn hiệu quả có thể xảy ra trong một kênh Chiếu sáng duy nhất, bản thân nó được gắn với một đầu ra giao dịch chưa sử dụng (UTXO). Về cơ bản, chúng tôi đã thực hiện khía cạnh "thời gian" - giao dịch - và đạt được một quy mô đáng kể bằng cách thu gọn chiều đó.

Nhưng việc tạo ra ngay cả một UTXO duy nhất cho mỗi người dùng, được cho là, không đủ tốt. Vì vậy, có rất nhiều đề xuất để đạt được quy mô lớn hơn nữa bằng cách cho phép nhiều người dùng chia sẻ một UTXO duy nhất theo cách tự chủ. Một lần nữa, thu gọn một khía cạnh "không gian" khác của việc mở rộng quy mô - người dùng - thành một UTXO.

Mục tiêu của chúng tôi ở đây là tổng quan về tất cả những đề xuất này, tìm hiểu những mẫu kỹ thuật chung của chúng, tìm hiểu những loại opcode mới và những nâng cấp soft fork khác mà chúng cần để hoạt động, và tạo ra một bảng so sánh về cách tất cả các phần ghép lại với nhau. Trong quá trình này, chúng ta cũng sẽ xác định thực sự một giao thức L2 là gì, loại co giãn nhanh Lightning đã có thể thực hiện, và hiểu được những cải tiến cần thiết cho mempools để đạt được tất cả điều này.

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

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

Định nghĩa

Layer 2 là gì?

Thường xuyên thuật ngữ “Layer 2” được định nghĩa một cách rộng rãi, đến mức mà thậm chí một thực thể giống ngân hàng (ví dụ: Liquid) cũng có thể được định nghĩa là một Layer 2. Vì mục đích của bài viết này, chúng tôi sẽ áp dụng một định nghĩa nghiêm ngặt: Layer 2 (L2) là một hệ thống được định giá theo Bitcoin, với mục đích cho phép BTC được giao dịch thường xuyên hơn số lượng giao dịch trên chuỗi với các bên khác. Điều này có nghĩa là:

1. Không ai có thể lợi nhuận khi đánh cắp tiền trong hệ thống, xem xét các hình phạt và chi phí trong hệ thống. Chi phí và hình phạt ngoài hệ thống như mất uy tín, 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. (Ưu tiên) Những chủ sở hữu thực sự của quỹ có thể rút quỹ của họ một cách đơn phương, 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.

Tùy chọn đầu tiên là bắt buộc vì chúng tôi muốn các hệ thống L2 của chúng tôi có thể đại diện cho số tiền và giao dịch có giá trị nhỏ đến mức chúng không thể được biểu diễn trên chuỗi. Ví dụ: trong Lightning, HTLC có thể có giá trị quá nhỏ để đại diện cho on-chain. Trong trường hợp đó, giá trị HTLC được cộng vào phí giao dịch của giao dịch cam kết. Mặc dù nút Lightning có thể "đánh cắp" bụi HTLC bằng cách đóng kênh vào đúng thời điểm, nhưng làm như vậy sẽ tốn kém hơn¹thì việc ăn cắp sẽ không sinh lời nếu giá trị của HTLC thấp hơn.

Tuy nhiên, việc rút khỏi đơn phương luôn là mục tiêu thiết kế chính của chúng tôi.²

Theo định nghĩa này, các hệ thống như Lightning được coi là hệ thống L2. Tuy nhiên, các hệ thống như Liquid, Cashu và Fedimint không phải là L2, vì một bên hoặc nhiều bên khác có quyền kiểm soát quỹ của bạn. Các hệ thống xác thực phía máy khách như RGB cũng không phải L2 theo định nghĩa này, vì chúng không thể giao dịch BTC một cách tin cậy. Cuối cùng,@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains không đạt được tiêu chuẩn, vì thực thể Statechain có thể đánh cắp các quỹ nếu họ không tuân thủ giao thức.

Covenants là gì?

...và tại sao hệ thống L2 có khả năng mở rộng hơn cần chúng?

Trong việc viết kịch bản Bitcoin, các hiệp ước là cơ chế thông qua đó cách mà một txout có thể được tiêu thụ được hạn chế trước, sao cho hình thức giao dịch được sử dụng để tiêu thụ txout đó được xác định trước hoặc được hạn chế theo cách không chỉ giới hạn duy nhất là chữ ký. Các hệ thống L2 chia sẻ UTXO giữa nhiều bên cần các hiệp ước vì họ cần cách hạn chế cách UTXO có thể được tiêu thụ để triển khai các quy tắc và động lực của giao thức L2.

Recursive Covenants

Một ước nguyện đệ quy là một ước nguyện có đặc tính rằng các quy tắc hạn chế cách mà một UTXO có thể được tiêu tốn có thể được áp dụng một cách đệ quy, đến các UTXO con của giao dịch tiêu tốn một cách vô hạn. Ước nguyện đệ quy có đã được coi là không mong muốn bởi một số ngườibởi vì họ có thể gắn kết tiền mãi mãi. Hoặc ít nhất là mãi mãi mà không cần sự cho phép của một bên thứ ba như chính phủ.

Mục tiêu

Lightning là hệ thống Layer 2 hiện tại "tốt nhất trong lớp". Tuy nhiên, nó có những hạn chế. Cụ thể là:

1. Mở rộng - Lightning hiện tại yêu cầu ít nhất một UTXO cho mỗi người dùng cuối cùng.³
2. Sự thanh khoản - Lightning yêu cầu các khoản tiền phải được ràng buộc trong các kênh.
3. Tương tác - Lightning yêu cầu người nhận thanh toán phải trực tuyến để nhận chúng một cách không đáng tin cậy.

Khi đánh giá hệ thống Layer 2, mục tiêu của chúng tôi sẽ là cải thiện những hạn chế quan trọng này, lý tưởng là không thêm hạn chế mới.

Giới hạn về quy mô của Lightning

Trong thực tế, “một UTXO cho mỗi người dùng cuối cùng” có nghĩa là gì? Kênh Lightning có thể hoạt động vô thời hạn, một cách nhìn khác về vấn đề này là hỏi có bao nhiêu kênh mới có thể được tạo ra mỗi năm⁴Tạo ra đầu ra taproot có chi phí nhỏ hơn 43vB; nếu việc tạo kênh được phân bổ, với nhiều kênh được tạo trong một giao dịch duy nhất, các chi phí giao dịch khác có thể trở nên không đáng kể và một số lượng lớn kênh có thể được mở mỗi năm để on-board người dùng mới. Ví dụ, giả sử rằng 90% dung lượng khối được dành cho mở các kênh Lightning taproot mới:

Được ước tính rằng Khoảng một nửa dân số toàn cầu sở hữu một điện thoại thông minh, 4,3 tỷ người. Vì vậy, thực tế là chúng ta có thể tiếp nhận một phần trăm đáng kể của toàn bộ dân số có khả năng sử dụng một kênh Lightning mỗi năm.

Tuy nhiên, các kênh không tồn tại mãi mãi. Đôi khi người dùng sẽ muốn chuyển ví, tăng hoặc giảm khả năng kênh, v.v. Phương pháp hiệu quả nhất để thay đổi khả năng của một kênh là thông qua nối, đặc biệt được triển khai trong Ví Phoenix.

Như kênh mở, việc nối cũng có thể được thực hiện theo cách trả góp để cải thiện hiệu suất, với nhiều hoạt động nối chia sẻ một giao dịch duy nhất để giảm số lượng đầu vào và đầu ra cần thiết để thêm và loại bỏ tiền⁵. Do đó, không gian khối delta cần thiết cho mỗi người dùng, giả sử sử dụng musig, là đầu ra taproot 43vB cộng thêm

57.5vB taproot keypath spend, tổng cộng là 100.5vB. Nếu chúng ta lại giả sử sử dụng 90% không gian khối, chúng ta sẽ có:

Cuối cùng, lưu ý cách chuyển đổi kênh Lightning giữa các ví có thể được thực hiện trong một giao dịch duy nhất bằng cách tin tưởng ví tiếp theo ký giao dịch cam kết sau khi tiền đã được gửi đến địa chỉ cam kết hoặc với sự hỗ trợ kênh gần với kênh mới hợp tác trong cả hai lần triển khai ví.

Tất nhiên, có những trường hợp sử dụng cạnh tranh cho Bitcoin vượt qua các kênh Lightning, và cách mà điều đó sẽ dịch thành tỷ lệ phí là khó để biết. Nhưng những con số này cho chúng ta một sự ước lượng xấp xỉ cho thấy với công nghệ hiện tại, ít nhất là có thể hỗ trợ hàng trăm triệu người dùng tự chủ của Lightning.

Tổng quan về Layer 2

Theo định nghĩa của chúng tôi về hệ thống L2, có hai mô hình thiết kế chính được thảo luận trong cộng đồng phát triển Bitcoin:

1. Kênh
2. Virtual UTXOs

Trong mô hình kênh, trong đó Lightning là ví dụ chính, giao thức tiến bộ bằng cách trao đổi giao dịch được ký trước giữa các bên có thể được khai thác, nhưng không nằm trong "đường dẫn hạnh phúc". Những giao dịch được ký trước này chia một UTXO giữa các bên; các giao dịch xảy ra bằng cách thay đổi cân bằng của phần chia đó, với các giao dịch được ký trước mới. Vì sẽ có nhiều giao dịch hợp lệ khác nhau có thể chi tiêu cùng một UTXO, nên cần có cơ chế khuyến khích để đảm bảo giao dịch chính xác là giao dịch thực sự được khai thác.

Trong mô hình thiết kế Virtual UTXO (V-UTXO), trong đó Ark là ví dụ nổi bật nhất, V-UTXOs được tạo ra thông qua các giao ước hoặc thỏa thuận nhiều bên, thông qua việc tạo ra các giao dịch có thể được khai thác để đơn phương rút tiền V-UTXO bằng cách đưa chúng vào chuỗi, nhưng không nằm trong "con đường hạnh phúc". Về mặt đó, V-UTXO tương tự như các kênh. Nhưng không giống như các kênh, các chương trình V-UTXO thực hiện các giao dịch bằng cách chi tiêu các V-UTXO, trong (về mặt khái niệm) một duy nhất⁶giao dịch được ký trước.

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

Thật thú vị, vì các UTXO ảo là "thực" theo nhiều nghĩa, nên khá dễ dàng để xây dựng các kênh trên các UTXO ảo bằng cách tạo các UTXO ảo, nếu được khai thác, sẽ dẫn đến việc tạo ra các UTXO cần thiết cho các kênh. Theo nghĩa đó, các lược đồ UTXO ảo là một

lớp thấp hơn một chút so với kênh.

Lightning

Tình trạng hiện tại, được triển khai trong sản xuất như Mạng Lightning, chủ yếu dựa trên Tiêu chuẩn của BOLT. Lightning là sự kết hợp của nhiều yếu tố, bao gồm các kênh Lightning và HTLCs, mạng định tuyến P2P, định tuyến hành tinh, tiêu chuẩn hóa hóa đơn, v.v. Đáng chú ý, Lightning không phải là một hệ thống đồng thuận, vì vậy các yếu tố khác nhau của 'hệ thống Lightning' không cần phải được áp dụng theo cách tương tự bởi tất cả người dùng. Với mục đích của bài viết này, khi chúng ta nói về 'Lightning', chúng tôi sẽ sử dụng nó theo nghĩa rộng, bao gồm các nâng cấp dễ dự đoán cho giao thức Lightning hiện tại (phổ biến) mà được sử dụng rộng rãi.

Như đã thảo luận ở trên, đặc điểm chính của Lightning là giới hạn khả năng mở rộng cuối người dùng, do cần có ít nhất một UTXO cho mỗi người dùng. Tuy nhiên, đối với yếu tố định tuyến “core” của Lightning - các nút Lightning công cộng định tuyến đa số các giao dịch - những giới hạn khả năng mở rộng này không quá đáng lo ngại vì Lightning vẫn hoạt động tốt nếu có nhiều người dùng cuối hơn nhiều so với các nút định tuyến, bởi mỗi kênh công cộng được sử dụng cho định tuyến thanh toán có thể dễ dàng hỗ trợ một số lượng lớn giao dịch mỗi giây. Đây cũng là lý do tại sao nhiều hệ thống L2 trong tương lai dự kiến ​​cũng tham gia vào mạng Lightning. Chúng ta cũng thấy điều này trong cách các hệ thống không hoàn toàn L2 hiện có như Cashu phụ thuộc mạnh vào mạng Lightning để thực sự hữu ích: việc sử dụng chính của Cashu có lẽ là gửi và nhận thanh toán Lightning.

Kênh Non-Interactive

Cấu trúc này cải tiến kênh Lightning bằng cách sử dụng OP_CTV để giảm yêu cầu tương tác. Tuy nhiên, vì nó không cải thiện giới hạn tỷ lệ 1-UTXO-per người dùng, chúng tôi sẽ không tiếp tục thảo luận về nó.

Nhà máy Kênh

Ở đây, chúng ta có nhiều bên đàm phán với địa chỉ n-of-n multisig duy nhất, cùng với giao dịch chi tiêu địa chỉ multisig đó để tạo ra n UTXO khác nhau chia nhỏ số tiền. Những UTXO đó sau đó được sử dụng cho các kênh thanh toán. Các kênh này có thể được sử dụng với cùng mức độ bảo mật như khi chúng được mở trực tiếp trên chuỗi, bởi vì trong trường hợp trạng thái kênh cần được đưa lên chuỗi, giao dịch chia nhỏ có thể được khai thác. Điều này tiềm năng giúp tiết kiệm không gian trên chuỗi khi các kênh được đóng lại, vì các bên có thể — trong lý thuyết — đồng ý đóng tất cả các kênh nn cùng một lúc.

Vì các nhà máy kênh đang thương lượng UTXO có thể được khai thác, nhưng không dự kiến sẽ thực sự được khai thác theo con đường hạnh phúc, chúng là một ví dụ rất nguyên thủy về V-UTXOs.

Bản thân các nhà máy kênh không yêu cầu bất kỳ phuộc mềm nào để có thể. Tuy nhiên, các nhà máy kênh đơn giản được mô tả ở trên có lẽ không thực tế ngoài số lượng nhỏ các bên do sự phối hợp cần thiết để thực sự đạt được lợi ích mở rộng. Do đó, các đề xuất giao ước như OP_Evicthoặc CTV (qua cây txout) nhằm mục tiêu cho phép kết quả cụ thể hơn trong đó các bên có thể bị buộc phải sử dụng on-chain, mà không cần phải buộc tất cả mọi người phải sử dụng on-chain cùng một lúc.

Eltoo/LN-Symmetry

Vì Eltoo là một cái tên rất khó hiểu, chúng tôi sẽ chỉ sử dụng tên cập nhật LN-Symmetry trong tương lai.

Trong khi các kênh Poon-Dryja khuyến khích trạng thái chính xác được xuất bản trên chuỗi bằng cách trừng phạt các trạng thái không chính xác, LN-Symmetry thay vào đó cho phép các trạng thái không chính xác được cập nhật với một giao dịch bổ sung. Điều này có lợi thế là đơn giản hóa các kênh Lightning bằng cách loại bỏ sự phức tạp của các hình phạt. Tuy nhiên, đây có thể là một bất lợi trong các tình huố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 gian lận.

LN-Symmetry cần một soft-fork để kích hoạtSIGHASH_ANYPREVOUT, điều này cần thiết để cho phép giao dịch trạng thái chi tiêu lại các giao dịch trạng thái khác trong quá trình cập nhật.

Một mình, LN-Symmetry không cung cấp bất kỳ cải tiến nào về quy mô trên các kênh Lightning thông thường. Nhưng những người ủng hộ đã lập luậnđiều này làm cho việc triển khai các nhà máy kênh dễ dàng hơn.

Ark

Ark tiến xa hơn trong việc tăng tỷ lệ giao dịch: hoàn toàn chuyển đổi được UTXOs ảo có thể được gộp và tách ra thành từng phần⁷ Giao dịch ngoài chuỗi. Trong Ark, một điều phối viên trung tâm, Nhà cung cấp dịch vụ Ark (ASP), cung cấp V-UTXOs cho người dùng với thời gian xác định, ví dụ: 4 tuần. Những khoảng thời gian này được gọi là vòng. Các V-UTXO này được tạo ra thông qua các txouts nhóm, mỗi vòng một vòng, thông qua một số loại cơ chế như CTV để cho phép một txout trên chuỗi duy nhất cam kết với một cây V-UTXO. Hết hạn vòng là cách Ark đạt được lợi thế mở rộng: vào cuối vòng, nhóm txout mở khóa, cho phép ASP đơn phương chi tiêu nó với một chữ ký duy nhất trong một giao dịch nhỏ. Do thời gian hết hạn vòng, bản thân V-UTXOs sẽ hết hạn khi nhóm tạo ra chúng hết hạn: người dùng sở hữu V-UTXO phải chi tiêu V-UTXO đó trước khi đạt đến thời gian hết hạn của pool txout hoặc đặt nó vào chuỗi (rút tiền đơn phương).

Để giao dịch V-UTXO giữa các bên, điều phối viên Ark đồng ký các giao dịch chi tiêu một hoặc nhiều V-UTXO, sao cho các giao dịch chỉ hợp lệ 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ẩn thận - xem tài liệu Ark để biết chi tiết đầy đủ - sự phụ thuộc này là điều khiến việc chi tiêu của V-UTXO trở nên đáng tin cậy: V-UTXO không thể được yêu cầu trên chuỗi trừ khi V-UTXO mới được tạo trong một giao dịch nhóm khác. Có một vài cách tiềm năng để thực sự thực hiện sự phụ thuộc đó. 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 cụ thể sẽ có nhiều vòng hoạt động khác nhau diễn ra cùng một lúc. Các vòng mới thường được tạo ra để cho phép chuyển tiền từ các vòng hiện có. Nhưng các vòng hiện có trùng với các vòng mới, vì chúng sẽ thường hết hạn sau một thời gian sau các vòng mới và các txouts mới của hồ sơ được tạo ra.

Kinh tế Ark

Khi một V-UTXO được tiêu, ASP phải cung cấp BTC phù hợp trong một giao dịch hồ bơi mới đại diện cho một vòng mới. Nhưng họ không thể thu hồi giá trị của V-UTXO đã tiêu cho đến khi vòng hết hạn. Do đó, kinh tế của việc tiêu V-UTXO có một chi phí thời gian-giá trị tiền, do tính thanh khoản mà ASP phải cung cấp.

Cụ thể, chi phí phát sinh khi V-UTXO được chi tiêu. Trong khi V-UTXO không được chi tiêu, 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 để rút tiền một mình; người dùng sở hữu khoản tiền đó. Tuy nhiên, để tiêu V-UTXO, ASP phải tạo ra một txout pool mới, sử dụng các khoản tiền ASP thu được từ nơi khác, trong khi các khoản tiền trong V-UTXO bị chi tiêu không có sẵn cho ASP cho đến khi thời gian hết hạn đến.

Do đó, việc tiêu tiền của một V-UTXO đòi hỏi một khoản vay ngắn hạn, mượn tiền để đảm bảo khoảng thời gian từ bây giờ đến khi vòng kết thúc. Điều này có nghĩa là chi phí thanh khoản để tiêu tiền của một V-UTXO thực tế giảm đi khi V-UTXO càng cũ hơn và thời gian hết hạn càng gần, cuối cùng - trong lý thuyết - đạt đến số không khi vòng kết thúc cuối cùng.

Cuối cùng, hãy nhớ rằng chi phí để tiêu một V-UTXO liên quan đến tổng kích thước của V-UTXO đã tiêu. Không phải số tiền trả cho người nhận. Điều này có nghĩa là những ví tiền dành cho giao dịch V-UTXOs trực tiếp (so với việc quản lý một V-UTXO cho mục đích, ví dụ như một kênh Lighting dựa trên V-UTXO) phải đưa ra sự thỏa thuận về cách chia quỹ thành V-UTXOs. Một V-UTXO duy nhất giảm thiểu chi phí rút tiền đơn phương, đồng thời tối đa hóa phí giao dịch dựa trên tính thanh khoản; chia quỹ thành nhiều V-UTXOs làm ngược lại. Điều này hoàn toàn không giống với kinh tế của Bitcoin trên chuỗi hoặc giao dịch Lightning.

Chi phí thanh khoản này là gì? Khi viết bài này, ví Lightning Phoenix tính 1% phí để giữ thanh khoản kênh trong 1 năm; trong tình huống xấu nhất, Phoenix sẽ phải ràng buộc tài chính của họ trong 1 năm. Tuy nhiên, điều này giả định rằng thanh khoản không được sử dụng. Có khả năng rằng chi phí vốn cho Phoenix thực tế cao hơn, và họ giả định rằng khách hàng trung bình sử dụng thanh khoản đến từ Phoenix trong thời gian ít hơn một năm. Phoenix cũng kiếm tiền từ phí giao dịch, có thể trợ cấp thanh khoản kênh. Cuối cùng, Phoenix có thể không có lợi nhuận!

Tỷ lệ trái phiếu kho bạc Mỹ cung cấp cho chúng ta một ước tính khác. Hiện tại, Tỷ lệ trái phiếu kho bạc Mỹ 3 tháng là khoảng 5% mỗi năm. Vì có một lập luận rằng tỷ lệ này bị thổi phồng do đô la Mỹ có tính lạm phát, chúng ta sẽ giả định chi phí thanh khoản cho các quỹ được tính bằng BTC là 3% mỗi năm cho phân tích của chúng ta.

Nếu khoảng thời gian vòng tròn là 4 tuần, điều này có nghĩa là giao dịch sẽ bắt đầu với chi phí thanh khoản là

, cuối cùng giảm xuống không. Giả sử người dùng cố gắng chuyển tiền của họ vào một vòng mới hai tuần trước khi vòng kết thúc, người dùng phải trả khoảng 1,5% mỗi năm cho chi phí thanh khoản để đạt được tự lưu giữ tài sản của họ. Trên mặt khác, nếu người dùng chờ đến phút cuối⁸ , chi phí có thể gần như bằng không, với nguy cơ bỏ lỡ thời gian hết hạn.

Người dùng có thể không coi đây là một chi phí nhỏ. Và chi phí này giả định rằng chi phí cố định của mỗi vòng đã trở nên không đáng kể do việc phân chia chi phí giao dịch và các chi phí khác qua một số lượng lớn người tham gia.

Nhưng nếu chi phí cố định không phải là điều không đáng kể? Giả sử mỗi giờ, ASP tạo ra 1000 người dùng và pool txouts trên trung bình. Trong một khoảng thời gian 4 tuần, đó là 672 giao dịch trên chuỗi. Điều này có nghĩa là để đơn giản giữ quỹ của họ, người dùng của ASP cần phải trả tiền cho gần như bằng số giao dịch như người dùng! Có lẽ việc tất cả họ mở các kênh Lightning riêng của mình sẽ rẻ hơn, ngay cả khi ASP yêu cầu họ chờ xác nhận trong một giờ.

Khởi động Ark

Một ASP mới với ít người dùng đối mặt với một tình huống khó khăn: hoặc các vòng ASP xảy ra không thường xuyên và người dùng phải chờ đợi một thời gian dài để các vòng đề xuất có đủ V-UTXO để đạt được tăng tốc hữu ích và giảm phí giao dịch. Hoặc các giao dịch hồ bơi ASP xảy ra thường xuyên, với phí giao dịch cao được trả bởi mỗi người dùng. Như chúng tôi đã cho thấy ở phần trước, có thể cần nhiều người dùng để phân bổ các vòng thường xuyên, và các txouts hồ bơi cơ bản của họ.

Bởi vì các vòng hết hạn, vấn đề này là một vấn đề liên tục, thậm chí còn tồi tệ hơn vấn đề mà kênh Lightning phải đối mặt: ít nhất một kênh Lightning có thể tiếp tục hữu ích mãi mãi, cho phép mở một kênh ngay bây giờ và trả dần trong nhiều tháng. Thứ hai, vì các vòng hết hạn, có ít linh hoạt hơn khi tạo ra các giao dịch mới để hỗ trợ các vòng này: nếu phí cao trong một hoặc hai tuần, người dùng có giao dịch từ nhóm sẽ không có lựa chọn nào khác ngoài việc trả (tổng hợp) các khoản phí cao để duy trì quyền sở hữu của họ đối với tài sản của mình. Với các kênh Lightning, có nhiều linh hoạt hơn khi thực sự mở một kênh.

Trong khi tác giả của Ark ban đầu đã tưởng tượng ra một kịch bản rất lạc quan trong đó các vòng mới sẽ được thực hiện trong vài giây, việc khởi động ban đầu sẽ có thể xảy ra với các trường hợp sử dụng có thể chờ đợi nhiều giờ để xác nhận giao dịch Ark nếu phí giao dịch không được bảo trợ.

Tương tác

Non-custodial Ark là một giao thức tương tác cao: vì V-UTXOs của bạn hết hạn, bạn phải tuân thủ các thời hạn cứng rắn để tương tác với ASP của bạn, nếu không ASP có thể chọn lấy tiền của bạn. Tính tương tác này cũng không thể được giao cho người khác: trong khi Lightning cówatchtowersđể ngăn không cho các bên đối tác cố gắng lừa bạn — ngay cả khi kênh của bạn chưa online — chủ sở hữu coin Ark phải sử dụng các khóa riêng tư của họ để làm mới các quỹ mà không cần tin cậy. Điều gần nhất có thể trong Ark với watchtowers sẽ là ký giao dịch cho phép watch tower rút quỹ của bạn một cách đơn phương trên chuỗi tới thời gian hết hạn, điều này sẽ tốn một khoản phí giao dịch đáng kể.

Xem xét điều gì sẽ xảy ra với một V-UTXO nếu chủ sở hữu không online: sau khi vòng hết hạn, ASP cần phục hồi các quỹ để lấy lại tính thanh khoản cho các vòng tiếp theo. Nếu chủ sở hữu V-UTXO không online, việc đưa V-UTXO đó vào chuỗi có chi phí giao dịch đáng kể, vì ASP bây giờ cần phục hồi quỹ ở nhiều cấp độ của cây V-UTXO. ASP có thể tái tạo lại các V-UTXO chưa được tiêu 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 các chủ sở hữu V-UTXO, vì họ không thể tiêu các V-UTXO đó mà không có dữ liệu⁹từ ASP. ASP cũng có thể đơn giản ghi lại V-UTXOs chưa tiêu dùng như một số dư giữ quản. Hoặc có thể thậm chí có chính sách tịch thu quỹ!

Cá nhân tôi nghi ngờ rằng với chi phí không nhỏ để tự lưu giữ trong Ark, nhiều người dùng sẽ chọn ASPs với chính sách tiếp tục chuyển tiền vào vòng mới và đơn giản chấp nhận nguy cơ gian lận vào cuối mỗi vòng. Điều này rẻ hơn việc di chuyển tiền của họ một cách chủ động đủ sớm để đảm bảo an toàn trong trường hợp, ví dụ, họ không kịp bật điện thoại để ví của họ chuyển tiền vào vòng mới.

Advanced Ark

Có thể khả thi để giảm các yêu cầu thanh khoản của Ark thông qua các giao ước nâng cao hơn, nếu đó là điển hình cho thanh khoản được sử dụng hết một phần thông qua một vòng. Ví dụ: giả sử rằng 50% tổng giá trị V-UTXO trong một txout pool đã được chi tiêu. Nếu ASP có thể mua lại chỉ một phần của txout pool của vòng, họ có thể phục hồi thanh khoản nhanh hơn, giảm chi phí thanh khoản tổng thể. Mặc dù không có đề xuất cụ thể nào về cách thực hiện điều này đã được công bố, nhưng chắc chắn có vẻ như điều đó có thể thực hiện được với các giao ước Đủ Nâng cao™. Nhiều khả năng thông qua một số loại soft-fork hồi sinh kịch bản bổ sung nhiều opcode hữu ích cùng một lúc.

Tương tự, thông qua các giao ước Đủ nâng cao™, toàn bộ cấu trúc cây txout có thể được thay thế bằng một số loại sơ đồ rút tiền lăn, có khả năng tiết kiệm không gian. Chúng tôi sẽ đề cập đến điều này trong phần tiếp theo, vì kỹ thuật này có khả năng hữu ích cho các chương trình khác.

Vấn đề quyền nuôi con cuối vòng là một trường hợp khác mà các giao ước Đủ nâng cao™ có thể giải quyết vấn đề: một giao ước, đặc biệt là giao ước chống ZK, có thể buộc ASP phải tạo lại tất cả các V-UTXO chưa sử dụng trong vòng tiếp theo, loại bỏ vấn đề quyền nuôi con hoàn nguyên về chúng vào cuối vòng. Mặc dù có thể không thể làm cho điều này trở nên đáng tin cậy, vì người dùng có thể sẽ cần một số dữ liệu từ ASP để chi tiêu V-UTXO của họ cho vòng mới, nhưng nó có thể ngăn ASP thu lợi tài chính từ gian lận đối với người dùng ngoại tuyến.

Thanh toán Phí trên Chuỗi trong Rồi từ Chỉ Thịch

Tương tự như Lightning, kinh tế của việc thanh toán phí trên chuỗi và giá trị thực tế của một V-UTXO sau khi trừ phí xác định xem việc sử dụng Ark có đáp ứng định nghĩa của chúng tôi về một L2 thông qua rút lui một chiều hoặc gian lận không có lợi ích cho ASP hay không. Chúng tôi sẽ thảo luận cụ thể hơn về điều này khi chúng tôi thảo luận về mẫu thiết kế cây txout.

Cuộn Validity

Một lớp lớn các cấu trúc giống như sidechain, thường được đề xuất sử dụng các dạng công nghệ chứng minh không có kiến thức (ZK) khác nhau để thực thi các quy tắc của chuỗi. Công nghệ ZK-proof là sự khác biệt quan trọng giữa công nghệ tổng hợp hiệu lực và các dạng sidechain khác: nếu sơ đồ ZK-proof hoạt động, tính hợp lệ của các giao dịch có thể được đảm bảo bằng toán học thay vì tin tưởng vào bên thứ ba. Khía cạnh "không có kiến thức" của bằng chứng ZK không thực sự là một yêu cầu trong trường hợp sử dụng này: hoàn toàn ổn nếu bằng chứng "rò rỉ" thông tin về những gì nó đang chứng minh. Nó chỉ tình cờ là hầu hết các sơ đồ toán học cho lớp chứng minh này xảy ra là bằng chứng không có kiến thức.

Từ quan điểm của Bitcoin, một chương trình tổng hợp hợp lệ đòi hỏi một giao ước, vì chúng tôi muốn có thể tạo UTXO cho chương trình chỉ có thể được chi tiêu nếu các quy tắc của chương trình được tuân theo. Đây không nhất thiết là một quá trình phi tập trung. Nhiều chương trình tổng hợp hiệu lực trên thực tế hoàn toàn tập trung; Bằng chứng tổng hợp đang chứng minh rằng trình tự giao dịch tập trung tuân theo các quy tắc cho một chuỗi giao dịch cụ thể.

Về phần giao ước gì... Công nghệ Zero-Knowledge Proof vẫn là một lĩnh vực rất mới, với những tiến bộ vẫn thường xuyên được thực hiện. Vì vậy, rất khó có khả năng chúng ta sẽ thấy bất kỳ opcode nào được thêm vào Bitcoin xác thực trực tiếp bất kỳ chương trình chống ZK cụ thể nào. Thay vào đó, người ta thường chấp nhận rằng các lược đồ cụ thể thay vào đó sẽ sử dụng các opcode chung hơn, đặc biệt là OP_CAT, để xác thực các bằng chứng ZK thông qua các tập lệnh. Chẳng hạn StarkWarelàchiến dịchđể có OP_CAT được áp dụng.

Rollups xác thực là một chủ đề tiềm năng lớn, với rất nhiều dự án có ít nội dung / cao hứng thú, nên chúng tôi sẽ không thảo luận thêm về nó ngoài việc nhấn mạnh các opcode có thể làm cho lớp thiết kế này khả thi.

BitVM

Nói chung, BitVM là một cách để xây dựng một kênh sáng lấp lánh giữa hai bên sao cho các quy tắc của kênh Lightning được thực thi bằng một chứng minh không có kiến thức. Vì nó thực sự không cần phải áp dụng các điều khoản được thực hiện trên Bitcoin hôm nay và vì nó không thể trực tiếp được sử dụng để tạo ra một hệ thống L2 có khả năng mở rộng vượt quá giới hạn 1-UTXO-per-người dùng, chúng tôi sẽ không thảo luận thêm về nó.

Kênh phân cấp

Kênh phân cấp¹⁰nhằm mục tiêu làm cho việc thay đổi kích thước kênh trở nên nhanh chóng và rẻ tiền: “Các kênh phân cấp làm cho khả năng của kênh trở nên giống như LN làm cho bitcoin”. Tuy nhiên, họ vẫn không vượt quá giới hạn 1 UTXO cho mỗi người dùng một cách cơ bản. Họ cũng không yêu cầu bất kỳ thay đổi nào đối với giao thức Bitcoin. Vì vậy, chúng tôi sẽ không tiếp tục thảo luận về họ. Những người ủng hộ họ chỉ cần triển khai chúng! Họ không cần sự cho phép của chúng tôi.

CoinPool

CoinPool cho phép nhiều người dùng chia sẻ một UTXO duy nhất, chuyển tiền giữa các người dùng khác nhau và rút tiền một chiều. Đề xuất giấy trắng CoinPool yêu cầu ba tính năng softfork mới, SIGHASH_ANYPREVOUT, SIGHASH_GROUP cho phép chữ ký chỉ áp dụng cho các UTXO cụ thể và OP_MerkleSub để xác minh việc xóa các nhánh cụ thể từ cây merkle; tính năng cuối cũng có thể được thực hiện bằng OP_CAT.

Hiện tại, phát triển CoinPool dường như đã đình đám, với lần commit cuối cùng vào trang web quy định cách đây hai năm.

Mạng Enigma

Trong khi tôi được yêu cầu đưa ra bản tin về Mạng lưới Enigma, có vẻ như thiếu tài liệu để diễn tả đề xuất này thực sự là gì. Của Bitfinex bài đăng trên blog đưa ra rất nhiều yêu cầu; Các Trang MIT trống rỗng. Vì bài đăng trên blog không thực sự làm rõ chính xác những gì được cho là đang diễn ra, chúng tôi sẽ không thảo luận thêm.

Xem xét vấn đề Mempool

Chính sách mempool hiện tại trong Bitcoin Core không lý tưởng cho các hệ thống L2. Ở đây chúng ta sẽ đi qua một số thách thức chính mà họ phải đối mặt và những cải tiến tiềm năng.

Ghim giao dịch

Cuối cùng là một kỹ thuật khai thác kinh tế, các cuộc tấn công ghim giao dịch, đề cập đến một loạt các tình huống mà ai đó có thể cố ý (.hoặc vô ý) làm cho việc khai thác một giao dịch mong muốn trở nên khó khăn do việc phát sóng trước một giao dịch xung đột mà không được khai thác. Đây là một hình thức khai thác kinh tế, vì trong tình huống giao dịch bị gài cản thực sự, tồn tại một giao dịch đáng mong đợi mà các nhà khai thác sẽ có lợi nếu họ khai thác nó; giao dịch gài cản xung đột không được khai thác trong một khoảng thời gian hợp lý, nếu có.

Ví dụ đơn giản nhất về ghim đến từ thực tế là không có RBF đầy đủ, thay thế giao dịch có thể bị tắt. Do đó, chúng ta có thể có một giao dịch phí thấp, với việc thay thế bị tắt, sẽ không được khai thác nhưng không thể thay thế. Về cơ bản, 100% sức mạnh băm đã khắc phục vấn đề này bằng cách bật RBF đầy đủ và khi viết, RBF đầy đủ sẽ được bật theo mặc định trong bản phát hành tiếp theo của Bitcoin Core (sau 11 năm nỗ lực!).

Điều này để lại việc gắn kết quy tắc BIP-125 số 3, vấn đề gắn kết cuối cùng còn liên quan đến giao thức L2 đa bên và chưa được sửa trong Bitcoin Core. Để tham khảo, Quy tắc BIP-125 số 3 nêu ra như sau:

Một giao dịch thay thế được yêu cầu để thanh toán phí tuyệt đối cao hơn (không được

chỉ là tỷ lệ phí) trên tổng phí được trả bởi tất cả các giao dịch được thay thế.

Quy tắc này có thể bị lợi dụng bằng cách phát sóng giao dịch ghim lớn, tỷ lệ phí thấp chi tiêu các đầu ra liên quan đến giao thức đa bên (hoặc một nhóm giao dịch). Vì giao dịch có tỷ lệ phí thấp, nó sẽ không được khai thác kịp thời, nếu có. Tuy nhiên, vì nó có tổng phí cao, việc thay thế nó bằng một giao dịch khác là không kinh tế.

Quy tắc số 3 đính kèm một cách khá dễ dàng được sửa chữa thông quaThay thế theo mức phívà khắc phục sự cố này hoạt động trong mọi tình huống. Thật không may, không rõ liệu RBFR có được Core áp dụng trong tương lai gần hay không, vì họ đã dành một lượng nỗ lực đáng kể cho một giải pháp từng phần kém hơn, Giao dịch TRUC/V3.

Thanh toán phí: RBF, CPFP, SIGHASH_ANYONECANPAY, Anchors, và Sponsorship

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

RBF là tiêu chuẩn vàng để thanh toán phí vì nó là không gian khối hiệu quả nhất trong hầu hết tất cả¹¹Tình huống: Giao dịch thay thế không cần bất kỳ đầu vào hoặc đầu ra bổ sung nào, so với những gì đã cần thiết nếu phí chính xác đã được đoán đúng lần đầu tiên.

Hiệu suất là quan trọng, bởi vì sự không hiệu quả trong thanh toán phíThanh toán phí ngoài băng tầnmột nguồn thu lợi nhuận đáng kể cho các nhà khai thác lớn; những nhà khai thác nhỏ hơn, phi tập trung không thể có lợi nhuận từ việc thanh toán phí ngoài kênh do tính không thực tế và vô ích của việc thanh toán cho một nhà khai thác nhỏ để xác nhận giao dịch. Thanh toán phí ngoài kênh cũng có vẻ mời gọi vấn đề AML / KYC: hiện nay, hầu hết các hệ thống thanh toán phí ngoài kênh thực sự có sẵn yêu cầu một quy trình AML / KYC nào đó để thanh toán phí, với trường hợp nổi bật của Máy gia tốc mempool.space, hiện tại (Tháng Tám năm 2024), chấp nhận Lightning mà không cần tài khoản.

Để sử dụng RBF trực tiếp trong các tình huống với các giao dịch được ký trước, bạn cần ký trước các biến thể phí bao gồm đầy đủ các khoản phí tiềm năng. Mặc dù điều này khá khả thi trong nhiều trường hợp vì số lượng biến thể cần thiết thường nhỏ¹²cho đến nay, giao thức Lightning sản xuất - và các giao thức đề xuất khác - đã chọn sử dụngChild-Pays-For-Parent (CPFP), thường thông qua các đầu ra trụ cột.

Ý tưởng đằng sau một đầu ra mỏ neo là bạn thêm một hoặc nhiều đầu ra vào một giao dịch với giá trị tối thiểu hoặc bằng không, với ý định thanh toán phí qua CPFP bằng cách tiêu thụ những đầu ra đó trong các giao dịch phụ. Điều này tất nhiên là rất không hiệu quả khi áp dụng cho các giao thức như LN có các giao dịch trên chuỗi nhỏ, gần nhưtăng gấp đôi tổng kích thước của giao dịch cam kết LN sử dụng đầu ra tạm thời. Điều này sẽ ít đáng lo ngại hơn khi áp dụng các giao thức sử dụng các giao dịch lớn hơn, như bất cứ thứ gì sử dụng OP_CAT để thực hiện các điều khoản.

Một vấn đề ít rõ ràng hơn với đầu ra neo là cần phải giữ xung quanh các UTXO bổ sung để trả phí. Trong một ứng dụng "máy khách" điển hình, đây có thể là một gánh nặng tổng thể đáng kể, vì không có đầu ra neo, thường không cần phải duy trì nhiều hơn một UTXO. Thật vậy, có khả năng một số ví Lightning tập trung vào người tiêu dùng hiện tại dễ bị đánh cắp bởi phía xa của kênh trong môi trường phí cao do không có khả năng trả phí.

SIGHASH_ANYONECANPAY có thể được sử dụng để thanh toán phí trong một số trường hợp bằng cách cho phép thêm đầu vào bổ sung vào các giao dịch đã ký; SIGHASH_SINGLE cho phép đầu ra cũng được thêm vào. Lightning sử dụng điều này cho các giao dịch HTLC. Hiện tại, thực tế này có thể dễ bị ghim giao dịch nếu không được xử lý cẩn thận¹³, như một kẻ tấn công có thể thêm một số lượng lớn đầu vào và/hoặc đầu ra vào giao dịch để tạo ra một mã pin phí cao/tỷ lệ phí thấp. RBFR khắc phục vấn đề này; phương pháp được sử dụng trong giao dịch TRUC/V3 không thể khắc phục vấn đề này. Cách thanh toán phí theo kiểu này không hiệu quả như RBF. Nhưng nó có thể hiệu quả hơn các đầu ra neo.

Cuối cùng, đã có nhiều đề xuất soft-fork để thêm một Tài trợ phí hệ thống đến giao thức Bitcoin. Điều này sẽ cho phép các giao dịch khai báo sự phụ thuộc vào các giao dịch khác, sao cho giao dịch tài trợ chỉ có thể được khai thác nếu giao dịch được tài trợ cũng đượ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 tài trợ có thể tuyên bố sự phụ thuộc đó bằng cách sử dụng ít vbyte hơn đáng kể so với kích thước của đầu vào giao dịch.

Thay thế Đạp xe

Cuộc tấn công đi xe đạp thay thế¹⁴tận dụng việc thay thế giao dịch để cố gắng thay thế một giao dịch L2 mong muốn đủ lâu để cho một giao dịch không mong muốn được khai thác thay vì đó. Về cơ bản, cuộc tấn công chu kỳ thay thế là một phương án thay thế cho các kỹ thuật ghim giao dịch trong việc ngăn chặn một giao dịch mong muốn, trung thực, khai thác đủ lâu để cho một giao dịch không mong muốn, không trung thực, được khai thác thay thế. Khác với cuộc tấn công ghim giao dịch, cuộc tấn công chu kỳ thay thế không thể xảy ra tình cờ.

Ví dụ cổ điển chống lại một Hợp đồng Hashed-Time-Locked (HTLC). Trong khi dễ dàng nghĩ về một HTLC như là một hợp đồng cho phép giao dịch được tiêu thụ thông qua việc tiết lộ một hình ảnh trước, hoặc thông qua thời gian chờ. Trên thực tế do hạn chế kịch bản Bitcoin, một HTLC cho phép một giao dịch luôn luôn được tiêu thụ thông qua việc tiết lộ một hình ảnh trước, và sau đó sau thời gian chờ, thêm vào đó là cơ chế thời gian chờ.

Sử dụng việc thay thế chu kỳ để tận dụng điều này bằng cách sử dụng preimage sau khi hết thời gian chờ, để thay thế giao dịch cố gắng chiếm đoạt đầu ra HLTC thông qua cơ chế hết thời gian chờ mà không để nạn nhân biết về preimage. Một cuộc tấn công thay thế chu kỳ thành công làm điều này đủ lâu cho một HTLC của kênh khác hết thời gian chờ.

Một thách thức chính trong việc khai thác vòng đời thay thế có lợi là mỗi vòng thay thế đều tốn tiền. Một phiên bản Lightning nhận thức được thời hạn sẽ tiêu tốn các khoản phí cao hơn và cao hơn trong việc cố gắng tiêu tốn đầu ra HTLC đã hết hạn trước khi đầu ra HTLC kế tiếp hết hạn. Thứ hai, bất kỳ ai cũng có thể đánh bại cuộc tấn công bằng cách đơn giản là phát lại giao dịch đã được thay thế.¹⁵sau khi chu kỳ thay thế kết thúc.

Cũng như ghim giao dịch, chu kỳ thay thế cũng là một khai thác kinh tế đối với các thợ mỏ. Vào cuối mỗi chu kỳ thay thế, tồn tại một giao dịch đã bị xóa khỏi mempool, nhưng hoàn toàn hợp lệ và có thể được khai thác nếu chỉ các thợ đào vẫn có nó trong mempool của họ.

Mẫu tính năng và Fork mềm

Bây giờ khi chúng tôi đã cung cấp cho bạn một cái nhìn tổng quan về đa dạng các hệ thống L2 phụ thuộc vào hiệp ước hiện có, và thách thức về mempool, chúng tôi sẽ cố gắng rút ngắn thông tin đó xuống một tập hợp các tính năng nổi bật của soft fork (chủ yếu là các mã opcode mới) và mẫu thiết kế mà các hệ thống L2 này chia sẻ. Đối với các đề xuất soft fork, chúng tôi cũng sẽ thảo luận về các rủi ro kỹ thuật cụ thể của đề xuất và các thách thức khi triển khai mỗi đề xuất.

OP_Expire

Trước tiên, chúng tôi sẽ giải quyết điều này. OP_Expire đã được đề xuất¹⁶ như một cách đơn giản để loại bỏ cuộc tấn công đi xe đạp thay thế bằng cách khắc phục sự cố tại nguồn: thực tế là HTLC có thể được chi tiêu theo hai cách khác nhau cùng một lúc. Trong bối cảnh của các hệ thống L2, điều này có liên quan đến bất cứ điều gì sử dụng cơ chế giống như HTLC và có thể là các trường hợp sử dụng khác. OP_Expire sẽ làm cho đầu ra giao dịch có thể không thể chi tiêu được sau một thời điểm, cho phép các điều kiện chi tiêu HTLC là độc quyền thực sự HOẶC thay vì "lập trình viên HOẶC".

Một soft-fork OP_Expire thực sự sẽ có khả năng bao gồm hai tính năng, tương tự như cách mà OP_CheckLockTimeVerifyvàOP_CheckSequenceVerifyCác mã opcode được chia thành hai phần:

1. Một trường chiều cao hết hạn cho các giao dịch, có thể được thực hiện trong phụ lục taproot.
2. Một opcode OP_Expire kiểm tra xem chiều cao hết hạn được thiết lập ít nhất là chiều cao mong muốn.

Mặc dù bản thân OP_Expire hầu như không đủ điều kiện là một giao ước, nhưng nó dường như hữu ích cho nhiều hệ thống L2 phụ thuộc vào giao ước. Tuy nhiên, nó có thể không đủ hữu ích vì việc đi xe đạp thay thế cũng có thể được giảm thiểu bằng cách phát lại vị tha¹⁵

Một thách thức rất đáng chú ý khi triển khai và sử dụng OP_Expire là reorgs: cộng đồng kỹ thuật Bitcoin, bắt đầu từ Satoshi¹⁷đã cố gắng đảm bảo rằng giao thức đồng thuận Bitcoin được thiết kế sao cho sau khi reorg sâu, các giao dịch đã được đào trước đó có thể được đào vào các khối mới. Nguyên tắc thiết kế này cố gắng tránh tình huống thảm họa khi một số lượng lớn tiền được xác nhận trở nên vĩnh viễn không hợp lệ - và do đó những người phụ thuộc vào những đồng tiền đó sẽ mất tiền - nếu một sự cố đồng thuận dẫn đến một reorg lớn.

Trong trường hợp có một sự tổ chức lại lớn, các giao dịch sử dụng thời hạn có thể trở thành không thể khai thác do đạt đến chiều cao hết hạn. Đề xuất OP_Expire đề xuất để giảm thiểu vấn đề này bằng cách xử lý các đầu ra của các giao dịch sử dụng thời hạn tương tự như giao dịch coinbase, làm cho chúng không thể tiêu thụ trong khoảng ~100 khối.

Một rào cản đáng kể trong việc triển khai việc hết hạn giao dịch là đạt được sự đồng thuận về việc liệu sự đánh đổi này có chấp nhận được hay thậm chí cần thiết hay không. Các loại giao dịch mà OP_Expire sẽ hữu ích đã liên quan đến các timeout khá dài, trong đó tiền của người dùng bị đóng băng. Thêm thời gian cho các timeout này không được mong muốn. Ngoài ra, double-spends luôn là một cách khác để vô hiệu hóa các đồng xu sau khi có một reorg: với việc sử dụng RBF ngày càng tăng và việc đề xuất sử dụng các keyless anchor outputs, liệu việc hết hạn giao dịch có tạo ra sự khác biệt đáng kể không?

SIGHASH_ANYPREVOUT

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

SIGHASH_ANYPREVOUT cũng có khả năng hữu ích trong trường hợp chúng tôi muốn sử dụng các biến thể tỷ lệ phí RBF được ký trước kết hợp với các giao dịch được ký trước, vì thực tế là chữ ký không còn phụ thuộc vào một txid cụ thể tránh được tổ hợp nổ của các biến thể tỷ lệ phí. Tuy nhiên, đề xuất BIP-118 hiện tại không giải quyết trường hợp sử dụng này và có thể không tương thích với nó do thực tế là SIGHASH_ANYPREVOUT được đề xuất cũng cam kết với giá trị của UTXO.

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

Hiện tại, cộng đồng kỹ thuật tổng quát dường như khá tích cực về việc triển khai BIP-118. Tuy nhiên, như đã thảo luận ở trên trong cuộc thảo luận về LN-Symmetry của chúng tôi, có cuộc tranh luận về việc liệu trình sử dụng chính của nó — LN-Symmetry — có thực sự là một ý tưởng tốt hay không.

OP_CheckTemplateVerify

Đề xuất mã opcode đầu tiên cụ thể cho đồng thuận của chúng tôi, OP_CheckTemplateVerify - hay được gọi là “CTV” - nhằm tạo ra một mã opcode đặc biệt, giới hạn bằng cách thực hiện đúng một việc: băm giao dịch chi tiêu theo một cách chỉ định mà không cam kết đến các đầu vào UTXO và kiểm tra bản tóm tắt kết quả với phần tử ngăn xếp trên cùng. Điều này cho phép giao dịch chi tiêu được giới hạn trước, mà không làm cho các hạn chế đồng thuận đệ quy thực sự trở nên khả thi.

Tại sao các hiệp ước đệ quy không thể thực hiện trong CTV? Bởi vì hàm băm: CTV kiểm tra giao dịch chi tiêu so với một hàm băm mẫu, và không có cách nào¹⁸tạo mẫu chứa một CTV với một băm của chính nó.

Tuy nói vậy, điều này không nhất thiết là một giới hạn thực sự: bạn có thể dễ dàng băm một chuỗi các băm mẫu CTV đến hàng chục triệu giao dịch chỉ trong vài giây trên một máy tính hiện đại. Vớithời gian khóa nSequence tương đốivà kích thước khối giới hạn thực sự đạt đến cuối chuỗi như vậy có thể dễ dàng được tạo ra để mất hàng nghìn năm.

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

Có thể nói rằng CTV được hỗ trợ rộng rãi nhất trong cộng đồng kỹ thuật so với bất kỳ đề xuất mã opcode bảo đảm nào khác vì tính đơn giản tương đối và loạt các trường hợp sử dụng rộng rãi của nó.

LNHANCE

Một đề xuất để triển khai CTV là kết hợp nó với hai mã opcode khác, OP_CheckSigFromStack(Verify) và OP_InternalKey. Vấn đề là, vào lúc viết, tài liệu trong pull-req đó và các BIP liên quan đơn giản không đủ để bào chữa hoặc phản đối đề xuất này. Các BIP hoàn toàn thiếu bất kỳ lý do nào cho những gì mà các mã opcode được kỳ vọng thực sự thực hiện trong các ví dụ thực tế, chưa kể là trong các kịch bản ví dụ chi tiết.

Mặc dù tác giả có lẽ có lý do tốt cho đề xuất của họ, trách nhiệm nằm ở họ để thực sự giải thích những lý do đó và chứng minh chúng một cách đúng đắn. Do đó, chúng tôi sẽ không thảo luận vấn đề này nữa.

OP_TXHASH

Tương tự như CTV, đề xuất này đạt được chức năng covenant không đệ quy bằng cách băm dữ liệu từ giao dịch tiêu tiền. Không giống CTV, đề xuất TXHASH cung cấp cơ chế 'field selector', cho phép linh hoạt trong cách thức chế định giao dịch tiêu tiền. Linh hoạt này đạt được hai mục tiêu chính:

1. Cho phép thêm phí vào giao dịch mà không làm hỏng giao thức đa-giao dịch.
2. Các giao thức đa người dùng nơi mà người dùng chỉ hạn chế đầu vào và đầu ra của chính họ.

Vấn đề chính với OP_TXHASH là cơ chế lựa chọn trường dữ liệu tạo ra khá nhiều phức tạp, làm cho việc xem xét và kiểm tra thử thách hơn so với đề xuất CTV đơn giản hơn nhiều. Hiện tại, không có nhiều phân tích thiết kế về cách mà cơ chế lựa chọn trường dữ liệu sẽ thực sự hữu ích như thế nào hoặc sẽ được sử dụng như thế nào. Do đó, chúng tôi sẽ không bàn luận về nó nữa.

OP_CAT

Toán tử nối chuỗi, nối hai phần tử trên đỉnh của ngăn xếp và đẩy kết quả nối trở lại ngăn xếp. Bitcoin ban đầu đi kèm với OP_CAT được kích hoạt. Nhưng Satoshi đã quietly removed nó vào năm 2010, có lẽ do thực hiện ban đầu bị tổn thương bởi các cuộc tấn công DoS do thiếu hạn chế về kích thước của phần tử kịch bản kết quả. Hãy xem kịch bản sau đây:

DUP MÈO DUP MÈO...

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

Nối chuỗi đủ để triển khai nhiều loại ước lệ, bao gồm cả ước lệ đệ quy, bằng cách thực hiện các bước sau:

1. Lắp ráp một giao dịch một phần, không có dữ liệu chứng kiến, trên ngăn xếp với một hoặc nhiều lần gọi OP_CAT (và bất kỳ logic cụ thể của điều khoản nào cần thiết).
2. Xác minh rằng giao dịch trên ngăn xếp phù hợp với giao dịch chi tiêu.

Như nó hóa ra, bởi lạm dụng toán học của chữ ký Schnorr, có thể thực hiện bước thứ hai với OP_CheckSig thông qua chữ ký được xây dựng cẩn thận. Tuy nhiên, có thể có khả năng rằng một soft-fork OP_CAT sẽ được kết hợp với OP_CheckSigFromStack, cho phép bước thứ hai được thực hiện bằng cách xác minh rằng một chữ ký trên ngăn xếp là một chữ ký hợp lệ cho giao dịch¹⁹, sau đó sử dụng lại cùng chữ ký đó với OP_CheckSig để xác thực rằng giao dịch chi tiêu khớp với nhau.²⁰

Việc chúng ta chỉ cần lắp ráp giao dịch mà không cần dữ liệu chứng nhận là một điểm quan trọng: hợp đồng chỉ cần xác thực những gì giao dịch thực hiện - đầu vào và đầu ra - không phải dữ liệu chứng nhận (nếu có) thực sự làm cho nó hợp lệ.

Ngoại trừ giới hạn kích thước tập lệnh, sự kết hợp của OP_CAT và OP_CheckSigFromStack là đủ để xây dựng nhiều loại hiệp ước, bao gồm cả hiệp ước đệ quy. So với các giải pháp hiệu quả hơn như CTV thì việc này tốn kém hơn. Nhưng sự khác biệt về chi phí lại ít hơn bạn nghĩ!

Nói một cách đại khái, việc sử dụng OP_CAT để làm điều này yêu cầu tất cả phần không liên quan đến chứng nhân của giao dịch chi tiêu được đặt trên ngăn xếp qua chứng nhân. Đối với các trường hợp sử dụng CTV điển hình như cây txout, giao dịch chi tiêu sẽ không có dữ liệu chứng nhân nào. Vì không gian chứng nhân được giảm giá 75%, điều đó tăng khoản phí giao dịch hiệu quả cho giao dịch con chỉ 25%. Không tệ!

OP_CAT Có Quá Mạnh Không?

Đây có lẽ là rào cản chính trị và kỹ thuật lớn nhất đối với việc triển khai OP_CAT: rất khó để dự đoán được các trường hợp sử dụng sẽ được làm cho khả dĩ bởi OP_CAT. Và một khi đã "thả mèo", thì rất khó để cho nó trở lại trong bụi.

Một ví dụ tuyệt vời là cách mà OP_CAT được cho là đủ để cho phép hiệu quả và an toàn đáng kểSTARK verification sẽ được triển khai trong Bitcoin script. Vì STARKs có khả năng chứng minh những tuyên bố cực kỳ tổng quát, việc triển khai STARKs một cách hiệu quả có những tác động quan trọng vượt ra ngoài phạm vi của hệ thống L2 vì nó cho phép xây dựng nhiều hệ thống khác nhau trên nền tảng Bitcoin. Một lập luận mạnh chống lại OP_CAT là những trường hợp sử dụng này có thể không hoàn toàn tốt cho người dùng Bitcoin.

Việc tạo ra Giá trị Khai thác của Trâu chủ đạo có hại là một vấn đề tiềm ẩn quan trọng,gọi là "MEV là evIL" (MEVil) của Matt Corallo. Nói tóm lại, MEVil là bất kỳ trường hợp nào mà các thợ đào / nhóm lớn có thể trích xuất giá trị bổ sung bằng cách sử dụng các chiến lược khai thác giao dịch tinh vi - ngoài việc tối đa hóa tổng phí - không thực tế đối với các thợ đào / nhóm nhỏ hơn áp dụng. Sự phức tạp cắt của các công cụ tài chính tiềm năng có thể được tạo ra bằng OP_CAT khiến việc loại trừ MEVil rất khó khăn. MEVil quan trọng đã xuất hiện trên Bitcoin từ các giao thức đấu giá mã thông báo; may mắn thay, trường hợp cụ thể đó đã bị đánh bại thông qua việc áp dụng RBF đầy đủ.

Bên cạnh tiềm năng của MEVil, còn rất nhiều trường hợp sử dụng cụ thể OP_CAT khác có thể gây hại. Ví dụ, đề xuất Drivechains đã được đã xem xét ở đâyvà được xem là có hại cho Bitcoin. Điều đótin rằng có thể thực hiện đượcđể triển khai Drivechain với OP_CAT. Một ví dụ khác là các đề xuất mã thông báo như Tài sản Taproot. Trong khi nó không thể chung chung ngăn chặn chúng được triển khai vớixác thực phía khách hàng, có các đề xuất để triển khai chúng với OP_CAT theo cách có thể hấp dẫn hơn đối với người dùng cuối, đồng thời sử dụng nhiều không gian khối hơn, có thể vượt qua giao dịch Bitcoin “hợp pháp”. Những trường hợp sử dụng này cũng có thể gây ra vấn đề pháp lý do sự lạm dụng giao thức token cho gian lận tài chính.

Băm Tăng Dần

Đối với các giao ước, OP_CAT sẽ được sử dụng chủ yếu để nối dữ liệu và sau đó băm nó. Một cách khác để đạt được mục tiêu tương tự là với một số loại opcode băm gia tăng lấy trạng thái giữa SHA256 và băm nhiều dữ liệu hơn vào đó; Bản thân SHA256 hoạt động trên các khối 64 byte. Có nhiều thiết kế khả thi cho opcode băm gia tăng.

Một quyết định thiết kế quan trọng là có nên hiển thị các byte trạng thái giữa thực tế trên ngăn xếp ở một số dạng chuẩn hay biểu diễn chúng trong một số loại mục ngăn xếp mờ đục mới mà giá trị byte thực tế không thể được thao tác trực tiếp. SHA256 được chỉ định cho một vectơ khởi tạo cụ thể, cố định, và dường như không biết liệu các thuộc tính mật mã của SHA256 có đúng hay không nếu cho phép các vectơ khởi tạo/trung trạng thái tùy ý.

Tất nhiên, vì băm tăng dần có thể làm gần như những gì mà OP_CAT có thể làm, chỉ hiệu quả hơn, nó chia sẻ tất cả các lo ngại về việc OP_CAT quá mạnh mẽ.

Kịch bản Hồi sinh

OP_CAT là một trong số 15 mã opcode mà Satoshi đã vô hiệu hóa. Ngoài việc khôi phục OP_CAT, Rusty Russell đang đề xuất²¹để về cơ bản khôi phục kịch bản Bitcoin về “Tầm nhìn Ban đầu của Satoshi” bằng cách kích hoạt lại hầu hết các opcode đó, thêm giới hạn DoS và có thể thêm thêm một số opcode khác trong cùng một soft-fork. Đặc biệt, một OP_CheckSigFromStack có thể.

Mặc dù OP_CAT đơn thuần chỉ làm cho các điều khoản (đệ quy) có thể thực hiện được, một “sự hồi sinh mã lệnh” đầy đủ sẽ làm cho các điều khoản phức tạp hơn có thể thực hiện được - và dễ dàng hơn rất nhiều - vì các phần của giao dịch chi tiêu có thể được điều khiển trực tiếp. Ví dụ, bạn có thể tưởng tượng một mã lệnh điều khoản sử dụng các mã lệnh số học để đảm bảo rằng tổng giá trị của các txouts trong giao dịch tuân theo một thuộc tính mong muốn nào đó.

Một lần nữa, việc tái khởi động mã nguồn gây ra tất cả những lo ngại tương tự, và nhiều hơn nữa, về việc quá mạnh mẽ mà chỉ riêng OP_CAT không thể.

Tính đơn giản

Tương tự như Script Revival, Simplicity liên quan đến L2 và covenants bằng cách làm cho mọi thứ có thể thực hiện được. Khác với Script Revival, một soft-fork Simplicity sẽ thêm một ngôn ngữ lập trình hoàn toàn mới vào hệ thống ghi chú của Bitcoin dựa trên chín toán tử nguyên thủy được biết đến là combinators.

Trong thực tế, Đơn giản đồng thời quá đơn giản và không đơn giản chút nào. Các combinator nguyên thủy quá thấp đến mức đáng ngạc nhiên nên các hoạt động cơ bản như cộng phải được thực hiện từ đầu một cách cần công; Đơn giản gốc sẽ rất dài dòng trong thực tế. Do đó, bất kỳ sử dụng thực tế nào của Đơn giản đều sử dụng một hệ thống thay thế mã, tương tự như cuộc gọi hàm thư viện, được biết đến nhưjets. Điều này đặt ra một vấn đề thực tế / chính trị: làm thế nào để quyết định về việc triển khai các đường ống? Có khả năng các đường ống sẽ được triển khai bằng C ++, giống như bất kỳ opcode nào khác, yêu cầu một vụ fork mềm cho mỗi đường ống mới.

OP_FancyTreeManipulationStuff

Có rất nhiều opcode tương đối chuyên biệt đã được đề xuất để thực hiện thao tác cây một cách hiệu quả về không gian cho các đề xuất L2 phụ thuộc vào giao ước. Ví dụ, Coinpools đã đề xuất cả hai TAPLEAF_UPDATE_VERIFYvàOP_MERKLESUB, cả hai đều điều khiển cây taproot theo cách cần thiết cho đề xuất Coinpools, và MATT Proposal đã đề xuất một OP_CheckContractVerify opcode, về cơ bản, xác minh các tuyên bố về Merkle Trees.

Với mục đích của bài viết này, chúng ta không cần phải đi vào chi tiết về từng đề xuất trong số nhiều đề xuất này. Thay vào đó, chúng ta có thể nói về chúng như một nhóm: tất cả chúng đều là những đề xuất tương đối cụ thể trong trường hợp sử dụng làm cho một lớp L2 trở nên khả thi, lý tưởng nhất là không có tác dụng phụ ngoài ý muốn. Tất cả chúng đều có lợi thế về hiệu quả: tất cả chúng đều sử dụng ít không gian khối hơn là đạt được cùng một mục tiêu với các mã opcode chung chung hơn như thao tác OP_CAT. Nhưng tất cả chúng đều có nhược điểm là thêm phức tạp vào hệ thống kịch bản, cho một trường hợp sử dụng thích hợp tiềm năng.

Cùng một động lực sẽ xảy ra nếu Bitcoin áp dụng hệ thống đoạn mã Simplicity. Tương đương với các mã opcode trong Simplicity là thêm một jet cho một mẫu thường được sử dụng. Một lần nữa, việc triển khai jets cho các hoạt động cụ thể theo trường hợp sử dụng như thao tác cây có những ưu điểm và nhược điểm tương tự như việc triển khai các mã opcode phức tạp cho các hoạt động cụ thể theo trường hợp sử dụng.

Quỹ Vốn

Tất cả các hệ thống L2 cố gắng có nhiều người dùng chia sẻ một UTXO duy nhất có thể được coi là một loại nhóm quỹ nhiều người dùng, với người dùng sở hữu một số loại quyền rút tiền. Có khả năng, cũng sẽ có một cơ chế để thêm tiền vào nhóm (ngoài việc tạo ra nhóm với các quỹ được chỉ định trước).

Để một nhóm quỹ trở nên hữu ích, nó phải có một số loại "trạng thái dữ liệu chia sẻ" được liên kết với nó: giá trị txout được phân chia như thế nào? Nếu nhóm quỹ phát triển theo thời gian, trạng thái đó cũng phải thay đổi khi quỹ được thêm hoặc xóa khỏi nhóm. Vì chúng tôi đang xây dựng trên Bitcoin, việc thêm hoặc xóa tiền khỏi nhóm chắc chắn sẽ liên quan đến việc chi tiêu UTXO mà nhóm kiểm soát.

Hãy nhớ rằng hệ thống đồng thuận Bitcoin chính nó dựa trên việc xác minh các thay đổi trạng thái: các giao dịch chứng minh qua các nhân chứng của chúng rằng các thay đổi đối với trạng thái tập UTXO là hợp lệ; bằng chứng công việc cho phép chúng ta đạt được sự đồng thuận về bộ giao dịch nào là chính xác. Điều này có nghĩa là các khoản quỹ cũng sẽ dựa trên việc xác minh các thay đổi trạng thái: chúng ta đang chứng minh với mọi nút Bitcoin rằng các quy tắc cho khoản quỹ đang được tuân theo trên mỗi thay đổi trạng thái.

Nhưng có một khía cạnh quan trọng khác đối với các nhóm quỹ L2 không tin cậy: khi trạng thái của nhóm quỹ thay đổi, hệ thống vốn phải xuất bản đủ dữ liệu để người dùng tham gia vào nhóm quỹ để thu hồi tiền của họ. Nếu chúng tôi chưa làm điều đó, thì hệ thống của chúng tôi sẽ không cung cấp việc rút tiền đơn phương, mà không có sự hợp tác của bên thứ ba. Nhiều chương trình dựa trên tổng hợp thất bại ở đây: chúng bị lỗi tính khả dụng của dữ liệu, trong đó người dùng không thể lấy lại tiền của họ nếu điều phối viên bên thứ ba ngoại tuyến, vì họ không có cách nào lấy dữ liệu cần thiết để xây dựng giao dịch thu hồi quỹ hợp lệ.

Với những ràng buộc này trong tâm trí, các cấu trúc dữ liệu của các quỹ tiền tệ sẽ được dựa trên gì? Không thể tránh khỏi, chúng đều là một loại cây nào đó. Cụ thể là một loại cây merkle nào đó. Chúng phải là một cây, vì đó là hầu như là cấu trúc dữ liệu có khả năng mở rộng duy nhất trong khoa học máy tính; chúng phải được merkelized, vì đó là cách hợp lý duy nhất để cam kết mật mã đối với trạng thái của cây. Cuối cùng, các cập nhật cho cây cuối cùng sẽ được xuất bản trên chuỗi khối Bitcoin, vì đó là chuỗi phương tiện xuất bảnTất cả người dùng L2 chia sẻ, và duy nhất mà chúng ta có thể buộc người dùng phải xuất bản để di chuyển tiền xu. Và bởi vì bất kỳ việc thực hiện hiệp ước nào đều cần các phần của cây để xác minh rằng các quy tắc của hiệp ước đang được tuân theo.

Vì vậy, với lý thuyết cấp cao, làm thế nào để điều này thực sự chuyển thành các tập lệnh và giao dịch Bitcoin?

Giao dịch ký trước cá nhân

Trường hợp suy biến của cây, với chính xác một lá trong đó. Ở đây, trạng thái của quỹ của chúng tôi có thể thay đổi trạng thái, nói một cách đại khái, một lần. Ví dụ, một kênh Lightning tiêu chuẩn rơi vào danh mục này và một khi mở, chỉ có thể đóng. Dữ liệu được xuất bản khi một kênh được đóng là giao dịch chính nó, đó là thông tin đủ để bên đối tác trong kênh tìm hiểu txid từ dữ liệu blockchain và khôi phục quỹ bằng cách tiêu thụ chúng.

Ở đây, chỉ có một "điều ước" cần thiết nhất là điều ước cơ bản nhất: giao dịch được ký trước.

Cây Txout

Mẫu thiết kế tiếp theo, phức tạp hơn, mà chúng tôi thấy trong các hồ bơi quỹ là cây txout. Ark là một ví dụ đáng chú ý. Ở đây, hồ bơi quỹ có thể được chia thành các giao dịch được định nghĩa trước trong cây, được áp dụng bằng các điều khoản đơn giản như các giao dịch được ký trước hoặc CTV, chia giá trị của UTXO đó thành các số tiền nhỏ hơn và nhỏ hơn cho đến khi đạt đến các nút lá có thể tiêu thụ bởi chủ sở hữu đúng.

Quan trọng nhận ra rằng mục đích của cây txout là cung cấp cho người dùng các tùy chọn về cách khôi phục lại quỹ của họ, và những tùy chọn đó đến với một chi phí: một cây txout luôn luôn là một cách tốn kém hơn để chia một nhóm quỹ, trả lại chúng cho chủ sở hữu, so với việc đơn giản chia nhỏ UTXO trong một giao dịch duy nhất. Mỗi tầng trong cây đều tăng chi phí do số byte được sử dụng trong txouts và txins cần thiết để tạo ra tầng đó.

Vì vậy, những loại tùy chọn nào một cây txout có thể cung cấp? Một lần nữa, Ark là một ví dụ tuyệt vời: chúng tôi không muốn việc mua lại trên chuỗi của một V-UTXO duy nhất để yêu cầu mọi V-UTXO phải được đưa vào chuỗi. Bằng cách sử dụng một cây, chuộc lại thay vào đó có thể chia cây thành các phần nhỏ hơn cho đến khi V-UTXO mong muốn được đưa vào chuỗi.

Tương tự như trường hợp giao dịch được ký trước của từng cá nhân, thông tin được công bố chính là các giao dịch chính họ, thông báo cho ví của người dùng khác cách để chi tiêu số tiền của họ nếu cần thiết.

Khả năng mở rộng của các cây txout có kinh tế của quy mô thú vị. Chi phí cho V-UTXO đầu tiên được đưa lên chuỗi, trong một vùng hồ chứa n V-UTXOs, gần như gấp log2(n)log2⁡(n) lần so với một giao dịch đơn lẻ vì log2(n) cấp giao dịch chia phải được đưa lên chuỗi. Tuy nhiên, khi V-UTXO đầu tiên được đưa lên chuỗi, các V-UTXOs sau trở nên rẻ hơn để đổi lấy trên chuỗi vì ai đó đã trả chi phí để khai thác các giao dịch trung gian.

Hãy nhớ rằng tổng số phần tử trong một cây nhị phân có

n lá là 2n. Điều này có nghĩa là để đặt tất cả các V-UTXO vào chuỗi, tổng chi phí để làm như vậy thông qua cây txout sẽ là bội số nhỏ của tổng chi phí để làm như vậy trong một giao dịch. Hiệu quả đáng ngạc nhiên!

Hoặc có thể không... Nếu tổng kích thước của việc chuộc lại hồ bơi quỹ đủ lớn, chúng có thể đại diện cho một nhu cầu không nhỏ về tổng lượng không gian khối lượng tổng cộng. Khối lượng không gian khối là một hệ thống cung cầu, vì vậy ở một số điểm phí sẽ tăng lên do nhu cầu cao. Ở mức cực đoan, hoàn toàn có thể tạo ra cây txout rất lớn và rất sâu đến mức thực sự chuộc lại mỗi

Không thể có V-UTXO trong cây.

Một câu hỏi mở về cây txout là ai trả phí và làm thế nào? Một giải pháp hiển nhiên là sử dụng đầu ra neo keyless trên các giao dịch lá và cho phép bất kỳ ai muốn các giao dịch lá được khai thác trả phí qua CPFP. Trong một số trường hợp sử dụng, chính các V-UTXO có thể được tiêu thụ ngay sau khi tạo ra mà không cần đợi thời gian CSV, vì vậy các V-UTXO có thể được tiêu thụ để thêm phí qua CPFP.

RBF rất phức tạp để thực hiện do sự cho phép: nơi rõ ràng để lấy phí cho RBF là giá trị V-UTXO. Nhưng làm thế nào để bạn đảm bảo rằng chỉ chủ sở hữu mới có khả năng ký giao dịch phí cao hơn? Trong nhiều trường hợp, không rõ làm thế nào để làm điều này theo cách hiệu quả hơn so với đầu ra neo không cần chìa khóa. Tuy nhiên, việc không làm được điều đó sẽ đặt ra những thách thức nghiêm trọng đối với các chương trình được sử dụng bởi ví của người dùng cuối, có thể không có UTXO để chi tiêu để thực hiện CPFP, nếu bản thân V-UTXOs không thể được chi tiêu ngay lập tức.

Cuối cùng, cần đặt suy nghĩ cẩn thận vào những động lực có trong hệ thống txout tree, có tính đến việc thanh toán phí. Ví dụ, trong một hệ thống giống như Ark, nếu một tập hợp các V-UTXOs riêng lẻ tốn quá nhiều tiền để đáng giá khi chuyển đến các V-UTXOs trên chuỗi, một nhà phối hợp không hợp tác có thể từ chối cho phép những V-UTXOs đó được chuyển đổi ngoại chuỗi, và sau đó lợi dụng bằng cách đánh cắp giá trị của những V-UTXOs đó trong một lần chi tiêu UTXO duy nhất khi đến thời gian chờ đợi.

Nếu điều này là sự thật, có thể nói rằng hệ thống như vậy sẽ không đáp ứng tiêu chí của chúng tôi để trở thành một L2 cho các V-UTXO nhỏ.

Các kế hoạch dựa trên cân bằng

Máy trạng thái của cây txout vẫn tương đối đơn giản: hoặc tồn tại hồ bơi quỹ, hoặc được chi tiêu để tạo ra hai hoặc nhiều hồ bơi quỹ nhỏ hơn. Với các hiệp ước tiên tiến hơn, chúng ta có thể xem xét hồ bơi quỹ như một số dư tiến hóa, với khả năng thêm và trừ tiền từ số dư đó.

Để làm điều này, chúng ta cần thiết lập một máy trạng thái phức tạp. Nhưng chúng ta cũng cần một cơ sở dữ liệu chia sẻ trong bản chất của nó. Tại sao? Bởi vì mục tiêu ở đây là chia sẻ một UTXO (đầu ra giao dịch chưa được tiêu thụ) qua nhiều chủ sở hữu khác nhau. Cuối cùng, nếu chúng ta thực sự muốn có được cải tiến về khả năng mở rộng, chúng ta phải làm điều đó một cách ít nhất có thể đưa dữ liệu sở hữu lên chuỗi.

Những yêu cầu này tự nhiên dẫn đến một cấu trúc dữ liệu giống cây có tính chất merkelized, chẳng hạn như một cây tổng merkle. Việc điều khiển cấu trúc dữ liệu đó tự nhiên sẽ yêu cầu một cái gì đó như OP_CAT, một mã opcode xác minh bằng chứng không biết, hoặc một mã opcode điều khiển cây cụ thể.

Thú vị là, giống như trong cây txout, bạn không thể tốt hơn với tỷ lệ log(n) trong khi vẫn duy trì các tính chất bảo mật tương tự. Tại sao? Hãy giả sử chúng ta có một OP_ZKP giả định mà thông qua một số toán học tiên tiến, cần chỉ 32 byte để chứng minh bất kỳ tuyên bố nào. Trong khi chứng minh zk này có thể chứng minh rằng cấu trúc dữ liệu đã được Merkel hóa đã được thay đổi theo các quy tắc của hệ thống lớp 2, nó sẽ không cung cấp các dữ liệu cần thiết cho người dùng tiếp theo để cũng thực hiện một thay đổi trạng thái. Điều này không đáp ứng tiêu chí ưa thích của chúng ta về cho phép rút tiền vô điều kiện: tốt nhất một người dùng có thể đạt được một khoản rút tiền vô điều kiện. Nhưng không có người dùng nào khác có thể làm được điều đó.

Ngược lại, nếu các phần được sửa đổi của cấu trúc dữ liệu hợp nhất được xuất bản thông qua scriptsig giao ước - ví dụ: anh chị em tiêu hóa trong cây merkle - người dùng tiếp theo có đủ dữ liệu để cập nhật sự hiểu biết của họ về trạng thái hệ thống và bản thân họ rút tiền vô điều kiện.

Một cách tiềm năng để vượt qua vấn đề này là nếu điều khoản yêu cầu chứng minh đã xuất bản trên một phương tiện xuất bản khác với chuỗi Bitcoin. Tuy nhiên, các đảm bảo về an ninh sẽ yếu hơn so với việc sử dụng Bitcoin.

Cuối cùng, hãy chú ý cách mà cây txout và phương pháp dựa trên cân bằng có thể được kết hợp. Nếu cấu trúc dữ liệu đang được thao tác là cây txout, tiền có thể được thêm vào cây txout bằng cách tiêu thụ đầu ra và thêm tiền mới, với một đoạn mã hợp đồng xác minh rằng tiền thực sự đã được thêm vào cây txout. Tương tự, tiền có thể bị loại bỏ bằng tất cả các cơ chế thông thường có sẵn cho một cây txout. Advanced Ark là một ví dụ về lớp hình thức này.

Tỷ lệ dữ liệu thất bại

L2 đạt được việc mở rộng bằng cách thêm yêu cầu tương tác trong các tình huống đối đầu. Gần như trong tất cả các trường hợp điều này có nghĩa là các bên trung thực trong giao thức phải tuân theo các hạn chót để giao dịch được đào; nếu không đáp ứng được hạn chót, có thể bị đánh cắp tiền.

Khả năng chứa khối tối đa trong tất cả các blockchain phi tập trung (và tập trung) được giới hạn bởi các ràng buộc kỹ thuật. Trong Bitcoin, kích thước khối tối đa là sao cho Bitcoin hoạt động về cơ bản ở sức chứa ~100% của thời gian. Vì khai thác Bitcoin hoạt động như một hệ thống đấu giá, đấu giá không gian khối cho người trả giá cao nhất, trong thực tế điều này có nghĩa là tỷ lệ phí tối thiểu để giao dịch được khai thác tăng và giảm khi nhu cầu tăng và giảm.

Tỷ lệ phí luôn là yếu tố ảnh hưởng đến kinh tế và chế độ thất bại của L2. Ví dụ: trong Lightning, các HTLC "có kích thước bụi" quá nhỏ để có thể được mua lại trên chuỗi có lợi nhuận sử dụng một mô hình bảo mật khác với các HTLC lớn hơn. Mặc dù giao thức Lightning chưa thực hiện đúng điều này, nhưng về lý thuyết, ngưỡng này phải động, dựa trên tỷ lệ phí khi chúng tăng và giảm, lý tưởng nhất là đến mức một bên có thể chọn liệu HTLC có tồn tại trong một giao dịch cam kết nhất định dựa trên tỷ lệ phí hay không.

Một loạt các cuộc tấn công đã được đề xuất trong đó tình huống này được kích hoạt có chủ ý trên Lightning, chẳng hạn như lũ lụt và cướp bóc²²và cuộc tấn công đồng loạt thoát ra²³. Vì khả năng blockchain của Bitcoin được chia sẻ cho tất cả các trường hợp sử dụng, vì vậy các cuộc tấn công giữa các hệ thống L2 khác nhau cũng có thể xảy ra: ví dụ kích hoạt một cuộc thoát khỏi Ark để thu lợi từ các kênh Lightning.

L2 chia sẻ UTXO giữa nhiều người dùng vốn đã làm cho những vấn đề này có khả năng tồi tệ hơn, vì trường hợp xấu nhất là nhu cầu không gian khối trong một thất bại cao hơn tương ứng. Khi viết, chúng tôi chưa bao giờ thực sự thấy các lỗi quy mô lớn trên Lightning, nơi số lượng lớn các kênh phải đóng cùng một lúc. Có một lập luận tốt rằng chúng ta nên có thêm kinh nghiệm hoạt động với Lightning và quy mô khoảng 1 UTXO-mỗi người dùng của nó, trước khi đẩy các giới hạn hơn nữa với các chương trình chia sẻ UTXO.

Thứ hai, trước khi các kế hoạch chia sẻ UTXO mới được áp dụng rộng rãi, cần tiến hành nghiên cứu cẩn thận về khả năng sinh lợi của các cuộc tấn công trong thời gian yêu cầu khối cao. Ví dụ, trong một hệ thống như Ark, nơi ASP có thể rút tiền bằng cách sử dụng ít không gian khối hơn các bên khác, có thể xảy ra trường hợp kích hoạt tỷ lệ phí cao một cách cố ý và sau đó thu hồi tiền mà không thể rút tiền một cách có lợi là một hình thức gian lận sinh lợi, vi phạm cả hai điều kiện của chúng tôi cho một hệ thống L2 thực sự.

Dọn dẹp sự đồng thuận

Có một số điều mà Satoshi đã sai trong giao thức Bitcoin ban đầu, đặc biệt là tấn công DoS kịch bản, tấn công timewarp và vấn đề với cây merkle. Trước đó, một số lỗi đồng thuận khác đã được sửa với các soft-fork, như việc chuyển sang đánh giá nLockTime dựa trên thời gian trung bình trước đó, (cố gắng) sửa vấn đề txid trùng lặp, v.v.

Soft-fork gần đây nhất, taproot, đã trải qua quá trình triển khai gây tranh cãi, mất khá nhiều thời gian để thực sự triển khai. Một lý lẽ để thực hiện một soft-fork dọn dẹp đồng thuận trước, trước khi kích hoạt bất kỳ opcode mới nào hoặc các tính năng khác cho các loại L2 mới, là chúng ta sẽ tìm hiểu thêm về sự sẵn lòng của cộng đồng rộng lớn để triển khai điều gì có thể được coi là một soft-fork tương đối không gây tranh cãi mà có lợi ích cho mọi người.

Kiểm tra phuộc mềm phụ thuộc L2

Các nhà phát triển không cần phải chờ đợi một soft-fork xảy ra thực sự để thử ý tưởng của họ. Một phương pháp đặc biệt phức tạp đang được sử dụng bởi các nhà phát triển của Ark trong Ark không hợp đồngđể mô phỏng những điều khoản mà họ cần với các giao dịch đã được ký trước. Điều này cho phép họ thử nghiệm các ý tưởng của Ark với BTC thực, trên mainnet, với các đặc tính tin cậy tương tự, như Ark được mong đợi đạt được với các điều khoản. Sự đánh đổi là Ark không có điều khoản yêu cầu tất cả các bên phải trực tuyến để ký các giao dịch đã được ký trước. Vì clArk hoạt động với BTC thực, nó có thể chứng minh được đủ hữu ích để sử dụng trong sản xuất cho các trường hợp sử dụng cụ thể có thể chịu được sự đánh đổi tương tác.

Một cách tiếp cận đơn giản hơn là giả vờ rằng một số bên không thể thực hiện các hành động mà các điều khoản sẽ ngăn chặn. Ví dụ, nếu giao thức đề xuất muốn sử dụng CTV để áp dụng rằng một cây txout được tiêu tốn trong một cây giao dịch, mỗi lần sử dụng CTV có thể được thay thế bằng NOP hoặc CheckSig. Mặc dù thực tế cây txout không được thực sự áp dụng, mỗi đoạn mã tương tác với cây và từng bên có thể được kiểm tra như thể nó được áp dụng, và vì NOP và CheckSig được phép trong các scripts tiêu chuẩn, giao thức có thể được kiểm tra trên mainnet với các quỹ thực tế.

Các Soft-Forks tiềm năng

Cuộc tiến hành ra sao? Ở đây chúng tôi sẽ phác thảo tất cả các kế hoạch chính của L2 mà chúng tôi đã phân tích và những soft-fork nào là hữu ích (U) hoặc bắt buộc (R) để làm cho các kế hoạch L2 này thành công. Như đã thảo luận ở trên, OP_CAT (và theo tiện ích, Script Revival, bao gồm OP_CAT), có thể giả lập tất cả các soft-fork khác trong danh sách này - ngoại trừ OP_Expire và Fee Sponsorship - vì vậy nếu nhu cầu của dự án được đáp ứng một cách hiệu quả nhất bởi một soft-fork khác trực tiếp, chúng tôi sẽ không bao gồm OP_CAT.

Chúng tôi cũng sẽ không bao gồm tất cả các mã opcode điều khiển cây merkle đề xuất. Chúng đều quá nhỏ, quá cụ thể cho trường hợp sử dụng, để có cơ hội được áp dụng đáng kể vào thời điểm này. Đến mức mà các mã opcode này hữu ích, việc thực hiện tác động của chúng thông qua OP_CAT và/hoặc Script Revival là một con đường có khả năng được áp dụng cao hơn.

CTV là người chiến thắng rõ ràng ở đây, tiếp theo là SIGHASH_ANYPREVOUT (OP_Expire hữu ích cho rất nhiều điều bằng cách là một sửa lỗi tuần hoàn thay thế, nhưng không thiết yếu). CTV thắng vì rất nhiều thứ phù hợp với mẫu thiết kế 'đảm bảo giao dịch chi tiêu khớp với mẫu này'; thậm chí việc xây dựng OP_CAT cũng có thể sử dụng CTV một cách hiệu quả.

Khác với OP_CAT, CTV không có vẻ gây ra nhiều rủi ro vượt quá việc khuyến khích thanh toán phí ngoài kênh trong một số trường hợp. Điều này không phải là lý tưởng. Nhưng không ai đã đưa ra một phương án thay thế được hỗ trợ rộng rãi.

Đề xuất cá nhân của tôi: thực hiện một sửa đổi mềm consensus cleanup, tiếp theo là CTV.

Disclaimer:

1. Bài viết này được in lại từ [petertodd], Chuyển tiếp tiêu đề gốc 'Lộ trình Ethereum có đi chệch hướng không?', Tất cả bản quyền thuộc về tác giả gốc [petertodd]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với Gate Họcđội ngũ, và họ sẽ xử lý nó ngay lập tức.

2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi có nêu, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là cấm.