إذا كنت تتنقل بشكل متكرر بين Base و Arbitrum أو Optimism عبر الجسور، فمن المؤكد أنك شعرت بـ「إحساس بالانفصال الدقيق」.
على الرغم من أن المعاملات على طبقة L2 أصبحت تقريبًا تنتهي في ثوانٍ، إلا أنه عندما تحاول نقل الأصول من السلسلة A إلى السلسلة B، غالبًا ما يتطلب الأمر انتظار عدة دقائق أو أكثر، وهذا ليس بسبب بطء L2 نفسه، بل لأن العمليات التقليدية تتطلب مسارًا طويلًا ودقيقًا لمعاملة تتعلق عبر الطبقات والعبر السلاسل:
ترتيب L2 → تقديم إلى L1 → توافق L1 وتأكيده النهائي (Finality)، بشكل عام، في بنية إيثريوم الحالية، يتطلب التثبيت النهائي لـ L1 عادة اثنين من Epoch (حوالي 13 دقيقة)، وهذا ضروري من ناحية الأمان، لكنه بالنسبة للتشغيل التفاعلي (Interop) يبدو بطيئًا جدًا.
وبما أن رؤية إيثريوم المستقبلية تتضمن وجود مئات أو آلاف من طبقات L2، التي لا ينبغي أن تكون جزر تنفيذ معزولة، بل يجب أن تتعاون ككيان واحد، فإن السؤال الرئيسي هو: هل يمكن تقليل هذا الانتظار قدر الإمكان؟
وفي هذا السياق، وضعت خارطة طريق التفاعل بين إيثريوم في مرحلة التسريع (Acceleration)، ثلاثة اتجاهات تحسين عالية التنسيق: قواعد التأكيد السريع (Fast L1 Confirmation Rule)، تقليل مدة فترات L1 (Shorter L1 Slots)، وتقليل دورة تسوية الشبكة من الطبقة الثانية (Shorter L2 Settlement).
يمكن القول إن هذا ليس مجرد تحسينات عشوائية، بل هو إعادة هيكلة منهجية لنظام «التأكيد، الإيقاع، والتسوية».
أولاً، قواعد التأكيد السريع: قبل الوصول إلى Finality، أعطِ النظام «إجابة موثوقة»
كما هو معروف، في بنية إيثريوم الحالية، يتراوح زمن الكتلة حوالي 12 ثانية، ويقوم عقد التحقق بالتصويت على الحالة الحالية للسلسلة في كل فترة (slot)، بينما يتأخر التثبيت النهائي (Finality) بعد عدة فترات.
بعبارة بسيطة، حتى لو تم تضمين المعاملة في كتلة، لا يزال يتعين على النظام الانتظار لفترة طويلة ليكون واثقًا من عدم إعادة تنظيمها أو تراجعها، حاليًا، يتطلب الأمر حوالي اثنين من Epoch (حوالي 13 دقيقة) ليتم اعتبار المعاملة غير قابلة للتراجع، وهذا طويل جدًا لمعظم السيناريوهات المالية على السلسلة.
هل يمكننا قبل الوصول إلى Finality، أن نوفر للتطبيقات وأنظمة العبر السلاسل إشارة تأكيد «سريعة وموثوقة»؟ هذا هو الهدف الذي حددته خارطة طريق التفاعل في إيثريوم ضمن مشروع #4: Fast L1 Confirmation Rule (قاعدة التأكيد السريع).
الهدف الرئيسي بسيط جدًا: تمكين التطبيقات وأنظمة العبر السلاسل من الحصول على إشارة تأكيد قوية وقابلة للتحقق خلال 15–30 ثانية، بدلاً من انتظار 13 دقيقة كاملة للوصول إلى Finality.
من الناحية التقنية، فإن قواعد التأكيد السريع لا تتطلب إدخال عملية توافق جديدة، بل تعتمد على إعادة استخدام تصويتات المُصدِقين (attesters) التي تحدث في كل slot ضمن نظام إثبات الحصة (PoS) الخاص بإيثريوم، حيث إذا تراكمت أصوات كافية ومتنوعة في وقت مبكر لكتلة معينة، حتى لو لم تصل بعد إلى مرحلة التثبيت النهائي، يمكن اعتبارها «غير قابلة للتراجع بشكل كبير تحت نماذج هجوم معقولة».
بمعنى آخر، هذا النوع من التأكيد لا يحل محل Finality، لكنه يوفر قبلها إشارة تأكيد قوية ومُعترف بها من قبل البروتوكول، وهو أمر حاسم للـ Interop: أنظمة العبر السلاسل، ومُحلل النوايا (Intent Solver)، والمحافظ، لم تعد بحاجة للانتظار حتى التثبيت النهائي، بل يمكنها أن تتقدم بثقة خلال 15–30 ثانية استنادًا إلى إشارة التأكيد البروتوكولية.
حتى الآن، يُعتبر مفهوم «التأكيد المسبق» (Preconfirmation) الذي تدعمه بشكل كبير رواية Based Rollup، خطوة انتقالية مهمة، وفكرته بسيطة جدًا، تخيل:
عندما نشتري تذاكر قطار على 12306، بمجرد اختيار الرحلة وإجراء عملية التوقيع، يُعطى المستخدم إشعارًا مبدئيًا بالتأكيد، يُعلمه أن عملية الحجز (وكل معاملة على حدة) قد تم قبولها وتدخل في مرحلة التحقق التالية، وهنا يمكن للمستخدم أن يبدأ في تنظيم الرحلة، وتحضير الأمتعة، فقط بعد أن يتم تأكيد المقصورة والمقعد (نشر المعاملة على L1)، يُعتبر الحجز مكتملًا رسميًا.
باختصار، في نظام Based Rollup، يُعنى «التأكيد المسبق» بأن المعاملة تُعتبر ضمن الكتلة قبل أن تُنشر رسميًا على L1، كإشارة أولية للمستخدم بأن المعاملة مقبولة وتحت المعالجة.
«سأعطيك وعدًا شفهيًا قويًا الآن، وسنؤكد بشكل نهائي لاحقًا»، من خلال هذا المنطق متعدد المستويات، فإن خارطة طريق إيثريوم للتفاعل بين السلاسل تميز بين مستويات الثقة المختلفة، وتبني تجربة تفاعلية سلسة قدر الإمكان.
ثانيًا، تقليل مدة L1 Slot: تسريع «نبض» إيثريوم
مقابل مفهوم التأكيد السريع، هناك تعديل أعمق وأهم من الناحية الفيزيائية — تقليل حجم الـ Slot.
إذا كان التأكيد السريع بمثابة «وعد بالدفع لاحقًا قبل التثبيت النهائي»، فإن تقليل مدة الـ Slot هو تقليل دورة التسوية في السجل مباشرة. في خارطة الطريق، الهدف المرحلي للمشروع #5 هو تقليل زمن الـ Slot في إيثريوم من 12 ثانية إلى 6 ثوانٍ.
هذا «نصف» بسيط، لكنه يثير ردود فعل متسلسلة في الشبكة، فكلما كانت الـ Slot أقصر، زادت سرعة إدراج المعاملات في الكتل، وتوزيعها، وتأكيدها، مما يقلل من زمن الاستجابة الكلي للبروتوكول.
ويؤثر ذلك بشكل مباشر على تجربة المستخدم، بما في ذلك التفاعلات مع L1 (مثل تحويل ETH)، وتقديم الحالة إلى L2، وحتى أن الجمع بين تقليل الـ Slot مع قواعد التأكيد السريع يُمكن أن يُنتج «ردود فعل فورية تقريبًا على الشبكة»، مما يمكّن التطبيقات والمحافظ وبروتوكولات العبر السلاسل من تقديم «تجربة تأكيد خلال ثوانٍ».
بالنسبة لبروتوكولات التفاعل عبر السلاسل، فإن تقليل الوقت يعني زيادة كفاءة استخدام الأموال، حيث أن الجسور أو صانعي السوق الذين يديرون الأصول بين السلاسل، يتحملون مخاطر «الأموال في الطريق» التي تستغرق دقائق أو أكثر، ويضطرون لفرض رسوم أعلى لمواجهة تقلبات الوقت.
وعندما يُقصر زمن التسوية ويزداد معدل دوران الأموال، فإن احتجاز رأس المال في الطريق يقل بشكل كبير، مما يؤدي إلى تقليل التكاليف، وخفض رسوم المستخدم، وتقليل تأخير الوصول، وهو ما يشجع المطورين والمستخدمين على العودة إلى طبقة التسوية الآمنة L1، بدلاً من الاعتماد على وسطاء طرف ثالث هش.
بالطبع، رفع معدل نبضات الشبكة إلى الضعف ليس مهمة سهلة. تعمل عدة مجموعات من فريق عمل إيثريوم على هذا التحدي المعقد:
تحليل الشبكة: فريق البحث (بما في ذلك Maria Silva وغيرهم) يجري تحليلات دقيقة لضمان أن تقليل الـ Slot لا يسبب مخاطر إعادة تنظيم كبيرة (Reorg)، أو ضغط مركزي على عقد المنزل ذات النطاق الترددي المحدود؛
تنفيذ العميل: وهو إعادة هيكلة أساسية تشمل توافق الطبقة والتشغيل، ويُلاحظ أن هذا العمل مستقل عن EIP-7732 (فصل المُصادقين الأصليين عن المُنشئين ePBS)، مما يعني أن خطة تسريع نبضات القلب يمكن أن تتقدم بشكل مستقل عن تقدم ePBS؛
بإجمال، عندما يُدمج تقليل الـ Slot إلى 6 ثوانٍ مع قواعد التأكيد السريع، فإن إيثريوم قد تحقق «ردود فعل فورية تقريبًا على الشبكة»، مما يمكّن التطبيقات والمحافظ من تقديم تجارب تأكيد خلال ثوانٍ غير مسبوقة.
ثالثًا، تقليل دورة تسوية L2: «الأصول تنطلق فورًا»
في خارطة الطريق، المشروع #6: Shorter L2 Settlement، هو الأكثر إثارة للجدل والأكثر خيالًا.
حاليًا، تعتمد Rollup التوقعية (Optimistic Rollup) على فترة تحدي تصل إلى 7 أيام، وحتى ZK Rollup، فهي مقيدة بسرعة إثباتات التحقق، وبصراحة، هذا التصميم آمن جدًا، لكنه يخلق مشكلة واقعية على مستوى التفاعل بين السلاسل:
الأصول والحالة «مقيدة زمنياً» بين السلاسل، مما يرفع تكاليف العبر السلاسل بشكل كبير، ويزيد من عبء إعادة التوازن على المُحلل (Solver)، ويؤدي إلى رسوم أعلى للمستخدمين. لذلك، يُنظر إلى تقليل دورة التسوية كعامل رئيسي لتمكين الانتشار الواسع لـ Interop، ويشمل العمل على:
إثباتات ZK في الوقت الحقيقي: مع تطور الأجهزة والتقنيات التكرارية، يتم تقليل زمن إثباتات التحقق من دقائق إلى ثوانٍ؛
آليات تسوية أسرع: مثل إدخال نماذج تسوية آمنة من نوع 2-out-of-3؛
طبقة تسوية مشتركة: تتيح لعدة طبقات L2 أن تُجري تغييرات الحالة ضمن سياق تسوية موحد، بدلاً من «السحب، الانتظار، والإيداع»؛
بالطبع، في نقاشات التفاعل بين السلاسل، هناك سؤال جوهري: إذا قمنا بتقليل فترة التحدي من 7 أيام إلى ساعة واحدة، هل نترك مجالًا للمهاجمين للقيام بأعمال خبيثة؟
نظريًا، لا يُعد هذا القلق بلا أساس، فمخاطر «الرقابة القسرية» (التحكم الجماعي لعقد التحقق) تختلف عن «الرقابة القسرية الناعمة» التي قد تتعرض لها الشبكة، والتي تتعلق بشكل خاص بهجمات «الرقابة الناعمة» التي يقودها مُنشئو الكتل: المهاجمون لا يحتاجون إلى السيطرة على التوافق، بل يكفي أن يضغطوا باستمرار على المُدافعين من خلال تقديم عروض عالية على المعاملات المهمة، مما يمنعها من الوصول إلى السلسلة.
المثير للاهتمام، أن التحليل الاقتصادي المنهجي الوحيد لهذا السيناريو يأتي من ورقة بحثية أصدرها Offchain Labs في فبراير 2025 بعنوان «Economic Censorship Games in Fraud Proofs»، التي وضعت ثلاثة نماذج، من الأكثر تشاؤمًا إلى الأكثر تفاؤلًا، تفترض:
نموذج G¹: محتوى الكتلة يُحدد بالكامل من قبل أعلى مزايد؛
نموذج G¹ₖ: بعض المُصدِقين يبنون الكتل محليًا دائمًا؛
نموذج Gᵐ: عدة مُصدِقين يقررون معًا محتوى الكتلة، طالما أن أحدهم يختار الدفاع عن المعاملات.
وفي الواقع، بسبب احتمال أن يختار المُصدِقون ترك فجوات (miss slots)، فإن بعض التصاميم قد تتدهور إلى الحالة الأسوأ G¹، لذلك اختارت الدراسة تحليل أسوأ الحالات.
وبناءً على ذلك، اقترح الباحثون استراتيجية دفاعية واقعية جدًا — «الدفاع بالتأخير»، التي تعتمد على أن للمُدافعين حق «تأخير خطوة واحدة»، أي أنهم لا يحتاجون إلى إتمام جميع عمليات التحقق المعقدة خلال ساعة واحدة، بل يكفي أن ينجحوا في تقديم معاملة خاصة على L1.
هذه المعاملة الخاصة تُستخدم بشكل واضح، فهي بمجرد أن تُنشر على السلسلة، تُطيل فترة التحدي من ساعة إلى 7 أيام. على سبيل المثال، إذا اكتشف المُدافع أن حالة L2 غير طبيعية، لا يحتاج إلى إتمام جميع عمليات التحقق خلال ساعة، بل يكفي أن ينجح في تقديم معاملة خاصة على L1، تعمل كإنذار، وتُطيل فترة التحدي تلقائيًا إلى 7 أيام.
وهذا يعني أن المهاجمين سيُجبرون على خوض معركة استنزاف غير متكافئة، حيث يتعين عليهم دفع رسوم أولوية أعلى باستمرار لمنع المعاملة من الوصول إلى السلسلة، ويجب أن يستمروا في ذلك طوال فترة التحدي.
وأظهرت نتائج الدراسة أن، إذا كان المهاجم قويًا جدًا ويستعد لإنفاق 100 مليار دولار لمهاجمة الشبكة بشكل مستمر، فإن:
خلال نافذة ساعة واحدة، يحتاج المدافعون إلى حوالي 33 مليون دولار من ميزانية الغاز للرد؛
أما إذا تم تفعيل آلية التأخير، وتمتد فترة التحدي إلى 7 أيام، فإن تكلفة رد المدافع تنخفض إلى حوالي 20 ألف دولار فقط؛
بمعنى آخر، هذه ميزة هيكلية حاسمة: تكلفة المهاجم تتزايد بشكل خطي، بينما تكلفة الدفاع تتطلب مرة واحدة فقط نجاحًا في نشر المعاملة.
وهذا الاختلاف الكبير في تكلفة الهجوم مقابل الدفاع (Cost to Attack vs. Cost to Defend) يضمن أن إيثريوم، حتى مع تقليل دورة التسوية، يظل قويًا من ناحية الأمان الاقتصادي.
وبالنسبة للتفاعل بين السلاسل، فإن الأمر مهم جدًا، لأنه يعني أن التأكيد السريع وتقليل دورة التسوية لا يتطلبان التضحية بالأمان، وأنه من خلال تصميم نظامي معقول، يمكن أن تتزامن عمليات التفاعل السريع عبر السلاسل مع الأمان الاقتصادي، على الأقل، مما يوفر أساسًا قويًا لتمكين التفاعل عبر السلاسل خلال ثوانٍ.
ختامًا
قد يتساءل البعض: لماذا نهتم بتحسين هذه الثواني أو الدقائق من التأخير؟
في عصر Web3، اعتدنا على الانتظار، واعتبرنا أن «الانتظار» هو الثمن الذي يدفعه التفاعل اللامركزي. لكن، في طريق وصول Web3 للجمهور، لا ينبغي للمستخدمين أن يهتموا أو يضطروا لحساب ما إذا كانت المعاملة على السلسلة قد وصلت إلى Finality، أو أين يقف التثبيت النهائي.
التحقق السريع، نبضات القلب خلال 6 ثوانٍ، وآليات الدفاع غير المتناظرة، كلها في جوهرها تعمل على شيء واحد — وهو إخفاء متغير «الزمن» من وعي المستخدم.
وأكرر ما أقول دائمًا: أفضل شكل من التكنولوجيا هو ذلك الذي يجعل التعقيد يختفي بسرعة في عملية التأكيد.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تطور إيثيريوم "ثانيًا" : من التأكيد السريع إلى ضغط التسوية، كيف يقضي Interop على أوقات الانتظار؟
المؤلف: imToken
إذا كنت تتنقل بشكل متكرر بين Base و Arbitrum أو Optimism عبر الجسور، فمن المؤكد أنك شعرت بـ「إحساس بالانفصال الدقيق」.
على الرغم من أن المعاملات على طبقة L2 أصبحت تقريبًا تنتهي في ثوانٍ، إلا أنه عندما تحاول نقل الأصول من السلسلة A إلى السلسلة B، غالبًا ما يتطلب الأمر انتظار عدة دقائق أو أكثر، وهذا ليس بسبب بطء L2 نفسه، بل لأن العمليات التقليدية تتطلب مسارًا طويلًا ودقيقًا لمعاملة تتعلق عبر الطبقات والعبر السلاسل:
ترتيب L2 → تقديم إلى L1 → توافق L1 وتأكيده النهائي (Finality)، بشكل عام، في بنية إيثريوم الحالية، يتطلب التثبيت النهائي لـ L1 عادة اثنين من Epoch (حوالي 13 دقيقة)، وهذا ضروري من ناحية الأمان، لكنه بالنسبة للتشغيل التفاعلي (Interop) يبدو بطيئًا جدًا.
وبما أن رؤية إيثريوم المستقبلية تتضمن وجود مئات أو آلاف من طبقات L2، التي لا ينبغي أن تكون جزر تنفيذ معزولة، بل يجب أن تتعاون ككيان واحد، فإن السؤال الرئيسي هو: هل يمكن تقليل هذا الانتظار قدر الإمكان؟
وفي هذا السياق، وضعت خارطة طريق التفاعل بين إيثريوم في مرحلة التسريع (Acceleration)، ثلاثة اتجاهات تحسين عالية التنسيق: قواعد التأكيد السريع (Fast L1 Confirmation Rule)، تقليل مدة فترات L1 (Shorter L1 Slots)، وتقليل دورة تسوية الشبكة من الطبقة الثانية (Shorter L2 Settlement).
يمكن القول إن هذا ليس مجرد تحسينات عشوائية، بل هو إعادة هيكلة منهجية لنظام «التأكيد، الإيقاع، والتسوية».
أولاً، قواعد التأكيد السريع: قبل الوصول إلى Finality، أعطِ النظام «إجابة موثوقة»
كما هو معروف، في بنية إيثريوم الحالية، يتراوح زمن الكتلة حوالي 12 ثانية، ويقوم عقد التحقق بالتصويت على الحالة الحالية للسلسلة في كل فترة (slot)، بينما يتأخر التثبيت النهائي (Finality) بعد عدة فترات.
بعبارة بسيطة، حتى لو تم تضمين المعاملة في كتلة، لا يزال يتعين على النظام الانتظار لفترة طويلة ليكون واثقًا من عدم إعادة تنظيمها أو تراجعها، حاليًا، يتطلب الأمر حوالي اثنين من Epoch (حوالي 13 دقيقة) ليتم اعتبار المعاملة غير قابلة للتراجع، وهذا طويل جدًا لمعظم السيناريوهات المالية على السلسلة.
هل يمكننا قبل الوصول إلى Finality، أن نوفر للتطبيقات وأنظمة العبر السلاسل إشارة تأكيد «سريعة وموثوقة»؟ هذا هو الهدف الذي حددته خارطة طريق التفاعل في إيثريوم ضمن مشروع #4: Fast L1 Confirmation Rule (قاعدة التأكيد السريع).
الهدف الرئيسي بسيط جدًا: تمكين التطبيقات وأنظمة العبر السلاسل من الحصول على إشارة تأكيد قوية وقابلة للتحقق خلال 15–30 ثانية، بدلاً من انتظار 13 دقيقة كاملة للوصول إلى Finality.
من الناحية التقنية، فإن قواعد التأكيد السريع لا تتطلب إدخال عملية توافق جديدة، بل تعتمد على إعادة استخدام تصويتات المُصدِقين (attesters) التي تحدث في كل slot ضمن نظام إثبات الحصة (PoS) الخاص بإيثريوم، حيث إذا تراكمت أصوات كافية ومتنوعة في وقت مبكر لكتلة معينة، حتى لو لم تصل بعد إلى مرحلة التثبيت النهائي، يمكن اعتبارها «غير قابلة للتراجع بشكل كبير تحت نماذج هجوم معقولة».
بمعنى آخر، هذا النوع من التأكيد لا يحل محل Finality، لكنه يوفر قبلها إشارة تأكيد قوية ومُعترف بها من قبل البروتوكول، وهو أمر حاسم للـ Interop: أنظمة العبر السلاسل، ومُحلل النوايا (Intent Solver)، والمحافظ، لم تعد بحاجة للانتظار حتى التثبيت النهائي، بل يمكنها أن تتقدم بثقة خلال 15–30 ثانية استنادًا إلى إشارة التأكيد البروتوكولية.
حتى الآن، يُعتبر مفهوم «التأكيد المسبق» (Preconfirmation) الذي تدعمه بشكل كبير رواية Based Rollup، خطوة انتقالية مهمة، وفكرته بسيطة جدًا، تخيل:
عندما نشتري تذاكر قطار على 12306، بمجرد اختيار الرحلة وإجراء عملية التوقيع، يُعطى المستخدم إشعارًا مبدئيًا بالتأكيد، يُعلمه أن عملية الحجز (وكل معاملة على حدة) قد تم قبولها وتدخل في مرحلة التحقق التالية، وهنا يمكن للمستخدم أن يبدأ في تنظيم الرحلة، وتحضير الأمتعة، فقط بعد أن يتم تأكيد المقصورة والمقعد (نشر المعاملة على L1)، يُعتبر الحجز مكتملًا رسميًا.
باختصار، في نظام Based Rollup، يُعنى «التأكيد المسبق» بأن المعاملة تُعتبر ضمن الكتلة قبل أن تُنشر رسميًا على L1، كإشارة أولية للمستخدم بأن المعاملة مقبولة وتحت المعالجة.
«سأعطيك وعدًا شفهيًا قويًا الآن، وسنؤكد بشكل نهائي لاحقًا»، من خلال هذا المنطق متعدد المستويات، فإن خارطة طريق إيثريوم للتفاعل بين السلاسل تميز بين مستويات الثقة المختلفة، وتبني تجربة تفاعلية سلسة قدر الإمكان.
ثانيًا، تقليل مدة L1 Slot: تسريع «نبض» إيثريوم
مقابل مفهوم التأكيد السريع، هناك تعديل أعمق وأهم من الناحية الفيزيائية — تقليل حجم الـ Slot.
إذا كان التأكيد السريع بمثابة «وعد بالدفع لاحقًا قبل التثبيت النهائي»، فإن تقليل مدة الـ Slot هو تقليل دورة التسوية في السجل مباشرة. في خارطة الطريق، الهدف المرحلي للمشروع #5 هو تقليل زمن الـ Slot في إيثريوم من 12 ثانية إلى 6 ثوانٍ.
هذا «نصف» بسيط، لكنه يثير ردود فعل متسلسلة في الشبكة، فكلما كانت الـ Slot أقصر، زادت سرعة إدراج المعاملات في الكتل، وتوزيعها، وتأكيدها، مما يقلل من زمن الاستجابة الكلي للبروتوكول.
ويؤثر ذلك بشكل مباشر على تجربة المستخدم، بما في ذلك التفاعلات مع L1 (مثل تحويل ETH)، وتقديم الحالة إلى L2، وحتى أن الجمع بين تقليل الـ Slot مع قواعد التأكيد السريع يُمكن أن يُنتج «ردود فعل فورية تقريبًا على الشبكة»، مما يمكّن التطبيقات والمحافظ وبروتوكولات العبر السلاسل من تقديم «تجربة تأكيد خلال ثوانٍ».
بالنسبة لبروتوكولات التفاعل عبر السلاسل، فإن تقليل الوقت يعني زيادة كفاءة استخدام الأموال، حيث أن الجسور أو صانعي السوق الذين يديرون الأصول بين السلاسل، يتحملون مخاطر «الأموال في الطريق» التي تستغرق دقائق أو أكثر، ويضطرون لفرض رسوم أعلى لمواجهة تقلبات الوقت.
وعندما يُقصر زمن التسوية ويزداد معدل دوران الأموال، فإن احتجاز رأس المال في الطريق يقل بشكل كبير، مما يؤدي إلى تقليل التكاليف، وخفض رسوم المستخدم، وتقليل تأخير الوصول، وهو ما يشجع المطورين والمستخدمين على العودة إلى طبقة التسوية الآمنة L1، بدلاً من الاعتماد على وسطاء طرف ثالث هش.
بالطبع، رفع معدل نبضات الشبكة إلى الضعف ليس مهمة سهلة. تعمل عدة مجموعات من فريق عمل إيثريوم على هذا التحدي المعقد:
بإجمال، عندما يُدمج تقليل الـ Slot إلى 6 ثوانٍ مع قواعد التأكيد السريع، فإن إيثريوم قد تحقق «ردود فعل فورية تقريبًا على الشبكة»، مما يمكّن التطبيقات والمحافظ من تقديم تجارب تأكيد خلال ثوانٍ غير مسبوقة.
ثالثًا، تقليل دورة تسوية L2: «الأصول تنطلق فورًا»
في خارطة الطريق، المشروع #6: Shorter L2 Settlement، هو الأكثر إثارة للجدل والأكثر خيالًا.
حاليًا، تعتمد Rollup التوقعية (Optimistic Rollup) على فترة تحدي تصل إلى 7 أيام، وحتى ZK Rollup، فهي مقيدة بسرعة إثباتات التحقق، وبصراحة، هذا التصميم آمن جدًا، لكنه يخلق مشكلة واقعية على مستوى التفاعل بين السلاسل:
الأصول والحالة «مقيدة زمنياً» بين السلاسل، مما يرفع تكاليف العبر السلاسل بشكل كبير، ويزيد من عبء إعادة التوازن على المُحلل (Solver)، ويؤدي إلى رسوم أعلى للمستخدمين. لذلك، يُنظر إلى تقليل دورة التسوية كعامل رئيسي لتمكين الانتشار الواسع لـ Interop، ويشمل العمل على:
بالطبع، في نقاشات التفاعل بين السلاسل، هناك سؤال جوهري: إذا قمنا بتقليل فترة التحدي من 7 أيام إلى ساعة واحدة، هل نترك مجالًا للمهاجمين للقيام بأعمال خبيثة؟
نظريًا، لا يُعد هذا القلق بلا أساس، فمخاطر «الرقابة القسرية» (التحكم الجماعي لعقد التحقق) تختلف عن «الرقابة القسرية الناعمة» التي قد تتعرض لها الشبكة، والتي تتعلق بشكل خاص بهجمات «الرقابة الناعمة» التي يقودها مُنشئو الكتل: المهاجمون لا يحتاجون إلى السيطرة على التوافق، بل يكفي أن يضغطوا باستمرار على المُدافعين من خلال تقديم عروض عالية على المعاملات المهمة، مما يمنعها من الوصول إلى السلسلة.
المثير للاهتمام، أن التحليل الاقتصادي المنهجي الوحيد لهذا السيناريو يأتي من ورقة بحثية أصدرها Offchain Labs في فبراير 2025 بعنوان «Economic Censorship Games in Fraud Proofs»، التي وضعت ثلاثة نماذج، من الأكثر تشاؤمًا إلى الأكثر تفاؤلًا، تفترض:
وفي الواقع، بسبب احتمال أن يختار المُصدِقون ترك فجوات (miss slots)، فإن بعض التصاميم قد تتدهور إلى الحالة الأسوأ G¹، لذلك اختارت الدراسة تحليل أسوأ الحالات.
وبناءً على ذلك، اقترح الباحثون استراتيجية دفاعية واقعية جدًا — «الدفاع بالتأخير»، التي تعتمد على أن للمُدافعين حق «تأخير خطوة واحدة»، أي أنهم لا يحتاجون إلى إتمام جميع عمليات التحقق المعقدة خلال ساعة واحدة، بل يكفي أن ينجحوا في تقديم معاملة خاصة على L1.
هذه المعاملة الخاصة تُستخدم بشكل واضح، فهي بمجرد أن تُنشر على السلسلة، تُطيل فترة التحدي من ساعة إلى 7 أيام. على سبيل المثال، إذا اكتشف المُدافع أن حالة L2 غير طبيعية، لا يحتاج إلى إتمام جميع عمليات التحقق خلال ساعة، بل يكفي أن ينجح في تقديم معاملة خاصة على L1، تعمل كإنذار، وتُطيل فترة التحدي تلقائيًا إلى 7 أيام.
وهذا يعني أن المهاجمين سيُجبرون على خوض معركة استنزاف غير متكافئة، حيث يتعين عليهم دفع رسوم أولوية أعلى باستمرار لمنع المعاملة من الوصول إلى السلسلة، ويجب أن يستمروا في ذلك طوال فترة التحدي.
وأظهرت نتائج الدراسة أن، إذا كان المهاجم قويًا جدًا ويستعد لإنفاق 100 مليار دولار لمهاجمة الشبكة بشكل مستمر، فإن:
بمعنى آخر، هذه ميزة هيكلية حاسمة: تكلفة المهاجم تتزايد بشكل خطي، بينما تكلفة الدفاع تتطلب مرة واحدة فقط نجاحًا في نشر المعاملة.
وهذا الاختلاف الكبير في تكلفة الهجوم مقابل الدفاع (Cost to Attack vs. Cost to Defend) يضمن أن إيثريوم، حتى مع تقليل دورة التسوية، يظل قويًا من ناحية الأمان الاقتصادي.
وبالنسبة للتفاعل بين السلاسل، فإن الأمر مهم جدًا، لأنه يعني أن التأكيد السريع وتقليل دورة التسوية لا يتطلبان التضحية بالأمان، وأنه من خلال تصميم نظامي معقول، يمكن أن تتزامن عمليات التفاعل السريع عبر السلاسل مع الأمان الاقتصادي، على الأقل، مما يوفر أساسًا قويًا لتمكين التفاعل عبر السلاسل خلال ثوانٍ.
ختامًا
قد يتساءل البعض: لماذا نهتم بتحسين هذه الثواني أو الدقائق من التأخير؟
في عصر Web3، اعتدنا على الانتظار، واعتبرنا أن «الانتظار» هو الثمن الذي يدفعه التفاعل اللامركزي. لكن، في طريق وصول Web3 للجمهور، لا ينبغي للمستخدمين أن يهتموا أو يضطروا لحساب ما إذا كانت المعاملة على السلسلة قد وصلت إلى Finality، أو أين يقف التثبيت النهائي.
التحقق السريع، نبضات القلب خلال 6 ثوانٍ، وآليات الدفاع غير المتناظرة، كلها في جوهرها تعمل على شيء واحد — وهو إخفاء متغير «الزمن» من وعي المستخدم.
وأكرر ما أقول دائمًا: أفضل شكل من التكنولوجيا هو ذلك الذي يجعل التعقيد يختفي بسرعة في عملية التأكيد.