لماذا قد تكون Glamsterdam واحدة من أهم الترقيات في Ethereum بعد الدمج؟

كتبه: KarenZ، أخبار Foresight

ترقية Glamsterdam في Ethereum يمكن أن تُفهم بسهولة على أنها مجرد تكرار تقني لزيادة الإنتاجية. لكن التعبير الأكثر دقة هو: إنها تعيد ترتيب عملية إنتاج الكتل في Ethereum، وعملية التحقق، وطريقة تسعير الموارد، مما يمهد الطريق لحدود غاز أعلى، وسعة blob أكبر، وتنفيذ متوازي مستقبلي.

حتى 23 يونيو 2026، قامت ethereum.org بتحديد Glamsterdam كترقية مخطط لها في النصف الثاني من عام 2026. اسم Glamsterdam يأتي من دمج ترقية الطبقة التنفيذية Amsterdam وترقية الطبقة التوافقية Gloas. وضعت خارطة الطريق الرسمية هذه الترقية بعد Fusaka في ديسمبر 2025 وقبل Hegotá، وحددت بوضوح ميزتين رئيسيتين: فصل المقترحين - البناة داخل البروتوكول، المعروف بـ ePBS، وقائمة الوصول على مستوى الكتلة، المعروفة بـ BAL.

من يقترح؟ من يبني؟ ePBS تكتب تقسيم مسؤوليات إنتاج الكتل داخل البروتوكول

يبدو إخراج كتل إيثيريوم اليوم مثل مناوبة تسليم عمل ضيقة الوقت: هناك من يتولى اقتراح الكتلة، وهناك من يتولى بناء محتوى المعاملات؛ وبينهما تعتمد العملية على بنى تحتية خارج البروتوكول مثل MEV-Boost وrelays طرف ثالث.

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

واحدة من أبرز تغييرات Glamsterdam هي EIP-7732، أي ePBS (Enshrined Proposer-Builder Separation)، وتتمثل في كتابة فصل مسؤوليات المُقترِح والبنّاء داخل البروتوكول.

ببساطة، المسؤول عن المقترحات يختار الكتلة التوافقية (التوافق/الإجماع) بينما مسؤول البناء (البنّاء/Builder) يجهز محتوى المعاملات داخلها. لا يمكن للبنّاء الاكتفاء بتعهد شفهي؛ بل يجب أن يقدم في البروتوكول «إثبات تعهد/ضمان التنفيذ»: يوضح فيه أي كتلة تنفيذ سيسلمها، وكم من المال سيكون مستعدًا لدفعه للمقترِح. بعد ذلك، يقوم Payload Timeliness Committee (لجنة توقيت/دقة تسليم الحمولة، PTC) بالتحقق من أنه يسلم في الوقت المحدد.

ليست النقطة الجوهرية لهذه التغييرات هي فقط تقليل الاعتماد على relays من طرف ثالث؛ بل كذلك توفير وقت لانتشار الكتل والتحقق منها.

اليوم، يحتاج المُتحقق/المدقق إلى معالجة الإجماع والتنفيذ معًا خلال نافذة حرجة قصيرة جدًا؛ يقوم ePBS بفصل هاتين المهمتين، بحيث يمكن الكشف عن حمل التنفيذ والتحقق منه لاحقًا. وفق تصميم EIP-7732، يمكن تمديد نافذة انتشار حمل التنفيذ—أي الوقت المتاح لنقل البيانات عبر الشبكة واستقبالها من قبل العقد—من نحو 2 ثانية إلى نحو 9 ثوانٍ. ومع تمديد النافذة، يصبح من غير المرجح أن تؤدي زيادة سعة الكتل إلى زيادة إسقاط الأصوات (تذاكر) أو مخاطر إعادة التنظيم (reorg) بسبب عدم قدرة العقد على تنزيل البيانات والتحقق والتصويت في الوقت المناسب.

قد لا يكون هذا محسوسًا مباشرةً عند المستخدمين العاديين، لكنه حاسم لتوسعة إيثيريوم. فوجود نافذة أطول للانتشار والتحقق يعني أن الشبكة يمكنها التعامل بأمان مع أحمال أكبر. ذكرت CoinDesk في تقريرها بتاريخ 16 يونيو 2026، نقلاً عن مهندس DevOps في مؤسسة إيثيريوم Parithosh Jayanthi، أن Glamsterdam قد يكون أحد أكبر الانقسامات/التشعّبات منذ عملية الدمج (Merge)، وأنه سيتغير معه الكثير من الافتراضات حول إيثيريوم، وسيهيئ الطريق لتوسعة على نطاق أكبر في المستقبل.

BAL وإعادة تسعير الموارد: التوسعة لا تعني الضغط على دواسة الغاز فقط، بل تعني أيضًا السيطرة على قاعدة البيانات

من التغييرات الجوهرية الأخرى في Glamsterdam هي EIP-7928: Block-Level Access Lists، أي قوائم وصول على مستوى الكتلة.

يمكن فهمها على أنها منح كل كتلة «سجل وصول»: عند تنفيذ هذه الكتلة، يجب تسجيل أي حسابات تمّت ملامستها وأي مواقع تخزين، وما الذي أصبحت عليه الحالة ذات الصلة بعد التنفيذ. وبهذه الطريقة، عند معالجة الكتل، لا يعود العقد/العُقدة تبدو وكأنها تفتح علبة مجهولة بالكامل؛ بل يمكن معرفة وقتًا أبكر ما البيانات التي يلزم قراءتها، وأي عمليات يمكن دفعها بالتوازي.

لقد أدخلت EIP-2930 السابقة بالفعل قوائم وصول على مستوى المعاملة، لكنها كانت اختيارية واستخدامها محدود. أما تغييرات EIP-7928 فتتمثل في رفع قائمة الوصول إلى مستوى الكتلة: تترك الـ header للكتلة «بصمة/البصمة» لهذه القائمة (سجل تجزئة/هاش)، بينما يتم تخزين قائمة وصول كاملة ضمن حمولة التنفيذ. عند تنفيذ العقد/العُقدة للكتلة، يتم التحقق مما إذا كانت سجلات الوصول المذكورة في القائمة تتطابق فعلاً مع عملية تنفيذ الكتلة؛ وإذا لم تتطابق، تصبح الكتلة غير صالحة.

لماذا هذا مهم؟ عند تنفيذ المعاملات على إيثيريوم اليوم، كثير من عمليات الوصول إلى البيانات لا يمكن معرفتها إلا بعد تشغيلها فعليًا حتى تلك الخطوة. عندما لا يعرف المُتحقِّق/العقد ما إذا كانت مجموعة من المعاملات ستقرأ وتكتب في الوقت نفسه حسابًا أو خانة تخزين بعينها، يصبح من الصعب الاطمئنان إلى المعالجة المتوازية. تعمل BAL ككتابة صريحة لمسار الوصول أثناء تنفيذ الكتلة، ما يتيح للعميل/الـ client إجراء قراءات متوازية من القرص، والتحقق من المعاملات بشكل متوازٍ، وحساب جذر الحالة state root بشكل متوازٍ، وحتى في بعض السيناريوهات يمكن إعادة تشغيل المعاملات بشكل غير كامل لتحديث الحالة. إنها ليست زرًا يخفض رسوم المستخدمين مباشرة، بل مساحة هندسية لفتح آفاق التوازي للـ clients.

لكن منطق توسعة Glamsterdam ليس مقتصرًا على «توسيع الطريق». كما أنه يقيّد التضخم الطويل الأمد لقاعدة بيانات إيثيريوم. يرفع EIP-8037 تكلفة إنشاء الحالة، ويُدخل تكلفة لكل بايت من الحالة CPSB. يمكن فهم الحالة على أنها محتوى قاعدة البيانات الذي يجب على إيثيريوم حفظه على المدى الطويل، مثل حسابات جديدة وعقود جديدة ومواقع تخزين جديدة. تنتهي مهمة تنفيذ المعاملة عند اكتمالها، لكن الحالة تبقى في سجلّ الحسابات/الدفتر الذي يجب على كل عقدة صيانته. إذا نما حجم الحالة بسرعة كبيرة، يصبح تشغيل العقدة أغلى تدريجيًا، كما سيجري ضغط اللامركزية تدريجيًا.

الأرقام التي يقدّمها EIP-8037 واضحة جدًا للوهلة الأولى: حتى يناير 2026، تبلغ قاعدة بيانات عقدة Geth مخصّصة للحالة قرابة 390 GiB؛ بعد رفع حد الغاز على الشبكة الرئيسية من 30 مليون إلى 60 مليون، ارتفعت الزيادة اليومية في الحالة من حوالي 105 MiB إلى حوالي 326 MiB، أي نمو سنوي مكافئ بنحو 116 GiB. إذا استُكملت هذه الوتيرة بشكل تناسبي تحت سقف 200 مليون gas، فقد يصل نمو الحالة إلى حوالي 387 GiB، وقد يتجاوز في أقل من عام عتبة تدهور الأداء البالغة 650 GiB.

لذلك، ما يهدف إليه EIP-8037 هو فصل تسعير «الحساب المؤقت» عن تسعير «الاحتلال الدائم لقاعدة البيانات». ستصبح إنشاء الحالة أغلى، لأن ما تقدمه الشبكة ليس مجرد تكلفة حساب لمرة واحدة، بل عبئ تخزين طويل الأمد.

كما ذكر Vitalik Buterin أيضًا ضمن تفسيره لمسار التوسعة Glamsterdam أن Glamsterdam سيفصل تكلفة إنشاء الحالة عن تكاليف التنفيذ والـ calldata: الهدف هو توسيع سعة التنفيذ أكثر، دون أن يتضخم حجم الحالة بالسرعة نفسها.

عند النظر إليهما معًا، تجعل BAL معالجة الكتل متوازية أسهل للعُقدة (وتعالج مشكلة «أن ننفّذ أسرع»)، بينما يجعل إعادة تسعير إنشاء الحالة عمليات احتلال قاعدة البيانات على المدى الطويل أكثر كلفة (وتعالج مشكلة «ألا نضخم دفتر الحسابات أكثر فأكثر»). ليست توسعة Glamsterdam مجرد رفع Gas limit، بل طرح سؤال أكثر واقعية: هل يمكن لإيثيريوم استيعاب معاملات أكثر، مع تجنب فقدان السيطرة على ضغط انتشار الكتل والتحقق منها وتخزين الحالة؟

يتشكل الآن سجل/قائمة EIP الخاص بـ Glamsterdam: ما الذي حُسم، وما الذي لا يزال ينتظر؟

اعتبارًا من 23 يونيو 2026، ووفقًا لآلية التتبع الخاصة بترقيات إيثيريوم على Forkcast، يقوم مطورو إيثيريوم حاليًا باختبار ترقية Glamsterdam في بيئات devnets. سيتم الإطلاق على Sepolia في 3 أغسطس، وعلى الشبكة الرئيسية في 16 سبتمبر (قد تتغير أوقات الإطلاق المحددة).

الخطط الحالية لإدخال Glamsterdam ضمن القائمة تتضمن 10 EIP:

  • EIP-7708 (تحويل ETH سيؤدي أيضًا إلى إنشاء سجلّات، ما يسهل الفهرسة وتتبع التحويلات الأصلية لـ ETH)

  • EIP-7732 (ePBS: يكتب تقسيم المسؤوليات بين المُقترِح والبنّاء داخل البروتوكول، مما يقلل الاعتماد على الـ relay خارج البروتوكول)

  • EIP-7778 (إلغاء ترحيل/ردّ الغاز المرتبط بـ Gas refund، بحيث يصبح ترميز احتساب غاز الكتل أكثر بساطة)

  • EIP-7843 (إضافة تعليمة SLOTNUM جديدة لتمكين العقود من قراءة رقم الـ slot الحالي)

  • EIP-7928 (قائمة وصول على مستوى الكتلة BAL لتسجيل الحسابات ومواقع التخزين التي تم الوصول إليها أثناء تنفيذ الكتلة، لتمهيد الطريق للتحقق المتوازي)

  • EIP-7954 (رفع الحد الأعلى لحجم العقد المسموح، بما يتيح بايتكود عقودًا أكبر)

  • EIP-7976 (رفع تكلفة الحد الأدنى للـ calldata، وضبط الحد الأدنى لتكلفتها)

  • EIP-7981 (رفع تكلفة قوائم الوصول، وإعادة معايرة تسعير الغاز لقائمة الوصول access list)

  • EIP-8024 (تعليمات SWAPN وDUPN وEXCHANGE متوافقة للخلف، لتعزيز قدرات عمليات مكدس EVM)

  • EIP-8037 (رفع تكلفة إنشاء الحالة Gas، وكبح تضخم قاعدة بيانات الحالة بسرعة)

يمكن تقسيم هذه الـ EIP تقريبًا إلى ثلاث فئات: الأولى هي إعادة هيكلة مسارات إخراج الكتل والتحقق، مع EIP-7732 وEIP-7928 في قلبها؛ والثانية هي تعديلات تسعير الموارد، بما فيها EIP-7778 وEIP-7976 وEIP-7981 وEIP-8037؛ والثالثة هي تغييرات في EVM وتجربة المطورين، وتشمل EIP-7708 وEIP-7843 وEIP-7954 وEIP-8024.

بعبارة أخرى، ليس Glamsterdam يغيّر نقطة واحدة فقط؛ بل يرقّي في الوقت نفسه تقاسم مسؤوليات إنتاج الكتل، والتحقق المتوازي، وتسعير الغاز، وقابلية استخدام EVM.

هناك أيضًا دفعة أخرى من EIP لا تزال ضمن قائمة «قيد النظر»:

  • EIP-2780 (تقسيم gas intrinsic الخاص بالمعاملة حسب الموارد)

  • EIP-7610 (التراجع عند إنشاء عقد من حساب تخزين غير فارغ)

  • EIP-7688 (بنية بيانات طبقة إجماع متوافقة مع المستقبل)

  • EIP-7904 (تحليل تكلفة Gas، وقد تتم إزالته من Glamsterdam)

  • EIP-7975 (eth/70، جزء من قوائم الإيصالات/التقارير)

  • EIP-7997 (مصنع عقود حتمي/Deterministic)

  • EIP-8038 (تحديث تكاليف Gas للوصول إلى الحالة)

  • EIP-8045 (استبعاد المُتحقِّقين الذين تمّت معاقبتهم من متابعة اقتراح الكتل)

  • EIP-8061 (رفع churn الخاص بالخروج والاندماج)

  • EIP-8070 (eth/72، Sparse Blobpool)

  • EIP-8080 (جعل الخروج يستخدم consolidation queue)

  • EIP-8136 (cell-level deltas للبثّ عبر بيانات)

  • EIP-8159 (eth/71، تبادل قوائم الوصول على مستوى الكتلة)

  • EIP-8246 (إزالة SELFDESTRUCT burn)

  • EIP-8282 (طلبات تنفيذ المُنشئ Builder Execution Requests: توفير تسجيل وخروج مخصصين لبنّائي ePBS)

إضافةً إلى ذلك، يدرج Forkcast أيضًا حاليًا EIP-8254 (تقييد عدد deposit requests ضمن كل كتلة على طبقة التنفيذ عند 8192) ضمن قائمة «مقترح إدخالها»:

من منظور المُراهنين/حاملي الرهان، فإن EIP-8061 وEIP-8080 المدرجين ضمن القائمة يستحقان اهتمامًا خاصًا. بالنسبة للمراهنين، يعني ذلك أن سيولة الخروج قد تتحسن. قالت Figment في مقالها بتاريخ 5 مايو 2026 إن مُشغلي الرهان المؤسسي هم الأكثر حاجة للتركيز على ePBS وEIP-8061 وEIP-8080، وقدّرت أنه في ظل حجم رهان يقارب 38.9 مليون ETH حتى أبريل 2026، يمكن لـ EIP-8061 رفع حد churn الخروج من 256 ETH/epoch إلى نحو 1187 ETH/epoch، بينما يتيح EIP-8080 للخروج العادي الاستفادة من السعة الفارغة في queue الخاصة بالدمج. وفي الوقت نفسه، تذكّر Figment أن جميع الأرقام قبل الإطلاق على الشبكة الرئيسية ينبغي اعتبارها تخمينات.

المصدر: Figment

تتغير البروتوكولات في الترقية، وتتحرك كذلك عضوية المؤسسة

جاء التحضير التقني لـ Glamsterdam، وتعديلات الموظفين/شؤون الأفراد لدى مجموعة بروتوكول كلستر (Protocol cluster) في مؤسسة إيثيريوم تقريبًا في التوقيت نفسه. ذكرت مدونة مؤسسة إيثيريوم بتاريخ 11 مايو 2026 أن Glamsterdam حقق عدة معالم: تم تأسيس أرضية (floor) حد 200 مليون gas كهدف موثوق لما بعد Glamsterdam، ويعمل ePBS بثبات في Glamsterdam devnet متعددة العملاء، وتم الانتهاء من تثبيت نص EIP-8037.

أعلنت نفس المقالة أيضًا عن تسليم قيادة Protocol cluster: سيصبح Will Corcoran وKev Wedderburn وFredrik منسقي الكتلة البروتوكولية الجدد. أما المنسق السابق Barnabé Monnot وTim Beiko فقد غادرا مؤسسة إيثيريوم، بينما Alex Stokes يأخذ إجازة.

وصف المؤسسة لتوزيع مهام/اختصاصات المنسقين الثلاثة الجدد كالتالي: Will Corcoran لديه خبرة في التنسيق عبر فرق متعددة؛ وKev Wedderburn يقود فريق zkEVM؛ وFredrik يقود مشروع Protocol Security ومشروع Trillion Dollar Security.

لم تتوقف هذه الجولة من التغييرات عند فريق البروتوكول. في 18 يونيو 2026، نشر Hsiao-Wei Wang منشورًا قال فيه إنه قرر بعد أخذ إجازة الاستقالة من منصب المدير التنفيذي المشارك ومن عضوية مجلس إدارة مؤسسة إيثيريوم

صرّح الباحث السابق في مؤسسة إيثيريوم Dankrad Feist في 19 يونيو 2026 بأن من يغادر EF هم من المؤمنين بـ CROPS (مناهضة الرقابة ومناهضة الاستيلاء، مع كونها مفتوحة المصدر، والخصوصية، والأمان). وقال إن المشكلة ليست في الاستراتيجية بل في الإدارة، مضيفًا أن هذا التسرب للمواهب يعد تطورًا سلبيًا نسبيًا بالنسبة لإيثيريوم. في المقابل، فسّر Azeem، المؤسس المشارك لشركة Miden، الأمر من الاتجاه الآخر، معتبرًا أن EF يصعب عليها تغيير ذاتها، وأن خروج المواهب قد يؤدي إلى تأسيس منظمة جديدة أكثر قدرة على تنفيذ خارطة طريق إيثيريوم؛ وعلى المدى الطويل قد يكون ذلك صافيًا إيجابيًا للنظام البيئي.

تعكس موافقةُ داخليين في مؤسسة إيثيريوم على موقفٍ ما بشكلٍ أقرب إلى وضع حدودٍ واضحة. ردّت كلٌّ من المساعدة (Aerugo) Bastian Aue، القائمة المؤقتة للتنفيذ المشترك لمؤسسة إيثيريوم، قائلة إن أسباب مغادرة أعضاء المؤسسة تشمل الخلافات الاستراتيجية، وتوافق الوظائف، والتغيّرات التنظيمية الطبيعية، أو اختيارات شخصية؛ ولن تناقش EF قضايا التوظيف الشخصية على وسائل التواصل الاجتماعي، لكنها تشير إلى أن المغادرين ينبغي أن يكون لديهم طريقة محترمة للانسحاب.

بعد ذلك قدّمت مؤسسة إيثيريوم سردًا تنظيميًا أوضح عبر سلسلة منشورات رسمية على تويتر/X: إن تحقيق إمكانات إيثيريوم يتطلب تحالفًا من عدة مؤسسات؛ وفي العام الماضي كانت هناك عدة مؤسسات عززت معًا مرونة النظام البيئي وقدراته. ومن بين الأمثلة التي ذكرتها EF: ethlabs المعلنة في 23 يونيو (مختبر بحثي غير ربحي يركز على إيثيريوم ومرحلتها/اعتمادها القادم مع ETH)، وEth Apps Guild التي انطلقت في أبريل 2026 (موجهة لاعتماد التطبيقات الأصلية لإيثيريوم بشكل واقعي، مع تركيز خاص على الأسواق الناشئة)؛ وEthereum Economic Zone (من المقرر إطلاقها في 2026 بهدف تقليل تفتت النظام البيئي عبر قابلية التكوين المتزامنة والبراهين المعرفية/zero-knowledge في الوقت الفعلي)؛ وArgot التي تأسست في 2025 (مجموعة حكم ذاتي من مهندسين وباحثين يقومون بصيانة أدوات Solidity ومترجمات open source).

يجعل هذا الـ thread الرسمي تغييرات مؤسسة إيثيريوم الأخيرة أسهل للفهم: فالمؤسسة ليست مجرد أنها تدفع الأشخاص والمشاريع إلى الخارج، وليست أنها تتخلى عن التنسيق المركزي؛ بل قد يكون الأمر أنها تفك خارطة طريق إيثيريوم لتتحملها المزيد من المنظمات معًا.

خلاصة

لذلك، لا ينبغي النظر إلى Glamsterdam على أنها مجرد مجموعة من EIPs. إنها إعادة ترتيب هندسية لإيثيريوم قبل الوصول إلى سعة إنتاج أعلى: من يبني الكتل، ومن يقترح، ومن يتحقق، وما هي البيانات التي يجب حفظها على المدى الطويل، وما الموارد التي ينبغي أن تصبح أغلى—كل ذلك يُطرح من جديد على الطاولة.

كلمات مفتاحية لمسار التكنولوجيا هي ePBS وBAL وبداية تعدد أبعاد Gas؛ أما كلمات مفتاحية لمسار التنظيم فهي أكثر واقعية: هل يمكن لمؤسسة إيثيريوم الحفاظ على قوة التنسيق، وهل تستطيع المنظمات الجديدة خارج المؤسسة تحويل هذه القدرة على التنسيق إلى تسليم مستمر؟

مرجع:

https://forkcast.org/upgrade/glamsterdam/

https://ethereum.org/roadmap/glamsterdam/

https://blog.ethereum.org/2026/05/11/protocol-update-may-26

https://x.com/VitalikButerin/status/2027403360484430122

#ETH