Solana تحدد حجم حد المعاملة الجديد البالغ 4,096 بايت لصفحة ذاكرة واحدة

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

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

جعلت QUIC حد 1,232-byte عديم الجدوى

كان الحد الأصلي لـ Solana تحذيراً شبكياً. عملت الشبكة مع MTU IPv6 بحجم 1,280 بايت.

هذا ترك 1,232 بايت لحمل المعاملة بعد تجاوزات البروتوكول، يكتب مؤلفو SIMD-0296. هذا منطقي عندما كان يجب على كل رسالة المرور عبر MTU بدون تجزئة.

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

كان حد 1,232 بايت قد تحول إلى قاعدة لا تستند إلى أي أساس تقني.

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

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

يفضل الاقتراح حجم 4,096 بايت بدلاً من أكبر حجم مسموح به في QUIC، بحيث تتسع المعاملة لصفحة ذاكرة واحدة قياسية بحجم 4 KiB لدى المُصدّق. لا تعبر أي معاملة حدود الصفحة.

إدارة الذاكرة لكل معاملة رخيصة التكلفة. يتم تقييد كل معاملة بصفحة واحدة فقط.

للوصول إلى حد 4,096 بايت، حلل كريك وفيتزجيرالد كيفية استخدام المطورين لحزم Jito لتجاوز القيود القديمة:

• 50% من الحزم المقدمة كانت بحجم 2,048 بايت أو أقل.
• كان 65% أقل من 6,144 بايت.
• بقي 100% أقل من 9,216 بايت.

يغطي السقف البالغ 4,096 بايت الغالبية العظمى من أعباء العمل متعددة المعاملات في استدعاء واحد، مع البقاء ضمن قيود صفحات الأجهزة لدى المُصدّق.

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

السعة الإضافية تتيح تنفيذ أعباء عمل تتجاوز حد 1,232 بايت.

أنتجت البراهين الصفرية المعرفة، مثل تلك المستخدمة في التحويلات السرية لامتدادات الرموز المميزة (Token Extensions)، حمولات تتجاوز حد 1,232 بايت.

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

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

كما يشير إلى توقيعات Winternitz لمرة واحدة ومخططات BLS على السلسلة التي تعمل بدون برامج تمهيدية (precompiles).

يتجنب التنسيق جداول البحث عن العناوين (Address Lookup Tables)، التي استخدمها الإصدار v0 للإشارة إلى ما يصل إلى 64 حساباً باستخدام مؤشرات قصيرة. تضيف الجداول تعقيداً دون عائد، لأن هناك الآن 64 عنواناً مضمناً بحجم 32 بايت، تشغل فقط 2,048 بايت، وهو أقل بكثير من السقف.

يبقى حد limit البالغ 64 حساباً لكل معاملة في شبكة Solana. ستصل التطبيقات كثيفة الحسابات إلى الحد حتى مع حل مشكلة ميزانية البايت.

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

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

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

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

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

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

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

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

تتطلب Anza من مزودي RPC الترقية إلى Agave v4.2. Helius أصدرت قائمة مراجعة للترحيل توضح العمل المطلوب.

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