شرح مفهوم التأكيد المسبق (Preconfirmation) باستخدام Taiko كمثال: كيف يمكن جعل معاملات Ethereum أكثر كفاءة؟

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

العنوان الأصلي: 《Preconfirmation (feat. Taiko): Make Ethereum Fast for the First Time!》

الكاتب: Ingeun Kim : : FP

نظرة عامة على النقاط الرئيسية

• Taiko هي شبكة Layer2 مبنية على Based Rollup، وتهدف إلى تحقيق التوافق الكامل مع Ethereum، مع دفع عملية لامركزية منظمي المعاملات (Sequencer). لمعالجة مشكلة تأخير التأكيد النهائي للمعاملات في آلية Rollup، قدمت Taiko مفهوم "التأكيد المسبق" (Preconfirmation). من خلال ضمان شمولية وترتيب المعاملات للمستخدمين بشكل مسبق، يخفف التأكيد المسبق من مشكلة ضعف كفاءة عملية تأكيد المعاملات في آلية Rollup، مما يعزز تجربة المستخدم بشكل ملحوظ.
• في نموذج Based Preconfirmation، يقدم مدققو L1 ضماناً لنتائج المعاملات للمستخدمين. يجب على مقدمي التأكيد المسبق إيداع ضمانات مالية والالتزام بآلية Slashing لضمان موثوقية النظام. من خلال إدخال آلية التأكيد المسبق، أنشأت مشاريع L2 مثل Taiko نهائية موثوقة للمعاملات، مما يوفر بيئة تشغيل أكثر ملاءمة لخدمات مثل DeFi التي تتطلب تأكيداً فورياً.
• حالياً، هناك العديد من المشاريع التي تشارك في بناء منظومة التأكيد المسبق. من المتوقع أن تعزز هذه التقنية كفاءة منظومة Ethereum L2، وتقوي التوافق مع Ethereum، وتدفع نحو توسع النظام البيئي بأكمله.

تتقدم Taiko بثبات نحو هدفها النهائي كحل Layer2 لـ Ethereum. لتحقيق هذا الهدف، تعطي Taiko الأولوية للتوافق الكامل مع Ethereum، ولامركزية منظمي المعاملات، ودعم المطورين. من الجدير بالذكر أن Taiko تحقق التوافق الكامل مع Ethereum من خلال بنية Based Rollup، وتسمح لأي شخص بالمشاركة كمنظم معاملات، مما يحقق لامركزية المنظمين. ومع ذلك، رغم مزايا نموذج Based Rollup، إلا أن بنيته لا تزال تعاني من بعض أوجه القصور الجوهرية.

ستحلل هذه المقالة مفهوم التأكيد المسبق (Preconfirmation) بعمق باستخدام Taiko كمثال. باعتباره جزءاً أساسياً من تقنية Layer2، يمثل التأكيد المسبق خطوة مهمة في تطور Rollup.

مشكلة الكفاءة الحالية في L2

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

القيود الجوهرية لـ Rollup: عملية تأكيد نهائية غير فعالة للمعاملات

حقق L2 قابلية التوسع من خلال Rollup، بالاعتماد على توفر البيانات ومعالجة المعاملات في منصات L1 مثل Ethereum. ومع ذلك، هناك قيد جوهري في Rollup: رغم إمكانية ترتيب وتنفيذ المعاملات بشكل مستقل، إلا أن جميع العمليات الأخرى لا تزال تنتظر التأكيد النهائي من L1.

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

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

طرح مفهوم التأكيد المسبق

تم طرح مفهوم التأكيد المسبق لحل مشكلة ضعف كفاءة التأكيد النهائي للمعاملات في شبكات L2. يتيح التأكيد المسبق للمستخدمين الحصول على تأكيد أسرع للمعاملات، مما يخفف من التأخير وعدم الكفاءة الشائعين في آلية Rollup.

ما هي المشكلات التي يهدف التأكيد المسبق إلى حلها؟

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

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

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

كيف يحل التأكيد المسبق هذه المشكلات؟

يحل التأكيد المسبق هذه المشكلات من خلال تقديم ضمانات شمولية وترتيب وتنفيذ المعاملات للمستخدمين. يوفر منظم المعاملات المركزي في L2 "تأكيداً ناعماً" للمستخدمين ويصدر شهادة تأكيد مسبق لضمان أن المعاملة سيتم تضمينها في النهاية على L1.

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

هل التأكيد المسبق هو الحل النهائي؟

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

شرح مفهوم وممارسة Based Preconfirmation باستخدام Taiko كمثال

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

قبل فهم Based Preconfirmation بعمق، من الضروري مراجعة بعض الخصائص الرئيسية لـ Taiko لفهم ملاءمة وفوائد هذه الطريقة بشكل أكثر شمولاً.

تحليل حالة Taiko

تُظهر Taiko بشكل كامل الخصائص الأساسية لـ Based Rollup. فهي لا تحقق فقط التوافق الكامل مع بنية Ethereum الأساسية، بل تلتزم أيضاً بالتماشي الكامل مع آليات الأمان في Ethereum. تعتمد Taiko بنية Based Rollup، مما يعني أنها لا تعتمد على منظم معاملات مركزي، بل تعتمد على مدققي Ethereum للقيام بدور منظم المعاملات، المسؤولين عن ترتيب المعاملات والكتل.

أي أن منظمي المعاملات في Taiko هم نفس فئة مقترحي الكتل في Ethereum. يمنحهم هذا التصميم مسؤوليات وحوافز خاصة، مثل الحصول على مكافآت MEV (القيمة القصوى القابلة للاستخراج) وغيرها من الفوائد المرتبطة بهوية المنظم. لذلك، عندما تحدث مشكلات في عملية تنظيم المعاملات في L2 الخاصة بـ Taiko، يتحمل هؤلاء المنظمون المسؤولية بشكل طبيعي بسبب ارتباط مصالحهم في منظومة Ethereum. تخلق هذه الآلية اختلافاً ملحوظاً في مسؤولية التشغيل بين Taiko وغيرها من مشاريع L2 في Ethereum.

بالإضافة إلى ذلك، من الجدير بالذكر أن نموذج Based Rollup في Taiko مصمم ليكون "Based Contestable Rollup (BCR)"، وهي بنية تهدف إلى تحفيز المنافسة الإيجابية. من خلال التصميم المفتوح وغير المصرح به، تضمن Taiko لامركزية النظام وتسمح بمشاركة أي شخص، مما يجعل النظام أكثر عدلاً وشفافية.

التأكيد المسبق القائم على Based Rollup

إذًا، كيف يبدو نموذج التأكيد المسبق المصمم خصيصاً لـ Based Rollup؟ الجواب هو "Based Preconfirmation". يهدف هذا النموذج إلى استبدال آلية التأكيد الناعم التقليدية بتأكيد يتم التحقق منه مباشرة على L1.

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

طرح Justin Drake لأول مرة مفهوم Based Preconfirmation، واقترح دوراً محدداً يُسمى "المؤكد المسبق" (Preconfer)، يمكنه تقديم ضمانات موقعة للمستخدمين توضح ترتيب المعاملة وحالة تنفيذها. لضمان موثوقية الالتزامات، يجب على كل مؤكد مسبق إيداع مبلغ معين من الضمان المالي. إذا فشلوا في الوفاء بالتزاماتهم بشأن ترتيب المعاملة أو حالة التنفيذ، سيواجهون عقوبة Slashing، أي فقدان جزء أو كل الضمان المالي.

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

هناك حالتان تؤديان إلى معاقبة المؤكد المسبق عبر Slashing:

1. أعطال النشاط (Liveness Faults): إذا فشل المؤكد المسبق لأي سبب في تضمين معاملة التأكيد المسبق للمستخدم في السلسلة، تحدث أعطال النشاط. ونظراً لأن هذه الأعطال ليست دائماً متعمدة، فإن العقوبة تكون معتدلة نسبياً. قد تنشأ هذه الأعطال من مشكلات في الشبكة أو انقطاع في سلسلة L1 أو L2، مما يؤدي إلى عدم تضمين المعاملة بشكل صحيح. لحماية المؤكدين المسبقين النزيهين من العقوبات غير المبررة، يتم عادةً تحديد مبلغ العقوبة بالتفاوض بين المستخدم والمؤكد المسبق.
2. أعطال الأمان (Safety Faults): إذا تم تضمين معاملة التأكيد المسبق في السلسلة، لكن النتيجة لا تتوافق مع طلب المستخدم الأصلي، تحدث أعطال الأمان. هذه المخالفة تقع بالكامل على عاتق المؤكد المسبق، لذا تكون العقوبة أشد. يتم مصادرة كامل الضمان المالي للمؤكد المسبق، بغض النظر عما إذا كان الخطأ متعمداً أم لا.

لكي يصبح أحدهم مؤكدًا مسبقًا في نموذج Based Preconfirmation، يجب على العقدة (عادةً مقترح كتلة L1) قبول شروط آلية Slashing وإيداع الضمان المطلوب. بعد الموافقة، يمكن للمؤكد المسبق تقديم الخدمات للمستخدمين وكسب الدخل من خلال رسوم الخدمة.

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

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

لماذا يرغب المستخدمون في دفع رسوم التأكيد المسبق؟

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

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

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

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

ما هي التحديات التي يواجهها Based Preconfirmation؟

لا يزال Based Preconfirmation مجال بحث يحظى باهتمام كبير في مشاريع Layer2 المدفوعة بـ Rollup مثل Taiko. رغم أن هذه الآلية تقدم حلاً واضحاً لتحسين أداء L2 وقابليته للتوسع مع الحفاظ على اللامركزية، إلا أنها لا تزال تواجه بعض التحديات العملية التي يجب التغلب عليها لتحقيق اعتماد أوسع.

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

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

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

خاصة Taiko، التي أحرزت تقدماً كبيراً في تنفيذ Based Preconfirmation. في الوقت نفسه، تتعاون Taiko مع شركاء مثل Taiko Gwyneth وNethermind وChainbound وLimechain وPrimev وEspresso لاستكشاف وتطوير سيناريوهات تطبيق Based Preconfirmation. تهدف هذه الشراكات إلى دفع تطور منظومة L2 إلى الأمام، وسيتم مناقشة المزيد من التفاصيل ذات الصلة في الفصول التالية.

منظور شامل لمنظومة التأكيد المسبق: شرح المخطط الانسيابي واستكشاف المشاريع

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

مخطط عملية التأكيد المسبق

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

قبل شرح الخطوات المحددة في المخطط، دعونا نتعرف على الأدوار المشاركة في عملية التأكيد المسبق ووظائفها:

• المستخدم (User): هو المستخدم الفردي الذي يستخدم شبكة L1 أو L2، ويقوم بإنشاء وإرسال المعاملات. إذا رغب المستخدم في الحصول على ضمان التأكيد المسبق، سيرسل المعاملة بعد كتابتها إلى المؤكد المسبق.
• المؤكد المسبق (Preconferrer): في عملية التأكيد المسبق، يكون المؤكد المسبق مسؤولاً عن مراجعة المعاملة والتحقق من صحتها، ثم تقديم ضمان التأكيد المسبق للمستخدم. من خلال التأكيد المسبق، يمكن للمستخدمين الحصول بسرعة على ضمان حالة المعاملة قبل التسوية النهائية. إذا لم يكن للعقدة أهلية التأكيد المسبق، فإنها تعمل كمشارك غير مؤكد مسبقاً (Non-Preconf Actors)، وتتعامل بشكل أساسي مع المعاملات العادية، مثل عقد التحقق القياسية.
• مدقق L1 (L1 Validator): مسؤول عن التحقق النهائي من المعاملات والكتل على شبكة L1. بمجرد أن يقدم المؤكد المسبق بيانات المعاملة، يقوم مدقق L1 بالتحقق منها وتسجيل البيانات النهائية على سلسلة كتل L1، لضمان اكتمال المعاملة وامتثالها لقواعد الإجماع.
• مدير تحديات التأكيد المسبق (Preconfirmation Challenge Manager): عندما تظهر نزاعات أو مشكلات في عملية التأكيد المسبق، يكون هذا الدور مسؤولاً عن التحقيق في المشكلة واتخاذ الإجراءات المناسبة لحل النزاع. يلعب هذا الدور دوراً محورياً في الحفاظ على عدالة وموثوقية عملية التأكيد المسبق.

الآن، دعونا نستعرض عملية التأكيد المسبق وفقاً لترتيب المخطط الانسيابي:

1. يرسل المستخدم طلب المعاملة إلى المؤكد المسبق ضمن المشاركين في التأكيد المسبق لبدء العملية.
2. يراجع المؤكد المسبق المعاملة ويرسل إيصال التأكيد المسبق، متعهداً للمستخدم بأن المعاملة ستُدرج في كتلة L1، مما يوفر للمستخدم ضماناً أولياً للتأكيد النهائي.
3. يقدم المؤكد المسبق بيانات المعاملة التي يجب تضمينها في كتلة L1 إلى مدقق L1. قد تكون هذه البيانات معاملة فردية أو بيانات مجمعة تمت معالجتها بواسطة منظم معاملات L2.
4. يتحقق مدقق L1 من بيانات المعاملة المقدمة أو البيانات المجمعة ويسجلها في كتلة L1، لضمان امتثالها لقواعد إجماع البلوكشين.
5. بعد فترة من الزمن، تصل الكتلة التي تحتوي على بيانات المعاملة أو البيانات المجمعة إلى النهائية، وتكتمل عملية تأكيد المعاملة رسمياً.
6. يمكن للمستخدم التحقق من النتيجة النهائية للمعاملة من خلال عقدة L1، وتقديم أي نزاعات أو تحديات محتملة بشأن التأكيد المسبق إذا لزم الأمر.
7. إذا لم يتم تضمين المعاملة على L1 كما تم التعهد به، سيواجه المؤكد المسبق عقوبة من مدير تحديات التأكيد المسبق، مثل Slashing للضمان المالي أو تجميد أصوله المرهونة.

استكشاف المشاريع ذات الصلة

• Astria: تهدف Astria إلى استبدال منظمي المعاملات المركزيين بشبكة منظمي معاملات لامركزية، وتدعم مشاركة عدة Rollup في هذه الشبكة. يوفر هذا التصميم مقاومة أقوى للرقابة، ونهائية أسرع للكتل، وتفاعلاً سلساً بين Rollup. لتحقيق نهائية الكتل السريعة، قدمت Astria وظيفة التأكيد المسبق، مما يمكّن Rollup من تقديم تأكيد سريع للمعاملات وتعزيز مقاومة الرقابة، وبالتالي تحسين تجربة المستخدم بشكل كبير.
• Bolt by Chainbound: Bolt هو بروتوكول تأكيد مسبق طورته Chainbound، يوفر لمستخدمي Ethereum خدمة تأكيد معاملات شبه فورية. يعمل على آلية مشاركة غير موثوقة وضمان اقتصادي، ويتوافق مع قناة MEV-Boost PBS الحالية، مما يخلق فرص دخل جديدة للمقترحين. الوظيفة الأساسية لـ Bolt هي التأكيد المسبق على L1، حيث يوفر نهائية فورية للمعاملات الأساسية (مثل التحويلات والتفويضات)، مما يعزز تجربة المستخدم. من خلال نقل مسؤولية شمولية المعاملات من منشئي الكتل المركزيين إلى المقترحين، يعزز Bolt مقاومة النظام للرقابة. كما تضمن آلية تسجيل المقترحين المرهونين بيئة غير موثوقة، وتدعم بمرونة أنواع العقود الذكية المختلفة.
• Espresso System: Espresso System هو بروتوكول يهدف إلى تعزيز التوافقية بين منظومات البلوكشين. يستخدم بروتوكول HotShot للتوافق البيزنطي (BFT) لتحقيق ترتيب المعاملات ونهائية البيانات بسرعة بين عدة سلاسل. يتكون Espresso System من Espresso Network وEspresso Marketplace، ويعملان معاً لتوفير نهائية معاملات سريعة وتوافقية عالية، بهدف تعزيز قابلية التوسع والأمان في منظومة البلوكشين.
• Ethgas: Ethgas هو سوق لتداول مساحة الكتل، حيث تتم مطابقة المعاملات من خلال نظام مركزي، وتنفذ العمليات على السلسلة عبر العقود الذكية. يقدم Ethgas وظيفتين رئيسيتين: التأكيد المسبق للشمولية (ضمان شمول المعاملة ضمن حد Gas محدد) والتأكيد المسبق للتنفيذ (ضمان وصول المعاملة إلى حالة أو نتيجة معينة). يركز Ethgas على حماية خصوصية المعاملات في تداول مساحة الكتل، ويشتهر بهدفه التشغيلي المحايد.
• Luban: يركز Luban على تطوير طبقة تنظيم معاملات لامركزية لربط بيانات معاملات Ethereum وRollup. تم تصميم هذه الطبقة كنظام لامركزي يفصل بين أدوار الاقتراح والتنفيذ. من خلال وظيفة التأكيد المسبق، يضمن Luban إمكانية تنفيذ المعاملات قبل تضمينها في شبكة Ethereum، مما يعزز موثوقية المعاملات بشكل كبير، ويساعد في تحسين الرسوم، وأسعار Gas، وMEV.
• Primev: تطور Primev شبكة مقترحين متكاملة مع MEV، تجمع بين التأكيد المسبق ووظائف MEV لبناء شبكة نظير إلى نظير فعالة وموثوقة. تسجل هذه الشبكة التزامات تنفيذ معاملات Ethereum، وتحفز المقترحين من خلال آليات المكافأة أو العقوبة. تتيح Primev لمشاركي MEV تحديد شروط تنفيذ محددة لمعاملاتهم، ويمكن لمنشئي الكتل والمدققين الالتزام بهذه الشروط، مما يضمن التأكيد المسبق للمعاملات. استناداً إلى EIP-4337، تدعم Primev خيارات تأكيد مسبق ورسوم Gas مرنة، مما يعزز كفاءة معالجة المعاملات ويحسن تجربة المستخدم.
• Puffer Unifi: تعتمد خدمة التحقق النشط (Actively Validated Services, AVS) في Puffer Unifi على EigenLayer، وتركز على حل تحديات التأكيد المسبق في منظومة Ethereum، خاصة في بنية Based Rollup. تستفيد AVS من وظيفة إعادة الرهن في EigenLayer لدعم آلية المشاركة في التأكيد المسبق، وتهدف إلى تحسين كفاءة التأكيد النهائي للمعاملات. مع تطور Based Rollup، تزداد الحاجة إلى مقدمي تأكيد مسبق موثوقين، وتهدف AVS في Puffer Unifi إلى تلبية هذا الطلب. رؤيتها النهائية هي تحقيق تأكيد مسبق فعال دون تغيير البروتوكول الأساسي، مما يدفع نحو نمو مستدام لمنظومة Ethereum.
• Skate: تعتمد خدمة التأكيد المسبق AVS في Skate على الأصول المعاد رهنها على EigenLayer، وتوفر أماناً اقتصادياً لجميع العمليات عبر السلاسل. تتحقق هذه الخدمة من البيانات والمعلومات المجمعة المطلوبة للمعاملات عبر السلاسل، ثم يوقع عليها مرحل Skate ويعدها للتنفيذ. من خلال هذه العملية، تحقق AVS في Skate تأكيداً مسبقاً للبيانات، مما يعزز موثوقية وكفاءة المعاملات عبر السلاسل بشكل كبير.
• Spire: Based Stack من Spire هو إطار عمل Based Rollup لـ Ethereum، يدعم المطورين في بناء سلاسل التطبيقات (App Chains). يسمح هذا الإطار لسلاسل التطبيقات بالتفاعل مباشرة مع Ethereum وتخصيص طريقة تنظيم المعاملات، ويدعم وظائف مثل التبادل عبر السلاسل، مع تحسين تجربة المستخدم من خلال التأكيد المسبق. يدعم Based Stack بيئات تنفيذ متعددة، ويضمن دخل تنظيم المعاملات لسلاسل التطبيقات، ويحافظ على التوافق مع منظمي المعاملات المشتركين التقليديين. كمشروع مفتوح المصدر، يوفر Based Stack للمطورين الأدوات والموارد اللازمة لبناء وإدارة سلاسل التطبيقات، مما يعزز تطويرها وتوافقية منظومة Ethereum.
• Taiko Gwyneth: Taiko Gwyneth هو تصميم Rollup تطوره Taiko، ويصنف ضمن بنية Based Rollup. يهدف إلى تحقيق التوافق الكامل مع Ethereum، مع إدارة تنظيم المعاملات مباشرة على Ethereum. يستفيد هذا التصميم بالكامل من أمان ولامركزية Ethereum، مع توفير إنتاجية عالية ونهائية سريعة. حالياً، تدير Taiko آلية مقترحين للمساعدة في إنشاء الكتل، وتستكشف آلية التأكيد المسبق لتعزيز إنتاج الكتل المربحة داخل المجتمع. تهدف هذه الآلية إلى تحسين جدولة الكتل وكفاءة نشر البيانات. لتحقيق هذه الأهداف، تتعاون Taiko بشكل وثيق مع مشاريع مثل Nethermind وGattaca.

• Chorus One: Chorus One هو مشروع يقدم خدمات التحقق والبنية التحتية لشبكات البلوكشين، ويركز على خدمات الرهن في عدة بروتوكولات لتعزيز استقرار وأمان الشبكة. كمدقق L1، تتمثل مسؤولية Chorus One في التحقق من المعاملات وإنشاء الكتل، مما يعزز موثوقية وكفاءة الشبكة ككل. مؤخراً، أبدت Chorus One اهتماماً كبيراً بتقنية التأكيد المسبق، حتى أنها نظمت فعاليات متخصصة حول هذا الموضوع خلال Devcon 2024.

• Nethermind: Nethermind هو مشروع يركز على تطوير عملاء وأدوات Ethereum، ويهدف إلى تحسين أداء واستقرار شبكة البلوكشين. من خلال إدخال تقنيات تحسين متقدمة، تدفع Nethermind بنشاط نحو زيادة إنتاجية معاملات شبكة Ethereum. فيما يتعلق بتقنية التأكيد المسبق، تجري Nethermind أبحاثاً معمقة، وقدمت اقتراحاً لبرنامج تمويل Taiko لتسريع نشر وظيفة التأكيد المسبق على شبكة Taiko الرئيسية. يستند هذا الاقتراح إلى مشروع Nethermind RFP-001، وينفذ على مرحلتين: المرحلة الأولى ستختبر وظيفة التأكيد المسبق بين مشاركين معتمدين محدودين؛ والمرحلة الثانية تخطط لتوسيع نطاق تطبيق التأكيد المسبق تدريجياً.

نظرة مستقبلية

تسعى Taiko والعديد من مشاريع Layer2 Based Rollup، سواء اعتمدت بنية Based Rollup أم لا، إلى تحسين عملية التأكيد النهائي للمعاملات غير الفعالة في Rollup التقليدي. من خلال إدخال مفهوم التأكيد المسبق (Preconfirmation)، تبني هذه المشاريع نظام تأكيد معاملات يمكّن المستخدمين من تأكيد المعاملات بسرعة وموثوقية أكبر. بهذه الطريقة، تواصل هذه المشاريع استكشاف سبل تحسين تجربة المستخدم وبناء الثقة.

تستفيد Taiko بالكامل من موقعها كمشروع Layer2 Based Rollup، وتدفع بنشاط نحو تنفيذ آلية Based Preconfirmation، لتحقيق التوافق الكامل مع Ethereum واللامركزية. من خلال توفير ضمان تأكيد نهائي سريع وموثوق للمعاملات، حسنت Taiko بشكل كبير سرعة معالجة المعاملات وموثوقيتها، مما أدى إلى تحسين تجربة المستخدم بشكل ملحوظ.

ومع ذلك، أشار العديد من خبراء الصناعة، بمن فيهم Ed Felten من Arbitrum، إلى أن هناك نقصاً في برامج وسيطة ناضجة تدعم التأكيد المسبق بشكل كامل. وهذا يشير إلى أن نضج تقنية التأكيد المسبق ونموذج ربح المؤكدين المسبقين (Preconfer) لا يزالان يواجهان تحديات، وهي قضايا تتطلب حلولاً إضافية.

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

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

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