Tác giả: Ẩn danh
" UTXO được chia sẻ bên long(chia sẻ UTXO)" (sau đây viết tắt là "UTXO được chia sẻ"), như tên cho thấy, cho phép nhiều người dùng chia sẻ quyền sở hữu UTXO và cho phép tiền của họ được đặt trong cùng một UTXO. Trọng tâm của khái niệm này không phải là quản lý các quyền mà là thể hiện và kiểm soát các trạng thái nội bộ - cho phép lưu trữ tiền của nhiều người dùng trong một UTXO, nhưng vẫn đảm bảo quyền giám sát tự chủ mà không vi phạm quyền sở hữu của người dùng khác.
Khái niệm "UTXO dùng chung" đã được chú ý và phát triển từ lâu. Từ góc nhìn rộng nhất, bất kỳ thiết kế nào trong đó có nhiều hơn một bên kiểm soát UTXO đều có thể được tính là loại này. Định nghĩa rộng nhất này cũng sẽ bao gồm UTXO được chia sẻ giữa hai bên, chẳng hạn như "Kênh Lightning". Ngay cả khi chúng tôi cố tình loại trừ việc chia sẻ UTXO giữa hai bên và chỉ bao gồm trường hợp UTXO được chia sẻ bởi ba bên trở lên, thì khái niệm "nhà máy kênh" [1] được đề xuất vào năm 2018 chắc chắn là một tập hợp con của UTXO được chia sẻ. Ngoài ra, khái niệm "nhóm thanh toán (CoinPool)" [2] được đề xuất vào năm 2020, cũng như một số thiết kế "ngẫu nhiên" được đề xuất khi thảo luận về đề xuất "giao ước" [3] , đã bổ sung thêm nội dung cho chủ đề này.
Trên thực tế, những thiết kế mà mọi người nghĩ ra rất đa dạng đến mức gần như gây nhầm lẫn và bối rối (ít nhất là đối với tôi). Những trở ngại đối với sự hiểu biết này đòi hỏi chúng ta phải tóm tắt những điểm chung của các thiết kế này, xác định khái niệm cơ bản và giải thích các thiết kế này dựa trên khái niệm cơ bản này và thuật ngữ hỗ trợ.
Điều đáng nói là một số tác giả đã bắt đầu thực hiện điều này một cách rõ ràng (coi các khái niệm có vẻ khác nhau như các thiết kế khác biệt trên cùng một khái niệm) [4] ; Giao diện chủ đề của Optech cũng kết hợp "nhóm thanh toán" và "nhóm thanh toán" với ý nghĩa tương tự. đã được sáp nhập thành tên "Joinpool" [5] (nhưng các khái niệm cơ bản về "Joinpool" và "nhà máy kênh" vẫn chưa được đề xuất).
Lấy cảm hứng từ những nỗ lực này, bài viết này cố gắng sử dụng "UTXO dùng chung" làm khái niệm cơ bản, thảo luận về các vấn đề cơ bản mà khái niệm này gặp phải, đồng thời giải thích các hình thức và đặc điểm của một số thiết kế phổ biến (như nhà máy kênh, Statechain, ARK).
Trước đó, chúng ta cần giải thích một số khái niệm cơ bản hơn.
khái niệm cơ bản
giao dịch cam kết
Trong giao thức hợp đồng, "giao dịch cam kết" đề cập đến giao dịch được ký bởi đối tác (và do đó hợp lệ và khả dụng), nhưng không được phát ra bên ngoài theo mặc định. Những giao dịch này có thể được coi là một “cam kết đáng tin cậy” do đối tác đưa ra và là sự đảm bảo cho người tham gia để đảm bảo rằng họ có thể đơn phương rút số tiền mà họ xứng đáng được hưởng.
Ví dụ, trong kênh sét, khi kênh được khởi tạo và lần trạng thái kênh được cập nhật, cả hai bên phải bàn giao giao dịch cam kết cho đối tác; các giao dịch cam kết này ghi lại trạng thái (số dư) mới nhất của hai bên trong kênh; kênh Sau khi được gửi tới Sau khi được xác nhận trên Chuỗi, số tiền của kênh sẽ phân tách cho cả hai bên.
Điều được nhấn mạnh ở đây là khả năng của các giao dịch cam kết thể hiện trạng thái nội bộ của hợp đồng. Kênh sét chỉ xuất hiện dưới dạng UTXO trên Chuỗi, nhưng nó có thể chứa tiền của hai người dùng trong đó. Nó phụ thuộc vào khả năng thực hiện giao dịch.
txO
Trong ngữ cảnh "UTXO được chia sẻ", "vTXO (UTXO ảo)" đề cập đến đơn vị tiền cơ bản nhất của người dùng nằm trong UTXO. Thuật ngữ này được đề xuất để thuận tiện cho việc phân tích và diễn đạt. Nhưng đồng thời, tiêu đề như vậy cũng có cơ sở thực tế chặt chẽ: vì chúng tôi thể hiện tiền của người dùng dưới dạng đầu ra của một giao dịch đã cam kết (TXO), hành động của các quỹ này không khác gì UTXO.
Ở đây, tôi chia vTXO thành hai loại: (1) Quỹ sở hữu độc quyền (giống như UTXO chữ ký đơn thông thường), có thể gọi là "coin"; (2) Kênh Lightning . Lý do tại sao nó được chia thành hai loại ở đây (thay vì coi kênh Lightning là UTXO được chia sẻ và do đó coi nó là loại duy nhất trước đây) là vì: (1) Đầu ra giao dịch của kênh Lightning đều có các tính năng sau để triển khai: "Cơ chế cập nhật ngoài Chuỗi" và các thiết bị được thiết kế đặc biệt không thể được tính là tiền xu; (2) Trải nghiệm sử dụng quỹ sở hữu độc quyền rất khác so với kênh Lightning: Kênh Lightning cho phép bắt đầu thanh toán ngay lập tức ( đồng thời, Lightning Network có thể khuếch đại khả năng thanh toán này) và quy mô thanh toán có thể được điều chỉnh; nhưng đối với các quỹ thuộc sở hữu độc quyền thì lượng lớn hai điều này đều không thể thực hiện được; các kênh Lightning và có những thuật ngữ có thể mô tả các đặc điểm này. Không cần thiết phải diễn đạt nó như một UTXO được chia sẻ và sau đó diễn đạt lại các đặc điểm này theo UTXO được chia sẻ, việc coi nó như một đơn vị có thể phân tích cơ bản sẽ mang lại sự tiện lợi lớn.
Sự phân loại này, nhìn lên, tất nhiên là không hoàn hảo, nhưng nó rất hữu ích. Trong tương lai, chúng ta sẽ thấy rằng từ nhìn lên chính thức, một số thiết kế (chẳng hạn như kênh một chiều với các nhà cung cấp dịch vụ) dường như cũng đáp ứng được lý do phân loại của kênh Lightning, nhưng cách sử dụng thực tế của chúng gần với tiền xu hơn trong trường hợp này; , Tôi vẫn phân loại nó là đồng xu.
Cơ chế cập nhật ngoài Chuỗi
Chỉ có một “giao dịch cam kết” là không đủ để xây dựng kênh Lightning. Hãy tưởng tượng rằng nếu chúng ta chỉ có thể cho phép lưu trữ tiền của hai người dùng trong cùng một UTXO, nhưng lần họ muốn thanh toán cho nhau, họ vẫn cần bắt đầu giao dịch trên Chuỗi, thì tính thực tế của cấu trúc này rất đáng giá Nghi ngờ. Thành công của Lightning Channel nằm ở việc thiết kế một cơ chế có thể sử dụng để cập nhật các giao dịch cam kết ngoài Chuỗi("LN-Panelty"), cho phép cả hai bên thanh toán cho nhau mà không cần thực hiện các giao dịch trên Chuỗi.
Trong bối cảnh các UTXO được chia sẻ, các cơ chế cập nhật ngoài Chuỗi đề cập đến các cơ chế có thể chuyển tiền giữa các vTXO mà không yêu cầu xác nhận Chuỗi.
UTXO được chia sẻ
Trong bài viết CoinPool [2] , hai tác giả đã tóm tắt một tính năng quan trọng: "rút lệnh tùy ý không tương tác", nghĩa là bất kể khi nào họ thoát, người dùng luôn có thể lấy lại số tiền họ xứng đáng và quá trình rút tiền không cần để được sự giúp đỡ từ người khác. Tôi cho rằng rằng thuộc tính này là thuộc tính cơ bản của UTXO được chia sẻ. Nếu không có thuộc tính này, nó sẽ bị giảm xuống thành một giải pháp lưu ký; cho dù có loại thiết kế nội bộ nào trong giải pháp lưu ký này thì nó cũng không thể được gọi là "UTXO được chia sẻ".
Về mặt kỹ thuật, điều này có nghĩa là chúng tôi cần cho phép mỗi bên (mọi người nắm giữ vTXO) phủ quyết việc thay đổi trạng thái của UTXO được chia sẻ. Nếu không, có thể xảy ra tình huống trong đó phần lớn người tham gia vi phạm quyền sở hữu tiền của người tham gia. Nghĩa là, tất cả những thay đổi trạng thái có thể xảy ra phải được sự đồng ý của từng người tham gia (trước hoặc ngay lập tức).
Ví dụ: nếu có ba người dùng chia sẻ UTXO thì cho dù A sử dụng tiền để thực hiện trong đó toán bên ngoài hay A muốn thanh toán cho B, miễn là giao dịch sử dụng UTXO được chia sẻ làm đầu vào thì phải đảm bảo rằng không có Được sự đồng ý của chữ ký C, các giao dịch này sẽ không có hiệu lực. Nếu không, A và B có thể âm mưu biển thủ tiền của C.
Tuy nhiên, xét về mặt thực tế, điều này đặt ra một thách thức: một khi người dùng ngoại tuyến, khả năng cập nhật trạng thái của những người dùng khác sẽ bị ảnh hưởng (mặc dù khả năng rút tiền không bị ảnh hưởng). (Tương tự như kênh Lightning, nếu đối tác ngoại tuyến, bạn sẽ không thể vận hành tiền trong kênh).
Có thể nói rằng tất cả các thiết kế UTXO được chia sẻ đều đang đáp ứng thách thức này.
Tiếp theo, chúng tôi sẽ sử dụng sê-ri ví dụ để giới thiệu hình thức thể hiện trạng thái bên trong UTXO được chia sẻ và loại vTXO, cách xác định tác động của người dùng ngoại tuyến đến UTXO được chia sẻ và từ đó ảnh hưởng đến tính thực tiễn và trải nghiệm người dùng của UTXO được chia sẻ. chia sẻ UTXO.
kiểm soát tắc nghẽn
Trước tiên hãy xem xét UTXO được chia sẻ nhiều người đơn giản nhất: n các bên đều sở hữu tiền (vTXO) trong một UTXO và các vTXO này đều được kiểm soát độc quyền; và nó đã được ký bởi những người khác); sau khi giao dịch cam kết như vậy được phát sóng và xác nhận khối, UTXO được chia sẻ này sẽ bị phân hủy hoàn toàn, nghĩa là trạng thái nội bộ được hiển thị hoàn toàn và mọi người đều nhận được số tiền ban đầu được lưu trữ trong tài khoản chung. UTXO. Như được hiển thị bên dưới:
Đây là thiết kế đơn giản nhất: vTXO sử dụng loại đơn giản nhất, không có cơ chế cập nhật ngoài Chuỗi(vì vậy ba người không thể bắt đầu thanh toán nội bộ ra khỏi Chuỗi) và việc một người đơn phương rút tiền sẽ dẫn đến việc rút tất cả. Việc sử dụng cấu trúc như vậy là gì?
Jeremy Rubin đặt tên cho cấu trúc này là "kiểm soát tắc nghẽn" dựa trên kịch bản sử dụng của nó: khi phí xử lý tăng, nhiều khoản thanh toán cần thực hiện sẽ được "lưu trữ" trong UTXO, chờ phí xử lý giảm xuống mức có thể chấp nhận được. cấp độ, các khoản thanh toán này được trải đều trên Chuỗi. Ví dụ: nếu Alice và ba người còn lại muốn rút tiền từ một sàn giao dịch giám hộ khi phí tăng lên, sàn giao dịch có thể phối hợp ba bên khởi tạo một UTXO chung và chuyển tiền của ba người sang UTXO chung này trước tiên; Khi đó, ba người lại hợp tác hoặc sử dụng giao dịch cam kết trong tay để rút trong đó.
Nếu ba người có thể được đảm bảo trực tuyến mọi lúc, tính hữu ích của cấu trúc này sẽ được cải thiện rất nhiều: ba người có thể điều phối thêm phí xử lý; họ cũng có thể thanh toán trực tiếp cho người khác mà không cần sử dụng địa chỉ thanh toán được sử dụng trong giao dịch tái cam kết. Nhưng trong trường hợp người dùng ngẫu nhiên, điều này không được đảm bảo. Trong trường hợp thoát không hợp tác, do giao dịch cam kết đã khóa trước phí xử lý nên người dùng muốn tăng tốc xác nhận chỉ có thể sử dụng giao dịch phụ để thêm phí xử lý (tức là "CPFP" [6] ), nhưng không thể sử dụng "thay thế phí" (RBF)".
Liên quan đến vấn đề này, một lĩnh vực khác có thể bị chỉ trích là cơ chế thoát chung của nó: trong tình huống không hợp tác, nếu người dùng háo hức thoát hơn những người khác và không thể đạt được tốc độ xử lý đặt trước của giao dịch đã cam kết thì TA sẽ hoàn toàn chịu trách nhiệm về phí xử lý bổ sung khi xác nhận tất cả các UTXO này trên Chuỗi. Điều này có nghĩa là nếu tất cả người dùng trong UTXO kiểm soát tắc nghẽn không có cùng sở thích về thời gian và kiểu sử dụng, thì trải nghiệm người dùng sẽ bị tổn hại hoặc thậm chí biến thành thảm họa.
Có cách nào để chỉ bật lên một vTXO thay vì mở rộng tất cả vTXO không? Rõ ràng là có - đó chỉ là "chỉ" việc sử dụng độ sâu cấu trúc kiểm soát tắc nghẽn.
Cải thiện kiểm soát tắc nghẽn
Như trong hình bên dưới, chúng ta có thể khởi tạo UTXO kiểm soát tắc nghẽn như thế này: khi Alice muốn đơn phương rút tiền, giao dịch cam kết mà cô ấy có thể sử dụng sẽ chỉ hiển thị vTXO thuộc về cô ấy và số tiền còn lại sẽ được trả lại cho người khác một thuộc về những người tham gia còn lại UTXO kiểm soát tắc nghẽn (chẳng hạn như "UTXO-2 kiểm soát tắc nghẽn" trong hình bên dưới), UTXO kiểm soát tắc nghẽn này cũng được ký trước bằng một giao dịch cam kết, cho phép Bob và Carol đơn phương rút tiền. Điều tương tự cũng áp dụng cho các tình huống khác, vì vậy "Giao dịch cam kết B" và "Giao dịch cam kết C" trong hình bên dưới không được cung cấp thêm chi tiết.
Cấu trúc này có thể giảm bớt đáng kể vấn đề phí xử lý bổ sung được đề cập trước đó, vì người dùng chỉ cần xác nhận thêm một UTXO bất cứ khi nào họ rút tiền.
Hơn nữa, giả sử Alice cũng sẽ chia sẻ chữ ký của mình trên giao dịch cam kết A với mọi người, thì giao dịch này cũng có thể được những người dùng khác sử dụng như một "giao dịch bị loại trừ" - khi Alice không phản hồi trong một thời gian dài, cô ấy sẽ bật lên chia sẻ này UTXO. Hãy để những người dùng còn lại tận hưởng những lợi ích mà UTXO chia sẻ thông thường có thể mang lại cho họ. Điều này cũng có thể hạn chế tác động của tính năng ngoại tuyến của Alice đối với những người dùng khác.
Điểm đáng chú ý là cấu trúc này chỉ cho phép người dùng xếp hàng và thoát từng người một; nếu nhiều người dùng cố gắng thoát ra cùng lúc, thì sẽ xảy ra vấn đề được gọi là " điều kiện cuộc đua ": những người dùng này sẽ bắt đầu tính phí. race., để tranh giành thứ tự xếp hàng (tư cách ra trước). Bởi vì chúng tôi không sắp xếp giao dịch cam kết cho phép nhiều người dùng thoát cùng lúc - nếu có giao dịch cam kết như vậy thì sẽ không có tranh chấp. Ví dụ: khi quan sát thấy Alice sắp thoát, Bob có thể sử dụng giao dịch cam kết được chuẩn bị cho ba người để thoát cùng lúc và sử dụng phương pháp RBF để cung cấp cho giao dịch này mức độ ưu tiên xác nhận cao hơn giao dịch của Alice (đây là Điều tốt là nó rẻ hơn so với việc đợi Alice thoát ra trước và tự mình thực hiện giao dịch); khi giao dịch của Bob được xác nhận, cả ba người họ có thể thoát ra đồng thời.
Thoạt nhìn, có vẻ như không còn nghi ngờ gì nữa về việc nên bổ sung thêm các giao dịch cam kết như vậy để cho phép nhiều người thoát cùng một lúc. Nhưng đồng thời, khái niệm "UTXO được chia sẻ" cũng sẽ bắt đầu cho chúng ta thấy sự tuyệt vời của nó: so với cấu trúc kiểm soát tắc nghẽn đơn giản ở trên, cấu trúc được cải tiến yêu cầu số lượng giao dịch cam kết yêu cầu chữ ký người dùng trong quá trình khởi tạo tăng lên đáng kể. có thể nói, nhu cầu tương tác giữa những người dùng đã tăng lên lượng lớn; hơn nữa, nó không tăng tuyến tính theo số lượng người dùng mà sẽ gây ra cái gọi là "sự bùng nổ kết hợp" nếu một giao dịch cam kết như vậy được thêm vào cho phép nhiều người; để thoát cùng lúc thì số lần thoát sẽ có khả năng bùng nổ hơn nữa (nếu điều này không rõ ràng vì số lượng 3 người quá ít, bạn đọc có thể thử vẽ UTXO dùng chung cho 5 người).
Người dùng cần phải hoàn thành nhiều tương tác như vậy bằng phương tiện giao tiếp nào? (Tất nhiên, đây là Internet, câu hỏi đặt ra là làm thế nào để những người dùng này tìm thấy nhau?) Với khả năng người dùng mất liên lạc trong quá trình khởi tạo sẽ khiến quá trình khởi tạo thất bại hoàn toàn và phải bắt đầu lại từ đầu, có nên chăng một số loại cơ chế chống Phù thủy có được sử dụng không? Đây là tất cả các vấn đề cần xem xét.
Vì vậy, có một số loại ý nghĩa vàng?
cấu trúc cây
Hãy xem xét UTXO được chia sẻ sau đây: Khi Alice muốn rút tiền (hoặc người khác muốn loại trừ Alice), Alice không thể bật lên trực tiếp từ UTXO được chia sẻ mà trước tiên cần phát "Giao dịch cam kết 01", giao dịch này sẽ thay thế UTXO được chia sẻ ban đầu. UTXO được chia làm đôi thành hai UTXO được chia sẻ, sau đó, Alice phát sóng giao dịch cam kết tiếp theo và tiếp tục phân tách UTXO được chia sẻ mà cô ấy tham gia;...v.v., cho đến khi vTXO của cô ấy hoàn toàn thoát ra.
(Những độc giả quen thuộc với lĩnh vực này có thể sẽ thốt lên: “Đây là một cấu trúc hình cây!” Đúng vậy.)
Xét về tính công bằng khi thoát, cấu trúc này không tốt bằng cấu trúc được mô tả ở phần trước: tùy thuộc vào thứ tự Alice thoát, cô ấy hầu như luôn cần xác nhận nhiều hơn 1 UTXO. Trong ví dụ của chúng tôi, nếu cô ấy thoát trước, cô ấy cần xác nhận thêm 2 UTXO. Nếu đó là UTXO dùng chung cho 8 người, cô ấy cần xác nhận thêm 3 UTXO.
Tuy nhiên, nếu nhìn kỹ vào hình trên, bạn có thể nhận thấy những ưu điểm rất lớn của nó, đặc biệt khi số lượng tham số lớn:
(1) Số lượng giao dịch đã cam kết cần ký giảm đi rất nhiều (cấu trúc này yêu cầu thêm một người dùng ký, nhưng số lượng giao dịch đã cam kết cần ký ít hơn cấu trúc trước đó là do có nhiều người dùng); có thể chia sẻ cùng một giao dịch cam kết để thoát;
(2) Nó cũng phần nào giảm bớt vấn đề tranh chấp trạng thái nói trên, bởi vì mỗi khi một UTXO dùng chung được chia ra, sẽ có thêm một UTXO được phép truy cập, tức là có thêm một thao tác người dùng ban đầu được đặt ở một nhánh khác. được phép; giả sử cả Alice và Carol To đều thoát ra, thì sau khi "Giao dịch cam kết 01" được xác nhận, họ có thể hoạt động song song mà không ảnh hưởng đến nhau;
(3) Nó cũng giúp các cơ chế cập nhật ngoài Chuỗi hoạt động dễ dàng hơn (nếu có). Giả sử Alice ngoại tuyến, trong cấu trúc kiểm soát chặn đơn giản mà chúng tôi đã đề cập trước đó, cơ chế cập nhật ngoài Chuỗi cũng sẽ dừng trong cấu trúc được cải tiến nêu trên, mặc dù những người khác có thể cập nhật giao dịch cam kết ban đầu không bao gồm Alice, nhưng họ cần; để cập nhật Một số lượng lớn cũng sẽ gây khó khăn cho việc thiết kế và tăng độ phức tạp của việc phân tích; trong cấu trúc này, vì số lượng giao dịch cam kết giảm đi đáng kể và các giao dịch cam kết không bao gồm Alice rất dễ xác định và phân tích, điều đó là đúng. tự nhiên dễ dàng hơn để thiết kế cơ chế cập nhật ngoài Chuỗi.
Tóm lại, trong các phần này, chúng tôi đã phân tích tác động của biểu thức trạng thái nội bộ UTXO được chia sẻ đến tính thực tế và trải nghiệm người dùng của nó. Ba biểu thức này có thể tạm gọi là "cấu trúc hạt", "cấu trúc sao-mặt trăng" và "cấu trúc cây". Vẫn chưa rõ ba cấu trúc này được đề xuất ban đầu như thế nào, nhưng tôi nghĩ chắc chắn có nhiều nhà phát triển đã nghĩ đến những cấu trúc này.
Trong những phân tích này, chúng tôi cũng đã tìm hiểu về nhiều thách thức mà các UTXO dùng chung có thể gặp phải trong vòng đời của chúng.
Tiếp theo, chúng tôi phân tích sâu hơn về tác động của loại vTXO.
Kênh xu so với kênh Lightning
Hãy xem hình thức UTXO được chia sẻ sau đây về đặc điểm, nó khác với cấu trúc "kiểm soát tắc nghẽn" như thế nào?
Có, nó sử dụng cấu trúc biểu hiện trạng thái giống hệt như kiểm soát tắc nghẽn, nhưng chính xác là vì các vTXO này không phải là những đồng tiền được kiểm soát độc quyền mà là các kênh sét, nên ngay cả khi UTXO được chia sẻ này cũng không triển khai cơ chế cập nhật Chuỗi(không thể cho phép. chuyển tiền giữa các vTXO) không ảnh hưởng đến khả năng thanh toán của những người dùng này vì họ đã mở các kênh sét giữa nhau! Họ có thể thanh toán cho nhau hoặc có thể bắt đầu và nhận thanh toán Lightning với sự trợ giúp của các đối tác trong các kênh chia sẻ. Điều duy nhất họ không thể làm là thay đổi kích thước kênh của mình trong UTXO được chia sẻ này - điều này đòi hỏi phải bắt đầu một giao dịch trên Chuỗi, giống như UTXO được chia sẻ này hơn.
Ví dụ này minh họa tác động của loại vTXO đối với trải nghiệm người dùng của UTXO được chia sẻ. Nó cũng minh họa rằng ngay cả khi cấu trúc biểu thức trạng thái không thay đổi, trải nghiệm người dùng có thể được cải thiện ở các khía cạnh khác. Tất nhiên, điều này cũng đòi hỏi phải tăng số lượng giao dịch đã cam kết mà người dùng cần ký trong giai đoạn khởi tạo.
Trên thực tế, hình trên được lấy cảm hứng từ nhà máy sản xuất kênh - thiết kế UTXO được chia sẻ nổi tiếng. Không giống như nhà máy kênh, ở đây tôi giả định rằng nó không có cơ chế cập nhật ngoài Chuỗi(trong khi nhà máy kênh có, ít nhất là nó được giả định là có). Nếu có một cơ chế như vậy thì ba người dùng này có thể điều chỉnh kích thước của các kênh với nhau mà không cần bắt đầu các giao dịch trên Chuỗi - điều này có những công dụng rõ ràng.
Cơ chế cập nhật off- Chuỗi bên long
Cơ chế cập nhật Chuỗi chuỗi có thể làm tăng đáng kể tiện ích của các UTXO dùng chung: khi vTXO là quỹ được kiểm soát độc quyền, cơ chế cập nhật Chuỗi chuỗi cho phép những người dùng này thanh toán cho nhau khi vTXO là kênh Lightning, cơ chế cập nhật Chuỗi chuỗi cho phép các kênh này điều chỉnh; kích thước của chúng.
Tuy nhiên, ngay cả khi đó là bản cập nhật Chuỗi, tất cả những người tham gia sẽ bị ảnh hưởng bởi trạng thái thay đổi đều phải có mặt trước khi có thể sử dụng (nếu không sẽ không an toàn). Vì vậy, một cơ cấu đại diện nhà nước phù hợp sẽ tạo thuận lợi cho hoạt động của nó.
Cuối cùng, mặc dù cơ chế cập nhật Chuỗi chuỗi có thể có tác dụng tương tự như kênh sét vTXO trong một số điều kiện nhất định, nhưng điều này không có nghĩa là việc phân loại các loại vTXO của chúng tôi là dư thừa, cũng không có nghĩa là cơ chế cập nhật Chuỗi chuỗi nên được xem xét như một yếu tố độc lập là dư thừa. Cả sự tiện lợi và đầy đủ trong phân tích đều yêu cầu chúng ta xác định chúng là hai yếu tố độc lập.
Tiếp theo, chúng tôi sẽ giới thiệu một số cơ chế cập nhật ngoài Chuỗi bên long . (Nếu bạn không quan tâm đến các chi tiết kỹ thuật, bạn có thể chuyển thẳng sang chương tiếp theo.)
Trong kênh Lightning, cơ chế cập nhật trạng thái ngoài Chuỗi được triển khai bằng cách cài đặt một thiết bị đặc biệt ở đầu ra của giao dịch cam kết: bất cứ khi nào trạng thái được cập nhật và giao dịch cam kết mới được trao đổi, cả hai bên sẽ sử dụng cam kết trước đó của mình. giá trị trong giao dịch được trao cho bên kia. Nếu một bên phát đi giao dịch cam kết lỗi thời như vậy thì bên kia sẽ có thể sử dụng giá trị bí mật tương ứng để lấy đi trước giá trị trong đầu ra thuộc về bên gian lận (hoặc bất cẩn). Điều này thực hiện một cơ chế phạt nhằm ngăn cản cả hai bên phát sóng các giao dịch đã cam kết lỗi thời.
Cơ chế như vậy cực kỳ khó mở rộng thành cơ chế cập nhật Chuỗi bên long . Cụ thể, khi một bên nộp trạng thái lỗi thời, bên đó thực sự có thể bị trừng phạt, nhưng các bên khác cũng bị đẩy về trạng thái cũ và không thể phân chia ngay quỹ theo trạng thái mới nhất. Giải pháp là làm cho mọi giao dịch cam kết đại diện cho trạng thái cũ có thể chi tiêu được bằng giao dịch cam kết đại diện cho trạng thái cập nhật trong một cửa sổ, đảm bảo rằng tiền luôn có thể được phân chia và áp dụng hình phạt theo trạng thái mới nhất. Vấn đề là điều này sẽ khiến số lượng giao dịch đã cam kết cần được ký lần bản cập nhật tăng trưởng cùng với số lượng cập nhật trạng thái đã xảy ra và số lượng giao dịch đã cam kết cần được lưu sẽ tăng trưởng bậc thang theo cách thức . Như được hiển thị bên dưới:
在第2 次更新状态时：共享UTXO --> 承诺交易#0 --> 承诺交易#01 --> 承诺交易#012共享UTXO --> 承诺交易#1 --> 承诺交易#12共享UTXO --> 承诺交易#2注1：承诺交易#0 表达的是初始状态。注2：纵向同一位置的承诺交易表达的是相同的状态。Bằng cách này, mặc dù tính bảo mật của các cập nhật trạng thái được đảm bảo nhưng gánh nặng tương tác và lưu trữ của người tham gia là rất lớn. Hơn nữa, khi người dùng phát sóng giao dịch cam kết cũ lên Chuỗi, để sử dụng kênh quyết toán trạng thái mới nhất, điều đó có thể. cần thiết cho Toàn bộ chuỗi giao dịch cần được xác nhận trên Chuỗi(ví dụ: Alice sẽ cam kết giao dịch #0 cho Chuỗi, sau đó những người khác sẽ tiếp tục phát #01 và #012 cho Chuỗi), có rất ít mở rộng.
Đó là lý do tại sao chúng tôi muốn "eltoo". Ý tưởng này đã được đề xuất vào năm 2018 [7] , trong đó đề xuất thẻ SIGHASH mới (tức là ANYPREVOUT, hiện được xác định bởi BIP-118 [8] ); sử dụng thẻ này, chữ ký chỉ có thể chỉ định đầu ra của giao dịch và Không có đầu vào nào được chỉ định, do đó, cùng một tập lệnh luôn có thể được sử dụng để chi tiêu cùng với việc tăng giá trị của trường nLocktime của giao dịch đã cam kết, có thể đạt được hiệu quả như vậy [9] : các giao dịch sau này trong chuỗi giao dịch có thể trực tiếp chi tiêu bất kỳ khoản nào của riêng họ Một giao dịch tổ tiên, bất kể có bao nhiêu giao dịch giữa hai bên khi chúng được ký kết và điều ngược lại không thể đúng. Nghĩa là, khi Alice đặt #0 trên Chuỗi, những người khác có thể phát trực tiếp #012, bỏ qua #01 ở giữa (thực ra lúc này không cần #012 nữa mà chỉ cần #2). Điều này giúp giảm bớt đáng kể gánh nặng tương tác và lưu trữ của người tham gia và tiết kiệm mở rộng.
Tuy nhiên, eltoo yêu cầu chúng tôi kích hoạt SIGHASH_ANYPREVOUT thông qua soft fork nên cơ chế này hiện không khả dụng.
Vào năm 2022, John Law đã đề xuất một cơ chế cập nhật Chuỗi khác được gọi là "Giao thức bảng điều chỉnh có thể điều chỉnh" [10] .
Trong cơ chế này, giao dịch cam kết (CT) đại diện cho trạng thái (có khóa thời gian tương đối) không chỉ lấy UTXO được chia sẻ làm đầu vào mà còn có thêm một đầu vào nhỏ (Bụi) từ người tham gia trước khi chia sẻ một lượng UTXO khác. quỹ. Khi một người tham gia, chẳng hạn như Alice, cố gắng thực hiện một giao dịch cam kết, đầu vào nhỏ trước tiên phải được xác nhận, nghĩa là ST ("giao dịch trạng thái") cần được phát hành. Và ST có một đầu ra khác, thực chất là khoản tiền gửi (Stake), vì khi cập nhật trạng thái, người tham gia phải cung cấp private key của khoản tiền gửi này.
Hiệu ứng cuối cùng là nếu người tham gia cố gắng thực hiện một giao dịch cam kết cũ, thì ST cũ phải được đưa vào Chuỗi trước, điều này sẽ khiến tiền gửi của nó bị lấy đi - tại thời điểm này, UTXO được chia sẻ vẫn chưa được sử dụng và do đó không ảnh hưởng đến khả năng sử dụng trạng thái mới nhất của tất cả người dùng. Tương tự, TPP thiết kế một giai đoạn chuẩn bị cho việc phân tách UTXO dùng chung, để những người dùng cố gắng lừa đảo (hoặc bất cẩn) không thể trực tiếp vận hành UTXO dùng chung, do đó tránh được vấn đề cần phải phát lại chuỗi giao dịch đã đề cập trước đó.
Một trong những lợi thế lớn của TPP là nó không yêu cầu thay đổi các lớp cơ bản của Bitcoin và có thể được triển khai ngay bây giờ.
Trên thực tế, có một cơ chế cập nhật bên long rất đơn giản, đó là giao dịch cam kết dựa trên khóa thời gian. Nó ra đời từ việc nghiên cứu các kênh hai bên [11] .
Trong cơ chế này, bản thân giao dịch cam kết có khóa thời gian ở cấp độ giao dịch và lần trạng thái được cập nhật, người tham gia sẽ ký một giao dịch cam kết với khóa thời gian ngắn hơn (để có thể công bố và xác nhận nhanh hơn). Bản thân khóa thời gian ngăn chặn vấn đề xung đột giao dịch cam kết, do đó không cần thiết kế thêm cơ chế để giải quyết khả năng xảy ra xung đột như vậy (người dùng giải phóng giao dịch cam kết đại diện cho trạng thái cũ).
Cơ chế này đơn giản và dễ thực hiện đến mức việc thảo luận về hai cơ chế trên dường như vô nghĩa. Nhưng đó không phải là trường hợp. Một lỗ hổng nghiêm trọng của cơ chế này là nó có tuổi thọ rõ ràng - sau một số lần cập nhật nhất định, UTXO được chia sẻ mới chỉ có thể quyết toán và thiết lập lại. Mặc dù nó có thể được giảm thiểu (ví dụ: một trong những phương pháp giảm thiểu là chèn nhiều giao dịch trung gian giữa UTXO được chia sẻ và giao dịch cam kết cuối cùng biểu thị trạng thái nhân lên khóa thời gian tương đối), nhưng về cơ bản thì không thể giải quyết được.
Lạc đề: Đề xuất hạn chế liên quan đến việc chia sẻ UTXO
Mặc dù các UTXO được chia sẻ thường được thảo luận cùng với các đề xuất soft fork khác nhau nhằm triển khai các điều khoản hạn chế, nhưng cho đến nay tôi hầu như không đề cập đến chúng. Lý do là mặc dù những hạn chế được đề xuất này có thể được sử dụng để hỗ trợ hoạt động của UTXO dùng chung nhưng chúng không xác định được các đặc điểm cơ bản của UTXO dùng chung - và chỉ bằng cách hiểu các đặc điểm cơ bản của UTXO dùng chung, chúng ta mới có thể hiểu được vai trò của những hạn chế này trong vấn đề này. kịch bản. Việc sử dụng nó là gì?
Chúng tôi phân tích ngắn gọn ba đề xuất ở đây: OP_TLUV [12] , OP_CTV [13] và OP_EVICT [14] .
Như đã đề cập trước đó, khi xây dựng UTXO dùng chung, cần có lượng lớn tương tác (ký lượng lớn giao dịch cam kết để đảm bảo an ninh), điều này sẽ cản trở tính thực tế và trải nghiệm người dùng của nó. Về vấn đề này, giải pháp của OP_TLUV là sử dụng cấu trúc cây tập lệnh Merkle của Taproot để chuyển trạng thái của người dùng vào các lá của cây tập lệnh. Khi người dùng cần thoát đơn phương, họ có thể tiết lộ lá này và thoát ra với số tiền được ghi trong đó TLUV sẽ xác minh số tiền và đảm bảo rằng số tiền còn lại được chuyển sang đầu ra taproot mới không còn cho phép thoát; Người dùng đã tham gia - khóa công khai của anh ta đã bị xóa khỏi khóa chung nội bộ của taproot và tập lệnh của anh ta đã bị xóa khỏi Merkle trees.
Vì bản thân cây tập lệnh Merkle có thể cam kết trạng thái quỹ của người dùng nên người dùng không cần phải ký giao dịch cam kết trong quá trình khởi tạo và tương tác, nó chỉ cần xác minh đầy đủ khóa công khai nội bộ và đầu ra thành phần cây tập lệnh bằng taproot. Điều này làm giảm đáng kể nhu cầu tương tác.
Những độc giả quen thuộc với các thiết kế giao thức khác trong lĩnh vực này có thể nói: Đây không phải là thiết kế "cây trạng thái" phổ biến theo mô hình trạng thái sao? Vâng, chính xác là như vậy. Nhưng đánh giá từ phân loại cấu trúc trước đây của chúng tôi, thiết kế này nên được phân loại là cấu trúc mặt trăng sao thay vì cấu trúc cây - nó cho phép một người dùng thoát trực tiếp và khiến những người dùng khác không bị ảnh hưởng, thay vì lần đôi UTXO được chia sẻ. Tương ứng, chúng ta cũng có thể tưởng tượng một cấu trúc cây sử dụng OP_TLUV - cây tập lệnh được cam kết chi trả một nửa số tiền của người tham gia và khóa chung tổng hợp.
Thật trùng hợp, OP_CTV cũng có thể được sử dụng để hỗ trợ thiết kế này. Bởi vì, OP_CTV cho phép chúng ta tạo một tập lệnh chỉ được chi tiêu bởi các giao dịch có đặc điểm nhất định, bao gồm số tiền đầu ra và tập lệnh. Do đó, chúng tôi cũng có thể chuyển giao giao dịch rút tiền của người dùng vào các lá của cây tập lệnh Merkel, cho phép người dùng đơn phương sử dụng nó - dù sao đi nữa, kết quả của việc sử dụng là số tiền của anh ta được rút và số tiền còn lại sẽ nhập vào UTXO, điều này cũng đã bị chúng tôi khóa bằng khóa công khai nội bộ thích hợp và cây tập lệnh Merkle, cho phép những người dùng còn lại đơn phương thoát ra.
So với OP_TLUV, trong cách sử dụng OP_CTV này, người dùng cần xác minh nhiều thứ hơn (cần xác minh rằng mỗi bước rút tiền sẽ chuyển số tiền còn lại vào đúng cây tập lệnh), nhưng cũng không cần ký giao dịch cam kết ( đã được xác minh Số lượng giống như khi chỉ sử dụng giao dịch cam kết).
Ý tưởng của OP_EVICT là thực hiện một cách tiếp cận khác. ZmnSCPxj, tác giả của OP_EVICT, nhận thấy rằng trong cấu trúc mặt trăng sao sử dụng OP_TLUV, việc thoát một giao dịch yêu cầu tiết lộ đường dẫn Merkle trees của các lá của chính nó; trong khi sử dụng cấu trúc cây cũng yêu cầu tiết lộ nhiều giao dịch tương tự như đường dẫn Merkle trees; . Có cách nào để tránh chi phí này?
Ý tưởng của OP_EVICT là cho phép người dùng ký trực tiếp vào đầu ra (khóa công khai và số tiền) đồng thời làm cho chữ ký đó có thể hiểu được bằng mã hoạt động OP_EVICT và được sử dụng để xác minh xem đầu ra giao dịch hiện tại có phù hợp với đầu ra đã ký hay không. Sau khi xác minh chữ ký và đầu ra tương ứng, OP_EVICT sẽ trừ khóa chung ký từ khóa chung nội bộ của taproot và yêu cầu khóa chung còn lại để ký giao dịch. Theo cách này, nó tương đương với khóa công khai nội bộ của chính taproot cam kết với thành phần của những người tham gia và tiền của người tham gia không cần phải được cam kết bởi Merkle trees, chỉ có chữ ký của chính khóa chung (và chữ ký đầu ra của người dùng khác) Bảo vệ.
OP_EVICT còn có một ưu điểm lớn: nó cho phép nhiều người dùng đăng xuất cùng một lúc. Do đó, nó có thể thực hiện cấu trúc sao-mặt trăng mà không gặp vấn đề về tranh chấp. (Nói chính xác hơn, chế độ tư duy của OP_EVICT là khác. Nó cho rằng người dùng hiếm khi cần đơn phương rút tiền. Ngược lại, vấn đề khó xử lý là một (một số) người dùng ngoại tuyến và những người dùng khác không thể sử dụng UTXO được chia sẻ Do đó, điều cần thiết là một công cụ có thể loại trừ người dùng ngoại tuyến một cách hiệu quả. Sau khi người dùng ngoại tuyến bị loại trừ, những người dùng còn lại có thể cập nhật trạng thái của họ thông qua hợp tác. Do đó, lối thoát của chính người dùng không phải là cách sử dụng opcode này "bình thường". . )
So với hai cách trước, vì không có phương pháp rõ ràng để cam kết trạng thái nên sẽ yêu cầu nhiều tương tác hơn giữa những người dùng, nhưng cũng ít hơn đáng kể so với trường hợp chỉ sử dụng các giao dịch cam kết.
Tóm lại, công dụng chính của các opcode ràng buộc trong các kịch bản UTXO dùng chung là để giảm yêu cầu tương tác. Nó có thể giảm chi phí hoạt động của một số cấu trúc biểu thức trạng thái nhất định, nhưng nó không xác định cấu trúc nào chúng ta có thể sử dụng. Việc nghiên cứu cấu trúc sẽ không mất đi ý nghĩa vì sự xuất hiện của các mệnh đề hạn chế.
Chia sẻ các trường hợp thiết kế UTXO
kênh bên long
Như được hiển thị trong hình trên, đây là UTXO kiểm soát tắc nghẽn với cơ chế cập nhật ngoài Chuỗi(vTXO là cấu trúc hạt bằng đồng xu và cơ chế cập nhật Chuỗi chuỗi).
Đôi khi, cơ cấu trong hình dưới đây cũng được coi là kênh bên long.
So với các kênh Lightning phi tập trung (và các kênh phân cấp sẽ được giới thiệu bên dưới), ưu điểm của kênh bên long là ít gặp rắc rối hơn bởi “hạn ngạch nhận (thanh khoản được tính)”. Nhược điểm là khó chống lại sự ảnh hưởng của người dùng ngoại tuyến hơn.
kênh nhiều lớp
“Kênh phân cấp” là ý tưởng được John Law đề xuất vào năm 2023 [15] . Nó sử dụng cấu trúc cây và vTXO là kênh sét. Đồng thời, tác giả đề xuất sử dụng TPP làm cơ chế cập nhật ngoài Chuỗi.
nhà máy kênh
Nhà máy sản xuất kênh sử dụng cấu trúc hạt, vTXO là kênh sét (có một kênh sét giữa hai người dùng chia sẻ UTXO) và các giao dịch cam kết giảm khóa thời gian được sử dụng làm cơ chế cập nhật ngoài Chuỗi.
Chuỗi trạng thái
Ý tưởng cơ bản của “Statechain” [16] là bằng cách chuyển private key điều khiển UTXO, UTXO có thể được chuyển hoàn toàn mà không cần giao dịch trên Chuỗi. Để tạo điều kiện thuận lợi cho việc chuyển giao như vậy, hai bên (người dùng và nhà cung cấp dịch vụ) cần cùng xây dựng khóa chung (cả hai bên chỉ có một nửa private key đằng sau khóa chung) và gửi tiền vào khóa chung này (để đảm bảo rút tiền không cần tin cậy, bạn cũng cần ký trước giao dịch cam kết có khóa thời gian); khi thanh toán, người thanh toán và/hoặc nhà cung cấp dịch vụ trước tiên phải hiển thị cho người nhận lịch sử chuyển quyền sở hữu theo Chuỗi UTXO để chứng minh tính xác thực của giao dịch. tiền; sau đó, trả tiền. Người nhận giao chữ ký của mình để bày tỏ sự sẵn sàng thanh toán; người nhận hợp tác với nhà cung cấp dịch vụ để tạo ra một đoạn private key mới và ký một giao dịch cam kết mới với thời gian khóa ngắn hơn và quá trình thanh toán được hoàn tất. .
Nếu được biểu thị dưới dạng UTXO được chia sẻ, thì đó là cấu trúc chuỗi sử dụng các giao dịch cam kết giảm thời gian khóa để cập nhật trạng thái; tuy nhiên, UTXO được chia sẻ này chỉ có một vTXO và người nắm giữ vTXO không thể chia vTXO của riêng mình sau khi thanh toán. toàn bộ vTXO phải được chuyển giao - bất kỳ lúc nào cũng chỉ có một người nắm giữ hợp Chuỗi của vTXO; người dùng thông đồng (họ có thể thông đồng để tạo chữ ký hợp lệ của private key UTXO được chia sẻ và do đó chuyển tiền) - đây là nhược điểm lớn nhất của nó và tại sao người dùng cần thực hiện xác minh bổ sung khi nhận thanh toán.
Nếu người dùng muốn kích hoạt nhiều khoản thanh toán chi tiết hơn thay vì có thể chuyển tất cả tiền cùng một lúc thì vTXO có thể được chuyển sang kênh Lightning và khoản thanh toán có thể được gửi trong kênh Lightning, điều này có thể được thực hiện [17 ] .
ARK và ARK v2
“ARK” [18] là một cấu trúc phẳng không có cơ chế cập nhật ngoài Chuỗi. Vì vậy, sự khác biệt giữa nó và "kiểm soát tắc nghẽn" là gì? Lý do là vTXO của nó không phải là một đồng xu thuần túy (nhưng nó cũng không phải là một kênh sét). Về nội dung kịch bản thì nó giống “kênh một chiều” hơn. Kênh một chiều này có hai đường chi tiêu, một là chữ ký đa của hai người tham gia; đường còn lại là chữ ký đơn của người dùng có khóa thời gian. Cái sau có thể được sử dụng để chỉ ra quyền sở hữu cuối cùng đối với số tiền trong kênh một chiều này và cũng có thể được sử dụng để thúc giục một người tham gia nhất định hành động. Cái trước cho phép các chức năng được hỗ trợ bởi các thiết bị đa chữ ký trước khi hết thời gian khóa. Khi mô tả các kênh một chiều bên dưới, trước tiên tôi sẽ liệt kê các tác nhân có thể sử dụng các nhánh khóa thời gian.
vTXO của người dùng trong ARK là kênh một chiều giữa nhà cung cấp dịch vụ ARK và người dùng. VTXO của người dùng bơm tiền vào kênh một chiều giữa người dùng và nhà cung cấp dịch vụ ARK thông qua giao dịch cam kết đặc biệt (Đổi TX).
Thiết kế này được sử dụng để hỗ trợ "thanh toán bằng đồng xu nguyên tử không tương tác": khi Alice cố gắng thanh toán cho David, cô ấy có thể bày tỏ cam kết đáng tin cậy bằng cách sử dụng kênh một chiều của mình với nhà cung cấp dịch vụ (Alice-Server Coin): Nếu và chỉ khi bạn trả cho David, tiền của tôi thuộc về bạn; nhưng nếu bạn không làm điều đó trong một thời gian nhất định, tôi sẽ lấy đi tiền của tôi. Điều này thực sự có thể thực hiện được bởi vì, với tư cách là một UTXO được chia sẻ, ARK không thể được sử dụng nếu không có sự đồng ý của Alice. Do đó, nếu nhà cung cấp dịch vụ không cung cấp dịch vụ, Alice luôn có thể phát hành CT và Đổi TX#A, sau đó rút tiền bằng đồng xu Alice-Server.
Tương ứng, nhà cung cấp dịch vụ không lo lắng rằng Alice sẽ vỡ nợ trên hóa đơn, bởi vì sau khi TA thanh toán cho David, anh ta luôn có thể yêu cầu Alice-Server coin xác nhận, sau đó sử dụng giao dịch cam kết do Alice đưa ra để rút tiền.
Cuối cùng, tình huống lý tưởng là cả hai bên sẽ hợp tác: nhà cung cấp dịch vụ hợp tác với David và Alice đồng ý làm việc với nhà cung cấp dịch vụ để thay đổi trạng thái của ARK trên Chuỗi. Trong quá trình này, Alice không trực tiếp trả tiền cho David; nếu David nhận được khoản thanh toán trên Chuỗi thì những người quan sát bên ngoài sẽ không biết ai trong ARK đã trả tiền cho anh ta (chỉ những người bạn đồng hành của Alice mới biết); thì ngay cả những đồng nghiệp của Alice trong ARK này cũng sẽ không biết số tiền được trao cho ai (miễn là những đồng nghiệp này không tham gia vào cả hai ARK).
Ngoài ra, mặc dù về mặt lý thuyết, kênh một chiều ở đây hỗ trợ các khoản thanh toán chi tiết nhưng ARK không hỗ trợ tính năng này. Giống như statechain, tiền được chuyển hoàn toàn.
ARK v2 về cơ bản tuân theo cấu trúc tương tự [19] , nhưng cho phép một số thiết kế cho phép các nhà cung cấp dịch vụ thu hồi vốn hiệu quả hơn (cũng dựa vào cây tập lệnh Merkle của taproot). Nhưng xét về cấu trúc của UTXO dùng chung thì hai phiên bản về cơ bản là giống nhau. Hơn nữa, ARK có thể thực hiện mà không cần điều khoản hạn chế, nhưng ARK v2 rõ ràng dựa vào điều khoản hạn chế.
Đánh giá cao và chỉ trích UTXO được chia sẻ
Bài viết của CoinPool đã phác thảo rõ ràng hai động lực để nghiên cứu UTXO được chia sẻ, đây cũng là những lợi ích mà việc chia sẻ UTXO dự kiến sẽ mang lại cho mọi người:
- Sự riêng tư. Khi nhiều người chia sẻ UTXO, người thực hiện thanh toán có thể bị ẩn trên Chuỗi và nếu người nhận cũng sử dụng UTXO được chia sẻ thì người nhận cũng có thể bị ẩn. ARK là biểu tượng của việc đi theo hướng này.
- Mở rộng . Số lượng UTXO (trạng thái trên Chuỗi ) trên Chuỗi có thể giảm và nhu cầu về không gian khối có thể giảm (ví dụ: cơ chế cập nhật Chuỗi có thể được sử dụng trong các UTXO được chia sẻ để thanh toán cho nhau). Người đại diện trong vấn đề này phải thuộc về nhà máy sản xuất kênh.
Những lời chỉ trích về khái niệm này chủ yếu xuất phát từ góc độ thực tế. Cho rằng khi số lượng người dùng tăng lên, rất hiếm khi tất cả người dùng đều trực tuyến, đồng nghĩa với việc trạng thái của họ thường xuyên bị kẹt và không thể cập nhật, vì vậy. nó là một loại tính dễ vỡ và tính sẵn có của cơ chế kém. Có một lời chỉ trích khác thậm chí còn gay gắt hơn, đến từ Peter Todd: Chúng tôi cho rằng cơ chế này sẽ được sử dụng để mở rộng khả năng xử lý của Bitcoin, tức là sử dụng nó để hỗ trợ những người có điều kiện kinh tế kém không đủ khả năng sở hữu Bitcoin. Tuy nhiên, UTXO trên Chuỗi và Người dùng sử dụng nó; tuy nhiên, chúng tôi cũng cho rằng khi có điều gì đó thực sự xảy ra, người dùng sẽ chủ động thoát ra hoặc bật lên Chuỗi một cách thụ động - làm sao họ có thể đột nhiên mua được nó?
Lời chỉ trích này rõ ràng cần phải phân tích sâu hơn để tìm ra câu trả lời hợp lý. Ít nhất, hiện tại, mọi người sẽ không ngừng nghiên cứu UTXO được chia sẻ vì một số lợi ích. Hơn nữa, những nghiên cứu này đã tạo ra giá trị, dù là về mặt lý thuyết (như TPP) hay thực tế (chẳng hạn như việc triển khai statechain).
Tóm tắt
Bài viết này phân tích các thành phần cơ bản của UTXO dùng chung và giải thích các thiết kế cụ thể của các UTXO dùng chung hiện nay, quy các đặc điểm của chúng là do việc sử dụng các thành phần cơ bản cụ thể.
Bài viết này chủ yếu tập trung vào các đặc điểm cấu trúc và bỏ qua nhiều chi tiết kỹ thuật (chẳng hạn như thiết kế các tập lệnh liên quan và hỗ trợ quá trình tương tác của người dùng). Nghiên cứu sâu hơn theo hướng này có thể giúp chúng tôi đánh giá sâu hơn những ưu và nhược điểm của các thiết kế khác nhau.
(Cuối văn bản)
chú thích cuối trang
1. https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micro Payment_Networks.pdf ↩
2. https://www.btcstudy.org/2022/06/15/coinpool-exploring-generic-Payment-pools-for-fun-and-privacy/ ↩
3. https://utxos.org/uses/scaling/ ↩
4. https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdaverify-by-zmnscpxj/ ↩
5. https://bitcoinops.org/en/topics/joinpools/ ↩
6. https://www.btcstudy.org/2022/03/17/introduction-to-fee-bumping-by-Bitcoin-Optech/#CPFP-%E7%AE%80%E4%BB%8B ↩
7. https://blockstream.com/eltoo.pdf ↩
8. https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki ↩
9. https://www.btcstudy.org/2020/09/01/en-eltoo-next-lightning/ ↩
10. https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories ↩
11. https://www.btcstudy.org/2022/11/14/under Hiểu-thanh toán- channels/ ↩
12. https://www.btcstudy.org/2023/06/29/tapleaf-update-verify-covenant-opcode-introduction/ ↩
13. https://www.btcstudy.org/2022/02/07/what-is-bitcoin-checktemplateverify/ ↩
14. https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdaverif
