اقتراح SIMD-0567 لحسابات الرموز في Solana (SOL) يُدمج مع خفض حوسبة بنسبة 81%

دمج SIMD-0567 مع خفض بنسبة 81% في الاختبارات

على أعتاب تغيير كبير في آلية حسابات الرموز لدى Solana (SOL)، تحركت الأوراق رسميًا يوم الاثنين: دُمج اقتراح SIMD-0567، وهو إعادة بناء لبرنامج الحسابات المرتبطة بالرموز، في مستودع اقتراحات تحسين الشبكة، وجاءت نتائج الاختبارات بخفض متوسط في وحدات الحوسبة يبلغ 81% بعد وزن تكرار استخدام كل تعليمة. وتقع المسارات القديم والجديد في قياسات الاقتراح على مسافة بعيدة بعضهما عن بعض: إنشاء حساب رمز قياسي من نوع SPL يستهلك حاليًا 18,433 وحدة حوسبة تحت البرنامج القائم، في حين ينجز تصميم p-ATA التعليمة نفسها بـ3,085 وحدة، أي خفض بنسبة 83.3%. هذا يجعل الملف قصة هندسية على مستوى الشبكة لا حدثًا سعريًا، ولم تُسجَّل أي ردة فعل على سعر Solana (SOL) عند نشر هذا التقرير. والحساب المرتبط بالرمز هو الحساب القياسي الذي تفتحه المحفظة لاستقبال رمز معين، ويُشتق عنوانه من المحفظة والرمز معًا؛ وكل مسار يتعامل مع رمز يحتاج إليه، من تحويلات المحفظة العادية إلى التفاعلات القابلة للتركيب مثل Solana Blinks. ويحافظ تصميم p-ATA على عنوان البرنامج نفسه المستخدم في برنامج ATA القائم، وعلى واجهات تعليمات Create وCreateIdempotent وRecoverNested كما هي، فلا تحتاج التطبيقات والمحافظ إلى تغيير العناوين أو الاستدعاءات عند تفعيل البرنامج الجديد. أما التوفير في بقية عائلة التعليمات فقد تراوح بين 63.3% و85.7%، ويتوقف الرقم الدقيق على برنامج الرمز المعني وعلى ما إذا كان لا بد من إنشاء الحساب خلال الاستدعاء. واقتُرحت تعليمة إضافية باسم CreateWithArgs تقبل معلومات تحسين إضافية؛ وفي اختبارات زُوّدت فيها هذه المعلومات كاملة، انخفض استهلاك الحوسبة لبعض أنواع الرموز والأوامر وارتفع لغيرها، وبلغ إنشاء حساب من نوع Token-2022 ما يعادل 182 وحدة حوسبة أكثر من مسار p-ATA القائم.

النطاق وحدود التكلفة

النطاق هو أول ما ينبغي ضبطه: يستبدل SIMD-0567 البرنامج الذي ينشئ حسابات الرموز، لا برنامج تحويل الرموز نفسه. وقد قدمت مؤسسة Solana (SOL) برنامج الرموز المنفصل، المعروف باسم p-token، بوصفه منشورًا بالكامل على الشبكة الرئيسية. وعلى مستوى الشبكة ككل، يتعلق التغيير بسعة الكتلة: كل عملية إنشاء حساب رمز تستهلك حاليًا ما يقارب 18,400 وحدة حوسبة، ما يعني أن خفضًا بنسبة 83% يحرر مساحة حقيقية في كل كتلة لبقية أعمال دفتر الأستاذ، ومن ضمنها حركة إنشاء الحسابات الكثيفة لدى المشاركين عالي التكرار مثل صانعي السوق وبنية روبوتات التداول بالذكاء الاصطناعي التي تفتح أعدادًا كبيرة من حسابات الرموز. وتتتبع تغطيتنا لـSolana هذه المسارات البروتوكولية إلى جانب أخبار السوق. كما يضيّق نقاش الاقتراح الرسمي نطاق ما يوفره المستخدمون فعلًا: شرح المؤلف في ذلك النقاش أن تكلفة معاملة إنشاء الحساب هي شبه كاملة وديعة الحجز المخصصة لضمان الإيجار، بينما لا تشكل رسوم الحوسبة سوى شريحة صغيرة من هذه الفاتورة. لذلك يقلل خفض وحدات الحوسبة بنسبة 81% الشريحة الحوسبية، لا الوديعة. ويمثل هذا التمييز أهمية عملية لكل من يضع ميزانية للتكاليف على السلسلة: الوديعة، لا رسوم الحوسبة، هي ما يحدد كلفة الحساب الجديد اليوم. والحالة هي الحد الآخر: لا تزال الوثيقة في مرحلة المراجعة، ولم يُحدد تاريخ تفعيل. ويذكر الاقتراح ثلاث خطوات تحقق قبل أن تتقدم الميزة: مقارنة نتائج التنفيذ بين البرنامجين القائم والجديد، واختبار يعيد تشغيل معاملات تاريخية من الشبكة الرئيسية، وتدقيق أمني خارجي. ولن يواجه المدققون، الذين تُشغّل عُقدهم هذه البرامج تحت أمن اقتصادي مدعوم عبر ستيكنغ، التغيير إلا بعد جدولة التفعيل. وحتى ذلك الحين، يواصل مشغلو العُقد وفرق التطبيقات تشغيل برنامج ATA القائم دون تعديل، والدمج نفسه لا يغيّر شيئًا على الشبكة الرئيسية اليوم.

التفعيل والتدقيق ما زالا معلقين

قراءتنا أن الدمج يدفع مكسب كفاءة حقيقيًا مع ترك توقيت الحصاد مفتوحًا. فنسبة 81% جاءت من اختبارات الاقتراح نفسها، لا من نشر فعلي على الشبكة؛ والتفعيل غير مجدول والتدقيق الخارجي لا يزال معلقًا، لذا يواصل جانب السوق، من تدفقات صناديق ETF الخاصة بـSolana الخارجة الأخيرة إلى التبني المؤسسي مثل إصدار السندات المرمزة على Solana، التحرك وفق تقويمه الخاص. أما الحد الذي نجا من هذا التغيير فهو وديعة حجز الإيجار: ولأنها تمثل ما يقارب كامل كلفة معاملة إنشاء الحساب، لن تنخفض فواتير المستخدمين بما يوازي خفض الحوسبة، وسيبقى التحليل الفني لـSolana لدينا متابعًا لصورة السعر على حدة عن هذا المسار الهندسي.