Solana (SOL) تُفعّل معاملات V1 على الشبكة التجريبية مع قفزة الحجم إلى 4,096 بايت

دخل تنسيق المعاملات الجديد V1 على شبكة Solana حيز التنفيذ على الشبكة التجريبية (testnet) يوم 1 سبتمبر، وذلك عند الإيبوك رقم 1025، ليُرفع الحجم الأقصى للمعاملة المُسلسَلة من 1,232 بايت إلى 4,096 بايت — أي زيادة تعادل 3.3 ضعفاً. أطلق استوديو التطوير Anza هذا الإصدار بوصفه التدربة الأخيرة قبل التفعيل على الشبكة الرئيسية المقرر في 9 سبتمبر، وهو موعد أُكّد في 29 أغسطس بعد بدء اختبارات V1 المحلية في 24 أغسطس. تصل هذه الترقية إلى Solana (SOL) في وقت تتعمق فيه الشبكة في التمويل على السلسلة، حيث أصبحت العمليات المعقدة متعددة الخطوات تُجهد تنسيق المعاملات القديم بشكل متزايد.

يقوم هذا التغيير على مقترحين من مسار تحسينات Solana: فبينما يحدد SIMD-0296 ميزانية المعاملة الأكبر، يحدد SIMD-0385 تنسيق رسالة V1، ناقلاً إعدادات المعاملة من تعليمات ComputeBudget إلى الرسالة نفسها — إعادة هيكلة تتيح للمتحققين قراءة متطلبات الموارد دون الحاجة إلى مسح قائمة التعليمات. كما يُلغي V1 جداول البحث عن العناوين التي كان يعتمدها V0، مدمجاً وضع العناوين داخلياً بدلاً من ذلك. والمرد العملي هنا هو الذرية: فالأعباء التشغيلية التي كانت تُقسَّم سابقاً إلى معاملات منفصلة — مثل التحقق من إثباتات المعرفة الصفرية، وأنظمة التوقيعات المتعددة الكبيرة، وإعدادات توقيعات BLS — يمكن الآن تنفيذها في نداء واحد شامل أو لا شيء. وقد اضطر المطورون تاريخياً لتجاوز سقف 1,232 بايت القديم بتكديس ما يصل إلى خمس معاملات ضمن حزم Jito، غير أن الحزم تفتقر إلى الذرية على مستوى البروتوكول وتتنافس داخل محرك كتل Jito الخاص. وبالنسبة لفرق dApp ومجمّعات التبادل اللامركزي التي تبني مسارات المبادلة، فإن معاملة V1 الأصلية إما تنجح أو تُتراجع كوحدة واحدة — مع توقيعات أقل تتحمل رسوماً على الطريق. ويبقى قيد واحد دون تغيير: سقف 64 حساباً مميزاً لا يزال سارياً، ما يعني أن التطبيقات كثيفة الحسابات لن تُفتح أمامها الباب بالكامل. وقد وثّق المدير التنفيذي لشركة Anza برينان وات لحظة التفعيل على منصة X، بنشره معاملة ضخمة من مستكشف الشبكة التجريبية مع عبارة "تنبيه: المعاملات الكبيرة وصلت إلى الشبكة التجريبية".

مشغلو RPC يتسابق مع موعد 9 سبتمبر

نظراً لأن تبنّي V1 اختياري، تظل المعاملات القديمة وتلك الخاصة بـ V0 تعمل كما هي — لكن المخاطر التشغيلية تقع على البنية التحتية الملزمة بقراءة الحركة الجديدة. فقد أشترطت Anza على مزودي RPC الترقية إلى Agave v4.2.2 أو v4.3.0-beta.3، فيما تحذّر إرشادات الترحيل إلى Agave 4.2 المتداولة بين فرق البنية التحتية من أن مستهلكي RPC الذين لا يُعلنون دعم V1 قد يواجهون إخفاقات في النداءات، مثل تعطل getBlock على معاملات V1. ما يجعل نافذة الشبكة التجريبية الحالية هي الجولة الأخيرة من الاستعداد لمشغلي RPC وموفري الفهارس والمحافظ وحزم تطوير البرمجيات ومنصات التحليلات قبل وصول الترقية إلى الشبكة الرئيسية. وتتزامن الترقية مع طرح Agave 4.2 الأوسع، والذي يُنتظر أن تُحقق خطة خفض التكاليف المرحلية في إطاره وفورات تقارب 90% وتقلّص زمن المعالجة من 500 إلى 200 مللي ثانية. ويتجلى الزخم خلف دفعة التمويل على السلسلة في البيانات: فقد وثّق بحث Galaxy للربع الثاني من عام 2026 حول Solana تصاعد نشاط العملات المستقرة والأسهم المرمّزة والأصول الواقعية، محاجّاً بأن مستقبل السلسلة يتوقف على جعل الأصول قابلة للاستخدام في الإقراض والضمانات والهامش والعوائد، لا في الإصدار والتداول وحدهما. يمكن للقراء الراغبين في متابعة السوق لحظيًا الاطلاع على أسعار السبوت والعقود الآجلة مباشرة عبر Bybit.

ويشكّل أمن البنية التحتية لـ البلوكتشين الوجه الآخر لمشهد سولانا هذا الأسبوع. فقد استغل مهاجم عقداً قديماً لبطاقات Rain يوم 28 أغسطس، مسحباً نحو 1.1 مليون دولار من برامج البطاقات المدعومة بالعملات المستقرة على الشبكة، وفق شركة الأمن Blockaid. وسمحت إعادة استخدام التوقيع عبر تعليمتي تحقق مستقلتين للمهاجم بمنح نفسه صلاحيات المدير واستدعاء الدالة WithdrawCollateralAsset، مع تسجيل 8,233 معاملة استغلال أساسية على مدى نحو ساعتين و29 دقيقة؛ ثم جُسّرت العائدات إلى إيثيريوم ودخل نحو 455.9 ETH إلى منصة Tornado Cash. وأفصحت منصة Avici عن خسائر بقيمة 500,859 دولار مؤثرة على 1,685 مستخدماً، فيما أعلنت Tria خسارة 431,945 دولار عبر 636 عميلاً، مع تعهّد كلتيهما بتعويض المتضررين، فيما تقول Rain إن كل البرامج على الإصدار المعرّض للخطر تمت ترقيتها منذ ذلك الحين. ولم تتأثر محافظ العملاء ذاتية الحفظ — فالثغرة كانت في كود التطبيق لا في السلسلة نفسها. وبقراءة الحدثين معاً، يرسم المشهد مرحلة الشبكة المقبلة: فالطبقة الأساسية توسّع قدرتها وتخفض زمن الاستجابة، في حين ينتقل عبء الأمن بشكل حاسم إلى طبقة التطبيقات، حيث ستحدد نظافة الإصدارات في نشر العقود المشتركة — بالمراقبة المستمرة إلى جانب التدقيق الدوري — ما إذا كانت أموال المستخدمين تبقى آمنة.