Skip to main content

ما هو نموذج الـ token

ملاحظة: هذا المستند هو ترجمة آلية للنسخة الإنجليزية الأصلية.

ما هو نموذج الـ token

يصف نموذج الـ token (token model) الدور الذي يؤديه الـ token ضمن منظومة المشروع. فبينما يحدّد معيار الـ token الصيغة التقنية (كيف يُحوَّل الـ token ويُتتبَّع ويُوافَق عليه)، يجيب نموذج الـ token عن سؤال مختلف جوهريًا: لأي غرض هذا الـ token؟ فهو يلتقط الغرض الاقتصادي والوظيفي للـ token — سواء أكان يمنح وصولًا إلى خدمات، أم يمكّن التصويت في الحوكمة، أم يدفع رسوم المعاملات، أم يكافئ المشاركين في الشبكة، أم لا يخدم أي غرض يتجاوز المضاربة.

وفهم نماذج الـ token جوهري لتقييم أي مشروع ذكاء اصطناعي معتمد على الكريبتو. فكثير من المشاريع تُصدِر عملات، لكن مجرد وجود token لا يعني أنه ضروري لعمل المشروع. فبعض العملات لها تكامل عميق قابل للتحقق مع خدمات الذكاء الاصطناعي في المشروع. وأخرى مُلصَقة كفكرة لاحقة، تضيف طبقة مالية إلى منتج كان سيعمل بالكفاءة نفسها دونها. ونموذج الـ token هو العدسة الأولى للتمييز بين هاتين الحالتين.

في DecAIHub، يُسجَّل نموذج الـ token في حقل Token model (token_type) في كل بطاقة مشروع. وتشمل القيم الشائعة Utility token وGovernance token وFee-mechanism وStaking وNo token. وتجمع مشاريع كثيرة بين نماذج متعددة — فقد يعمل token واحد كـ utility token وgovernance token معًا، أو يجمع بين الـ staking ووظائف آلية الرسوم. ويلتقط الحقل الأدوار الأساسية، وتصف أقسام الأدلة في بطاقة المشروع مدى التحقق من تلك الأدوار.

باختصار: نموذج الـ token يصف لأي غرض يُستخدم token المشروع — دوره الاقتصادي والوظيفي في المنظومة. وهو مكمّل لمعيار الـ token، الذي يصف الصيغة التقنية فقط.

كيف تعمل نماذج الـ token

طيف منفعة الـ token

توجد نماذج الـ token على طيف يمتد من "متكامل بعمق" إلى "بلا دور وظيفي". وفهم هذا الطيف مفتاح لتقييم مشاريع الذكاء الاصطناعي المعتمدة على الكريبتو:

تكامل عالٍ — الـ token مطلوب بنيويًا لكي يعمل النظام. ومن الأمثلة العملات التي يجب عمل staking لها لتشغيل عقدة حوسبة ذكاء اصطناعي، أو العملات المحروقة كدفع مقابل كل استدعاء استدلال، أو العملات المستخدمة كوسيط التبادل الوحيد داخل سوق لامركزي. وإزالة الـ token من شأنها أن تعطّل الوظيفة الأساسية للنظام.

تكامل متوسط — يوفّر الـ token حوافز اقتصادية أو حقوق حوكمة لكنه غير مطلوب بدقة للخدمة الأساسية. ومن الأمثلة governance tokens التي تتيح للحاملين التصويت على ترقيات البروتوكول، أو عملات المكافآت الموزَّعة على واسمي البيانات. ويمكن للنظام نظريًا أن يعمل دون الـ token، لكن بنية الحوافز ستكون مختلفة.

تكامل منخفض أو معدوم — الـ token موجود لكن لا دور قابلًا للتحقق له في عمليات المشروع. فقد يكون المشروع أطلق token لأغراض جمع التمويل، أو قد يمثّل الـ token سردية مضاربية ("AI token") دون أن يكون منسوجًا في آليات المنتج. وفي DecAIHub، تُحدَّد هذه الحالات عبر بُعد Token necessity ضمن DecAI Fit.

أنواع نماذج الـ token الشائعة

فيما يلي نماذج الـ token الأكثر شيوعًا في مشاريع الذكاء الاصطناعي المعتمدة على الكريبتو. ويحدّد كل نموذج علاقة مختلفة بين الـ token ووظيفة المشروع.

Utility token

يوفّر الـ utility token وصولًا إلى منتج أو خدمة ضمن منظومة المشروع. فالـ token هو "المفتاح" الذي يفتح الوظيفة — فدونه لا يستطيع المستخدم استعمال ميزات معينة أو يجب أن يدفع رسومًا أعلى.

آليات الـ utility الشائعة في مشاريع الذكاء الاصطناعي المعتمدة على الكريبتو:

الآلية كيف تعمل سياق مثالي
الوصول الـ token مطلوب لاستخدام الخدمة (الوصول إلى API، الميزات المميزة) سوق استدلال ذكاء اصطناعي يتطلب دفعًا بالـ token لكل استعلام
المدفوعات الـ token يُستخدم كوسيط التبادل داخل المنظومة سوق بيانات يدفع فيه المشترون للبائعين بـ token المشروع
المكافآت الـ token يُوزَّع على المشاركين الذين يسهمون بعمل مزوّدو الحوسبة يُكافَؤون على ساعات GPU؛ واسمو البيانات يُكافَؤون على التعليقات التوضيحية
الحوافز الـ token يُستخدم لإقلاع مشاركة الشبكة أو إدامتها مكافآت مبكرة لجذب المُصدِّقين أو مزوّدي الحوسبة أو المساهمين بالبيانات

تعتمد القيمة المقترحة للـ utility token على ما إذا كانت المنفعة حقيقية وقابلة للتحقق. فالمشروع الذي يدّعي أن token الخاص به "يوفّر وصولًا إلى خدمات ذكاء اصطناعي" لكنه لا يقدّم منتجًا أو API عاملًا له utility token بالاسم فقط.

Governance token

يمنح الـ governance token الحاملين حق التصويت على قرارات البروتوكول — تغييرات المعلمات، وتخصيصات الخزينة، ومقترحات الترقية، والتوجّه الاستراتيجي. وgovernance tokens هي مكافئ البلوكتشين لأسهم التصويت، وإن كانت عادةً لا تمنح حقوق ملكية أو مشاركة في الأرباح بالمعنى القانوني.

في مشاريع الذكاء الاصطناعي المعتمدة على الكريبتو، قد تشمل قرارات الحوكمة:

  • أي نماذج ذكاء اصطناعي يدعمها البروتوكول.
  • كيف تُوزَّع مكافآت الحوسبة.
  • أي مصادر بيانات تُعتمَد.
  • ما إذا كان يُدمَج بلوكتشين جديد أو يُوسَّع إلى سلسلة جديدة.

تعتمد فعالية الـ governance token على مدى نشاط مشاركة المجتمع ومقدار السلطة الفعلية لآلية التصويت. فالـ governance token الذي يحتفظ فيه الفريق المؤسِّس بحق النقض أو تحتفظ فيه محفظة واحدة بأغلبية العملات هو حوكمة في الشكل لا في الجوهر.

Fee-mechanism

يكون الـ token من نوع fee-mechanism مطلوبًا لدفع الرسوم ضمن البروتوكول. وخلافًا للـ utility token الذي يمنح وصولًا، يُستهلَك الـ token من نوع آلية الرسوم أو يُعاد توزيعه مع كل معاملة أو عملية. ومن الأمثلة:

  • عملات تُحرَق مع كل استدعاء استدلال ذكاء اصطناعي، ما يخلق ضغطًا انكماشيًا مرتبطًا بالاستخدام.
  • عملات يدفعها المستخدمون وتُوزَّع على المُصدِّقين أو مزوّدي الحوسبة كتعويض.
  • عملات تُؤخَذ كرسم بروتوكول وتُوجَّه إلى خزينة لتمويل التطوير.

تربط عملات آلية الرسوم تداول الـ token مباشرةً بمقاييس استخدام المشروع. فإذا كانت خدمة الذكاء الاصطناعي مستخدمة بكثافة، تدفّق مزيد من العملات عبر آلية الرسوم. وإذا لم يكن للخدمة مستخدمون، لم يكن لآلية الرسوم نشاط.

Staking

يعني الـ staking كنموذج token أنه يجب قفل الـ token (عمل staking له) للمشاركة في الشبكة بدور محدد. ويخدم الـ staking أغراضًا متعددة:

  • الأمن — في شبكات PoS، يؤمّن الـ staking السلسلة باشتراط أن يضع المُصدِّقون رأس مال على المحك.
  • ضمان الجودة — في شبكات الذكاء الاصطناعي، قد يُشترَط الـ staking قبل أن تتمكن عقدة من الإسهام بالحوسبة أو البيانات أو تقييم النماذج. وتعمل الحصة كسند: فإذا أنتجت العقدة عملًا منخفض الجودة، أمكن اقتطاع جزء من حصتها (slashed).
  • الوصول — تتطلب بعض البروتوكولات عمل staking لقدر أدنى قبل أن يتمكن مستخدم أو عقدة من الوصول إلى الميزات المميزة، أو الطوابير ذات الأولوية الأعلى، أو أحمال العمل الأكبر.

يخلق الـ staking مساءلة. فمزوّد الحوسبة الذي يجب عليه عمل staking للعملات قبل تقديم موارد GPU لديه حافز مالي لتقديم خدمة موثوقة. ويمكن مصادرة جزء من العملات المقفلة إذا قدّم المزوّد نتائج استدلال غير صحيحة أو خرج عن الاتصال.

No token

يعني الـ no token أن المشروع ليس لديه token خاص به. وهذا خيار تصميمي صالح ومرغوب أحيانًا. فقد يعمل المشروع على بلوكتشين قائم، ويدفع الرسوم بالـ token الأصلي للسلسلة (ETH، SOL، BNB)، ويموّل عملياته عبر المنح أو الإيرادات أو رأس المال الجريء. وغياب الـ token لا يعني أن المشروع أقل جدية أو أقل وظيفية — بل يوحي أحيانًا بأن الفريق أعطى الأولوية لبناء منتج بدلًا من إطلاق أصل مالي.

في DecAIHub، تُقيَّم المشاريع التي تحمل Token model: No token على أبعادها في الذكاء الاصطناعي والسلسلة دون عدسة Token necessity.

الجمع بين نماذج الـ token

معظم العملات في الواقع لا تندرج بدقة في فئة واحدة. فكثيرًا ما يجمع token المشروع بين أدوار متعددة:

  • Utility + Governance — يدفع الـ token ثمن خدمات الذكاء الاصطناعي ويمنح حقوق تصويت على ترقيات البروتوكول.
  • Staking + Fee-mechanism — يجب على المُصدِّقين عمل staking للـ token للمشاركة، ويدفع المستخدمون رسومًا بالـ token نفسه تُوزَّع جزئيًا على المشاركين في الـ staking.
  • Utility + Staking + Governance — يوفّر الـ token وصولًا إلى الخدمة، ويجب عمل staking له للمشاركة، ويمنح حقوق تصويت في الحوكمة.

وقد يُدرِج حقل Token model في DecAIHub قيمًا متعددة لتعكس هذه التركيبات. وتصف بطاقة المشروع وأقسام الأدلة كيف يُطبَّق كل دور ويُتحقَّق منه.

لماذا يهم لمشاريع الذكاء الاصطناعي المعتمدة على الكريبتو

نموذج الـ token من أهم الأبعاد لتقييم مشروع ذكاء اصطناعي معتمد على الكريبتو لأنه يكشف العلاقة بين الـ token والمنتج الفعلي:

  • Token necessity — هل يحتاج المشروع إلى token لكي يعمل، أم أُضيف الـ token أساسًا لجمع التمويل أو المضاربة؟ ويُلتقَط هذا في بُعد Token necessity في DecAIHub. فالمشروع الذي تعمل فيه خدمة الذكاء الاصطناعي دون الـ token تكون ضرورة token لديه أضعف من مشروع يكون فيه الـ token آلية الدفع الوحيدة للاستدلال.
  • مواءمة الحوافز — يوائم نموذج token جيد التصميم مصالح المستخدمين والمزوّدين والبروتوكول. فمزوّدو الحوسبة يكسبون عملات مقابل العمل الجيد، وحاملو الـ token يستفيدون من نمو الاستخدام، والمستخدمون يحصلون على وصول إلى الخدمات. ويمكن لنموذج رديء التصميم أن يخلق حوافز غير متوائمة (مثل مكافأة الكم على حساب الجودة).
  • الاستدامة — نماذج الـ token التي تعتمد كليًا على مكافآت تضخمية (طباعة عملات جديدة لدفع المزوّدين) تواجه أسئلة استدامة طويلة الأمد. أما نماذج آلية الرسوم المرتبطة بالاستخدام الفعلي فأكثر استدامة عمومًا لأنها تربط تداول الـ token بالطلب الفعلي على الخدمة.
  • الأعلام الحمراء — إذا لم يتصل نموذج token المشروع بمنتجه الأساسي بأي طريقة قابلة للتحقق، كان هذا علمًا أحمر لـ token-washing: استخدام token لجذب الاهتمام الاستثماري دون منفعة حقيقية.

أين يظهر هذا في بطاقات مشاريع DecAIHub

يسجّل حقل Token model (token_type) في بطاقة مشروع DecAIHub الأدوار الاقتصادية الأساسية لـ token المشروع. وتشمل القيم الشائعة:

  • Utility token — يوفّر الـ token وصولًا إلى الخدمات أو يُستخدم كوسيط تبادل.
  • Governance token — يمنح الـ token حقوق تصويت على قرارات البروتوكول.
  • Fee-mechanism — يُستهلَك الـ token أو يُعاد توزيعه كجزء من بنية رسوم البروتوكول.
  • Staking — يجب قفل الـ token للمشاركة في أدوار الشبكة.
  • No token — المشروع ليس لديه token خاص به.

كثيرًا ما يُقرَن هذا الحقل بـ:

  • معيار الـ token — الصيغة التقنية للـ token (ERC-20، BEP-20، SPL، token أصلي).
  • Token necessity (جزء من DecAI Fit) — مدى ضرورة الـ token لعمل المشروع.
  • أقسام الأدلة — أي مصادر Tier-1 أو Tier-2 أو Tier-3 تتحقق من الدور المُدَّعى للـ token.

ما الذي لا يثبته نموذج الـ token وحده

  • نموذج الـ token لا يثبت أن الـ token ضروري. فيمكن لمشروع أن يصف token الخاص به بأنه "utility" بينما لا يقدّم خدمة عاملة تتطلبه. فالوسم يصف الدور المقصود؛ والتحقق يتطلب أدلة.
  • نموذج الـ token لا يثبت أن للمشروع ذكاءً اصطناعيًا حقيقيًا. فيمكن لمشروع أن يكون له نموذج token جيد التصميم (staking، آلية رسوم، utility) بلا أي مكوّن ذكاء اصطناعي قابل للتحقق. فتصميم الـ token وعمق الذكاء الاصطناعي بُعدان مستقلان.
  • نموذج الـ token لا يثبت القيمة. فالـ governance token ليس ذا قيمة بطبيعته لمجرد أنه يمنح حقوق تصويت. وتعتمد قيمته على ما الذي يُحكَم وما إذا كانت آلية الحوكمة ذات سلطة فعلية.
  • نموذج الـ token لا يثبت اللامركزية. فيمكن لـ staking token أن يوجد في نظام يتحكم فيه كيان واحد بأغلبية المعروض المقفل، ما يمركز الشبكة فعليًا رغم آلية الـ staking.
  • نموذج الـ token لا يمنع token-washing. فيمكن لمشروع أن يصف نموذج token معقدًا في ورقته البيضاء دون تطبيق أي منه. ويقيّم DecAIHub نموذج الـ token مقابل أدلة قابلة للتحقق، لا مقابل الادّعاءات وحدها.

لا تخلط بين

  • معيار الـ token — يصف المعيار الصيغة التقنية (ERC-20، BEP-20، SPL). ويصف النموذج الدور الاقتصادي (utility، governance، staking). وهما يجيبان عن سؤالين مختلفين: "كيف يعمل تقنيًا؟" مقابل "لأي غرض هو؟".
  • الـ tokenomics — يغطي الـ tokenomics التصميم الاقتصادي الأوسع: إجمالي المعروض، وجدول الإصدار، وفترات الـ vesting، وآليات الحرق، وإدارة الخزينة. ونموذج الـ token مكوّن واحد من الـ tokenomics، يركّز تحديدًا على الدور الوظيفي للـ token.
  • سعر الـ token — يصف نموذج الـ token المنفعة والوظيفة، لا القيمة السوقية. فيمكن أن يكون لـ utility token سعر منخفض؛ ويمكن أن يكون لـ meme token سعر مرتفع. فالسعر تحدّده ديناميكيات السوق، لا وسم النموذج.
  • الإجماع — يصف الإجماع كيف تتفق الشبكة على الكتل. وتستخدم آلية إجماع PoS الـ staking لأمن الشبكة، وهو أمر متصل بنموذج الـ staking token لكنه متمايز عنه. فيمكن لمشروع أن يكون له نموذج staking token على سلسلة PoW، أو token بلا staking على سلسلة PoS.

الأسئلة المتكررة

هل يمكن أن يكون لمشروع نماذج token متعددة؟

نعم، ومعظمها كذلك. فكثيرًا ما يعمل token واحد كـ utility token وgovernance token معًا، أو يجمع بين الـ staking ووظائف آلية الرسوم. وقد يُدرِج حقل Token model في DecAIHub قيمًا متعددة لتعكس ذلك. والسؤال الرئيسي ليس كم نموذجًا يُدَّعى بل كم نموذجًا مُطبَّق بشكل قابل للتحقق.

هل الـ utility token ضروري دائمًا للمشروع؟

لا. تُصدِر بعض المشاريع utility token لأنها تحتاج فعلًا إلى وسيط تبادل أو آلية وصول أصلية. وأخرى تُصدِره لأنه نمط شائع لجمع التمويل في الكريبتو، حتى عندما تستطيع الخدمة الأساسية أن تعمل بـ ETH أو SOL أو عملة مستقرة. ويساعد بُعد Token necessity في DecAIHub على التمييز بين هاتين الحالتين بالسؤال عمّا إذا كان الـ token مطلوبًا بنيويًا أم مجرد مريح.

ما هو الـ token-washing؟

الـ token-washing هو ممارسة تصميم token والترويج له أساسًا لجذب الاهتمام الاستثماري، دون بناء منفعة حقيقية في منتج المشروع. فالمشروع الذي يصف نموذج token معقدًا في ورقته البيضاء لكن دون منتج عامل، ودون نشاط على السلسلة، ودون تكامل token قابل للتحقق، يمارس الـ token-washing. ويقيّم DecAIHub ادّعاءات الـ token مقابل أدلة Tier-1 وTier-2 وTier-3 لتحديد هذا النمط.

كيف يتصل نموذج الـ token بالذكاء الاصطناعي في مشروع؟

يحدّد نموذج الـ token كيف يتفاعل الـ token مع خدمات المشروع، بما فيها خدمات الذكاء الاصطناعي. ففي مشروع ذكاء اصطناعي معتمد على الكريبتو جيد التصميم، يكون نموذج الـ token مقترنًا بإحكام بمنتج الذكاء الاصطناعي: يدفع المستخدمون ثمن استدلال الذكاء الاصطناعي بالـ token، ويكسب مزوّدو الحوسبة الـ token مقابل الإسهام بوحدات GPU، أو يقوم المُصدِّقون بعمل staking للـ token قبل أن يتمكنوا من تقييم مخرجات النماذج. وفي مشروع رديء التصميم، يوجد الـ token بمعزل عن مكوّن الذكاء الاصطناعي.

ماذا يعني "No token" في بطاقة مشروع DecAIHub؟

يعني أن المشروع ليس لديه token عملة مشفّرة خاص به. وقد لا يزال المشروع يستخدم عملات قائمة (ETH لرسوم الغاز، عملات مستقرة للمدفوعات) لكنه لم يُصدِر token خاصًا. وهذه تسمية محايدة — فهي لا تعني أن المشروع أفضل أو أسوأ من مشروع لديه token. فبعض مشاريع الذكاء الاصطناعي القوية تعمل دون token خاص بها؛ وبعض الضعيفة تُصدِر عملات كنشاط أساسي.

هل الـ token من نوع آلية الرسوم مثل دفع رسوم الغاز؟

لا. رسوم الغاز تُدفَع بالـ token الأصلي للبلوكتشين (ETH على Ethereum، SOL على Solana) وتذهب إلى المُصدِّقين مقابل معالجة المعاملات. أما الـ token من نوع آلية الرسوم فيعمل على مستوى التطبيق: يُستهلَك token المشروع نفسه أو يُعاد توزيعه عندما يتفاعل المستخدمون مع خدمات المشروع المحددة. على سبيل المثال، قد تفرض منصة استدلال ذكاء اصطناعي لامركزية رسمًا بـ token الخاص بها على كل استدعاء API، منفصلًا عن رسم الغاز الأساسي المدفوع للبلوكتشين.

مراجع خارجية

انظر أيضًا