تطور Ethereum "في غضون ثوانٍ": من التأكيد السريع إلى ضغط التسوية، كيف يمكن لـ Interop القضاء على وقت الانتظار؟

إذا كنت تتنقل كثيرًا بين Base وArbitrum وOptimism، فلا بد أنك شعرت بنوع من "الانفصال" الدقيق.

على الرغم من أن معاملات L2 الفردية أصبحت تقريبًا فورية النتائج، إلا أنه عندما تحاول نقل الأصول من سلسلة A إلى سلسلة B، غالبًا ما تحتاج إلى الانتظار عدة دقائق أو أكثر، وليس لأن L2 نفسها ليست سريعة بما فيه الكفاية، بل لأن العملية التقليدية لأي معاملة تتعلق بالتنقل بين الطبقات أو السلاسل يجب أن تمر بمسار طويل ودقيق:

ترتيب منظم L2 → إرسال إلى L1 → تحقيق التوافق النهائي في L1 (Finality)، باختصار، في بنية Ethereum الحالية، عادةً ما يتطلب التحقق النهائي في L1 دورتين Epoch (حوالي 13 دقيقة)، وهذا ضروري للأمان بلا شك، لكنه بطيء جدًا بالنسبة للتشغيل البيني (Interop).

فبحسب الرؤية الكبرى لـ Ethereum، من المتوقع أن يوجد في المستقبل مئات أو حتى آلاف من L2، ويجب ألا تكون هذه السلاسل جزرًا معزولة عن بعضها البعض، بل يجب أن تعمل معًا كوحدة واحدة، لذا فإن المفتاح هو تقليل وقت الانتظار هذا قدر الإمكان. 

وفي هذا السياق بالذات، حددت خارطة طريق Ethereum Interop في مرحلة التسريع (Acceleration) ثلاثة اتجاهات تحسين مترابطة للغاية: قاعدة التأكيد السريع (Fast L1 Confirmation Rule)، تقصير وقت Slot في L1 (Shorter L1 Slots)، تقليل دورة تسوية الشبكة في L2 (Shorter L2 Settlement). 

يمكن القول إن هذا ليس تحسينًا متفرقًا، بل هو إعادة هيكلة منهجية حول "التأكيد، الإيقاع والتسوية".

أولاً: قاعدة التأكيد السريع — إعطاء النظام "إجابة موثوقة" قبل Finality

من المعروف أنه في بنية Ethereum الحالية، الفاصل الزمني بين الكتل في الشبكة الرئيسية حوالي 12 ثانية، ويقوم المدققون بالتصويت على حالة السلسلة في كل Slot، بينما يأتي التحقق النهائي (Finality) بعد عدة Slots.

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

فهل يمكننا قبل وصول Finality، إعطاء التطبيقات وأنظمة التشغيل البيني إشارة تأكيد "سريعة وموثوقة بما فيه الكفاية"؟ هذا بالضبط ما تهدف إليه خارطة طريق Ethereum Interop في Project #4: Fast L1 Confirmation Rule (قاعدة التأكيد السريع).

هدفها الأساسي مباشر جدًا، وهو تمكين التطبيقات وأنظمة التشغيل البيني من الحصول على إشارة تأكيد L1 "قوية وقابلة للتحقق" خلال 15–30 ثانية، دون الحاجة لانتظار 13 دقيقة كاملة للوصول إلى Finality.

من الناحية الميكانيكية، قاعدة التأكيد السريع لا تقدم عملية توافق جديدة، بل تعيد استخدام تصويت attester الذي يحدث في كل Slot ضمن نظام PoS في Ethereum، فعندما تتراكم أصوات كافية ومنتشرة من المدققين على كتلة معينة في Slots المبكرة، حتى لو لم تصل بعد إلى مرحلة Finality، يمكن اعتبارها "من غير المرجح جدًا أن يتم التراجع عنها ضمن نموذج هجوم معقول".

ببساطة، هذا المستوى من التأكيد لا يحل محل Finality، بل يوفر تأكيدًا قويًا معترفًا به من قبل البروتوكول قبل Finality، وهذا أمر بالغ الأهمية للتشغيل البيني: لم تعد أنظمة التشغيل البيني، وحلول Intent، والمحافظ بحاجة إلى الانتظار بشكل أعمى حتى Finality، بل يمكنها المضي قدمًا بأمان في الخطوة التالية خلال 15–30 ثانية بناءً على إشارة تأكيد على مستوى البروتوكول.

حاليًا، يلعب مفهوم Preconfirmation الذي تروج له Based Rollup دورًا انتقاليًا مهمًا في هذا الاتجاه، ومنطقه بسيط جدًا، كما يوحي اسمه، تخيل التالي: 

عندما نشتري تذكرة قطار عبر 12306، بمجرد اختيار الرحلة وتقديم الطلب (توقيع المعاملة)، يقدم نظام الحجز تأكيدًا مبدئيًا يُخبرك بأن عملية الشراء (أي كل معاملة) قد تم قبولها وهي قيد المعالجة، ويمكنك حينها البدء في التخطيط للرحلة وتحضير الأمتعة، وعندما يتم تأكيد التذكرة نهائيًا (نشر المعاملة على L1)، تكون قد أكملت عملية الشراء وحجز المقعد.

بعبارة أخرى، في Based Rollup، تعني Preconfirmation أنه قبل إرسال المعاملة رسميًا إلى L1 للتأكيد، يتم الالتزام بتضمينها في الكتلة، أي إعطاء المستخدم إشارة تأكيد أولية ليعلم أن معاملته قد تم قبولها وهي قيد المعالجة.

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

ثانيًا: تقصير Slot في L1 — تسريع "نبض" Ethereum

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

إذا كانت قاعدة التأكيد السريع بمثابة "إعطاء وعد" قبل التوافق النهائي، فإن تقصير وقت Slot في L1 هو تقليل دورة "تسوية الدفتر". في خارطة طريق Interop، الهدف المرحلي لـ Project #5 واضح جدًا: تقليل وقت Slot في الشبكة الرئيسية لـ Ethereum من 12 ثانية إلى 6 ثوانٍ.

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

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

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

وعندما يتم تقليل دورة التسوية في L1 ويتضاعف معدل دوران رأس المال، سيقل بشكل كبير احتجاز رأس المال العالق. والنتيجة واضحة: تكلفة احتكاك أقل، رسوم مستخدم أقل، وتأخير أقل في الوصول للأموال، مما سيحفز المطورين والمستخدمين للعودة إلى طبقة التسوية الآمنة في L1 بدلاً من الاعتماد على وسطاء ضعفاء.

بالطبع، مضاعفة "نبض" الشبكة ليس بالأمر السهل. تعمل عدة فرق من مؤسسة Ethereum على هذه الهندسة المعقدة في وقت واحد:

• تحليل الشبكة: يقوم فريق البحث (بما في ذلك الباحثة Maria Silva وآخرون) بتحليل البيانات بدقة لضمان ألا يؤدي تقصير Slot إلى مخاطر إعادة التنظيم (Reorg) بسبب تأخير الشبكة، أو إلى ضغط مركزي على العقد المنزلية ذات النطاق الترددي الضعيف؛
• تنفيذ العميل: هذا يتطلب إعادة هيكلة شاملة على مستوى طبقة التوافق والتنفيذ. والجدير بالذكر أن هذا العمل مستقل عن EIP-7732 (فصل المنشئ عن المدقق الأصلي ePBS)، مما يعني أن خطة تسريع النبض يمكن أن تتقدم بشكل مستقل بغض النظر عن تقدم ePBS؛

بشكل عام، عند دمج Slot الست ثوانٍ مع قاعدة التأكيد السريع، من المتوقع أن تمتلك Ethereum "رد فعل على السلسلة شبه فوري"، مما يسمح لـ dApp والمحافظ في النظام البيئي ببناء تجربة تأكيد في غضون ثوانٍ لم يسبق لها مثيل.

ثالثًا: تقليل دورة تسوية L2 — جعل الأصول "قابلة للسحب الفوري"

في خارطة طريق Interop، يعتبر Project #6: Shorter L2 Settlement هو الأكثر جدلاً، لكنه أيضًا الأكثر إثارة للخيال.

في البنية الحالية، تعتمد Optimistic Rollup عادةً على فترة تحدي تصل إلى 7 أيام، وحتى ZK Rollup مقيدة بوتيرة توليد وإثبات الأدلة، وبصراحة، هذا التصميم لا تشوبه شائبة من حيث الأمان، لكنه يخلق مشكلة واقعية على مستوى التشغيل البيني:

يتم "تأمين" الأصول والحالة بين السلاسل لفترات زمنية طويلة. وهذا لا يزيد فقط من تكلفة التشغيل البيني، بل يزيد أيضًا من عبء إعادة التوازن على Solver، وينعكس في النهاية في رسوم مستخدم أعلى. لذلك يُنظر إلى تقليل دورة التسوية كأحد أهم العوامل لنجاح Interop على نطاق واسع، وتشمل الاتجاهات الهندسية الرئيسية الحالية (للمزيد اقرأ مقال ZK Dawn: Is Ethereum's Endgame Roadmap Accelerating?):

• إثبات ZK الفوري: مع تطور تسريع الأجهزة والأدلة التكرارية، يتم تقليل وقت توليد الأدلة من دقائق إلى ثوانٍ؛
• آليات تسوية أسرع: مثل إدخال نموذج تسوية آمن 2-out-of-3؛
• طبقة تسوية مشتركة: تمكين عدة L2 من تغيير الحالة تحت دلالة تسوية موحدة، بدلاً من "السحب — الانتظار — الإيداع"؛

بالطبع، في مناقشات Interop، هناك سؤال جوهري لا يمكن تجنبه: إذا تم تقليل فترة التحدي من 7 أيام تقليدية إلى ساعة واحدة لتحقيق تأكيد أسرع بين السلاسل، فهل سيترك ذلك مساحة للمهاجمين للقيام بأعمال خبيثة؟

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

ومن المثير للاهتمام أن التحليل الاقتصادي المنهجي الوحيد لهذا السيناريو يأتي من ورقة Offchain Labs المنشورة في فبراير 2025 بعنوان "Economic Censorship Games in Fraud Proofs"، والتي بنت ثلاثة نماذج من الأكثر تشاؤمًا إلى الأكثر تفاؤلاً، بافتراض: 

• نموذج G¹: محتوى الكتلة يحدده الطرف الأعلى سعرًا بالكامل؛
• نموذج G¹ₖ: بعض المدققين يبنون الكتل محليًا دائمًا؛
• نموذج Gᵐ: يقرر عدة مدققين محتوى الكتلة، ويكفي أن يختار أحدهم معاملة المدافع.

في الواقع الهندسي، نظرًا لأن المدققين قد يختارون Slots فارغة (miss slots)، قد تتدهور بعض التصاميم إلى الحالة الأكثر تشاؤمًا G¹، لذا اختارت الورقة التحليل من أسوأ الحالات. 

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

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

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

النتائج الكمية التي قدمتها الورقة واضحة جدًا أيضًا، فبحسب التقديرات، إذا كان مهاجم قوي مستعدًا لإنفاق 100 ملايين دولار على هجوم رقابي مستمر، فإن:

• خلال نافذة الساعة الواحدة، يحتاج المدافع فقط إلى ميزانية Gas بقيمة 33 مليون دولار للرد؛
• إذا تم تفعيل آلية التأخير بنجاح وتم تمديد فترة التحدي إلى 7 أيام، قد تنخفض تكلفة الدفاع إلى حوالي 200 ألف دولار فقط؛

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

وهذا التفاوت الكبير بين تكلفة الهجوم والدفاع (Cost to Attack vs. Cost to Defend) يضمن أنه حتى مع تقليص دورة التسوية بشكل كبير، تظل Ethereum قوية من الناحية الاقتصادية. 

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

كلمة أخيرة

قد يتساءل البعض: لماذا كل هذا الجهد لتحسين بضع ثوانٍ أو دقائق من التأخير؟

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

التأكيد السريع، نبض الست ثوانٍ، وآلية الدفاع غير المتكافئة، كلها تهدف إلى شيء واحد — إزالة "الوقت" كمتغير من إدراك المستخدم.

وكما قال الكاتب مؤخرًا مرارًا وتكرارًا: أفضل شكل للتقنية هو أن تختفي التعقيدات تمامًا في تأكيد فائق السرعة.