تستهدف سولانا تاريخ 9 سبتمبر لإطلاق Transaction v1، وهو تنسيق جديد يرفع الحد الأقصى لحجم المعاملات المتسلسلة من 1,232 بايت إلى 4,096 بايت.

تمنح هذه الزيادة المطورين مساحة معاملات أكبر بحوالي 3.3 مرة. وتقول خارطة طريق سولانا الرسمية إن السعة الإضافية يمكن أن تستوعب إثباتات المعرفة الصفرية (zero-knowledge proofs)، وعمليات التوقيع المتعدد الكبيرة (large multisignature operations)، والدفعات (batches)، وبعض مخططات التوقيع على السلسلة (onchain signature schemes).

في السابق، كان يجب تقسيم العمليات الكبيرة إلى عدة معاملات عندما تتجاوز تعليماتها وتواقيعها ومعلومات الحساب سقف 1,232 بايت. وقد أضافت هذه العملية تعقيدًا لأن معاملة واحدة قد تنجح بينما تفشل خطوة أخرى.

يمكن أن يسمح Transaction v1 للمطورين بدمج المزيد من هذه التعليمات في عملية واحدة ذرية (atomic operation). فإما أن تنجح كل التعليمات أو تفشل المعاملة بأكملها. يمكن أن يستفيد هذا النموذج من مسارات التداول، والتحويلات السرية، والعمليات عبر السلاسل، والتطبيقات التي تعالج البراهين التشفيرية المعقدة.

لا ترفع الترقية حد سولانا البالغ 64 حسابًا مرجعيًا لكل معاملة. يمكن للتطبيقات أن تتضمن المزيد من البيانات والتعليمات، ولكن لا يمكنها التفاعل تلقائيًا مع المزيد من الحسابات.

ستظل معاملات سولانا الحالية صالحة

يعد Transaction v1 اختياريًا. يمكن للمحافظ والتطبيقات الاستمرار في إرسال معاملات Legacy و v0 ضمن حد 1,232 بايت الحالي. لا يحتاج المستخدمون إلى ترحيل الرموز المميزة أو استبدال SOL أو إكمال مطالبة قبل التفعيل.

يجب على المطورين اعتماد التنسيق الجديد عمدًا للوصول إلى سعته الأكبر. تحدد وثائق سولانا ثلاثة تنسيقات مدعومة: Legacy و v0 و v1. ينظم كل تنسيق عناوين الحسابات وحدود الموارد بشكل مختلف.

يستخدم تنسيق v0 جداول البحث عن العناوين (Address Lookup Tables)، أو ALTs، لتمثيل عناوين الحسابات من خلال فهارس مضغوطة بحجم بايت واحد. يزيل V1 جداول ALTs ويضع عناوين الحسابات الكاملة بحجم 32 بايت مباشرة داخل المعاملة.

يخلق هذا مفاضلة. يوفر V1 مساحة إجمالية أكبر، ولكن التطبيقات التي تعتمد بشكل كبير على جداول البحث قد تستهلك بايتات أكثر لتمثيل نفس الحسابات. وجد التحليل الفني لسولانا أن 90% من المعاملات التي تم فحصها ستضيف أقل من 1,400 بايت عند التحويل من v0 إلى v1.

يجب على مزودي البنية التحتية تحديث برامجهم

ينطبق خطر التوافق الرئيسي على الخدمات التي تقرأ الكتل والمعاملات. يجب على مزودي استدعاء الإجراءات عن بُعد (Remote procedure call providers) تعيين أقصى إصدار للمعاملات المدعوم لديهم إلى واحد. وإلا، فقد تفشل الطلبات عند مصادفة معاملة من الإصدار v1.

يجب على المفهرسين (Indexers) والمستكشفين (explorers) وخدمات التحليلات أيضًا تغيير طريقة استردادهم لحدود الموارد. تضع معاملات Legacy و v0 حدود الحوسبة (compute limits) وإعدادات رسوم الأولوية (priority-fee settings) داخل تعليمات ComputeBudget. يخزن V1 هذه المعلومات في تكوين معاملة مخصص.

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

يجب على التطبيقات التي ترسل معاملات v1 تعيين حدود وحدات الحوسبة (compute-unit) والبيانات المحملة (loaded-data) بشكل صريح لأن كلاهما يتم تعيينه افتراضيًا على صفر. يجب على المطورين اختبار بناء المعاملات، وتوقيعها، وفك تشفيرها قبل نقل حركة المرور الإنتاجية إلى هذا التنسيق.

لا يزال 9 سبتمبر هو تاريخ التفعيل المستهدف

حدد جاكوب كريتش، نائب رئيس التكنولوجيا في مؤسسة سولانا (Solana Foundation)، 9 سبتمبر كتاريخ إطلاق الشبكة الرئيسية المخطط له. وكما ذكرت crypto.news سابقًا، فإن الترقية مدرجة ضمن إطلاق Anza’s Agave 4.2.

ومع ذلك، لا تزال خريطة الطريق الرسمية تصف ميزة الشبكة الرئيسية بأنها "غير مفعلة". وتقول أيضًا إن جدول إصدار Anza "مؤقت وقابل للتغيير". وقد تم تفعيل الميزة بالفعل على شبكة الاختبار (Testnet) وشبكة المطورين (devnet)، وفقًا لصفحة حالة المؤسسة الأحدث.

تأتي زيادة الحجم من SIMD-0296، بينما يحدد SIMD-0385 تنسيق v1. وقد شارك جاكوب كريتش وأندرو فيتزجيرالد في تأليف كلا المقترحين.

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

يظل Transaction v1 منفصلاً عن تخفيضات الإيجار في سولانا، وأهداف الفتحات الأقصر، وإعادة تصميم إجماع Alpenglow. وفي تغطية ذات صلة، أفادت crypto.news أن Alpenglow تستهدف إتمامًا نهائيًا (finality) يبلغ حوالي 150 مللي ثانية، مع بقاء أكتوبر هدفًا للتطوير بدلاً من تاريخ تفعيل مضمون.