قامت Solana بتقليص حد المعاملات الجديد البالغ 4096 بايت إلى صفحة ذاكرة واحدة

Solana بزيادة كمية البيانات التي يمكن أن تحملها معاملة واحدة إلى ثلاثة أضعاف في 9 سبتمبر. يتناسب هذا الحد الأقصى الجديد البالغ 4096 بايت مع صفحة ذاكرة واحدة بحجم 4 كيلوبايت من أجهزة التحقق، وفقًا لاقتراح SIMD-0296 على GitHub.

أصبحت أحمال العمل التي تتطلب معاملات متعددة تتطلب الآن استدعاءً ذريًا واحدًا لإكمالها.

جعل بروتوكول QUIC الحد الأقصى البالغ 1232 بايت بلا جدوى

كان الحد الأصلي لشبكة Solana بمثابة تحذير بشأن الشبكات. فقد كانت الشبكة تعمل بوحدة نقل قصوى (MTU) لبروتوكول IPv6 تبلغ 1280 بايت.

أوضح مؤلفو معيار SIMD-0296 أن ذلك يترك 1232 بايتًا لحمولة المعاملة بعد احتساب النفقات العامة للبروتوكول. وهذا أمر منطقي نظرًا لأن كل رسالة يجب أن تمر عبر وحدة النقل القصوى (MTU) دون تجزئة.

انتقلت Solana إلى QUIC كطريقة قياسية للتعامل مع المعاملات في عام 2022. لا يحدد RFC 9000 الحد الأقصى لحجم التدفق، لذلك يمكن أن تمر الحمولات الأكبر حجمًا دون أي مشاكل على مستوى الشبكة.

لقد تحول الحد الأقصى البالغ 1232 بايت إلى قاعدة ليس لها أساس تقني.

قام المهندسان جاكوب كريتش وأندرو فيتزجيرالد من شركة أنزا بكتابة الوثيقتين. الوثيقة SIMD-0296 الحد الأقصى لحجم الملف.

يُعرّف defiتنسيق رسالة الإصدار الأول، والذي يحتوي على البايتات الإضافية. ويحلّ هذا المعيار مشكلةً كان المطورون يتجاهلونها منذ إطلاق السلسلة. معيار SIMD-0385

يُفضّل الاقتراح استخدام 4096 بايت بدلاً من أكبر حجم يسمح به بروتوكول QUIC، بحيث يمكن وضع المعاملة في صفحة واحدة قياسية بحجم 4 كيلوبايت من ذاكرة المُدقِّق. ولا تتجاوز أي معاملة حدود الصفحة.

إدارة الذاكرة لكل معاملة غير مكلفة. كل معاملة تقتصر على صفحة واحدة.

للوصول إلى الحد الأقصى البالغ 4096 بايت، قام كريتش وفيتزجيرالد بتحليل كيفية استخدام المطورين لحزم جيتو للتحايل على القيود القديمة:

• كانت 50% من الحزم المقدمة بحجم 2048 بايت أو أصغر.
• كان 65% أقل من 6144 بايت.
• بقي حجم الملف 100% أقل من 9216 بايت.

يغطي حد أقصى يبلغ 4096 بايت الغالبية العظمى من أحمال العمل متعددة المعاملات هذه في مكالمة واحدة مع البقاء ضمن قيود صفحة الأجهزة الخاصة بالمدقق.

تُصدر استدعاءات RPC غير المُجهزة الآن الخطأ -32015 على Solana

تتيح السعة الإضافية أحمال العمل التي تتجاوز حد 1232 بايت.

لقد أدت إثباتات المعرفة الصفرية، مثل تلك المستخدمة في عمليات النقلdentلـ Token Extensions، إلى توليد حمولات تجاوزت الحد الأقصى البالغ 1232 بايت.

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

يستفيد تجميع التوقيعات في نظام BLS وتكوينات التوقيعات المتعددة الكبيرة أيضًا من هذا التغيير. ويشير معيار SIMD-0296 إلى التوقيعات المتعددة المتداخلة، وهو نوع التوقيعات المتعددة الذي تستخدمه خزائن المؤسسات والمنظمات اللامركزية المستقلة عبر Squads، باعتباره أحد المحركات الرئيسية.

كما يشير أيضًا إلى التوقيعات لمرة واحدة لـ Winternitz ومخططات BLS على السلسلة التي تعمل بدون عمليات تجميع مسبقة.

يتجنب هذا التنسيق جداول البحث عن العناوين، التي كانت تُستخدم في الإصدار 0 للإشارة إلى ما يصل إلى 64 حسابًا بفهارس قصيرة. تُضيف هذه الجداول تعقيدًا دون فائدة تُذكر، إذ يوجد الآن 64 عنوانًا مضمنًا بحجم 32 بايت، والتي لا تشغل سوى 2048 بايت، وهو أقل بكثير من الحد الأقصى.

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

تتيح حزم Jito للمطورين دمج ما يصل إلى خمس معاملات في تسلسل الكل أو لا شيء لحل مشكلة الحد الأقصى للبايت.

تحقق المعاملة v1 نفس النتيجة الذرية في معاملة واحدة. إنها توفر خاصية الذرية الأصلية مباشرة إلى الطبقة الأساسية.

الإصدار الأول (V1) اختياري للمرسلين، لذا تستمر المعاملات القديمة والإصدار صفر (v0) في العمل. Solana مؤسسة ملاحظات إلى أنه تغيير جذري للبنية التحتية التي تقرأ الكتل.

إذا لم يتم تحديث أدوات البيانات ومستكشفات الكتل لإصدار Solanaالجديد، فسوف تتجمد تمامًا أو تظهر أخطاء.

عندما يحاول تطبيق قراءة معاملة أو كتلة من الإصدار الأول بدون معلمة الإصدار الجديد، ترفض خوادم Solanaالطلب برمز خطأ النظام -32015.

ستواجه الأدوات التي تبث الكتل الحية باستمرار معاملة v1 جديدة، وستتلقى استجابة فارغة تمامًا، وستتوقف عند هذا الحد.

تُظهر أدوات الفهرسة، أو الأدوات التي تسجل بيانات المعاملات، رسوم أولوية صفرية للمعاملات الجديدة لأنها تبحث في المكان الخطأ.

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

تطلب شركة أنزا من مزودي خدمة RPC الترقية إلى Agave v4.2. شركة هيليوس قائمة مرجعية للهجرة توضح تفاصيل العمل المطلوب.

تم تفعيل المعاملة v1 على شبكة اختبار Solana خلال الحقبة 1025 في 1 سبتمبر. وقد حددت أنزا رسميًا موعد نشر الشبكة الرئيسية في 9 سبتمبر.