HashKey Capital: Khả năng lập trình của Bitcoin “Giao ước”

Tác giả gốc: HashKey Capital Trưởng bộ phận nghiên cứu đầu tư Jeffrey HU, Giám đốc đầu tư HashKey Capital Harper LI

Gần đây, đã có một làn sóng thảo luận trong cộng đồng Bitcoin về việc kích hoạt lại các opcode như OP_CAT. Taproot Wizard cũng đã thu hút rất nhiều sự chú ý bằng cách tung ra NFT Quantum Cats và tuyên bố đã nhận được số BIP-420. Những người ủng hộ tuyên bố rằng việc kích hoạt OP_CAT có thể kích hoạt "giao ước", hợp đồng thông minh hoặc khả năng lập trình của Bitcoin.

Nếu bạn để ý thấy từ "hạn chế" và thực hiện tìm kiếm một chút, bạn sẽ thấy rằng đây lại là một cái hố thỏ lớn khác. Các nhà phát triển đã thảo luận trong nhiều năm, ngoài OP_CAT, còn có OP_CTV, APO, OP_VAULT và các kỹ thuật khác để thực hiện các điều khoản hạn chế.

Vậy chính xác thì những "hạn chế" của Bitcoin là gì? Tại sao nó lại thu hút được nhiều sự chú ý và thảo luận của các nhà phát triển trong vài năm qua? Loại khả năng lập trình nào có thể đạt được với Bitcoin? Nguyên tắc thiết kế đằng sau nó là gì? Bài viết này cố gắng đưa ra một giới thiệu và thảo luận tổng quan.

"Hạn chế" là gì

Các giao ước, đôi khi được dịch sang tiếng Trung Quốc là "hạn chế" Còn được dịch là "hợp đồng", đây là một cơ chế có thể đặt ra các điều kiện cho các giao dịch Bitcoin trong tương lai.

Tập lệnh Bitcoin hiện tại cũng chứa các điều kiện hạn chế, chẳng hạn như nhập chữ ký hợp pháp khi chi tiêu, gửi tập lệnh đủ điều kiện, v.v. Nhưng miễn là người dùng có thể mở khóa nó, anh ta có thể sử dụng UTXO ở bất cứ nơi nào anh ta muốn.

Điều khoản hạn chế là đưa ra nhiều hạn chế hơn dựa trên cách mở khóa hạn chế này, chẳng hạn như hạn chế chi tiêu sau UTXO, tức là để đạt được điều gì đó như " " Hiệu ứng quỹ đặc biệt để sử dụng độc quyền" hoặc các điều kiện đầu vào khác được gửi trong giao dịch, v.v.

Nói đúng hơn, tập lệnh Bitcoin hiện tại cũng có một số hạn chế nhất định, chẳng hạn như khóa thời gian dựa trên opcode, là các nLock được giao dịch thông qua trường nội tâm Hoặc nSequence để triển khai giới hạn thời gian trước khi giao dịch được chi tiêu, nhưng về cơ bản nó bị giới hạn về thời gian.

Vậy tại sao các nhà phát triển và nhà nghiên cứu lại thiết kế những biện pháp kiểm tra hạn chế này? Bởi vì các điều khoản hạn chế không chỉ là những hạn chế vì mục đích hạn chế mà chúng còn đặt ra các quy tắc để thực hiện giao dịch. Bằng cách này, người dùng chỉ có thể thực hiện các giao dịch theo các quy tắc đặt trước để hoàn thành quy trình kinh doanh được xác định trước.

Vì vậy, theo trực giác, điều này có thể mở ra nhiều kịch bản ứng dụng hơn.

Các kịch bản ứng dụng

Đảm bảo hình phạt khi đặt cược

Một trong những ví dụ trực quan nhất về các điều khoản hạn chế là giao dịch gạch chéo của Babylon trong quy trình đặt cược Bitcoin.

Quy trình đặt cược Bitcoin của Babylon là người dùng gửi tài sản BTC của họ đến một tập lệnh đặc biệt trên chuỗi chính và các điều kiện chi tiêu bao gồm hai loại:

Nguồn: Đặt cược Bitcoin: Mở khóa 21 M Bitcoin để đảm bảo nền kinh tế bằng chứng cổ phần

Hãy chú ý đến việc "gửi bắt buộc" ở đây, có nghĩa là ngay cả khi UTXO có thể được mở khóa, tài sản không thể được gửi đi bất cứ nơi nào khác một cách tùy tiện. Điều này sẽ đảm bảo rằng những người dùng độc hại không thể sử dụng chữ ký đã biết của họ để chuyển tài sản về cho chính họ nhằm thoát khỏi sự trừng phạt.

Nếu chức năng này được triển khai sau khi các hạn chế như OP_CTV được triển khai, thì các mã opcode như OP_CTV có thể được thêm vào nhánh "kết thúc xấu" của tập lệnh đặt cược để triển khai những hạn chế.

Trước khi OP_CTV được kích hoạt, Babylon cần sử dụng một phương pháp linh hoạt, do người dùng + ủy ban cùng thực hiện, để mô phỏng hiệu quả của việc thực thi các điều khoản hạn chế.

Kiểm soát tắc nghẽn

Nói chung, tắc nghẽn đề cập đến thời điểm phí giao dịch trên mạng Bitcoin Tỷ lệ rất cao và có rất nhiều giao dịch được tích lũy trong nhóm giao dịch đang chờ được đóng gói, vì vậy nếu người dùng muốn xác nhận giao dịch nhanh chóng, họ cần tăng phí xử lý.

Tại thời điểm này, nếu người dùng phải gửi nhiều giao dịch cho nhiều người nhận thanh toán, họ sẽ phải tăng phí xử lý và chịu chi phí cao hơn. Đồng thời, nó cũng sẽ đẩy tốc độ xử lý của toàn bộ mạng lên cao hơn nữa.

Nếu có những hạn chế, một giải pháp là người gửi trước tiên phải cam kết thực hiện giao dịch gửi hàng loạt. Lời hứa này có thể khiến tất cả người nhận tin rằng giao dịch cuối cùng sẽ được thực hiện và họ có thể đợi cho đến khi tỷ lệ xử lý thấp trước khi gửi các giao dịch cụ thể.

Như được minh họa trong hình bên dưới, khi nhu cầu về không gian khối cao, việc thực hiện các giao dịch sẽ trở nên rất tốn kém. Bằng cách sử dụng OP_CHECKTEMPLATEVERIFY, bộ xử lý thanh toán khối lượng lớn có thể tổng hợp tất cả các khoản thanh toán của họ thành một giao dịch O(1) duy nhất để xác nhận. Sau đó, theo thời gian, khi nhu cầu về không gian khối giảm, các khoản thanh toán có thể được thu nhỏ lại từ UTXO đó.

Nguồn: https://utxos.org/uses/scaling/

This kịch bản là một trường hợp ứng dụng điển hình được đề xuất bởi điều khoản hạn chế OP_CTV. Bạn có thể tìm thấy nhiều trường hợp ứng dụng hơn tại https://utxos.org/uses/. Ngoài tính năng kiểm soát tắc nghẽn ở trên, trang còn liệt kê Cược Soft Fork, tùy chọn phi tập trung, Drivechains, Kênh hàng loạt, Kênh không tương tác, Khai thác miễn phí phối hợp không cần tin cậy. Nhóm, kho tiền, giới hạn hợp đồng khóa thời gian băm (HTLCS) an toàn hơn, v.v.

Vault

Vault là một loại ứng dụng Bitcoin tương đối phổ biến Các kịch bản ứng dụng đã được thảo luận, đặc biệt là trong khu vực của các điều khoản hạn chế. Bởi vì hoạt động hàng ngày chắc chắn đòi hỏi sự cân bằng giữa nhu cầu lưu ký quỹ và nhu cầu sử dụng quỹ nên mọi người hy vọng sẽ có một loại ứng dụng vault có thể đảm bảo an toàn cho tiền và thậm chí hạn chế tính bảo mật của tiền ngay cả khi tài khoản bị hack (khóa riêng là bị rò rỉ).

Dựa trên công nghệ triển khai các điều khoản hạn chế, các ứng dụng lớp vault có thể được xây dựng tương đối dễ dàng.

Lấy thiết kế của OP_VAULT làm ví dụ: khi tiêu tiền vào kho tiền, trước tiên một giao dịch cần phải được gửi đến chuỗi. Giao dịch này cho biết ý định chi tiêu kho tiền, một "trình kích hoạt" và đặt các điều kiện bên trong nó:

• Nếu mọi thứ đều ổn thì giao dịch thứ hai là giao dịch rút tiền cuối cùng. Sau khi chờ N khối, số tiền có thể được chi tiêu tiếp ở bất cứ đâu

• Nếu phát hiện ra rằng giao dịch này đã bị đánh cắp (hoặc bị ép buộc bằng một "cuộc tấn công cờ lê"), trước khi giao dịch rút N khối được gửi, nó có thể được gửi ngay đến một địa chỉ an toàn khác (lưu trữ an toàn hơn cho người dùng)

Quy trình OP_VAULT, nguồn: BIP-345 

Nó cần lưu ý rằng ứng dụng vault cũng có thể được xây dựng mà không bị hạn chế. Một phương pháp khả thi là sử dụng khóa riêng để chuẩn bị chữ ký cho chi tiêu trong tương lai, sau đó hủy khóa riêng. Tuy nhiên, vẫn còn nhiều hạn chế, chẳng hạn như cần phải đảm bảo rằng khóa riêng đã bị hủy (tương tự như quy trình thiết lập tin cậy trong bằng chứng không có kiến ​​thức), số tiền và phí xử lý được xác định trước (vì cần phải có ký trước) và thiếu tính linh hoạt.

So sánh quy trình OP_VAULT và quy trình vault được ký trước, nguồn: BIP-345 

Các kênh trạng thái mạnh mẽ và linh hoạt hơn

Người ta thường tin rằng các kênh trạng thái, bao gồm cả Lightning Network, có mức độ bảo mật gần như giống như chuỗi chính ( Trong điều kiện nút có thể quan sát trạng thái mới nhất và có thể xuất bản trạng thái mới nhất lên chuỗi một cách bình thường). Tuy nhiên, với những hạn chế được áp dụng, một số ý tưởng thiết kế kênh trạng thái mới có thể mạnh mẽ hoặc linh hoạt hơn trên Lightning Network. Những cái được biết đến nhiều hơn bao gồm Eltoo, Ark, v.v.

Eltoo (còn gọi là LN-Symmetry) là một trong những ví dụ điển hình hơn. Giải pháp kỹ thuật này đồng âm với "L2" và đề xuất một lớp thực thi cho Lightning Network cho phép mọi trạng thái kênh tiếp theo thay thế trạng thái trước đó mà không cần cơ chế phạt. Do đó, nó cũng có thể tránh được nhu cầu lưu tương tự như Lightning. Các nút mạng. Nhiều trạng thái trước đó để ngăn chặn đối thủ của bạn làm điều ác. Để đạt được hiệu quả trên, Eltoo đã đề xuất phương thức chữ ký SIGHASH_NOINPUT, cụ thể là APO (BIP-118).

Ark nhằm mục đích giảm bớt khó khăn trong thanh khoản đầu vào và quản lý kênh của Lightning Network. Đó là giao thức kiểu tham gia trong đó nhiều người dùng có thể chấp nhận một nhà cung cấp dịch vụ làm đối tác trong một khoảng thời gian nhất định và thực hiện các giao dịch UTXO ảo (vUTXO) bên ngoài chuỗi nhưng chia sẻ UTXO trên chuỗi để giảm chi phí. Tương tự như vault, Ark cũng có thể được triển khai trên mạng Bitcoin hiện tại, tuy nhiên, sau khi đưa ra các hạn chế, Ark có thể giảm lượng tương tác cần thiết dựa trên các mẫu giao dịch và đạt được lối thoát đơn phương đáng tin cậy hơn.

Tổng quan về mặt kỹ thuật của các mệnh đề hạn chế

Như có thể thấy từ các ứng dụng trên, các mệnh đề hạn chế giống Hiệu ứng hơn là một công nghệ nhất định, vì vậy có nhiều cách kỹ thuật để đạt được nó. Nếu phân loại, bạn có thể bao gồm:

• Loại: loại chung, loại đặc biệt

• Phương pháp triển khai: dựa trên Opcode, dựa trên chữ ký

• Đệ quy: đệ quy, không đệ quy

Và trong số đó, đệ quy đề cập đến việc thực hiện một số mệnh đề hạn chế. Bạn cũng có thể giới hạn đầu ra tiếp theo bằng cách giới hạn đầu ra tiếp theo và bạn có thể nhận ra rằng các hạn chế được thêm vào có thể vượt quá một giao dịch. đạt được độ sâu giao dịch cao hơn.

Một số thiết kế mệnh đề hạn chế phổ biến bao gồm:

* Đệ quy: nếu kết hợp OP_CAT 

Thiết kế các mệnh đề hạn chế

Có thể thấy từ phần giới thiệu trước rằng Bitcoin Script hiện tại chủ yếu giới hạn các điều kiện để mở khóa và không giới hạn cách sử dụng thêm UTXO. Để thực hiện các hạn chế, chúng ta phải nghĩ ngược lại: Tại sao tập lệnh Bitcoin hiện tại không thể thực hiện các hạn chế?

Lý do chính là do tập lệnh Bitcoin hiện tại không thể đọc được nội dung của giao dịch, tức là "xem xét nội tâm" của giao dịch.

Nếu chúng tôi có thể triển khai việc xem xét nội tâm giao dịch - kiểm tra bất kỳ nội dung nào của giao dịch (bao gồm cả đầu ra), thì chúng tôi có thể triển khai các điều khoản hạn chế.

Do đó, ý tưởng thiết kế các điều khoản hạn chế chủ yếu tập trung vào cách đạt được sự xem xét nội tâm.

Dựa trên Opcode và dựa trên chữ ký

Ý tưởng đơn giản và thô sơ nhất là thêm a hoặc Nhiều opcode (tức là một opcode + nhiều tham số hoặc nhiều opcode có chức năng khác nhau) trực tiếp đọc nội dung của giao dịch. Đây là ý tưởng dựa trên mã hoạt động.

Một cách suy nghĩ khác là thay vì trực tiếp đọc và kiểm tra nội dung của giao dịch trong tập lệnh, bạn có thể sử dụng hàm băm của nội dung giao dịch - nếu Hàm băm đã được ký, do đó, miễn là OP_CHECKSIG được sửa đổi trong tập lệnh để kiểm tra chữ ký, việc xem xét nội tâm và hạn chế giao dịch có thể được thực hiện gián tiếp. Ý tưởng này dựa trên thiết kế chữ ký. Chủ yếu bao gồm APO và OP_CSFS, v.v.

APO

SIGHASH_ANYPREVOUT (APO) là một phương pháp chữ ký Bitcoin được đề xuất. Cách ký đơn giản nhất là cam kết cả đầu vào và đầu ra của giao dịch, nhưng Bitcoin cũng có một cách linh hoạt hơn, đó là SIGHASH, cam kết có chọn lọc về đầu vào hoặc đầu ra của giao dịch.

Phạm vi chữ ký hiện tại của SIGHASH và các kết hợp của nó cho đầu vào và đầu ra giao dịch (nguồn "Làm chủ Bitcoin , 2 nd》

Như được hiển thị trong hình trên, ngoài ALL áp dụng cho tất cả dữ liệu, phương thức chữ ký NONE chỉ áp dụng cho tất cả các đầu vào không có For đầu ra; SINGLE dựa trên điều này và chỉ áp dụng cho các đầu ra có cùng số thứ tự đầu vào. Ngoài ra, SIGHASH cũng có thể được kết hợp và sau khi áp dụng công cụ sửa đổi ANYONECANPAY, nó chỉ áp dụng cho một đầu vào. p style=" text-align: left;">SIGHASH của APO chỉ ký phần đầu ra chứ không phải phần đầu vào. Điều này có nghĩa là các giao dịch được ký bằng APO có thể được thêm vào bất kỳ UTXO nào đáp ứng các điều kiện. style="text-align:center">

Tính linh hoạt này là cơ sở lý thuyết để APO triển khai các mệnh đề hạn chế:

p>

• Một hoặc nhiều các nét có thể được tạo trước Giao dịch

• Xây dựng khóa chung chỉ có thể lấy một chữ ký thông qua thông tin của các giao dịch này

• Bằng cách này, mọi tài sản được gửi đến địa chỉ khóa công khai này chỉ có thể được sử dụng thông qua các giao dịch được tạo trước

< p style="text-align: left;">Điều đáng chú ý là vì khóa chung này không có khóa riêng tương ứng nên đảm bảo rằng những tài sản này chỉ có thể được sử dụng thông qua các giao dịch được tạo trước. Sau đó, chúng tôi có thể quy định đích đến của tài sản trong các giao dịch được tạo trước này để thực hiện các điều khoản hạn chế.

Chúng ta có thể hiểu rõ hơn bằng cách so sánh các hợp đồng thông minh của Ethereum: Điều chúng ta có thể đạt được thông qua hợp đồng thông minh là chỉ thông qua một số điều kiện nhất định, chúng ta mới có thể rút tiền từ địa chỉ hợp đồng . , thay vì dựa vào chữ ký EOA để chi tiêu tùy ý. Từ quan điểm này, Bitcoin có thể đạt được hiệu quả này thông qua việc cải tiến cơ chế chữ ký.

Nhưng vấn đề với quy trình trên là có sự phụ thuộc vòng tròn trong tính toán, vì nội dung đầu vào cần phải được biết trước để ký trước và tạo giao dịch .

APO và SIGHASH_NOINPUT Ý nghĩa của việc triển khai phương pháp chữ ký này là nó có thể giải quyết được vấn đề phụ thuộc vòng tròn này. Khi tính toán, bạn chỉ cần biết toàn bộ kết quả đầu ra của. giao dịch (được chỉ định) Thế là xong.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), cụ thể là BIP-119, áp dụng Cách Opcode cải tiến. Nó lấy hàm băm cam kết làm tham số và yêu cầu bất kỳ giao dịch nào thực thi mã opcode đều chứa một tập hợp đầu ra khớp với cam kết đó. Thông qua CTV, người dùng Bitcoin sẽ được phép giới hạn cách họ sử dụng Bitcoin của mình.

Đề xuất ban đầu được đưa ra dưới tên OP_CHECKOUTPUTSHASHVERIFY (COSHV) và trọng tâm ban đầu của nó là khả năng tạo các giao dịch kiểm soát tắc nghẽn, do đó, cũng có những lời chỉ trích về đề xuất này tập trung vào vấn đề này Giải pháp này không đủ chung và quá cụ thể đối với trường hợp sử dụng kiểm soát tắc nghẽn.

Trong trường hợp sử dụng kiểm soát tắc nghẽn được đề cập ở trên, người gửi Alice có thể tạo 10 kết quả đầu ra và băm 10 kết quả đầu ra này, đồng thời sử dụng Tóm tắt được tạo để tạo tập lệnh tapleaf chứa COSHV. Alice cũng có thể sử dụng khóa chung của người tham gia để tạo khóa nội bộ Taproot, cho phép họ cộng tác chi tiêu mà không tiết lộ đường dẫn tập lệnh Taproot.

Sau đó, Alice đưa cho mỗi người nhận một bản sao của tất cả 10 kết quả đầu ra để mỗi người có thể xác minh giao dịch thiết lập của Alice. Sau đó, khi họ muốn chi tiêu khoản thanh toán, một trong hai người có thể tạo một giao dịch chứa kết quả đầu ra đã hứa.

Trong suốt quá trình, khi Alice tạo và gửi giao dịch thiết lập, Alice có thể gửi giao dịch đó qua các phương thức liên lạc không đồng bộ hiện có, chẳng hạn như email hoặc ổ đĩa đám mây. đầu ra. Điều này có nghĩa là người nhận không cần phải trực tuyến hoặc tương tác với nhau.



Nguồn: https://bitcoinops.org/en/newsletters/2019/05 /29 /#proposes-transaction-output-commitments

Tương tự như APO, địa chỉ cũng có thể được tạo dựa trên điều kiện chi tiêu và "khóa" có thể được tạo theo nhiều cách khác nhau . ”, bao gồm: thêm các khóa khác, khóa thời gian và logic kết hợp.



Nguồn: https://twitter.com/OwenKemeys/status/1741575353716326835

CTV đề xuất trên cơ sở này rằng nó có thể kiểm tra xem giao dịch đã chi tiêu sau khi băm có khớp với giao dịch đã xác định hay không, tức là dữ liệu giao dịch có thể được sử dụng làm chìa khóa để mở "ổ khóa".

Chúng ta có thể tiếp tục mở rộng ví dụ trên với 10 người nhận. Người nhận có thể đặt thêm khóa địa chỉ của mình thành một tx đã ký nhưng chưa được phát sóng được gửi đến Lô người nhận tiếp theo. địa chỉ, v.v., tạo thành một cấu trúc cây như trong hình bên dưới. Alice có thể thực hiện thay đổi số dư tài khoản liên quan đến nhiều người dùng chỉ bằng cách sử dụng 1 không gian khối utxo trên chuỗi.



Nguồn: https://twitter.com/OwenKemeys/status/1741575353716326835

Điều gì sẽ xảy ra nếu một trong các lá là kênh sét, kho lạnh hoặc đường dẫn thanh toán khác? Khi đó, cây này sẽ mở rộng từ cây chi tiêu một chiều, đa cấp thành cây chi tiêu đa chiều, đa cấp, các kịch bản mà nó có thể hỗ trợ sẽ phong phú và linh hoạt hơn.



Nguồn: https://twitter.com/OwenKemeys/status/1744181234417140076

Kể từ khi được giới thiệu, CTV đã được đổi tên từ COSHV vào năm 2019, được cấp BIP-119  vào năm 2020 và nổi lên như một ngôn ngữ lập trình Sapio để tạo hợp đồng CTV vào năm 2022 và. Kể từ năm 2023, nó đã nhận được rất nhiều cuộc thảo luận, cập nhật và tranh luận về kế hoạch kích hoạt từ cộng đồng. Đây vẫn là một trong những đề xuất nâng cấp soft fork được thảo luận nhiều hơn trong cộng đồng.

OP_CAT

OP_CAT, như đã giới thiệu ở phần đầu, cũng là một bản nâng cấp hiện đang được phát hành thu hút nhiều sự quan tâm. Đề xuất, triển khai chức năng nối (concatenante) hai phần tử trong ngăn xếp. Mặc dù có vẻ đơn giản nhưng OP_CAT có thể rất linh hoạt để triển khai nhiều chức năng trong tập lệnh.

Ví dụ trực tiếp nhất là các phép toán liên quan đến cây merkle. Cây Merkle có thể hiểu là hai phần tử đầu tiên được ghép nối rồi sau đó được băm. Hiện tại, có các mã hoạt động băm như OP_SHA 256 trong tập lệnh Bitcoin, vì vậy nếu OP_CAT có thể được sử dụng để ghép hai phần tử thì chức năng xác minh của cây merkle có thể được triển khai trong tập lệnh và nó sẽ có một ứng dụng khách nhẹ để Khả năng xác minh ở mức độ nhất định.

Cơ sở triển khai khác cũng bao gồm các cải tiến đối với chữ ký Schnorr: các điều kiện chữ ký chi tiêu của tập lệnh có thể được đặt thành việc ghép khóa chung của người dùng và số không công khai; người ký muốn ký một giao dịch khác để tiêu tiền ở nơi khác, anh ta phải sử dụng cùng một số nonce và rò rỉ khóa riêng. Nghĩa là, cam kết về nonce được thực hiện thông qua OP_CAT, qua đó đảm bảo tính hợp lệ của giao dịch đã ký.

Các kịch bản ứng dụng khác của OP_CAT bao gồm: Bistream, chữ ký cây, chữ ký Lamport kháng lượng tử, vault, v.v.

Bản thân OP_CAT không phải là một tính năng mới. Nó tồn tại trong phiên bản đầu tiên của Bitcoin, nhưng nó đã bị xóa vào năm 2010 do có khả năng bị các cuộc tấn công khai thác. bắt đầu bị vô hiệu hóa. Ví dụ: việc sử dụng lại OP_DUP và OP_CAT có thể dễ dàng làm cho ngăn xếp nút đầy đủ phát nổ khi xử lý các tập lệnh như vậy, hãy xem bản demo này.

Nhưng liệu vấn đề bùng nổ ngăn xếp được đề cập ở trên có xảy ra nếu OP_CAT được bật lại ngay bây giờ không? Bởi vì đề xuất OP_CAT hiện tại chỉ liên quan đến việc kích hoạt nó trong tapscript, giới hạn mỗi phần tử ngăn xếp không quá 520 byte, nên vấn đề bùng nổ ngăn xếp trước đó sẽ không phát sinh. Cũng có một số nhà phát triển cho rằng lệnh cấm trực tiếp của Satoshi đối với OP_CAT có thể quá khắc nghiệt. Tuy nhiên, do tính linh hoạt của OP_CAT, một số kịch bản ứng dụng có thể dẫn đến lỗ hổng hiện không thể hết được.

Vì vậy, xét đến các kịch bản ứng dụng và rủi ro tiềm ẩn, OP_CAT gần đây đã nhận được rất nhiều sự chú ý và cũng đã có những đánh giá PR. Đây là một trong những bản nâng cấp phổ biến nhất. đề xuất hiện nay.

Kết luận

"Kỷ luật tự giác mang lại tự do", như bạn có thể thấy ở trên giới thiệu, các điều khoản Hạn chế có thể được triển khai trực tiếp trong các tập lệnh Bitcoin để hạn chế chi tiêu thêm cho các giao dịch, từ đó đạt được các quy tắc giao dịch tương tự như hiệu ứng hợp đồng thông minh. So với các phương pháp ngoài chuỗi như BitVM, phương pháp lập trình này có thể được xác minh nguyên bản hơn trên Bitcoin và cũng có thể cải thiện các ứng dụng trên chuỗi chính (kiểm soát tắc nghẽn), các ứng dụng ngoài chuỗi (kênh trạng thái) và hướng Ứng dụng mới khác ( hình phạt đặt cược, v.v.).

Nếu công nghệ triển khai các điều khoản hạn chế có thể được kết hợp với một số nâng cấp cơ bản, nó sẽ giải phóng thêm tiềm năng của khả năng lập trình. Ví dụ: đề xuất nhà điều hành 64 bit đang được xem xét gần đây có thể được kết hợp thêm với OP_TLUV được đề xuất hoặc các ràng buộc khác có thể được lập trình dựa trên số lượng satoshi đầu ra của giao dịch.

Tuy nhiên, các điều khoản hạn chế cũng có thể dẫn đến một số hành vi lạm dụng hoặc lỗ hổng ngoài ý muốn, vì vậy cộng đồng cũng thận trọng hơn về điều này. Ngoài ra, việc nâng cấp các điều khoản hạn chế cũng yêu cầu nâng cấp phần mềm các quy tắc đồng thuận. Do tình huống xảy ra trong quá trình nâng cấp taproot, các nâng cấp liên quan đến các hạn chế cũng có thể mất thời gian để hoàn thành.

Cảm ơn Ajian, Fisher và Ben vì đã xem xét và đề xuất bài viết này!

Tài liệu tham khảo
https://utxos.org/

https:/ /bitcoincovenants.com/

Bộ sưu tập tài nguyên liên quan đến các giao ước:

https:/ /Gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345 : Đề xuất OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https: //maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

OP_CAT:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN- 2024-0001.md

Thủ thuật CAT và Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298