مخطط بيانات تعريف التوكن

ما هو مخطط بيانات تعريف التوكن؟

مخطط بيانات تعريف التوكن هو تنسيق منظم يحدد كيفية كتابة المعلومات المتعلقة بتوكن كريبتو وتخزينها وقراءتها بواسطة المحافظ والتطبيقات اللامركزية (dApps) والمستكشفات والأسواق والألعاب وأدوات الفهرسة.

في معظم نقاشات الكريبتو، يشير Token Metadata Schema إلى بنية JSON المستخدمة لوصف NFTs وغيرها من الأصول المرمزة.

يخبر المخطط التطبيقات بالحقول المتوقعة، مثل

و و و وروابط الوسائط.

قد يخزن عقد التوكن الملكية على السلسلة، بينما تُخزن بياناته التعريفية عبر URI يشير إلى ملف JSON.

ينص معيار ERC-721 الرسمي على أن URI التوكن قد يشير إلى ملف JSON متوافق مع ERC-721 Metadata JSON Schema.

ويعرّف معيار ERC-1155 الرسمي مخطط ERC-1155 Metadata URI JSON Schema لعقود التوكنات المتعددة.

يُعد مخطط البيانات التعريفية مهماً لأنه يساعد التطبيقات المختلفة على عرض التوكن نفسه بصورة متسقة.

من دون مخطط، يمكن لكل مشروع تسمية الحقول بطريقة مختلفة، وستواجه المحافظ صعوبة في معرفة القيمة التي تمثل الصورة أو الوصف أو السمات.

بالنسبة للمبتدئ، أسهل طريقة لفهم Token Metadata Schema هي اعتباره تنسيق ملصق لأصل مشفر.

تثبت البلوكشين وجود التوكن ومن يملكه، بينما يوضح مخطط البيانات التعريفية ما الذي يمثله التوكن.

أهمية Token Metadata Schema في الكريبتو

تكمن أهمية Token Metadata Schema في أن المستخدمين لا يتفاعلون مع معرّفات التوكنات الخام وحدها.

بل يتفاعلون مع الصور والأسماء والأوصاف والسمات والمستويات والشارات ومعلومات الندرة والمحتوى القابل للفتح وغيرها من التفاصيل المقروءة بشرياً.

لا تستطيع المحفظة عرض التوكن بصورة صحيحة إلا إذا عرفت كيفية قراءة بياناته التعريفية.

ولا تستطيع اللعبة عرض عنصر بصورة صحيحة إلا إذا فهمت سمات العنصر وحقول الوسائط الخاصة به.

ولا يستطيع السوق تصفية المجموعات بصورة صحيحة إلا إذا نُظمت السمات بطريقة قابلة للتوقع.

قد يحتاج بروتوكول إقراض يقبل NFTs كضمانات إلى معلومات دقيقة عن المجموعة والسمات والوسائط لدعم عمليات التقييم.

وقد تحتاج منصة أصول من العالم الحقيقي إلى حقول بيانات تعريفية تشير إلى المستندات أو الجهات المُصدرة أو التقييمات أو الشروط القانونية أو حالة التحقق.

وقد يحتاج تطبيق مقيّد بالتوكنات إلى بيانات تعريفية للتحقق مما إذا كان التوكن يمنح الوصول إلى مستوى عضوية معين.

عندما تكون البيانات التعريفية منظمة بوضوح، تستطيع التطبيقات قراءتها تلقائياً.

وعندما تكون البيانات التعريفية فوضوية أو غير متسقة، قد يرى المستخدمون صوراً معطلة أو سمات مفقودة أو أسماء غير صحيحة أو تفاصيل قديمة للأصل.

لهذا السبب، يُعد تصميم مخطط البيانات التعريفية جزءاً من تجربة مستخدم الكريبتو، وليس مجرد تفصيل خاص بالمطورين.

Token Metadata Schema وToken URI

Token URI هو الرابط أو المعرّف الذي يشير إلى البيانات التعريفية للتوكن.

أما Token Metadata Schema فهو بنية البيانات الموجودة في ذلك الرابط أو ضمن الاستجابة المشفرة.

على سبيل المثال، قد يعيد عقد ERC-721 القيمة

من .

ينبغي أن يتبع ملف JSON الموجود في URI هذا مخطط بيانات تعريفية حتى تتمكن المحافظ من فهمه.

Token URI هو عنوان البيانات التعريفية.

أما Token Metadata Schema فهو تنسيق البيانات التعريفية.

هذا الفرق مهم لأن URI الذي يعمل لا يكفي إذا كان JSON الموجود داخله غير صالح أو مربكاً.

يمكن أن يمتلك التوكن ملف بيانات تعريفية يمكن الوصول إليه، لكنه قد يُعرض بصورة غير صحيحة إذا كانت الحقول مفقودة أو مسماة بطريقة غير معيارية.

ويمكن أن يكون للتوكن مخطط صحيح، لكنه يفشل في التحميل إذا كان URI يشير إلى مساحة تخزين غير متاحة.

يتطلب تصميم NFT الجيد كلاً من Token URI موثوق ومخطط Token Metadata Schema واضح.

Token Metadata Schema في ERC-721

ERC-721 هو المعيار التقليدي لـ NFTs الفريدة على الشبكات المشابهة لـ Ethereum.

يتضمن امتداد البيانات التعريفية لـ ERC-721 الدوال

و و.

يصف معيار ERC-721 البيانات التعريفية باستخدام مخطط JSON بسيط يمكن أن يتضمن حقولاً مثل

و و.

ساعدت هذه البنية البسيطة على تسهيل عرض NFTs عبر المحافظ والتطبيقات.

يمكن لتوكن ERC-721 أن يمثل فناً رقمياً أو عناصر ألعاب أو بطاقات عضوية أو شهادات أو أراضي افتراضية أو شارات هوية أو سجلات أصول من العالم الحقيقي.

يمكن أن يكون لكل معرّف توكن ملف بيانات تعريفية خاص به.

وهذا يعني أن معرّف التوكن 1 قد يملك صورة واسماً وسمات مختلفة عن معرّف التوكن 2.

يساعد المخطط العملاء على فهم الحقول التي تصف كل توكن فريد.

غالباً ما يوسّع المطورون نمط البيانات التعريفية الأساسي لـ ERC-721 بإضافة حقول للسمات والوسائط والرسوم المتحركة والندرة والترخيص أو بيانات خاصة بالمشروع.

قد تكون هذه الامتدادات مفيدة، لكن ينبغي أن تبقى الحقول الأساسية واضحة ومتوافقة مع أدوات Web3 الشائعة.

Token Metadata Schema في ERC-1155

ERC-1155 هو معيار للتوكنات المتعددة يمكنه إدارة التوكنات القابلة للاستبدال وشبه القابلة للاستبدال وغير القابلة للاستبدال ضمن عقد واحد.

يكتسب مخطط البيانات التعريفية لـ ERC-1155 أهمية خاصة لأن العقد الواحد قد يحتوي على العديد من معرّفات التوكنات ذات المعاني المختلفة.

يمكن لعقد ERC-1155 واحد أن يمثل عملات ألعاب وأسلحة ودروعاً وتذاكر وشارات وإصدارات محدودة ومقتنيات فريدة.

يسمح معيار ERC-1155 بأن يتضمن URI العنصر النائب

.

يستبدل برنامج العميل

بمعرّف التوكن الفعلي قبل جلب البيانات التعريفية.

توضح وثائق OpenZeppelin ERC-1155 Metadata URI الرسمية أن امتداد URI للبيانات التعريفية يربط كل توكن بملف JSON يتبع ERC-1155 Metadata URI JSON Schema.

يمكن أن تتضمن بيانات ERC-1155 التعريفية حقولاً مثل

و و و وغيرها من البيانات الخاصة بالتوكن.

يتيح المخطط للمحافظ والتطبيقات اللامركزية عرض أنواع كثيرة من الأصول من عقد واحد دون الحاجة إلى منطق مخصص لكل معرّف توكن.

يجب التعامل مع بيانات ERC-1155 التعريفية بحذر، لأن الاستبدال الخاطئ للمعرّف يمكن أن يؤدي إلى عروض معطلة أو غير صحيحة.

يسهّل تصميم بيانات ERC-1155 التعريفية القوي تفسير كل معرّف توكن وجلبه بشكل موثوق.

الحقول الشائعة في Token Metadata Schema

أكثر الحقول شيوعاً هو

، الذي يمنح التوكن عنواناً مقروءاً بشرياً.

والحقل الشائع التالي هو

، الذي يشرح ما يمثله التوكن.

يشير حقل

عادةً إلى الصورة الرئيسية المعروضة في المحافظ والأسواق.

يمكن لحقل

الإشارة إلى وسائط أغنى، مثل الفيديو والصوت والكائنات ثلاثية الأبعاد أو المحتوى التفاعلي، عندما يدعمها العميل.

يمكن لحقل

الإشارة إلى صفحة رسمية تضم معلومات إضافية عن التوكن أو المجموعة.

يحتوي حقل

عادةً على مصفوفة من كائنات السمات المستخدمة للندرة والتصفية وإحصاءات الألعاب وتنظيم المجموعات.

يُستخدم حقل

أحياناً لاقتراح لون خلفية لعرض الأصل.

يُستخدم حقل

غالباً لبيانات تعريفية بأسلوب ERC-1155 أو معلومات منظمة خاصة بالمشروع.

تضيف بعض المشاريع حقولاً مثل

و و و أو .

يمكن أن تكون الحقول المخصصة مفيدة، لكن ينبغي توثيقها حتى تتمكن التطبيقات من تفسيرها بصورة صحيحة.

مثال على مخطط بيانات تعريفية أساسي لـ NFT

يكون ملف البيانات التعريفية البسيط لـ NFT عادةً كائن JSON يضم عدداً قليلاً من الحقول الواضحة.

يوضح هذا المثال اسماً مقروءاً ووصفاً ومرجعاً للصورة وسمتين.

المخطط بسيط بما يكفي للمحافظ والتطبيقات اللامركزية لتحليله.

تستخدم الصورة URI بأسلوب IPFS، ما يعني أن الوسائط يُشار إليها عبر تخزين معنون بالمحتوى.

تُنظم السمات كمصفوفة، مما يسهّل بناء أدوات التصفية والندرة.

يمكن للمشروع إضافة حقول أخرى، لكن ينبغي تجنب التعقيد غير الضروري الذي يخل بالتوافق.

أفضل البيانات التعريفية قابلة للقراءة آلياً وسهلة الفهم للبشر في آن واحد.

حقل الاسم

يمنح حقل

التوكن عنوان العرض الخاص به.

بالنسبة لمجموعة NFT، من الشائع استخدام اسم المجموعة ورقم التوكن.

مثال على ذلك هو

.

قد يستخدم عنصر اللعبة اسماً مثل

أو .

وقد يستخدم توكن العضوية اسماً مثل

.

ينبغي أن يكون الاسم ثابتاً وواضحاً وغير مضلل.

قد تنسخ مجموعة مزيفة اسم مشروع حقيقي، لذلك لا ينبغي للمستخدمين الاعتماد على حقل الاسم وحده.

عنوان العقد الرسمي أهم من الاسم المعروض.

ينبغي للمطورين تجنب تغيير الأسماء على نحو غير متوقع ما لم يكن التوكن مصمماً ليكون ديناميكياً.

يحسن حقل الاسم الجيد سهولة التعرف دون الادعاء بإثبات الأصالة.

حقل الوصف

يشرح حقل

ما يمثله التوكن.

يساعد الوصف الواضح المستخدمين على فهم غرض الأصل أو قصته أو استخداماته أو دوره في العضوية.

بالنسبة لـ NFTs الفنية، قد يشرح الوصف الفكرة أو موضوع المجموعة.

وبالنسبة لعناصر الألعاب، قد يوضح كيفية استخدام العنصر.

وبالنسبة لتوكنات الأصول من العالم الحقيقي، قد يلخص فئة الأصل مع توجيه المستخدمين إلى المستندات القانونية في مكان آخر.

ينبغي ألا يتضمن الوصف ادعاءات مضللة بشأن القيمة أو العوائد المضمونة أو الصفة الرسمية.

قد تعرض المحافظ والتطبيقات اللامركزية الوصف مباشرةً للمستخدمين، لذلك يمكن للروابط غير الآمنة أو رسائل الاحتيال أن تنشئ مخاطر تصيد احتيالي.

ينبغي للمطورين الحفاظ على فائدة الأوصاف وصدقها.

ينبغي أن يتذكر المستخدمون أن الوصف يقدمه منشئ التوكن أو الجهة المتحكمة في البيانات التعريفية.

الوصف ليس تحققاً مستقلاً من جودة التوكن أو مشروعيته.

حقل الصورة

يشير حقل

إلى ملف الوسائط الرئيسي المعروض للتوكن.

يمكن أن يشير إلى PNG أو JPG أو GIF أو SVG أو صيغة صورة مدعومة أخرى، حسب التطبيق.

يمكن تخزين الصورة على IPFS أو Arweave أو خوادم HTTPS أو تشفيرها مباشرةً داخل البيانات التعريفية.

حقل الصورة مهم لأن كثيراً من المستخدمين يتعرفون إلى NFTs بصرياً.

قد يجعل رابط الصورة المعطل التوكن يبدو غير مكتمل حتى إن كانت الملكية صالحة على السلسلة.

وقد تجعل الصورة المضللة توكناً مزيفاً يبدو مشروعاً.

وقد يختفي URL للصورة مركزي إذا تعطل الخادم أو النطاق.

يمكن لـ URI الصورة المعنون بالمحتوى أن يحسن السلامة، لكن يجب أن يبقى المحتوى متاحاً عبر التخزين أو التثبيت.

ينبغي للمطورين استخدام تخزين متين للصور الخاصة بالأصول طويلة الأجل.

ينبغي للمستخدمين التحقق من جودة تخزين الصور قبل الوثوق بـ NFTs عالية القيمة.

حقل السمات

يستخدم حقل

عادةً لوصف السمات والندرة وخصائص الألعاب والمستويات والحالة أو الخصائص المنظمة الأخرى.

تكون كل سمة عادةً كائناً يضم

و.

على سبيل المثال، قد يكون

هو ، وقد تكون هي .

بالنسبة لعنصر لعبة، قد يكون

هو ، وقد تكون هي .

تُعد بنية السمات مهمة لأن الأسواق وأدوات التحليل تستخدمها للتصفية وترتيب الندرة.

يمكن للسمات غير المتسقة أن تجعل أدوات الندرة غير دقيقة.

وقد تقسم أسماء السمات التي بها أخطاء إملائية ما ينبغي أن يكون فئة واحدة إلى عدة فئات.

ينبغي تنسيق السمات الرقمية باتساق حتى تتمكن الأدوات من مقارنتها بصورة صحيحة.

ينبغي أن توضح NFTs الديناميكية ما إذا كانت السمات قابلة للتغير بمرور الوقت.

تساعد السمات الجيدة المستخدمين على فهم هوية التوكن واستخداماته.

حقل الخصائص

يستخدم حقل

غالباً للاحتفاظ ببيانات تعريفية منظمة تتجاوز بيانات الاسم والوصف والصورة الأساسية.

تستخدم أمثلة بيانات ERC-1155 التعريفية عادةً

لمعلومات التوكن الإضافية.

قد يتضمن عنصر اللعبة خصائص مثل الندرة والفئة والمتانة أو مواد التصنيع.

وقد يتضمن توكن التذكرة خصائص مثل تاريخ الحدث ومستوى المقعد والمكان ونوع الوصول.

وقد يتضمن توكن أصل من العالم الحقيقي خصائص مثل فئة الأصل ومرجع الجهة المُصدرة والولاية القضائية وهاش المستند أو حالة التحقق.

يمكن أن تكون الخصائص قوية لأنها تتيح نماذج بيانات أغنى.

لكنها قد تصبح فوضوية أيضاً إذا استخدم كل مشروع أسماء وتنسيقات مختلفة دون توثيق.

ينبغي للمطورين الحفاظ على ثبات أسماء الخصائص وإمكانية توقعها.

ينبغي للتطبيقات التعامل مع الخصائص كبيانات غير موثوقة إلى أن تتحقق منها منطقية العقد أو مصادر موثوقة.

يمكن لحقل خاصية وصف أصل، لكنه لا يثبت تلقائياً صحة الادعاء.

Token Metadata Schema وIPFS

يُستخدم IPFS عادةً لتخزين بيانات تعريفية للتوكنات وملفات الوسائط.

توضح وثائق العنونة بالمحتوى في IPFS الرسمية أن IPFS يستخدم معرّفات المحتوى، أو CIDs، للإشارة إلى البيانات بناءً على المحتوى نفسه.

يفيد ذلك للبيانات التعريفية لأن CID يمكن أن يوضح ما إذا كان المحتوى المشار إليه قد تغير.

إذا تغيرت بيانات JSON التعريفية، فينبغي أن يتغير CID أيضاً.

يوفر ذلك للمستخدمين سلامة أقوى من URL خادم عادي يمكنه تغيير المحتوى على العنوان نفسه.

لكن IPFS لا يضمن تلقائياً إتاحة المحتوى إلى الأبد.

تحتاج ملفات البيانات التعريفية والصور إلى التثبيت أو الخدمة بواسطة العقد حتى يتمكن العملاء من استرجاعها.

قد يتعطل مخطط بيانات تعريفية مخزن على IPFS إذا لم يحافظ أحد على إتاحة المحتوى.

ينبغي للمطورين التخطيط للتثبيت والتخزين طويل الأجل قبل سك التوكنات.

ينبغي للمستخدمين فهم أن العنونة بالمحتوى تحسن السلامة، لكن الإتاحة لا تزال تتطلب دعماً للتخزين.

Token Metadata Schema وتخزين HTTP

تخزن بعض المشاريع البيانات التعريفية على خوادم HTTPS القياسية.

يمكن أن يجعل ذلك تحديث البيانات التعريفية وإنشاءها وخدمتها بسرعة أمراً سهلاً.

وهو شائع بالنسبة لـ NFTs الديناميكية وأصول الألعاب وآليات الكشف والأصول التي تعتمد على أنظمة خلفية نشطة.

الجانب السلبي هو أن بيانات HTTP التعريفية تعتمد على وقت تشغيل الخادم والتحكم بالنطاق وأمن الاستضافة وعمليات المشروع.

إذا أصبح الخادم غير متصل بالإنترنت، فقد تختفي بيانات التوكن التعريفية من واجهات المستخدم.

وإذا انتهت صلاحية النطاق، فقد تصبح نقطة نهاية البيانات التعريفية غير آمنة أو غير متاحة.

وإذا غيّر مشغل الخادم JSON، فقد يرى المستخدمون محتوى مختلفاً من دون تغيير على السلسلة.

ليست بيانات HTTP التعريفية سيئة تلقائياً، لكن ينبغي الإفصاح عنها بوضوح.

ينبغي للمطورين توضيح ما إذا كانت البيانات التعريفية قابلة للتعديل والمدة التي سيُحافظ فيها على التخزين.

ينبغي للمستخدمين توخي حذر أكبر مع الأصول عالية القيمة التي تعتمد بالكامل على خوادم بيانات تعريفية مركزية.

Token Metadata Schema والبيانات التعريفية على السلسلة

تعني البيانات التعريفية على السلسلة أن بيانات التوكن التعريفية تُخزن أو تُنشأ مباشرةً بواسطة العقد الذكي.

يمكن أن يقلل ذلك الاعتماد على أنظمة التخزين الخارجية.

قد يعيد العقد URI بقيمة

يحتوي على بيانات تعريفية مشفرة.

قد تتضمن البيانات التعريفية صورة SVG على السلسلة أو منطق فن توليدي.

يمكن أن تحسن البيانات التعريفية على السلسلة المتانة لأن البيانات مرتبطة بحالة البلوكشين.

وقد تكون أكثر تكلفة أيضاً لأن تخزين البيانات وإنشاءها على السلسلة يستهلكان موارد.

قد يكون تغيير البيانات التعريفية على السلسلة أصعب، وهو مفيد للاستمرارية لكنه أقل فائدة للألعاب أو بيانات الاعتماد الديناميكية.

ينبغي للمطورين اختيار البيانات التعريفية على السلسلة عندما تكون الاستمرارية وتقليل الحاجة إلى الثقة أهم من المرونة.

ينبغي للمستخدمين الاستمرار في فحص منطق العقد، لأن البيانات التعريفية على السلسلة قد تكون ديناميكية أيضاً إذا سمح العقد بذلك.

البيانات التعريفية على السلسلة هي نموذج تخزين، وليست ضماناً تلقائياً للجودة.

Token Metadata Schema وNFTs الديناميكية

NFTs الديناميكية هي توكنات يمكن أن تتغير بياناتها التعريفية بناءً على الأحداث أو الوقت أو اللعب أو بيانات Oracle أو قرارات الحوكمة أو إجراءات المستخدم.

يمكن للبيانات التعريفية الديناميكية أن تجعل NFTs أكثر فائدة وتفاعلية.

يمكن لشخصية في لعبة أن ترتقي في المستوى.

ويمكن لبطاقة العضوية أن تتغير من نشطة إلى منتهية الصلاحية.

ويمكن لبيان اعتماد أن يتحدث بعد إكمال المستخدم إنجازاً جديداً.

ويمكن لتوكن أصل من العالم الحقيقي تحديث حالة التحقق أو مراجع المستندات.

ينبغي أن يوضح مخطط البيانات التعريفية الحقول الديناميكية.

ينبغي للمستخدمين معرفة الحقول القابلة للتغيير والجهة التي تتحكم في هذه التغييرات.

ينبغي ألا يخفي NFT ديناميكي تحكماً إدارياً تعسفياً خلف لغة مبهمة للبيانات التعريفية.

تكون البيانات التعريفية الديناميكية الجيدة قابلة للتوقع وموثقة ومرتبطة بسلوك توكن ذي معنى.

Token Metadata Schema وتحديثات البيانات التعريفية

تشيع تحديثات البيانات التعريفية أثناء الكشف وتقدم اللعبة والتحقق من الأصول وتصحيح الأخطاء.

يعرّف امتداد تحديث بيانات ERC-4906 الرسمية أحداثاً تُخطر العملاء عند تغير بيانات NFT التعريفية.

هذا مهم لأن المحافظ والمفهرسات غالباً ما تخزن البيانات التعريفية مؤقتاً لأجل السرعة.

إذا تغيرت البيانات التعريفية دون إصدار إشارة تحديث، فقد يواصل المستخدمون رؤية معلومات قديمة.

ينبغي إقران مخطط البيانات التعريفية بسلوك تحديث واضح.

بالنسبة للكشف، ينبغي للمشروع توضيح وقت تغير البيانات التعريفية المؤقتة إلى بيانات تعريفية نهائية.

وبالنسبة للأصول الديناميكية، ينبغي للمشروع توضيح الأحداث التي تؤدي إلى تغير البيانات التعريفية.

وبالنسبة للتحديثات التي يتحكم فيها المدير، ينبغي للمشروع الإفصاح عمن يمكنه تغيير البيانات التعريفية وفي أي ظروف.

تبني تحديثات البيانات التعريفية الشفافة الثقة.

أما التحديثات المخفية فتنشئ حالة من عدم اليقين وقد تضر بقيمة التوكن.

Token Metadata Schema والبيانات التعريفية على مستوى العقد

تصف البيانات التعريفية على مستوى التوكن معرّف توكن محدداً.

أما البيانات التعريفية على مستوى العقد فتصف العقد أو المجموعة بالكامل.

يوحّد معيار البيانات التعريفية على مستوى العقد ERC-7572 الرسمي الدالة

للمعلومات الغنية على مستوى العقد، مثل الاسم والوصف والصورة.

يفيد ذلك لأن المجموعة قد تحتاج إلى شعار أو بانر أو وصف أو معلومات رسوم أو روابط اجتماعية أو صورة على مستوى المشروع.

يمكن أن يمتلك NFT واحد في مجموعة مخطط Token Metadata Schema خاصاً به، فيما تمتلك المجموعة أيضاً مخطط بيانات تعريفية على مستوى العقد.

كلا الطبقتين مهمتان لتجربة المستخدم.

إذا كانت بيانات التوكن التعريفية صحيحة لكن بيانات المجموعة التعريفية خاطئة، فقد يظل المستخدمون يرون معلومات مربكة.

وإذا كانت بيانات المجموعة التعريفية صحيحة لكن بيانات التوكن معطلة، فقد لا تُعرض التوكنات الفردية بصورة صحيحة.

ينبغي للمطورين دعم البيانات التعريفية على مستوى التوكن والعقد عند الاقتضاء.

ينبغي للمستخدمين فهم أن هاتين طبقتان مرتبطتان لكنهما مختلفتان من البيانات التعريفية.

Token Metadata Schema وERC-1046

يوسع ERC-1046 أفكار Token URI لتتجاوز حالات استخدام NFT الأساسية.

يضيف مقترح قابلية التشغيل البيني لـ ERC-1046 tokenURI الرسمي دعم Token URI لـ ERC-20 ويوسع قابلية التشغيل البيني للبيانات التعريفية بين أنواع التوكنات.

هذا مهم لأن التوكنات القابلة للاستبدال قد تحتاج أيضاً إلى بيانات تعريفية.

قد يحتاج التوكن القابل للاستبدال إلى شعار ووصف وتفاصيل الجهة المُصدرة وروابط رسمية وملاحظات امتثال أو مراجع للوثائق.

تساعد البيانات التعريفية الموحدة المحافظ والتطبيقات على تقديم التوكنات القابلة للاستبدال بوضوح أكبر.

لكن ينبغي للمستخدمين ألا يعاملوا حقول البيانات التعريفية على أنها إثبات للمشروعية.

يمكن لتوكن احتيالي أن يقدم شعاراً ووصفاً جيدين.

لا يزال عنوان العقد والجهة المُصدرة والسيولة والأمان واقتصاديات التوكن والمصادر الرسمية مهماً.

يوضح ERC-1046 أن مخططات البيانات التعريفية لا تتعلق بصور المقتنيات فقط.

بل هي جزء من جهد أوسع لجعل معلومات التوكنات قابلة للتشغيل البيني.

Token Metadata Schema وERC-5625

ERC-5625 هو امتداد مقترح للبيانات التعريفية يتعلق بمعلومات التخزين اللامركزي لـ NFTs.

يضيف امتداد ERC-5625 NFT Metadata JSON Schema dStorage الرسمي خاصية تخزين لامركزي إلى بيانات NFT التعريفية، بحيث يمكن وصف معلومات تخزين الأصل بصورة أوضح.

هذا مهم لأن البيانات التعريفية غالباً ما تشير إلى ملفات مخزنة خارج البلوكشين.

قد يبدو التوكن متيناً، لكن وسائطه قد تعتمد على ترتيبات تخزين غير واضحة.

يمكن أن تساعد إضافة بيانات تعريفية متعلقة بالتخزين المستخدمين والتطبيقات على فهم مكان تخزين بيانات الأصل.

كما يمكن أن تساعد على تحديد ما إذا كان المحتوى مخزناً على IPFS أو Arweave أو نظام تخزين لامركزي آخر.

لا تضمن البيانات التعريفية للتخزين الاستمرارية بمفردها.

إنها تمنح التطبيقات طريقة أوضح لوصف افتراضات التخزين وفحصها.

بالنسبة لـ NFTs عالية القيمة، قد تكون تفاصيل التخزين اللامركزي جزءاً مهماً من العناية الواجبة.

يصبح مخطط البيانات التعريفية أقوى عندما يوضح ماهية الأصل وكيفية حفظ بياناته معاً.

التحقق من المخطط

يعني التحقق من المخطط فحص ما إذا كانت البيانات التعريفية تتبع البنية المتوقعة.

يمكن لأداة التحقق فحص ما إذا كان JSON صالحاً.

ويمكنها فحص وجود الحقول المطلوبة.

ويمكنها فحص ما إذا كان حقل الصورة URI صالحاً.

ويمكنها فحص ما إذا كانت السمات منسقة كمصفوفة.

ويمكنها فحص ما إذا كانت القيم الرقمية مخزنة باتساق.

ويمكنها فحص ما إذا كانت حقول الوسائط تشير إلى أنواع ملفات مدعومة.

يساعد التحقق من المخطط على منع عروض المحافظ المعطلة وأخطاء الأسواق.

كما يساعد المطورين على اكتشاف الأخطاء قبل السك أو الكشف.

ينبغي للمشروع التحقق من البيانات التعريفية قبل نشرها بشكل دائم في التخزين اللامركزي.

مخطط البيانات التعريفية والندرة

تعتمد أدوات الندرة غالباً على حقل

في بيانات NFT التعريفية.

إذا كانت السمات غير متسقة، فقد تصبح حسابات الندرة غير دقيقة.

على سبيل المثال، قد تعامل بعض الأدوات

و و كقيم مختلفة.

إذا استخدم توكن

واستخدم آخر ، فقد تقسم أدوات الندرة فئة السمة.

إذا كانت سمة مفقودة من بعض التوكنات، فقد تتغير حسابات الندرة بصورة غير متوقعة.

ينبغي للمشاريع استخدام أسماء وقيم سمات متسقة عبر المجموعة بأكملها.

ينبغي لها أيضاً تجميد البيانات التعريفية النهائية عندما يُراد أن تكون المجموعة غير قابلة للتغيير.

ينبغي للمستخدمين توخي الحذر خلال فترات الكشف لأن بيانات الندرة قد لا تكون مستقرة بعد.

يمكن لجودة مخطط البيانات التعريفية أن تؤثر مباشرةً في طريقة تقييم الجامعين لـ NFT.

بالنسبة للمجموعات ذات التسعير القائم على السمات، تكون البيانات التعريفية النظيفة مهمة بصفة خاصة.

مخطط البيانات التعريفية وأصول الألعاب

تحتاج أصول الألعاب غالباً إلى مخططات بيانات تعريفية أغنى من NFTs الفنية البسيطة.

قد يحتاج عنصر اللعبة إلى حقول للمستوى والمتانة وقوة الهجوم والدفاع والندرة والفئة والعنصر وفترة التهدئة وحالة الترقية أو خانة المعدات.

وقد تحتاج شخصية NFT إلى حقول للخبرة والمهارات والمخزون والفصيل والصحة والحالة المرئية.

قد تتغير بعض هذه الحقول أثناء اللعب.

ينبغي للمطورين تحديد القيم التي تنتمي إلى السلسلة والقيم التي تنتمي إلى البيانات التعريفية.

ينبغي ألا يعتمد منطق اللعب المهم على بيانات تعريفية خارج السلسلة غير متحقق منها وحدها.

ينبغي لعقد اللعبة أو خادمها التحقق من القيم الأساسية قبل السماح بإجراءات عالية القيمة.

يمكن للبيانات التعريفية تحسين العرض، لكن ينبغي حماية قواعد اللعبة بمنطق موثوق.

ينبغي للمستخدمين فهم ما إذا كانت قيمة العنصر تعتمد على استمرار تشغيل اللعبة.

يمكن لمخطط البيانات التعريفية وصف أصل لعبة، لكن منظومة اللعبة تمنحه استخداماته.

مخطط البيانات التعريفية والأصول من العالم الحقيقي

قد تستخدم توكنات الأصول من العالم الحقيقي مخططات البيانات التعريفية لوصف أصول خارج السلسلة.

يمكن أن تشمل الأمثلة سجلات العقارات والسلع والفواتير والسندات ووحدات الصناديق والمقتنيات وائتمانات الكربون أو بيانات الاعتماد المرتبطة بالهوية.

قد يتضمن مخطط البيانات التعريفية حقولاً للجهة المُصدرة وفئة الأصل وURI المستند وتاريخ التقييم والولاية القضائية وأمين الحفظ وحالة التحقق وهاش المستند.

يمكن لهذه الحقول مساعدة المستخدمين على فهم التوكن، لكنها لا تنشئ ملكية قانونية تلقائياً.

تعتمد الحقوق القانونية على مستندات الجهة المُصدرة والعقود وترتيبات الحفظ والولاية القضائية وقواعد الاسترداد.

ينبغي لمخطط بيانات أصل من العالم الحقيقي التعريفية أن يفصل معلومات التسويق عن المراجع المهمة قانونياً.

وينبغي أن يتجنب الادعاءات المبهمة التي لا يمكن التحقق منها.

وينبغي أن يحافظ على سلامة المستندات عبر الهاشات أو التخزين المتين متى أمكن.

ينبغي للمستخدمين قراءة المستندات القانونية الرسمية قبل الاعتماد على بيانات أصل من العالم الحقيقي التعريفية.

يمكن للبيانات التعريفية دعم الإفصاح، لكنها لا يمكن أن تحل محل العناية القانونية الواجبة.

مخطط البيانات التعريفية ومخاطر الأمان

يمكن لبيانات التوكن التعريفية أن تنشئ مخاطر أمنية لأن المحافظ والتطبيقات اللامركزية تجلب بيانات من مصادر خارجية وتعرضها.

قد يتضمن ملف بيانات تعريفية ضار روابط تصيد احتيالي أو رسائل مكافآت مزيفة أو صوراً مضللة أو عناوين URL خارجية خطرة.

قد يظهر NFT مزعج في محفظة ويستخدم البيانات التعريفية ليخبر المستخدم بزيارة صفحة مطالبة مزيفة.

وقد تنسخ مجموعة مزيفة الأسماء والصور والسمات من مجموعة حقيقية.

وقد يغير خادم بيانات تعريفية مخترق بيانات تبدو آمنة إلى محتوى ضار لاحقاً.

ينبغي للمحافظ والتطبيقات اللامركزية التعامل مع البيانات التعريفية كمدخلات غير موثوقة.

ينبغي ألا تنفذ نصوصاً برمجية من البيانات التعريفية.

وينبغي لها تنقية الروابط الخارجية ومحتوى الوسائط حيثما أمكن.

ينبغي ألا يدخل المستخدمون عبارات الاسترداد أو المفاتيح الخاصة أو نسخ المحفظة الاحتياطية لأن البيانات التعريفية تطلب منهم ذلك.

لا يثبت مخطط البيانات التعريفية الذي يبدو منظماً أن التوكن آمن.

مخطط البيانات التعريفية وقابلية التعديل

تعني قابلية التعديل أن البيانات التعريفية يمكن أن تتغير بعد سك التوكن.

تحتاج بعض المشاريع إلى قابلية التعديل لأن التوكن ديناميكي.

وتَعِد مشاريع أخرى بأن تكون البيانات التعريفية دائمة وغير متغيرة.

ينبغي أن يتوافق مخطط البيانات التعريفية مع وعد المشروع.

إذا سُوقت مجموعة على أنها فن غير قابل للتغيير، فينبغي ألا تبقى البيانات التعريفية تحت تحكم إداري غير مقيّد.

أما إذا كان التوكن عنصر لعبة، فقد تكون البيانات التعريفية الديناميكية متوقعة.

وإذا كان التوكن بيان اعتماد، فقد تكون التحديثات ضرورية، لكن ينبغي أن تكون قابلة للتدقيق.

ينبغي للمستخدمين التحقق ممن يتحكم في تحديثات البيانات التعريفية.

ينبغي للمطورين توثيق ما إذا كانت البيانات التعريفية غير قابلة للتغيير أو ديناميكية أو خاضعة لتحكم المدير أو الحوكمة.

تُعد قابلية التعديل المخفية أحد أكبر مخاطر الثقة في بيانات NFT التعريفية.

مخطط البيانات التعريفية والتخزين المؤقت

يعني التخزين المؤقت حفظ البيانات التعريفية مؤقتاً حتى تتمكن التطبيقات من تحميل التوكنات بسرعة أكبر.

تخزن المحافظ والأسواق والمستكشفات والمفهرسات البيانات التعريفية مؤقتاً غالباً.

التخزين المؤقت مفيد لأن جلب كل ملف بيانات تعريفية مراراً سيكون بطيئاً.

لكن المشكلة هي أن البيانات التعريفية المخزنة مؤقتاً قد تصبح قديمة.

أثناء الكشف، قد تعرض بعض التطبيقات صوراً مؤقتة حتى بعد نشر البيانات التعريفية النهائية.

وأثناء تحديث ديناميكي، قد تعرض بعض التطبيقات سمات قديمة إلى أن يتجدد التخزين المؤقت.

يمكن لمعايير تحديث البيانات التعريفية أن تساعد العملاء على معرفة وقت تحديث البيانات المخزنة مؤقتاً.

ينبغي للمطورين دعم أحداث التحديث عندما يُتوقع تغير البيانات التعريفية.

ينبغي للمستخدمين فهم أن تأخر العرض قد ينتج عن التخزين المؤقت لا عن فشل التوكن.

يعمل مخطط البيانات التعريفية القوي بأفضل صورة عند إقرانه بسلوك جيد لتحديث ذاكرة التخزين المؤقت.

مخطط البيانات التعريفية والمفهرسات

تجمع المفهرسات بيانات البلوكشين وتنظمها للتطبيقات والمحافظ والمستكشفات والأسواق.

بالنسبة لبيانات التوكن التعريفية، قد تستدعي المفهرسات

وتجلب ملفات JSON وتحلل السمات وتخزن الصور مؤقتاً وتوفر استجابات API.

تحتاج المفهرسات إلى مخططات بيانات تعريفية قابلة للتوقع حتى تعمل بكفاءة.

إذا استخدم كل مشروع أسماء حقول غير معتادة، فسيتعين على المفهرسات بناء منطق مخصص.

إذا كانت ملفات البيانات التعريفية غير صالحة أو بطيئة، فقد تفشل المفهرسات في عرض الأصول بصورة صحيحة.

إذا تغيرت البيانات التعريفية دون أحداث، فقد تعرض المفهرسات بيانات قديمة.

لهذا السبب، يفيد اتساق المخطط منظومة Web3 بأكملها.

ينبغي للمطورين اختبار البيانات التعريفية مع سلوك المفهرسات الشائعة قبل الإطلاق.

ينبغي للمستخدمين معرفة أن المحافظ المختلفة قد تعرض بيانات تعريفية مختلفة إذا حدثت مفهرساتها في أوقات مختلفة.

المفهرسات جزء خفي لكنه مهم من قابلية استخدام بيانات التوكن التعريفية.

أفضل الممارسات للمطورين

استخدم حقول بيانات تعريفية مدعومة على نطاق واسع مثل

و و و.

أعد JSON صالحاً من كل Token URI.

استخدم أسماء وقيم سمات ثابتة عبر المجموعة.

استخدم تخزيناً متيناً لملفات البيانات التعريفية والوسائط.

ثبّت ملفات IPFS أو استخدم خطة تخزين موثوقة طويلة الأجل.

وثق ما إذا كانت البيانات التعريفية قابلة للتعديل أو غير قابلة للتغيير أو ديناميكية.

أصدر أحداث تحديث البيانات التعريفية عند تغيرها.

تحقق من البيانات التعريفية قبل نشرها بشكل دائم.

اختبر سلوك العرض عبر المحافظ والمستكشفات والتطبيقات اللامركزية.

تجنب وضع الوعود القانونية الحساسة داخل بيانات تعريفية قابلة للتحرير فقط.

أفضل الممارسات للمستخدمين

تحقق مما إذا كانت بيانات التوكن التعريفية مخزنة على IPFS أو خادم أو Arweave أو على السلسلة.

تحقق من عنوان العقد الرسمي بدلاً من الوثوق باسم التوكن أو صورته.

توخ الحذر من البيانات التعريفية التي تتضمن روابط خارجية أو ادعاءات مكافآت.

لا توقّع معاملات لمجرد عرض البيانات التعريفية.

لا تدخل عبارة استرداد في أي صفحة مرتبطة ببيانات التوكن التعريفية.

تحقق مما إذا كان المدير يستطيع تغيير البيانات التعريفية.

راجع السمات بعناية خلال فترات الكشف عن NFT.

افهم أن الصورة المعروضة لا تثبت الأصالة.

بالنسبة لتوكنات الأصول من العالم الحقيقي، اقرأ المستندات القانونية خارج ملف البيانات التعريفية.

تعامل مع البيانات التعريفية على أنها معلومات مفيدة، لا دليلاً مستقلاً على القيمة أو الأمان.

أخطاء شائعة في Token Metadata Schema

الخطأ الأول هو نشر JSON غير صالح.

الخطأ الثاني هو استخدام أسماء سمات غير متسقة عبر التوكنات.

الخطأ الثالث هو توجيه حقول الصور إلى ملفات غير متاحة.

الخطأ الرابع هو الاعتماد على خادم مركزي دون إفصاح.

الخطأ الخامس هو تغيير البيانات التعريفية بعد السك دون قواعد واضحة.

الخطأ السادس هو نسيان متطلبات استبدال

في ERC-1155.

الخطأ السابع هو استخدام تنسيقات وسائط غير مدعومة دون صور احتياطية.

الخطأ الثامن هو التعامل مع البيانات التعريفية باعتبارها ملزمة قانونياً بينما هي وصفية فقط.

الخطأ التاسع هو عدم إصدار أحداث تحديث عند تغير البيانات التعريفية.

الخطأ العاشر هو تضمين روابط غير آمنة قد تعرض المستخدمين للتصيد الاحتيالي.

الأسئلة الشائعة

ماذا يعني Token Metadata Schema؟

يعني Token Metadata Schema التنسيق المنظم المستخدم لوصف بيانات تعريفية لتوكن كريبتو، عادةً بصيغة JSON.

هل يقتصر Token Metadata Schema على NFTs؟

لا، هو الأكثر شيوعاً مع NFTs، لكن مخططات البيانات التعريفية يمكن أن تدعم أيضاً التوكنات القابلة للاستبدال وتوكنات الأصول من العالم الحقيقي والتوكنات الخاصة بالتطبيقات.

ما الحقول الشائعة في بيانات NFT التعريفية؟

تشمل الحقول الشائعة

و و و و و.

ما الفرق بين Token URI وToken Metadata Schema؟

يشير Token URI إلى البيانات التعريفية، بينما يحدد Token Metadata Schema بنية البيانات التعريفية الموجودة هناك.

ما هو ERC-721 Metadata JSON Schema؟

هو مخطط البيانات التعريفية الأساسي الذي يصفه ERC-721 لبيانات NFT التعريفية المعادة عبر Token URI.

ما هو ERC-1155 Metadata URI JSON Schema؟

هو مخطط البيانات التعريفية الذي تستخدمه توكنات ERC-1155، بما في ذلك دعم استبدال معرّف التوكن عبر

.

هل يمكن تخزين بيانات التوكن التعريفية على IPFS؟

نعم، يمكن تخزين بيانات التوكن التعريفية على IPFS باستخدام معرّفات المحتوى التي تساعد على التحقق من سلامة المحتوى.

هل يضمن IPFS إتاحة البيانات التعريفية دائماً؟

لا، يحسن IPFS العنونة بالمحتوى، لكن تظل الملفات بحاجة إلى التثبيت أو الخدمة حتى يتمكن المستخدمون من استرجاعها.

هل يمكن أن تتغير بيانات التوكن التعريفية بعد السك؟

نعم، يمكن أن تتغير البيانات التعريفية إذا استخدم المشروع بيانات ديناميكية أو خوادم قابلة للتعديل أو URIs أساسية خاضعة لتحكم المدير أو منطق محلل قابل للتحديث.

ما البيانات التعريفية الديناميكية للتوكن؟

هي بيانات تعريفية تتغير بناءً على الوقت أو اللعب أو نشاط المستخدم أو بيانات Oracle أو حالة العقد أو تحديثات المشروع.

فيما يستخدم ERC-4906؟

يعرّف ERC-4906 أحداث تحديث البيانات التعريفية حتى تعرف المحافظ والتطبيقات متى ينبغي تحديث بيانات NFT التعريفية.

فيما يستخدم ERC-7572؟

يوحّد ERC-7572 الدالة

للبيانات التعريفية على مستوى العقد، مثل اسم المجموعة ووصفها وصورتها.

هل يمكن أن تكون البيانات التعريفية ضارة؟

نعم، قد تتضمن البيانات التعريفية روابط تصيد احتيالي أو ادعاءات مكافآت مزيفة أو صوراً مضللة أو مراجع خارجية غير آمنة.

لماذا تُعرض سمات NFT أحياناً بصورة غير صحيحة؟

قد تُعرض سمات NFT بصورة غير صحيحة لأن السمات غير متسقة أو مفقودة أو بها أخطاء إملائية أو مخزنة مؤقتاً أو منسقة بطريقة لا يفهمها العميل.

ما الذي يجعل Token Metadata Schema جيداً؟

مخطط Token Metadata Schema الجيد صالح ومتسق ومتين وموثق ومتوافق مع الأدوات الشائعة ويوضح ما إذا كانت البيانات التعريفية قابلة للتغير.

الخلاصة

Token Metadata Schema هو التنسيق المنظم الذي يخبر المحافظ والتطبيقات اللامركزية والمستكشفات والألعاب والأسواق والمفهرسات بكيفية قراءة معلومات توكن كريبتو.

وهو الأكثر أهمية لـ NFTs لأن ملكية NFT تُخزن على السلسلة، بينما تُخزن الأسماء والصور والسمات والأوصاف والوسائط غالباً عبر ملفات البيانات التعريفية.

يعرّف كل من ERC-721 وERC-1155 أنماطاً للبيانات التعريفية تساعد التطبيقات على حل معلومات التوكن وعرضها باتساق.

يسهّل مخطط البيانات التعريفية الجيد فهم التوكنات وتصفيتها وتداولها والتحقق منها واستخدامها داخل التطبيقات.

أما المخطط الضعيف فقد يسبب صوراً معطلة وسمات مفقودة وبيانات قديمة ومخاطر تصيد احتيالي وارتباكاً لدى المستخدمين.

تشمل الحقول المهمة

و و و و والخصائص الخاصة بالمشروع.

تؤثر خيارات التخزين مثل IPFS وHTTPS وArweave والبيانات على السلسلة في الاستمرارية وقابلية التعديل والتكلفة والثقة.

ينبغي أن تكون تحديثات البيانات التعريفية شفافة، خصوصاً بالنسبة للكشف وNFTs الديناميكية وأصول الألعاب وبيانات الاعتماد وتوكنات الأصول من العالم الحقيقي.

ينبغي للمطورين التحقق من البيانات التعريفية واستخدام تخزين متين وتوثيق قابلية التعديل وإصدار أحداث التحديث والاختبار عبر أدوات Web3 الشائعة.

ينبغي للمستخدمين التحقق من عناوين العقود وتجنب روابط البيانات التعريفية المشبوهة وفهم مخاطر التخزين والتعامل مع البيانات التعريفية بوصفها وصفية لا دليلاً مطلقاً.

في معجم الكريبتو، ينبغي فهم Token Metadata Schema على أنه تنسيق البيانات الذي يمنح توكنات الكريبتو معنى مقروءاً بشرياً ويتيح لمنظومة Web3 عرض معلومات التوكن باتساق وأمان.