أوبتيميزم يرفع سرعة الشبكة إلى 200 مللي ثانية، لكن خلاصات البيانات القياسية تفقد معلومات أساسية

تستهدف شبكة أوبتيميزم (Optimism) تقنية جديدة تسمى “الكتل الفرعية” (Subblocks) لتسريع شبكتها الرئيسية (OP Mainnet)، حيث تخطط لتقليص الفاصل الزمني لتأكيدات المعاملات من 250 ملي ثانية إلى 200 ملي ثانية، على أن يتم هذا التغيير تدريجياً بحلول 31 أغسطس. الكتل الفرعية هي تحديثات سريعة يرسلها المُسلسِل (المُتحكم بالشبكة) بينما لا يزال يبني الكتلة الرئيسية، مما يعطي التطبيقات معلومات مبكرة عن المعاملات قبل اكتمال الكتلة نهائياً.

لكن هذا التحسين بنسبة 20% يحمل معه مخاطرة صامتة تتعلق بالتوافق. توضح إشعارات الترحيل من أوبتيميزم أن أربعة حقول ستبقى داخل كل رسالة مرسلة لكنها ستفقد وظيفتها العملية:

• حقول “جذر الحالة” (state_root)، و”تجزئة الكتلة” (block_hash)، و”جذر السحوبات” (withdrawals_root) ستصبح قيماً صفرية.
• حقل “السحوبات” (withdrawals) سيتحول إلى قائمة فارغة.

نوع الرسالة يبقى نفسه (ExecutionPayloadFlashblockDeltaV1)، ولذلك يمكن للبرمجيات الاستمرار في قراءة التدفق دون ظهور أخطاء، مع بقاء حقول أخرى مثل “جذر الإيصالات” (receipts_root) و”سجل الأحداث” (logs_bloom) تعمل بقيم حقيقية. هذا المزيج يجعل الترقية سهلة التجاهل لأنظمة تعتقد أن نجاح فك التشفير يعني أن جميع البيانات صحيحة ومفيدة.

لماذا تعتبر الكتل الفرعية بسرعة 200 ملي ثانية نقطة تحول لمزودي الخدمات؟

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

معظم التطبيقات آمنة في هذه النقطة لأنها لا تلمس هذه الطبقة التقنية مباشرة. فهي تتصل بمزود RPC يدعم الكتل الفرعية وتستخدم طرق إيثيريوم المعتادة، غالباً مع وسم “قيد الانتظار” (pending). المزود أو العقدة المُهيأة بشكل صحيح يبني عرضه الخاص للحالة، ولذلك تعمل استعلامات مثل eth_getBalance وتعيد بيانات مؤكدة أولياً دون الحاجة لجذر حالة صالح في الرسالة الخام.

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

السرعة الجديدة تظهر بالفعل في وثائق مزودي الخدمات، فشركة Alchemy توضح في دليلها لشبكة OP Mainnet أن التحديثات ستصل كل 200 ملي ثانية عبر نقاط نهاية RPC الحالية، بينما تطبق QuickNode التغيير على مكونات JSON-RPC الخاصة بشبكة Optimism الرئيسية وشبكة سيبوليا التجريبية.

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

الأسئلة الشائعة

س1: ما هي الكتل الفرعية في شبكة أوبتيميزم؟

الكتل الفرعية هي تحديثات سريعة ترسلها الشبكة للمطورين أثناء بناء الكتلة الرئيسية، وهي تؤكد المعاملات بشكل مبدئي قبل إغلاق الكتلة النهائية، ما يمنح التطبيقات ردود فعل أسرع.

س2: هل يؤثر التغيير الجديد على أموال المستخدمين أو أمان الشبكة؟

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

س3: ماذا يعني تقليص الفاصل الزمني من 250 إلى 200 ملي ثانية للمستخدم العادي؟

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