سولانا (SOL) ترفع سعة المعاملات إلى 4,096 بايت وسط مخاطر توافق تقنية

معاملات بحجم 4,096 بايت تاقعة على الشبكة الرئيسية

تستعد شبكة سولانا (SOL) لرفع الحد الأقصى لحجم المعاملة الواحدة على السلسلة إلى أكثر من ثلاثة أضعاف حجمها الحالي، وتلك المرحلة الأخيرة قبل التفعيل على الشبكة الرئيسية كشفت فجوات توافق تمتد عبر شبكة Solana وبنيتها التحتية المحيطة بها. فصيغة المعاملات v1 ترفع السقف المسموح للمعاملة الواحدة من 1,232 بايت إلى 4,096 بايت، وقد أبدى المشاركون في النظام البيئي مخاوف بشأن جاهزيتهم قبيل النشر في بيئة الإنتاج. وجهة الخلل ملموسة تمامًا: عملاء RPC والفهارس وخدمات البيانات الأخرى التي لم تُحدَّث لدعم صيغة v1 قد تُصدر أخطاء أو تتوقف عن العمل كليًا لحظة محاولتها قراءة كتل تحتوي على معاملات v1. ومستكشفو الكتل ومنصات التحليل وخوادم المحافظ وكل خدمة تعيد تشغيل البيانات التاريخية للسلسلة تقع جميعها داخل نطاق الضرر — وبالنسبة لبعضها، سيظهر العطل على شكل فجوات صامتة في البيانات بدلاً من انقطاع ظاهر للعيان.

وإن رفع الحد الأقصى جوهري بسبب ما يتيحه من إمكانات. فسولانا تضمّن عدة تعليمات داخل معاملة ذرية واحدة، لكن سقف 1,232 بايت الحالي يجبر المطورين على تقسيم العمليات المعقدة — صفقات التمويل اللامركزي متعددة الخطوات، وإنشاء الحسابات دفعة واحدة، وكتابة البيانات المضغوطة — عبر معاملات منفصلة، ما يضيف رسومًا وزمن انتقال عند كل انقسام. أما عند 4,096 بايت، فتتسع عمليات أغنى بكثير داخل وحدة ذرية واحدة، وهو ما يفسر المتابعة الدقيقة لهذا التغيير منذ إطلاق معاملات v1 على الشبكة الاختبارية بالتزامن مع القفزة إلى 4,096 بايت. وقد أصبحت الترقية فعّالة بالفعل على بيئتي testnet وdevnet في سولانا، ما يمنح المطورين وقتًا للبناء وفق الصيغة الجديدة. بيد أنه حتى 4 سبتمبر لم يُفعَّل على الشبكة الرئيسية بعد، تاركًا لمشغلي البنية التحتية نافذة لترقيع برمجياتهم قبل وصول التغيير إلى بيئة الإنتاج. وهذا التحول في الصيغة واحد من عدة ترقيات لشبكة سولانا تمضي في خط الأنابيب بالتوازي، وهو ما يرفع عبء التنسيق على كل مزود خدمة في المصب.

رسوم التخزين تنخفض إلى 6,333 لامبورت

وبينما تتسع سعة الشبكة، تُعاد تسعير اقتصاديات الحالة في الاتجاه المعاكس. فقد أعلن فريق التطوير الأساسي Anza في منشور رسمي أن الشبكة الرئيسية لسولانا فعّلت الخطوة الأولى من مقترح SIMD-0437، ما خفّض رسوم التخزين المستحقة لكل بايت من حالة السلسلة من 6,960 لامبورت إلى 6,333 لامبورت — أي خفض بنحو 9%. ورسوم التخزين هي رصيد اللامبورت المرتبط بالبيانات المحفوظة في حساب ما، لذا فإن خفض تكلفتها الوحدوية يقلص مباشرة كلفة الاحتفاظ بالحالة على السلسلة، سواء تعلق الأمر بحساب رمز بسيط أو بمجموعة بيانات برنامج معقد.

ويُنفَّذ SIMD-0437 على مراحل عبر خمس خطوات مقصودة. أما المراحل اللاحقة، المشروطة كلٌّ منها بنمو الحالة المُلاحظ فعليًا، فستخفض تدريجيًا الكلفة الوحدوية إلى 696 لامبورت لكل بايت — أي خفض تراكمي يقارب 90% من السعر الأصلي. ويحمل هذا التصميم صمام أمان صريحًا: فالمقترح المرافق SIMD-0438 يتيح استعادة جدول الرسوم الأصلي إذا أظهر نمو الحالة مؤشرات ضغط. فالخفض إذن تدريجي وقابل للعكس، وليس إعادة ضبط اقتصادية تُجرى مرة واحدة. وتتراكم التأثيرات العملية مع الوقت: فالحالة الأرخص تقلص كلفة الاحتفاظ بالحسابات على السلسلة على المدى الطويل، وهو ما يهم المطورين الذين ينشرون برامجهم، والقادمين الجدد الذين يقرؤون دليل كيفية شراء سولانا (SOL) وسيواجهون كلفة استمرار أقل على الحسابات التي يفتحونها. كما يتغذى هذا التغيير مباشرة في اقتصاديات الرمز لسولانا، إذ تعمل رسوم التخزين إلى جانب حرق الرسوم وعوائد الستيكنغ بوصفها أحد الروافع المشكِّلة لديناميكيات عرض Solana (SOL). أما مشغلو المُصادقين — الذي تتوسع متطلبات عتادهم مع حجم الحالة — فسيراقبون ما إذا كان السعر الأرخص يُسرّع النمو، وهي بالضبط الحالة التي صُمم SIMD-0438 لمراقبتها. ومن يتتبع السوق لحظة بلحظة يمكنه متابعة أسعار السبوت والعقود الآجلة مباشرة على Bybit.

الطريق نحو 696 لامبورت

وقد ظهرت تفاصيل تقنية جديدة حول عبء الجاهزية لصيغة v1. إذ حددت Anza موعدًا مبدئيًا وهو 9 سبتمبر لتفعيل الشبكة الرئيسية، فيما جرى تفعيل devnet مسبقًا عند الإيبوك 1140. وتأتي المواصفات عبر مقترحي SIMD-0296 وSIMD-0385، وتبقى صيغتا legacy وv0 دون تغيير، فلا هجرة مطلوبة من المرسلين — إذ يقع الخطر على جانب القراءة. إذ يجب على مستهلكي RPC تمرير قيمة عددية maxSupportedTransactionVersion تساوي 1؛ وإلا فتُعيد getTransaction الخطأ -32015، ويفشل getBlock فشلًا كليًا إذا احتوت الكتلة على معاملة v1 واحدة فقط، ويتعطل blockSubscribe مُعيدًا قيمة null. وقد تكون الأعطال صامتة أيضًا: فصيغة v1 تنقل حدود الحوسبة ورسوم الأولوية إلى كائن transactionConfig بدلاً من تعليمات ComputeBudget، ما يعني أن الفهارس التي تمسح قوائم التعليمات قد تسجل ميزانيات حوسبة صفرية دون إطلاق أي خطأ. وتشمل الحد الأدنى للإصدارات المتوافقة @solana/kit 8.0.0، وweb3.js 3.0.0-rc.3، وRust 4.2.x، وsolders 0.29.0، فيما توفر إضافة Geyser plugin 15.1.1 جسر تراجع مؤقت.

(حتى الساعة ‏06:58 UTC‏) (حتى 06:58 بتوقيت UTC) تُقرأ التطويران معًا بوصفهما قوسًا واحدًا متصلًا: سولانا توسّع الحالة ذاتها، لا مجرد معدل الإنتاجية. فالسعة لكل معاملة ترتفع بأكثر من ثلاثة أضعاف بينما تميل كلفة تخزين تلك البيانات نحو خفض يقارب 90% — وكلا التغييرين يدفعان التعقيد عمدًا نحو الخارج، أي نحو مزودي RPC والفهارس الذين أصبحوا اليوم مالكي عبء التوافق. فمتأخرة هذه البنية التحتية، لا البروتوكول نفسه، هي الخطر على المدى القريب، وهو ما يمنح التفعيل المرحلي ورافعة التراجع عبر SIMD-0438 قيمتهما. وكما جادلنا في تغطيتنا لأطروحة الدورة العظمى للرموز لدى Lily Liu، فإن اقتصاديات الحالة هي الساحة التي ستُحسم فيها سباق البنية التحتية في سوق العملات البديلة الأوسع.