Lược đồ metadata token

Lược đồ metadata token là gì?

Lược đồ metadata token là một định dạng có cấu trúc, quy định cách thông tin về token tiền mã hóa được viết, lưu trữ và đọc bởi ví, dApp, trình khám phá blockchain, marketplace, trò chơi và công cụ lập chỉ mục.

Trong hầu hết các cuộc thảo luận về crypto, Token Metadata Schema đề cập đến cấu trúc JSON dùng để mô tả NFT và các tài sản token hóa khác.

Lược đồ này cho ứng dụng biết các trường dữ liệu cần có, chẳng hạn như

, , , và các liên kết media.

Hợp đồng token có thể lưu quyền sở hữu on-chain, trong khi metadata được lưu thông qua một URI trỏ đến tệp JSON.

Tiêu chuẩn ERC-721 chính thức nêu rằng URI token có thể trỏ đến một tệp JSON tuân thủ ERC-721 Metadata JSON Schema.

Tiêu chuẩn ERC-1155 chính thức xác định ERC-1155 Metadata URI JSON Schema dành cho hợp đồng đa token.

Lược đồ metadata quan trọng vì nó giúp các ứng dụng khác nhau hiển thị cùng một token một cách nhất quán.

Nếu không có lược đồ, mỗi dự án có thể đặt tên trường khác nhau, khiến ví khó xác định giá trị nào là hình ảnh, giá trị nào là mô tả và giá trị nào thể hiện các thuộc tính.

Với người mới, cách dễ nhất để hiểu Token Metadata Schema là xem nó như định dạng nhãn cho một tài sản tiền mã hóa.

Blockchain chứng minh token tồn tại và ai sở hữu token, còn lược đồ metadata giải thích token đó đại diện cho điều gì.

Vì sao Token Metadata Schema quan trọng trong crypto?

Token Metadata Schema quan trọng vì người dùng không chỉ tương tác với các Token ID thô.

Họ tương tác với hình ảnh, tên, mô tả, thuộc tính, cấp độ, huy hiệu, thông tin độ hiếm, nội dung có thể mở khóa và các chi tiết khác mà con người có thể đọc.

Ví chỉ có thể hiển thị token chính xác khi biết cách đọc metadata.

Trò chơi chỉ có thể hiển thị vật phẩm chính xác khi hiểu các trường thuộc tính và media của vật phẩm đó.

Marketplace chỉ có thể lọc bộ sưu tập chính xác khi các thuộc tính được cấu trúc theo cách có thể dự đoán.

Giao thức cho vay chấp nhận NFT làm tài sản thế chấp có thể cần thông tin chính xác về bộ sưu tập, thuộc tính và media để hỗ trợ quy trình định giá.

Nền tảng tài sản trong thế giới thực có thể cần các trường metadata tham chiếu tài liệu, tổ chức phát hành, thẩm định, điều khoản pháp lý hoặc trạng thái xác minh.

Ứng dụng token-gated có thể cần metadata để xác minh liệu token có cấp quyền truy cập vào một cấp độ thành viên nhất định hay không.

Khi metadata được cấu trúc rõ ràng, ứng dụng có thể tự động đọc dữ liệu đó.

Khi metadata lộn xộn hoặc thiếu nhất quán, người dùng có thể thấy hình ảnh bị lỗi, thiếu thuộc tính, tên không chính xác hoặc thông tin tài sản lỗi thời.

Đây là lý do thiết kế lược đồ metadata là một phần của trải nghiệm người dùng crypto, không chỉ là chi tiết dành cho nhà phát triển.

Token Metadata Schema và Token URI

Token URI là liên kết hoặc mã định danh trỏ đến metadata token.

Token Metadata Schema là cấu trúc của dữ liệu tại liên kết đó hoặc trong phản hồi được mã hóa đó.

Ví dụ, hợp đồng ERC-721 có thể trả về

từ .

Tệp JSON tại URI đó nên tuân theo lược đồ metadata để ví có thể hiểu được.

Token URI là địa chỉ của metadata.

Token Metadata Schema là định dạng của metadata.

Sự khác biệt này quan trọng vì URI hoạt động vẫn chưa đủ nếu JSON bên trong URI không hợp lệ hoặc khó hiểu.

Token có thể có tệp metadata truy cập được nhưng vẫn hiển thị sai nếu các trường bị thiếu hoặc được đặt tên không theo tiêu chuẩn.

Token cũng có thể có lược đồ chính xác nhưng không tải được nếu URI trỏ đến nơi lưu trữ không khả dụng.

Thiết kế NFT tốt cần cả Token URI đáng tin cậy và Token Metadata Schema rõ ràng.

Token Metadata Schema trong ERC-721

ERC-721 là tiêu chuẩn phổ biến cho NFT độc nhất trên các mạng theo phong cách Ethereum.

Phần mở rộng metadata ERC-721 bao gồm

, và .

Tiêu chuẩn ERC-721 mô tả metadata bằng một lược đồ JSON đơn giản, có thể gồm các trường như

, và .

Cấu trúc đơn giản này giúp NFT dễ hiển thị hơn trên ví và các ứng dụng.

Token ERC-721 có thể đại diện cho nghệ thuật kỹ thuật số, vật phẩm trò chơi, thẻ thành viên, chứng chỉ, đất ảo, huy hiệu danh tính hoặc hồ sơ tài sản trong thế giới thực.

Mỗi Token ID có thể có tệp metadata riêng.

Điều này có nghĩa Token ID 1 có thể có hình ảnh, tên và thuộc tính khác với Token ID 2.

Lược đồ giúp client hiểu trường nào mô tả mỗi token độc nhất.

Nhà phát triển thường mở rộng mẫu metadata ERC-721 cơ bản bằng các trường bổ sung cho thuộc tính, media, hoạt ảnh, độ hiếm, giấy phép hoặc dữ liệu riêng của dự án.

Các phần mở rộng này có thể hữu ích, nhưng các trường cốt lõi nên rõ ràng và tương thích với công cụ Web3 phổ biến.

Token Metadata Schema trong ERC-1155

ERC-1155 là tiêu chuẩn đa token, có thể quản lý token có thể thay thế, bán có thể thay thế và không thể thay thế trong cùng một hợp đồng.

Lược đồ metadata ERC-1155 đặc biệt quan trọng vì một hợp đồng có thể chứa nhiều Token ID mang ý nghĩa khác nhau.

Một hợp đồng ERC-1155 có thể đại diện cho coin trong game, vũ khí, áo giáp, vé, huy hiệu, phiên bản giới hạn và vật phẩm sưu tầm độc nhất.

Tiêu chuẩn ERC-1155 cho phép URI chứa placeholder

.

Phần mềm client thay thế

bằng Token ID thực tế trước khi lấy metadata.

Tài liệu OpenZeppelin ERC-1155 Metadata URI chính thức giải thích rằng phần mở rộng metadata URI trỏ mỗi token đến một tệp JSON tuân theo ERC-1155 Metadata URI JSON Schema.

Metadata ERC-1155 có thể gồm các trường như

, , , và dữ liệu riêng khác của token.

Lược đồ giúp ví và dApp hiển thị nhiều loại tài sản từ một hợp đồng mà không cần logic tùy chỉnh cho từng Token ID.

Metadata ERC-1155 phải được xử lý cẩn thận vì việc thay thế ID sai có thể gây hiển thị lỗi hoặc không chính xác.

Thiết kế metadata ERC-1155 tốt giúp mỗi Token ID dễ diễn giải và truy xuất một cách đáng tin cậy.

Các trường phổ biến trong Token Metadata Schema

Trường phổ biến nhất là

, cung cấp tiêu đề mà con người có thể đọc cho token.

Trường phổ biến tiếp theo là

, giải thích token đại diện cho điều gì.

Trường

thường trỏ đến hình ảnh chính được hiển thị trong ví và marketplace.

Trường

có thể trỏ đến media phong phú hơn như video, âm thanh, đối tượng 3D hoặc nội dung tương tác nếu client hỗ trợ.

Trường

có thể trỏ đến trang chính thức có thêm thông tin về token hoặc bộ sưu tập.

Trường

thường chứa mảng đối tượng thuộc tính dùng cho độ hiếm, lọc, chỉ số game và tổ chức bộ sưu tập.

Trường

đôi khi được dùng để đề xuất màu nền hiển thị cho tài sản.

Trường

thường được dùng cho metadata theo kiểu ERC-1155 hoặc thông tin có cấu trúc riêng của dự án.

Một số dự án thêm các trường như

, , , hoặc .

Các trường tùy chỉnh có thể hữu ích, nhưng nên được tài liệu hóa để ứng dụng có thể diễn giải chính xác.

Ví dụ về lược đồ metadata NFT cơ bản

Một tệp metadata NFT đơn giản thường là đối tượng JSON với một số trường rõ ràng.

Ví dụ này cho thấy tên dễ đọc, mô tả, tham chiếu hình ảnh và hai thuộc tính.

Lược đồ đủ đơn giản để ví và dApp phân tích.

Hình ảnh sử dụng URI theo kiểu IPFS, nghĩa là media được tham chiếu thông qua hệ thống lưu trữ định địa chỉ theo nội dung.

Các thuộc tính được cấu trúc dưới dạng mảng, giúp việc xây dựng công cụ lọc và độ hiếm dễ hơn.

Dự án có thể thêm nhiều trường hơn, nhưng nên tránh sự phức tạp không cần thiết làm giảm khả năng tương thích.

Metadata tốt vừa máy có thể đọc vừa dễ hiểu với con người.

Trường Name

Trường

cung cấp tiêu đề hiển thị cho token.

Với bộ sưu tập NFT, một mẫu phổ biến là sử dụng tên bộ sưu tập và số token.

Một ví dụ là

.

Vật phẩm game có thể dùng tên như

hoặc .

Token thành viên có thể dùng tên như

.

Tên nên ổn định, rõ ràng và không gây hiểu lầm.

Bộ sưu tập giả có thể sao chép tên của dự án thật, vì vậy người dùng không bao giờ nên chỉ dựa vào trường tên.

Địa chỉ hợp đồng chính thức quan trọng hơn tên được hiển thị.

Nhà phát triển nên tránh thay đổi tên bất ngờ, trừ khi token được thiết kế là động.

Trường tên tốt giúp dễ nhận diện nhưng không giả vờ chứng minh tính xác thực.

Trường Description

Trường

giải thích token đại diện cho điều gì.

Mô tả rõ ràng giúp người dùng hiểu mục đích, câu chuyện, tiện ích hoặc vai trò thành viên của tài sản.

Với NFT nghệ thuật, mô tả có thể giải thích ý tưởng hoặc chủ đề bộ sưu tập.

Với vật phẩm game, mô tả có thể giải thích cách sử dụng vật phẩm.

Với token tài sản trong thế giới thực, mô tả có thể tóm tắt loại tài sản đồng thời dẫn người dùng đến tài liệu pháp lý ở nơi khác.

Mô tả không nên chứa các tuyên bố gây hiểu lầm về giá trị, lợi nhuận được đảm bảo hoặc trạng thái chính thức.

Ví và dApp có thể hiển thị trực tiếp mô tả cho người dùng, vì vậy liên kết không an toàn hoặc thông điệp lừa đảo có thể tạo ra rủi ro phishing.

Nhà phát triển nên duy trì mô tả hữu ích và trung thực.

Người dùng nên nhớ rằng mô tả do người tạo token hoặc bên kiểm soát metadata cung cấp.

Mô tả không phải là sự xác minh độc lập về chất lượng hoặc tính hợp pháp của token.

Trường Image

Trường

trỏ đến tệp media chính được hiển thị cho token.

Trường này có thể trỏ đến PNG, JPG, GIF, SVG hoặc định dạng hình ảnh được hỗ trợ khác tùy ứng dụng.

Hình ảnh có thể được lưu trên IPFS, Arweave, máy chủ HTTPS hoặc mã hóa trực tiếp trong metadata.

Trường hình ảnh quan trọng vì nhiều người dùng nhận diện NFT bằng hình ảnh.

Liên kết hình ảnh lỗi có thể khiến token trông không hoàn chỉnh dù quyền sở hữu on-chain vẫn hợp lệ.

Hình ảnh gây hiểu lầm có thể khiến token giả trông có vẻ hợp pháp.

URL hình ảnh tập trung có thể biến mất nếu máy chủ hoặc tên miền gặp sự cố.

URI hình ảnh định địa chỉ theo nội dung có thể cải thiện tính toàn vẹn, nhưng nội dung vẫn cần được cung cấp qua lưu trữ hoặc pinning.

Nhà phát triển nên sử dụng giải pháp lưu trữ hình ảnh bền vững cho tài sản dài hạn.

Người dùng nên kiểm tra chất lượng lưu trữ hình ảnh trước khi tin tưởng NFT có giá trị cao.

Trường Attributes

Trường

thường được dùng để mô tả thuộc tính, độ hiếm, đặc điểm game, cấp độ, trạng thái hoặc các tính năng có cấu trúc khác.

Mỗi thuộc tính thường là một đối tượng có

và .

Ví dụ,

có thể là và có thể là .

Với vật phẩm game,

có thể là và có thể là .

Cấu trúc thuộc tính quan trọng vì marketplace và công cụ phân tích dùng dữ liệu này để lọc và xếp hạng độ hiếm.

Thuộc tính không nhất quán có thể làm công cụ độ hiếm thiếu chính xác.

Tên thuộc tính bị viết sai có thể chia một danh mục đáng lẽ thống nhất thành nhiều danh mục.

Thuộc tính dạng số nên được định dạng nhất quán để công cụ có thể so sánh chính xác.

NFT động nên nêu rõ liệu thuộc tính có thể thay đổi theo thời gian hay không.

Thuộc tính tốt giúp người dùng hiểu danh tính và tiện ích của token.

Trường Properties

Trường

thường được dùng để lưu metadata có cấu trúc ngoài dữ liệu cơ bản về tên, mô tả và hình ảnh.

Các ví dụ metadata ERC-1155 thường dùng

cho thông tin token bổ sung.

Vật phẩm game có thể gồm các properties như độ hiếm, lớp, độ bền hoặc nguyên liệu chế tạo.

Token vé có thể gồm các properties như ngày sự kiện, hạng ghế, địa điểm và loại quyền truy cập.

Token tài sản trong thế giới thực có thể gồm các properties như loại tài sản, tham chiếu tổ chức phát hành, khu vực pháp lý, hash tài liệu hoặc trạng thái xác minh.

Properties có thể mạnh mẽ vì cho phép mô hình dữ liệu phong phú hơn.

Chúng cũng có thể trở nên lộn xộn nếu mọi dự án dùng tên và định dạng khác nhau mà không có tài liệu.

Nhà phát triển nên giữ tên property ổn định và có thể dự đoán.

Ứng dụng nên coi properties là dữ liệu chưa đáng tin cậy cho đến khi được xác minh bởi logic hợp đồng hoặc nguồn đáng tin cậy.

Trường property có thể mô tả tài sản, nhưng không tự động chứng minh tuyên bố đó là đúng.

Token Metadata Schema và IPFS

IPFS thường được dùng để lưu metadata token và tệp media.

Tài liệu định địa chỉ theo nội dung IPFS chính thức giải thích rằng IPFS dùng Content Identifier, hay CID, để tham chiếu dữ liệu dựa trên chính nội dung đó.

Điều này hữu ích với metadata vì CID có thể cho thấy nội dung được tham chiếu có thay đổi hay không.

Nếu metadata JSON thay đổi, CID cũng phải thay đổi.

Điều này mang lại tính toàn vẹn cao hơn URL máy chủ thông thường, vốn có thể thay đổi nội dung tại cùng một địa chỉ.

Tuy nhiên, IPFS không tự động đảm bảo tính khả dụng vĩnh viễn.

Các tệp metadata và hình ảnh cần được pin hoặc được node phục vụ để client có thể truy xuất.

Lược đồ metadata lưu trên IPFS vẫn có thể lỗi nếu không có ai duy trì khả năng truy cập nội dung.

Nhà phát triển nên lập kế hoạch pinning và lưu trữ dài hạn trước khi mint token.

Người dùng nên hiểu định địa chỉ theo nội dung cải thiện tính toàn vẹn, nhưng khả năng truy cập vẫn cần hạ tầng lưu trữ hỗ trợ.

Token Metadata Schema và lưu trữ HTTP

Một số dự án lưu metadata trên máy chủ HTTPS tiêu chuẩn.

Cách này có thể giúp metadata dễ cập nhật, tạo và phục vụ nhanh.

Phương thức này phổ biến với NFT động, tài sản game, cơ chế reveal và tài sản phụ thuộc vào hệ thống backend đang hoạt động.

Nhược điểm là metadata HTTP phụ thuộc vào thời gian hoạt động của máy chủ, quyền kiểm soát tên miền, bảo mật hosting và hoạt động của dự án.

Nếu máy chủ ngừng hoạt động, metadata token có thể biến mất khỏi giao diện người dùng.

Nếu tên miền hết hạn, endpoint metadata có thể không an toàn hoặc không khả dụng.

Nếu nhà vận hành máy chủ thay đổi JSON, người dùng có thể thấy nội dung khác mà không có thay đổi on-chain.

Metadata HTTP không tự động là xấu, nhưng cần được công bố rõ ràng.

Nhà phát triển nên giải thích metadata có thể thay đổi hay không và lưu trữ được duy trì trong bao lâu.

Người dùng nên cẩn trọng hơn với tài sản giá trị cao phụ thuộc hoàn toàn vào máy chủ metadata tập trung.

Token Metadata Schema và metadata on-chain

Metadata on-chain nghĩa là metadata token được lưu trữ hoặc tạo trực tiếp bởi hợp đồng thông minh.

Cách này có thể giảm sự phụ thuộc vào hệ thống lưu trữ bên ngoài.

Hợp đồng có thể trả về URI

chứa metadata đã được mã hóa.

Metadata có thể gồm hình ảnh SVG on-chain hoặc logic nghệ thuật tạo sinh.

Metadata on-chain có thể tăng độ bền vững vì dữ liệu gắn với trạng thái blockchain.

Cách này cũng có thể tốn kém hơn vì lưu trữ và tạo dữ liệu on-chain tiêu tốn tài nguyên.

Metadata on-chain có thể khó thay đổi hơn, hữu ích cho tính lâu dài nhưng ít phù hợp hơn với game hoặc thông tin xác thực động.

Nhà phát triển nên chọn metadata on-chain khi tính lâu dài và giảm thiểu yêu cầu tin cậy quan trọng hơn tính linh hoạt.

Người dùng vẫn nên kiểm tra logic hợp đồng vì metadata on-chain cũng có thể là động nếu hợp đồng cho phép.

Metadata on-chain là mô hình lưu trữ, không phải sự đảm bảo tự động về chất lượng.

Token Metadata Schema và NFT động

NFT động là token có metadata có thể thay đổi theo sự kiện, thời gian, hoạt động trong game, dữ liệu oracle, quyết định quản trị hoặc hành động của người dùng.

Metadata động có thể giúp NFT hữu ích và tương tác hơn.

Nhân vật game có thể tăng cấp.

Thẻ thành viên có thể chuyển từ hoạt động sang hết hạn.

Thông tin xác thực có thể được cập nhật sau khi người dùng hoàn thành thành tích mới.

Token tài sản trong thế giới thực có thể cập nhật trạng thái xác minh hoặc tham chiếu tài liệu.

Lược đồ metadata nên thể hiện rõ các trường động.

Người dùng nên biết trường nào có thể thay đổi và ai kiểm soát các thay đổi đó.

NFT động không nên che giấu quyền kiểm soát tùy ý của admin sau ngôn ngữ metadata mơ hồ.

Metadata động tốt có thể dự đoán, được tài liệu hóa và gắn với hành vi token có ý nghĩa.

Token Metadata Schema và cập nhật metadata

Cập nhật metadata phổ biến trong các đợt reveal, quá trình phát triển trong game, xác minh tài sản và sửa lỗi.

Phần mở rộng cập nhật metadata ERC-4906 chính thức xác định các sự kiện thông báo cho client khi metadata NFT thay đổi.

Điều này quan trọng vì ví và indexer thường lưu cache metadata để tăng tốc.

Nếu metadata thay đổi nhưng không phát tín hiệu cập nhật, người dùng có thể tiếp tục thấy thông tin cũ.

Lược đồ metadata nên đi kèm hành vi cập nhật rõ ràng.

Với reveal, dự án nên giải thích khi nào metadata placeholder sẽ đổi thành metadata cuối cùng.

Với tài sản động, dự án nên giải thích sự kiện nào kích hoạt thay đổi metadata.

Với cập nhật do admin kiểm soát, dự án nên công bố ai có thể thay đổi metadata và trong điều kiện nào.

Cập nhật metadata minh bạch xây dựng niềm tin.

Cập nhật metadata ẩn tạo ra sự không chắc chắn và có thể làm tổn hại giá trị token.

Token Metadata Schema và metadata cấp hợp đồng

Metadata cấp token mô tả một Token ID cụ thể.

Metadata cấp hợp đồng mô tả toàn bộ hợp đồng hoặc bộ sưu tập.

Tiêu chuẩn metadata cấp hợp đồng ERC-7572 chính thức chuẩn hóa

cho thông tin phong phú cấp hợp đồng như tên, mô tả và hình ảnh.

Điều này hữu ích vì bộ sưu tập có thể cần logo, banner, mô tả, thông tin phí, liên kết mạng xã hội hoặc hình ảnh cấp dự án.

Một NFT trong bộ sưu tập có thể có Token Metadata Schema riêng, trong khi bộ sưu tập cũng có lược đồ metadata cấp hợp đồng.

Cả hai lớp đều quan trọng đối với trải nghiệm người dùng.

Nếu metadata token đúng nhưng metadata bộ sưu tập sai, người dùng vẫn có thể thấy thông tin khó hiểu.

Nếu metadata bộ sưu tập đúng nhưng metadata token lỗi, các token riêng lẻ có thể không hiển thị chính xác.

Nhà phát triển nên hỗ trợ cả metadata cấp token và cấp hợp đồng khi phù hợp.

Người dùng nên hiểu đây là các lớp metadata liên quan nhưng khác nhau.

Token Metadata Schema và ERC-1046

ERC-1046 mở rộng ý tưởng Token URI vượt ra ngoài các trường hợp sử dụng NFT cơ bản.

Đề xuất khả năng tương tác tokenURI ERC-1046 chính thức bổ sung hỗ trợ token URI cho ERC-20 và mở rộng khả năng tương tác metadata giữa các loại token.

Điều này quan trọng vì token có thể thay thế cũng có thể cần metadata.

Token có thể thay thế có thể cần logo, mô tả, thông tin tổ chức phát hành, liên kết chính thức, ghi chú tuân thủ hoặc tham chiếu tài liệu.

Metadata được chuẩn hóa giúp ví và ứng dụng trình bày token có thể thay thế rõ ràng hơn.

Tuy nhiên, người dùng không nên coi các trường metadata là bằng chứng về tính hợp pháp.

Token lừa đảo vẫn có thể cung cấp logo và mô tả đẹp mắt.

Địa chỉ hợp đồng, tổ chức phát hành, thanh khoản, bảo mật, tokenomics và nguồn chính thức vẫn rất quan trọng.

ERC-1046 cho thấy lược đồ metadata không chỉ liên quan đến hình ảnh vật phẩm sưu tầm.

Đây là một phần trong nỗ lực rộng hơn nhằm giúp thông tin token có khả năng tương tác.

Token Metadata Schema và ERC-5625

ERC-5625 là phần mở rộng metadata được đề xuất liên quan đến thông tin lưu trữ phi tập trung cho NFT.

Phần mở rộng dStorage của ERC-5625 NFT Metadata JSON Schema chính thức thêm property lưu trữ phi tập trung vào metadata NFT để thông tin lưu trữ tài sản được mô tả rõ ràng hơn.

Điều này quan trọng vì metadata thường trỏ đến các tệp được lưu bên ngoài blockchain.

Token có thể trông bền vững, nhưng media của token có thể phụ thuộc vào cách sắp xếp lưu trữ không rõ ràng.

Thêm metadata liên quan đến lưu trữ có thể giúp người dùng và ứng dụng hiểu dữ liệu tài sản được lưu ở đâu.

Điều này cũng có thể giúp xác định nội dung được lưu trên IPFS, Arweave hay hệ thống lưu trữ phi tập trung khác.

Metadata lưu trữ không tự đảm bảo tính lâu dài.

Nó cung cấp cho ứng dụng cách rõ ràng hơn để mô tả và kiểm tra các giả định về lưu trữ.

Với NFT giá trị cao, chi tiết lưu trữ phi tập trung có thể là phần quan trọng của quá trình thẩm định.

Lược đồ metadata mạnh hơn khi giải thích cả tài sản là gì và dữ liệu của tài sản được bảo toàn như thế nào.

Xác thực lược đồ

Xác thực lược đồ là kiểm tra metadata có tuân theo cấu trúc dự kiến hay không.

Validator có thể kiểm tra JSON có hợp lệ không.

Validator có thể kiểm tra các trường bắt buộc có tồn tại không.

Validator có thể kiểm tra trường hình ảnh có phải URI hợp lệ không.

Validator có thể kiểm tra attributes có được định dạng dưới dạng mảng không.

Validator có thể kiểm tra các giá trị số có được lưu nhất quán không.

Validator có thể kiểm tra các trường media có trỏ đến loại tệp được hỗ trợ không.

Xác thực lược đồ giúp ngăn hiển thị ví lỗi và lỗi marketplace.

Việc này cũng giúp nhà phát triển phát hiện sai sót trước khi mint hoặc reveal.

Dự án nên xác thực metadata trước khi công bố vĩnh viễn lên hệ thống lưu trữ phi tập trung.

Lược đồ metadata và độ hiếm

Công cụ độ hiếm thường phụ thuộc vào trường

trong metadata NFT.

Nếu attributes không nhất quán, việc tính toán độ hiếm có thể thiếu chính xác.

Ví dụ,

, và có thể bị một số công cụ coi là các giá trị khác nhau.

Nếu một token dùng

và token khác dùng , công cụ độ hiếm có thể chia tách danh mục thuộc tính.

Nếu một thuộc tính thiếu ở một số token, tính toán độ hiếm có thể thay đổi bất ngờ.

Dự án nên sử dụng tên và giá trị thuộc tính nhất quán trên toàn bộ bộ sưu tập.

Dự án cũng nên đóng băng metadata cuối cùng khi bộ sưu tập được thiết kế là không thể thay đổi.

Người dùng nên cẩn trọng trong giai đoạn reveal vì dữ liệu độ hiếm có thể chưa ổn định.

Chất lượng lược đồ metadata có thể ảnh hưởng trực tiếp đến cách nhà sưu tầm đánh giá NFT.

Với bộ sưu tập có định giá dựa trên thuộc tính, metadata rõ ràng đặc biệt quan trọng.

Lược đồ metadata và tài sản game

Tài sản game thường cần lược đồ metadata phong phú hơn NFT nghệ thuật đơn giản.

Vật phẩm game có thể cần trường về cấp độ, độ bền, sức tấn công, phòng thủ, độ hiếm, lớp, nguyên tố, thời gian hồi chiêu, trạng thái nâng cấp hoặc ô trang bị.

NFT nhân vật có thể cần trường về kinh nghiệm, kỹ năng, kho đồ, phe phái, máu và trạng thái hình ảnh.

Một số trường này có thể thay đổi trong quá trình chơi.

Nhà phát triển nên quyết định giá trị nào thuộc on-chain và giá trị nào thuộc metadata.

Logic gameplay quan trọng không nên chỉ phụ thuộc vào metadata off-chain chưa được xác minh.

Hợp đồng hoặc máy chủ game nên xác minh các giá trị quan trọng trước khi cho phép hành động có giá trị cao.

Metadata có thể cải thiện hiển thị, nhưng quy tắc game nên được bảo vệ bằng logic đáng tin cậy.

Người dùng nên hiểu liệu giá trị của vật phẩm có phụ thuộc vào việc game tiếp tục hoạt động hay không.

Lược đồ metadata có thể mô tả tài sản game, nhưng hệ sinh thái game mới mang lại tiện ích cho tài sản đó.

Lược đồ metadata và tài sản trong thế giới thực

Token tài sản trong thế giới thực có thể dùng lược đồ metadata để mô tả tài sản off-chain.

Ví dụ có thể gồm hồ sơ bất động sản, hàng hóa, hóa đơn, trái phiếu, chứng chỉ quỹ, vật phẩm sưu tầm, tín chỉ carbon hoặc thông tin xác thực gắn với danh tính.

Lược đồ metadata có thể gồm trường về tổ chức phát hành, loại tài sản, URI tài liệu, ngày định giá, khu vực pháp lý, bên lưu ký, trạng thái xác minh và hash tài liệu.

Các trường này có thể giúp người dùng hiểu token, nhưng không tự động tạo ra quyền sở hữu pháp lý.

Quyền pháp lý phụ thuộc vào tài liệu của tổ chức phát hành, hợp đồng, thỏa thuận lưu ký, khu vực pháp lý và quy tắc quy đổi.

Lược đồ metadata tài sản trong thế giới thực nên tách thông tin marketing khỏi các tham chiếu quan trọng về pháp lý.

Lược đồ này nên tránh các tuyên bố mơ hồ không thể xác minh.

Khi có thể, nên bảo toàn tính toàn vẹn của tài liệu bằng hash hoặc lưu trữ bền vững.

Người dùng nên đọc tài liệu pháp lý chính thức trước khi dựa vào metadata tài sản trong thế giới thực.

Metadata có thể hỗ trợ công bố thông tin, nhưng không thể thay thế thẩm định pháp lý.

Lược đồ metadata và rủi ro bảo mật

Metadata token có thể tạo rủi ro bảo mật vì ví và dApp lấy rồi hiển thị dữ liệu từ nguồn bên ngoài.

Tệp metadata độc hại có thể chứa liên kết phishing, thông điệp phần thưởng giả, hình ảnh gây hiểu lầm hoặc URL bên ngoài nguy hiểm.

NFT spam có thể xuất hiện trong ví và dùng metadata để yêu cầu người dùng truy cập trang claim giả.

Bộ sưu tập giả có thể sao chép tên, hình ảnh và attributes từ bộ sưu tập thật.

Máy chủ metadata bị xâm phạm có thể thay đổi metadata trông an toàn thành nội dung độc hại sau này.

Ví và dApp nên coi metadata là dữ liệu đầu vào chưa đáng tin cậy.

Chúng không nên thực thi script từ metadata.

Khi có thể, chúng nên làm sạch liên kết bên ngoài và nội dung media.

Người dùng không bao giờ nên nhập cụm từ khôi phục, khóa riêng tư hoặc bản sao lưu ví chỉ vì metadata yêu cầu làm như vậy.

Lược đồ metadata trông rõ ràng không chứng minh token an toàn.

Lược đồ metadata và khả năng thay đổi

Khả năng thay đổi nghĩa là metadata có thể được thay đổi sau khi token được mint.

Một số dự án cần khả năng này vì token là động.

Các dự án khác cam kết metadata sẽ vĩnh viễn và không thay đổi.

Lược đồ metadata nên phù hợp với cam kết của dự án.

Nếu bộ sưu tập được tiếp thị là nghệ thuật không thể thay đổi, metadata không nên vẫn nằm dưới quyền kiểm soát admin không giới hạn.

Nếu token là vật phẩm game, metadata động có thể là điều được kỳ vọng.

Nếu token là thông tin xác thực, cập nhật có thể cần thiết nhưng nên có thể kiểm toán.

Người dùng nên kiểm tra ai kiểm soát việc cập nhật metadata.

Nhà phát triển nên tài liệu hóa liệu metadata là không thể thay đổi, động, do admin kiểm soát hay do quản trị kiểm soát.

Khả năng thay đổi bị che giấu là một trong những rủi ro niềm tin lớn nhất trong metadata NFT.

Lược đồ metadata và cache

Cache là việc lưu tạm metadata để ứng dụng tải token nhanh hơn.

Ví, marketplace, trình khám phá blockchain và indexer thường lưu cache metadata.

Cache hữu ích vì việc liên tục lấy lại mọi tệp metadata sẽ chậm.

Vấn đề là metadata đã cache có thể trở nên lỗi thời.

Trong đợt reveal, một số ứng dụng có thể vẫn hiển thị hình ảnh placeholder sau khi metadata cuối cùng đã được công bố.

Trong đợt cập nhật động, một số ứng dụng có thể hiển thị attributes cũ đến khi cache được làm mới.

Tiêu chuẩn cập nhật metadata có thể giúp client biết khi nào cần làm mới dữ liệu cache.

Nhà phát triển nên hỗ trợ sự kiện cập nhật khi metadata dự kiến thay đổi.

Người dùng nên hiểu độ trễ hiển thị có thể do cache thay vì token bị lỗi.

Lược đồ metadata mạnh hoạt động tốt nhất khi đi kèm hành vi làm mới cache hiệu quả.

Lược đồ metadata và indexer

Indexer thu thập dữ liệu blockchain và tổ chức dữ liệu đó cho ứng dụng.

Với metadata token, indexer có thể gọi

, lấy tệp JSON, phân tích attributes, cache hình ảnh và cung cấp phản hồi API.

Indexer cần lược đồ metadata có thể dự đoán để hoạt động hiệu quả.

Nếu mọi dự án dùng tên trường bất thường, indexer phải xây dựng logic tùy chỉnh.

Nếu tệp metadata không hợp lệ hoặc tải chậm, indexer có thể không hiển thị tài sản chính xác.

Nếu metadata thay đổi mà không có sự kiện, indexer có thể hiển thị dữ liệu lỗi thời.

Đây là lý do tính nhất quán của lược đồ hỗ trợ toàn bộ hệ sinh thái Web3.

Nhà phát triển nên kiểm tra metadata với hành vi của indexer phổ biến trước khi ra mắt.

Người dùng nên biết các ví khác nhau có thể hiển thị metadata khác nhau nếu indexer của chúng làm mới vào thời điểm khác nhau.

Indexer là phần ẩn nhưng quan trọng đối với khả năng sử dụng metadata token.

Các phương pháp tốt nhất cho nhà phát triển

Sử dụng các trường metadata được hỗ trợ rộng rãi như

, , và .

Trả về JSON hợp lệ từ mọi Token URI.

Sử dụng tên và giá trị thuộc tính ổn định trong toàn bộ bộ sưu tập.

Dùng lưu trữ bền vững cho metadata và tệp media.

Pin tệp IPFS hoặc sử dụng kế hoạch lưu trữ dài hạn đáng tin cậy.

Tài liệu hóa liệu metadata có thể thay đổi, không thể thay đổi hay động.

Phát sự kiện cập nhật metadata khi metadata thay đổi.

Xác thực metadata trước khi công bố vĩnh viễn.

Kiểm tra hành vi hiển thị trên ví, trình khám phá blockchain và dApp.

Tránh chỉ đưa các cam kết pháp lý nhạy cảm vào metadata có thể chỉnh sửa.

Các phương pháp tốt nhất cho người dùng

Kiểm tra metadata token được lưu trên IPFS, máy chủ, Arweave hay on-chain.

Xác minh địa chỉ hợp đồng chính thức thay vì tin vào tên hoặc hình ảnh token.

Cẩn trọng với metadata chứa liên kết bên ngoài hoặc tuyên bố về phần thưởng.

Không ký giao dịch chỉ để xem metadata.

Không nhập cụm từ khôi phục trên bất kỳ trang nào được liên kết từ metadata token.

Kiểm tra metadata có thể được admin thay đổi hay không.

Xem kỹ attributes trong giai đoạn NFT reveal.

Hiểu rằng hình ảnh được hiển thị không chứng minh tính xác thực.

Với token tài sản trong thế giới thực, hãy đọc tài liệu pháp lý bên ngoài tệp metadata.

Coi metadata là thông tin hữu ích, không phải bằng chứng độc lập về giá trị hoặc độ an toàn.

Các lỗi phổ biến về Token Metadata Schema

Lỗi đầu tiên là công bố JSON không hợp lệ.

Lỗi thứ hai là sử dụng tên attributes không nhất quán giữa các token.

Lỗi thứ ba là trỏ trường hình ảnh đến tệp không khả dụng.

Lỗi thứ tư là phụ thuộc vào máy chủ tập trung mà không công bố rõ.

Lỗi thứ năm là thay đổi metadata sau khi mint mà không có quy tắc rõ ràng.

Lỗi thứ sáu là quên yêu cầu thay thế

của ERC-1155.

Lỗi thứ bảy là sử dụng định dạng media không được hỗ trợ mà không có hình ảnh dự phòng.

Lỗi thứ tám là coi metadata có tính ràng buộc pháp lý khi nó chỉ mang tính mô tả.

Lỗi thứ chín là không phát sự kiện cập nhật khi metadata thay đổi.

Lỗi thứ mười là chứa liên kết không an toàn có thể khiến người dùng gặp phishing.

FAQ

Token Metadata Schema có nghĩa là gì?

Token Metadata Schema là định dạng có cấu trúc dùng để mô tả metadata của token tiền mã hóa, thường ở dạng JSON.

Token Metadata Schema chỉ dành cho NFT phải không?

Không. Lược đồ này phổ biến nhất với NFT, nhưng cũng có thể hỗ trợ token có thể thay thế, token tài sản trong thế giới thực và token riêng của ứng dụng.

Trường nào phổ biến trong metadata NFT?

Các trường phổ biến gồm

, , , , và .

Token URI khác Token Metadata Schema như thế nào?

Token URI trỏ đến metadata, còn Token Metadata Schema xác định cấu trúc metadata tại đó.

ERC-721 Metadata JSON Schema là gì?

Đây là lược đồ metadata cơ bản được ERC-721 mô tả cho metadata NFT trả về thông qua token URI.

ERC-1155 Metadata URI JSON Schema là gì?

Đây là lược đồ metadata dành cho token ERC-1155, bao gồm hỗ trợ thay thế Token ID qua

.

Metadata token có thể được lưu trên IPFS không?

Có. Metadata token có thể được lưu trên IPFS bằng các mã định danh nội dung giúp xác minh tính toàn vẹn của nội dung.

IPFS có đảm bảo metadata luôn khả dụng không?

Không. IPFS cải thiện khả năng định địa chỉ theo nội dung, nhưng tệp vẫn cần được pin hoặc phục vụ để người dùng có thể truy xuất.

Metadata token có thể thay đổi sau khi mint không?

Có. Metadata có thể thay đổi nếu dự án sử dụng metadata động, máy chủ có thể thay đổi, base URI do admin kiểm soát hoặc logic resolver có thể cập nhật.

Metadata token động là gì?

Metadata token động là metadata thay đổi theo thời gian, gameplay, hoạt động người dùng, dữ liệu oracle, trạng thái hợp đồng hoặc cập nhật dự án.

ERC-4906 được dùng để làm gì?

ERC-4906 xác định sự kiện cập nhật metadata để ví và ứng dụng biết khi nào metadata NFT cần được làm mới.

ERC-7572 được dùng để làm gì?

ERC-7572 chuẩn hóa

cho metadata cấp hợp đồng như tên, mô tả và hình ảnh của bộ sưu tập.

Metadata có thể độc hại không?

Có. Metadata có thể chứa liên kết phishing, tuyên bố phần thưởng giả, hình ảnh gây hiểu lầm hoặc tham chiếu bên ngoài không an toàn.

Vì sao thuộc tính NFT đôi khi hiển thị không chính xác?

Thuộc tính NFT có thể hiển thị sai vì attributes không nhất quán, thiếu, viết sai, bị cache hoặc được định dạng theo cách client không hiểu.

Điều gì tạo nên một Token Metadata Schema tốt?

Token Metadata Schema tốt phải hợp lệ, nhất quán, bền vững, được tài liệu hóa, tương thích với công cụ phổ biến và nêu rõ liệu metadata có thể thay đổi hay không.

Kết luận

Token Metadata Schema là định dạng có cấu trúc hướng dẫn ví, dApp, trình khám phá blockchain, game, marketplace và indexer cách đọc thông tin về token tiền mã hóa.

Lược đồ này đặc biệt quan trọng với NFT vì quyền sở hữu NFT được lưu on-chain, trong khi tên, hình ảnh, thuộc tính, mô tả và media thường được lưu qua tệp metadata.

ERC-721 và ERC-1155 đều xác định các mẫu metadata giúp ứng dụng phân giải và hiển thị thông tin token một cách nhất quán.

Lược đồ metadata tốt giúp token dễ hiểu, lọc, giao dịch, xác minh và sử dụng trong ứng dụng hơn.

Lược đồ metadata yếu có thể gây hình ảnh lỗi, thiếu thuộc tính, dữ liệu lỗi thời, rủi ro phishing và nhầm lẫn cho người dùng.

Các trường quan trọng gồm

, , , , và properties riêng của dự án.

Lựa chọn lưu trữ như IPFS, HTTPS, Arweave và dữ liệu on-chain ảnh hưởng đến tính lâu dài, khả năng thay đổi, chi phí và mức độ tin cậy.

Cập nhật metadata nên minh bạch, đặc biệt với reveal, NFT động, tài sản game, thông tin xác thực và token tài sản trong thế giới thực.

Nhà phát triển nên xác thực metadata, sử dụng lưu trữ bền vững, tài liệu hóa khả năng thay đổi, phát sự kiện cập nhật và kiểm tra trên các công cụ Web3 phổ biến.

Người dùng nên xác minh địa chỉ hợp đồng, tránh liên kết metadata đáng ngờ, hiểu rủi ro lưu trữ và coi metadata là thông tin mô tả thay vì bằng chứng tuyệt đối.

Trong bảng thuật ngữ crypto, Token Metadata Schema nên được hiểu là định dạng dữ liệu mang lại ý nghĩa con người có thể đọc cho token tiền mã hóa và cho phép hệ sinh thái Web3 hiển thị thông tin token một cách nhất quán và an toàn.