tổng quan

So với các chuỗi khối có khả năng hoàn toàn turing như ethereum, bitcoin scripting được coi là hạn chế cao, chỉ có khả năng thực hiện các hoạt động cơ bản, và thậm chí thiếu hỗ trợ cho phép nhân và chia. Quan trọng hơn, dữ liệu của blockchain gần như không thể truy cập được bởi các script, dẫn đến sự thiếu linh hoạt và khả năng lập trình đáng kể. Do đó, đã có nỗ lực lâu dài để cho phép bitcoin scripts đạt được khả năng tự phân tích.

introspection refers to the ability of Bitcoin scripts to inspect and constrain transaction data. this allows scripts to control the usage of funds based on specific transaction details, enabling more complex functionalities. currently, most Bitcoin opcodes either push user-supplied data onto the stack or manipulate existing data on the stack. introspection opcodes, however, can push data from the current transaction (such as timestamps, amounts, txid, etc.) onto the stack, allowing for more granular control over UTXO spending.

Hiện tại, chỉ có ba mã lệnh chính trong việc viết kịch bản Bitcoin hỗ trợ kiểm tra: checklocktimeverify, checksequenceverify và checksig, cùng với các biến thể của nó như checksigverify, checksigadd, checkmultisig và checkmultisigverify.

Covenant, đơn giản thì đề cập đến những hạn chế về cách chuyển đổi tiền, cho phép người dùng chỉ định cách phân phối utxo. Nhiều covenant được thực hiện thông qua các mã opcode tự phân tích, và các cuộc thảo luận về tự phân tích hiện đã được phân loại dưới chủ đề covenant trên.Bitcoin optech.

Bitcoin hiện có hai hợp đồng, csv (checksequenceverify) và cltv (checklocktimeverify), cả hai đều là hợp đồng dựa trên thời gian và là nền tảng cho nhiều giải pháp về mở rộng như mạng lightning. Điều này cho thấy giải pháp mở rộng của Bitcoin phụ thuộc mạnh vào việc tự kiểm tra và hợp đồng.

làm thế nào chúng ta thêm điều kiện vào việc chuyển đổi của đồng tiền? trong không gian mật mã, phương pháp phổ biến nhất của chúng tôi là thông qua cam kết, thường được thực hiện thông qua các hash. Để chứng minh rằng các yêu cầu chuyển đổi được đáp ứng, cơ chế chữ ký cũng cần được sử dụng để xác minh. Do đó, nhiều điều chỉnh về các hash và chữ ký tồn tại trong các hiệp ước.

Dưới đây, chúng tôi sẽ mô tả đề xuất mã opcode Thánh thỏa được thảo luận rộng rãi.

ctv (checktemplateverify) bip-119

CTV (CheckTemplateVerify) là một đề xuất nâng cấp Bitcoin có trong BIP-119 đã thu hút được sự chú ý đáng kể của cộng đồng. CTV cho phép tập lệnh đầu ra chỉ định một mẫu để chi tiêu tiền trong một giao dịch, bao gồm các trường như nversion, nlocktime, băm scriptsig, số lượng đầu vào, hàm băm chuỗi, số lượng đầu ra, hàm băm đầu ra, chỉ mục đầu vào. Các hạn chế mẫu này được thực hiện thông qua cam kết băm và khi tiền được chi tiêu, tập lệnh sẽ kiểm tra xem giá trị băm của các trường được chỉ định trong giao dịch chi tiêu có khớp với giá trị băm trong tập lệnh đầu vào hay không. Điều này giới hạn hiệu quả thời gian, phương pháp và số lượng giao dịch trong tương lai của UTXO đó.

Đáng chú ý, input txid được loại trừ khỏi hash này. Sự loại trừ này là cần thiết, vì trong cả giao dịch legacy và segwit, txid phụ thuộc vào các giá trị trong scriptpubkey khi sử dụng kiểu ký hiệu sighash_all mặc định. Bao gồm txid sẽ dẫn đến một phụ thuộc vòng tròn trong cam kết hash, khiến cho việc xây dựng trở nên không thể.

ctv triển khai kiểm tra bên trong bằng cách trực tiếp lấy thông tin giao dịch cụ thể để băm và so sánh với cam kết trên ngăn xếp. Phương pháp này của kiểm tra bên trong ít yêu cầu không gian chuỗi hơn nhưng thiếu một số tính linh hoạt.

Nền tảng của các giải pháp tầng hai của Bitcoin như Lightning Network là các giao dịch được ký trước. Việc ký trước thường đề cập đến việc tạo và ký các giao dịch trước nhưng không phát sóng chúng cho đến khi đáp ứng được một số điều kiện nào đó. CTV cài đặt một hình thức ký trước nghiêm ngặt hơn, đăng tải cam kết của việc ký trước trên chuỗi, giới hạn trong mẫu được xác định trước.

ctv ban đầu được đề xuất nhằm giảm tắc nghẽn trong Bitcoin, cũng có thể được gọi là kiểm soát tắc nghẽn. Trong những thời điểm tắc nghẽn cao, ctv có thể cam kết cho nhiều giao dịch tương lai trong một giao dịch duy nhất, tránh cần phải phát sóng nhiều giao dịch trong những thời điểm cao điểm và hoàn tất các giao dịch thực tế sau khi tắc nghẽn giảm nhẹ. Điều này có thể hữu ích đặc biệt trong thời kỳ chạy ngân hàng trao đổi. Ngoài ra, mẫu có thể được sử dụng để triển khai két đựng để bảo vệ chống lại các cuộc tấn công hack. Vì hướng của quỹ được xác định trước, hacker không thể điều hướng utxos bằng kịch bản ctv đến địa chỉ của họ.

ctv có thể cải thiện đáng kể mạng lưới tầng hai. ví dụ, trong mạng lưới lightning, ctv có thể cho phép tạo ra cây hết thời gian và nhà máy kênh bằng cách mở rộng một utxo duy nhất thành một cây ctv, mở nhiều kênh trạng thái chỉ với một giao dịch và một xác nhận. hơn nữa, ctv cũng hỗ trợ giao dịch nguyên tử trong giao thức ark qua atlc.

apo (sighash_anyprevout) bip-118

bip-118 giới thiệu một loại cờ băm chữ ký mới cho tapscript, nhằm mục đích tạo điều kiện cho logic chi tiêu linh hoạt hơn được gọi là sighash_anyprevout. apo và ctv có nhiều điểm tương đồng. khi giải quyết vấn đề chu kỳ giữa scriptpubkeys và txids, phương pháp của apo là loại bỏ thông tin đầu vào liên quan và chỉ ký các đầu ra, cho phép giao dịch gắn động đến các utxo khác nhau.

một cách logic, hoạt động xác minh chữ ký op_checksig (và các biến thể của nó) thực hiện ba chức năng:

1. lắp ráp các phần của giao dịch chi tiêu.
2. băm chúng.
3. xác minh rằng hash đã được ký bởi một khóa đã cho.

cụ thể của chữ ký có rất nhiều linh hoạt, với quyết định về việc ký các trường giao dịch nào được xác định bởi cờ sighash. theo định nghĩa của các mã opcode chữ ký trong bip 342, cờ sighash được chia thành sighash_all, sighash_none, sighash_single và sighash_anyonecanpay. sighash_anyonecanpay kiểm soát các đầu vào, trong khi các cờ khác kiểm soát các đầu ra.

sighash_all là cờ sighash mặc định, ký tất cả các đầu ra; sighash_none không ký đầu ra nào; sighash_single ký một đầu ra cụ thể. sighash_anyonecanpay có thể được thiết lập với ba cờ sighash đầu tiên. nếu sighash_anyonecanpay được thiết lập, chỉ đầu vào cụ thể được ký; nếu không, tất cả các đầu vào phải được ký.

Rõ ràng, những cờ sighash này không loại bỏ hoàn toàn sự ảnh hưởng của đầu vào, ngay cả sighash_anyonecanpay, yêu cầu cam kết với một đầu vào.

do đó, bip 118 đề xuất sighash_anyprevout. chữ ký apo không cần phải cam kết với spent input utxo (được biết đến là prevout) mà chỉ cần ký các đầu ra, tạo ra tính linh hoạt lớn trong việc kiểm soát bitcoin. bằng cách xây dựng trước các giao dịch và tạo chữ ký và khóa công cộng một lần sử dụng tương ứng, tài sản gửi đến địa chỉ khóa công cộng đó phải được tiêu tốn thông qua giao dịch được xây trước, từ đó thực hiện một covenant. tính linh hoạt của apo cũng có thể được sử dụng cho việc sửa chữa giao dịch; nếu một giao dịch bị kẹt trên chuỗi do phí thấp, một giao dịch khác có thể dễ dàng được tạo ra để tăng phí mà không cần chữ ký mới. hơn nữa, đối với ví đa chữ ký, không phụ thuộc vào spent inputs làm cho các hoạt động thuận tiện hơn.

Vì nó loại bỏ chu kỳ giữa ScriptpubKeys và TXID đầu vào, APO có thể thực hiện kiểm tra nội tâm bằng cách thêm dữ liệu đầu ra vào nhân chứng, mặc dù điều này vẫn đòi hỏi phải tiêu thụ thêm không gian nhân chứng.

đối với các giao thức không thuộc chuỗi như mạng sét và kho báu, apo giảm thiểu nhu cầu lưu trạng thái trung gian, giảm thiểu yêu cầu lưu trữ và phức tạp. trường hợp sử dụng trực tiếp nhất của apo là eltoo, giúp đơn giản hóa nhà máy kênh, xây dựng các tháp canh nhẹ và giá rẻ, và cho phép thoát ra một chiều mà không cần để lại trạng thái sai, tăng cường hiệu suất của mạng sét theo nhiều cách. apo cũng có thể được sử dụng để mô phỏng các chức năng ctv, tuy nhiên điều này yêu cầu cá nhân lưu trữ chữ ký và giao dịch được ký trước, điều này tốn kém hơn và hiệu quả kém hơn so với ctv.

Những lời chỉ trích chính của APO tập trung vào nhu cầu về một phiên bản quan trọng mới, không thể được thực hiện bằng cách đơn giản là tương thích ngược. Ngoài ra, loại băm chữ ký mới có thể gây ra rủi ro tiềm ẩn của việc chi tiêu gấp đôi. Sau các cuộc thảo luận cộng đồng rộng rãi, APO đã thêm chữ ký thường xuyên vào cơ chế ký ban đầu để giảm bớt các lo ngại về bảo mật, do đó có được mã BIP-118.

op_vault bip-345

bip-345 đề xuất việc thêm hai mã opcode mới, op_vault và op_vault_recover, khi kết hợp với ctv, thực hiện một hợp đồng đặc biệt cho phép người dùng áp đặt một khoảng thời gian trì hoãn khi tiêu thụ coin cụ thể. Trong khoảng thời gian này, giao dịch đã thực hiện trước đó có thể được "đảo ngược" thông qua một con đường phục hồi.

người dùng có thể tạo một hầm bằng cách tạo một địa chỉ taproot cụ thể phải chứa ít nhất hai script trong mast của nó: một với opcode op_vault để tạo điều kiện thuận lợi cho quá trình rút tiền dự kiến, và một khác với opcode op_vault_recover để đảm bảo rằng tiền có thể được khôi phục bất kỳ lúc nào trước khi hoàn thành quá trình rút tiền.

op_vault làm thế nào để thực hiện rút tiền bị gián đoạn theo thời gian? op_vault đạt được điều này bằng cách thay thế script đã được tiêu thụ của op_vault bằng một script cụ thể, hiệu quả cập nhật một lá duy nhất của mast trong khi để lại các nút lá taproot còn lại không thay đổi. thiết kế này tương tự như tluv, trừ việc op_vault không hỗ trợ cập nhật cho khóa bên trong.

bằng cách giới thiệu một mẫu trong quá trình cập nhật script, có thể giới hạn thanh toán. tham số khoá thời gian được chỉ định bởi op_vault và mẫu opcode ctv hạn chế tập hợp các đầu ra có thể được tiêu tốn qua đường dẫn script này.

bip-345 được thiết kế đặc biệt cho kho bảo mật, tận dụng op_vault và op_vault_recover để cung cấp cho người dùng một phương pháp giám sát an toàn sử dụng một khóa bảo mật cao (như ví giấy hoặc multisig phân tán) như một đường dẫn khôi phục, đồng thời cấu hình một độ trễ nhất định cho các khoản thanh toán thường xuyên. Thiết bị của người dùng liên tục giám sát việc chi tiêu từ kho, và nếu có một giao dịch chuyển tiền bất ngờ xảy ra, người dùng có thể khởi động quá trình khôi phục.

việc triển khai kho thông qua bip-345 đòi hỏi xem xét vấn đề chi phí, đặc biệt là đối với giao dịch khôi phục. Các giải pháp có thể bao gồm cpfp (con trả phí cho cha), neo tạm thời, và cờ ký mới sighash_group.

tluv (tapleafupdateverify)

Chương trình tluv được xây dựng xung quanh Taproot và nhằm mục tiêu giải quyết hiệu quả vấn đề thoát khỏi shared utxos. Nguyên tắc hướng dẫn là khi một Taproot output được chi tiêu, các cập nhật một phần có thể được thực hiện cho khóa nội bộ và mast (tapscript trie) thông qua các biến đổi mật mã và cấu trúc nội bộ của địa chỉ Taproot, như được mô tả bởi tluv script. Điều này cho phép việc triển khai các chức năng covenant.

Khái niệm của tluv scheme là tạo địa chỉ taproot mới dựa trên đầu vào chi tiêu hiện tại bằng cách giới thiệu một opcode mới, tapleaf_update_verify. Điều này có thể được đạt được bằng cách thực hiện một hoặc nhiều hành động sau:

1. cập nhật khóa công khai nội bộ
2. cắt các đường dẫn Merkle
3. xóa tập lệnh đang được thực thi
4. thêm một bước mới ở cuối đường dẫn merkle

cụ thể, tluv chấp nhận ba đầu vào:

1. một tài liệu chỉ định cách cập nhật khóa công khai nội bộ.
2. một bước mới xác định cho đường dẫn merkle.
3. một cái chỉ định liệu có xóa script hiện tại và/hoặc cắt bớt bao nhiêu bước của đường dẫn merkle.

Opcode tluv tính toán scriptpubkey được cập nhật và xác minh rằng đầu ra tương ứng với đầu vào hiện tại đã được tiêu vào scriptpubkey này.

tluv được truyền cảm hứng từ khái niệm coinpool. Ngày nay, các nhóm cộng đồng có thể được tạo ra chỉ bằng cách sử dụng các giao dịch được ký trước, nhưng nếu muốn thực hiện thoát không cần phép, điều đó sẽ yêu cầu tạo ra một số chữ ký tăng theo hình mũ. Tuy nhiên, tluv cho phép thoát không cần phép mà không cần bất kỳ chữ ký trước. Ví dụ, một nhóm đối tác có thể sử dụng taproot để xây dựng một shared utxo, gom tiền của họ lại với nhau. Họ có thể di chuyển tiền nội bộ bằng cách sử dụng khóa taproot hoặc ký chung để khởi xướng thanh toán bên ngoại. Cá nhân có thể thoát khỏi nhóm quỹ chung bất kỳ lúc nào, loại bỏ đường thanh toán của họ, trong khi những người khác vẫn có thể hoàn tất thanh toán thông qua các đường dẫn ban đầu, và việc thoát của cá nhân không tiết lộ thêm thông tin về những người khác bên trong. Chế độ này hiệu quả và riêng tư hơn so với các giao dịch không gom nhóm.

Mã opcode tluv đạt được hạn chế giao dịch bằng cách cập nhật cây taproot gốc, nhưng nó không thực hiện kiểm tra số lượng đầu ra. Do đó, cần một mã opcode mới, in_out_amount. Mã opcode này đẩy hai phần tử vào ngăn xếp: số lượng utxo cho đầu vào này và số lượng cho đầu ra tương ứng, sau đó, những người sử dụng tluv được mong đợi sử dụng các toán tử số học để xác minh rằng số tiền được giữ lại một cách thích hợp trong scriptpubkey đã được cập nhật.

Kiểm tra tổng số lượng đầu ra tăng sự phức tạp vì số lượng trong satoshi cần tới 51 bit để biểu diễn, nhưng scripts chỉ cho phép các phép toán toán học 32 bit. điều này đòi hỏi định nghĩa lại hành vi opcode để nâng cấp các toán tử trong scripts hoặc sử dụng sighash_group để thay thế in_out_amount.

tluv có tiềm năng như một giải pháp cho các hồ bơi tài trợ tầng 2 phi tập trung, mặc dù tính đáng tin cậy trong việc điều chỉnh cây taproot vẫn cần xác nhận.

matt

matt (merkleize tất cả các thứ) nhằm đạt được ba mục tiêu: merkleize trạng thái, merkleize tập lệnh và merkleize thực thi, từ đó cho phép hợp đồng thông minh toàn cầu.

1. Merkleizing trạng thái: điều này bao gồm xây dựng một Merkle Trie, trong đó mỗi nút lá đại diện cho băm của một trạng thái, với gốc Merkle thể hiện trạng thái tổng thể của hợp đồng.
2. merkleizing the script: điều này ám chỉ việc tạo ra một cây merkle sử dụng tapscript, trong đó mỗi nút lá đại diện cho một con đường chuyển trạng thái có thể.
3. thực thi merkleizing: việc thực thi được merkleized thông qua cam kết mật mã và cơ chế thách thức gian lận. Đối với bất kỳ chức năng tính toán nào, các thành viên có thể tính toán ngoại tuyến và sau đó đăng tải cam kết, f(x)=y. Nếu các thành viên khác tìm thấy kết quả sai, f(x)=z, họ có thể khởi động thách thức. Trọng tài được thực hiện thông qua tìm kiếm nhị phân, tương tự như nguyên tắc của optimistic rollup.

merkleizing thực thi

Để thực hiện matt, ngôn ngữ kịch bản Bitcoin cần có các chức năng sau:

1. buộc một đầu ra có một script cụ thể (và số lượng tương ứng)
2. đính kèm một mảnh dữ liệu vào một đầu ra
3. đọc dữ liệu từ đầu vào hiện tại (hoặc một đầu vào khác)

Điểm thứ hai rất quan trọng: dữ liệu động có nghĩa là trạng thái có thể được tính toán thông qua dữ liệu đầu vào được cung cấp bởi người tiêu dùng, vì điều này cho phép mô phỏng một máy trạng thái, có khả năng xác định trạng thái tiếp theo và dữ liệu bổ sung. Hệ thống Matt triển khai điều này thông qua mã opcode op_checkcontractverify (op_ccv), một sự kết hợp của các opcode op_checkoutputcontractverify và op_checkinputcontractverify đã được đề xuất trước đó, sử dụng tham số cờ bổ sung để chỉ định mục tiêu của hoạt động.

Kiểm soát số tiền đầu ra: Phương pháp đơn giản nhất là kiểm tra trực tiếp; tuy nhiên, số tiền đầu ra là số 64 bit, đòi hỏi toán học 64 bit, đây là một phức tạp đáng kể trong kịch bản Bitcoin. Op_ccv áp dụng phương pháp kiểm tra trì hoãn, giống như op_vault, trong đó tất cả các đầu vào đến cùng một đầu ra với ccv sẽ được cộng tổng số tiền gửi, đóng vai trò như mức giới hạn tối thiểu cho số tiền đó của đầu ra đó. Sự trì hoãn này là vì kiểm tra này xảy ra trong quá trình giao dịch chứ không phải trong quá trình đánh giá tập lệnh của các đầu vào.

Với tính phổ biến của chứng minh gian lận, một số biến thể của hợp đồng Matt nên có thể thực hiện tất cả các loại hợp đồng thông minh hoặc các công trình tầng 2, mặc dù các yêu cầu bổ sung (như khóa vốn và độ trễ thời gian thách thức) cần được đánh giá chính xác; nghiên cứu thêm cần được thực hiện để đánh giá các ứng dụng nào là chấp nhận được cho các giao dịch. Ví dụ, sử dụng cam kết mật mã và cơ chế thách thức gian lận để mô phỏng chức năng op_zk_verify, đạt được việc cuộn trên Bitcoin không cần tin tưởng.

Trong thực tế, những việc đã xảy ra. Johan Torås Halseth đã sử dụng opcode op_checkcontractverify từ đề xuất soft fork của Matt để thực hiệnelftrace, cho phép bất kỳ chương trình nào hỗ trợ biên dịch risc-v được xác minh trên chuỗi khối bitcoin, cho phép một bên trong giao thức hợp đồng truy cập vào quỹ thông qua xác minh hợp đồng, từ đó kết nối xác minh cố định của bitcoin.

csfs (op_checksigfromstack)

từ sự giới thiệu về mã lệnh apo, chúng ta đã biết rằng op_checksig (và các hoạt động liên quan của nó) chịu trách nhiệm lắp ráp các giao dịch, băm và xác minh chữ ký. tuy nhiên, tin nhắn được xác minh bởi những hoạt động này được suy ra từ việc tuần tự hóa của giao dịch bằng cách sử dụng mã lệnh, và nó không cho phép chỉ định bất kỳ tin nhắn nào khác. một cách đơn giản, op_checksig (và các hoạt động liên quan của nó) phục vụ để xác minh thông qua cơ chế chữ ký xem liệu utxo đang được tiêu tốn như một đầu vào giao dịch đã được ủy quyền để được tiêu tốn bởi người giữ chữ ký, từ đó bảo vệ an ninh của Bitcoin.

Như tên gọi của nó, csfs kiểm tra chữ ký từ ngăn xếp. opcode csfs nhận ba tham số từ ngăn xếp: một chữ ký, một thông điệp và một khóa công khai, và xác minh tính hợp lệ của chữ ký. Điều này có nghĩa là mọi người có thể chuyển bất kỳ thông điệp nào đến ngăn xếp thông qua chứng nhận và xác minh nó thông qua csfs, cho phép một số đổi mới trên Bitcoin.

Tính linh hoạt của CSF cho phép nó thực hiện các cơ chế như chữ ký thanh toán, ủy quyền, hợp đồng oracle, trái phiếu bảo vệ chi tiêu gấp đôi và quan trọng hơn là xem xét nội tâm giao dịch. Nguyên tắc sử dụng CSF để xem xét nội tâm giao dịch khá đơn giản: nếu nội dung giao dịch được op_checksig sử dụng được đẩy vào ngăn xếp thông qua nhân chứng, và cùng một khóa công khai và chữ ký được sử dụng để xác minh cả bằng op_csfs và op_checksig và nếu cả hai xác minh đều vượt qua thành công, thì nội dung tin nhắn tùy ý được chuyển đến op_csfs giống như giao dịch chi tiêu được nối tiếp hóa (và các dữ liệu khác) được sử dụng ngầm bởi op_ kiểm tra. Sau đó, chúng tôi thu thập dữ liệu giao dịch đã được xác minh trên ngăn xếp, có thể được sử dụng để áp dụng các hạn chế đối với các giao dịch chi tiêu với các opcode khác.

csfs thường xuất hiện cùng với op_cat vì op_cat có thể kết nối các lĩnh vực khác nhau của giao dịch để hoàn thành việc chuỗi hóa, cho phép lựa chọn chính xác hơn các lĩnh vực giao dịch cần thiết cho kiểm tra trực quan. Mà không có op_cat, script không thể tính lại hash từ dữ liệu có thể kiểm tra riêng lẻ, vì vậy thực sự nó chỉ có thể kiểm tra xem hash có tương ứng với một giá trị cụ thể hay không, có nghĩa là tiền xu chỉ có thể được chi tiêu thông qua một giao dịch cụ thể duy nhất.

csfs có thể triển khai các mã opcode như cltv, csv, ctv, apo, vv., làm nó trở thành một mã opcode tự động đa năng. Do đó, nó cũng hỗ trợ các giải pháp mở rộng cho lớp2 của Bitcoin. Nhược điểm là nó yêu cầu thêm một bản sao hoàn chỉnh của giao dịch đã ký trên ngăn xếp, điều này có thể làm tăng kích thước của các giao dịch được thiết kế để tham khảo sử dụng csfs. Ngược lại, các mã opcode tham khảo đơn mục đích như cltv và csv có chi phí chênh lệch tối thiểu, nhưng việc thêm mỗi mã opcode tham khảo đặc biệt mới đều yêu cầu thay đổi đồng thuận.

txhash (op_txhash)

op_txhash là một mã opcode kích hoạt khám phá đơn giản cho phép người điều hành chọn và đẩy mã băm của một trường cụ thể lên ngăn xếp. Cụ thể, op_txhash đẩy một cờ txhash từ ngăn xếp và tính toán một txhash (đã gắn thẻ) dựa trên cờ đó, sau đó đẩy mã băm kết quả trở lại ngăn xếp.

do sự tương đồng giữa txhash và ctv, một lượng lớn thảo luận đã nảy sinh trong cộng đồng về hai cái.

Txhash có thể được coi là một bản nâng cấp toàn cầu của ctv, cung cấp một mẫu giao dịch tiên tiến hơn cho phép người dùng chỉ định một phần của giao dịch chi tiêu một cách rõ ràng, giải quyết nhiều vấn đề liên quan đến phí giao dịch. Không giống như các opcode hợp đồng khác, txhash không yêu cầu một bản sao của dữ liệu cần thiết trong chứng nhận, giảm yêu cầu lưu trữ; không giống như ctv, txhash không tương thích với nop và chỉ có thể được thực hiện trong tapscript; sự kết hợp của txhash và csfs có thể phục vụ như một phương thức thay thế cho ctv và apo.

Về mặt xây dựng các điều khoản, txhash có lợi hơn cho việc tạo ra 'các điều khoản cộng hưởng', trong đó tất cả các phần dữ liệu giao dịch mà bạn muốn sửa đổi được đẩy vào ngăn xếp, được băm cùng nhau và mã băm kết quả được xác minh để khớp với giá trị cố định; ctv phù hợp hơn để tạo ra 'các điều khoản trừ đi', trong đó tất cả các phần dữ liệu giao dịch mà bạn muốn giữ miễn phí được đẩy vào ngăn xếp. Sau đó, sử dụng một opcode sha256 lăn, quá trình băm bắt đầu từ một trạng thái trung gian cố định mà cam kết với một tiền tố của dữ liệu băm giao dịch. Các phần miễn phí được băm vào trạng thái trung gian này.

Trường txfieldselector được xác định trong đặc tả txhash dự kiến sẽ được mở rộng sang các opcode khác, chẳng hạn như op_tx.

Bản thảo liên quan đến txhash hiện đang ở trạng thái nháp trên github và chưa được gán số.

op_cat

op_cat là một mã lệnh được bao phủ bởi bí ẩn, ban đầu bị bỏ rơi bởi satoshi nakamoto do lo ngại về an ninh, nó đã gây ra cuộc tranh luận sôi nổi giữa các nhà phát triển bitcoin lõi và thậm chí còn kích thích văn hóa meme trên internet. Cuối cùng, op_cat đã được chấp thuận theo bip-347 và đã được gọi là đề xuất bip có khả năng được thông qua nhiều nhất trong thời gian gần đây.

Trong thực tế, hành vi của op_cat khá đơn giản: nó nối hai phần tử từ ngăn xếp. Làm thế nào nó kích hoạt chức năng covenant?

Thật vậy, khả năng nối hai yếu tố tương ứng với cấu trúc dữ liệu mật mã mạnh mẽ: Merkle Trie. Để xây dựng Merkle Trie, chỉ cần các hoạt động ghép nối và băm và các hàm băm có sẵn trong các tập lệnh Bitcoin. Do đó, với op_cat, về mặt lý thuyết chúng ta có thể xác minh bằng chứng Merkle trong các tập lệnh Bitcoin, đây là một trong những phương pháp xác minh nhẹ phổ biến nhất trong công nghệ blockchain.

như đã đề cập trước đó, csfs, với sự trợ giúp của op_cat, có thể triển khai một kế hoạch ước nguyên tổng quát. Trên thực tế, nếu thiếu csfs, việc tận dụng cấu trúc của chữ ký schnorr, op_cat có thể tự thực hiện việc quan sát giao dịch.

trong chữ ký Schnorr, thông điệp cần được ký được tạo thành từ các trường sau:

Những trường này chứa các thành phần chính của một giao dịch. Bằng cách đặt chúng trong scriptpubkey hoặc witness và sử dụng op_cat kết hợp với op_sha256, chúng ta có thể xây dựng một chữ ký schnorr và xác minh nó bằng cách sử dụng op_checksig. Nếu việc xác minh thành công, ngăn xếp sẽ giữ lại dữ liệu giao dịch đã được xác minh, đạt được việc kiểm tra giao dịch. Điều này cho phép chúng ta trích xuất và “kiểm tra” các phần khác nhau của giao dịch, chẳng hạn như đầu vào, đầu ra, địa chỉ mục tiêu hoặc số lượng Bitcoin liên quan.

Đối với các nguyên tắc mật mã cụ thể, bạn có thể tham khảo bài viết của Andrew Poelstra về 'Cat and Schnorr Tricks'.

Tóm lại, tính linh hoạt của op_cat cho phép nó mô phỏng gần như bất kỳ opcode của đồng đoàn nào. Một loạt opcode của đồng đoàn phụ thuộc vào chức năng của op_cat, điều này đáng kể nâng cao vị trí của nó trong danh sách hợp nhất. Lý thuyết, chỉ dựa vào op_cat và các opcode Bitcoin hiện có, chúng tôi hy vọng xây dựng được một btc zk rollup tối thiểu đáng tin cậy. Starknet, chakra và những đối tác hệ sinh thái khác đang tích cực đẩy mạnh để điều này xảy ra.

kết luận

khi chúng tôi khám phá các chiến lược đa dạng để mở rộng Bitcoin và nâng cao tính khả dụng của nó, trở nên rõ ràng rằng con đường phía trước bao gồm sự kết hợp của cải tiến gốc, tính toán ngoại chuỗi và khả năng viết kịch bản tinh vi.

không có một lớp cơ sở linh hoạt, không thể xây dựng một lớp thứ hai linh hoạt hơn được.

Việc mở rộng tính toán ngoại chuỗi là tương lai, nhưng tính khả chuyển của Bitcoin cần phải vượt qua để hỗ trợ tốt hơn tính mở rộng này và trở thành một loại tiền tệ toàn cầu thực sự.

tuy nhiên, bản chất của việc tính toán trên Bitcoin hoàn toàn khác so với Ethereum. Bitcoin chỉ hỗ trợ "xác minh" dưới dạng tính toán và không thể thực hiện tính toán tổng quát, trong khi Ethereum được tạo ra để tính toán, với việc xác minh là kết quả của tính toán. Sự khác biệt này rõ ràng từ một điểm: Ethereum tính phí gas cho giao dịch không thực thi thành công, trong khi Bitcoin không.

covenant đại diện cho một hình thức hợp đồng thông minh dựa trên việc xác minh thay vì tính toán. trừ vài nguyên tắc cốt lõi của satoshi, có vẻ như mọi người đều coi covenant là một lựa chọn tốt để cải thiện bitcoin. tuy nhiên, cộng đồng vẫn tiếp tục tranh luận dữ dội về phương pháp nào nên được sử dụng để triển khai covenant.

apo, op_vault và tluv hướng đến các ứng dụng trực tiếp, và việc chọn chúng có thể đạt được các ứng dụng cụ thể một cách rẻ hơn và hiệu quả hơn. Người hâm mộ mạng lightning network sẽ ưa thích apo để đạt được đối xứng ln; những người muốn triển khai một hầm đạn sẽ được phục vụ tốt nhất bởi op_vault; để xây dựng coinpool, tluv cung cấp nhiều quyền riêng tư và hiệu quả hơn. op_cat và txhash linh hoạt hơn, với khả năng có ít lỗ hổng bảo mật hơn, và có thể triển khai nhiều trường hợp sử dụng khi kết hợp với các opcode khác, có lẽ với sự phức tạp của kịch bản. ctv và csfs đã điều chỉnh xử lý blockchain, với ctv triển khai đầu ra bị trễ và csfs triển khai chữ ký bị trễ. matt nổi bật với chiến lược thực thi lạc quan và chứng minh gian lận, sử dụng cấu trúc của merkle trie để triển khai hợp đồng thông minh phổ quát, mặc dù vẫn cần các opcode mới cho khả năng tự xem xét.

chúng tôi thấy rằng cộng đồng Bitcoin đang tích cực thảo luận về khả năng thu được covenants thông qua một soft fork. Starknet đã chính thức thông báo sự gia nhập vào hệ sinh thái Bitcoin, kế hoạch thực hiện thanh toán trên mạng Bitcoin trong vòng sáu tháng sau khi sáp nhập của op_cat. Chakra sẽ tiếp tục theo dõi các diễn biến mới nhất trong hệ sinh thái Bitcoin, thúc đẩy việc sáp nhập của soft fork op_cat, và tận dụng tính linh hoạt được mang lại bởi covenants để xây dựng một lớp thanh toán Bitcoin an toàn và hiệu quả hơn.

disclaimer:

1. bài viết này được in lại từ [Gương]. tất cả bản quyền thuộc về tác giả gốc [ chakra]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với Gate họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. miễn trách nhiệm: quan điểm và ý kiến được diễn đạt trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm học tập của Gate.io. Trừ khi có ghi chú, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là không được phép.