كيف يحقق المتداول التأكيد الفوري عبر Espresso؟ استعراض تفصيلي لكل مرحلة من التقديم حتى النهائية.

تمر المعاملة بعملية متكررة تتضمن "التقديم → التسلسل → تأكيد الإجماع → ظهور الحالة" قبل أن تُعتبر "مؤكدة" من قبل السلاسل الأخرى أو الجسور أو التطبيقات في بيئة متعددة الشبكات. يعمل Espresso Network (ESP) كطبقة أساسية مشتركة للتأكيد والتسوية، حيث يستقبل الكتل من متسلسلات الـRollup. يستخدم HotShot من خلال شبكة المدققين لتوفير تأييد BFT خلال ثوانٍ، مما يجعل الكتل المؤكدة من Espresso متاحة للوصول من الجهات النهائية.

تُحل هذه العملية تحدي تسلسل التأكيد: لم تعد التطبيقات بحاجة إلى انتظار التسوية النهائية على Ethereum L1 للحصول على تسلسل وحالة قابلة للتحقق؛ يمكن أن تستمر تسوية L1 وفقًا لقواعد الجسر. فهم توقيت تفعيل كل مرحلة وآلية نقل التأكيدات يوضح حدود قراءة الحالة عبر السلاسل.

ما المتطلبات اللازمة لدخول المعاملة إلى Espresso؟

قبل دخول المعاملة إلى مسار تأكيد Espresso، يجب أن يكون النظام جاهزًا للتكامل: يجب أن تكون البيئة المستهدفة متصلة بـEspresso؛ يجب وجود متسلسل معتمد (أو منشئ كتل مكافئ)؛ ويجب قبول المعاملة وفقًا لقواعد التنفيذ والتسلسل الخاصة بالبيئة. لا يستبدل Espresso طبقة التنفيذ لكل بيئة، بل يوفر تأكيدًا لامركزيًا لإخراج المعاملات من المتسلسل.

يوضح الجدول أعلاه أن التأكيد من المستوى الثاني يتطلب وجود "تكامل + تقديم معتمد + قراءة نهائية" جميعها. عادةً ما يلاحظ المستخدم فقط أن "المعاملة تم تقديمها إلى Rollup"، بينما يجب على النظام تضمين تلك المعاملة في كتلة موجهة إلى Espresso.

الخطوة 1: كيف يتم تقديم المعاملات وانتظارها؟

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

خلال مرحلة التقديم والانتظار، قد تعرض الواجهة بسرعة عبارة "تم الاستلام" أو "تم التأكيد مبدئيًا"—وهذه تعليقات من متسلسل الـRollup نفسه؛ لم يحدث تأكيد Espresso بعد. داخليًا، يقفل المتسلسل ترتيب الدفعة، ويولد كتلة للتقديم، ويرسلها عبر واجهة التكامل. يمكن تكرار هذه العملية حسب الحاجة—يتم تجميع وتقديم المعاملات الجديدة عند وصولها.

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

الخطوة 2: كيف يكمل HotShot التسلسل والتأكيد؟

عندما تدخل كتلة إلى Espresso، تدير شبكة المدققين HotShot ضمن إطار إثبات الحصّة (Proof of Stake) وتحمل الأعطال البيزنطية (BFT)، ويتم الاتفاق على ترتيب الكتل وتوافر البيانات (DA). تم تصميم HotShot للاستجابة المتفائلة—يؤكد بأسرع ما يمكن عندما تسمح ظروف الشبكة بذلك. تصف المصادر العامة أوقات تأكيد الشبكة الرئيسية عادةً بعدة ثوانٍ.

يتم تفعيل التأكيد عندما يصوت المدققون ذوو الوزن الكافي على الكتلة المقترحة. بمجرد تحقيق الحد الأدنى، تصبح الكتلة كتلة مؤكدة من Espresso، ويُثبت ترتيبها والتزامها في طبقة الإجماع. يظل التنفيذ مع كل بيئة Rollup أو تطبيق، حيث تنتقل الحالة بشكل حتمي وفقًا للتسلسل المؤكد؛ لا ينفذ Espresso نفسه منطق الأعمال.

يفرق هذا الجدول بين "التأكيد من المستوى الثاني" (يكتمل عبر إجماع HotShot على Espresso) و"التسوية النهائية على L1". يمكن أن تستمر الأخيرة كما هو مصمم أصلاً، لكن قد يتطلب بروتوكول الطبقة أن تكون الكتل المطابقة لتأكيد Espresso فقط مؤهلة للتسوية على L1 الجسرية.

الشكل 1. المسار الأساسي لتأكيد Espresso: تقديم المستخدم/التطبيق → تجميع متسلسل Rollup → تأكيد مدقق HotShot → استهلاك Rollup/الجسر/التطبيق للنهائية.

تعتمد مشاركة المدققين في التأكيد على التخزين وحوافز البروتوكول؛ تخزين ESP ورسوم البروتوكول توضح دور ESP في تخزين المدققين ودفع الرسوم، وهي أساس لتشغيل طبقة التأكيد ولا تغير التسلسل أعلاه.

الخطوة 3: كيف يتم نقل نتائج التأكيد إلى Rollup أو الجسر أو التطبيق؟

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

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

كيف يختلف هذا عن "انتظار التسوية النهائية على Ethereum L1"؟

عند الاعتماد فقط على التسوية النهائية على Ethereum L1، يجب على دفعات Rollup انتظار نهائية L1 قبل أن تعتبر الجسور والتطبيقات عبر السلاسل الحالة آمنة—عادةً ما تستغرق العملية أكثر من عشر دقائق. يحقق مسار Espresso تأكيد BFT خلال ثوانٍ بعد تقديم المتسلسل، مما يسمح للجهات النهائية بقراءة حالة التأكيد مبكرًا، وتبقى التسوية النهائية على L1 نقطة أمان لاحقة.

يبرز هذا الجدول الفرق في "من يقدم التزام التسلسل الموثوق أولاً" و"متى تبدأ الجسور والتطبيقات عمليات عبر البيئات". لا يلغي Espresso التسوية على L1 بل يضيف طبقة تأكيد متكررة وسريعة بينهما.

الشكل 2. مسار Espresso مقابل مسار التسوية على L1 فقط: اليسار يظهر قراءة الجسور/التطبيقات بعد تأكيد HotShot من المستوى الثاني؛ اليمين يظهر العمليات بعد نهائية L1.

ما المخاطر ونقاط الفشل في هذه العملية؟

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

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

الملخص

التأكيد من المستوى الثاني على Espresso Network هو عملية متكررة: يتم أولًا قبول المعاملات من بيئة Rollup، وتجميعها وتقديمها من متسلسل معتمد؛ يكمل مدققو HotShot التأكيد BFT خلال ثوانٍ؛ تصبح الكتل المؤكدة من Espresso متاحة فورًا للقراءة من Rollup والجسر والتطبيق؛ يمكن أن تستمر التسوية النهائية على L1 وفقًا لقواعد المطابقة. تحليل محفزات ونقاط فشل التقديم والتأكيد والنقل يوضح أن "نهائية المستوى الثاني" هي تصميم تسلسل تأكيد، وليست حدثًا منفردًا.

الأسئلة الشائعة

ما هو Espresso Network؟

يعمل Espresso Network كطبقة أساسية مشتركة للتأكيد والتسوية لبيئات متعددة الشبكات والتطبيقات. تحتفظ كل بيئة بقواعدها الخاصة للتنفيذ والتسلسل؛ بعد تقديم الكتل إلى Espresso، يوفر المدققون نهائية سريعة عبر HotShot، يمكن قراءتها من السلاسل والجسور الأخرى.

كيف يحقق Espresso نهائية المستوى الثاني؟

بعد تقديم المتسلسلين المعتمدين الكتل إلى Espresso، يدير المدققون HotShot، ويؤكدون ترتيب الكتل وتوافر البيانات عند بلوغ حد التصويت BFT. تصف المصادر العامة أوقات التأكيد المعتادة بعدة ثوانٍ، مما يسمح للجهات النهائية بقراءة عروض التأكيد دون انتظار التسوية النهائية على Ethereum L1.

ما هو HotShot؟

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

كيف يحسن Espresso سرعة التأكيد عبر السلاسل؟

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

ما هي مخاطر استخدام Espresso؟

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