المرحلة التالية لإيثيريوم: ربط L1 و L2، وتعزيز الخصوصية، وتحسين تجربة المستخدم

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

من تقليل الضرائب بشكل كبير على Rollup من خلال إدخال Blob من Dencun، إلى تعديل كفاءة المدققين وآلية التخزين في Pectra، وحتى تنفيذ PeerDAS في Fusaka لتقليل عبء توزيع البيانات، فقد ركزت طبقة البروتوكول تقريبًا كل جهودها على شيء واحد: جعل إيثريوم تستهلك كمية أكبر من البيانات دون رفع عتبة العقد بشكل مفرط.

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

لكن عندما تم توسيع الطريق، لا يزال قيادة السيارة غير مريحة:

• ما زلنا بحاجة إلى نقل الأصول بين ثلاث أو أربع L2، وسهولة الخطأ في سحب السلسلة؛
• رغم أن التحويل واحد يُحزم في بضع ثوانٍ، إلا أن الجسر والبورصة يجبرانك على الانتظار عشرات الدقائق قبل التأكيد؛
• يسيطر المُبنِّون المحترفون تقريبًا على تجميع الكتل، وعندما تريد إرسال معاملة حساسة، قد تُرفض فجأة من قبل القواعد غير الرسمية خارج البروتوكول؛
• لا نتحدث حتى عن أن مستخدمًا جديدًا حتى اليوم، إذا أراد فقط تحويل بضع مئات من USDC، فلا يزال عليه أن يفهم لماذا يجب أن يكون هناك ETH في محفظته، وما هو Nonce، وما هو Gas؛

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

وهو أيضًا بالضبط المشكلة الجديدة التي بدأت في معالجتها إيثريوم من Glamsterdam إلى Hegotá، من الربع الرابع لعام 2026 إلى عام 2027.

Of course, scaling won't hit the brakes.

لا يزال Glamsterdam يركز بشدة على الأداء، وأبرز ميزتين فيه هما: ePBS (EIP-7732) وBAL (Block-level Access Lists، EIP-7928)، وببساطة:

• ePBS يُدرج رسميًا في البروتوكول التخصص بين Proposer و Builder الذي يُمارس بالفعل بكثافة خارج البروتوكول اليوم، مع تقسيم نوافذ الوقت للإنتاج والتحقق بشكل أكثر علمية، لتوفير مساحة كافية للتعامل مع كتل أكبر في المستقبل؛
• يُعادل BAL وضع قائمة "وصول" في بداية الكتلة، بحيث يمكن للعقدة مسحها بسرعة والتنبؤ مسبقًا بالبيانات أو معالجتها بالتوازي، مما يعالج عقدة I/O التخزينية؛

خارج التوسع، فإن المعاناة الحقيقية لمعظم الناس اليوم اليوم ليست في كون TPS لإيثيريوم غير كافية، بل في "كثرة السلاسل".

على سبيل المثال، ETH على الشبكة الرئيسية، والميمات التي تُستخدم على Robinhood Chain، وUSDC المستخدم للدفع والتسوية قد يكون على Arbitrum، وUSDC الذي ترغب في شرائه بسعر منخفض قد يكون على Base.....

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

لذلك، لإعادة تجميع الأحجية المبعثرة إلى شبكة واحدة، بالإضافة إلى بروتوكولات السلاسل المتقاطعة التي تُظهر قدراتها، فإن الآلية الأساسية التي تم دفعها مؤخرًا على مستوى البروتوكول تستحق الاهتمام بشكل كبير — FCR (Fast Confirmation Rule، قاعدة التأكيد السريع).

يعتقد الكثيرون أن المعاملة تُعتبر مكتملة بمجرد تضمينها في كتلة، لكن من حيث التشفير والتوافق، قد تواجه كتلة حديثة إعادات تنظيمية صغيرة، والـ"نهائية" الحقيقية غير القابلة للعكس تتطلب من إيثريوم اجتياز فترتين، ما يستغرق حوالي 13 دقيقة.

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

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

وفقًا للأهداف المحددة من قبل مؤسسة إيثريوم، من المتوقع أن يُقدّم FCR هذا "التأكيد القوي" إلى حوالي 15-30 ثانية، مع الحفاظ على مزامنة الشبكة بشكل طبيعي، وعلى الرغم من أنه لا يعادل الإنهاء الكامل، إلا أنه يكفي لتقديم إشارة تأكيد مبكرة ونموذج أمان واضح للعديد من الجسور واتصالات البلوكشين المتقاطعة والبنية التحتية التي تضطر حاليًا إلى الانتظار حتى الإنهاء.

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

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

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

لكن مع زيادة حجم الكتل وازدياد احترافية المُنشئين، يواجه إيثريوم مشكلة مزدوجة أخرى نموذجية.

بما أن المُبنِّين المحترفين قد وصلوا بكفاءة بناء الكتل إلى أقصى حد باستخدام قوة حوسبة رائدة وتدفق أوامر، فإن مصير معظم الكتل يقع طبيعيًا في أيدي عدد قليل من المؤسسات الكبرى.

هذا يخلق خطرًا شديدًا: الرقابة.

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

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

وهذا هو السبب في أن FOCIL (Fork-choice Enforced Inclusion Lists، EIP-7805) تحتل موقعًا محوريًا في خطط Hegotá.

منطقه بسيط وقاسي للغاية، وهو وضع قيد على Builder.

في كل Slot، يختار البروتوكول عشوائيًا مجموعة من المُحققين المستقلين العاديين لوضع المعاملات المؤهلة والمعترض عليها من مخزن الذاكرة الخاص بهم في قائمة "تضمين (Inclusion List)"، ولا يزال بإمكانك، كـ Builder، ترتيب ترتيب المعاملات بحرية لكسب MEV الخاص بك، لكن الكتلة التي تقدمها يجب أن تحتوي بصدق على جميع المعاملات الواردة في القائمة.

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

بمجرد إنشاء هذه الآلية، وجدت أخيرًا نقطة انطلاق لعيب آخر في إيثريوم كان يُطالب به منذ فترة طويلة ولكن لم يُحرَّك أبدًا، ألا وهو الخصوصية التي ينتظرها الجميع.

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

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

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

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

هذا يعني أن إيثريوم قررت أخيرًا إجراء تعديل جذري على نموذج حسابات EOA الذي استمر لأكثر من عشر سنوات.

بصراحة، نموذج التوقيع بالمفتاح الخاص الذي لا يزال يستخدمه إيثريوم حتى اليوم، هو أمر غير إنساني للغاية بالنسبة للمستخدمين العاديين قليلاً على الإنترنت:

فقدان المفتاح الخاص يعني الدمار الأبدي؛ حتى مع وجود آلاف العملات المستقرة في المحفظة، لا يمكن نقل الأصول مؤقتًا بسبب نقص 0.001 ETH كرسوم معاملة؛ للعب DeFi، يجب أولاً الموافقة ثم التبديل، ويتطلب الأمر ثلاث نقرات للتوقيع لإكمال مهمة واحدة؛ يجب أن تتم معاملات Nonce بالترتيب الصارم، وعندما تعلق معاملة واحدة، تتوقف جميع المعاملات الأخرى.

في الدورتين الأوليين من الترقيات، قام المجتمع بإجراء تنازلات مختلفة. على سبيل المثال، تم تطوير ERC-4337، واستخدام محافظ العقود خارج البروتوكول كوسيلة للإنقاذ؛ كما تم إدخال EIP-7702 في Pectra، مما يسمح للعناوين العادية بربط منطق عقد مؤقت للحصول على مرونة إضافية.

لكن 7702 في النهاية هو جسر مؤقت، والعرض الرئيسي الذي تم قفله من قبل Hegotá هو مفهوم التمثيل الأصلي للحسابات EIP-8141 (Frame Transactions، صفقات الإطار).

يمكن فهمها ببساطة على أنها، في الماضي، كانت معاملة إيثريوم تربط ثلاث مهام بشكل صارم معًا، مثل من يثبت هويتك (التحقق) + من يدفع هذه الرسوم (دفع الغاز) + ما الذي يجب فعله بالضبط (التنفيذ)، بينما يفصل EIP-8141 هذه المهام الثلاث من أسفل البروتوكول إلى "إطارات" مختلفة (اقرأ المزيد في التجريد الحسابي الأصلي + التهديدات الكمية: لماذا لم يصبح EIP-8141 النجم الأول في هيجوتا إيثريوم؟):

• إطار التحقق: لم يعد مُقَيَّدًا بتوقيعات منحنى إيليبتيك ECDSA الثابتة، بل يمكنه دعم طرق تحقق أكثر مرونة مثل Passkey، ودمج وظائف مثل بصمة الهاتف وFace ID بشكل أعمق، مما يجعل تبديل المفاتيح واستعادة الحساب أكثر طبيعية؛
• إطار الدفع: تحليل الغاز كميّة أصلية. يمكن للتطبيق أن يدفع رسوم الغاز مباشرةً عن المستخدمين الجدد، أو يمكنك تحديد خصم USDC مباشرةً من التحويل داخل إطار الدفع، دون الحاجة إلى وسيط لشراء وبيع الغاز خارج السلسلة؛
• Execution frame: Native support for atomic batching, authorization and redemption in one step—success means all take effect together, failure means a clean and complete rollback of everything;

إذا أُضيفت أيضًا EIP-8250 (Keyed Nonces) التي تُناقش حاليًا في الطابور، فسيمكن للحسابات المستقبلية أن تمتلك مسارات متعددة متوازية من Nonce.

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

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

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

إنه لا يزال تحت سيطرة المستخدم بالكامل، تمامًا كما كان من قبل، لكنه سيكون بديهيًا مثل مسح رمز الدفع في Alipay أو فتح القفل بالبصمة.

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

Dencun تحل Blob؛ Pectra تواصل التوسع مع تحسين قدرات المُحققين والحسابات؛ Fusaka تُمهد الطريق لزيادة سعة البيانات باستخدام PeerDAS؛ وفي المرحلة التالية، Glamsterdam، ستُرسي الأساس لزيادة حد الغاز والتنفيذ المتوازي من خلال تغييرات هيكلية مثل ePBS وBAL.

التوسع لم ينتهِ بعد، لكنه لم يعد المشكلة الوحيدة.

أخيرًا، وجدت إيثريوم الوقت الكافي لمواجهة المشكلات الأكثر جوهرية وإرباكًا، وهو ما جعل فريق إيثريوم يُعيد ترتيب اتجاهات تطوير البروتوكول في عام 2026 ويربطها بأهداف ثلاثة بسيطة جدًا:

Scale، تحسين تجربة المستخدم، وتعزيز L1.

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