تلبي blockchain الخاصة بـ Ethereum متطلبات الأمان واللامركزية العالية، ولكنها غير قابلة للتطوير. على وجه التحديد، رسوم المعاملات مرتفعة جدًا لتشغيل العقود الذكية الثقيلة من الناحية الحسابية. كما أنه يمكنه فقط تسجيل عدد قليل من المعاملات على كل كتلة. ولتحسين قابلية التوسع، تم اقتراح عدة حلول مختلفة. ومن بين هذه الحلول، أحد أكثر الحلول نجاحًا هو نوع شبكة الطبقة الثانية (L2) التي تسمى بروتوكولات التجميع المتفائلة. تم اقتراح عدة تصميمات مختلفة لبروتوكولات التجميع التي تعتمد على Ethereum – أحد الأمثلة على ذلك هو Arbitrum. في حين أن تصميم هذه البروتوكولات لكيفية تفويض العمليات الحسابية الثقيلة لها يختلف، إلا أنها تشترك في شيء واحد مشترك: من وقت لآخر تقوم بنشر دفعات (مضغوطة) من المعاملات على سلسلة كتل الإيثيريوم، والتي يشار إليها بالطبقة الأساسية أو الطبقة. 1 (L1). ويمكن استخدام هذه المعاملات المسجلة على الطبقة الأساسية لاحقًا كمرجع لبروتوكولات التجميع والعقود الذكية، التي تحكم حالات النزاع المتعلقة بحالة تنفيذ المعاملات.
تعمل بروتوكولات التجميع (الطبقة الثانية، باختصار) على إنشاء أسئلة تصميم اقتصادي جديدة لحلها. وفي هذا المشروع نتناول إحداها. على وجه التحديد، نناقش نشر دفعات البيانات من سلاسل القيمة المجمعة للطبقة الثانية على الطبقة الأساسية والتي تشكل معظم التكاليف التي تتكبدها سلاسل القيمة المحتسبة. يتم تجميع معاملات المستخدم المرسلة إلى بروتوكول التجميع مع تردد ثابت ثم ضغطها لإنشاء دفعة. نحن ندرس مسألة كيفية تقليل تكاليف ترحيل الدُفعات في هذا المشروع. نحن نحاول العثور على استراتيجية مثالية لتحديد موعد ترحيل دفعات المعاملات حيث يتقلب سعر L1 لترحيل البيانات. تضيف مثل هذه الخوارزمية إلى قوة النظام، وبشكل عام، إلى أمنه. إن المقايضة واضحة: تجنب ترحيل الدفعات عندما يكون السعر مرتفعًا، ولكن في الوقت نفسه، تجنب التأخير كثيرًا في الترحيل.
الدافع وراء هذا السؤال هو الخبرة التاريخية مع تقلب رسوم قاعدة غاز الإيثريوم بطريقة يمكن التنبؤ بها جزئيًا، وفي بعض الأحيان، مواجهة فترات من الرسوم الأساسية المرتفعة جدًا عند نشر منتج رئيسي عليها. أحد الأمثلة التي لا تُنسى على ذلك تضمنت رسمًا أساسيًا يزيد عن 100 ضعف المعيار لفترة عدة ساعات. قرر بروتوكول تراكمي واحد على الأقل، وهو Arbitrum، التحكم يدويًا في سياسة ترحيل الدُفعات خلال تلك الحالة. هذه الفواصل الزمنية ليست متكررة جدًا ولا طويلة جدًا، مما يعطي الأمل أنه بعد بعض التأخير، ستنخفض تكاليف النشر في النهاية، ويمكن استئناف النشر.
نقوم بتحليل تكلفة الدُفعة إلى جزأين: تكلفة الترحيل التي يمكن ملاحظتها بشكل مباشر عند ترحيل الدُفعات، وتكلفة التأخير التي لا يمكن قياسها بشكل مباشر. وبشكل أكثر واقعية، فإننا نفسر التكلفة الإجمالية على أنها مجموع تكاليف الترحيل والتأخير.
تكاليف التأخير لها عدة مكونات:
• الأول هو أمر نفسي: لا يحب المستخدمون عدم نشر الدفعات لفترة طويلة من الوقت، حيث قد يشير ذلك إلى أن مكونات النظام معطلة أو غير متوفرة.
• ويتعلق الجزء الثاني بالنهائية المؤجلة: لا يتم إنهاء معاملات L2 بشكل كامل حتى يتم ترحيلها كجزء من دُفعة ويكون ترحيل هذه الدُفعة نهائيًا على L1. وحتى ذلك الحين، يجب على المستخدمين إما الانتظار حتى النهاية أو الثقة في جهاز التسلسل في نظام L2 ليكون صادقًا وغير معيب، مما قد يتسبب في تأخير النهاية. يفرض هذا التأخير النهائي تكاليف على بعض التطبيقات.
• ويتعلق الجزء الثالث بالطبيعة الفنية المحددة لحساب رسوم المعاملة على مجموعات L2: أي، يتم حساب رسوم المعاملة عند إنشاء المعاملات، وليس عند نشرها على L1. ولذلك، يؤدي المزيد من التأخير إلى تقديرات أقل دقة لتكلفة المستوى الأول التي تعزى إلى معاملات المستوى الثاني، مما يزيد من خطر التسعير غير العادل أو غير الفعال للمعاملات المجمعة.
نحن نمثل المشكلة كعملية قرار ماركوف. في كل جولة، نقوم بحساب إجمالي التكاليف بشكل مستقل عن الجولات السابقة. تتميز كل جولة بحجم وسعر قائمة الانتظار الحالية، والتي تشكل حالة. يتم تصميم السعر في الجولة التالية كمتغير عشوائي، والذي يعتمد على السعر الحالي. اعتمادًا على الإستراتيجية المتبعة في الجولة الحالية، يقوم المتغير العشوائي الذي يشير إلى السعر في الجولة التالية بنقل الحالة إلى الحالة التالية. من أجل التنفيذ العملي، نقوم بفصل مساحة السعر واستخدام تقريب منفصل لمتغير عشوائي مستمر. من أجل حل مشكلة التحسين المتمثلة في العثور على الإستراتيجية المثالية في كل جولة، نستخدم أدوات من البرمجة الديناميكية مثل التعلم السريع. يتيح لنا هيكل الحل تصميم خوارزمية عملية لنشر الدُفعات، والتي تبدو بديهية وبسيطة. تتميز الخوارزمية بمعلمتين فقط. لقد قمنا باختبار الخوارزمية مقابل عدد قليل من الخوارزميات المعيارية الطبيعية، بناءً على بيانات الرسوم الأساسية للإيثيريوم للعام السابق. تغطي البيانات الفترة الكاملة من تقديم EIP 1559 في أغسطس 2021 حتى نوفمبر 2022. ويتيح لنا هذا الاختبار الخلفي العثور على مجموعات المعلمات المثالية لجميع الخوارزميات ومقارنة أدائها.
الأعمال ذات الصلة
إن مشكلة التحسين المطروحة تشبه إلى حد كبير مشكلة سياسة المخزون (IP)، التي تمت دراستها لفترة طويلة في أدبيات بحوث الاقتصاد والعمليات (المرجع [1]، [2]). في مشاكل الملكية الفكرية، يجب بيع العناصر المنتجة حديثًا مقابل بعض الأسعار ويتم توزيع سعر الطلب. ورغم أن مشكلة تحسين الملكية الفكرية تتلخص في تعظيم الإيرادات ــ وهو ما يتحقق من خلال تعظيم الإيرادات من التجارة وتقليص تكاليف الصيانة ــ فإن مشكلتنا تكمن في تقليص التكاليف إلى الحد الأدنى. والفرق الوحيد بين مشكلة التحسين لدينا ومشكلات IP هو أن تكلفة التأخير في مشاكل IP خطية في حجم المخزون، بحيث يتم تفسير تكلفتها على أنها تكلفة صيانة العناصر المخزنة، في حين أننا نمثل التكلفة على أنها خطية فائقة في عدد التأخير أغراض. يظهر في [3] أفضلية الاستراتيجيات الثابتة البحتة في مجموعة واسعة من عمليات اتخاذ القرار لماركوف. تمت مناقشة تقارب خوارزمية البرمجة الديناميكية التي تغطي حالتنا أيضًا في [4].
النتائج والاستنتاجات
نتيجة بحثنا هي خوارزمية فعالة وقوية. على وجه التحديد، تعمل الخوارزمية التي تحافظ على متوسط وأقصى عدد من الدُفعات في قائمة الانتظار مقبولة بدرجة كافية على تحسين تكاليف النشر للخوارزمية التافهة، التي تنشر الدُفعات فورًا عند إنشائها، بنسبة 8%. من ناحية أخرى، فإن الخوارزمية التي تهتم بشكل معتدل فقط بطول قائمة انتظار الدُفعات يمكنها تحسين تكاليف نشر الخوارزمية التافهة بنسبة 29%. أي أننا نحصل على خوارزميات فعالة مع ضمانات المتانة. في كل جولة، لا تقوم الخوارزمية الجديدة بنشر عدد كبير جدًا من الدُفعات ويكون عدد الدُفعات المحفوظة في قائمة الانتظار محددًا بوظيفة نشر السعر في كل جولة. يمكن استخدام النتائج التي توصلنا إليها من خلال المشاريع التي تنشر البيانات إلى الطبقة الأساسية بمعدل منتظم. تشمل طرق البحث المستقبلية مشكلة التحسين حيث تعتمد الأسعار الحالية والمستقبلية على عدد الدُفعات المنشورة في كل جولة. قد يكون هذا هو الحال إذا أصبحت بروتوكولات التجميع هي المهيمنة في قابلية التوسع في الرسوم الأساسية. إن معرفة الطرف الثابت الأمثل متروك أيضًا للبحث المستقبلي.
لمزيد من المحتويات التقنية والتفاصيل الدقيقة للنمذجة/التنفيذ، راجع ورقتنا: https://arxiv.org/pdf/2212.10337.pdf