Skip to main content

ما هي سلسلة الكتل غير المتوافقة مع EVM (non-EVM)

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

ما هي سلسلة الكتل غير المتوافقة مع EVM (non-EVM)

سلسلة الكتل غير المتوافقة مع EVM (non-EVM blockchain) هي أي سلسلة كتل لا تستخدم آلة Ethereum الافتراضية كمحرك تنفيذ لها. فبدلًا من تشغيل رمز Solidity الثنائي، تستخدم سلاسل non-EVM آلات افتراضية مختلفة، ولغات برمجة مختلفة، ونماذج تنفيذ مختلفة. وتشمل الأمثلة Solana (SVM/Sealevel)، والسلاسل القائمة على Cosmos (CosmWasm، ووحدات خاصة بالتطبيقات)، وNEAR (بيئة تشغيل قائمة على WebAssembly)، وSui وAptos (MoveVM)، وBittensor (بيئة تشغيل مخصصة قائمة على Substrate).

يهم هذا التمييز لأن اختيار الآلة الافتراضية يحدد لغات البرمجة التي يستخدمها المطورون، وكيف تتصرف العقود الذكية، وما الأدوات المتاحة، ومدى سهولة تفاعل المشروع مع سلاسل أخرى. فالمشروع المبني على سلسلة non-EVM لا يستطيع ببساطة نسخ ولصق عقود Solidity من Ethereum — بل يحتاج إلى قاعدة شيفرة مختلفة، ومهارات مطورين مختلفة، ومجموعة مختلفة من أدوات البنية التحتية.

باختصار: تستخدم سلاسل الكتل غير المتوافقة مع EVM بيئات تنفيذ غير آلة Ethereum الافتراضية. ويعني ذلك لغات برمجة مختلفة، وأدوات مختلفة، ومفاضلات معمارية مختلفة — لكن أيضًا إمكانية لخصائص أداء لا تستطيع EVM تحقيقها.

كيف يختلف تنفيذ non-EVM عن EVM

EVM آلة افتراضية قائمة على المكدّس تنفّذ رمز Solidity الثنائي تسلسليًا، وتستخدم أعدادًا صحيحة بطول 256 بت، وتقيس الحوسبة عبر gas. أما سلاسل non-EVM فتنحرف عن هذا النموذج بطرق متنوعة:

آلات افتراضية مختلفة

السلسلة / المنظومة الآلة الافتراضية اللغة الأساسية الفرق المعماري الرئيسي
Solana SVM (Sealevel) Rust تنفيذ متوازٍ للمعاملات عبر الوصول المعلَن للحالة
سلاسل Cosmos CosmWasm / وحدات أصلية Rust (CosmWasm)، Go (الوحدات) سلسلة كتل خاصة بالتطبيق مع اتصال مدمج عبر السلاسل (IBC)
NEAR WebAssembly (Wasm) Rust، AssemblyScript تنفيذ مجزّأ (sharded) مع استدعاءات غير متزامنة عبر الشظايا
Sui MoveVM Move نموذج حالة محوره الكائن يتيح التنفيذ المتوازي
Aptos MoveVM Move محرك تنفيذ متوازٍ Block-STM
Bittensor بيئة تشغيل Substrate Rust تنسيق خاص بالذكاء الاصطناعي؛ الشبكات الفرعية (subnets) كوحدات تنفيذ

تتخذ كل آلة افتراضية مفاضلات مختلفة. فآلة Solana الافتراضية SVM تتطلب من المعاملات أن تعلن مسبقًا الحالة التي ستصل إليها، ما يتيح لبيئة التشغيل تنفيذ المعاملات غير المتعارضة بالتوازي — وهو ما لا تستطيع EVM فعله أصلًا. وتستبدل سلاسل Cosmos نموذج التنفيذ المشترك بالكامل: فيحصل كل تطبيق على سلسلته الخاصة بمنطق مخصص، متصلة بسلاسل أخرى عبر بروتوكول IBC. أما السلاسل القائمة على Move (Sui وAptos) فتستخدم نموذج برمجة موجّهًا نحو الموارد يمنع فئات معينة من الأخطاء (مثل إعادة الدخول - reentrancy) على مستوى اللغة.

لغات برمجة مختلفة

تهيمن Solidity على منظومة EVM — وهي لغة صُمّمت خصيصًا لعقود Ethereum الذكية. أما سلاسل non-EVM فتستخدم لغات عامة الأغراض أو بدائل مصممة لغرض محدد:

  • Rust — تستخدمها Solana (عبر إطار Anchor)، وCosmos (عبر CosmWasm)، وNEAR، والسلاسل القائمة على Substrate بما فيها Bittensor. وضمانات سلامة الذاكرة في Rust وأداؤها يجعلانها ملائمة للبرامج على السلسلة.
  • Move — طُوّرت أصلًا في Facebook/Diem، وتُستخدم الآن في Sui وAptos. وتعامل Move الأصول على السلسلة كموارد من الدرجة الأولى لا يمكن تكرارها أو تدميرها عرضًا، ما يقلّل فئة من ثغرات العقود الذكية الشائعة.
  • Go — تُستخدم لتطوير الوحدات الأصلية في سلاسل Cosmos SDK. ويشغّل المدققون ملفات ثنائية مُترجَمة بـ Go مباشرةً.
  • AssemblyScript — لغة شبيهة بـ TypeScript تُترجَم إلى WebAssembly، تُستخدم كلغة بديلة لتطوير NEAR.

يعني هذا التنوع اللغوي أن المطورين لا يستطيعون نقل مهارات Solidity مباشرةً إلى سلاسل non-EVM. فالمشروع المبني على Solana يحتاج إلى مهندسي Rust؛ والمشروع المبني على Sui يحتاج إلى مهندسي Move. ويؤثر مجمّع مواهب المطورين لكل لغة في مدى سرعة بناء المشروع وتكراره.

خصائص أداء مختلفة

كثيرًا ما تحقق سلاسل non-EVM ملامح أداء مختلفة:

  • التنفيذ المتوازي — تنفّذ Solana وSui وAptos المعاملات غير المتعارضة بالتوازي، ما قد يقدّم إنتاجية أعلى من نموذج التنفيذ التسلسلي لـ EVM.
  • رسوم أدنى وأكثر قابلية للتنبؤ — لدى بعض سلاسل non-EVM بنى رسوم مصممة للإنتاجية العالية منذ البداية، ما يتفادى أسواق الرسوم المتقلبة التي قد تشهدها سلاسل EVM أثناء الازدحام.
  • نماذج حالة مخصصة — يمكن لسلاسل non-EVM استخدام نماذج حالة محسّنة لأنماط وصول محددة. فنموذج Sui المحوره الكائن، مثلًا، يتيح ملكية لكل كائن ومعالجة متوازية يصعب تنفيذها على EVM.

تأتي مزايا الأداء هذه مع مفاضلات: منظومات مطورين أصغر، وأدوات أقل نضجًا، وشركات تدقيق أقل ذات خبرة ذات صلة، وقابلية تركيب أقل مع منظومة DeFi والرموز الكبيرة القائمة على EVM.

لماذا يهم ذلك مشاريع الذكاء الاصطناعي والتشفير

لاختيار الآلة الافتراضية تبعات عملية على المشاريع المرتبطة بالذكاء الاصطناعي على سلسلة الكتل:

  • مرونة التنفيذ — يمكن لسلاسل non-EVM دعم نماذج تنفيذ أنسب لأعباء تنسيق الذكاء الاصطناعي. فالتنفيذ المتوازي، وآلات الحالة المخصصة، ومجموعات التعليمات الأقل أعباءً قد تخدم بشكل أفضل المعاملات عالية التردد المرتبطة بالذكاء الاصطناعي (إسناد مهام الحوسبة، وتقديم النتائج، وتحديثات سجل النماذج).
  • ملاءمة اللغة — تتوافق السلاسل القائمة على Rust جيدًا مع بنية الذكاء الاصطناعي/التعلّم الآلي، إذ إن الكثير من أدوات الذكاء الاصطناعي (المكونات الحرجة للأداء، وتنسيق GPU، وبرمجة الأنظمة) مكتوب بـ Rust أو يتكامل جيدًا مع شيفرة Rust.
  • التصميم الخاص بالتطبيق — تتيح سلاسل تطبيقات Cosmos (appchains) والشبكات الفرعية لـ Bittensor لمشاريع الذكاء الاصطناعي بناء منطق تنفيذ مخصص على مستوى السلسلة، من دون قيود مجموعة تعليمات EVM ونموذج gas الخاص بها.
  • مفاضلات المنظومة — لا تستطيع مشاريع non-EVM الاستفادة بسهولة من منظومة EVM الكبيرة من بروتوكولات DeFi، وجسور الرموز، وبنية المحافظ التحتية. فمشاريع الذكاء الاصطناعي على سلاسل non-EVM يجب إما أن تبني هذه البنية التحتية بنفسها، أو تعتمد على جسور عبر السلاسل، أو تقبل بمنظومة أولية أصغر.

في بطاقات مشاريع DecAIHub، يخبر Type: non-EVM القارئ بأن المشروع لا يستخدم Solidity، ولا يمكنه النشر على سلاسل متوافقة مع EVM من دون إعادة كتابة، ويعمل في منظومة تقنية مختلفة.

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

في بطاقات مشاريع DecAIHub، تظهر تسمية non-EVM في:

  • Type — non-EVM يشير إلى أن العقود الذكية للمشروع أو منطقه على السلسلة يستخدم آلة افتراضية غير EVM. ويؤثر ذلك في الأدوات واللغات والمعايير السارية.
  • Main chain — تُدرج سلسلة non-EVM المحددة (Solana، أو Bittensor، أو سلسلة Cosmos، أو Sui، إلخ). ولكل سلسلة آلتها الافتراضية ولغتها ومنظومتها الخاصة.
  • Token standard — لسلاسل non-EVM معايير رموز خاصة بها. فـ Solana تستخدم رموز SPL؛ وسلاسل Cosmos تستخدم تسميات أصلية أو CW-20 (CosmWasm)؛ والسلاسل القائمة على Move تستخدم موارد العملة/الأصل القابل للاستبدال. وهذه ليست قابلة للتبادل مع ERC-20.
  • العقود الذكية / المنطق على السلسلة — تختلف لغة البرمجة والإطار عن مشاريع EVM. فبرامج Solana مكتوبة بـ Rust (Anchor)، وعقود Cosmos بـ Rust (CosmWasm) أو Go، وهكذا.

ما لا يثبته تصنيف non-EVM وحده

  • non-EVM لا يعني أداءً أفضل. فرغم أن بعض سلاسل non-EVM تقدّم تنفيذًا متوازيًا أو رسومًا أدنى، يعتمد الأداء على السلسلة المحددة، وبنية مدققيها التحتية، والحمل الحالي — لا على اختيار الآلة الافتراضية فحسب.
  • non-EVM لا يثبت التطور التقني. فاختيار سلسلة non-EVM قرار يتعلق بالبنية التحتية. وهو لا يشير إلى جودة مكوّن الذكاء الاصطناعي للمشروع، أو شيفرته، أو منتجه.
  • non-EVM لا يعني أن المشروع لا يستطيع التفاعل مع سلاسل EVM. فالعديد من مشاريع non-EVM تستخدم الجسور، أو الأوراكل، أو الرموز المغلَّفة (wrapped) للاتصال بـ Ethereum ومنظومات EVM الأخرى. والتفاعل عبر السلاسل ممكن؛ لكنه يتطلب بنية تحتية إضافية فحسب.
  • اختلاف الآلة الافتراضية لا يعني ضمانات أمان مختلفة. فثغرات العقود الذكية، وأخطاء المنطق، ومخاطر المركزية موجودة على جميع السلاسل بصرف النظر عن الآلة الافتراضية. ولغات non-EVM مثل Rust وMove تلغي بعض فئات الأخطاء لكنها تُدخل أخرى.
  • تسمية non-EVM لا تفسّر لماذا اختار المشروع تلك السلسلة. فقد يُدفع الاختيار باحتياجات الأداء، أو خبرة فريق المطورين، أو حوافز المنظومة، أو ببساطة بالمكان الذي بدأ فيه الفريق المؤسس. ومن دون سياق إضافي، تكون التسمية وحدها معلوماتية، لا تقييمية.

لا تخلط بين

  • EVM — EVM هي آلة Ethereum الافتراضية. وnon-EVM معرَّفة في مقابلها: فأي سلسلة لا تستخدم EVM تقع في فئة non-EVM.
  • Ethereum — Ethereum هي سلسلة EVM الأصلية. وكون السلسلة non-EVM يعني أنها ليست Ethereum ولا تستخدم محرك تنفيذ Ethereum — لكنها قد تظل تتفاعل مع Ethereum عبر الجسور أو بروتوكولات عبر السلاسل.
  • Solana — Solana واحدة من سلاسل non-EVM المحددة بآلتها الافتراضية الخاصة (SVM). و"non-EVM" فئة واسعة تشمل Solana وCosmos وSui وAptos وNEAR وBittensor وغيرها كثير.
  • "مناهضة Ethereum" — كون السلسلة non-EVM ليس موقفًا ضد Ethereum. فالعديد من سلاسل non-EVM تتعايش مع Ethereum وتستفيد من السيولة المجسورة. واختيار الآلة الافتراضية يعكس أولويات تصميم مختلفة، لا معارضة أيديولوجية.
  • عدم التوافق — لا تستطيع سلاسل non-EVM تشغيل رمز EVM الثنائي أصلًا، لكن هذا لا يعني أنها معزولة. فالجسور عبر السلاسل، وبروتوكولات المراسلة (مثل IBC وLayerZero وWormhole)، والرموز المغلَّفة تتيح قابلية التشغيل البيني بين منظومات EVM وnon-EVM.

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

ما أكثر سلاسل non-EVM شيوعًا التي تستخدمها مشاريع الذكاء الاصطناعي والتشفير؟

Solana وBittensor من أكثر سلاسل non-EVM المصادَفة في مجال الذكاء الاصطناعي والتشفير الذي يتعقّبه DecAIHub. فإنتاجية Solana العالية ومنظومتها القائمة على Rust تجذبان مشاريع الذكاء الاصطناعي التي تحتاج إلى تنسيق سريع ومنخفض التكلفة على السلسلة. وBittensor مصمَّمة لغرض الذكاء الاصطناعي اللامركزي، بشبكات فرعية مكرّسة لمهام ذكاء اصطناعي محددة. وسلاسل تطبيقات Cosmos نمط آخر، خصوصًا للمشاريع التي تريد بيئة تنفيذ مخصصة بالكامل مع اتصال مدمج عبر السلاسل عبر IBC.

هل يمكن لمشروع non-EVM النشر أيضًا على سلاسل EVM؟

نعم، لكن ذلك يتطلب قاعدة شيفرة منفصلة. فالمشروع المكتوب بـ Rust لـ Solana لا يمكن نشره على Ethereum كما هو — بل سيحتاج إلى إعادة كتابته بـ Solidity (أو امتلاك تنفيذ Solidity منفصل). وتحتفظ بعض المشاريع بعقود على سلاسل EVM وnon-EVM معًا، لكن كل نشر يتطلب تطويرًا وتدقيقًا وصيانة مستقلة. كما يمكن للجسور عبر السلاسل أن تتيح لمشاريع non-EVM تمثيلًا للرمز على سلاسل EVM (مثل رموز SPL المغلَّفة كـ ERC-20 على Ethereum).

هل non-EVM أفضل لتطبيقات الذكاء الاصطناعي؟

لا توجد إجابة شاملة. فسلاسل non-EVM يمكن أن تقدّم مزايا لحالات استخدام ذكاء اصطناعي محددة — فالتنفيذ المتوازي في Solana يناسب التنسيق عالي الإنتاجية، وبنية الشبكات الفرعية في Bittensor مصمَّمة لغرض حوافز الذكاء الاصطناعي، وسلاسل تطبيقات Cosmos تتيح منطق تنفيذ مخصصًا بالكامل. ومع ذلك، تقدّم سلاسل EVM منظومة مطورين أكبر، وأدوات أكثر نضجًا، وسيولة DeFi أعمق، ودعم محافظ أوسع. ويعتمد الخيار الأفضل على متطلبات المشروع المحددة: ما الأعباء التي تعمل على السلسلة، وما الأداء المطلوب، وما المنظومة التي يفضّلها الفريق، وأين المستخدمون المستهدفون.

هل لسلاسل non-EVM معايير رموز مثل ERC-20؟

نعم، لكنها مختلفة. فـ Solana تستخدم رموز SPL. وسلاسل Cosmos تستخدم تسميات أصلية أو رموز CW-20 (عبر CosmWasm). وSui وAptos تستخدمان موارد العملة والأصل القابل للاستبدال في Move. وNEAR تستخدم NEP-141. ويحدد كل معيار كيفية إنشاء الرموز ونقلها وإدارتها على تلك السلسلة. وهذه المعايير ليست قابلة للتبادل مع ERC-20 — فالرمز المبني كـ SPL على Solana لا يمكن استخدامه مباشرةً على سلسلة EVM من دون تغليف أو جسر.

مراجع خارجية

انظر أيضًا

No comments to display

Back to top