Solana Virtual Machine بلغة مستخدمي Bitcoin
لماذا يقترح Bitcoin Hyper اعتماد Solana Virtual Machine بيئةً للتنفيذ؟ دليل للقارئ الذي يعرف Bitcoin ويطّلع على العقود الذكية للمرة الأولى.
غرض تعليمي. محتوى هذا المقال مُعدّ لأغراض إعلامية وتوضيحية فحسب، وهو لا يشكّل استشارة مالية. إخلاء المسؤولية الكامل.
من مكتب Bitcoin إلى مطبخ Solana
لـ Bitcoin لغة برمجة نصية اسمها Script، وهي محدودة عن قصد: فهي ليست كاملة بمعنى تورينغ، ولا تدعم الحلقات التكرارية، ولا تسمح إلا بعمليات أوّلية مثل التحقّق من التواقيع، والتحقّق من الأقفال الزمنية، وإعداد ترتيبات التوقيع المتعدّد. وهذه البساطة نفسها هي ما يجعلها آمنة وقابلة للتنبّؤ.
وسلك Ethereum الطريق المعاكس: فقدّم EVM (Ethereum Virtual Machine)، وهي بيئة كاملة بمعنى تورينغ يستطيع أي شخص أن يكتب فيها برامج اعتباطية (عقوداً ذكية). قوية، لكن بعيب واحد: التنفيذ فيها تسلسلي، عقد واحد في كل مرة، الواحد تلو الآخر.
أما Solana فردّت على تحدّي التوسّع ببنية مختلفة جذرياً: SVM (Solana Virtual Machine) وبيئة التشغيل Sealevel.
نموذج الحسابات في Solana (وفي SVM)
في Ethereum «يملك» العقد الذكي حالته، أي أن البيانات تقيم داخل العقد نفسه. أما في SVM فالأمران منفصلان:
- - الشيفرة (البرنامج) تقيم في حساب غير قابل للتغيير
- - البيانات (الحالة) تقيم في حسابات منفصلة يتحكّم بها البرنامج
وهذا يتيح لـ Sealevel تحليل المعاملات مسبقاً: فإذا كانت المعاملة A تمسّ الحسابين {X, Y} والمعاملة B تمسّ الحسابين {Z, W}، أمكن تنفيذهما على التوازي دون تعارض.
والنتيجة العملية سعة معالجة أعلى بكثير من EVM عند تكافؤ العتاد.
ماذا يعني ذلك للمطوّرين
تُكتب برامج SVM بلغة Rust (أو C/C++) وتُترجَم إلى شيفرة eBPF الثنائية. وأوسع الأُطر انتشاراً هو Anchor، الذي يضيف وحدات ماكرو وأعرافاً برمجية تجعل التطوير أكثر سلاسة.
والهدف المعلَن لـ Bitcoin Hyper هو التوافق الفوري: فبحسب وثائق المشروع، يُفترض أن يعمل أي برنامج Solana قائم على Hyper بتعديلات طفيفة — تغيير نقطة نهاية RPC وبعض إعدادات الشبكة. ويُفترض أن تعمل الأدوات نفسها (Solana CLI وAnchor وإضافات بيئات التطوير) دون تغيير.
وإذا تحقّق ذلك فسيكون ميزة تنافسية غير هيّنة: ففي منظومة Solana آلاف المطوّرين وعدد كبير من البرامج القائمة، ونقلها إلى Bitcoin Hyper سيخفض حاجز الدخول انخفاضاً حاداً. غير أن هذا حتى الآن هدف مخطَّط له أكثر منه نتيجة خضعت لتحقّق مستقل.
ما لم يتّضح بعد
ومع ذلك ينبغي قول بعض الأمور بصراحة:
- لم يخضع التوافق الكامل لتحقّق مستقل: فالوصول إلى DevNet انتقائي والاختبار العلني محدود
- اختلافات في نموذج الرسوم: يستخدم Bitcoin Hyper توكن $HYPER للرسوم بدلاً من SOL، ومن ثمّ تختلف بعض التجريدات
- الاعتماد على برامج نظام Solana: تستند بعض تطبيقات Solana إلى برامج نظام (مثل Token Program الرسمي) قد لا تكون متاحة بالصورة نفسها
ادّعاء «التوافق الفوري» يستحق قدراً من حسن الظن — لكنه يستحق كذلك تدقيقاً نقدياً. اختبر على DevNet قبل أن تفترض شيئاً؛ فالأمر لم يخضع بعد لتحقّق مستقل في بيئة إنتاجية.
تشبيه سلسلة المطاعم
تخيّل SVM بوصفها مطبخ مطعم ضمن سلسلة امتياز: الوصفة (شيفرة Rust) واحدة في كل مكان، والمكان قد يختلف (Bitcoin Hyper بدلاً من الشبكة الرئيسية لـ Solana)، لكن المعدّات (بيئة تشغيل SVM وAnchor) متطابقة. ويُفترض أن يخرج الطبق نفسه.
ويكمن الفرق في المكوّن الأساسي: فبدلاً من SOL يكون $HYPER هو «وقود» هذا المطبخ.