Fractal Bitcoin OP_CAT: Giải thích kỹ thuật chi tiết về các hạn chế

Tác giả: Thủ lĩnh băng đảng ở đây với: >

op_cat đã được đề xuất làm ràng buộc và gần đây nó đã nhận được số BIP của 347. Đầu tiên chúng ta hãy hiểu “giao ước” là gì.

 1. Trước tiên chúng ta phải hiểu những hạn chế cơ bản của Bitcoin Script ngày nay. Nhìn bề ngoài, Bitcoin cho phép tạo ra các hợp đồng thông minh cơ bản: mã xác định các quy tắc khóa và mở khóa tiền. Tuy nhiên, ngôn ngữ lập trình của nó, Bitcoin Script, rất hạn chế và chỉ hoạt động khi các giao dịch liên quan đến việc chuyển tiền.

2. Trong Bitcoin ngày nay, bạn không có cách nào để định cấu hình trước hoặc chỉ định đường dẫn chuyển tiền của mình cũng như không thể giới hạn khi khóa quỹ. tiền có thể được rút nhanh chóng (trừ khi bạn sử dụng quy trình làm việc độc đáo dựa trên PSBT (Giao dịch Bitcoin đang chờ xử lý), nhưng điều này không xử lý tốt phí giao dịch cũng như không xóa nó một cách đáng tin cậy khi bạn quyết định không còn cần thiết nữa, hãy chặn phát sóng). Sự đơn giản này, mặc dù là cốt lõi của mô hình bảo mật Bitcoin, nhưng lại mang đến những hạn chế đáng kể đối với khả năng của Script, một ngôn ngữ lập trình, để hỗ trợ các hợp đồng thông minh (thậm chí là cơ bản). Chế độ thực hiện tuyến tính.

Chế độ thực thi tuyến tính

1 Một trong những hạn chế của Bitcoin Script nằm ở hoạt động của nó. chế độ: Các mã hoạt động được thực thi tuần tự và không có vòng lặp.

Lấy giao dịch P2PKH này làm ví dụ, bạn có thể thấy tập lệnh được thực thi tuyến tính: sao chép khóa chung, băm khóa chung thành một địa chỉ, xác minh Giá trị băm nhất quán với tập lệnh khóa và khóa chung này cuối cùng được sử dụng để kiểm tra chữ ký giao dịch. Việc thiếu vòng lặp có nghĩa là tập lệnh không hoàn thành Turing và được đảm bảo chấm dứt, ngăn chặn các hoạt động vòng lặp vô hạn có thể gây ra thời gian ngừng hoạt động của nút hoặc làm chậm đáng kể toàn bộ mạng. Mặc dù lựa chọn thiết kế này cho phép hạn chế mức tiêu thụ tài nguyên về mặt tĩnh nhưng nó cũng hạn chế khả năng quản lý các quy trình công việc phức tạp của Tập lệnh.

2. Thiếu số học cơ bản Bitcoin Script có ít hơn 100 opcode quan trọng, điều này đôi khi gây ngạc nhiên: nó không thể nhân, chia hoặc Kết hợp các đối tượng trong ngăn xếp. Nhiều người dùng quan tâm đến OP_CAT có thể biết rằng Satoshi Nakamoto đã vô hiệu hóa nhiều opcode trong Bitcoin vào năm 2010, bao gồm OP_OR, OP_MUL (nhân), OP_DIV (chia) và OP_CAT (nối chuỗi). Các opcode bị vô hiệu hóa này đã bị xóa vì quá trình triển khai ban đầu của chúng có các lỗ hổng có thể khai thác được và có thể ảnh hưởng đến an ninh mạng. Nhưng việc thiếu các opcode này khiến Script khó thực hiện các phép toán cơ bản, vốn rất hữu ích trong một số trường hợp đơn giản, chẳng hạn như tính phí giao dịch trong hợp đồng.

3. Nói trắng ra, tôi nghĩ hầu hết mọi người đều cho rằng hợp đồng thông minh của Bitcoin có thể xem số tiền giao dịch và các phần khác của giao dịch. . Dữ liệu, vì thông tin này được hiển thị công khai trên blockchain. Nhưng điều ngược lại mới đúng. Hợp đồng trong Bitcoin không thể đặt điều kiện chi tiêu dựa trên dữ liệu giao dịch, vì khả năng hiểu dữ liệu giao dịch của Bitcoin Script rất hạn chế. Nếu tập lệnh có khả năng xem xét nhiều chi tiết hơn trong dữ liệu giao dịch, chúng tôi có thể phát triển các hợp đồng thông minh mạnh mẽ hơn nhiều, có thể thực hiện tất cả những điều thú vị như thực thi một điều kiện chi tiêu nhất định, tạo các giao dịch được thực hiện theo từng giai đoạn và cho phép bảo mật nâng cao hơn các tính năng (chẳng hạn như “vault”).

4. Vậy chúng ta nên làm gì? Nhiều thử nghiệm tiên phong hơn trong Bitcoin Script, chẳng hạn như ngôn ngữ Đơn giản và các ngôn ngữ khác, nhằm mục đích cung cấp các lựa chọn thay thế cho các ràng buộc dạng ngăn xếp. Các mã opcode như OP_MULTISHA256, OP_LESS và OP_LE32TOLE64 được thiết kế để nâng cấp sức mạnh tính toán của Bitcoin. Các đề xuất xử lý các mã hoạt động nội quan như OP_CTV và OP_CAT được phân loại là "hạn chế". Vậy, sự khác biệt giữa "hợp đồng thông minh" và "hạn chế" là gì?

5. Hợp đồng thông minh so với các hạn chế Hợp đồng thông minh là các giao dịch tự thực hiện có thể chuyển tiền mà không cần qua trung gian. Trên Bitcoin ngày nay, các hợp đồng thông minh chỉ giới hạn ở hoạt động khóa và mở khóa Bitcoin bằng Bitcoin Script. Các hạn chế được thiết kế để nâng cao khả năng hợp đồng thông minh của Bitcoin bằng cách cho phép người dùng kiểm soát cách chi tiêu tiền của họ trong các giao dịch trong tương lai. Nếu chúng tôi cho phép Script xem xét dữ liệu giao dịch thì về cơ bản chúng tôi cho phép sử dụng dữ liệu này trong logic hợp đồng. Dưới đây là một số mã hoạt động nội quan thú vị hơn được đề xuất để giới hạn chức năng của mệnh đề:

OP_TXHASH: Cung cấp giá trị băm của đầu vào (hoặc đầu ra) của giao dịch , và cung cấp cho Script khả năng xác thực và thực thi các điều kiện dựa trên dữ liệu giao dịch. OP_CSFS + OP_CAT: Hai mã opcode này cho phép các tập lệnh kiểm tra chữ ký trên dữ liệu tùy ý, không chỉ chính giao dịch. Điều này có nghĩa là Tập lệnh có thể xác minh các điều kiện dựa trên dữ liệu giao dịch và thông tin bên ngoài, điều này mở rộng khả năng hoạt động xác minh trong tập lệnh Bitcoin. Hai mã hoạt động này được thiết kế trên phạm vi rộng nên chúng có thể hỗ trợ các quy trình xác minh phức tạp và khả năng xem xét nội tâm. Những người khác cố tình thu hẹp và được thiết kế để hạn chế hơn.

OP_CHECKTEMPLATEVERIFY (CTV): cho phép nhúng đầu ra của giao dịch vào mẫu của giao dịch chi tiêu tiếp theo, cho phép hạn chế hạn chế hơn. OP_VAULT: Cho phép hạn chế cụ thể đối với hợp đồng Vault, cho phép người dùng chỉ định đích đến của giao dịch nhưng không thực sự chuyển tiền cho đến khi hết thời gian trễ.

Ngoài ra còn có OP_CAT, đây không phải là opcode cho phép trực tiếp xem xét nội tâm... OP_CAT: cho phép Script ghép hai phần tử trong ngăn xếp qua lại. có thể sử dụng để tập hợp các đoạn thông tin trong kịch bản.

OP_CAT: Giải phóng mọi khả năng Trong Bitcoin Script, chỉ có ba opcode chính có thể xem xét dữ liệu giao dịch: CHECKLOCKTIMEVERIFY (khóa thời gian tuyệt đối),

Ngoài ra, chúng còn có một số biến thể, chẳng hạn như: CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG và CHECKMULTISIGVERIFY, về cơ bản là các biến thể vi mô của CHECKSIG; có thể xem liệu kiểm tra có vượt qua hay không và chỉ cung cấp chức năng rất hẹp. CHECKSIG cũng tương tự, ngoại trừ việc bạn có thể lấy chữ ký và khóa chung từ ngăn xếp.

Trước đây, chúng ta hiểu phép nối là hàm nối hai phần tử, nhưng chúng ta cũng có thể sử dụng nó để tách một phần tử - chia chữ ký thành (r, s) Đúng.

Làm cách nào để lấy được hàm OP_SPLIT (tách) từ OP_CAT (nối)? "Nếu bạn có một số đối tượng lớn, bạn có thể chia chúng làm đôi bằng cách yêu cầu người dùng cung cấp hai mảnh này tại thời điểm tiêu thụ. Bạn có thể CAT hai mảnh rồi kiểm tra sự bằng nhau. Mỗi thao tác có thể được sử dụng Phương pháp này được đảo ngược . Với CAT, bạn có thể chia đôi chữ ký ”

Chuyện quái gì đang xảy ra vậy? Trước tiên, người dùng cung cấp chữ ký, khóa chung và giao dịch đã ký. Bạn có thể chia đôi chữ ký và kiểm tra từng phần riêng biệt với dữ liệu giao dịch. Kỹ thuật này có thể được coi là một loại phân đoạn hoặc một loại ghép nối, bởi vì nó xác minh rằng chữ ký và khóa chung là một phần của giao dịch hợp lệ. (Lưu ý của người dịch: "Dữ liệu có thể được chia thành hai nửa" ở đây không có nghĩa là một phần dữ liệu có thể được chia thành hai phần trong quá trình chạy tập lệnh, mà hai phần dữ liệu được truyền riêng biệt dưới dạng dữ liệu chứng kiến , sau đó sử dụng CAT Việc ghép chúng lại với nhau và chạy kiểm tra lẽ ra đã chạy trên dữ liệu hoàn chỉnh cho phép chúng tôi chạy kiểm tra bổ sung trên cả hai phần dữ liệu khi chúng được chuyển vào. Điều này có liên quan gì đến việc xem xét nội tâm? "Trong Taproot, chúng tôi đã có chữ ký Schnorr. Sử dụng mã xác minh chữ ký OP_CAT và Schnorr, hóa ra là chúng tôi có thể nhận được một ràng buộc không đệ quy: bạn thực sự có thể nhận được hàm băm của một giao dịch. Thay vì giá trị băm giao dịch được viết nguệch ngoạc là giá trị băm SHA2 của tất cả dữ liệu giao dịch trong ngăn xếp ”

Cách lấy các đầu vào giao dịch còn lại trong ngăn xếp Hoặc hàm băm SHA2 của đầu ra. Chúng ta sẽ bỏ qua phép toán ma thuật, nhưng đây là điểm khởi đầu: bằng cách sử dụng OP_CAT, chúng ta đặt ra các ràng buộc đối với một số phần nhất định của giao dịch làm yêu cầu để mở khóa tập lệnh. Chúng tôi có thể hạn chế địa chỉ của người gửi hoặc số tiền được gửi trong một giao dịch và hàm băm của giao dịch sẽ đóng vai trò là chìa khóa để mở khóa tiền.

An toàn

Sử dụng kỹ thuật tương tự, chúng ta có khả năng giao dịch nội tâm, Và đưa ra chúng tôi một hợp đồng an toàn cơ bản ngay lập tức. Theo lý luận của Poelstra trong bài viết, một nhà phát triển tên Rijndael đã chứng minh rằng chúng tôi có thể triển khai Purrfect Vaults ("Perfect Vaults") chỉ với OP_CAT. Người dùng có thể chỉ định địa chỉ mà số tiền sẽ chuyển đến tiếp theo, điều này cung cấp cơ chế thu hồi tiền nếu khóa bị xâm phạm và làm giảm động cơ đánh cắp khóa riêng tư.

Cây Merkle trong script

Trong Bitcoin ngày nay, “cây Kerr mặc định” Cấu trúc dữ liệu này được sử dụng để xác minh, đồng bộ hóa dữ liệu và theo một nghĩa nào đó là các giao dịch và khối "ràng buộc". OP_CAT có thể ghép hai biến trong ngăn xếp và khi được sử dụng với hàm băm SHA256 của khóa chung, trình xác minh cây Merkle trực tiếp có thể được triển khai trong tập lệnh. Cách tiếp cận này, ban đầu được đề xuất bởi Pieter Wuille vào năm 2015, đã được triển khai trong Liquid.

Chữ ký cây

Cung cấp tập lệnh đa chữ ký có cùng kích thước với khóa chung Con số này có mối quan hệ logarit và có thể mã hóa các điều kiện chi tiêu khác với n-of-m. Ví dụ: các giao dịch nhỏ hơn 1 KB có thể hỗ trợ chữ ký cây với 1000 khóa chung. Nó cũng mở ra các điều kiện chi tiêu để khái quát hóa một cách hợp lý.

Giới hạn loại đệ quy Mệnh đề ràng buộc

Nếu bạn có thể diễn giải một giao dịch và áp đặt các ràng buộc lên các phần cụ thể của giao dịch đó, thì bạn có thể tạo các điều kiện có thể được áp dụng qua nhiều giao dịch . Điều kiện, tức là tạo ra những chuỗi ràng buộc liên tục. Khái niệm này được gọi là "hạn chế đệ quy".

OP_CAT là một giao thức độc đáo vì nó mang lại cho chúng ta sức mạnh to lớn chỉ với 10 dòng mã. Nó giải quyết tất cả các hạn chế mà chúng tôi đã đề cập trước đó: khả năng hiển thị dữ liệu giao dịch, khả năng toán học tốt hơn và mô hình thực thi tuyến tính. Mặc dù OP_CAT thoạt nhìn có vẻ không có gì nổi bật nhưng nó mở ra tiềm năng to lớn có thể khai thác một cách sáng tạo. Nó cũng có thể đóng vai trò là nền tảng cho nhiều khả năng hơn nằm ngoài phạm vi của bài viết này, chẳng hạn như chữ ký Lamport kháng lượng tử.

Có an toàn không?

Trước khi OP_CAT bị xóa lần đầu, kết hợp với OP_DUP (ngăn xếp trùng lặp), ngay cả khi đối tượng được thao tác ban đầu trong ngăn xếp chỉ có 1 byte, bằng cách áp dụng nhiều lần điều này Đối với opcodes, kích thước của đối tượng ngăn xếp cũng sẽ mở rộng nhanh chóng cho đến khi bộ nhớ được lấp đầy. Điều này có thể được sử dụng như một cuộc tấn công DoS. Đề xuất mới dễ dàng ngăn chặn cuộc tấn công này bằng cách áp đặt giới hạn 520 byte cho các phần tử ngăn xếp.

Có rủi ro khi tạo hợp đồng có thời hạn vô thời hạn không?

Nếu câu hỏi là đúng, thì việc OP_CAT thay đổi chế độ thực thi tuyến tính của tập lệnh có nghĩa là tập lệnh không còn có thể hạn chế tĩnh việc sử dụng tài nguyên của nó nữa (làm cho tập lệnh trở thành tập lệnh tuyến tính hàm của âm lượng), thì câu trả lời là không.

Liệu các hạn chế có tạo ra thị trường cho việc phát hành các loại tiền khác trên Bitcoin không?

Nếu chúng tôi có các hạn chế đệ quy thì về mặt kỹ thuật, bạn có thể phát triển các ứng dụng 2 lớp phức tạp, bao gồm NFT, sàn giao dịch phi tập trung, mèo điện tử, v.v. Tuy nhiên, nó không phải là dễ dàng để làm điều đó. Thật khó để thấy điều này sẽ tạo ra một thị trường lớn như thế nào.

Bạn có thể sử dụng CAT để "làm hoen ố" vĩnh viễn một khoản tiền không?

Trong trường hợp đồng tiền màu và NFT, việc phát hành tài sản thực sự "đốt cháy" một satoshi, đánh dấu nó tượng trưng cho quyền sở hữu tài sản "lớp 2". Quá trình này được gọi là "ô nhiễm". Nhưng chỉ chủ sở hữu một khoản tiền mới có thể đánh dấu số tiền của mình và ví Bitcoin không hiểu điều này (trừ khi nhà phát triển thêm mã bổ sung để kích hoạt tính năng này). Các đồng tiền thu được cũng sẽ không được ví Bitcoin chấp nhận. Có thể chúng sẽ được ví Tamagotchi hoặc thứ gì đó chấp nhận, nhưng nó sẽ không liên quan đến đại đa số người dùng Bitcoin.

Nó có gây ra vấn đề MEV cho Bitcoin không?

Điểm khác biệt chính giữa Bitcoin và Ethereum là khả năng hiển thị của các giao dịch. Không giống như Ethereum, không phải tất cả các khía cạnh của hợp đồng trong Bitcoin đều nhất thiết phải minh bạch, do đó, những người khai thác Bitcoin không có khả năng giống như những người khai thác Ethereum trong việc xem trạng thái nội bộ của hợp đồng và thực hiện trước một số hoạt động nhất định.

Mối quan tâm chính về OP_CAT là nó có thể ảnh hưởng đến các khuyến khích kinh tế và tạo ra "Giá trị có thể trích xuất của thợ mỏ (MEV)". Bài viết cuối cùng của tôi đã thảo luận chi tiết về chủ đề này. Điều mà nhiều người dùng lo ngại là nếu chúng tôi thực hiện được các hợp đồng lớp 2 về mặt kỹ thuật thì MEV chắc chắn sẽ xuất hiện.

Nhưng thực tế có phải như vậy không? Cụ thể, nếu bạn có thể phát hành coin lớp 2 trên Bitcoin, điều đó có nghĩa là chúng chắc chắn sẽ được chấp nhận? Bạn có thể tưởng tượng việc phát triển các hợp đồng hoán đổi đơn giản hoặc NFT tương đối kém hiệu quả, nhưng việc phát triển một thứ gì đó phức tạp như sàn giao dịch phi tập trung với các nhà tạo lập thị trường tự động là điều gần như không thể và mặc dù “Hoạt động về mặt kỹ thuật” nhưng chúng tôi chưa bao giờ thấy bất cứ điều gì như thế này được phát triển trên Liquid.

OP_CAT có tương đối hoàn hảo không?

Một số người chơi Bitcoin, có thể được gọi là "những người theo chủ nghĩa kiên cố hóa", ủng hộ việc giữ Bitcoin ở trạng thái hiện tại và nghi ngờ về bất kỳ nâng cấp giao thức nào. Họ đặc biệt lo ngại rằng những thay đổi lớn, chẳng hạn như việc đưa ra các hạn chế, có thể làm giảm tính phân cấp của mạng. Tuyên bố của họ dựa trên niềm tin rằng tốt hơn hết là nên bám sát tầm nhìn ban đầu của Bitcoin.

Điều trớ trêu là OP_CAT là một phần của Bitcoin ban đầu, dẫn đến ý kiến ​​​​hoàn toàn ngược lại. Một số người tin rằng việc đưa OP_CAT trở lại phù hợp hơn với tầm nhìn ban đầu của Satoshi Nakamoto.

OP_CAT là lựa chọn tốt nếu bạn muốn có một số tính năng bảo mật của các hạn chế đệ quy, nhưng nó chắc chắn không tốt bằng ngôn ngữ kịch bản kiểu Lisp toàn diện. . Vấn đề là việc giới thiệu một thứ như thế này sẽ là một sự thay đổi lớn và khó có thể sớm thu hút được sự chú ý. Hoặc có thể bạn ở phía bên kia và thích sự đơn giản của các ràng buộc không đệ quy như OP_CTV và OP_VAULT.

Các hạn chế không đệ quy đơn giản hơn và dễ phân tích hơn mà không có nguy cơ tạo ra các chuỗi hạn chế không được kiểm soát. Nhưng điều gì sẽ xảy ra nếu một số hình thức hạn chế đệ quy nhất định xảy ra? Trong vài năm qua, các nhà phát triển đã nhận thấy rằng hầu hết mọi phần mở rộng logic xác minh giao dịch đều có thể được sử dụng để mô phỏng chức năng của OP_CAT. Trong vũ trụ của Script, hai thế giới có thể được phân chia dựa trên số lượng phần tử ngăn xếp. Đối với các phần tử lớn hơn 4 byte, bạn có thể kiểm tra sự bằng nhau, diễn giải chúng dưới dạng khóa công khai hoặc chữ ký và băm chúng. Đối với các phần tử nhỏ hơn hoặc bằng 4 byte, bạn có thể thực hiện các thao tác trên chúng. Với bộ xử lý RISC-V chạy trên BitVM, bạn có thể làm bất cứ điều gì. Bất cứ điều gì cho phép bạn mô phỏng chức năng OP_CAT (tách các phần tử ngăn xếp hoặc ghép chúng lại với nhau) sẽ hợp nhất hai thế giới này, cho phép bạn "làm bất cứ điều gì" trong tập lệnh của mình.

Một số nhà nghiên cứu, chẳng hạn như Andrew Poelstra, dự đoán rằng chúng ta có thể tạo ra các ràng buộc đệ quy với một số lượng rất nhỏ các opcode mới. Nếu điều này là đúng thì có lý do để tìm ra cách tốt nhất có thể. OP_CAT có phải là đề xuất hạn chế có nhiều khả năng được thông qua nhất không? OP_CAT vẫn là một đối thủ mạnh trong cuộc tranh luận về các biện pháp hạn chế. OP_CAT không phải là công cụ đẹp nhất nhưng nó có tỷ lệ công suất/độ phức tạp cao nhất, cho phép các nhà phát triển tạo ra một số tính năng mới tuyệt vời. Có nhiều khả năng hơn cho tương lai của BTC.