معاملات Solana V1 تصل إلى شبكة الاختبار بهدف دمج العمليات متعددة الخطوات في عملية واحدة

في 1 سبتمبر، أطلقت Anza معاملة الإصدار V1 على شبكة سولانا التجريبية، ممكّنةً من إجراء آخر محاكاة لهذا الترقية قبل إطلاقها في 9 سبتمبر.

يهدف التغيير إلى تمكين أعباء العمل التشفيرية وخدمات التمويل اللامركزي التي كانت تتطلب في البداية تقسيمها عبر معاملات مختلفة من معالجتها الآن في معاملة ذرية واحدة، كما أشارت Solana Compass.

الوظائف التي كانت تُقسّم سابقًا الآن تندمج في مكالمة واحدة

التغيير الأبرز هو زيادة المساحة. فقد ارتفع الحد الأقصى لحجم معاملة سولانا المُسلسلة من 1,232 بايت إلى 4,096 بايت، أي بزيادة بنسبة 3.3 أضعاف، ودخل حيز النفاذ عند حقبة الشبكة التجريبية 1025.

وفقًا للموقع المخصص لتحديث المعاملات الكبيرة من قبل مؤسسة Solana، فإن حجم المعاملات الكبير هذا سيجعل من الممكن تنفيذ براهين المعرفة الصفرية ومعاملات التوقيع المتعدد الكبيرة بالإضافة إلى مخططات توقيع متنوعة لم يكن تحقيقها ممكنًا ضمن معاملة واحدة.

نتيجة لذلك، تقل المعاملات التي يجب معالجتها، وتقل الأموال المطلوبة لدفع رسوم التوقيعات، ولا حاجة للانتظار لسلسلة من التأكيدات. ستستفيد مخططات توقيع BLS، بالإضافة إلى المعاملات السرية وإعدادات التوقيع المتعدد من هذه الترقية.

هناك مقترخان رئيسيان ضروريان للتحسين. يزيد SIMD-0296 حجم المعاملة من 1,232 بايت إلى 4,096 بايت، بينما يحدد SIMD-0385 تنسيق الرسالة V1 وينقل تكوين المعاملة إلى الرسالة نفسها.

قبل أقل من يوم من تفعيل الترقية، نشر الرئيس التنفيذي لشركة Anza برينان وات منشورًا على منصة X يذكر معاملة كبيرة على مستكشف الشبكة التجريبية مع الرسالة: "انتباه: وصلت المعاملات الكبيرة إلى الشبكة التجريبية."

لماذا تتفوق معاملة واحدة على مجموعة معاملات

تكمن أهمية الذرية في حقيقة أنه في بعض الأحيان يتجاوز المطورون الحد القديم لحجم Solana باستخدام حزم Jito. في الواقع، يوضح SIMD-0296 هذه الحيلة ويذكر أيضًا أن الحزم تفتقر إلى الذرية على مستوى البروتوكول كما هو الحال مع معاملة أصلية واحدة.

وفقًا لتوثيق Jito، يمكن أن تتضمن الحزم ما يصل إلى خمس معاملات تُعالَج بالتتابع على أساس الكل أو لا شيء. غير أن الحزم تعمل ضمن محرك الكتل الخاص بـ Jito وتتنافس بين رسوم المُصادِقين. أما معاملة V1، فتشير إلى معاملة Solana الأصلية الواحدة، التي تحمل ضمان الذرية على مستوى المعاملة من Solana.

لمطوري DeFi، يمكن أن يساعد ذلك في تبسيط إنشاء مسارات التبادل، والإثباتات، وأنواع أخرى من المعاملات متعددة الخطوات. إذا غُطيت العملية بالكامل بواسطة معاملة V1، فإنها إما تنجح أو تُرجع كـ معاملة أصلية واحدة بدلاً من الاعتماد على مجموعة من المعاملات.

ما الذي يحصل عليه DeFi بما يتجاوز البايتات الإضافية

تُعدّل V1 أيضًا هيكل المعاملة. فبينما تعالج Legacy وV0 رسوم الأولوية وطلبات الموارد باستخدام تعليمات ComputeBudget، فإن SIMD-0385 ينقل هذه الإعدادات إلى تكوينات معاملة V1، مما يبسّط مهمة المُصادِقين في تحديد احتياجات الموارد دون الحاجة للبحث بنشاط عبر قائمة التعليمات.

تُلغي V1 أيضًا جداول عناوين الحسابات (ALTs) التي اعتمدتها V0 بهدف اختصار عناوين الحسابات. وفقًا لتحليل المؤسسة لمفاضلة ALT في V1، تقوم V1 بدلاً من ذلك بتضمين وضع العناوين داخليًا. وهذا يجعل إدخال المُصادِق أسهل مقارنة بالطريقة المستخدمة في التطبيقات كثيفة الحسابات في V0، التي تستهلك عددًا أكبر من البايتات عند التحويل.

الفائدة العملية للموجهات ومجمعات DEX هي وجود مساحة أكبر للمسارات الذرية المعقدة. ومع ذلك، لا يخلو هذا التحسن من قيود. فبالفعل، تظل السعة القصوى لسولانا البالغة 64 حسابًا مختلفًا دون تغيير، وبالتالي قد تعاني التطبيقات التي تتطلب استخدامًا مكثفًا للحسابات من هذه القيود نفسها، حتى لو لم تعد سعة الحد بالبايت مشكلة.

يتم تقديم هذا الترقية بينما تقفز Solana نحو التمويل على السلسلة. يُظهر تقرير غالاكسي عن Solana للربع الثاني من عام 2026 نشاطًا متزايدًا للعملات المستقرة والأسهم المرمزة والأصول الواقعية.

وفقًا لـ Galaxy، فإن مستقبل إمكانات سولانا سيعتمد بشكل كبير على القدرة على استخدام الأصول في الإقراض، والضمان، والهامش، والعائد، بدلاً من الاكتفاء بالإصدار أو التداول. بناءً على بيانات DeFiLlama الخاصة بسولانا، يبدو أن المنصة تتمتع بحضور قوي في مجال التمويل اللامركزي.

علاوة على ذلك، يتزامن توقيت الترقية مع مرحلة ترقية Agave 4.2. وقد أشار Cryptopolitan إلى أنه يُتوقع أن يؤدي الخطة التدريجية لتخفيض التكاليف إلى توفير يقارب 90%، مع تقليل وقت المعالجة من 500 إلى 200 مللي ثانية، مما يعود بفوائد على مُصدري العملات المستقرة، ومزودي المحافظ، وأنظمة الدفع.

يملك مشغلو RPC أسبوع واحد للتحديث

الإصدار V1 اختياري، لذا فإن معاملات Legacy وV0 تواصل العمل. المشكلة تكمن في ما إذا كانت البنية التحتية التي تقرأ حركة مرور V1 جاهزة أم لا.

ألزمت شركة Anza مزودي خدمات RPC بالانتقال إلى Agave v4.2.2 أو v4.3.0-beta.3. ويؤكد دليل هيليوس للانتقال إلى Agave 4.2 أيضًا أن مستهلكي RPC الذين لا يوضحون الامتثال لـ V1 قد يواجهون فشلًا في المكالمات مثل getBlock عند استخدام معاملة V1.

بدأت العملية باختبار محلي للإصدار V1 في 24 أغسطس، وبعد ذلك بوقت قصير تم تأكيد تاريخ الشبكة الرئيسية في 9 سبتمبر في 29 أغسطس. تم تفعيل الإصدار V1 على شبكة الاختبار في 1 سبتمبر عند الدورة (epoch) 1025، مع تفعيل مقرر على الشبكة الرئيسية في 9 سبتمبر.

تُعد هذه الجولة الأخيرة من اختبار الشبكة خطوة تحضيرية أخيرة لمزودي خدمات RPC، والمؤشرات، والمحافظ، وأدوات SDK، ومنصات التحليل قبل إطلاق الشبكة الرئيسية.