Chén thánh của mạng lớp hai Bitcoin: Nội tâm và Hợp đồng
Tuyển chọn TechFlowTuyển chọn TechFlow
Chén thánh của mạng lớp hai Bitcoin: Nội tâm và Hợp đồng
Một bài viết giải thích chi tiết các đề xuất mã thao tác (opcode) nổi bật trong hệ sinh thái BTC: OP_CAT, CTV, APO, MATT
Chuyên sâu báo cáo Web3Tác giả: Chakra Research
Tổng quan
So với các blockchain hoàn thiện Turing như Ethereum, script trên Bitcoin bị coi là rất hạn chế, 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 hoặc chia. Quan trọng hơn, dữ liệu chuỗi khối gần như không thể được đọc bởi script, dẫn đến thiếu linh hoạt và khả năng lập trình thấp. Do đó, trong thời gian dài, người ta đã cố gắng tìm cách để cho phép script của Bitcoin (Script) có khả năng tự kiểm tra (Introspection).
Tự kiểm tra (Introspection) ám chỉ khả năng cho phép script Bitcoin kiểm tra và ràng buộc dữ liệu giao dịch. Điều này cho phép script kiểm soát việc sử dụng tiền dựa trên chi tiết cụ thể của giao dịch, từ đó đạt được chức năng phức tạp hơn. Hiện tại, hầu hết các mã vận hành (Opcode) của Bitcoin chỉ có hai chức năng: đẩy dữ liệu do người dùng cung cấp lên ngăn xếp hoặc thao tác dữ liệu đã có trên ngăn xếp. Opcode tự kiểm tra có thể đưa dữ liệu giao dịch hiện tại (như dấu thời gian, số tiền, ID giao dịch, v.v.) lên ngăn xếp, cho phép kiểm soát chi tiêu UTXO ở mức độ chi tiết cao hơn.
Hiện nay, chỉ có ba opcode chính trong script Bitcoin hỗ trợ tự kiểm tra: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY và CHECKSIG; CHECKSIG còn có các biến thể như CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG và CHECKMULTISIGVERIFY.
Hợp đồng (Covenant), nói một cách đơn giản, là giới hạn cách chuyển đổi token, cho phép người dùng chỉ định cách phân phối UTXO. Nhiều loại hợp đồng được thực hiện thông qua các opcode tự kiểm tra, và hiện nay trên Bitcoin Optech, tự kiểm tra đã được xếp vào mục thảo luận về hợp đồng.
Bitcoin hiện có hai loại hợp đồng: CSV (CheckSequenceVerify) và CLTV (CheckLockTimeVerify), cả hai đều là hợp đồng theo thời gian — nền tảng cho nhiều giải pháp mở rộng như mạng Lightning. Từ đây, chúng ta cũng thấy rằng các phương án mở rộng quy mô của Bitcoin phần lớn phụ thuộc vào tự kiểm tra và hợp đồng.
Làm thế nào để thêm điều kiện giới hạn vào việc chuyển đổi token? Trong thế giới mã hóa, cách phổ biến nhất là cam kết (Commitment), thường được thực hiện thông qua hàm băm (Hash). Để chứng minh rằng yêu cầu chuyển đổi được đáp ứng, cần dùng cơ chế chữ ký để xác minh. Do đó, trong hợp đồng tồn tại nhiều điều chỉnh liên quan đến hàm băm và chữ ký.
Dưới đây, chúng tôi sẽ mô tả các đề xuất opcode hợp đồng đang được thảo luận rộng rãi.
CTV (CheckTemplateVerify) BIP-119
CTV (CheckTemplateVerify) là một nâng cấp Bitcoin được cộng đồng thảo luận sôi nổi, nằm trong BIP-119. CTV cho phép script đầu ra xác định mẫu giao dịch chi tiêu khoản tiền này, bao gồm các trường như nVersion, nLockTime, hash scriptSig, số lượng đầu vào, hash sequences, số lượng đầu ra, hash outputs, chỉ số đầu vào... Những giới hạn mẫu này được thực hiện thông qua một cam kết hàm băm. Khi chi tiêu trong tương lai, script sẽ kiểm tra xem hash của các trường nhất định trong giao dịch chi tiêu có khớp với giá trị hash trong script đầu vào hay không. Thực tế, những mẫu này giới hạn chi tiết thời gian, cách thức, số tiền chi tiêu tương lai của UTXO đó.
Đáng chú ý, TXID đầu vào bị loại khỏi cam kết hàm băm. Việc loại trừ này là bắt buộc — dù trong giao dịch Legacy hay Segwit, với loại chữ ký mặc định SIGHASH_ALL, TXID đều phụ thuộc vào giá trị scriptPubKey để tạo ra. Vì vậy, nếu bao gồm TXID sẽ dẫn đến vòng lặp cam kết hàm băm, khiến việc xây dựng không thể thành công.
CTV thực hiện tự kiểm tra bằng cách dùng opcode mới lấy trực tiếp thông tin nhất định từ giao dịch, thực hiện băm và so sánh với cam kết trên ngăn xếp. Cách tự kiểm tra này tiêu tốn ít không gian trên chuỗi, nhưng lại thiếu tính linh hoạt.
Nền tảng cho các giải pháp lớp hai Bitcoin như mạng Lightning là các giao dịch đã ký trước. Ký trước thường ám chỉ việc tạo và ký sẵn giao dịch, nhưng chưa phát sóng lên mạng cho đến khi điều kiện nhất định được thỏa mãn. Về bản chất, CTV thực hiện chức năng ký trước nghiêm ngặt hơn, khi cam kết ký trước được công bố trực tiếp trên chuỗi, và giao dịch chỉ có thể diễn ra theo mẫu đã định trước.
CTV ban đầu được đề xuất nhằm giảm tắc nghẽn trên Bitcoin, còn được gọi là kiểm soát tắc nghẽn. Khi mạng Bitcoin tắc nghẽn, có thể dùng CTV để cam kết nhiều giao dịch tương lai bằng một giao dịch duy nhất, thay vì phải phát sóng nhiều giao dịch trong lúc tắc nghẽn, chờ đến khi tình trạng tắc nghẽn giảm bớt mới hoàn tất giao dịch thực sự. Kiểm soát tắc nghẽn có thể giúp ích rất lớn khi sàn giao dịch bị rút tiền hàng loạt. Ngoài ra, mẫu còn có thể dùng để triển khai kho lưu trữ (Vault), phòng chống tấn công hacker. Do hướng đi của tiền đã được xác định, hacker không thể chuyển UTXO sử dụng script CTV sang địa chỉ của mình.
CTV có thể cải thiện đáng kể mạng lớp hai. Ví dụ, đối với việc triển khai Timeout Trees và Channel Factory trong mạng Lightning, nhờ CTV, một UTXO đơn lẻ có thể mở rộng thành một cây CTV, đồng thời mở nhiều kênh trạng thái, nhưng chỉ cần một giao dịch trên chuỗi và một lần xác nhận. Ngoài ra, CTV cũng hỗ trợ giao dịch nguyên tử ATLC trong giao thức Ark.
APO (SIGHASH_ANYPREVOUT) BIP-118
BIP-118 đề xuất một loại cờ băm chữ ký mới cho tapscript, giúp viết logic chi tiêu linh hoạt hơn, gọi là SIGHASH_ANYPREVOUT. APO khá giống CTV ở nhiều điểm, nhưng để giải quyết vấn đề vòng lặp giữa scriptPubKeys và TXID, APO chọn loại bỏ thông tin đầu vào liên quan, chỉ ký lên đầu ra, cho phép giao dịch liên kết động với các UTXO khác nhau.
Về mặt logic, thao tác xác minh chữ ký OP_CHECKSIG (và các opcode tương tự) có ba chức năng:
-
Ghép nối các phần của giao dịch chi tiêu
-
Thực hiện băm dữ liệu đó.
-
Xác minh xem hash đã được ký bởi khóa cho trước hay chưa.
Nội dung cụ thể cần ký có thể điều chỉnh rất nhiều, tùy thuộc vào việc lựa chọn các trường nào của giao dịch để ký, được quyết định bởi cờ SIGHASH. Theo định nghĩa của opcode chữ ký trong BIP 342, các cờ SIGHASH bao gồm SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY... trong đó SIGHASH_ANYONECANPAY điều khiển đầu vào, còn lại điều khiển đầu ra.
SIGHASH_ALL là cờ mặc định, ký lên tất cả các đầu ra; SIGHASH_NONE không ký bất kỳ đầu ra nào; SIGHASH_SINGLE chỉ ký một đầu ra nhất định. SIGHASH_ANYONECANPAY có thể kết hợp với ba cờ SIGHASH đầu tiên — nếu bật, chỉ ký lên đầu vào đã chỉ định, ngược lại thì phải ký lên tất cả đầu vào.
Rõ ràng, các cờ SIGHASH này đều không thể loại bỏ ảnh hưởng của đầu vào, ngay cả SIGHASH_ANYONECANPAY vẫn phải cam kết ít nhất một đầu vào.
Do đó, BIP 118 đề xuất SIGHASH_ANYPREVOUT. Chữ ký APO không cần cam kết UTXO đầu vào bị chi tiêu (gọi là PREVOUT), mà chỉ cần ký lên đầu ra, mang lại sự linh hoạt cao hơn trong 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ý sử dụng một lần cùng khóa công khai tương ứng, tài sản gửi đến địa chỉ khóa công khai đó phải được chi tiêu theo giao dịch đã xây dựng trước — từ đó tạo thành hợp đồng. Tính linh hoạt của APO còn có thể dùng để sửa lỗi giao dịch: nếu một giao dịch bị kẹt do phí thấp, có thể dễ dàng tạo giao dịch khác để 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 làm cho thao tác trở nên đơn giản hơn.
Do loại bỏ vòng lặp giữa scriptPubKeys và TXID đầu vào, APO có thể thực hiện tự kiểm tra bằng cách thêm dữ liệu đầu ra vào phần chứng kiến (Witness), tuy nhiên điều này vẫn tiêu tốn thêm không gian dữ liệu chứng kiến.
Đối với các giao thức ngoài chuỗi như mạng Lightning và kho lưu trữ, APO giảm số lượng trạng thái trung gian cần lưu trữ, làm giảm đáng kể nhu 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, đơn giản hóa Channel Factory, xây dựng tháp giám sát nhẹ và rẻ hơn, cho phép rút lui đơn phương mà không để lại trạng thái sai, từ đó nâng cao hiệu suất mạng Lightning trên mọi phương diện. APO cũng có thể mô phỏng chức năng CTV, nhưng đòi hỏi cá nhân phải lưu trữ chữ ký và giao dịch đã ký trước, chi phí cao hơn và hiệu quả kém hơn CTV.
APO bị chỉ trích chủ yếu vì yêu cầu một phiên bản khóa hoàn toàn mới, không thể thực hiện chỉ bằng khả năng tương thích ngược. Hơn nữa, kiểu băm chữ ký mới có thể tiềm ẩn rủi ro double-spend. Sau thảo luận rộng rãi trong cộng đồng, APO sau đó yêu cầu thêm chữ ký thông thường trên nền tảng chữ ký cũ, làm giảm rủi ro an toàn, và do đó nhận được mã số BIP-118.
OP_VAULT BIP-345
BIP-345 đề xuất thêm hai opcode mới là OP_VAULT và OP_VAULT_RECOVER, kết hợp với CTV để thực hiện một loại hợp đồng chuyên dụng, cho phép người dùng áp đặt khoảng thời gian trì hoãn khi chi tiêu token nhất định, và trong giai đoạn trì hoãn này, có thể "hủy" giao dịch chi tiêu trước đó thông qua đường dẫn phục hồi.
Người dùng có thể tạo một địa chỉ Taproot đặc biệt để thiết lập kho lưu trữ, MAST phải chứa ít nhất hai script: một script OP_VAULT để thúc đẩy quá trình rút tiền như mong đợi, và một script OP_VAULT_RECOVER để đảm bảo có thể phục hồi coin bất cứ lúc nào trước khi hoàn tất rút tiền.
OP_VAULT thực hiện rút tiền có thể tạm dừng bằng cách khóa thời gian như thế nào? Nói đơn giản, opcode OP_VAULT thực hiện một việc: thay thế script OP_VAULT đã chi tiêu bằng một script chỉ định, thực chất là cập nhật một nút lá đơn lẻ trong MAST, các nút lá khác giữ nguyên. Thiết kế tương tự TLUV, chỉ khác là OP_VAULT không hỗ trợ cập nhật khóa nội bộ.
Việc giới thiệu mẫu trong quá trình cập nhật script có thể đạt được hiệu quả giới hạn thanh toán. Tham số khóa thời gian do OP_VAULT chỉ định, còn mẫu từ opcode CTV giới hạn tập hợp đầu ra được chi tiêu qua đường dẫn script này.
BIP-345 sinh ra để phục vụ kho lưu trữ. Nhờ OP_VAULT và OP_VAULT_RECOVER, người dùng có thể sở hữu một hình thức lưu ký an toàn, dùng một khóa cực kỳ an toàn (ví giấy, đa ký phân tán) làm đường dẫn phục hồi, còn các giao dịch hàng ngày thì cấu hình độ trễ chi tiêu nhất định. Thiết bị người dùng liên tục theo dõi tình trạng chi tiêu kho lưu trữ, nếu phát hiện chuyển tiền bất ngờ, người dùng có thể phục hồi.
Khi triển khai BIP-345 cho kho lưu trữ, cần cân nhắc vấn đề phí, đặc biệt là giao dịch phục hồi. Các giải pháp khả thi bao gồm CPFP, điểm neo tạm thời và các cờ băm chữ ký mới như SIGHASH_GROUP.
TLUV (TapleafUpdateVerify)
Kế hoạch TLUV được xây dựng xung quanh Taproot, nhằm giải quyết vấn đề rút khỏi UTXO chia sẻ một cách hiệu quả. Tư tưởng chỉ đạo là khi một đầu ra Taproot bị chi tiêu, chúng ta có thể, dựa trên các bước cập nhật mô tả bởi script TLUV, tận dụng cấu trúc nội bộ và biến đổi mật mã học của địa chỉ Taproot, để cập nhật từng phần khóa nội bộ và MAST, từ đó thực hiện chức năng hợp đồng.
Ý tưởng của kế hoạch TLUV là thông qua một opcode mới TAPLEAF_UPDATE_VERIFY, có thể 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 thực hiện một hoặc nhiều thao tác sau:
-
Cập nhật khóa công khai nội bộ
-
Cắt ngắn đường dẫn Merkle
-
Loại bỏ nút lá hiện đang thực thi
-
Thêm một nút lá mới vào cuối đường dẫn Merkle
Cụ thể, TLUV nhận ba đầu vào:
-
Một tham số chỉ định cách cập nhật khóa công khai nội bộ
-
Một tham số chỉ định nút lá mới cho đường dẫn Merkle
-
Một tham số chỉ định có xóa nút lá hiện tại và/hoặc xóa bao nhiêu nút lá đường dẫn Merkle hay không
Opcode TLUV sẽ tính toán scriptPubKey đã 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 chi tiêu tới scriptPubKey đó hay không.
Tình huống khởi phát cho TLUV là nhóm vốn chung (CoinPool). Hiện nay có thể tạo nhóm vốn bằng giao dịch đã ký trước, nhưng nếu muốn rút vốn không cần sự cho phép, cần tạo số lượng chữ ký tăng theo cấp số mũ, trong khi TLUV có thể đạt được việc rút vốn không cần sự cho phép mà không cần chữ ký trước. Ví dụ: một nhóm bạn dùng Taproot tạo một UTXO chung, gộp vốn của nhau. Họ có thể di chuyển vốn bên trong bằng khóa Taproot, hoặc cùng ký để thanh toán ra ngoài. Cá nhân có thể rút khỏi nhóm vốn bất cứ lúc nào, xóa đường dẫn thanh toán của mình, những người còn lại vẫn có thể thanh toán qua đường dẫn cũ, đồng thời việc rút của cá nhân không tiết lộ thông tin bổ sung về những người khác. So với giao dịch không nhóm vốn, cách này hiệu quả và riêng tư hơn.
Opcode TLUV đạt được giới hạn chi tiêu từng phần bằng cách cập nhật MAST gốc, nhưng chưa thực hiện tự kiểm tra số tiền đầu ra. Vì vậy cần thêm opcode mới IN_OUT_AMOUNT, đẩy hai dữ liệu lên ngăn xếp: số tiền UTXO đầu vào và số tiền đầu ra tương ứng, sau đó người dùng TLUV dùng toán tử toán học để xác minh tiền có được giữ đúng trong scriptPubKey cập nhật hay không.
Việc tự kiểm tra số tiền đầu ra tạo thêm độ phức tạp, vì số tiền Bitcoin biểu thị bằng satoshi cần tới 51 bit, nhưng script chỉ cho phép toán tử 32 bit. Cần nâng cấp toán tử trong script bằng cách định nghĩa lại hành vi opcode, hoặc dùng SIGHASH_GROUP thay thế IN_OUT_AMOUNT.
TLUV hứa hẹn cung cấp giải pháp cho nhóm vốn lớp 2 phi tập trung, tuy nhiên độ tin cậy trong việc điều chỉnh khóa công khai Taproot vẫn cần xác minh thêm.
MATT
MATT (Merkleize All The Things) cố gắng đạt ba mục tiêu: Merkle hóa trạng thái, Merkle hóa script và Merkle hóa thực thi, từ đó thực hiện hợp đồng thông minh tổng quát.
Merkle hóa trạng thái: Xây dựng một Merkle Trie, mỗi nút lá là hash của trạng thái, Merkle Root đại diện cho toàn bộ trạng thái hợp đồng.
Merkle hóa script: Là MAST cấu thành từ Tapscript, mỗi nút lá là một đường dẫn chuyển đổi trạng thái tiềm năng.
Merkle hóa thực thi: Thực hiện Merkle hóa thực thi thông qua cam kết mã hóa và cơ chế thách thức gian lận. Với bất kỳ hàm tính toán nào, các bên có thể tính toán ngoài chuỗi rồi công bố cam kết f(x)=y, nếu bên khác phát hiện kết quả sai f(x)=z thì có thể thách thức, trọng tài bằng phương pháp chia đôi — nguyên lý giống Optimistic Rollup.
Thách thức gian lận trong Merkle hóa thực thi
Để thực hiện MATT, script lập trình Bitcoin cần có các chức năng sau:
-
Buộc một đầu ra phải có script cụ thể (và số tiền tương ứng)
-
Gắn một đoạn dữ liệu vào đầu ra
-
Đọc dữ liệu đầu vào hiện tại (hoặc đầu vào khác)
Điểm thứ hai rất quan trọng — dữ liệu động nghĩa là trạng thái có thể được tính toán thông qua dữ liệu đầu vào do người chi tiêu cung cấp, vì nó cung cấp mô phỏng máy trạng thái, và có thể quyết định trạng thái tiếp theo cùng dữ liệu đính kèm. Kế hoạch MATT đề xuất opcode OP_CHECKCONTRACTVERIFY (OP_CCV), hợp nhất các opcode trước đó OP_CHECKOUTPUTCONTRACTVERIFY và OP_CHECKINPUTCONTRACTVERIFY, dùng thêm tham số flags để chỉ định đối tượng thao tác.
Kiểm soát số tiền đầu ra: Cách trực tiếp nhất là tự kiểm tra trực tiếp, nhưng số tiền đầu ra là số 64 bit, cần toán tử 64 bit — điều này rất phức tạp khi triển khai trong script Bitcoin. CCV dùng phương pháp kiểm tra trì hoãn, tương tự OP_VAULT: tất cả đầu vào có CCV trỏ tới cùng đầu ra sẽ được cộng dồn số tiền, làm giới hạn dưới cho số tiền đầu ra. Việc kiểm tra trì hoãn vì nó xảy ra trong quá trình giao dịch chứ không trong giai đoạn đánh giá script đầu vào.
Do tính phổ quát của bằng chứng gian lận, một số biến thể hợp đồng MATT nên có thể thực hiện mọi loại hợp đồng thông minh hoặc xây dựng lớp hai, mặc dù các yêu cầu bổ sung (như khóa vốn và độ trễ thách thức) cần được đánh giá chính xác; cần nghiên cứu thêm để xác định ứng dụng nào chấp nhận được về mặt giao dịch. Ví dụ, mô phỏng hàm OP_ZK_VERIFY bằng cam kết mã hóa và cơ chế thách thức gian lận để thực hiện rollup phi tin cậy trên Bitcoin.
Thực tế, điều đó đang diễn ra. Johan Torås Halseth đã sử dụng opcode OP_CHECKCONTRACTVERIFY từ đề xuất soft fork MATT để triển khai elftrace, có thể xác minh tất cả chương trình hỗ trợ biên dịch RISC-V trên chuỗi Bitcoin, cho phép một bên trong hợp đồng nhận tiền thông qua hợp đồng, thực hiện cầu nối xác minh gốc trên Bitcoin.
CSFS (OP_CHECKSIGFROMSTACK)
Từ phần giới thiệu opcode APO, chúng ta đã biết OP_CHECKSIG (và các opcode liên quan) chịu trách nhiệm ghép nối giao dịch, xử lý băm và xác minh chữ ký. Nhưng thông điệp nó xác minh được tạo từ việc serial hóa giao dịch sử dụng opcode đó, không cho phép chỉ định thông điệp khác. Nói đơn giản, OP_CHECKSIG (và các opcode liên quan) có chức năng bảo vệ an toàn Bitcoin bằng cách xác minh xem UTXO đầu vào có được ủy quyền chi tiêu bởi người nắm giữ chữ ký hay không.
CSFS, như tên gọi, kiểm tra chữ ký từ ngăn xếp (Stack). 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, sau đó xác minh tính hợp lệ của chữ ký. Điều này cho phép người dùng truyền bất kỳ thông điệp nào lên ngăn xếp qua dữ liệu chứng kiến và xác minh bằng CSFS, mở ra khả năng sáng tạo trên Bitcoin.
Đặc điểm linh hoạt của CSFS cho phép thực hiện nhiều cơ chế như chữ ký thanh toán, ủy quyền quyền hạn, hợp đồng oracle, trái phiếu bảo vệ double-spend... Quan trọng hơn, nó có thể thực hiện tự kiểm tra giao dịch. Nguyên lý rất đơn giản: nếu đẩy nội dung giao dịch được dùng bởi OP_CHECKSIG lên ngăn xếp qua chứng kiến, sau đó dùng cùng khóa công khai và chữ ký để xác minh cả bằng CSFS và OP_CHECKSIG, nếu cả hai đều thành công thì nội dung bất kỳ truyền cho CSFS giống với giao dịch chi tiêu serialized (và dữ liệu khác) được dùng ngầm bởi OP_CHECKSIG. Như vậy, chúng ta có dữ liệu giao dịch đã được xác minh trên ngăn xếp, có thể dùng các opcode khác để áp đặt giới hạn lên giao dịch chi tiêu.
CSFS thường xuất hiện cùng OP_CAT, vì OP_CAT có thể nối các trường khác nhau của giao dịch để hoàn tất serialization, giúp chọn chính xác các trường giao dịch cần tự kiểm tra. Không có OP_CAT, script không thể tái tính toán hash từ dữ liệu có thể kiểm tra riêng lẻ, nên điều nó thực sự có thể làm là kiểm tra hash có bằng giá trị cụ thể hay không — nghĩa là coin chỉ có thể chi tiêu bằng một giao dịch duy nhất.
CSFS có thể thực hiện các opcode như CLTV, CSV, CTV, APO — là một opcode tự kiểm tra tổng quát, do đó cũng hỗ trợ giải pháp mở rộng lớp 2 Bitcoin. Điểm yếu là cần thêm một bản sao đầy đủ của giao dịch đã ký lên ngăn xếp, có thể làm tăng đáng kể kích thước giao dịch muốn dùng CSFS để tự kiểm tra. Ngược lại, các opcode tự kiểm tra mục đích đơn như CLTV và CSV tiêu tốn ít nhất, nhưng mỗi opcode tự kiểm tra đặc biệt mới đều cần thay đổi đồng thuận.
TXHASH (OP_TXHASH)
OP_TXHASH là một opcode tự kiểm tra rất trực tiếp, cho phép người dùng chọn hash của một trường nhất định để đẩy lên ngăn xếp. Cụ thể, OP_TXHASH sẽ lấy một cờ txhash từ ngăn xếp, tính toán một txhash (đã đánh dấu) theo cờ đó, rồi đẩy hash kết quả lên ngăn xếp.
Do sự tương đồng giữa TXHASH và CTV, cộng đồng đã có nhiều tranh luận về hai cái này.
TXHASH có thể được coi là nâng cấp tổng quát của CTV, cung cấp mẫu giao dịch cao cấp hơn, cho phép người dùng chỉ rõ một phần của giao dịch chi tiêu, giải quyết nhiều vấn đề về phí giao dịch. So với các opcode hợp đồng khác, TXHASH không cần cung cấp bản sao dữ liệu cần thiết trong chứng kiến, giảm thêm nhu cầu lưu trữ; khác với CTV, TXHASH không tương thích NOP, chỉ có thể triển khai trong tapscript; kết hợp TXHASH với CSFS có thể thay thế CTV và APO.
Về cách xây dựng hợp đồng, TXHASH dễ thực hiện "hợp đồng cộng", đẩy tất cả phần dữ liệu giao dịch bạn muốn cố định lên ngăn xếp, băm chung và xác minh hash kết quả khớp với giá trị cố định; CTV dễ thực hiện "hợp đồng trừ", đẩy tất cả phần dữ liệu giao dịch bạn muốn giữ tự do lên ngăn xếp, sau đó dùng OP_SHA256 cuộn từ trạng thái trung gian cố định, cam kết tiền tố hash dữ liệu giao dịch. Các phần tự do được băm vào trạng thái trung gian đó.
Trường TxFieldSelector được định nghĩa trong đặc tả TXHASH hứa hẹn mở rộng sang các opcode khác như OP_TX.
BIP liên quan đến TXHASH hiện đang ở trạng thái Draft trên Github, chưa có mã số.
OP_CAT
OP_CAT là một opcode颇具神秘色彩, từng bị Satoshi loại bỏ do lo ngại an toàn, gần đây lại thu hút sự thảo luận mạnh mẽ từ các nhà phát triển cốt lõi Bitcoin, thậm chí gây nên văn hóa Meme trên Internet, cuối cùng OP_CAT được phê duyệt BIP-347, được nhiều người gọi là đề xuất BIP khả thi nhất gần đây.
Thực tế, hành vi của OP_CAT rất đơn giản: nối hai phần tử trên ngăn xếp thành một. Làm thế nào để thực hiện chức năng hợp đồng?
Thực tế, chức năng nối hai phần tử tương ứng với cấu trúc dữ liệu mật mã mạnh mẽ Merkle Trie. Quá trình xây dựng Merkle Trie chỉ cần hai thao tác: nối và băm, trong khi hàm băm đã có sẵn trong script Bitcoin. Do đó, có OP_CAT, về mặt lý thuyết chúng ta có thể xác minh Merkle Proof trong script Bitcoin — cách xác minh nhẹ phổ biến nhất trong blockchain.
Như đã đề cập, CSFS nhờ OP_CAT có thể thực hiện giải pháp hợp đồng tổng quát. Thực tế, không cần CSFS, tận dụng cấu trúc chữ ký Schnorr, bản thân OP_CAT có thể thực hiện tự kiểm tra giao dịch.
Trong chữ ký Schnorr, thông điệp cần ký được tạo từ các trường sau:
Các trường này chứa các yếu tố chính của giao dịch, bằng cách đặt chúng vào scriptPubKey hoặc chứng kiến, dùng OP_CAT và OP_SHA256, chúng ta có thể xây dựng một chữ ký Schnorr và xác minh bằng OP_CHECKSIG. Nếu 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, thực hiện tự kiểm tra giao dịch, có thể trích xuất và "kiểm tra" các phần khác nhau của giao dịch, như đầu vào, đầu ra, địa chỉ đích hoặc số Bitcoin liên quan.
Nguyên lý mật mã cụ thể có thể tham khảo bài viết CAT and Schnorr Tricks của Andrew Poelstra.
Tóm lại, tính linh hoạt của OP_CAT khiến nó gần như có thể mô phỏng mọi opcode hợp đồng, và nhiều opcode hợp đồng phụ thuộc vào chức năng OP_CAT, làm vị trí của nó trong danh sách hợp nhất tiến lên đáng kể. Về lý thuyết, chỉ cần OP_CAT và các opcode Bitcoin hiện có, chúng ta có thể xây dựng một BTC ZK Rollup tối thiểu hóa sự 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 điều này.
Kết luận
Khi khám phá nhiều chiến lược mở rộng Bitcoin và tăng cường khả năng lập trình, rõ ràng con đường phía trước liên quan đến sự kết hợp của cải tiến nội bộ, tính toán ngoài chuỗi và các chức năng script phức tạp.
Không có tầng cơ sở linh hoạt, không thể xây dựng lớp hai linh hoạt hơn.
Mở rộng ngoài chuỗi là tương lai, nhưng khả năng lập trình trên Bitcoin phải đột phá để hỗ trợ tốt hơn việc mở rộng, trở thành tiền tệ thế giới thực sự.
Tuy nhiên, tính toán Bitcoin và Ethereum thực tế có bản chất khác nhau. Bitcoin chỉ hỗ trợ "xác minh" như một dạng tính toán, không thể tính toán tổng quát, trong khi Ethereum về bản chất là tính toán, xác minh chỉ là sản phẩm phụ. Một điểm khác biệt rõ ràng: Ethereum thu phí Gas cho cả giao dịch thất bại, còn Bitcoin thì không.
Hợp đồng thực hiện một dạng hợp đồng thông minh dựa trên xác minh chứ không phải tính toán. Về hợp đồng, ngoài một vài nguyên giáo Bitcoin cực đoan, dường như ai cũng cho rằng hợp đồng là lựa chọn tốt để cải tiến Bitcoin. Tuy nhiên, cộng đồng luôn tranh luận gay gắt về nên dùng方案 nào để thực hiện hợp đồng.
APO, OP_VAULT, TLUV thiên về ứng dụng trực tiếp, chọn chúng có thể thực hiện ứng dụng cụ thể một cách rẻ và hiệu quả hơn. Người yêu thích mạng Lightning sẽ thích APO vì có thể đạt LN-Symmetry; muốn thực hiện kho lưu trữ thì nên dùng OP_VAULT; xây CoinPool thì TLUV riêng tư và hiệu quả hơn. OP_CAT, TXHASH tổng quát hơn, khả năng có lỗ hổng an toàn nhỏ hơn, kết hợp với các opcode khác có thể thực hiện nhiều trường hợp sử dụng hơn, đương nhiên có thể phải đánh đổi bằng độ phức tạp script. CTV và CSFS điều chỉnh quá trình xử lý blockchain, CTV thực hiện đầu ra trì hoãn, CSFS thực hiện chữ ký trì hoãn. MATT tương đối độc lập, dùng tư tưởng thực thi lạc quan và bằng chứng gian lận, tận dụng cấu trúc Merkle Trie để thực hiện hợp đồng thông minh tổng quát, nhưng vẫn cần opcode mới để mang lại chức năng tự kiểm tra.
Chúng tôi thấy cộng đồng Bitcoin đang thảo luận sôi nổi về khả năng thông qua soft fork để Bitcoin có được hợp đồng. Starknet chính thức tuyên bố gia nhập hệ sinh thái Bitcoin, dự kiến triển khai thanh toán trên mạng Bitcoin trong vòng sáu tháng sau khi OP_CAT được hợp nhất. Chakra sẽ tiếp tục theo dõi sát sao diễn biến mới nhất của hệ sinh thái Bitcoin, thúc đẩy việc hợp nhất soft fork OP_CAT, và sử dụng khả năng lập trình từ tự kiểm tra và hợp đồng để xây dựng một tầng thanh toán Bitcoin an toàn và hiệu quả hơn.
Cảm ơn Jeffrey, Ben, Mutourend, Lynndell đã đọc và góp ý cho bài viết này
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@ChakraChain
