"Các "Hiệp ước" của Bitcoin là các cơ chế thiết lập điều kiện cho các giao dịch Bitcoin trong tương lai. Bài viết chỉ rõ các khái niệm cơ bản, các kịch bản áp dụng, và các phương pháp triển khai kỹ thuật của các điều khoản hạn chế, và thảo luận về các nguyên tắc thiết kế đứng sau chúng. Các đề xuất kỹ thuật như OP_CAT, OP_CTV, và APO được giới thiệu, và cách chúng tăng cường khả năng lập trình và chức năng hợp đồng thông minh của Bitcoin. Đồng thời, bài viết cũng đề cập đến ứng dụng của các điều khoản hạn chế trong mạng lưới Bitcoin, như kiểm soát tắc nghẽn, kho bảo vệ, kênh trạng thái, v.v., và thảo luận về các ý tưởng thiết kế để triển khai các điều khoản hạn chế và các tranh cãi cộng đồng tiềm năng.

Được viết chung bởi Jeffrey HuvàHarper Li

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

Nếu bạn chú ý đến từ “covenants” và tìm kiếm một chút, bạn sẽ thấy rằng đây là một cái hang thỏ lớn khác. Các nhà phát triển đã nói về các công nghệ thực hiện các điều khoản, như OP_CTV, APO, OP_VAULT và nhiều hơn nữa, ngoài OP_CAT.

Cụ thể hơn, các script Bitcoin hiện tại cũng có một số loại hợp đồng, chẳng hạn như khóa thời gian dựa trên opcode, được thực hiện bằng cách nội suy trường nLock hoặc nSequence của giao dịch để giới hạn thời gian trước khi giao dịch có thể được tiêu thụ, nhưng vẫn chỉ giới hạn trong khoảng thời gian.

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

Covenants là gì?

Covenant là một cơ chế có thể đặt điều kiện cho các giao dịch Bitcoin trong tương lai.

Trong thực tế, các kịch bản Bitcoin hiện tại chứa ràng buộc, như việc phải nhập chữ ký hợp lệ, gửi các kịch bản tuân thủ khi tiêu. Miễn là người dùng có thể mở khóa, anh ấy có thể tiêu UTXO đó ở bất kỳ nơi nào anh ấy muốn.

Covenant là việc áp đặt nhiều hạn chế hơn trên hạn chế về cách mở khóa, chẳng hạn như giới hạn chi tiêu của UTXO sau khi đã được chi tiêu, nhằm đạt được hiệu quả tương tự như việc đặt nguồn, hoặc các điều kiện đầu vào được đưa vào giao dịch, v.v.

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 kiểm tra hạn chế này? Đó là bởi vì khoản kiện không chỉ là hạn chế vô nghĩa, mà còn là việc đặt ra các quy tắc cho việc thực hiện giao dịch. Theo cách này, người dùng chỉ có thể thực hiện giao dịch theo các quy tắc được thiết lập trước, từ đó hoàn thành quy trình kinh doanh dự định.

Vì vậy, một cách ngược đời, điều này mang đến nhiều kịch bản ứng dụng hơn.

Kịch bản ứng dụng

Đảm bảo Xử phạt Staking

Một ví dụ rất trực quan về một ước lệ là quá trình cắt giảm của Babylon trong quá trình đặt cược Bitcoin.

Quy trình đặt cược Bitcoin của Babylon liên quan đến việc người dùng gửi BTC của họ đến một tập lệnh đặc biệt trên chuỗi chính với hai điều kiện chi tiêu:

• Kết thúc vui vẻ: sau một khoản thời gian nhất định, người dùng có thể mở khóa bằng chữ ký của họ, điều đó có nghĩa là quá trình rút vốn đã hoàn tất.
• Kết thúc tồi tệ: Nếu người dùng bị tấn công double-spend trên chuỗi PoS, người dùng có thể mở khóa tài sản bằng chữ ký của mình thông qua EOTS (chữ ký một lần có thể trích xuất), và một phần của tài sản có thể bị buộc gửi đến địa chỉ đốt cháy (slash) bởi một diễn viên thực thi trong mạng lưới.

Nguồn: Bitcoin Staking: Mở khóa 21 triệu Bitcoin để Bảo vệ Nền kinh tế Proof-of-Stake

Lưu ý từ “buộc”, điều này có nghĩa rằng 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, chỉ có thể được đốt cháy. Điều này đảm bảo rằng một người dùng xấu không thể thoát khỏi việc chuyển tài sản trở lại cho chính họ với chữ ký đã biết của mình.

Tính năng này, sau khi thực hiện các giao ước như OP_CTV, có thể được thực hiện bằng cách thêm opcode vào "kết thúc xấu" của tập lệnh đặt cọc.

Trước khi OP_CTV được kích hoạt, Babylon sẽ cần một phương án tạm thời để mô phỏng hiệu quả của việc áp đặt các điều khoản bằng cách yêu cầu người dùng + ủy ban làm việc cùng nhau.

Kiểm soát / Quy mô tắc nghẽn

Nói chung, tắc nghẽn xảy ra khi phí giao dịch trên Bitcoin cao với một số lượng giao dịch tương đối lớn tích luỹ trong hồ bơi 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í giao dịch.

Tại thời điểm đó, nếu người dùng phải gửi nhiều giao dịch đến nhiều địa chỉ khác nhau, họ sẽ phải tăng phí và gánh thêm chi phí cao hơn. Do đó, điều này sẽ làm tăng thêm phí giao dịch của toàn bộ mạng.

Nếu có một hiệp ước, thì có một giải pháp: một giao dịch cam kết duy nhất với nhiều đầu ra. Cam kết này có thể thuyết phục tất cả các người nhận rằng giao dịch cuối cùng sẽ diễn ra và mọi người có thể chờ đến khi phí thấp trước khi gửi giao dịch cụ thể.

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

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

Kịch bản này là một trong những trường hợp sử dụng điển hình được trình bày bởi ràng buộc OP_CTV này. Có thể tìm thấy nhiều trường hợp sử dụng khác tại https://utxos.org/uses.Ngoài việc kiểm soát tắc nghẽn được đề cập ở trên, trang liệt kê còn có các Cược Soft Fork, tùy chọn Phi tập trung, Drivechains, Kênh Batch, Kênh Không tương tác, Hồ bơi đào Trustless Coordination-Free, Kho, Hợp đồng Thời gian bị Khóa Hashed An toàn (HTLCS) Giới hạn, và nhiều hơn nữa.

Kho bảo mật

Kho bảo mật là một trong những trường hợp sử dụng của ứng dụng Bitcoin được thảo luận rộng rãi, đặc biệt là trong lĩnh vực của các điều khoản. Bởi vì các hoạt động hàng ngày không thể tránh khỏi việc cân nhắc giữa việc giữ an toàn quỹ với việc sử dụng chúng, mọi người muốn có một kho bảo mật có thể giữ an toàn quỹ, hoặc thậm chí hạn chế sử dụng chúng khi tài khoản bị hack (ví dụ, làm compromi khóa riêng tư).

Dựa trên các kỹ thuật được sử dụng để thực hiện các điều khoản hạn chế, loại kho bảo quản này có thể được xây dựng một cách tương đối dễ dàng.

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

• Nếu mọi thứ ổn, thì giao dịch thứ hai cuối cùng sẽ rút tiền. Sau khi chờ đợi N khối, tiền có thể được tiêu tiếp ở bất kỳ đâu.
• Nếu như hóa ra giao dịch bị đánh cắp (hoặc bị ép buộc trong một “tấn công kích hoạt”), tài sản có thể được gửi ngay lập tức đến một địa chỉ an toàn khác (an toàn hơn cho người dùng) ngay trước khi giao dịch rút tiền được gửi sau N khối lập tức.

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

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

Các kho báu được tính sẵn và OP_VAULT, nguồn: BIP-345

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

Có thể giả định nói chung rằng các kênh trạng thái, bao gồm Mạng Lightning, có gần như cùng mức bảo mật với chuỗi chính (liên quan đến việc đảm bảo các nút có thể quan sát trạng thái mới nhất và có thể đăng tải trạng thái mới nhất lên chuỗi). Tuy nhiên, với các hợp đồng, một số thiết kế kênh trạng thái mới có thể được tạo một cách mạnh mẽ hoặc linh hoạt hơn trên cơ sở của Mạng Lightning. Một số thiết kế nổi tiếng bao gồm Eltoo, Ark.

Eltoo (cũng được biết đến với tên LN-Symmetry) là một ví dụ điển hình. Lấy viết tắt của “L2”, công nghệ này đề xuất một lớp thực thi cho Mạng Lightning cho phép bất kỳ trạng thái kênh nào sau này thay thế trạng thái trước mà không cần cơ chế phạt, do đó tránh được việc các nút Mạng Lightning cần lưu trữ nhiều trạng thái trước đó để ngăn ngừa kẻ thù của họ thực hiện hành vi độc hại. Để đạt được hiệu ứng trên, Eltoo đề xuất chữ ký SIGHASH_NOINPUT, APO (BIP-118).

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

Tổng quan về Covenants

Như có thể thấy từ các ứng dụng trên, các ấn định hợp đồng giống như một hiệu ứng hơn là một công nghệ cụ thể, và do đó có nhiều cách kỹ thuật để triển khai chúng. Chúng có thể được phân loại như sau:

• Loại: chung, hạn chế
• Triển khai: dựa trên opcode, dựa trên chữ ký
• Đệ quy: đệ quy, không đệ quy

Ở đây, đệ quy có nghĩa là: có một số triển khai của các hiệp ước cũng có thể giới hạn đầu ra của giao dịch tiếp theo bằng cách giới hạn đầu ra của giao dịch này, điều đó có nghĩa là mỗi giao dịch trong chuỗi giao dịch bị hạn chế bởi giao dịch trước đó.

Một số mẫu thiết kế covenant phổ biến bao gồm:

Thiết kế của Covenants

Như đã thấy từ phần giới thiệu trước, các kịch bản Bitcoin hiện tại chủ yếu hạn chế các điều kiện mở khóa và không hạn chế cách mà UTXO đó có thể được tiêu thụ tiếp theo. Để triển khai các điều khoản, chúng ta cần suy nghĩ theo hướng ngược lại: tại sao các kịch bản Bitcoin hiện tại không thể triển khai các điều khoản?

Lý do chính là các kịch bản Bitcoin hiện tại không thể đọc giao dịch chính nó, điều này có nghĩa là tự kiểm tra của giao dịch.

Nếu chúng ta có thể triển khai sự tự kiểm tra - kiểm tra bất cứ điều gì trong giao dịch (bao gồm cả đầu ra) - thì chúng ta có thể triển khai các bản covenant.

Vì vậy, thiết kế của các ước hẹn cũng tập trung vào cách thức triển khai sự tự quan sát.

Dựa trên Opcode vs 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 mã opcode (một mã opcode + nhiều tham số, hoặc nhiều mã opcode với các chức năng khác nhau) và đọc nội dung của giao dịch trực tiếp. Điều này cũng được gọi là ý tưởng dựa trên mã opcode.

Một cách suy nghĩ khác là thay vì đọc và kiểm tra nội dung của giao dịch trực tiếp trong script, có thể sử dụng hash của nội dung giao dịch, điều này có nghĩa là nếu hash này đã được ký, sau đó bằng cách biến đổi opcode như OP_CHECKSIG trong script để kiểm tra chữ ký này, có thể giúp thực hiện gián đoạn và khả năng tự kiểm tra giao dịch một cách gián tiếp. Ý tưởng này dựa trên phương pháp thiết kế chữ ký. Nó chủ yếu bao gồm APO và OP_CSFS.

APO

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

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

Như đã thấy ở trên, ngoài ALL áp dụng cho tất cả dữ liệu, NONE được ký theo cách chỉ áp dụng cho tất cả các đầu vào và không áp dụng cho các đầu ra, và SINGLE xây dựng trên điều này bằng cách áp dụng nó chỉ cho các đầu ra có số chỉ mục đầu vào giống nhau. Ngoài ra, SIGHASH có thể kết hợp, với bộ sửa đổi ANYONECANPAY được đặt lên, để áp dụng chỉ cho một đầu vào.

APO’s SIGHASH, ngược lại, chỉ ký đầu ra, không phải đầu vào. Điều này có nghĩa là giao dịch được ký bằng APO có thể được đính kèm sau này vào bất kỳ UTXO nào đáp ứng điều kiện.

Tính linh hoạt này là lý do đằng sau việc thực hiện các điều khoản của APO:

• Một hoặc nhiều giao dịch có thể được tạo ra trước
• Thông tin từ các giao dịch này được sử dụng để xây dựng một khóa công khai mà chỉ chữ ký chi tiêu mới có thể được suy ra/kiểm tra
• để đảm bảo rằng bất kỳ tài sản nào được gửi đến địa chỉ khóa công khai này chỉ có thể được chi tiêu thông qua các giao dịch đã được tạo trước.

Chúng tôi nên lưu ý rằng vì khóa công khai này không có khóa riêng tư tương ứng, nó đảm bảo rằng các tài sản này chỉ có thể được chi tiêu thông qua các giao dịch đã được tạo trước. Sau đó, chúng ta có thể thực hiện một hiệp ước bằng cách xác định nơi mà các tài sản sẽ đi trong các giao dịch đã được tạo trước.

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

Tuy nhiên, vấn đề với quá trình trên là có một dev@lists.linuxfoundation.org/msg08075.html">không thể đệ quy trong quá trình tính toán, vì cần phải biết đầu vào để ký trước và tạo giao dịch.

Tầm quan trọng của APO và việc triển khai SIGHASH_NOINPUT của phương pháp chữ ký này là giải quyết vấn đề phụ thuộc vòng tròn bằng việc chỉ cần biết (xác định) đầy đủ đầu ra của giao dịch vào thời điểm tính toán.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), hoặc BIP-119, sử dụng một cải tiến cho Opcode. Nó lấy băm cam kết làm đối số và yêu cầu rằng bất kỳ giao dịch nào thực hiện một opcode chứa một tập hợp các đầu ra khớp với cam kết đó. Với CTV, nó sẽ cho phép người dùng Bitcoin giới hạn cách họ sử dụng Bitcoin.

Ban đầu được giới thiệu dưới dạng OP_CHECKOUTPUTSHASHVERIFY (COSHV) và tập trung sớm vào khả năng tạo giao dịch kiểm soát tắc nghẽn, sự chỉ trích về đề xuất cũng tập trung vào việc nó không phổ quát đủ và quá cụ thể cho 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 kẹt xe được đề cập ở trên, Alice, người gửi, có thể tạo ra 10 đầu ra và băm 10 đầu ra đó, sau đó sử dụng bản rút trích kết quả để tạo ra một tập tin script chứa COSHV. Alice cũng có thể sử dụng các khóa công khai của các bên tham gia để hình thành một khóa nội bộ Taproot cho phép họ cùng nhau làm việc để chi tiêu tiền mà không cần tiết lộ con đường của kịch bản Taproot.

Sau đó, Alice cung cấp cho mỗi người nhận một bản sao của tất cả 10 đầu ra để mỗi người trong số họ có thể xác minh giao dịch thiết lập của Alice. Khi họ muốn chi tiêu thanh toán sau này, bất kỳ ai trong số họ đều có thể tạo giao dịch với các đầu ra đã cam kết.

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 của các đầu ra này thông qua các phương pháp truyền thông bất đồng bộ hiện có, 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/#proposed-transaction-output-commitments

Tương tự như APOs, địa chỉ có thể được xây dựng dựa trên điều kiện chi tiêu, và “khóa” có thể được thực hiện bằng cách khác nhau, bao gồm các khóa bổ sung, khóa thời gian tương đối hoặc cố định, và các logic khác để kết hợp chúng.

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

Dựa trên điều này, CTV đề xuất kiểm tra xem giao dịch đã tiêu sau băm khớp với giao dịch đã xác định, điều đó có nghĩa là dữ liệu giao dịch được sử dụng như là chìa khóa để mở khóa “khóa”.

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

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

Và nếu một trong những lá là một kênh sét đánh, hoặc lưu trữ lạnh, hoặc một đường thanh toán khác? Sau đó, cây sẽ được mở rộng từ một cây thanh toán đa chiều một chiều đến một cây thanh toán đa chiều đa chiều, và các kịch bản có thể được hỗ trợ sẽ phong phú và linh hoạt hơn.

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

Kể từ khi được đề xuất, CTV đã trải qua việc thay đổi tên từ COSHV vào năm 2019, được gán BIP-119 vào năm 2020, và sự xuất hiện của Sapio, ngôn ngữ lập trình được sử dụng để tạo hợp đồng hỗ trợ CTV, và đã nhận được rất nhiều thảo luận của cộng đồng, cập nhật và tranh luận về các tùy chọn kích hoạt của nó vào năm 2022 và 2023, và vẫn là một trong những đề xuất nâng cấp soft fork được thảo luận nhiều nhất trong cộng đồng.

OP_CAT

OP_CAT, như mô tả trong đoạn mở đầu, cũng là một đề xuất nâng cấp đang nhận được rất nhiều sự chú ý, và thực thi một chức năng nối hai phần tử hoặc hai tập dữ liệu từ ngăn xếp. Mặc dù trông đơn giản, OP_CAT rất linh hoạt và có thể thực thi trong các kịch bản theo nhiều cách khác nhau.

Ví dụ trực tiếp nhất là hoạt động của Merkle Tree, có thể được hiểu là hai phần tử được nối và sau đó được băm. Hiện tại, có OP_SHA256 và các mã lệnh băm khác trong kịch bản Bitcoin, vì vậy nếu bạn có thể nối hai phần tử bằng cách sử dụng OP_CAT, bạn có thể thực hiện chức năng xác minh Merkle Tree trong kịch bản, đồng thời cũng cung cấp khả năng xác minh của máy khách nhẹ đến một mức độ nào đó.

Một cơ sở khác cho việc triển khai là việc cải thiện chữ ký Schnorr: bạn có thể đặt điều kiện ký chi tiêu của một script để là sự liên kết giữa khóa công khai của người dùng và một nonce công khai; sau đó nếu người ký muốn ký giao dịch khác để chi tiêu tiền ở nơi khác, anh ấy hoặc cô ấy phải sử dụng cùng một nonce, điều này có thể tiết lộ khóa riêng tư. Đó là, OP_CAT đạt được cam kết với nonce và đảm bảo tính hợp lệ của giao dịch đã ký.

Các ứng dụng khác của OP_CAT bao gồm Bistream,chữ ký cây, chữ ký Lamport chống lại quantum, kho bảo và nhiều hơn nữa.

OP_CAT chính nó không phải là một tính năng mới, vì nó đã tồn tại trong những phiên bản sớm nhất của Bitcoin, nhưng đã tắt năm 2010 do tiềm năng bị tấn công. Ví dụ, việc sử dụng lặp đi lặp lại của OP_DUP và OP_CAT có thể dễ dàng gây nổ stack của nút đầy khi xử lý các kịch bản như vậy, như đã thấy trong điều này danh mục.

Nhưng liệu vấn đề nổ ngăn xếp được đề cập ở trên có xảy ra ngày nay sau khi OP_CAT đã được kích hoạt lại 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, có giới hạn là 520 byte cho mỗi phần tử ngăn xếp, điều này sẽ không gây ra vấn đề nổ ngăn xếp trước đó. Cũng có một số nhà phát triển nghĩ rằng Satoshi Nakamoto có thể đã quá nghiêm khắc khi vô hiệu hóa OP_CAT ngay lập tức. Tuy nhiên, do tính linh hoạt của OP_CAT, có thể đúng rằng một số kịch bản ứng dụng có thể dẫn đến các lỗ hổng sẽ tồn tại.

Do đó, kết hợp các kịch bản ứng dụng và rủi ro tiềm năng, OP_CAT đã nhận được rất nhiều sự chú ý gần đây, và cũng đã có một PR review, và hiện đang là một trong những đề xuất nâng cấp nóng bỏng nhất.

Kết luận

“Tự quy định mang lại sự tự do”, như có thể thấy từ sự giới thiệu ở trên, các điều khoản có thể được triển khai trực tiếp vào các script Bitcoin để đảm bảo việc tiêu tiền tiếp theo trên các giao dịch, từ đó cho phép quy tắc giao dịch tương tự như hiệu ứng của hợp đồng thông minh. Cách tiếp cận lập trình này có thể được xác minh một cách tự nhiên hơn trên Bitcoin so với các cách tiếp cận ngoại chuỗi như BitVM, và cũng có thể cải thiện các ứng dụng trên chuỗi chính (kiểm soát quá tải), các ứng dụng ngoại chuỗi (kênh trạng thái), và các hướng ứng dụng mới khác (cắt giảm staking, v.v.).

Các kỹ thuật triển khai của các bản ký ức, nếu kết hợp với một số nâng cấp khác, có thể mở khóa tiềm năng của Khả năng lập trình. Ví dụ, đề xuất gần đây về số học 64-bit

trong đánh giácó thể được kết hợp thêm với đề xuấtOP_TLUVhoặc các điều khoản khác có thể được lập trình dựa trên số satoshi được xuất ra bởi giao dịch.

Tuy nhiên, các điều khoản cũng có thể dẫn đến những lạm dụng hoặc lỗ hổng không đúng kế hoạch, vì vậy cộng đồng cũng rất cẩn trọng về điều này. Ngoài ra, việc nâng cấp các điều khoản sẽ cần phải liên quan đến việc nâng cấp soft fork của các quy tắc đồng thuận. Với hoàn cảnh xung quanh việc nâng cấp taproot, có khả năng rằng việc nâng cấp liên quan đến các điều khoản cũng sẽ mất thời gian để hoàn thành.

Cảm ơn đặc biệt

Cảm ơn Ajian, Fisher và Benđể xem xét và đề xuất!

Tham khảo

• https://utxos.org/
• https://bitcoincovenants.com/
• Một bộ sưu tập tài nguyên liên quan đến các hiệp ướ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-final28.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
• CAT và các mẹo Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Xin lưu ý: Tài liệu này chỉ dành cho mục đích thông tin chung, không chiếm, cũng không nên được hiểu là bất kỳ hình thức tư vấn đầu tư, mời mọc hoặc đề xuất đầu tư nào, và không có trách nhiệm hoặc trách nhiệm nào được chấp nhận bởi HashKey Capital liên quan đến việc sử dụng hoặc phụ thuộc vào bất kỳ thông tin nào như vậy.

Cập nhật tin tức mới nhất từ HashKey Capital -

Website — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

tuyên bố:

1. Bài viết này được sao chép từ [trung bình], bản quyền thuộc về tác giả gốc [Jeffrey Hu và Harper Li], nếu bạn có bất kỳ ý kiến nào về việc tái bản, vui lòng liên hệ Học cửađội , và đội sẽ xử lý nó càng sớm càng tốt theo các quy trình liên quan.

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

3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn và không được đề cập trong Gate.io, bài viết dịch không được sao chép, phân phối hoặc đạo văn.