الكاتب:yyy
تويتر: @y_cryptoanalyst
1. مقدمة
الوقت يمر بسرعة، وفقًا لـ Optimism، فقد مر أكثر من عام منذ إصدار العملة، ووفقًا لـ Arbitrum، فإن إصدار العملة ليس سوى الخطوة الأولى في رحلتهم الطويلة خلال هذه الفترة نفذت ترقية Bedrock وأطلقت وحدة L2 Stack OP Stack، والتي على أساسها تم إنشاء Star Rollup مثل Base، واستكشاف L3 لتعزيز تطبيق Arbitrum Orbit.
وتحت قيادة هذين العملاقين، تجاوزت القيمة الإجمالية للقيمة الإجمالية (TVL) لمسار التراكم بأكمله 10 مليار دولار أمريكي وهي مستقرة حاليًا عند حوالي 10 مليار دولار أمريكي. على الرغم من أن مجموعة Rollup يتم الحديث عنها كثيرًا باعتبارها حل توسعة "التوقيع" الخاص بـ Ethereum، إلا أنها لا تزال تتمتع بسمات مركزية وغير مقاومة للرقابة.
عادةً ما تعتمد سلاسل Rollup السائدة على مُرتِّب مركزي تعمل به الجهة الرسمية. رغم أن مشاريع Rollup مثل Arbitrum وOptimism وStarkNet وضعت لا مركزية المُرتِّب في خارطة الطريق، فهي ما تزال ضمن مرحلة التخطيط ولم تتحقق بعد على المدى القصير.
تُعد المُرتِّبات اللامركزية أهم قطعة في ألغاز لامركزية Rollup. بالنسبة إلى Rollup نفسها، فهي تتمتع بمكانة استراتيجية بالغة الأهمية، وهي ما يتجه إليه الناس.
وفقًا لبيانات L2Beat، حتى 1 أكتوبر 2023 كانت TVL في مسار L2
ثانيًا: رسوم معاملات Rollup
قبل فهم ما هو المُرتِّب، دعنا نتحدث أولًا عن مكوّنات رسوم معاملات Rollup. رسوم Rollup هي رسوم الغاز التي ينشئها المستخدم عند تنفيذ معاملات L2 مثل Arbitrum.
يتكون بشكل رئيسي من جزأين:
1）رسوم تنفيذ L2
2）رسوم بيانات L1
رسوم تنفيذ L2: تكلفة تنفيذ المعاملة على L2 (يجب دفع رسوم تنفيذ لكل معاملة تُنشأ على سلسلة L2).
سعر غاز المعاملة = الرسوم الأساسية في L2 + الرسوم ذات الأولوية في L2
رسوم تنفيذ L2 = سعر غاز المعاملة * كمية غاز L2 المستخدمة
تكلفة بيانات L1: هي تكلفة نشر معاملات L2 على L1. عادةً ما تكون تكلفة بيانات L1 أعلى من تكلفة تنفيذ L2.
رسوم معاملات L2 = رسوم تنفيذ L2 + رسوم بيانات L1
صافي إيراد المُرتِّب = إيرادات رسوم معاملات L2 - تكاليف تشغيل المُرتِّب - رسوم بيانات L1
يمتلك المُرتِّب المركزي الذي تديره الجهة المنفِّذة نوعًا من السلطة في تحديد التسعير (مثلًا: رفع رسوم تنفيذ L2 أو رفع رسوم بيانات L1 قليلًا)، وهذا يفسر سبب تحقيق بعض مشاريع الـRollup المعروفة أرباحًا هائلة.
ما هو المُرتِّب؟
المُرتِّب، كما يوحي الاسم، هو الدور المسؤول عن ترتيب المعاملات. في شبكة Bitcoin، تكون مسؤولية ترتيب المعاملات على عاتق المُعدِّنين؛ وفي Ethereum تتولاها مجموعة العقد. وهي ليست أدوارًا ثابتة، بل تُحدَّد بموجب آليات توافقية من يملك الحق في المشاركة في التنفيذ الترتيبي.
في الوقت الراهن، تُشغِّل معظم Rollups السائدة مُرتِّبًا مركزيًا واحدًا فقط. تدخل معاملات المستخدمين في L2 إلى mempool (وتكون المعاملات داخل mempool في هذه المرحلة غير مرتبة)، فيقوم المُرتِّب بترتيب المعاملات وتجميعها وضغطها في دفعات مرتبة، ثم يرسلها إلى طبقة DA في Ethereum.
خط سير عمل المُرتِّب
هل يتطلب Rollup مُرتِّبًا دائمًا؟
الإجابة: لا. يمكن للمعاملات على Rollup أن تتجاوز المُرتِّب وترسل إلى طبقة الأساس L1 مباشرة، بحيث يتولى L1 ترتيب المعاملات والتسوية، لكن ذلك يواجه استهلاكًا أعلى للغاز ووقت تأكيد معاملات أطول.
يشبه مُرتِّب Rollup استخدام «المسار السريع»؛ إذ يضغط ويجمع مئات/آلاف معاملات L2 في معاملة واحدة على L1، ما يقلل بشكل كبير تكلفة الغاز.
وهذا أيضًا هو سبب تشغيل أغلب Rollups السائدة لمُرتِّبين مركزيين حاليًا: توفير غاز أقل للمستخدمين، وتأكيد معاملات أسرع، لتحسين تجربة المستخدم.
ثالثًا: المُرتِّب المركزي مقابل المُرتِّب اللامركزي
مركزي!
الميزة الواضحة للتمركز هي أنه يمكن ترتيب المعاملات كما يشاء المُرتِّب دون الحاجة لتبديل أحد أو التوافق على نتائج الترتيب. وهذا يعني أيضًا سرعة تأكيد المعاملات جدًا، وبالتالي تجربة مستخدم أفضل؛
لكن التمركز يمنح المُرتِّب أيضًا سلطة كبيرة في ترتيب المعاملات؛ يمكنه ترتيب المعاملات كيفما يشاء لتعظيم فرصه في المراجحة، والاستحواذ على قيمة MEV، وتأخير معاملات المستخدمين أو حتى إجراء رقابة كاملة على معاملات المستخدمين.
يمكن للمُرتِّب اغتنام قيمة MEV داخل كتلة واحدة عبر تغيير ترتيب المعاملات؛ والأخطر هو أنه بما أن المُرتِّب يتحكم في ترتيب عدة كتل متتالية، فمن السهل تنفيذ MEV عبر الكتل (cross-block MEV)، ما يؤدي إلى هجوم أكبر نطاقًا.
الحالات المذكورة أعلاه تقع ضمن سوء تصرف المُرتِّب من تلقاء نفسه. بعض الأخطاء لا يكون المُرتِّب قد قصدها عمدًا، لكنها مع ذلك تُلحق ضررًا بتجربة المستخدم وحقوقه. على سبيل المثال: قد يقوم المُرتِّب بالغلط بإعادة تضمين معاملة تم إِنفاق رموزها بالفعل ضمن الالتزام الناعم، ثم إرسالها إلى التحقق على L1؛ وقد يؤدي ذلك إلى حالة لا تتلقى فيها المعاملة تأكيدًا لفترة طويلة. ومثال آخر: إذا تعطّل مُرتِّب واحد، فقد تمنع ذلك من إصدار كتل على الطبقة الثانية بشكل طبيعي، فتتوقف الشبكة لفترة طويلة.
صيد السمك والقبض على الدجاج لا يمكن جمعهما دائمًا، لكن تحسين أداء Rollup لا يجوز بأي حال أن يتم على حساب اللامركزية ومقاومة الرقابة.
لا مركزي؟
إذا كان التمركز هو 1، فاللامركزية هي متعدد. تختلف مسارات تنفيذ حلول المُرتِّبين اللامركزيين، لكن المفهوم الأساسي واحد: تفويض الصلاحيات.
لم يعد المُرتِّب يملك حقًا مطلقًا مركزيًا في ترتيب المعاملات. وبالنسبة لدور المُرتِّب، يتم اختياره من مجموعة مُرتِّبين معينة عبر آلية انتخاب محددة، مع إجراء تناوب دوري ثابت.
إن اللامركزية تمنع المُرتِّبين من الاستحواذ المستمر على MEV، كما تمنع المُرتِّب الواحد من تدقيق/مراجعة معاملات المستخدمين. وبالإضافة إلى آليات العقوبة عند سوء التصرف، يمكن تنظيم سلوك المُرتِّبين بشكل فعّال.
رابعًا: نظرة عامة على مسار المُرتِّبين اللامركزيين
بعد أن ظللنا نطوف طويلاً، وصلنا أخيرًا إلى صلب الموضوع. توجد طريقتان لإنشاء مُرتِّب لا مركزي: إما أن ينفذ مشروع Rollup نفسه ذلك، أو الاستعانة بطرف ثالث. وبالاستعانة بطرف ثالث، يمكن أيضًا تسمية ذلك Sequencing-as-a-Service، أي التسلسل كخدمة.
تركز مشاريع مثل Espresso وAstria وSUAVE وRadius كلها على حلول مُرتِّبين لا مركزيين، ومسارات التنفيذ تختلف فيما بينها.
1. Espresso
كانت Espresso Systems في المراحل المبكرة مزودًا يركز على حلول الخصوصية. في مارس 2022 أعلنت الحصول على جولة تمويل A بقيمة تقارب 30 مليون دولار، شاركت فيها Electric Capital وSequoia وBlockchain Capital. حاليًا تحوّلت Espresso Systems عمليًا إلى تقديم خدمة Espresso Sequencer، أي مُرتِّب لا مركزي مخصص لـ Rollups.
وضع تمويل Espresso
تمر معاملات L2 في آلية ترتيب Espresso عبر دورة حياة تقريبية كالتالي:
1） يتم إرسال المعاملات التي تحدث على الطبقة الثانية إلى خادم Rollup (API)؛
2） تدخل المعاملة إلى mem池، ثم يقوم المُرتِّب (عبر انتخاب إجماع HotShot) بترتيب المعاملة وإدراجها في كتلة؛
3） يقوم المُرتِّب ببث المعاملة، ثم بعد الوصول إلى إجماع HotShot عبر عقد أخرى تتم عملية إصدار الكتلة، وتُنفَّذ المعاملة؛ يوفر الالتزام الناعم تأكيدًا سريعًا للمعاملة
4） يرسل المُرتِّب «التزام الكتلة» الذي يتضمن المعاملات مرفقًا بشهادة إجماع (QC: Quorum Certificate) ويتم تخزينه في عقد المُرتِّب على L1 (إثبات أن الكتلة حققت نهائية ناعمة عبر الإجماع)؛
5）تقوم عقد Rollup التي نفّذت هذه الكتلة بإرسال حالة Rollup الجديدة إلى L1 (في هذه اللحظة يحتاج zkRU إلى إرفاق إثبات صحة، وORU يفتح فترة التحدّي)
6）يتحقق عقد Rollup من صحة تحديث الحالة المُرسل بواسطة عقد المُرتِّب عبر التحقق من QC (شهادة النصاب).
دورة حياة معاملات L2 في آلية ترتيب Espresso
يبدو هذا التسلسل غامضًا وصعب الفهم. وببساطة، يعني ذلك:
يختار إجماع HotShot واحدًا من بين مجموعة من المُرتِّبين؛ ويتولى هذا المختار مسؤولية ترتيب معاملات Rollup وإدراجها في كتلة. يجب أن توقع الكتلة من قِبل عقد Rollup الأخرى لتحقيق الإجماع (يوافق أكثر من 2/3 من عقد HotShot) كي تكون «نهائية»، ثم تُقدَّم التزامات الكتلة وحالة Rollup الجديدة إلى طبقة الأساس L1 للتحقق.
النهائية المذكورة أعلاه تحمل علامات اقتباس، فـ «النهائية» بعلامات اقتباس ليست مفهومًا واحدًا مع «النهائية» بدون علامات. تهدف «النهائية» بعلامات إلى تأكيد معاملات Rollup بشكل أسرع، مع تأخير أقل وتجربة مستخدم أفضل؛ لكن نهائية معاملات Rollup في النهاية لا بد أن تقوم بها طبقة الأساس L1 عبر التحقق (يحتاج zkRU إلى التحقق من إثبات الصحة، وORU يحتاج إلى انتظار نهاية فترة التحدّي). وعندما يثبت أن معاملات Rollup المقدمة صحيحة، عندها فقط تصبح معاملات Rollup نهائية فعلًا.
وهذا يعني: إذا كانت عملية التحقق من المعاملات على طبقة الأساس L1 غير صالحة، فسيتعين على كتل Rollup الخاصة التي تم بناؤها أن تواجه التراجع/الارتداد. لذلك، «النهائية» تهدف إلى تأكيد المعاملات بسرعة، بينما «النهائية» الثانية تهدف إلى توريث أمان Ethereum.
بنية ترتيب المعاملات بدون Espresso 
بنية ترتيب المعاملات مع دمج Espresso
Espresso + EigenLayer
يعالج Espresso مشكلة تناوب المُرتِّبين ومشكلة تحديد «النهائية» عبر HotShot، كما يعالج مشكلة دخول المُرتِّبين عبر EigenLayer.
آلية إعادة الترهين في EigenLayer تجعل مرهني Ethereum قادرين أيضًا على أن يصبحوا مُرتِّبين في Espresso، ما يوفر ضمانًا أمنيًا لإجماع HotShot.
بعبارة بسيطة: يمكن لحملة/مُرهِني عقد Ethereum أن يصبحوا Espresso Sequencer (ESQ) عبر آلية إعادة الترهين في EigenLayer؛ وبذلك يحصل مُرهِنو Ethereum على عائد عقد PoS، كما يستحوذون أيضًا على قيمة MEV في الطبقة الثانية.
العائد المحتمل لحائزي ETH = مكافآت عقد/عُقد الشبكة الأصلية + مكافآت عقد L2 EVM + مكافآت عقد سلاسل PoS أخرى (باستخدام آلية إعادة الترهين عبر EigenLayer)، ثلاثية دفعات تعزز ETH بشكل كبير.
حل المُرتِّبين اللامركزيين في EigenLayer
يقدّم Espresso حلًا لا مركزيًا عامًا للمُرتِّب (منفّذ التسلسل) لحالات الاستخدام المتعددة. وبالإضافة إلى EigenLayer، تشمل مشاريع شراكات النظام البيئي أيضًا Arbitrum وOP Stack وCaldera وAltLayer وغيرها من مشاريع الوحدات النمطية البارزة.
خريطة مشاريع شراكات نظام Espresso البيئي
2. Astria
تموضع Astria هو كمُرتِّب لامركزي عام وغير مُرخّص، يقدم خدمات مُرتِّب مشتركة جاهزة للاستخدام لمختلف Rollups. أما بالنسبة للتمويل، فقد أعلنت Astria في أبريل 2023 عن إتمام جولة تمويل بذري Seed بقيمة 5.5 مليون دولار بقيادة Maven 11، بمشاركة 1k(x) وDelphi Digital وLemniscap وRobot Ventures وغيرها. ورغم أن حجم التمويل ليس كبيرًا، إلا أن تشكيلة المستثمرين تبدو قوية جدًا.
وضع تمويل Astria
آلية التشغيل
تشغيل المُرتِّب اللامركزي في Astria قريب جدًا من آلية تشغيل Espresso Sequencer من حيث الهدف والتصميم، وكلاهما يسعى إلى إضعاف امتياز المُرتِّب عبر تفويض صلاحية ترتيب المعاملات. وبشكل أكثر تفصيلًا:
بالنسبة لتناوب المُرتِّبين، اقترحت Astria آليتين للتناوب: تناوب القادة البسيط (Leader Rotation) وخوارزمية إجماع تحمل الأخطاء البيزنطية (BFT).
1） تناوب القادة
تتكوّن مجموعة من المُرتِّبين عبر الانتخابات، وتقوم مجموعة المُرتِّبين بتناوب ترتيب معاملات Rollup. تمنع هذه الطريقة مُرتِّبًا واحدًا من الاحتكار المطول لحق ترتيب المعاملات، وتعالج مشكلة المراجعة المستمرة على المستخدمين إلى حدٍّ ما.
آلية تبادل/تناوب القادة في Astria
2）خوارزمية إجماع BFT
على غرار آلية تناوب القائد، يملك المُرتِّب الذي يأتي دوره صلاحية ترتيب المعاملات، لكن ضمن مجموعة المُرتِّبين يجب أن يوافق ما لا يقل عن 2/3 من الأعضاء على هذا الترتيب للوصول إلى إجماع.
لكلتا الطريقتين مزايا وعيوب: فالأولى تكون أسرع في تأكيد المعاملات، وتُمكّن من إنتاج كتل بسرعة، وكفاءتها قريبة من المُرتِّب المركزي. لكن المقابل هو أنه ما زال من الصعب تقييد المُرتِّب المُعيَّن كي لا يتصرف بسوء. أما باستخدام إجماع BFT فإن احتمال ارتكاب المُرتِّبين لسوء التصرف أقل، ولا يلزم إلا أن يصوت على الإجماع ما لا يقل عن 2/3 من المُرتِّبين في المجموعة. غير أن ذلك يتطلب وقتًا للتصويت على الإجماع، ما يسبب مشكلة تأخر/بطء الشبكة.
خوارزمية إجماع BFT في Astria
3. SUAVE
SUAVE هي حل مُرتِّب لامركزي «جاهز للتوصيل والاستخدام» لبناء Flashbots. وباعتباره حلًا عامًا، يمكن لـ SUAVE توفير mempool وبناء كتل لامركزية لأي L1/L2. والاختلاف بين SUAVE وبين تصميم المُرتِّب المشترك السابق يكمن في أن SUAVE Chain بحد ذاتها هي سلسلة متوافقة مع EVM، وتحقق ترتيب المعاملات عبر أسلوب «المزايدة» على الكتل.
بنية SUAVE
يتكون نظام SUAVE من 3 مكونات أساسية: بيئة تفضيلات عامة، وسوق تنفيذ أفضل تنفيذ، وبناء كتل لامركزية.
1）بيئة التفضيلات
تمتاز بخاصية تغطية واسعة، من المعاملات البسيطة إلى الأحداث المعقدة. تُعبَّر تفضيلات المستخدمين على شكل معاملات داخل mempool. وباعتبار mempool بيئة عامة يجمع التفضيلات معًا، يتيح SUAVE بيئة تفضيلات عامة متعددة السلاسل أن تصبح تفضيلات المستخدمين شفافة وواضحة للجميع، ويزيل فجوة المعلومات، ويعالج مشكلة MEV عبر السلاسل إلى حدٍّ ما.
2）سوق التنفيذ
سوق التنفيذ عبارة عن شبكة يشارك فيها المنفِّذون. يقوم المنفِّذون بمراقبة memepool الخاص بـ SUAVE والمنافسة فيما بينهم. تدفع آلية المنافسة المنفِّذين إلى تقديم أفضل تنفيذ لتفضيلات المستخدمين. ويمكن فهمها على أنها: جميع المنفِّذين يحققون تفضيلات المستخدمين عبر أسلوب «المزايدة»، ويقومون بإرجاع أكبر قدر ممكن من قيمة MEV الناتجة عن معاملات المستخدمين إلى المستخدمين.
3） بناء كتل لا مركزية
أخيرًا، وبناءً على التفضيلات التي تم جمعها وأفضل مسار للتنفيذ، تقوم شبكة بناء الكتل اللامركزية بإدراجها داخل الكتل. وبذلك تتم العملية كاملة من اكتشاف المعاملة إلى ترتيبها ثم إصدار الكتل.
المكوّنات الأساسية لـ SUAVE
4.Radius
تتمثل رؤية Radius في طبقة ترتيب مشتركة لا تتطلب الثقة. وبخلاف آليات التنفيذ في الحلول السابقة، يضمن Radius عبر تمكين mempool مُشفّر أن تُرتَّب معاملات Rollup دون ثقة، مما يلغي فعليًا MEV الفعّال وحجب/تدقيق معاملات المستخدمين.
من ناحية التمويل: أعلن Radius في يونيو 2023 إتمام جولة تمويل أولية Pre-seed بقيمة 1.7 مليون دولار، بقيادة Hashed، مع مشاركين تشمل Superscrypt وLambdaClass وCrypto.com.
معلومات التمويل لـ Radius
تقلل المُرتِّبات اللامركزية المبنية على آليات توافقية مثل Espresso وAstria من MEV ومخاطر التدقيق/الرقابة إلى حدّ ما، لكنها تدفع ثمنًا يتمثل في التضحية بقابلية التوسع للشبكة وكفاءة الوقت، مما يؤدي إلى تأخير معين في تأكيد المعاملات (يتطلب الوصول إلى توافق حول ترتيب المعاملات). علاوة على ذلك، ورغم أن ترتيب المعاملات يتم في بيئة لامركزية، إلا أن المعاملات ذات الصلة في mempool تكون شفافة، لذلك ما زال لدى المُرتِّب مجال لإساءة الاستفادة من MEV. يسعى Radius إلى كسر هذه المشكلة من المصدر عبر mempool مُشفّر، حيث تصبح معلومات المعاملات غير مرئية للمُرتِّبين، بهدف القضاء على الاستحواذ الخبيث على MEV والتدقيق.
الهيكل التقني
يمكن تقسيم بنية Radius التقنية إلى أربع طبقات/مستويات وظيفية كبيرة: طبقة الترتيب (Radius)، طبقة التنفيذ (Rollup)، طبقة التسوية وطبقة توفر البيانات.
1）طبقة الترتيب
يقوم المستخدم بتقديم معاملات مشفرة وإثباتات إلى المُرتِّب؛
2. يقوم المُرتِّب بإثبات التحقق والتحقق من المعاملات؛
3. يقوم المُرتِّب بترتيب المعاملات، ولا يمكن فك تشفيرها قبل ذلك؛
4. يقوم المُرتِّب ببناء كتلة؛
5. يقدّم المُرتِّب الكتلة إلى تنفيذ Rollup.
2）طبقة التنفيذ
يتلقى Rollup الكتل من المُرتِّب وينفذ المعاملات وفق الترتيب الذي توفره؛
2. يقدّم Rollup حالة المعاملة وإثبات الحالة إلى طبقة التسوية.
3） طبقة التسوية
طبقة التسوية تستقبل حالة Rollup وإثباتات الحالة القادمة من Rollup، وتقوم بالتحقق من صحة الإثبات وتحديد نهائية المعاملة؛
2. تتحقق طبقة الترتيب مما إذا كان التنفيذ مطابقًا للترتيب.
4）طبقة توفر البيانات
تخزن طبقة توفر البيانات البيانات وتضمن توفرها.
مستويات البنية الوظيفية المختلفة في Radius
آلية تشفير mempool - PVDE
يستخدم Radius مخططًا للتشفير مبنيًا على إثباتات المعرفة الصفرية لإنشاء mempool مشفر عبر آلية «التشفير المتأخر القابل للتحقق عمليًا» (PVDE).
الخطوات التفصيلية كالتالي:
عندما يقدّم المستخدم معاملة إلى المُرتِّب:
1. يقوم المستخدم بتوليد لغز قفل زمني ومفتاح متماثل؛
2. يقوم المستخدم باستخدام مفتاح متماثل لتشفير المعاملة، فتدخل المعاملة المشفرة إلى mempool؛
3. يقوم المُرتِّب بترتيب المعاملات المشفرة، ولا بد أن يقوم المُرتِّب بفك لغز القفل الزمني للوصول إلى مفتاح فك التشفير؛
4. يقوم المُرتِّب بحساب الالتزام بالطلب قبل فك لغز القفل الزمني، ثم يقدّم الالتزام إلى طبقة التسوية (لاستخدامها في التحقق من أن المُرتِّب قد قدّم المعاملات إلى Rollup بالترتيب).
عملية تشفير وفك تشفير معاملات Radius
حلول لامركزية المُرتِّب
يضمن mempool المشفّر عدم الحاجة إلى الثقة تجاه المُرتِّب، لكن يبقى هناك خطر فشل نقطة واحدة. إذا تم تشغيل مُرتِّب واحد مع mempool مشفّر، فإن فشل المُرتِّب سيؤدي إلى تعطل الشبكة. لحل هذه المشكلة، اقترح Radius عدة حلول لتنفيذ المُرتِّب اللامركزي، بما في ذلك آلية انتخاب القادة السريين، وآلية تجزئة مجموعة المُرتِّبين وغيرها.
وبالطبع يمكن لـ Radius أيضًا اختيار الاستناد إلى آلية تناوب المُرتِّبين في Espresso وAstria، مع تحقيق لامركزية ترتيب المعاملات وعدم الحاجة إلى الثقة.
تحسين مساحة الكتلة
يهدف Radius إلى تحقيق هدف يتمثل في حماية المستخدمين مع تعظيم أرباح Rollup عبر تحسين مساحة الكتل. يستخدم Rollup آلية ترتيب من يأتي أولًا يخدم أولًا (FCFS). الميزة هي منع MEV بشكل فعّال، أما العيب فهو أنه يجب التضحية بالأرباح المحتملة لمزاد مساحة الكتلة.
ولحل المعضلتين الصعبتين لترتيب المعاملات المذكورتين أعلاه، يقسّم Radius مساحة الكتل إلى جزأين: مساحة الكتل العلوية ومساحة الكتل السفلية:
ضمنها، تُخصص مساحة الكتل العلوية حصريًا لمعاملات المستخدمين: يتم تشفير معاملات المستخدمين لإزالة التلاعب بترتيب المعاملات، وبالتالي حماية المستخدمين من مخاطر MEV الضارة والرقابة. أما مساحة الكتل السفلية فتُدخل سوقًا للتداول المبني على المزاد؛ حيث يمكن للمُتحكّمين إرسال معاملات مجمعة مع عروض أسعارها إلى المُرتِّب، فيقوم المُرتِّب باختيار أعلى عرض سعر للمعاملات المجمعة وإدراجها في الكتلة. هذه الطريقة تُمكّن من تعظيم أرباح Rollup.
هذا كل شيء بخصوص حلول المُرتِّبين اللامركزيين العامة السائدة حاليًا. أما بالنسبة إلى Rollup، فهناك مفاضلات على عدة أبعاد: هل يتم تشغيل مُرتِّب مركزي أم مُرتِّب لا مركزي؟ هل يتم دمج حل مُرتِّب عام طرف ثالث أم تنفيذ حل لا مركزي داخلي؟ وأي تقنية تُستخدم لتحقيق لامركزية ترتيب المعاملات؟
خامسًا: منافسة/مراهنات بين Rollups
الموازنة 1: هل نذهب نحو اللامركزية؟
تعتمد Optimism وArbitrum وzkSync وBase وغيرها من Rollups السائدة على مُرتِّبات مركزية لكسب أرباح كبيرة، وحتمًا سيتضمن تفويض حق ترتيب المعاملات إلى اللامركزية مشاركة في الأرباح. وبدون النظر إلى المنافسة المتزايدة في مسار Rollup، لا يرغب أحد في اقتسام «الطعام الشهي» الذي تم الاستيلاء عليه. لكن لنفترض أن Rollup قام أولًا بإطلاق مُرتِّب لا مركزي؛ فقد يكون ذلك مدخلًا ضخمًا لحركة المرور، ويخلق تأثيرًا تجريبيًا داخل فئة فرعية من Rollup، مما يدفع Rollups الأخرى إلى لامركزية مُرتِّباتها.
الموازنة 2: دمج مُرتِّب عام تابع لطرف ثالث مقابل حل مخصص داخلي
عمومًا توجد مساران فقط لتنفيذ لامركزية المُرتِّب: إما أخذ حل جاهز من الغير واستخدامه، أو النزول لبنائه بنفسك. فإذا كان بإمكان أطراف مثل Espresso وAstria توفير خدمة مُرتِّب لامركزي جاهزة للاستخدام لـ Rollup، فسيستطيع Rollup الاستمرار في التركيز على تميّز المنتج وتحسين الأداء، وتعزيز قدرته التنافسية الأساسية. بالإضافة إلى ذلك، فإن دمج حلول المُرتِّب اللامركزية من النوع العام يسهل تحقيق قابلية التشغيل البيني، ما يتيح احتمالات إضافية مثل التحكيم عبر Rollups. أما عيب هذا الحل فقد يتمثل في أنه قد لا يوفر تمكينًا فعالًا للعملة الأصلية الخاصة بـ Rollup نفسه.
إذا استخدم Rollup حلًا داخليًا مخصصًا لتحقيق مُرتِّب لا مركزي، فهذا هو الأكثر استهلاكًا للوقت والأغلى. لكن بالفعل هو الطريقة الأكثر فعالية لتمكين عملة Rollup الأصلية محليًا. مثلًا، يمكن لمشاريع StarkNet أن تطلب من المستخدمين رهن الرموز الأصلية لبروتوكول لتصبح ضمن مجموعة المُرتِّبين المشاركة في ترتيب معاملات Rollup، وتفرض رسوم خدمة معينة، وبذلك تتحقق تراكمية القيمة.
الموازنة 3: أي تقنية تُستخدم لتحقيق تنفيذ المُرتِّب بشكل لا مركزي؟
كما ذُكر سابقًا، توجد العديد من حلول التنفيذ التقنية لتحقيق ترتيب معاملات لا مركزي، بما في ذلك على سبيل المثال لا الحصر حلول مبنية على آليات توافق مختلفة، وFCFS، ومزاد مساحة الكتل، وmempool مشفّر، وغيرها. لكل حل تقني مزايا وعيوب: فالحلول القائمة على آليات الإجماع ستكون مقيدة بكفاءة الوقت، وmempool المُشفّر قد لا يحقق تعظيم أرباح Rollup. وبالطبع يمكن أيضًا الرجوع إلى Astria لدمج آليتين تقنيتين مختلفتين. نقطة المفاضلة بين مختلف الحلول التقنية هي الأسئلة التي يتعين على جميع مشاريع Rollup التفكير فيها بعمق.
كُتب في النهاية
رغم أن الرو-ل أب (Rollup) الرائدين في الوقت الحالي، Optimism وArbitrum، قد أصدرا عملات بالفعل، فقد يكون ذلك مجرد البداية، والمنافسة الحقيقية ربما بدأت للتو. وعلى الأقل وفقًا للاتجاهات الحالية، فإن المُرتِّبين اللامركزيين سيكونون ساحة صراع حاسمة.
تتنامى أيضًا مشاريع Rollup المبنية على zk بهدوء. ففي بيئة تزداد فيها حدة المنافسة، قد يؤدي خطأ واحد إلى خسائر لا يمكن تعويضها. لكن في مواجهة الابتكار الذي قد يحدد بقاء المشاريع أو موتها، لا مجال للاختيار أمام Rollups؛ عليهم فقط مواكبة التيار.
مراجع
[1] Binance Research: Rollups في Ethereum مركزية. نظرة على المُنسِّقين/المُرتِّبين اللامركزيين
[2] Espresso HotShot: Consensus Designed for Rollups
[3] تلخيصات على مستوى الحزم—قدرات خارقة من تسلسل L1
[4] Introducing Astria: The Shared Sequencer Network https://blog.astria.org/introducing-astria/
[5] Introducing the Astria Development Cluster
https://blog.astria.org/introducing-the-astria-development-cluster/
[6] Why Decentralize Sequencers?
https://blog.astria.org/why-decentralize-sequencers/
[7] IOSG شرح مفصل لـ SUAVE: العقد القادم لعقد MEV في نمو حجمه
[8] The Future of MEV is SUAVE
[9] Radius Gitbook