Được viết bởi: Nghiên cứu Luân xa
Tổng quan
So với các chuỗi khối Turing-complete như Ethereum, các tập lệnh trên Bitcoin được coi là rất hạn chế và chỉ có thể thực hiện các hoạt động cơ bản, 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ể đọc được bằng các tập lệnh, dẫn đến thiếu tính linh hoạt nghiêm trọng và khả năng lập trình thấp. Vì vậy, mọi người từ lâu đã cố gắng tìm cách làm cho Bitcoin Script trở nên nội tâm.
Xem xét nội tâm đề cập đến khả năng cho phép các tập lệnh Bitcoin 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 cụ thể của giao dịch, cho phép thực hiện chức năng phức tạp hơn. Hầu hết các mã hoạt động Bitcoin (Opcode) hiện tại 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 hoạt động trên dữ liệu hiện có trên ngăn xếp. Mã hoạt động nội quan có thể đẩy dữ liệu giao dịch hiện tại (chẳng hạn như dấu thời gian, số tiền, ID giao dịch, v.v.) vào ngăn xếp để cung cấp khả năng kiểm soát chi tiết hơn về cách chi tiêu UTXO.
Hiện tại, chỉ có ba mã hoạt động chính trong Bitcoin Script hỗ trợ xem xét nội tâm: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY và CHECKSIG cũng có các biến thể như CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG và CHECKMULTISIGVERIFY.
Nói một cách đơn giản, hợp đồng là một hạn chế về cách chuyển mã thông báo. Người dùng có thể chỉ định phương thức phân phối UTXO thông qua hợp đồng. Nhiều hợp đồng được thực hiện thông qua các mã hoạt động nội tâm và việc xem xét nội tâm hiện đã được thảo luận trong các mục nhập hợp đồng trong Bitcoin Optech.
Bitcoin hiện có hai hợp đồng, CSV (CheckSequenceVerify) và CLTV (CheckLockTimeVerify), cả hai đều là hợp đồng thời gian, là cơ sở cho nhiều kế hoạch mở rộng, chẳng hạn như Lightning Network. Từ đó chúng ta cũng có thể thấy rằng kế hoạch mở rộng 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 các hạn chế về việc chuyển mã thông báo? Trong thế giới mã hóa, phương pháp được sử dụng phổ biến nhất là cam kết, thường được thực hiện thông qua hàm băm. Để chứng minh rằng chúng tôi đáp ứng các yêu cầu chuyển khoản, chúng tôi cần xác minh thông qua cơ chế chữ ký. 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 hợp đồng được thảo luận rộng rãi.
CTV (CheckTemplateVerify) BIP-119
CTV (CheckTemplateVerify) là một bản nâng cấp Bitcoin được cộng đồng thảo luận sôi nổi và được đưa vào BIP-119. CTV cho phép tập lệnh đầu ra chỉ định mẫu để sử dụng tiền trong giao dịch chi tiêu, 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ủa mẫu này. các hạn chế được chuyển qua hàm băm Để đạt được điều này, tập lệnh chi tiêu trong tương lai sẽ kiểm tra xem giá trị băm của 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. Các mẫu này thực sự giới hạn thời gian, phương thức, số tiền và các chi tiết khác. của giao dịch chi tiêu trong tương lai UTXO.
Điều đáng chú ý là TXID đầu vào được loại trừ khỏi lời hứa băm. Loại trừ này là cần thiết, cho dù trong giao dịch Legacy hay Segwit, ở loại chữ ký SIGHASH_ALL mặc định, TXID phải được tạo dựa trên giá trị của scriptPubKey. Do đó, việc bao gồm TXID sẽ gây ra vòng lặp trong lời hứa băm và không thể xây dựng thành công.
Cách CTV thực hiện việc xem xét nội tâm là lấy trực tiếp thông tin được chỉ định của giao dịch thông qua một mã opcode mới, băm nó và so sánh nó với cam kết trong ngăn xếp. Phương pháp xem xét nội tâm này tiêu tốn ít không gian hơn trên chuỗi nhưng thiếu tính linh hoạt nhất định.
Cơ sở của các giải pháp lớp thứ hai của Bitcoin 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 chúng lên mạ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 chức năng ký trước chặt chẽ hơn, xuất bản các cam kết đã ký trước trực tiếp trên chuỗi và các giao dịch chỉ có thể được thực hiện theo các mẫu trước.
CTV ban đầu được đề xuất để giảm bớt tắc nghẽn Bitcoin, còn có thể được gọi là kiểm soát tắc nghẽn. Khi Bitcoin tương đối tắc nghẽn, CTV có thể được sử dụng để thực hiện nhiều giao dịch trong tương lai thông qua một giao dịch duy nhất mà không cần phải phát sóng nhiều giao dịch trong thời gian tắc nghẽn và sau đó hoàn thành giao dịch thực tế sau khi tình trạng tắc nghẽn khối giảm bớt. Kiểm soát tắc nghẽn có thể giúp ích rất nhiều khi sàn giao dịch gặp sự cố. Ngoài ra, các mẫu cũng có thể được sử dụng để triển khai vault nhằm ngăn chặn các cuộc tấn công của hacker. Vì đích đến của số tiền đã được xác định nên tin tặc không thể gửi UTXO bằng tập lệnh CTV đến địa chỉ của chính hắn.
CTV có thể mang lại những cải tiến lớn cho mạng lớp 2. Ví dụ: để triển khai Cây hết thời gian và các nhà máy kênh trong Lightning Network, thông qua CTV, một UTXO duy nhất có thể được mở rộng thành cây CTV và nhiều kênh trạng thái được mở cùng lúc, trong khi chỉ có một giao dịch và một xác nhận trên dây chuyền. Ngoài ra, CTV còn hỗ trợ các 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 đã ký mới cho tapscript để tạo điều kiện viết logic chi tiêu linh hoạt hơn, được gọi là SIGHASH_ANYPREVOUT. APO và CTV giống nhau về nhiều mặt. Đối mặt với vấn đề vòng lặp giữa scriptPubKeys và TXID, giải pháp của APO là loại trừ thông tin liên quan đến đầu vào và chỉ ký đầu ra để các giao dịch có thể được liên kết động với các UTXO khác nhau.
Được phân chia một cách hợp lý, hoạt động xác minh chữ ký OP_CHECKSIG (và các mã hoạt động tương tự của nó) có ba chức năng:
Tập hợp các phần khác nhau của giao dịch chi tiêu
Đã trúng.
Xác minh rằng hàm băm đã được ký bởi khóa đã cho.
Nội dung cụ thể của chữ ký có nhiều chỗ để điều chỉnh. Trường giao dịch nào được tập hợp cho chữ ký được xác định bởi cờ SIGHASH. Theo định nghĩa của opcode chữ ký BIP 342, các cờ SIGHASH được chia thành SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, v.v., trong đó SIGHASH_ANYONECANPAY kiểm soát đầu vào và đầu ra kiểm soát phần còn lại.
SIGHASH_ALL là cờ SIGHASH mặc định, ký hiệu cho tất cả đầu ra; SIGHASH_NONE không ký bất kỳ đầu ra nào; SIGHASH_ANYONECANPAY có thể được đặt cùng với ba cờ SIGHASH đầu tiên. Nếu SIGHASH_ANYONECANPAY được đặt, chỉ đầu vào được chỉ định mới được ký, nếu không tất cả đầu vào cần phải được ký.
Rõ ràng, không có cờ SIGHASH nào trong số này có thể loại bỏ tác động của đầu vào. Ngay cả SIGHASH_ANYONECANPAY cũng yêu cầu cam kết đối với đầu vào.
Do đó, BIP 118 đề xuất SIGHASH_ANYPREVOUT. Chữ ký APO không yêu cầu sử dụng UTXO đầu vào (đượ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à xây dựng chữ ký sử dụng 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 để thực hiện 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 trong chuỗi do phí thấp, một giao dịch khác có thể dễ dàng được tạo với mức phí cao hơn mà không cần chữ ký mới. Ngoài ra, đối với ví đa chữ ký, chữ ký không phụ thuộc vào đầu vào đã chi tiêu, giúp thao tác dễ dàng hơn.
Vì vòng lặp giữa scriptPubKeys và TXID đầu vào bị loại bỏ. 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 nhân chứng (Nhân chứng). Tất nhiên, điều này vẫn yêu cầu tiêu thụ thêm không gian dữ liệu của nhân chứng.
Đối với các giao thức ngoài chuỗi như Lightning Network và Vault, APO giảm trạng thái trung gian cần lưu, giảm đáng kể 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 sản xuất kênh, xây dựng tháp canh nhẹ và rẻ, đồng thời cho phép thoát đơn phương mà không để lại trạng thái lỗi, cải thiện hiệu suất của Lightning Network về mọi mặt. APO cũng có thể được sử dụng để mô phỏng các chức năng của CTV, nhưng nó yêu cầu các cá nhân lưu trữ chữ ký và các giao dịch được ký trước, điều này tốn kém hơn và không hiệu quả bằng CTV.
Lời chỉ trích chính đối với APO 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 thuần túy. Ngoài ra, các loại hàm băm chữ ký mới có thể tiềm ẩn rủi ro chi tiêu gấp đôi. Sau các cuộc thảo luận rộng rãi trong cộng đồng, APO đã yêu cầu bổ sung chữ ký chung ngoài chữ ký ban đầu. Vấn đề bảo mật đã được giảm bớt và APO đã nhận được số BIP-118.
OP_VAULT BIP-345
BIP-345 đề xuất thêm hai opcode mới, OP_VAULT và OP_VAULT_RECOVER, để kết hợp với CTV để thực hiện hợp đồng chuyên dụng cho phép người dùng buộc một khoảng thời gian trì hoãn đối với việc chi tiêu các mã thông báo được chỉ định. Trong thời gian trì hoãn, dữ liệu trước đó có thể được khôi phục. thông qua con đường phục hồi Chi tiêu "Hoàn tác".
Người dùng có thể xây dựng kho tiền bằng cách tạo một địa chỉ Taproot cụ thể cần chứa ít nhất hai tập lệnh, một tập lệnh OP_VAULT để hỗ trợ quá trình rút tiền dự kiến và một tập lệnh OP_VAULT_RECOVER khác để đảm bảo rằng bất kỳ lúc nào trước khi quá trình rút tiền hoàn tất, Tiền xu có thể được phục hồi.
OP_VAULT Làm cách nào để thực hiện rút tiền bị khóa theo thời gian? Nói một cách đơn giản, opcode OP_VAULT hoàn thành một việc: thay thế tập lệnh OP_VAULT đã sử dụng bằng tập lệnh được chỉ định, thực sự hoàn thành việc cập nhật một nút lá duy nhất của MAST, giữ nguyên các nút lá còn lại. Thiết kế tương tự TLUV, ngoại trừ OP_VAULT không hỗ trợ cập nhật khóa nội bộ.
Việc giới thiệu các mẫu trong quá trình cập nhật tập lệnh có thể đạt được hiệu quả hạn chế thanh toán. Trong số đó, tham số khóa thời gian được chỉ định bởi OP_VAULT và mẫu do opcode CTV mang lại giới hạn tập hợp đầu ra được sử dụng thông qua đường dẫn tập lệnh này.
BIP-345 được sinh ra cho vault. Với OP_VAULT và OP_VAULT_RECOVER, người dùng có thể có phương thức lưu ký an toàn với khóa có độ bảo mật cao (ví giấy, phân phối nhiều chữ ký) làm đường dẫn khôi phục và phần còn lại của cấu hình thanh toán hàng ngày. bị trì hoãn. 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ể khôi phục nó.
BIP-345 yêu cầu cân nhắc về chi phí khi triển khai vault, đặc biệt là khôi phục các giao dịch. Các giải pháp khả thi bao gồm CPFP, neo tạm thời và cờ băm chữ ký mới như SIGHASH_GROUP.
TLUV (TapleafUpdateVerify)
Giải pháp TLUV được xây dựng xung quanh Taproot và nhằm mục đích giải quyết vấn đề thoát UTXO dùng chung một cách hiệu quả. Ý tưởng hướng dẫn là khi sử dụng đầu ra Taproot, chúng tôi có thể cập nhật một phần khóa nội bộ và MAST bằng cách sử dụng cấu trúc bên trong và chuyển đổi mật mã của địa chỉ Taproot theo các bước cập nhật được mô tả trong tập lệnh TLUV, từ đó hiện thực hóa chức năng hợp đồng. .
Ý tưởng của giải pháp TLUV là thông qua mã opcode mới TAPLEAF_UPDATE_VERIFY, bạn có thể tạo địa chỉ Taproot mới dựa trên đầu vào tiêu thụ 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 dẫn merkle
Xóa nút lá hiện đang thực thi
Thêm nút lá mới vào cuối đường dẫn Merkle
Cụ thể, TLUV nhận được ba đầu vào:
Một chỉ định cách cập nhật khóa chung nội bộ
Một người chỉ định một nút lá mới cho đường dẫn Merkle
Một chỉ định có nên loại bỏ nút lá hiện tại hay không và/hoặc có bao nhiêu nút lá đường dẫn Merkle cần loại bỏ
Mã hoạt động TLUV tính toán scriptPubKey đã cập nhật và xác minh rằng đầu ra tương ứng với đầu vào hiện tại sẽ sử dụng scriptPubKey đó.
Kịch bản đầy cảm hứng của TLUV là CoinPool. Ngày nay, có thể tạo một nhóm liên kết chỉ bằng các giao dịch được ký trước, nhưng nếu bạn muốn đạt được lối thoát không được phép, bạn cần tạo số lượng chữ ký lớn hơn theo cấp số nhân, trong khi 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 đã sử dụng Taproot để xây dựng UTXO dùng chung nhằm gộp tiền của nhau. Họ có thể sử dụng khóa Taproot để chuyển tiền nội bộ và cũng có thể đồng ký tên để thực hiện thanh toán bên ngoài. Các cá nhân có thể thoát khỏi quỹ chung bất kỳ lúc nào và xóa đường dẫn thanh toán của riêng mình. Những người khác vẫn có thể hoàn tất thanh toán thông qua đường dẫn ban đầu. Đồng thời, việc thoát của cá nhân sẽ không tiết lộ thêm thông tin về những người khác bên trong. So với các giao dịch không gộp, phương pháp này hiệu quả và riêng tư hơn.
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 MAST ban đầu, nhưng không thực hiện việc xem xét nội tâm số tiền đầu ra. Vì vậy, cũng cần bao gồm một opcode mới IN_OUT_AMOUNT, đẩy hai phần dữ liệu vào ngăn xếp: lượng UTXO đầu vào này và lượng đầu ra tương ứng, sau đó yêu cầu người sử dụng TLUV sử dụng các toán tử toán học để xác minh rằng số tiền được bảo lưu đúng cách trong scriptPubKey được cập nhật.
Việc xem xét nội bộ số lượng đầu ra sẽ tạo thêm một lớp phức tạp khác, vì số lượng Bitcoin yêu cầu tối đa 51 bit để biểu thị bằng satoshi, nhưng tập lệnh chỉ cho phép các phép toán 32 bit và cần được nâng cấp trong tập lệnh bằng cách xác định lại toán tử hành vi opcode hoặc sử dụng SIGHASH_GROUP thay vì IN_OUT_AMOUNT.
TLUV dự kiến sẽ cung cấp giải pháp cho nhóm quỹ Lớp 2 phi tập trung. Tất nhiên, độ tin cậy của các chỉnh sửa khóa công khai Taproot vẫn chưa được xác nhận.
MATT
MATT (Merkleize All The Things) cố gắng đạt được ba mục tiêu: trạng thái dựa trên Merkle, tập lệnh dựa trên Merkle và thực thi dựa trên Merkle, sau đó hiện thực hóa các hợp đồng thông minh phổ quát.
Trạng thái Merkle: Xây dựng Merkle Trie, trong đó mỗi nút lá là giá trị băm của trạng thái và Merkle Root đại diện cho trạng thái của toàn bộ hợp đồng.
Tập lệnh Merkle: nghĩa là MAST bao gồm Tapscript. Mỗi nút lá là một đường dẫn chuyển đổi trạng thái có thể.
Thực thi Merkle: Việc thực thi Merkle đạt được thông qua các cơ chế thách thức gian lận và cam kết được mã hóa Đố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 ngoài chuỗi và sau đó đưa ra cam kết f(x)=y và những người tham gia khác nhận thấy rằng kết quả tính toán sai f. (x)= z, bạn có thể thách thức và phân xử thông qua phương pháp phân đôi, nguyên tắc tương tự như Tổng hợp lạc quan.
Những thách thức gian lận được kích hoạt bởi Merkle
Để triển khai MATT, các tập lệnh lập trình Bitcoin cần phải có chức năng sau:
Buộc đầu ra phải có các tập lệnh cụ thể (và số lượng của chúng)
Nối một phần dữ liệu vào đầ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 rất 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 cung cấp mô phỏng máy trạng thái và có thể xác định trạng thái tiếp theo bằng dữ liệu bổ sung. Giải pháp MATT được triển khai bằng cách đề xuất mã op_CHECKCONTRACTVERIFY (OP_CCV), là sự hợp nhất của mã op_CHECKOUTPUTCONTRACTVERIFY và OP_CHECKINPUTCONTRACTVERIFY được đề xuất ban đầu, đồng thời sử dụng tham số cờ bổ sung để chỉ định đối tượng của hoạt động.
Kiểm soát lượng đầu ra: Cách trực tiếp nhất là thông qua việc xem xét nội tâm trực tiếp. Tuy nhiên, lượng đầu ra là số 64 bit và yêu cầu các hoạt động 64 bit, rất phức tạp trong việc triển khai các tập lệnh Bitcoin. CCV áp dụng phương pháp kiểm tra trì hoãn, tương tự như OP_VAULT. Tất cả các đầu vào có CCV cho cùng một đầu ra đều có tổng lượng đầu vào là giới hạn dưới của lượng đầu ra. Sự chậm trễ là do việc kiểm tra được thực hiện trong quá trình giao dịch chứ không phải trong quá trình đánh giá tập lệnh đã nhập.
Do tính tổng quát của việc chống gian lận, một số biến thể của hợp đồng MATT sẽ cho phép tất cả các loại hợp đồng thông minh hoặc xây dựng lớp thứ hai, mặc dù cần phải đánh giá chính xác các yêu cầu bổ sung (như khóa vốn và trì hoãn thời gian thử thách); để đánh giá Ứng dụng nào là một giao dịch được chấp nhận. Ví dụ: cam kết mật mã và cơ chế thách thức gian lận được sử dụng để mô phỏng chức năng OP_ZK_VERIFY nhằm triển khai Rollup không đáng tin cậy trên Bitcoin.
Trên thực tế, nó đã xảy ra rồi. Johan Torås Halseth đã triển khai elftrace bằng cách sử dụng mã hoạt động OP_CHECKCONTRACTVERIFY trong đề xuất fork mềm MATT, mã này có thể xác minh tất cả cá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 thỏa thuận hợp đồng nhận tiền thông qua hợp đồng, đạt được cầu nối A để xác minh gốc của Bitcoin.
CSFS (OP_CHECKSIGFROMSTACK)
Từ việc giới thiệu mã opcode 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, băm và xác minh chữ ký. Tuy nhiên, thông báo mà nó xác minh có được bằng cách tuần tự hóa giao dịch bằng mã opcode này và không có thông báo nào khác được phép chỉ định. Nói một cách đơn giản, OP_CHECKSIG (và các hoạt động liên quan của nó) hoạt động thông qua cơ chế chữ ký để xác minh xem UTXO được sử dụng làm đầu vào giao dịch có được phép sử dụng bởi người nắm giữ chữ ký 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. Mã 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 các thông báo tùy ý đến ngăn xếp thông qua dữ liệu chứng kiến và được CSFS xác minh. điều này tạo nên một số đổi mới về tiền tệ là có thể thực hiện được.
Các tính năng linh hoạt của CSFS cho phép nó triển khai nhiều cơ chế như chữ ký thanh toán, ủy quyền, hợp đồng tiên tri, trái phiếu bảo vệ chi tiêu gấp đôi và quan trọng hơn là cho phép xem xét nội tâm giao dịch. Nguyên tắc sử dụng CSFS để xem xét nội bộ giao dịch 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, thì cùng một khóa công khai và chữ ký sẽ được sử dụng để xác minh nội dung bằng cả CSFS và OP_CHECKSIG. Nếu cả hai đều vượt qua thành công. , thì nội dung của bất kỳ thông báo nào được chuyển tới CSFS đều giống với giao dịch chi tiêu được tuần tự hóa (và dữ liệu khác) được sử dụng ngầm cho OP_CHECKSIG. Chúng tôi đã xác minh dữ liệu giao dịch trên ngăn xếp và có thể áp dụng các mã hoạt động khác cho giới hạn giao dịch chi tiêu.
CSFS thường xuất hiện cùng với OP_CAT, vì OP_CAT có thể kết nối các trường giao dịch khác nhau để hoàn thành việc tuần tự hóa và có thể chọn chính xác hơn các trường giao dịch cần đượ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 hàm 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 hàm băm có bằng một giá trị cụ thể hay không, nghĩa là đồng xu chỉ có thể được chi tiêu thông qua một giao dịch cụ thể.
CSFS có thể triển khai CLTV, CSV, CTV, APO và các mã hoạt động khác. Đây là mã hoạt động nội tâm chung, vì vậy nó cũng có thể hỗ trợ kế hoạch mở rộng Lớp 2 của Bitcoin. Điểm bất lợi là cần phải thêm một bản sao hoàn chỉnh 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ô của các giao dịch mà bạn muốn xem xét nội tâm bằng CSFS. Để so sánh, các mã hoạt động xem xét nội tâm có mục đích đơn lẻ như CLTV và CSV sử dụng chi phí tối thiểu, nhưng việc thêm mỗi mã hoạt động xem xét nội tâm đặc biệt mới đòi hỏi phải có sự thay đổi đồng thuận.
TXHASH (OP_TXHASH)
OP_TXHASH là một opcode xem xét nội tại rất đơn giản cho phép người vận hành chọn hàm băm của một trường để đẩy vào ngăn xếp. Cụ thể, OP_TXHASH sẽ bật cờ txhash ra khỏi ngăn xếp, tính toán txhash (được gắn thẻ) dựa trên cờ đó và đẩy hàm băm kết quả vào 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à một bản nâng cấp chung cho CTV, cung cấp mẫu giao dịch nâng cao hơn cho phép người dùng chi tiêu một cách rõ ràng một phần của giao dịch, giải quyết nhiều vấn đề xung quanh 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 của dữ liệu cần thiết trong phần làm chứng, điều này làm giảm hơn nữa nhu 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; CSFS có thể được coi là giải pháp thay thế cho CTV và APO.
Từ góc độ cách xây dựng hợp đồng, TXHASH giúp việc triển khai "hợp đồng phụ" dễ dàng hơn bằng cách đẩy tất cả các phần của dữ liệu giao dịch mà bạn muốn sửa vào ngăn xếp, băm tất cả chúng lại với nhau và xác minh rằng hàm băm kết quả khớp với giá trị cố định; CTV Việc thực hiện "hợp đồng trừ" sẽ dễ dàng hơn, đẩy tất cả các phần của dữ liệu giao dịch mà bạn muốn giữ trống vào ngăn xếp. Sau đó, sử dụng OP_SHA256 cuộn để bắt đầu từ trạng thái trung gian cố định cam kết tiền tố của dữ liệu băm giao dịch. 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.
BIP liên quan đến TXHASH hiện đang ở trạng thái Dự thảo trên Github và chưa được đánh số.
OP_CAT
OP_CAT là một mã hoạt động khá bí ẩn. Nó đã bị Satoshi Nakamoto bỏ rơi do vấn đề bảo mật. Gần đây, nó đã gây ra một số lượng lớn các cuộc thảo luận giữa các nhà phát triển cốt lõi của Bitcoin và thậm chí còn gây ra văn hóa Meme trên Internet. BIP-347 và được nhiều người gọi là đề xuất BIP rất có thể sẽ được thông qua trong thời gian tới.
Trong thực tế, OP_CAT hoạt động 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?
Trên thực tế, chức năng ghép 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ỉ yêu cầu hai thao tác: nối và băm, và trong các tập lệnh Bitcoin đều có sẵn các hàm băm. Do đó, với OP_CAT, về mặt lý thuyết, chúng tôi có thể xác minh Merkle Proof trong tập lệnh Bitcoin, đây là phương pháp xác minh nhẹ được sử dụng phổ biến nhất trong chuỗi khối.
Như đã đề cập trước đó, CSFS, với sự trợ giúp của OP_CAT, có thể triển khai một sơ đồ hợp đồng chung. Trên thực tế, bản thân OP_CAT có thể thực hiện việc xem xét nội tâm giao dịch mà không cần 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 nhân chứng, sử dụng OP_CAT và OP_SHA256, chúng ta có thể tạo chữ ký Schnorr và kiểm tra nó bằng OP_CHECKSIG. Nếu quá trình xác minh thành công, dữ liệu giao dịch đã được xác minh sẽ được giữ lại trong ngăn xếp, cho phép xem xét nội bộ giao dịch, với khả năng 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 có liên quan.
Để biết các nguyên tắc mật mã cụ thể, vui lòng tham khảo bài viết Thủ thuật CAT và Schnorr do Andrew Poelstra xuất bản.
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 opcode hợp đồng và một số lượng lớn opcode hợp đồng dựa vào chức năng của OP_CAT, điều này khiến nó dẫn đầu đáng kể 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 ta 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 và Starknet, Chakra cũng như các đối tác sinh thái khác đang tích cực thúc đẩy điều này.
Phần kết luận
Khi chúng tôi khám phá nhiều chiến lược để mở rộng quy mô Bitcoin và tăng khả năng lập trình của nó, rõ ràng rằng con đường phía trước liên quan đến sự kết hợp của các cải tiến gốc, tính toán ngoài chuỗi và khả năng viết kịch bản phức tạp.
Nếu không có lớp nền linh hoạt, bạn không thể xây dựng lớp thứ hai linh hoạt hơn.
Việc mở rộng điện toán ngoài chuỗi là tương lai, nhưng phải có bước đột phá về khả năng lập trình trên Bitcoin để hỗ trợ tốt hơn cho việc mở rộng và trở thành một loại tiền tệ trong thế giới thực.
Tuy nhiên, các phép tính của Bitcoin và Ethereum thực sự khác nhau về cơ bản. 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ể được nhìn thấy ở một điểm: Ethereum tính phí dưới dạng Gas cho các giao dịch thất bại, trong khi Bitcoin thì không.
Hợp đồng thực hiện một hình thức 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, tất cả mọi người ngoại trừ một số ít người theo trào lưu chính thống của Satoshi dường như đều nghĩ 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 tiếp tục tranh luận về việc nên sử dụng phương pháp nào để thực hiện hợp đồng.
APO, OP_VAULT và TLUV thiên về các ứng dụng trực tiếp hơn và việc chọn chúng có thể triển khai các ứng dụng cụ thể theo cách rẻ hơn và hiệu quả hơn. Những người đam mê Lightning Network sẽ thích APO hơn vì nó có thể triển khai LN-Symmetry; nếu bạn muốn triển khai vault, tốt nhất nên sử dụng OP_VAULT để xây dựng CoinPool, sử dụng TLUV để có sự riêng tư và hiệu quả hơn. OP_CAT và TXHASH linh hoạt hơn và ít có khả năng có lỗ hổng bảo mật hơn. Bằng cách kết hợp với các opcode khác, tất nhiên có thể đạt được nhiều trường hợp sử dụng hơn nhưng lại phải trả giá bằng sự phức tạp của tập lệnh. CTV và CSFS đã thực hiện các điều chỉnh đối với quy trình 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 tương đối độc đáo, sử dụng các ý tưởng thực thi lạc quan và bằng chứng gian lận, đồng thời sử dụng cấu trúc của Merkle Trie để triển khai hợp đồng thông minh toàn cầu, nhưng nó vẫn cần các mã hoạt động mới để mang lại chức năng xem xét nội tâm.
Chúng tôi thấy rằng cộng đồng Bitcoin đã thảo luận sôi nổi về khả năng cho phép Bitcoin có được hợp đồng thông qua các fork mềm. Starknet chính thức tuyên bố gia nhập 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 các xu hướng mới nhất trong hệ sinh thái Bitcoin, thúc đẩy việc sáp nhập các nhánh mềm OP_CAT và sử dụng khả năng lập trình do nội tâm và hợp đồng mang lại để xây dựng lớp thanh toán Bitcoin an toàn và hiệu quả hơn.
Cảm ơn Jeffrey, Ben, Mutourend và Lynndell vì đã xem xét và đề xuất bài viết này
