كيف نفهم المحطة التالية لقابلية التوسع في إيثريوم؟

مقالة: imToken

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

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

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

ومن بين ذلك، تشمل ما شارك فيه فيتاليك نوس، مثل مفاهيم Keyed Nonces، وترقية Glamsterdam التي تدور حول تحديد حد الغاز عند 200 مليون، بالإضافة إلى خارطة الطريق لعام 2026 التي تركز على تجريد الحسابات الأصلية، والتفاعل عبر L2، وتعزيز أمان L1، وغيرها من الخطوات التي تظهر كخطوط خفية.

أولًا: رفع حد الغاز إلى 200 مليون؟

لنبدأ بأبسط شيء يمكن للمستخدمين ملاحظته، وهو حد الغاز.

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

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

عند مراجعة منحنى توسعة حد الغاز في إيثريوم، نجد أنه في سبتمبر 2019، تجاوز حد الغاز في الشبكة لأول مرة 10 ملايين بعد أن كان 8 ملايين، وحتى هذا العام، استغرقت 7 سنوات ليرتفع من 8 ملايين إلى 60 مليون، مع دخول عام 2025 كمرحلة تسريع — حيث ارتفع إلى 30 مليون في فبراير، ثم إلى 36 مليون، وفي يوليو إلى 45 مليون، وبعد ترقية Fusaka في ديسمبر، وصل إلى 60 مليون.

يمكن القول إن معظم التوسعة تم إنجازها في عام 2025، وهو عام مهم جدًا في تاريخ إيثريوم، حيث بعد 7 أشهر من ترقية Pectra في مايو، تلتها ترقية Fusaka، أثبتت أن شبكة إيثريوم، رغم التغييرات الكبيرة في القيادة، لا تزال قادرة على دفع تحديثات مهمة، وهو ما يعكس دخول إيثريوم رسميًا في وتيرة تطوير "نواتين من التحديثات الكبيرة في السنة" بسرعة متزايدة.

وبحسب ملخص التفاعل بين إيثريوم و Soldøgn الذي أصدرته مؤسسة إيثريوم في 2 مايو، شارك أكثر من 100 مساهم رئيسي من إيثريوم في اجتماع تفاعلي حول ترقية Glamsterdam في أرخبيل سفالبارد بالنرويج، وركز الاجتماع على تنفيذ متعدد للعملاء، والاختبار، وتوحيد المعايير، حيث توصل المطورون إلى توافق استراتيجي حول حد الغاز عند 200 مليون بعد ترقية Glamsterdam.

وهذا يعني، إذا سارت العمليات اللاحقة بشكل سلس، فمن المتوقع أن يرتفع قدرة تنفيذ L1 من حوالي 60 مليون إلى مستوى 200 مليون، وعلى المدى الطويل، أصبح موقف إيثريوم من حد الغاز أكثر جرأة، حيث يقترح EIP-9698 زيادة الحد كل عامين بمقدار عشرة أضعاف، ليصل إلى 3.6 مليار بحلول 2029، وهو ضعف الحد الحالي بـ50 مرة.

لكن، من المهم أن نؤكد أن رفع حد الغاز ليس مجرد زيادة حجم الكتلة بشكل عشوائي.

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

لذلك، فإن استراتيجية توسيع Glamsterdam تعتمد على مجموعة من الإجراءات:

• ePBS (فصل المُقترح والمنفذ بشكل مستقل) يجعل عملية بناء الكتلة والتحقق منها أكثر وضوحًا ضمن قواعد البروتوكول، مما يسمح للمحققين بمعالجة كتل أكبر بشكل أكثر أمانًا؛

• قوائم الوصول على مستوى الكتلة (BAL) تسجل مسبقًا الحسابات والمواقع التي ستتم زيارتها أثناء تنفيذ الكتلة، لدعم القراءة المتوازية من القرص، والتحقق المتوازي من المعاملات، وحساب جذر الحالة بشكل متوازي؛

• و EIP-8037 يرفع من تكلفة عمليات إنشاء الحالة، لتجنب التضخم السريع للحالة بعد زيادة حد الغاز؛

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

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

ثانيًا: Keyed Nonces: تحويل "صف واحد" إلى "قنوات متعددة"

إذا كانت حدود الغاز تتعلق بـ"كم يمكن أن تستوعب الكتلة"، فإن Keyed Nonces تركز على مشكلة أكثر تفصيلًا ولكنها حاسمة: كيف يتم ترتيب المعاملات؟

كما هو معروف، يمكن فهم nonce في إيثريوم ببساطة كـ"رقم تسلسلي" للمعاملة، ويهدف إلى منع تكرار المعاملة، وضمان معالجة معاملات نفس الحساب بالترتيب.

هذه الآلية واضحة في سيناريوهات التحويلات العادية، حيث يتم ترتيب المعاملات بشكل تسلسلي: المعاملة الأولى، الثانية، الثالثة، وهكذا.

لكن المشكلة تظهر عندما يصبح الحساب أكثر تعقيدًا، مثل التعامل مع معاملات الخصوصية، أو المحافظ الذكية، أو مفاتيح الجلسة، أو العمليات الجماعية، أو الدفع من طرف ثالث، حيث يمكن أن يصبح nonce الأحادي عائقًا، ولهذا اقترح EIP-8250 مفهوم Keyed Nonces، والذي يقوم على أساس أن كل حساب يمكن أن يمتلك عدة حقول nonce.

بالتحديد، يستبدل هذا المفهوم nonce الأحادي في إطار Frame Transaction الخاص بـ EIP-8141، بـ(nonce_key, nonce_seq)، حيث يمثل nonce_key القيمة 0 للـnonce التقليدي، ويمكن أن يختار البروتوكول إدارة تسلسل nonce بشكل مستقل عبر مفاتيح مختلفة، بحيث تكون المعاملات تحت مفاتيح مختلفة مستقلة، ولا تتداخل أو تتعرض لإعادة التشغيل.

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

وهذا مهم بشكل خاص لبروتوكولات الخصوصية، لأنه لتجنب ربط أنشطة المستخدم على السلسلة بعنوان عام واحد، قد يستخدم بروتوكول الخصوصية عناوين مشتركة لإرسال المعاملات، لكن في نظام nonce الأحادي، قد يؤدي تجميع معاملات المستخدم إلى إلغاء أو تعطيل معاملات مستخدمين آخرين.

أما Keyed Nonces، فهي تسمح لكل معاملة باختيار حقل nonce الخاص بها، على سبيل المثال، من خلال اشتقاقه من Nullifier الخاص بالخصوصية، وتقليل احتمالية التصادم في الصفوف من البروتوكول.

ويحدد فيتاليك نوس، عند تقديمه لـ EIP-8250، أن Keyed Nonces «لا تدعم فقط بروتوكولات الخصوصية بشكل أقوى، بل قد تكون أيضًا خطوة أولى نحو استراتيجية توسعة الحالة الجديدة في إيثريوم — من خلال إنشاء أنواع تخزين مخصصة لكل حالة استخدام، مع الحفاظ على لامركزية البروتوكول، وتحقيق أقصى قدر من التوسع. »

بمعنى آخر، يمكن فهم الأمر ببساطة على أنه حل لمشكلة حجم الكتلة (Gas Limit)، بينما Keyed Nonces تتناول "شكل الحالة" — أي أن إيثريوم في المستقبل لن يتحمل فقط المزيد من المعاملات، بل أنواعًا أكثر تنوعًا من المعاملات.

ثالثًا: كيف ستؤثر هذه التغييرات على المستخدم العادي؟

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

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

وبالتالي، فإن التغييرات على مستوى البروتوكول، لا تكتمل إلا عندما تتحول إلى عمليات أكثر وضوحًا، وسلاسة، وأمانًا في المحافظ.

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

وبنفس المنطق، فإن Keyed Nonces، رغم أنه يبدو كتحسين تقني منخفض المستوى، إلا أن تأثيره على المستخدمين ليس مجرد تصور نظري. فاليوم، كثير من المستخدمين يواجهون مواقف مثل: معاملة لم يتم تأكيدها بعد، أو معاملة عالقة، أو محاولة إلغائها أو تسريعها، دون فهم كامل للعلاقة بين nonce، والغاز، واستبدال المعاملة، خاصة عند وجود عمليات متعددة تعمل بشكل متزامن، حيث يمكن أن تؤدي خطوة فاشلة إلى تعطيل العمليات التالية.

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

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

وبالتالي، فإن عمليات التحويل، أو التفويض، أو المعاملات الخاصة، أو الجماعية، أو الدفع بالغاز، يمكن أن يكون لها مساحات تنفيذ مستقلة، مما يقلل من احتمالية التداخل أو التعطيل.

وهذا سيفتح بلا شك آفاقًا جديدة لتصميم المحافظ الذكية.

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

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

وهذا هو السبب في أن حد الغاز، وقوائم الوصول، وePBS، وKeyed Nonces، ومعاملات الإطار، وتجريد الحسابات، والتفاعل عبر L2، كلها، على الرغم من أنها تبدو كأنها تقنيات مختلفة، إلا أنها جميعًا تخدم هدفًا واحدًا: تمكين إيثريوم من استيعاب سيناريوهات استخدام أكثر تعقيدًا، دون التضحية باللامركزية والأمان.

عند تجميع هذه التطورات، يتضح أن التركيز في إيثريوم مؤخرًا ليس متشتتًا، بل مترابطًا:

• رفع حد الغاز، لمعالجة ضغط الأداء وتكاليف التشغيل؛

• BAL، ePBS، EIP-8037، للحفاظ على قابلية التحقق من العقد، والسيطرة على نمو الحالة أثناء التوسعة؛

• Keyed Nonces، ومعاملات الإطار، لتحسين نماذج الحسابات، وتعزيز الخصوصية، ودعم المحافظ الذكية؛

• تجريد الحسابات الأصلية، والتفاعل عبر L2، لتحسين تجربة المستخدم بشكل ملموس.

وهذا يعني أن إيثريوم يدخل مرحلة جديدة.

فبعد سنوات، كانت السوق تركز أكثر على توسعة L2، وتقليل رسوم Blob، والنهج المعياري، وكان المستخدمون يتنقلون بين L2، ويبحثون عن بيئات تفاعل أقل تكلفة. لكن، مع استمرار رفع حد الغاز، وتقدم ترقية Glamsterdam، وتطوير حلول تجريد الحسابات والتفاعل عبر L2، فإن السؤال الذي يجيب عليه إيثريوم الآن هو: "كيف نجعل تجربة المستخدم على السلسلة أكثر تكاملًا، وكأنها كيان واحد."

وفي هذه العملية، ستزداد أهمية المحافظ بشكل كبير.

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

فلنواصل العمل معًا.