يُشار غالبًا إلى BAL (EIP-7928) في مناقشات Glamsterdam بأنه "الشرط المسبق للتنفيذ المتوازي". لا يعني هذا المصطلح تنفيذ جميع المعاملات بالتوازي مباشرةً، بل يشير إلى انتقال علاقات الوصول إلى الحالة من افتراضات ضمنية إلى قيود واضحة قابلة للتحقق. وعند تحديد هذه القيود بوضوح، يمكن تحقيق جدولة مستقرة.
ترتبط هذه الطبقة من القيود بشكل مباشر بأهداف الترقية الموضحة في نظرة عامة على ترقية Glamsterdam، وتكمل آلية ePBS (EIP-7732): حيث تعالج ePBS حدود التعاون في إنتاج الكتل، بينما يحدد BAL حدود قيود التنفيذ. وتوضح تأثير Glamsterdam على DApps كيف تؤثر التغييرات في طبقة القيود على أداء التطبيقات وإيقاع الإصدارات.
BAL هو اختصار لـ Block-Level Access Lists، أي قوائم الوصول على مستوى الكتلة، والتي تسجل الحسابات وخانات التخزين التي تم الوصول إليها أثناء تنفيذ الكتلة، وقد تتضمن أيضًا نتائج الحالة بعد التنفيذ. الهدف ليس استبدال محرك التنفيذ، بل تزويده بمعلومات أوضح وأبكر لاكتشاف التعارض وتجهيز البيانات.
يوفر التنفيذ التسلسلي التقليدي اتساقًا بسيطًا، لكنه يواجه حدود الكفاءة عند ارتفاع الضغط. ولتحقيق التنفيذ المتوازي، يجب أولًا تحديد "أي المعاملات تتعارض مع بعضها؟" تكمن قيمة BAL في نقل اكتشاف التعارضات من وقت التنفيذ إلى مرحلة التخطيط قبل التنفيذ. وبحسب خارطة طريق Ethereum.org و EIP-7928، يُعد BAL اقتراحًا رئيسيًا في ترقية Glamsterdam.
مع تزايد تعقيد الكتل، إذا ظهرت علاقات القراءة/الكتابة للحالة فقط أثناء التنفيذ، يصبح من الصعب على العملاء التخطيط لمسارات التنفيذ مسبقًا. حتى مع توفر عتاد قوي، قد تتراجع الكفاءة بسبب تعارضات التراجع والجدولة المتكررة.
تقلل قوائم الوصول على مستوى الكتلة من احتمالية "اكتشاف التعارض أثناء التنفيذ فقط". ومع وجود قيود واضحة مسبقًا، يمكن للعملاء تجهيز البيانات، وتقسيم المهام، وعزل التعارضات، مما يقلل من تقلبات الأداء العشوائية. أما بالنسبة لخدمات الفهرسة والعقد المؤرشفة التي تعتمد على قراءات حالة مكثفة، فإن معرفة علاقات الوصول مسبقًا تساعد في تحسين تخطيط الإدخال/الإخراج.
| مرحلة التنفيذ | بدون قيود مسبقة | مع قيود BAL |
|---|---|---|
| توقيت اكتشاف التعارض | تراجع أثناء التنفيذ | توقع قبل التنفيذ |
| تجهيز البيانات | تحميل فوري | تجميع مسبق ممكن |
| استراتيجية الجدولة | معتمدة على الخبرة | معتمدة على القواعد |
يظهر الجدول أن BAL يغير "توفر المعلومات" بدلاً من تحديد الإنتاجية النهائية فقط.
يتيح BAL للعملاء تقسيم المعاملات إلى "مجموعات قابلة للتوازي" والاحتفاظ بـ "مسارات يجب أن تكون تسلسلية". حتى إذا لم يكن التوازي الكامل ممكنًا، يمكن تحسين المقاطع القليلة التعارض أولًا، وتوسيع نطاق التوازي تدريجيًا.
هندسيًا، لا يقدم BAL دفعة أداء فورية، بل يحسن إمكانية التنبؤ بسلوك التنفيذ. وبالنسبة لفرق تشغيل العقد، غالبًا ما تكون إمكانية التنبؤ أكثر أهمية من الأداء المؤقت، لأنها تؤثر مباشرة على اتفاقيات مستوى الخدمة والاستجابة للحوادث. وتعد التغيرات في معدلات التعارض والتراجع على شبكات الاختبار مؤشرات رئيسية لفعالية BAL.
| مرحلة الجدولة | بدون قيود مسبقة | مع قيود BAL |
|---|---|---|
| التحضير قبل التنفيذ | يعتمد على التقديرات | تجميع مسبق حسب قائمة الوصول |
| التعامل مع التعارض | تراجعات متكررة أثناء التشغيل | عزل مبكر للتعارضات |
| ثبات النتائج | متغير جدًا | نتائج أكثر قابلية للتنبؤ |
| مراقبة العمليات | صعوبة تحديد العتبات | إمكانية وضع مقاييس منظمة |
الشكل 1. آلية BAL: دعم قوائم الوصول على مستوى الكتلة لاكتشاف التعارضات وجدولة التنفيذ المتوازي.
BAL ليس بديلًا للتنفيذ المتوازي، بل هو شرطه المسبق. يتطلب تحقيق التنفيذ المتوازي أيضًا تنفيذات العملاء واستراتيجيات الجدولة وإدارة الحالة. بدون قيود أساسية، يؤدي فرض التوازي غالبًا إلى زيادة عدم اليقين.
ببساطة، يجعل BAL التنفيذ المتوازي هدفًا هندسيًا واقعيًا بدلًا من كونه مجرد مفهوم نظري. يجيب عن سؤال "هل الشروط المسبقة متوفرة؟" وليس "هل تحقق الأداء الأقصى؟" وحتى مع إدخال استراتيجيات توازي متقدمة، تبقى قيود BAL ضرورية لإدارة التعارضات.
على المطورين الانتباه لأنماط الوصول إلى الحالة. التصاميم التي تعتمد على عمليات كتابة متكررة لنفس الحالة، أو الاعتماد على عقود متداخلة، أو ربط معاملات مجمعة قد تُظهر سلوكيات تنفيذ جديدة تحت هذه القيود. ينبغي اختبار مسارات التنفيذ قبل الإطلاق، وليس الاكتفاء بالتحقق من الوظائف.
ينبغي لفرق المنتجات أيضًا إعادة ضبط تواصل الأداء. قد لا تكون التحسينات في تجربة المستخدم بعد الترقية خطية، خاصة مع تكيف النظام البيئي. النهج الحذر هو استخدام مقاييس مرحلية: التحقق من الاستقرار، معدلات الفشل، ونسب التأخير المئوية—not فقط المتوسطات. يجب أن تتماشى إعادة تعيين المقاييس والإصدارات المرحلية مع إطار تكيّف التطبيق.
أول التحديات هو تحقيق الاتساق بين العملاء. قد تفسر عملاء التنفيذ المختلفة قوائم الوصول واستراتيجيات الجدولة بطرق متباينة، ما يتطلب تقاربًا مستمرًا عبر شبكات الاختبار والمقارنات بين العملاء مع لقطات مقاييس مؤرخة.
ثاني التحديات هو تكلفة التعلم للنظام البيئي. إذا أغفلت فرق التطوير هياكل الوصول إلى الحالة، قد تظهر انحرافات في الأداء بعد الترقية؛ كما أن العقود القديمة قد لا تتبع أنماط وصول مناسبة، ما يتطلب أدوات ووقتًا للهجرة.
ثالث التحديات هو تحديث أنظمة المراقبة. تحتاج فرق العمليات إلى مقاييس جديدة متعلقة بقيود الوصول لتحديد مصدر المشكلات—سواء من تجهيز البيانات أو تعارضات الجدولة أو اختناقات محرك التنفيذ. بدون تحديث المراقبة، لن تتحقق الفائدة الكاملة للآلية. وبالنسبة إلى قائمة التحقق من استعداد ترقية العقدة، يجب تضمين سجلات BAL ومعدلات تراجع التعارض ضمن معايير القبول. وفي سياق مقارنة Glamsterdam مع Dencun/Fusaka، تعتبر هذه التحديات مخاطر هيكلية فريدة ولا يمكن معالجتها عبر زيادة السعة فقط.
يعالج BAL (EIP-7928) ترتيب التنفيذ بجعل علاقات الوصول إلى الحالة واضحة، وهيكلة اكتشاف التعارضات، وتحويل الجدولة من نمط استجابي إلى تخطيط يمكن التحقق منه. وبينما لا يحدد وحده نجاح الترقية، إلا أنه ضروري للتنفيذ المتوازي المستقر ويعد آلية قيد أساسية في طبقة تنفيذ Glamsterdam.
لا. BAL هو طبقة القيد المسبق للتنفيذ المتوازي، ويوفر الأساس لاكتشاف التعارضات. التنفيذ المتوازي يعتمد أيضًا على تنفيذ العملاء واستراتيجيات الجدولة.
بجعل علاقات الوصول إلى الحالة واضحة مسبقًا، يمكن للعملاء تجهيز البيانات وتجميع المهام مبكرًا، مما يقلل من تراجعات التعارض أثناء التشغيل ويحسن استقرار التنفيذ.
تركز ePBS على حدود التعاون في إنتاج الكتل، بينما يركز BAL على حدود قيود التنفيذ. كل منهما يعمل في طبقة مختلفة، وهما متكاملان ضمن Glamsterdam.
ينبغي مراجعة أنماط الوصول إلى الحالة ومسارات المعاملات عالية التكرار، ودعم اختبار سلوك التنفيذ قبل وبعد الترقية، وتحديث مراقبة الأداء وحدود التنبيه لتجنب الاعتماد على افتراضات تنفيذ قديمة.
لا. يوفر BAL اكتشاف التعارضات ومدخلات الجدولة، لكن يجب معالجة المعاملات عالية التعارض بشكل تسلسلي. ويعتمد نطاق التوازي على أنماط الوصول، وتنفيذ العملاء، وخصائص حمل الشبكة.





