تحديث غلامستردام، حل توسيع الطبقة الأولى لشبكة إيثيريوم

الأصل | Odaily Planet Daily jk

يعتبر مطورو إيثيريوم الرئيسيون ترقية Glamsterdam القادمة أكبر عملية إعادة هيكلة على مستوى البروتوكول منذ عملية الدمج. ويتكون الاسم من جزأين: يحتفظ تحديث طبقة التنفيذ باسم "أمستردام"، نسبةً إلى موقع فعاليات Devconnect السابقة؛ بينما يُطلق على تحديث طبقة الإجماع اسم "Gloas"، نسبةً إلى نجم. وبعد ترقية Fusaka السابقة، تُعزز Glamsterdam قابلية التوسع في الطبقة الأولى (L1) من خلال إعادة تنظيم كيفية معالجة الشبكة للمعاملات وإدارة قاعدة بياناتها المتنامية، مما يُحدث تغييرًا جذريًا في طريقة إنشاء إيثيريوم للكتل والتحقق منها.

تتمحور هذه الترقية حول ثلاثة أهداف أساسية:

• المعالجة المعجلة (التوازي): إعادة تنظيم طريقة تسجيل الشبكة لتبعيات البيانات، مما يسمح لها بمعالجة عدد كبير من المعاملات بشكل آمن في وقت واحد، بدلاً من معالجتها ببطء واحدة تلو الأخرى.
• قابلية التوسع: تقسيم عبء العمل الثقيل لإنشاء الكتل والتحقق منها، مما يمنح الشبكة المزيد من الوقت لنشر كميات أكبر من البيانات دون تباطؤ.
• الاستدامة: تعديل رسوم الشبكة لتعكس بدقة تكاليف الأجهزة طويلة الأجل لتخزين البيانات الجديدة، وإزالة العقبات أمام الزيادات المستقبلية في حدود الغاز مع تجنب تدهور أداء الأجهزة.

يركز المقترحان الرئيسيان للتحديث على طبقة الإجماع وطبقة التنفيذ:

هناك مقترحان رئيسيان من Headliner. المصدر: إيثيريوم

الاقتراح الرئيسي الأول: ePBS، تحويل "الوسطاء الخارجيين" إلى "قواعد مدمجة"

أولاً، دعونا نناقش الاقتراح الرئيسي لطبقة الإجماع، والتي تفصل بين المقترحين والبناة داخل البروتوكول، والمختصر باللغة الإنجليزية باسم ePBS (EIP-7732).

في كل مرة تُنشئ فيها شبكة إيثيريوم كتلة، تتضمن العملية خطوتين: شخص مسؤول عن "اختيار الكتلة" (المقترح)، وشخص آخر مسؤول عن "تجميع المعاملات في الكتلة" (المنشئ). حاليًا، لا يُحدد بروتوكول إيثيريوم نفسه هذا التقسيم للعمل، بل يعتمد على مجموعة من "الشركات الوسيطة" خارج السلسلة (المعروفة باسم "المرحِّلات") لتسهيل العملية. كما تُنشئ هذه العلاقة خارج السلسلة مسارًا أثناء التحقق من الكتلة، مما يُجبر المدققين على إكمال بث المعاملات وتنفيذها بسرعة خلال فترة زمنية ضيقة لا تتجاوز ثانيتين، مما يحد من كمية البيانات التي يمكن للشبكة معالجتها. على سبيل المثال، يُشبه هذا الأمر مطعمًا تعتمد فيه عمليات الطلب والطهي على وسيط خارجي مستقل لتنسيق توصيل الأطباق؛ فإذا فشل هذا الوسيط، قد لا يتوافق المطبخ مع مكتب الاستقبال.

يقوم نظام ePBS بتضمين تقسيم العمل بين "طلب الطعام وطهيه" في دليل التشغيل الخاص بالمطعم، متجاوزًا بذلك الاعتماد على جهات خارجية. ونتيجةً لذلك، تم دمج آلية موثوقة لتسليم ودفع الكتل مباشرةً في البروتوكول، مما يلغي الحاجة إلى برامج وسيطة خارجية. مع ذلك، إذا رغب الطرفان في استخدام وظائف معقدة غير محددة في البروتوكول، فبإمكانهما اللجوء إلى جهات خارجية. إضافةً إلى ذلك، ولمنع حدوث أي فوضى أثناء مرحلة "التسليم"، أنشأ نظام ePBS "فريقًا للتحقق من الأطباق" للتأكد من "هوية مقدم الطلب" و"ما إذا كان الطبق قد تم تحضيره في الوقت المحدد"، مما وسّع نطاق وقت التسليم من ثانيتين إلى حوالي 9 ثوانٍ، ما يسمح للمطعم بمعالجة المزيد من الطلبات في وقت واحد، وبالتالي يمكن لشبكة إيثيريوم استيعاب المزيد من البيانات الموجهة إلى الطبقة الثانية.

الاقتراح الثاني الرئيسي: BALs، إعداد "قائمة تسوق" قبل المغادرة

بعد ذلك، دعونا نناقش الاقتراح الرئيسي لطبقة التنفيذ، وهي قائمة الوصول على مستوى الكتلة، والتي يتم اختصارها إلى BALs (EIP-7928).

حالياً، تُشبه طريقة معالجة معاملات إيثيريوم إلى حدٍ ما شخصاً يتسوق في سوبر ماركت وهو مغمض العينين: عليه أولاً أن يتحسس السلعة، ويتأكد من ماهيتها، ثم يقرر كيفية التعامل معها، مما يُجبره على وضع سلعة واحدة في قائمة الانتظار. ولأن النظام لا يعرف مسبقاً البيانات التي ستستخدمها المعاملة، كالحسابات المعنية، فإنه مُلزم بمعالجة المعاملات بالتسلسل؛ وإلا فقد تحاول معاملتان تعديل البيانات نفسها دون قصد (كرصيد العنوان نفسه)، مما يُسبب تعارضات.

تتيح قوائم الوصول الأساسية (BALs) للمستخدم الحصول على قائمة تسوق توضح بوضوح "الأرفف التي يجب التوجه إليها والمنتجات التي يجب شراؤها" قبل الانطلاق. وبفضل هذه القائمة، يستطيع النظام تحديد المعاملات التي لن تتعارض مع بعضها مسبقًا، مما يسمح بتجميع المعاملات غير المرتبطة ومعالجتها بالتوازي بدلًا من وضعها في قائمة انتظار واحدة تلو الأخرى. كما تتميز هذه القائمة بميزة إضافية: فعند انضمام عُقد جديدة إلى الشبكة، يمكنها نسخ النتائج النهائية المسجلة في هذه القائمة مباشرةً دون الحاجة إلى إعادة حساب جميع المعاملات التاريخية المعقدة، مما يُسرّع عملية المزامنة للعُقد الجديدة بشكل ملحوظ. ولتسهيل تداول هذه القائمة داخل الشبكة، قامت شركة Glamsterdam أيضًا بتضمين ترقية لبروتوكول الإرسال تُمكّن العُقد من مشاركة قوائم الوصول هذه، والتي أصبحت الآن شرطًا أساسيًا لجميع عملاء طبقة التنفيذ.

المقترحات الداعمة: إعادة تقييم العمليات "التي تشغل حيزاً مكانياً"

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

• يتناول المقترح الأول عمليات مثل إنشاء حسابات جديدة ونشر العقود التي "تشغل مساحة دائمة" في الشبكة. سابقًا، لم تكن الرسوم المفروضة متناسبة مع المساحة الفعلية المشغولة؛ أما الآن، فسيتم إعادة حسابها بناءً على "الدفع مقابل كل وحدة مساحة مشغولة"، بهدف التحكم في معدل نمو البيانات الإجمالي للشبكة عند مستوى آمن ومتوقع يبلغ 120 جيجابايت سنويًا، مما يضمن استمرار عمل الشبكة على أجهزة عادية. إضافةً إلى ذلك، سيتم احتساب رسوم التخزين هذه بشكل منفصل، ولن تُدمج مع رسوم الحوسبة لمعالجة المعاملات. طالما أن المطورين على استعداد لدفع مبلغ إضافي بسيط في رسوم التخزين، فسيظل بإمكانهم نشر تطبيقات أكبر وأكثر تعقيدًا دون التقيد الفوري بحد الغاز الإجمالي.
• يتناول المقترح الثاني عمليات مثل الاستعلام عن البيانات الموجودة في الشبكة وقراءتها، والتي كانت أسعارها منخفضة سابقًا ولم تكن تتناسب مع تكاليف الاستعلام الفعلية مع ازدياد حجم البيانات. هذه المرة، سيتم رفع معايير التسعير لهذه العمليات لتعكس بشكل أفضل ظروف التحميل الحقيقية للأجهزة الحديثة، مع منع الأفراد من استغلال الرسوم المنخفضة لإغراق الشبكة عمدًا بطلبات استعلام مفرطة.

تاريخ إطلاق الشبكة الرئيسية: لم يُحدد بعد

فيما يتعلق بالجدول الزمني، يمر مشروع غلامستردام حاليًا بمرحلة حساسة. فعلى الصعيد الرسمي، كان آخر اجتماع موثق لجميع المطورين الأساسيين لطبقة التنفيذ (ACDE) هو الاجتماع رقم 241، الذي عُقد في 16 يوليو، وتضمن جدول أعماله الرئيسي تحديثات حول مرحلة تطوير شبكة غلامستردام واختيار المقترحات الرئيسية للتحديث التالي، هيغوتا. ويشير جدول زمني متداول على نطاق واسع في هذا المجال إلى أن مرحلة التطوير مرت بثماني دورات، من 0 إلى 7، خلال الفترة من 28 مارس 2026 إلى 8 يوليو، تلتها عملية إطلاق شبكة اختبار سيبوليا، التي كان من المقرر إطلاقها في 3 أغسطس 2026، ثم عملية إطلاق شبكة اختبار هودي، التي كان من المقرر إطلاقها في 17 أغسطس 2026، مع تحديد 16 سبتمبر 2026 موعدًا مستهدفًا لتفعيل الشبكة الرئيسية.

كان الجدول الزمني الأصلي للإصدار في النصف الأول من عام 2026، المصدر: إيثيريوم

مع ذلك، وبناءً على آخر التطورات، يُرجّح تأجيل هذا الجدول الزمني. أطلق فريق EthPandaOps مؤخرًا شبكة اختبار جديدة تُسمى Plataberget، وهي أول شبكة اختبار عامة قصيرة الأجل مُصممة خصيصًا لـ Glamsterdam. من المتوقع تأجيل عمليات النشر الرسمية لـ Sepolia و Hoodi حتى سبتمبر، وبالتالي تم تغيير موعد إطلاق الشبكة الرئيسية إلى الربع الأخير من عام 2026. هذه هي المرة الثانية التي يتأخر فيها الجدول الزمني لـ Glamsterdam، بعد التأجيل السابق من النصف الأول من عام 2026 الذي كان مُخططًا له أصلًا. وقد أكد المطورون الأساسيون مرارًا وتكرارًا على أن صحة الترقية لها الأولوية على الالتزام بأي تاريخ مُحدد، لذا إلى حين تحديد ارتفاع الكتلة المُحدد خلال اجتماع لجنة تطوير الشبكة (ACD) الرسمي، قد لا نشهد هذه الترقية حتى الربع الأخير أو حتى نهاية العام.