ضاعفت Solana للتو قدرتها على إجراء المعاملات ثلاث مرات، فماذا سيحدث بعد ذلك؟

أطلقت Solana ميزة المعاملات الإصدار الأول (Transaction V1) على شبكتها الرئيسية يوم الثلاثاء، مما يتيح إضافة المزيد من البيانات إلى كل معاملة. وهذا سيوفر للمطورين مساحة أكبر لتنفيذ عمليات معقدة في عملية واحدة متكاملة.

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

تم طرح بوابة ميزة txv1 في بداية الحقبة 1035 في حوالي الساعة 01:00 بالتوقيت العالمي المنسق في 15 سبتمبر، كما هو مذكور في صفحة ترقية Solana ، والمعاملة V1 متاحة الآن على الشبكة الرئيسية وشبكة الاختبار وشبكة التطوير.

من 1232 بايت إلى 4096 بايت

أولها هو قيد حجم المعاملة. الآن، ضاعفت Solana الحد الأقصى لحجم المعاملات المتسلسلة إلى 4096 بايت من 1232 بايت، مما يوفر مساحة أكبر للمعاملات، أي ما يقارب ثلاثة أضعاف ونصف المساحة.

تم defiتنسيق المعاملة الجديدة في SIMD-0296، بينما يعتمد تنسيق رسالة V1 على SIMD-0385.

حتى الآن، كان الحد الأقصى لحجم البيانات في Solana يعتمد على قيود صارمة لحجم وحدة النقل القصوى للشبكة. أما الآن، فإن التحرر من هذا الحد الصارم في بروتوكول QUIC يُتيح إجراء معاملات أكبر.

ستكون المساحة الإضافية مفيدة في التعامل مع أنواع أحمال العمل التي تتضمن كميات كبيرة من بيانات المعاملات، مثل إثباتات المعرفة الصفرية، وعمليات التوقيع المتعدد الضخمة، والتوقيعات التي تشمل BLS. وكما ذكر موقع Cryptopolitan، تم إطلاق الإصدار الأول (V1) على شبكة الاختبار في الحقبة 1025، في الأول من سبتمبر، مما أتاح الفرصة لمزودي البنية التحتية للاستعداد لإطلاق الشبكة الرئيسية.

لماذا تُعدّ عملية واحدة من عمليات الذرات مهمة؟

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

ولكن كما يوضح التفسير الوارد في SIMD-0296، فإن الحزمة لا تساوي المعاملة الأصلية عند مناقشة الذرية على مستوى البروتوكول.

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

في بعض الحالات، قد يتطلب تنفيذ عملية ما عددًا أقل من التوقيعات والتأكيدات.

المفاضلة بين جدول البحث عن العناوين

كما يغير الإصدار الأول الطريقة التي تدير بها المعاملات الموارد ومراجع الحسابات.

تم نقل إعدادات حد الحوسبة ورسوم الأولوية من تعليمات ComputeBudget إلى إعدادات المعاملات، مما يتيح لمقدمي البنية التحتية الوصول إلى هذه الإعدادات بسهولة.

كما يتم حذف معاملات الإصدار الأول من جداول البحث عن العناوين لأن الحسابات المشار إليها مضمنة في المعاملة.

في حين أن هذا يساعد على تبسيط المعاملة، إلا أنه يأتي على حساب حجم المعاملة، حيث أن جدول البحث عن العنوان v0 سيتطلب فهرسًا من بايت واحد فقط بينما يتطلب المفتاح العام المضمن 32 بايت.

أظهر تحليل جداول البحث عن العناوين في Solana أن 62% من معاملات الإصدار 0 استخدمت جدول بحث واحد على الأقل عن العناوين؛ لذا، فإن المعاملات الكثيفة التي تستخدم أكثر من جدول بحث عن العناوين ستزيد حجم المعاملة بأكثر من 1500 بايت. ويبقى الحد الأقصى لعدد الحسابات 64 حسابًا كما هو.

أين يندرج الإصدار الأول (V1) ضمن جهود Solanaفي مجال التمويل القائم على الرموز الرقمية؟

يأتي هذا التحديث في وقتٍ تُعزز فيه Solana مكانتها في مجال التمويل اللامركزي. ووفقًا لموقع DeFiLlama، تبلغ القيمة الإجمالية المُودعة في Solanaالتابع لسولانا DeFi 5.95 مليار دولار، بينما يبلغ حجم التداول اللامركزي على مدار 24 ساعة حوالي 1.79 مليار دولار.

أشار ملخص شهر أغسطس لشركة Solana أيضًا إلى أن قيمة الأصول الحقيقية على الشبكة تجاوزت 4 مليارات دولار أمريكي، موزعة على أكثر من 350 ألف عنوان. بالإضافة إلى ذلك، جمعت منصة xStocks أصولًا مدارة تزيد قيمتها عن 500 مليون دولار أمريكي.

لا يعني توفر سعة معاملات أكبر بالضرورة زيادة في معدل التبني.

لاحظت شركة Galaxy Research أن جزءًا كبيرًا من القيمة المرتبطة برموز Solanaلا يزال غير مستخدم، في حين أن المنصات المنافسة لا تزال تتصدر بعض المجالات سريعة النمو.

وبالتالي، يُوسّع الإصدار الأول نطاق التطبيقات التي يُمكن للمطورين إنشاؤها على Solana. إلا أن السؤال الأكثر صعوبة هو ما إذا كان المستخدمون والسيولة ونشاط المعاملات سيتبعون ذلك.

ما الذي يتعين على المشغلين فعله الآن؟

يجب على قارئات RPC ضبط قيمة maxSupportedTransactionVersion على 1 لكل من getTransaction و getBlock، بينما تحتاج الفهارس إلى قراءة حدود الحوسبة V1 ورسوم الأولوية من transactionConfig. يجب على المدققين ومشغلي RPC تشغيل Agave الإصدار 4.2.2 أو أحدث. كما يجب على مرسلي V1 تحديد حدود الحوسبة وحدود الحساب المُحمّل بشكل صريح، واستخدام base64 للمعاملات التي يزيد حجمها عن 1232 بايت. في الوقت نفسه، يجب على مزودي المحافظ الإعلان عن دعم V1 فقط بعد التأكد من قدرة برامجهم على تحليل وتوقيع التنسيق الجديد بشكل صحيح، وفقًا Solanaلإرشادات ترقية.