Giải thích chi tiết về các giải pháp lập trình Bitcoin Nội tâm và Giao ước

Tác giả: Chakra; Trình biên dịch: 0xjs@金财经

Bài viết này là Phần III của loạt bài viết về khả năng mở rộng Bitcoin do Chakra xuất bản.

Đối với phần đầu tiên, vui lòng tham khảo bài viết trước của Jinse Finance "Đánh giá về Bitcoin kế hoạch mở rộng riêng: SegWit và Taproot",

Đối với phần thứ hai, vui lòng tham khảo bài viết trước của Jinse Finance "Khả năng mở rộng Bitcoin: Phân tích các giải pháp lớp 2 và các dự án liên quan".

Phần thứ ba là bài viết này, như sau:

Tổng quan

So với các chuỗi khối hoàn chỉnh Turing như Ethereum, các tập lệnh Bitcoin được coi là có tính hạn chế Cực kỳ mạnh mẽ, nó chỉ có thể thực hiện các thao tác cơ bản và thậm chí không hỗ trợ phép nhân và chia. Quan trọng hơn, bản thân dữ liệu của blockchain gần như không thể truy cập được bằng các tập lệnh, dẫn đến thiếu tính linh hoạt và khả năng lập trình nghiêm trọng. Do đó, đã có những nỗ lực để tạo ra các tập lệnh Bitcoin mang tính nội tâm.

Việc xem xét nội tâm đề cập đến khả năng của các tập lệnh Bitcoin trong việc kiểm tra và hạn chế dữ liệu giao dịch. Điều này cho phép các tập lệnh kiểm soát việc sử dụng tiền dựa trên các chi tiết giao dịch cụ thể, cho phép thực hiện các chức năng phức tạp hơn. Hiện tại, hầu hết các mã Bitcoin đều đẩy dữ liệu do người dùng cung cấp vào ngăn xếp hoặc thao tác dữ liệu hiện có trên ngăn xếp. Tuy nhiên, opcode xem xét nội tâm có thể đẩy dữ liệu của giao dịch hiện tại (chẳng hạn như dấu thời gian, số tiền, txid, v.v.) vào ngăn xếp, cho phép kiểm soát chi tiết hơn đối với chi tiêu UTXO.

Tính đến thời điểm hiện tại, chỉ có ba mã hoạt động chính hỗ trợ tính năng xem xét nội tâm trong Tập lệnh Bitcoin: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY và CHECKSIG, cũng như các biến thể của chúng là CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG và CHECKMULTISIGVERIFY.

Giao ước (còn được dịch là "hạn chế"), nói một cách đơn giản, đề cập đến các hạn chế về phương thức chuyển tiền, cho phép người dùng chỉ định phương thức phân phối UTXO. Nhiều hợp đồng được thực hiện thông qua các mã hoạt động nội quan và cuộc thảo luận về nội quan hiện đã được chuyển sang chủ đề Hợp đồng Bitcoin Optech.

Bitcoin hiện có hai hợp đồng là CSV (CheckSequenceVerify) và CLTV (CheckLockTimeVerify). Cả hai hợp đồng đều là hợp đồng dựa trên thời gian và là nền tảng của nhiều giải pháp mở rộng (chẳng hạn như Lightning Network). Điều này minh họa rằng giải pháp mở rộng quy mô của Bitcoin phụ thuộc rất nhiều vào việc xem xét nội tâm và hợp đồng.

Làm cách nào để thêm điều kiện vào việc chuyển mã thông báo? Trong thế giới tiền điện tử, cách phổ biến nhất mà chúng tôi thực hiện là thông qua các lời hứa, thường là thông qua hàm băm. Để chứng minh rằng các yêu cầu chuyển giao được đáp ứng, cơ chế chữ ký cũng được yêu cầu để xác minh. Vì vậy, có nhiều điều chỉnh về hàm băm và chữ ký trong hợp đồng.

Dưới đây, chúng tôi mô tả đề xuất opcode Covenant đượ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 trong BIP-119, đã thu hút được sự chú ý rộng rãi từ cộng đồng. CTV cho phép các tập lệnh đầu ra chỉ định các mẫu để giải ngân tiền trong các giao dịch, bao gồm nVersion, nLockTime, hàm 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 và các trường khác. Các hạn chế mẫu này được triển khai thông qua các lời hứa băm và khi chi tiêu tiền, tập lệnh sẽ kiểm tra xem hàm băm của trường được chỉ định trong giao dịch chi tiêu có khớp với hàm băm trong tập lệnh đầu vào hay không. Điều này hạn chế một cách hiệu quả thời gian, phương thức và số lượng giao dịch trong tương lai đối với UTXO đó.

Điều đáng chú ý rằng TXID đầu vào được loại trừ khỏi hàm băm này. Việc loại trừ này là cần thiết vì trong các giao dịch truyền thống và SegWit, khi sử dụng loại chữ ký SIGHASH_ALL mặc định, TXID phụ thuộc vào giá trị trong scriptPubKey. Việc bao gồm TXID gây ra sự phụ thuộc vòng tròn trong lời hứa băm, khiến cho việc xây dựng không thể thực hiện được.

Phương pháp xem xét nội tâm của CTV là trực tiếp lấy thông tin giao dịch được chỉ định cho hoạt động băm và sau đó so sánh nó với cam kết trên ngăn xếp. Phương pháp xem xét nội tâm này có yêu cầu thấp hơn về không gian chuỗi nhưng thiếu tính linh hoạt nhất định.

Nền tảng của các giải pháp lớp thứ hai của Bitcoin (chẳng hạn như Lightning Network) là các giao dịch được ký trướ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 tán chúng cho đến khi đáp ứng một số điều kiện nhất định. Về bản chất, CTV thực hiện một hình thức ký trước hạn chế hơn, xuất bản các cam kết đã ký trước trên chuỗi và giới hạn chúng ở các mẫu được xác định trước.

CTV ban đầu được đề xuất để giảm bớt tình trạng tắc nghẽn của Bitcoin, còn có thể được gọi là kiểm soát tắc nghẽn. Khi tình trạng tắc nghẽn nghiêm trọng, CTV có thể cam kết thực hiện nhiều giao dịch trong tương lai trong một giao dịch, tránh phát sóng nhiều giao dịch trong giờ cao điểm và hoàn thành giao dịch thực tế khi tình trạng tắc nghẽn giảm bớt. Điều này có thể đặc biệt hữu ích trong quá trình trao đổi. Ngoài ra, mẫu có thể được sử dụng để triển khai Vault nhằm bảo vệ khỏi các cuộc tấn công của hacker. Vì dòng tiền được xác định trước nên tin tặc không thể sử dụng tập lệnh CTV để trỏ UTXO đến địa chỉ của chính chúng.

CTV có thể tăng cường đáng kể mạng Lớp 2. Ví dụ: trong Lightning Network, CTV có thể tạo cây thời gian chờ và nhà máy sản xuất kênh bằng cách mở rộng một UTXO duy nhất thành cây CTV, cho phép mở nhiều kênh trạng thái chỉ bằng một giao dịch và một xác nhận. Ngoài ra, CTV hỗ trợ các giao dịch nguyên tử trong giao thức Ark thông qua ATLC.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 giới thiệu cờ băm chữ ký mới cho tapscript được thiết kế để hỗ trợ 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. Cách tiếp cận của APO để giải quyết vấn đề vòng lặp giữa scriptPubKeys và TXID là loại trừ thông tin đầu vào có liên quan và chỉ ký đầu ra, cho phép các giao dịch được liên kết động với các UTXO khác nhau.

Về mặt 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. Tập hợp các phần khác nhau của giao dịch chi tiêu.

2. Băm chúng.

3. Xác minh rằng hàm băm đã được ký bởi khóa đã cho.

Các chi tiết cụ thể của chữ ký rất linh hoạt và cờ SIGHASH xác định trường nào của giao dịch được ký. Theo định nghĩa về 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 đầu vào, trong khi những cái khác kiểm soát đầu ra.

SIGHASH_ALL là cờ SIGHASH mặc định, ký tất cả đầu ra; SIGHASH_NONE không ký bất kỳ đầu ra cụ thể nào; SIGHASH_ANYONECANPAY có thể được đặt cùng với ba cờ SIGHASH đầu tiên. Nếu SIGHASH_ANYONECANPAY được đặt thì chỉ đầu vào được chỉ định mới được ký; nếu không, tất cả đầu vào phải được ký.

Rõ ràng, các cờ SIGHASH này không loại bỏ tác động của đầu vào, ngay cả SIGHASH_ANYONECANPAY, yêu cầu phải cam kết với đầu vào.

Do đó, BIP 118 đã đề xuất SIGHASH_ANYPREVOUT. Chữ ký APO không yêu cầu cam kết UTXO đầu vào đã chi tiêu (được gọi là PREVOUT) mà chỉ yêu cầu đầu ra, mang lại sự linh hoạt cao hơn cho việc kiểm soát Bitcoin. Bằng cách xây dựng trước giao dịch và tạo chữ ký một lần và khóa chung tương ứng, tài sản được gửi đến địa chỉ khóa công khai đó phải được sử dụng thông qua giao dịch được xây dựng trước, từ đó hoàn thành hợp đồng. Tính linh hoạt của APO cũng có thể được sử dụng để sửa chữa giao dịch; nếu một giao dịch bị kẹt trên chuỗi vì phí quá thấp, một giao dịch khác có thể dễ dàng được tạo để tăng phí mà không cần chữ ký mới. Ngoài ra, đối với ví đa chữ ký, việc không phụ thuộc vào đầu vào đã chi tiêu giúp thao tác thuận tiện hơn.

Vì vòng lặp giữa scriptPubKeys và TXID đầu vào bị loại bỏ nên APO có thể thực hiện việc xem xét nội tâm bằng cách thêm dữ liệu đầu ra vào Witness, mặc dù điều này vẫn yêu cầu tiêu thụ thêm dung lượng Witness.

Đối với các giao thức ngoài chuỗi như Lightning Network và Vaults, APO giảm nhu cầu lưu trạng thái trung gian, giảm đáng kể yêu cầu lưu trữ và độ phức tạp. Trường hợp sử dụng ngay lập tức nhất cho APO là Eltoo, giúp nâng cao hiệu suất của Lightning Network theo nhiều cách bằng cách đơn giản hóa các nhà máy kênh, xây dựng các tháp canh nhẹ và rẻ, đồng thời cho phép thoát ra đơn phương mà không để lại trạng thái lỗi. APO cũng có thể được sử dụng để mô phỏng chức năng của CTV, mặc dù nó yêu cầu các cá nhân lưu trữ các giao dịch đã ký và ký trước, điều này đắt hơn và kém hiệu quả hơn CTV.

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

OP_VAULT BIP-345

BIP-345 đề xuất bổ sung hai mã opcode mới, OP_VAULT và OP_VAULT_RECOVER, khi được sử dụng cùng với CTV, thực hiện các hợp đồng chuyên biệt cho phép người dùng buộc Trì hoãn việc sử dụng một loại tiền tệ cụ thể. Trong thời gian trì hoãn này, các giao dịch đã thực hiện trước đó có thể được "hoàn tác" thông qua đường dẫn khôi phục.

Người dùng có thể tạo Vault bằng cách tạo một địa chỉ Taproot cụ thể, địa chỉ này phải chứa ít nhất hai tập lệnh trong MAST của nó: một tập lệnh có mã op_VAULT để hỗ trợ quá trình rút tiền dự định và một tập lệnh khác có mã op_VAULT_RECOVER để đảm bảo rằng mã thông báo có thể được khôi phục bất kỳ lúc nào trước khi quá trình rút tiền hoàn tất.

Cách triển khai OP_VAULT Rút tiền khóa thời gian bị gián đoạn? OP_VAULT thực hiện điều này bằng cách thay thế tập lệnh OP_VAULT đã sử dụng bằng tập lệnh được chỉ định, cập nhật hiệu quả một lá của MAST trong khi không thay đổi các nút lá Taproot còn lại. Thiết kế này tương tự như TLUV, ngoại trừ OP_VAULT không hỗ trợ cập nhật các khóa bên trong.

Có thể hạn chế thanh toán bằng cách giới thiệu các mẫu trong quá trình cập nhật tập lệnh. Tham số khóa thời gian được chỉ định bởi OP_VAULT và mẫu cho mã opcode CTV giới hạn tập hợp đầu ra có thể được sử dụng thông qua đường dẫn tập lệnh này.

BIP-345 được thiết kế đặc biệt cho Vault, tận dụng OP_VAULT và OP_VAULT_RECOVER để cung cấp cho người dùng phương thức ký quỹ an toàn, sử dụng các khóa có độ bảo mật cao (chẳng hạn như ví giấy hoặc chữ ký đa phân tán) làm đường dẫn khôi phục, đồng thời cung cấp Thanh toán thông thường được định cấu hình với độ trễ nhất định. Thiết bị của người dùng liên tục theo dõi chi tiêu của kho tiền và nếu xảy ra chuyển khoản bất ngờ, người dùng có thể bắt đầu khôi phục.

Việc triển khai Vault thông qua BIP-345 đi kèm với việc cân nhắc về chi phí, đặc biệt là đối với việc khôi phục các giao dịch. Các giải pháp khả thi bao gồm CPFP (con trả tiền cho cha mẹ), neo tạm thời và cờ băm có chữ ký SIGHASH_GROUP mới.

TLUV (TapleafUpdateVerify)

Giải pháp TLUV được xây dựng xung quanh Taproot và được thiết kế để giải quyết hiệu quả vấn đề thoát UTXO chung. Nguyên tắc là khi sử dụng đầu ra Taproot, các khóa bên trong và MAST (tapscript trie) có thể được cập nhật một phần thông qua các phép biến đổi mật mã và cấu trúc bên trong của địa chỉ Taproot, như được mô tả trong tập lệnh TLUV. Điều này làm cho việc thực hiện chức năng Giao ước có thể thực hiện được.

Ý tưởng của sơ đồ TLUV là tạo một đị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ã opcode mới TAPLEAF_UPDATE_VERIFY. Điều này có thể được thực hiện bằng cách thực hiện một hoặc nhiều hành động sau:

• Cập nhật khóa công khai nội bộ

< li >

Cắt đường dẫn Merkle

• Xóa tập lệnh hiện đang thực thi

• Thêm một bước mới vào cuối con đường Merkle

  p>

Cụ thể, TLUV Chấp nhận ba đầu vào:

• Chỉ định cách cập nhật khóa chung nội bộ.

• Một cách để chỉ định một bước mới cho đường dẫn Merkle.

• Chỉ định xem có xóa tập lệnh hiện tại hay không và/hoặc số bước cần cắt bớt trong đường dẫn Merkle.

Mã hoạt động TLUV tính toán scriptPubKey được cập nhật và xác minh xem đầu ra tương ứng với đầu vào hiện tại có được sử dụng cho scriptPubKey này hay không.

TLUV được lấy cảm hứng từ khái niệm CoinPool. Ngày nay, các nhóm liên kết có thể được tạo chỉ bằng các giao dịch được ký trước, nhưng nếu muốn thoát ra không được phép thì cần phải tạo số lượng chữ ký lớn hơn theo cấp số nhân. Mặt khác, TLUV cho phép thoát không được phép mà không cần ký trước. Ví dụ: một nhóm đối tác có thể gộp tiền của họ lại với nhau bằng Taproot để xây dựng các UTXO dùng chung. Họ có thể sử dụng khóa Taproot để chuyển tiền nội bộ hoặc đồng ký tên để bắt đầu thanh toán bên ngoài. Các cá nhân có thể rút khỏi nhóm quỹ chung bất kỳ lúc nào, xóa đường dẫn 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 qua đường dẫn ban đầu và việc rút tiền của cá nhân đó không tiết lộ thông tin khác về những người khác bên trong. Mô hình này hiệu quả và riêng tư hơn các giao dịch không gộp.

Mã hoạt động TLUV thực hiện các hạn chế chi tiêu một phần bằng cách cập nhật Taproot Trie ban đầu, nhưng nó không thực hiện việc xem xét nội bộ số tiền đầu ra. Do đó, một opcode mới IN_OUT_AMOUNT cũng được yêu cầu. Mã hoạt động này đẩy hai mục vào ngăn xếp: lượng UTXO của đầu vào này và lượng đầu ra tương ứng, sau đó người sử dụng TLUV cần sử dụng các toán tử toán học để xác minh rằng số tiền được giữ lại đúng cách trong scriptPubKey đã cập nhật.

Việc xem xét nội bộ số lượng đầu ra sẽ làm tăng thêm độ phức tạp, vì số lượng satoshi yêu cầu tối đa 51 bit để thể hiện, nhưng tập lệnh chỉ cho phép các phép toán 32 bit. Điều này yêu cầu xác định lại hành vi opcode để nâng cấp toán tử trong tập lệnh hoặc thay thế IN_OUT_AMOUNT bằng SIGHASH_GROUP.

TLUV có tiềm năng trở thành một giải pháp cho các nhóm lớp 2 phi tập trung, nhưng độ tin cậy của nó trong việc điều chỉnh Taproot Trie vẫn cần được xác nhận.

MATT

MATT (Merkleize All The Things) nhằm đạt được ba mục tiêu: Hợp nhất trạng thái, Hợp nhất tập lệnh và Hợp nhất việc thực hiện, từ đó hiện thực hóa các hợp đồng thông minh phổ quát.

• Hợp nhất trạng thái: Điều này liên quan đến việc xây dựng Merkle Trie, trong đó mỗi nút lá đại diện cho hàm băm của giá trị trạng thái, trong khi Merkle Root phản ánh tình trạng chung của hợp đồng.

• Hợp nhất tập lệnh: Điều này đề cập đến việc sử dụng Tapscript để tạo thành MAST, trong đó mỗi nút lá biểu thị một đường dẫn chuyển đổi trạng thái có thể có.

• Hợp nhất việc thực hiện: Hợp nhất việc thực thi 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, người tham gia có thể tính toán nó ngoài chuỗi và sau đó đưa ra cam kết f(x)=y. Nếu những người tham gia khác phát hiện ra kết quả không chính xác f(x)=z, họ có thể bắt đầu thử thách. Việc phân xử được thực hiện thông qua tìm kiếm nhị phân, tương tự như nguyên tắc Tổng hợp lạc quan.

Thực thi được Merkel hóa

Để triển khai MATT, ngôn ngữ tập lệnh Bitcoin cần có các chức năng sau:

• Bắt buộc đầu ra phải có một tập lệnh cụ thể (và số của nó)

• Nối thêm một phần dữ liệu đến Đầu ra

• Đọc dữ liệu từ đầu vào hiện tại (hoặc đầu vào khác)

Điểm thứ hai là Quan trọng: Dữ liệu động có nghĩa là trạng thái có thể được tính toán từ dữ liệu đầu vào do người tiêu dùng cung cấp, vì điều này cho phép mô phỏng máy trạng thái, có thể xác định trạng thái tiếp theo và dữ liệu bổ sung. Lược đồ MATT đạt được điều này thông qua mã op_CHECKCONTRACTVERIFY (OP_CCV), là sự hợp nhất của các mã 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 lượng đầu ra: Phương pháp đơn giản nhất là xem xét trực tiếp; tuy nhiên, lượng đầu ra là một số 64 bit và yêu cầu số học 64 bit, điều này gây ra rất nhiều sự phức tạp trong các tập lệnh Bitcoin. OP_CCV sử dụng phương pháp kiểm tra độ trễ như OP_VAULT, trong đó lượng đầu vào của tất cả đầu vào cho cùng một đầu ra trong CCV được cộng lại với nhau dưới dạng giới hạn dưới cho lượng đầu ra đó. Sự chậm trễ là do việc 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á đầu vào của tập lệnh.

Với sự phổ biến của các bằng chứng gian lận, một số biến thể của hợp đồng MATT sẽ có thể triển khai tất cả các loại hợp đồng thông minh hoặc cấu trúc lớp 2, mặc dù các yêu cầu bổ sung (chẳng hạn như khóa quỹ và trì hoãn giai đoạn thử thách) cần phải được đáp ứng. được đánh giá chính xác; Cần nghiên cứu sâu hơn để đánh giá ứng dụng nào có thể chấp nhận 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 nhằm triển khai các bản Tổng hợp không đáng tin cậy trên Bitcoin.

Trong thực tế, điều này đã xảy ra rồi. Johan Torås Halseth đã triển khai elftrace bằng cách sử dụng mã op_CHECKCONTRACTVERIFY trong đề xuất fork mềm MATT, cho phép bất kỳ chương trình nào được biên soạn với sự hỗ trợ của RISC-V đều được xác minh trên chuỗi khối Bitcoin, cho phép một bên trong thỏa thuận hợp đồng vượt qua Xác minh hợp đồng để truy cập vào quỹ, bắc cầu xác minh gốc Bitcoin.

CSFS (OP_CHECKSIGFROMSTACK)

Từ việc giới thiệu mã hoạt động APO, chúng tôi biết rằng OP_CHECKSIG (và các hoạt động liên quan của nó) chịu trách nhiệm tập hợp các giao dịch, tính toán băm và xác minh chữ ký. Tuy nhiên, các tin nhắn được xác minh bằng các hoạt động này được tuần tự hóa thông qua giao dịch opcode và không cho phép chỉ định bất kỳ tin nhắn nào khác. Nói một cách đơn giản, vai trò của OP_CHECKSIG (và các hoạt động liên quan của nó) là sử dụng cơ chế chữ ký để xác minh xem UTXO được sử dụng làm đầu vào giao dịch có được chủ sở hữu chữ ký cho phép sử dụng hay không, từ đó bảo vệ tính bảo mật của Bitcoin.

CSFS, như tên cho thấy, kiểm tra chữ ký từ ngăn xếp (Kiểm tra Chữ ký Từ Ngăn xếp). Opcode CSFS nhận ba tham số từ ngăn xếp: chữ ký, thông báo và khóa chung và xác minh tính hợp lệ của chữ ký. Điều này có nghĩa là người ta có thể chuyển bất kỳ thông báo nào đến ngăn xếp thông qua các nhân chứng và xác minh nó thông qua CSFS, do đó tạo điều kiện cho một số cải tiến của Bitcoin.

Tính linh hoạt của CSFS Cho phép nó triển khai các cơ chế như chữ ký thanh toán, ủy quyền, hợp đồng tiên tri, đảm bảo 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 xem xét nội bộ giao dịch bằng CSFS rất đơ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ả OP_CSFS và OP_CHECKSIG đều được xác minh bằng cùng một khóa và chữ ký chung và nếu cả hai quá trình xác minh đều thành công thì Nội dung của bất kỳ thông báo nào tới OP_CSFS đều giống với giao dịch chi phí được xê-ri hóa (và dữ liệu khác) được OP_CHECKSIG ngầm sử dụng. Sau đó, chúng tôi nhận được dữ liệu giao dịch đã được xác minh trên ngăn xếp có thể được sử dụng để đặt giới hạn cho các giao dịch chi tiêu bằng cách sử dụng các mã hoạt động khác.

CSFS thường được thấy cùng với OP_CAT vì OP_CAT có thể ghép các trường khác nhau của giao dịch để hoàn thành quá trình tuần tự hóa, cho phép lựa chọn chính xác hơn các trường giao dịch cần thiết cho việc xem xét nội tâm. Nếu không có OP_CAT, tập lệnh không thể tính toán lại các giá trị băm từ dữ liệu có thể được kiểm tra riêng lẻ, vì vậy tất cả những gì nó thực sự có thể làm là kiểm tra xem giá trị băm có tương ứng với một giá trị cụ thể hay không, nghĩa là mã thông báo chỉ có thể được sử dụng thông qua một giao dịch cụ thể duy nhất.

CSFS có thể triển khai các opcode như CLTV, CSV, CTV, APO, v.v., khiến nó trở thành một opcode xem xét nội tâm linh hoạt. Do đó, nó cũng góp phần vào các giải pháp mở rộng lớp 2 của Bitcoin. Điểm bất lợi là nó yêu cầu thêm một bản sao đầy đủ của giao dịch đã ký vào ngăn xếp, điều này có thể làm tăng đáng kể quy mô giao dịch bằng cách sử dụng tính năng xem xét nội bộ CSFS. Các mã hoạt động xem xét nội tâm có mục đích đơn lẻ như CLTV và CSV có ít chi phí so sánh, nhưng việc thêm từng mã hoạt động xem xét nội tâm đặc biệt mới đòi hỏi phải có những thay đổi đồng thuận.

TXHASH (OP_TXHASH)

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

Do sự tương đồng giữa TXHASH và CTV nên đã có rất nhiều cuộc thảo luận về cả hai trong cộng đồng.

TXHASH có thể được coi là bản nâng cấp chung cho CTV, cung cấp các mẫu giao dịch nâng cao hơn, cho phép người dùng chỉ định rõ ràng các phần khác nhau của giao dịch chi tiêu và giải quyết nhiều vấn đề liên quan đến phí giao dịch. Không giống như các mã giao dịch khác, TXHASH không yêu cầu bản sao của dữ liệu cần thiết trong bằng chứng, điều này làm giảm hơn nữa 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 triển khai trong tapscript; như các lựa chọn thay thế CTV và APO.

Từ góc độ xây dựng hợp đồng, TXHASH có lợi hơn trong việc tạo "hợp đồng phụ gia" trong đó tất cả các phần của dữ liệu giao dịch bạn muốn sửa sẽ được đẩy lên ngăn xếp, được băm cùng nhau và được xác minh để tạo ra hàm băm khớp với một giá trị cố định; CTV phù hợp hơn để tạo "hợp đồng trừ" trong đó tất cả các phần dữ liệu giao dịch mà bạn muốn giữ trống sẽ được đẩy lên ngăn xếp. Sau đó, bằng cách sử dụng các opcode SHA256 cuộn, quá trình xử lý băm bắt đầu từ trạng thái trung gian cố định được cam kết với tiền tố của dữ liệu băm giao dịch. Phần miễn phí được băm sang 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.

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

OP_CAT

OP_CAT là một opcode bí ẩn ban đầu bị Satoshi Nakamoto bỏ rơi vì lý do bảo mật, nhưng gần đây đã gây ra các cuộc thảo luận sôi nổi giữa các nhà phát triển cốt lõi của Bitcoin và thậm chí nó còn bắt đầu văn hóa Meme trên Internet. Cuối cùng, OP_CAT đã được phê duyệt theo BIP-347 và được coi là đề xuất BIP có nhiều khả năng được thông qua nhất trong tương lai gần.

Trên thực tế, hoạt động của OP_CAT rất đơn giản: nó nối hai phần tử từ ngăn xếp. Nó triển khai chức năng Giao ước như thế nào?

Trên thực tế, kết nối Khả năng của hai phần 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 nối và băm và chức năng băm được cung cấp trong Bitcoin Script. Do đó, bằng cách sử dụng OP_CAT, về mặt lý thuyết, chúng tôi có thể xác minh bằng chứng Merkle bằng 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ệ chuỗi khối.

Như đã đề cập trước đó, CSFS cho phép thực hiện các giải pháp Giao ước phổ quát với sự trợ giúp của OP_CAT. Trên thực tế, bản thân OP_CAT có thể cho phép xem xét nội tâm giao dịch ngay cả khi không có CSFS, tận dụng cấu trúc của chữ ký Schnorr.

Trong chữ ký Schnorr, thông báo cần được ký bao gồm các trường sau:

Các trường này chứa các thành phần chính của giao dịch. Bằng cách đặt chúng vào scriptPubKey hoặc Witness và sử dụng OP_CAT kết hợp với OP_SHA256, chúng ta có thể tạo chữ ký Schnorr và xác minh nó bằng OP_CHECKSIG. Nếu quá trình 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, cho phép kiểm tra nội bộ giao dịch. Điều này cho phép chúng tôi 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ỉ đích hoặc số lượng Bitcoin liên quan.

Để biết các nguyên tắc mật mã cụ thể, bạn có thể tham khảo bài viết "Thủ thuật CAT và Schnorr" của Andrew Poelstra.

Tóm lại, tính linh hoạt của OP_CAT cho phép nó mô phỏng hầu hết mọi mã hoạt động của Giao ước. Nhiều opcode của Giao ước dựa vào chức năng của OP_CAT, điều này giúp tăng đáng kể vị trí của nó trong danh sách hợp nhất. Về lý thuyết, chỉ dựa vào OP_CAT và các opcode Bitcoin hiện có, chúng tôi có thể hy vọng xây dựng một bản tổng hợp BTC ZK được giảm thiểu độ tin cậy. Starknet, Chakra và các đối tác hệ sinh thái khác đang tích cực thúc đẩy mục tiêu này.

Kết luận

Khi chúng tôi khám phá các chiến lược khác nhau để mở rộng quy mô Bitcoin và nâng cao khả năng lập trình của nó, rõ ràng là con đường phía trước liên quan đến các cải tiến gốc, tính toán ngoài chuỗi và khả năng tổng hợp các khả năng viết kịch bản phức tạp.

Không có lớp nền linh hoạt thì không thể xây dựng lớp thứ hai linh hoạt hơn.

Mở rộng điện toán ngoài chuỗi là xu hướng trong tương lai, nhưng khả năng lập trình của Bitcoin cần một bước đột phá để hỗ trợ tốt hơn khả năng 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 điện toán trên Bitcoin về cơ bản khác với bản chất của điện toán trên Ethereum. Bitcoin chỉ hỗ trợ "xác minh" như một hình thức tính toán và không thể thực hiện các phép tính chung, trong khi Ethereum có bản chất tính toán và xác minh là sản phẩm phụ của tính toán. Sự khác biệt này có thể thấy ở một điểm: Ethereum tính phí gas cho các giao dịch không thể thực hiện được, trong khi Bitcoin không tính phí gas.

Hợp đồng là một dạng hợp đồng thông minh dựa trên sự xác minh chứ không phải tính toán. Ngoại trừ một số ít người theo trào lưu chính thống của Satoshi, mọi người dường như đều đồng ý rằng hợp đồng là một lựa chọn tốt để cải thiện Bitcoin. Tuy nhiên, cộng đồng vẫn đang tranh luận gay gắt về phương pháp nào nên được sử dụng để thực hiện hợp đồng.

APO, OP_VAULT và TLUV có xu hướng được áp dụng trực tiếp. Việc chọn ba phương pháp này có thể hiện thực hóa các ứng dụng cụ thể rẻ hơn và hiệu quả hơn. Những người đam mê Lightning Network sẽ chọn APO để triển khai LN-Symmetry; những người dùng muốn triển khai Vault tốt nhất nên sử dụng OP_VAULT; và để xây dựng CoinPool, TLUV có thể mang lại sự riêng tư và hiệu quả tốt hơn. OP_CAT và TXHASH có nhiều tính năng hơn, ít có lỗ hổng bảo mật hơn và có thể được kết hợp với các opcode khác để đạt được nhiều trường hợp sử dụng hơn, nhưng chi phí có thể tăng độ phức tạp của tập lệnh. CTV và CSFS điều chỉnh phương pháp xử lý chuỗi khối, CTV triển khai đầu ra bị trì hoãn và CSFS triển khai chữ ký bị trì hoãn. MATT nổi bật nhờ các chiến lược thực hiện lạc quan và chống gian lận, tận dụng cấu trúc Merkle Trie để triển khai các hợp đồng thông minh có mục đích chung, nhưng chức năng xem xét nội tâm vẫn yêu cầu các mã hoạt động mới.

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 nhận được Giao ước thông qua một đợt phân nhánh mềm. Starknet đã chính thức thông báo rằng họ sẽ tham gia hệ sinh thái Bitcoin và có kế hoạch triển khai thanh toán trên mạng Bitcoin trong vòng sáu tháng sau khi sáp nhập OP_CAT. Chakra sẽ tiếp tục chú ý đến những phát triển mới nhất trong hệ sinh thái Bitcoin, thúc đẩy việc sáp nhập fork mềm OP_CAT và sử dụng khả năng lập trình do Covenants mang lại để xây dựng lớp thanh toán Bitcoin an toàn và hiệu quả hơn.