Đây là Phần 5 trong loạt bài kỹ thuật về giao ước Bitcoin của Cointelegraph Research. Nhấp vào đây để đọc bài viết trước. 

MATT (Merkleize All The Things) là một khuôn khổ hợp đồng thông minh dành cho Bitcoin, cho phép tạo hợp đồng có trạng thái và bằng chứng gian lận có khả năng mở rộng. Hợp đồng có trạng thái lưu giữ thông tin qua nhiều giao dịch và có thể cập nhật thông tin này khi hợp đồng phát triển. Các tập lệnh Bitcoin tiêu chuẩn không hỗ trợ khả năng này vì mỗi giao dịch được đánh giá độc lập, không ghi nhớ những lần thực thi trước đó.

Mọi đề xuất covenant đều cho phép UTXO mang trạng thái ở một mức độ nào đó, như được minh họa bởi các ngôn ngữ lập trình kịch bản như Sapio, vốn được xây dựng dựa trên OP_CTV. Cơ chế này dùng địa chỉ để biểu diễn một máy trạng thái hữu hạn, trong đó các giao dịch đóng vai trò là những chuyển đổi trạng thái. Tuy nhiên, mô hình này không có cách nào triển khai logic số học một cách gọn gàng; MATT giải quyết khoảng trống đó, đặc biệt là thông qua cách triển khai được đề xuất bằng OP_CCV. Vì MATT cho phép tính toán dữ liệu đã cam kết tại thời điểm chi tiêu rồi nhúng dữ liệu đó vào đầu ra tiếp theo, mỗi lần chi tiêu có thể tạo ra trạng thái mới một cách linh hoạt thay vì lựa chọn từ một tập trạng thái định trước. 

Cách OP_CCV cam kết trạng thái vào khóa Taproot

Để hiểu đề xuất MATT, trước tiên cần xem lại cách Taproot cam kết dữ liệu thông qua khóa công khai. Mỗi đầu ra Taproot đều chứa một khóa công khai cơ sở, gọi là khóa nội bộ, có thể được biến đổi bằng mật mã, hay còn gọi là “tweak”, để cam kết thêm thông tin. Về mặt hình thức, khóa công khai sau khi tweak là Q = P + t·G, trong đó P là khóa nội bộ, G là điểm sinh của đường cong elliptic secp256k1, còn t là giá trị băm có gắn thẻ của P và dữ liệu được cam kết. 

Trong một đầu ra Taproot thông thường, cam kết này thường mã hóa gốc Merkle của một cây taptree, chứa các đường dẫn chi tiêu ẩn. MATT mở rộng cơ chế này để nhúng cả trạng thái hợp đồng vào khóa. Thay vì nhúng trực tiếp logic phức tạp vào ngôn ngữ lập trình kịch bản của Bitcoin, MATT mã hóa phép tính thành một chuỗi các cam kết trạng thái, còn mạng lưới chỉ xác minh rằng mỗi lần chuyển đổi trạng thái đều hợp lệ.

MATT có thể được hiện thực hóa bằng nhiều tổ hợp opcode khác nhau. Cách triển khai trực tiếp nhất và được đặc tả đầy đủ nhất dựa trên OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV cung cấp phép toán cơ bản giúp UTXO mang trạng thái khả thi trong Taproot.  OP_CCV cho phép một script xác minh rằng khóa đầu vào hoặc đầu ra Taproot đã được tweak để cam kết một phần dữ liệu trạng thái cụ thể. Trước tiên, khóa nội bộ được tweak bằng giá trị băm của trạng thái hiện tại của hợp đồng, sau đó áp dụng thêm phép tweak taptree tiêu chuẩn của Taproot. Vì vậy, khóa đầu ra thu được cam kết cả tapscript (tập hợp các điều kiện chi tiêu) lẫn trạng thái hiện tại của hợp đồng.

Sau đó, OP_CCV có thể áp đặt trạng thái nào được chuyển tiếp sang đầu ra tiếp theo. Opcode này cho phép script kiểm tra dữ liệu trạng thái được cung cấp trên ngăn xếp witness, thực hiện phép tính trên dữ liệu đó và yêu cầu trạng thái cập nhật thu được phải được cam kết chính xác trong một đầu ra được chỉ định. Đây là cách các lần chuyển đổi trạng thái được thực thi trên chuỗi. Định dạng ngăn xếp là:

<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY

Opcode này hỗ trợ ba chế độ kiểm tra đầu ra cùng với một chế độ riêng để kiểm tra đầu vào. Ở chế độ mặc định, toàn bộ giá trị BTC của UTXO đầu vào được phân bổ cho đầu ra được chỉ định; ở chế độ khấu trừ, chỉ một phần có giá trị bằng số tiền của đầu ra được phân bổ, phần còn lại có thể dùng cho các đầu ra khác; còn ở chế độ bỏ qua, script và cam kết dữ liệu được xác minh mà không ràng buộc số tiền.  Vì chế độ mặc định và chế độ khấu trừ được thiết kế để bảo toàn giá trị qua các đầu ra được kiểm tra, phí giao dịch phải được thanh toán bằng các đầu vào riêng dùng để trả phí. Có thể thêm một đầu vào chuyên dùng trả phí và một đầu ra tiền thừa vào giao dịch mà không xung đột với các ràng buộc của covenant. Điều này ngăn việc vô tình đốt tiền, vốn có thể xảy ra với các cách triển khai covenant sơ khai hơn như OP_CTV hoặc SIGHASH_ANYPREVOUT. Cơ chế này cũng khắc phục một hạn chế lớn của covenant kiểu giao dịch ký sẵn: chúng thường ấn định số tiền từ trước nên không thể đáp ứng việc điều chỉnh phí linh hoạt hoặc mở khóa một phần.

OP_CCV + OP_CAT: Bằng chứng Merkle và bằng chứng gian lận

Khi kết hợp OP_CCV với OP_CAT, khuôn khổ MATT trở nên linh hoạt hơn nữa. OP_CAT cho phép nối các byte trong Script, nhờ đó có thể tạo và xác minh bằng chứng Merkle trực tiếp trên chuỗi. Trong cấu trúc như vậy, một đầu ra Taproot gắn với hai cây Merkle riêng biệt. Cây thứ nhất là cây script Taproot quen thuộc (taptree), có các lá là những script chi tiêu của hợp đồng. Cây thứ hai là một cây trạng thái riêng, có các lá là dữ liệu của hợp đồng, chẳng hạn như các bước trung gian của một phép tính.  Script OP_CCV + OP_CAT có thể xác minh bằng chứng Merkle dựa trên gốc cây trạng thái hiện tại, tính gốc đã cập nhật sau một lần chuyển trạng thái và dùng OP_CCV để buộc đầu ra tiếp theo phải cam kết gốc đó. 

Cấu trúc này cho phép xây dựng các hệ thống bằng chứng gian lận có điều kiện phạt, trong đó một phép tính dài được cam kết ngoài chuỗi và chỉ cần tiết lộ, xác minh trên chuỗi bước cụ thể đang bị tranh chấp (cùng với đường dẫn của bước đó trong cây nhị phân). Các hệ thống tương tự tồn tại dưới dạng rollup lạc quan trên những blockchain khác: toàn bộ phép tính diễn ra ngoài chuỗi, còn hợp đồng trên chuỗi chỉ can thiệp khi có người đưa ra khiếu nại. Bằng chứng gian lận đòi hỏi phép tính phải được biên dịch thành một mạch nhị phân hoặc dạng biểu diễn tương đương theo từng bước, có thể được cam kết trong cây Merkle. OP_CCV + OP_CAT sẽ loại bỏ nhu cầu dùng chữ ký một lần Lamport và đồ thị giao dịch ký sẵn mà BitVM dựa vào để đảm bảo tính nhất quán của trạng thái.

Ngoài bằng chứng gian lận, sự kết hợp OP_CCV và OP_CAT còn có ý nghĩa đối với vault. Chỉ riêng OP_CCV đã có thể triển khai vault, nhưng khi kết hợp với OP_CAT, nó cho phép tạo vault đầy đủ tính năng, về cơ bản tương đương với chức năng được đề xuất cho OP_VAULT. Như James O’Beirne, tác giả của OP_VAULT, đã lưu ý, OP_CCV là một thiết kế tổng quát và vững chắc hơn, về thực chất thay thế đề xuất trước đây của ông.

Trong bài tiếp theo của loạt bài này, chúng ta sẽ chuyển từ các đề xuất covenant tổng quát sang xem xét những opcode dành riêng cho từng ứng dụng như OP_VAULT, OP_UNVAULT và OP_EVICT. Mỗi opcode được thiết kế để giải quyết một vấn đề cụ thể thay vì cung cấp khả năng lập trình đa dụng.

Tạp chí: Những người nắm giữ Bitcoin đã nhận được eCash — Bạn có thể làm gì với số eCash đó?