Tác giả: Hiroki Gondo
Nguồn: https://medium.com/nayuta-engineering-blog-en/under Hiểu- taproot-assets-protocol-e2dfe3fc1e07
Giao thức Taproot Assets (trước đây gọi là "Taro", sau đây viết tắt là "TAP") là giao thức đại diện cho tài sản dựa trên UTXO trên Bitcoin . Bài viết này nhằm giải thích cách TAP tạo và chuyển giao tài sản.
Giao thức hoàn chỉnh được chia thành nhiều phần. Bài viết này chủ yếu giải thích bip-tap và bit-tap-ms-smt.
Việc triển khai của Lightning Labs có thể được tìm thấy ở đây .
Taproot là gì?
" Taproot " là một loại đầu ra Bitcoin mới cho phép chỉ định đồng thời hai loại điều kiện chi tiêu: Chi tiêu chính ( Key Path ) và Chi tiêu tập lệnh ( Script Path ).
Key Path , giống như đầu ra P2PKH truyền thống, được sử dụng bằng chữ ký khóa chung. Tập hợp khóa có chữ ký Schnorr (đa chữ ký) cũng có thể được sử dụng ở đây trong Taproot.
Script Path , giống như P2SH truyền thống, cho phép lập trình các điều kiện chi tiêu phức tạp bằng ngôn ngữ tập lệnh. Và Taproot cũng cho phép chỉ định nhiều tập lệnh cùng một lúc. Các tập lệnh này không được tuần tự hóa trực tiếp trong đầu ra Taproot mà được xây dựng dưới dạng Merkle trees và được nén thành hàm băm gốc. Khi đầu ra được sử dụng bằng cách sử dụng tập lệnh, chỉ tập lệnh đó cần được hiển thị (không hiển thị các tập lệnh khác).
TAP nhúng dữ liệu vào Script Pat ("Cây tài sản"). Dữ liệu này không thể giải thích được và không thể phát hiện được đối với nút Bitcoin vì nó đã được băm.
Đại diện tài sản trong Tài sản Taproot
Cây tài sản
Cây tài sản là cấu trúc "cây tổng Merkle thưa thớt" hai cấp thể hiện giao thức Taproot Assets. Cấp thấp hơn thể hiện UTXO của một tài sản(được xác định bởi " id tài sản( asset_id )"). Cấp trên tổng hợp cây từ cấp dưới.
Giá trị của giá trị băm gốc ( asset_tree_root) của Merkle trees cấp cao hơn sẽ được Taproot nhúng vào đầu ra Script Path , từ đó cam kết với trạng thái của cây.
Việc chuyển giao tài sản cũng tạo ra một cây tài sản mới và cây tài sản cũ được cập nhật. Điều này có thể được thực hiện bằng cách bắt đầu một giao dịch Bitcoin mới sử dụng đầu ra Taproot của cây tài sản cũ; các giao dịch chuyển tiền không đáp ứng các thông số kỹ thuật (ví dụ: lạm phát, các cuộc gọi trùng lặp) sẽ bị cho rằng không hợp lệ. *
* Phương pháp được sử dụng ở đây là một khái niệm gọi là " xác minh máy trạm "; độc giả quen thuộc với sự đồng thuận đáng chú ý của Bitcoin có thể tò mò về cơ sở cho tính đúng đắn của thông số kỹ thuật ở đây, nhưng bây giờ tôi sẽ bỏ qua vấn đề đó.
Cây tổng Merkle thưa thớt
"Cây tổng Merkle thưa thớt" (sau đây viết tắt là "MS-SMT") là một biến thể của Merkle trees, được xác định bởi bip-tap-ms-smt . Bởi vì khóa của nó là 256 bit nên nó có 2^256 lá. Hầu hết các lá đều trống rỗng.
Mỗi lá chứa một đại lượng và mỗi nút nhánh cam kết tổng số lượng được đại diện bởi các lá trên cây con của nó. Ngay cả khi không biết nội dung của cây con, tổng số chứa trong cây con có thể được biết đơn giản bằng cách kiểm tra các nút nhánh. Gốc cây hứa hẹn tổng số lượng được đại diện bởi tất cả các lá.
Cũng giống như Merkle trees thông thường, chỉ cần một cây được cắt tỉa có chứa các lá mục tiêu cũng có thể cung cấp bằng chứng cho thấy những lá mục tiêu này có trên cây (Merkle proof). Nhưng MS-SMT cũng hỗ trợ "không có bằng chứng". Điều này được thực hiện bằng một hạn chế: số lượng lá biểu thị một từ khóa không tồn tại phải được đặt rõ ràng thành một giá trị biểu thị sự không tồn tại của nó (None) (do đó, việc chứng minh sự tồn tại của "Không" cấu thành Một không chứa bằng chứng). Do đó, MS-SMT mặc định sẽ có 2^256 lá biểu thị "Không".
Lá tài sản(UTXO tài sản)
MS-MST cấp thấp hơn của cây tài sản có asset_script_key làm khóa và lá tài sản làm giá trị. Mỗi lá tài sản đại diện cho một UTXO của tài sản(để đơn giản, nó sẽ được biểu thị trực tiếp dưới dạng "UTXO"* bên dưới) và các thuộc tính sau (bao gồm thuộc tính tùy chọn) sẽ được tuần tự hóa dưới dạng Định dạng "type-length-value" .
* Không phải UTXO của Bitcoin haha.
-
taproot_asset_version -
asset_genesis -
asset_id -
asset_type -
amt -
lock_time -
relative_lock_time -
prev_asset_witnesses
-prev_asset_id
-asset_witness
-split_commitment_proof -
split_commitment -
asset_script_version -
asset_script_key -
asset_group_key -
canonical_universe
asset_genesis là lấy hình ảnh gốc của asset_id .
asset_script_key vừa là từ khóa cho lá tài sản vừa là khóa chung ở dạng Taproot (được xác định trong tap-vm độc lập với Bitcoin) và là điều kiện để chi tiêu UTXO được đại diện bởi lá tài sản đó.
Khi chi tiêu UTXO, trước tiên, điều kiện chi tiêu Bitcoin(bên ngoài) phải được đáp ứng, sau đó điều kiện chi tiêu TAP (nội bộ), được chỉ định bởi asset_script_key và asset_script_key phải được đáp ứng bởi prev_asset_id và asset_witness . Ví dụ: asset_witness là chữ ký của asset_script_key của UTXO đang được sử dụng.
Nếu UTXO được phân chia trong quá trình chuyển tài sản thì cũng cần phải có split_commitment và split_commitment_proof .
split_commitment là một MS-SMT đề cập đến tất cả các UTXO sau khi phân tách (theo nghĩa này, cây tài sản thực sự có ba cấp độ) và tổng giá trị trong thư mục gốc là tất cả số tiền đã được chuyển.
split_commitment_proof là bằng chứng Merkle của split_commitment , chứng minh sự tồn tại của sự phân chia.
Trong số tất cả các phần tách, chỉ có một phần sẽ có prev_asset_id , asset_witness và split_commitment . Tất cả các phần chia tách khác chỉ có split_commitment_proof . Tất cả các phân vùng đều chia sẻ prev_asset_id và asset_witness .
Tạo tài sản
Việc tạo tài sản yêu cầu nhúng cây tài sản mới chứa UTXO của tài sản mới vào đầu ra Taproot của giao dịch Bitcoin (giao dịch trở thành giao dịch ban đầu của tài sản). ID của tài sản( asset_id ) được xác định theo công thức sau.
asset_id := sha256(genesis_outpoint || sha256(asset_tag) || asset_meta_hash || output_index || asset_type) genesis_outpoint là đầu ra giao dịch trước đó được chi tiêu bởi giao dịch này và output_index là số chỉ mục chứa đầu ra của cây tài sản này. Điều này đảm bảo rằng asset_id là duy nhất trên toàn cầu.
Tài sản mới được tạo UTXO bỏ qua prev_asset_id và asset_witness .
Chuyển nhượng tài sản
Giống như Bitcoin UTXO, tài sản UTXO có thể được hợp nhất hoặc phân chia khi tài sản được chuyển nhượng. Nhưng hãy bắt đầu với một ví dụ đơn giản - không chia tách cũng không hợp nhất -*.
*Các giải thích sau đây đã được đơn giản hóa phần nào. Ví dụ: đầu ra thay đổi của giao dịch Bitcoin bị bỏ qua.
Alice có 10 tài sản nhất định, tất cả đều được chuyển cho Bob.
Alice tạo và phát sóng một giao dịch Bitcoin, chi tiêu đầu ra Taproot tại nơi chứa tài sản UTXO của cô ấy. Giao dịch này có hai đầu ra Taproot. Một đầu ra chứa cây tài sản mới, bao gồm UTXO mới sở hữu 10 tài sản nhất định và Bob có thể kiểm soát (ví dụ: sử dụng khóa Bitcoin của Bob). Đầu ra còn lại chứa một cây tài sản , được hình thành bằng cách loại bỏ các lá tài sản tương ứng khỏi cây tài sản ban đầu do Alice kiểm soát.
UTXO mới của Bob sử dụng prev_asset_id để lập chỉ mục cho UTXO đặt hàng trước của Alice. Trong asset_witness có chữ ký của lời mở đầu asset_script_key . Trong asset_script_key của UTXO mới này, có một khóa công khai mới do Bob đưa trước.
Bob cần xác minh rằng các điều kiện chi tiêu đã được đáp ứng và tài sản không bị thổi phồng sau khi chuyển khoản để xác nhận đã nhận được khoản thanh toán.
- Cây tài sản mới tạo của Bob có chứa UTXO mới đáp ứng các điều kiện chi tiêu không?
- UXTO đầu vào đã bị xóa khỏi cây tài sản cập nhật của Alice chưa?
- Có bất kỳ đầu ra Taproot nào khác trong giao dịch không? Chúng có chứa cây tài sản khác không? *
- vân vân.
Điều này đạt được bằng cách chứng minh/xác minh bằng chứng bao gồm/không bao gồm của MS-SMT cũng như bằng chứng và tiền ảnh do Taproot đưa ra.
* Nếu một UTXO khác được thêm vào một cây tài sản khác (không phải cây tài sản của Bob) và UTXO đầu vào cũng được chi tiêu thì nó sẽ cấu thành một khoản chi tiêu gấp đôi.
Hợp nhất UTXO
Alice có lần lượt 3 và 7 tài sản nhất định ở hai lá và cô ấy muốn chuyển tất cả chúng cho Bob.
Mỗi UTXO đầu vào có thể thuộc về một cây tài sản khác nhau hoặc một khóa khác ( asset_script_key ) trên cùng một cây tài sản. UTXO mới của Bob phải chứa prev_asset_id và asset_witness cho hai UTXO đã sử dụng này.
Tách UTXO
Alice có 7 tài sản nhất định và sẵn sàng chuyển 3 cho Bob. Do đó, Alice sẽ giữ 3 và Bob sẽ nhận được 7.
Thay đổi UTXO của Alice sẽ có prev_asset_id , asset_witness và split_commitment ; UTXO mới của Bot sẽ chỉ có split_commitment_proof *.
Tôi sẽ không giải thích cách hợp nhất và tách UTXO cùng một lúc.
* Điều này hơi khác so với thông số kỹ thuật , nhưng có vẻ như việc triển khai mới nhất đã thực hiện điều này.
Chuyển nhượng tài sản
Mặc dù không có khối lượng phía trước nhưng mỗi UTXO đầu vào phải được xác minh là hợp pháp trước khi có thể xác minh việc chuyển giao tài sản. Đối với mỗi UTXO đầu vào, phải chứng minh/xác minh rằng mọi giao dịch trên toàn bộ đường dẫn lưu thông từ giao dịch tạo tài sản đến đầu vào hiện tại đều được thực hiện chính xác.
Đường dẫn này là một biểu đồ phức tạp từ giao dịch gốc đến giao dịch mới nhất. Trong hình trên, đối với Tx A , tất cả các giao dịch màu xanh (giao dịch tổ tiên của nó) cần được xác minh; trong khi đối với Tx B , tất cả các giao dịch màu xanh và đỏ cần được xác minh. Đây là một thách thức đáng kể mở rộng vì lịch sử sẽ tăng trưởng theo cấp số nhân.
Ngoài ra, do các hình ảnh sơ bộ và bằng chứng cần thiết để xác minh không được công bố trên blockchain nên việc chuyển chúng giữa người gửi và người nhận tài sản cũng là một vấn đề.
Mở rộng
Lịch sử ngày càng tăng là một thách thức đáng kể mở rộng. Một số giải pháp đã được đề xuất, nhưng hỗ trợ cho Lightning Network là một trong những giải pháp hứa hẹn nhất. Các giao dịch ngoài Chuỗi không được thêm vào lịch sử.
Bộ giao thức này là mới và các thông số kỹ thuật chưa đầy đủ. Ví dụ, tôi đã chỉ ra vấn đề này trước đây.
