Tác giả gốc: Trưởng phòng nghiên cứu đầu tư của HashKey Capital Jeffrey HU, Giám đốc đầu tư của 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òn thu hút rất nhiều sự chú ý của mọi người khi tung ra Quantum Cats NFT và tuyên bố đã lấy được số BIP-420. Những người ủng hộ cho 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 chú ý đến từ hạn chế và 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, được dịch là “hạn chế” trong tiếng Trung và đôi khi được dịch là “hợp đồng”, 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 và gửi tập lệnh phù hợp khi chi tiêu. 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, nhằm đạt được hiệu ứng tương tự như quỹ chuyên dụng hoặc các điều kiện đầu vào khác được gửi trong thời gian chờ giao dịch;
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. Ví dụ: khóa thời gian dựa trên mã hoạt động là để nhận ra giới hạn thời gian trước khi giao dịch được thực hiện bằng cách xem xét nội bộ trường nLock hoặc nSequence của giao dịch, nhưng về cơ bản là như vậy. bị giới hạn bởi những hạn chế 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ế các biện pháp kiểm tra giới hạn 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 cách phản trực giác, điều này có thể mở ra nhiều kịch bản ứng dụng hơn.
Kịch bản ứng dụng
Đảm bảo hình phạt đặ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 cắt giảm 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. Các điều kiện chi tiêu bao gồm hai loại:
Kết thúc có hậu: Sau một khoảng thời gian nhất định, người dùng có thể mở khóa nó bằng chữ ký của mình, quá trình này hoàn tất quá trình hủy đặt cọc.
Bad end: Nếu người dùng thực hiện hành vi xấu xa như double-signing trên một chuỗi PoS nào đó được Babylon cho thuê thì thông qua EOTS (chữ ký một lần có thể trích xuất, chữ ký có thể trích xuất một lần), phần tài sản này có thể được mở khóa và Một tác nhân điều hành trong mạng buộc một phần tài sản phải được gửi đến địa chỉ ghi (dấu gạch chéo)
Nguồn: Đặt cược Bitcoin: Mở khóa 21 triệu Bitcoin để đảm bảo nền kinh tế bằng chứng cổ phần
Hãy chú ý đến việc bắt buộc gửi ở đây, có nghĩa là ngay cả khi UTXO này có thể được mở khóa, tài sản không thể được gửi đi bất kỳ nơi nào khác một cách tùy tiện và chỉ có thể bị đốt cháy. Đ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 các 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ế.
điều khiển tắc nghẽn
Nói chung, tắc nghẽn đề cập đến khi phí giao dịch trên mạng Bitcoin rất cao và có nhiều giao dịch tích lũy hơn trong nhóm giao dịch đang chờ được đóng gói. Do đó, nếu người dùng muốn xác nhận giao dịch nhanh chóng, họ cần tăng phí giao dịch.
Lúc 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 thì sẽ phải tăng phí xử lý và chịu chi phí tương đối cao. Đồ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 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 hiển thị trong biểu đồ 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/
Kịch bản này là 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 này còn liệt kê các 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.
Kho tiền
Vault là một kịch bản ứng dụng được thảo luận rộng rãi trong các ứng dụng Bitcoin, đặc biệt là trong lĩnh vực có 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ỉ).
Các ứng dụng lớp Vault có thể được xây dựng tương đối dễ dàng dựa trên các kỹ thuật triển khai các hạn chế.
Lấy thiết kế của OP_VAULT làm ví dụ: khi chi tiền trong 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 sự kích hoạt và đặt một điều kiện trong đó:
Nếu mọi thứ đều ổn thì giao dịch thứ hai là giao dịch mà việc rút tiền cuối cùng được thực hiện. Sau khi chờ N khối, tiền có thể được chi tiêu thêm ở bất cứ đâu
Nếu phát hiện giao dịch này đã bị đánh cắp (hoặc bị ép buộc trong một cuộc tấn công bằng cờ lê), 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) trước khi giao dịch rút N khối được gửi.
Quy trình cho OP_VAULT, nguồn: BIP-345
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
Nhìn chung có thể coi rằng các kênh trạng thái, bao gồm cả Lightning Network, có tính bảo mật gần như giống như chuỗi chính (với điều kiện là các nút có thể quan sát trạng thái mới nhất và thường có thể xuất bản trạng thái mới nhất lên chuỗi). 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 về thanh khoản trong nước và quản lý kênh của Lightning Network. Đây là một dạng giao thức tham gia chung. Nhiều người dùng có thể chấp nhận 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 kỹ thuật về các hạn chế
Có thể thấy từ các ứng dụng trên, các mệnh đề hạn chế giống như một tác dụng hơn là một công nghệ nhất định nên có nhiều cách kỹ thuật để triển khai chúng. Nếu được phân loại, điều này có thể bao gồm:
Kiểu: Loại chung, loại đặc biệt
Phương thức triển khai: Dựa trên Opcode, dựa trên chữ ký
Đệ quy: đệ quy, không đệ quy
Trong số đó, đệ quy đề cập đến việc thực hiện một số điều khoản 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. Các hạn chế được thêm vào có thể vượt quá một giao dịch và đạt đến độ 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 với OP_CAT
Thiết kế hạn chế
Như có thể thấy từ phần giới thiệu trước, tập lệnh Bitcoin 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 UTXO có thể được chi tiêu thêm. Để 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ế?
Nguyên nhân 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 nội quan 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 ràng buộc.
Vì vậy, ý tưởng thiết kế các mệnh đề 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 một hoặc nhiều opcode (tức là một opcode + nhiều tham số hoặc nhiều opcode với các chức năng khác nhau) để đọc trực tiếp nội dung của giao dịch. Đây là ý tưởng dựa trên mã hoạt động.
Một ý tưởng khác là bạn không thể trực tiếp đọc và kiểm tra nội dung của giao dịch trong tập lệnh, nhưng 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ý thì chỉ cần sửa đổi nó trong tập lệnh, chẳng hạn như OP_CHECKSIG After kiểm tra chữ ký này, chúng tôi có thể gián tiếp thực hiện việc xem xét nội tâm và hạn chế giao dịch. Ý 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.
MỘT PO
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: Mastering 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ả đầu vào và không được sử dụng cho đầu ra; SINGLE dựa trên điều này và chỉ áp dụng cho đầu ra có cùng số thứ tự đầu vào. Ngoài ra, SIGHASH cũng có thể được kết hợp sau khi áp dụng công cụ sửa đổi ANYONECANPAY, nó chỉ có thể áp dụng cho một đầu vào.
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ũng có nghĩa là các giao dịch được ký bằng APO sau này có thể được đính kèm với bất kỳ UTXO nào đáp ứng các điều kiện.
Tính linh hoạt này là cơ sở lý thuyết để APO thực hiện các điều khoản hạn chế:
Một hoặc nhiều giao dịch có thể được tạo trước
Sử dụng thông tin của các giao dịch này, một khóa công khai chỉ có thể lấy được chữ ký sẽ được xây dựng.
Bằng cách này, mọi tài sản được gửi đến địa chỉ khóa công khai đó chỉ có thể được sử dụng thông qua các giao dịch được tạo trước
Đ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ỉ khi vượt 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ì chi tiêu tùy tiện bằng chữ ký EOA. 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, bởi vì đầu vào cần phải được biết trước để ký trước và tạo giao dịch.
Ý nghĩa của việc APO và SIGHASH_NOINPUT 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 (chỉ định) tất cả các kết quả đầu ra của giao dịch.
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), BIP-119, áp dụng phương pháp cải thiện Opcode. 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.
Đề xuất ban đầu được đưa ra dưới tên OP_CHECKOUTPUTSHASHVERIFY (COSHV) và ban đầu tập trung vào khả năng tạo các giao dịch kiểm soát tắc nghẽn, do đó, những lời chỉ trích về đề xuất cũng tập trung vào việc kế hoạch này không đủ chung chung và quá cụ thể đối với các 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 và băm 10 kết quả đầu ra, đồng thời sử dụng các bản tóm tắt kết quả để 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 trong số họ 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 10 bản sao đầu ra này thông 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. Đ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 xây dựng 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 có thể kết hợp.
Nguồn: https://twitter.com/OwenKemeys/status/1741575353716326835
Trên cơ sở đó, CTV đề xuất 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ề 10 máy thu. Người nhận có thể đặt thêm khóa địa chỉ của nó thành một tx đã ký nhưng chưa được phát sóng và gửi nó đến lô địa chỉ người nhận tiếp theo, v.v., tạo thành một hệ thống như trong hình bên dưới. . cấu trúc cây. 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
Và đ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 CTV được đề xuất, nó đã được đổi tên từ COSHV vào năm 2019, được gán 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 ra sự hỗ trợ cho các hợp đồng CTV vào năm 22 và 23, nó đã nhận được rất nhiều cuộc thảo luận, cập nhật và cập nhật từ cộng đồng. Cuộc tranh luận về kế hoạch kích hoạt của nó 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
Như đã giới thiệu ở phần đầu, OP_CAT cũng là một đề xuất nâng cấp hiện đang thu hút nhiều sự chú ý. Chức năng mà nó thực hiện là ghép 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 hoạt động 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ử, chức năng xác minh của cây merkle có thể được triển khai trong tập lệnh, tập lệnh này cũng có xác minh ứng dụng khách nhẹ ở một mức nhất định. khả năng.
Các nền tảng triển khai bổ sung 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à mã thông báo công khai, sau đó nếu người ký muốn ký một giao dịch khác, số tiền sẽ được chi tiêu ở nơi khác; sử dụng cùng một nonce và khiến khóa riêng bị rò rỉ. 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 các phiên bản đầu tiên của Bitcoin nhưng đã bị vô hiệu hóa vào năm 2010 vì nó có thể bị khai thác bởi các cuộc tấn công. Ví dụ: việc sử dụng lại OP_DUP và OP_CAT có thể dễ dàng khiến nút đầy đủ làm nổ tung ngăn xếp khi xử lý các tập lệnh như vậy. Xem bản demo này.
Nhưng liệu vấn đề nổ ngăn xếp được đề cập ở trên sẽ không xảy ra nếu OP_CAT được bật lại ngay bây giờ? 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 và tapscript giới hạn mỗi phần tử ngăn xếp ở mức không quá 520 byte nên sự cố nổ ngăn xếp trước đó sẽ không xảy ra. Cũng có một số nhà phát triển cho rằng lệnh cấm trực tiếp OP_CAT của Satoshi Nakamoto có thể quá khắc nghiệt. Tuy nhiên, do tính linh hoạt của OP_CAT, hiện tại một số kịch bản ứng dụng có thể gây ra lỗ hổng vẫn chưa thể được khắc phục.
Do đó, xem xét 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 đã nhận được các đánh giá PR. Đây là một trong những đề xuất nâng cấp phổ biến nhất hiện nay.
Phần kết luận
“Kỷ luật tự giác mang lại tự do.” Như có thể thấy từ phần giới thiệu ở trên, 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ế việc 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ẽ tiếp tục giải phóng tiềm năng của khả năng lập trình. Ví dụ: đề xuất của 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 hạn chế 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 sơ hở ngoài ý muốn nên 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. Với tình huống này 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 đã đánh giá và đề xuất bài viết này!
Người giới thiệu
https://utxos.org/
Một tập hợp các tài nguyên liên quan đến 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/apers/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
