Pycardano: The Ultimate Course for Python and AI Developers

Bài 3.0: Lý Thuyết CIP-68 – Kỷ Nguyên Của Tài Sản Động (Dynamic Assets) Trên Cardano

Chào mừng các bạn đến với chuỗi series mới: Thực Chiến CIP-68 với PyCardano & Aiken! Trong thế giới blockchain, NFT và Token thường được biết đến là những tài sản tĩnh, không thể thay đổi sau khi được tạo ra. Nhưng điều gì sẽ xảy ra nếu bạn muốn tạo ra một thanh kiếm NFT trong game có thể tăng cấp (level up)? Hay một thẻ căn cước (DID) có thể cập nhật trạng thái xác minh?

Đó là lúc chúng ta cần đến CIP-68. Trong Bài 3.0 này, chúng ta sẽ đi sâu vào lý thuyết để hiểu tại sao CIP-68 ra đời và cách cơ chế nội tại của nó hoạt động trước khi bắt tay vào code.

1. Vấn đề của chuẩn NFT cũ (CIP-25)

Trước đây, chuẩn phổ biến nhất để đúc (mint) NFT trên Cardano là CIP-25. Với CIP-25, Metadata (dữ liệu mô tả NFT như tên, hình ảnh, thuộc tính) được gắn trực tiếp vào giao dịch đúc (Minting Transaction).

Vấn đề chết người của CIP-25:

Bất di bất dịch: Metadata nằm trong phần dữ liệu giao dịch. Khi giao dịch đã được đưa lên blockchain, nó là vĩnh viễn không thể thay đổi.
Không thể nâng cấp: Nếu thanh kiếm NFT của bạn ở level 1 (được ghi trong metadata lúc đúc), nó sẽ mãi mãi ở level 1. Muốn lên level 2, cách duy nhất là… đốt (burn) NFT cũ và đúc một NFT hoàn toàn mới. Điều này phá vỡ tính liên tục và trải nghiệm người dùng.
Smart Contract “bị mù”: Smart Contract trên Cardano không thể đọc được metadata của CIP-25 vì dữ liệu đó không nằm trong UTxO (không phải là Datum).

2. Giải pháp mang tên CIP-68 (Datum-Driven Assets)

Để giải quyết vấn đề trên, cộng đồng Cardano đã thông qua chuẩn CIP-68. Triết lý cốt lõi của CIP-68 cực kỳ thông minh: “Tách rời phần xác và phần hồn của Token”.

Thay vì nhét metadata vào giao dịch đúc, CIP-68 lưu trữ metadata bên trong Datum của một UTxO trên Smart Contract. Và để liên kết giữa người dùng và metadata này, CIP-68 yêu cầu đúc ra MỘT CẶP TOKEN (thay vì 1 token như trước đây).

Cấu Trúc Cặp Token (The Twin Tokens)

Mỗi khi đúc một tài sản CIP-68, hệ thống thực chất đúc ra 2 token đi liền với nhau (cùng chung Policy ID và phần lõi của Token Name):

User Token (Token của người dùng): * Đây là phần “xác” – thứ đại diện cho quyền sở hữu.
- Token này sẽ được gửi trực tiếp vào ví của người dùng.
- Người dùng có thể bán, gửi hoặc chuyển nhượng token này tự do.
Reference Token (Token Tham chiếu): * Đây là phần “hồn” – nơi chứa metadata.
- Token này KHÔNG gửi cho người dùng, mà bị khóa vĩnh viễn tại địa chỉ của một Smart Contract.
- Đi kèm với Token này là một Inline Datum chứa toàn bộ metadata (Tên, hình ảnh, level, thuộc tính,…).

3. Cách Hai Token Liên Kết Với Nhau (Prefix Mechanism)

Làm sao ví của người dùng (chứa User Token) hay các chợ NFT (như jpg.store) biết tìm metadata (Reference Token) ở đâu?

CIP-68 sử dụng một hệ thống Tiền tố (Prefix) ở phần đầu của Token Name (Tên Token). Hai token này có phần lõi tên hoàn toàn giống nhau, chỉ khác nhau ở tiền tố Hexadecimal (mã Hex).

Các Prefix chuẩn hóa:

(100) Reference Token: Bắt đầu bằng 000643b0
(222) User NFT: Bắt đầu bằng 000de140 (Dành cho NFT độc bản – Non-Fungible)
(333) User FT: Bắt đầu bằng 0014df10 (Dành cho Token thông thường – Fungible)

Ví dụ thực tế: Bạn muốn tạo một NFT có tên lõi là MySword. Khi chuyển sang Hex, MySword = 4d7953776f7264. Lúc đúc (Mint), hệ thống sẽ tạo ra 2 token:

Reference Token Name: 000643b0 + 4d7953776f7264 $\rightarrow$ Gửi vào Smart Contract kèm Datum.
User Token Name: 000de140 + 4d7953776f7264 $\rightarrow$ Gửi cho người dùng.

Bất kỳ dApp hay ví nào khi nhìn thấy User Token có prefix 222, nó sẽ tự động thay tiền tố thành 100, quét trên mạng lưới xem cái Reference Token đó đang nằm ở đâu, rồi đọc Datum của nó để hiển thị hình ảnh!

4. Vòng Đời Của Tài Sản CIP-68 (Mint, Update, Burn)

Để nắm rõ nguyên lý thực hành, chúng ta hãy xem xét vòng đời của một tài sản CIP-68 qua 3 giai đoạn: Đúc (Mint), Cập nhật (Update), và Đốt (Burn).

🛠️ Giai đoạn 1: Mint (Đúc tài sản)

Khi một tài sản CIP-68 được sinh ra, giao dịch đúc (Minting Transaction) phải thực hiện đồng thời các công việc sau:

Tạo Cặp Token: Mint ra một số lượng token bằng nhau cho cả User Token (Prefix 222) và Reference Token (Prefix 100).
Khởi tạo Metadata: Đóng gói các thông tin khởi đầu (ví dụ: Tên, Hình ảnh, Cấp độ 1) thành một cấu trúc Datum hợp lệ theo chuẩn CIP-68.
Phân bổ (Distribution): – Gửi Reference Token cùng với Inline Datum vừa tạo vào địa chỉ của Smart Contract.
- Gửi User Token về ví của người dùng. (Kết quả: Người dùng nhận được NFT, Smart Contract nắm giữ Metadata).

Giai đoạn 2: Update (Cập nhật Metadata)

Đây chính là sức mạnh cốt lõi của CIP-68, sử dụng cơ chế CKV (Continuing Key Validation):

Chi tiêu (Spend) UTxO: Người có quyền (thường là người giữ Admin Token hoặc đáp ứng một điều kiện logic trong game) tạo một giao dịch Spend để lấy UTxO chứa Reference Token ra khỏi Smart Contract.
Sửa đổi Datum: Kẻ tấn công có thể cố gắng sửa Datum thành thông tin rác, nhưng Validator (Smart Contract) sẽ can thiệp và kiểm tra logic (Ví dụ: Chỉ cho phép tăng cấp độ, không được đổi tên).
Trả về (Continuing Output): Giao dịch phải tạo ra một UTxO mới trả về đúng địa chỉ Smart Contract cũ, giữ nguyên Reference Token, nhưng đính kèm Datum đã được cập nhật (Ví dụ: Cấp độ 2). (Kết quả: Metadata được cập nhật. Người dùng mở ví ra sẽ lập tức thấy NFT của mình đã lên cấp mà không cần giao dịch gì).

Giai đoạn 3: Burn (Hủy bỏ tài sản)

Khi một tài sản không còn giá trị sử dụng, chúng ta có thể đốt nó để dọn dẹp blockchain và thu hồi lại lượng ADA bị khóa (minUTxO) ở cả ví và Smart Contract.

Thu thập Token: Giao dịch Burn phải lấy User Token từ ví người dùng và Reference Token từ Smart Contract.
Kiểm tra đồng bộ: Smart Contract thường được lập trình để bắt buộc: “Nếu anh muốn đốt Reference Token của tôi, anh phải chứng minh rằng anh cũng đang đốt User Token tương ứng”. Điều này ngăn chặn việc đốt mất phần “hồn” khiến User Token trong ví trở thành token rác (bị mù metadata).
Hủy bỏ (Mint với số lượng âm): Đưa cả 2 token vào trường Mint với số lượng âm (ví dụ: -1) để xóa chúng vĩnh viễn khỏi tổng cung. (Kết quả: Cả 2 Token biến mất, ADA bị khóa được trả về cho các bên).

Tổng Kết Bài 3.0

CIP-68 biến tài sản tĩnh thành tài sản động (Dynamic Assets).
Nó hoạt động dựa trên việc tách làm 2 Token: (222) User Token ở ví người dùng và (100) Reference Token bị khóa trên Smart Contract.
Metadata không còn bị chết cứng trong Transaction, mà được sống trong Datum của Smart Contract.
Quá trình Update sử dụng cơ chế Continuing Output (CKV) để thay đổi Datum mà không cần động đến ví của người dùng.
Quá trình Burn yêu cầu thiêu hủy đồng bộ cả cặp token để tránh để lại dữ liệu rác trên chuỗi.

Tiếp theo là gì? Lý thuyết nghe rất hấp dẫn rồi! Trong Bài 3, chúng ta sẽ xắn tay áo lên và viết Smart Contract CIP-68 bằng ngôn ngữ Aiken. Chúng ta sẽ định nghĩa cấu trúc Datum tiêu chuẩn của CIP-68 và viết logic Validator để xử lý toàn bộ quy trình Mint, Update và Burn này.

Hẹn gặp lại các bạn ở Bài 3!
Chi tiết nội source code của bài học các bạn có thể theo dõi tại đây!!!!

CIP-68 Dynamic NFT Implementation