أصبحت آليات رسوم المعاملات نماذج العمود الفقري لفهم وساطة منتجي الكتل بين المستخدمين الراغبين في التعامل و "السلسلة" (أو "البروتوكول") التي يتعامل عليها المستخدمون. نظرا للقدرة على استخدام بعض الإمدادات التي توفرها السلسلة ، يجب على منتجي البلوك التحكيم في المستخدمين الذين سيكون لديهم القدرة على استخدام المورد النادر للتنفيذ على السلسلة ، وبأي تكلفة. في Ethereum ، بالنسبة لمسألة التكلفة ، فإن منتجي الكتل مقيدون بآلية رسوم EIP-1559 ، والتي تحدد ديناميكيا سعرا احتياطيا من كتلة إلى كتلة ، تسمى "الرسوم الأساسية". الرسوم الأساسية هي سعر ، معبرا عنه لكل وحدة غاز ، والتي يجب أن تدفعها معاملة المستخدم ليتم تضمينها وتنفيذها. يجوز للمستخدم تقديم ما يسمى ب "رسوم الأولوية" بما يتجاوز الرسوم الأساسية ، لزيادة تحفيز منتجي البلوك في أوقات الازدحام.

في هذه المذكرة، نحقق في مسألة أسواق الرسوم المضمنة، أي أسواق الرسوم التي تعيش داخل أسواق الرسوم الأخرى. تم مناقشة هذا السؤال في سياق مختلف في ورقة حديثة من Maryam Bahrani و Pranav Garimidi و Tim Roughgarden، "Gate"تصميم آلية رسوم المعاملات في عالم ما بعد MEV 9”. في هذا البحث، يقوم الكتّاب بنمذجة استخدام الباحثين، مما يوسّع وساطة الوصول إلى السلسلة بين المستخدمين ومنتجي الكتل. يتلقى منتجو الكتل "تلميحات" من الباحثين، المتجسّدة في حزم ذرية من المعاملات التي يجب أن تُدرج في السلسلة. سوق رسوم الباحثين مدفوعة بوسيلة هدف تعظيم كمية تعرف بالقيمة القصوى المستخرجة أو MEV.

In our setting, users wish to access the chain but do not express their demand using protocol-legible transactions. Instead, users produce “operations”, to be bundled by entities known as “bundlers”, who then originate a protocol-legible transaction packing the operations together towards execution. Thus, to the EIP-1559 fee mechanism, bundlers are the users of the chain, yet the actual users must first obtain inclusion in the bundle of a bundler before they may gain inclusion to the chain. In other words, we may see this setting as part of the larger question of …تعاون الكتلة الإنشائية، والتي تنشأ مع (البناة/الباحثين الجزئيين) بالإضافة إلى قوائم الاستثناء.

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

للتحقيق في التمييز بين أسواق الرسوم المباشرة وآلياتها المضمنة (الفرعية)، يجب علينا تحديد القيود الاقتصادية التي يلتزم بها المجمع. في القسم التالي، نقدم نموذجًا بسيطًا لدالة تكلفة المجمع مستندًا إلى الممارسة، وتحديدًا المجمعين الذين يشاركون في بروتوكول ERC-4337، الذي نلخصه بإيجاز.

نموذج

التجميع في ERC-4337

يقوم المستخدم الذي يرغب في أداء بعض الأنشطة على السلسلة عبر الحزم بإصدار عملية مستخدم (UserOp ، أو عملية). ينبعث UserOp هذا من محفظة المستخدم ، على سبيل المثال ، بعد التفاعل مع DApp. بمجرد بث UserOp ، قد يقرر بعض المجمعين الذين يتلقون العملية تضمينه في حزمة. الحزمة هي معاملة وصفية "حساب مملوك خارجيا" (EOA) ، والتي تكتب بيانات UserOps المضمنة في حقل bundle.calldata الخاص بها. يصدر المجمع الحزمة لإدراجها في كتلة من قبل منتج كتلة (نناقش العلاقة بين المجمع ومنتج الكتلة في ملاحظة مستقبلية).

بمجرد أن يتم تضمين الحزمة في الكتلة، وتتجه الكتلة إلى السلسلة، يتم تنفيذ الحزمة جنبًا إلى جنب مع المعاملات الأخرى في الكتلة. بشكل أساسي، تتم خطوات تنفيذ الحزمة على النحو التالي:

• التحقق المسبق: ستستهلك معاملة EOA الخاصة بالمجمع 21000 غاز ، وسيؤدي الاتصال بعقد EntryPoint إلى إعداد المتغيرات الرئيسية لتتبع تنفيذ العمليات في حلقة التشغيل.
• عملية حلقة 3: لكل عملية مدرجة في الحزمة، تحدث الخطوتان التاليتان:
  • خطوة التحقق: يقوم مشغلي المستخدم بأداء العمليات التي تحتوي على خطوة تحقق، والتي يتم ترميزها في "محفظة العقد الذكي" المنشأة في البداية من قبل المستخدم (أثناء UserOp الأولي). يمكن أن تقوم خطوة التحقق بفحص بسيط للتوقيع، أو أداء عمليات أكثر تعقيداً لـ "منح" الحق لـ UserOp بالمتابعة في تنفيذه. يتم قياس خطوة التحقق بواسطة op.verificationGasLimit.
  • خطوة التنفيذ: هو النواة الأساسية لـ UserOp، تقوم خطوة التنفيذ بأداء العملية الموصوفة في op.callData. تتم مراقبة هذه الخطوة أيضًا، باستخدام op.callGasLimit.

كما هو موضح في التحليل السابق ، يتم تنفيذ خطوة التحقق المسبق مرة واحدة ، مما يوفر إمكانية استهلاك تكاليف التحقق المسبق عبر جميع المستخدمين المشمولين. عند تنفيذ الحزمة ، يتم تحميل جميع التكاليف (على سبيل المثال ، block.basefee + رسوم الأولوية التي يدفعها المجمع إلى منتج الكتلة بما في ذلك) على المجمع ، الذي يجب أن يضمن أن عمليات المستخدم تعوضها بما يكفي عن التكاليف المتكبدة. نجعل هذه العبارات دقيقة في القسم التالي.

نموذج سوق الرسوم للحزم

نحاول أن نظل متسقين مع نماذج أسواق الرسوم الكلاسيكية. المستخدم t الذي يرغب في إرسال عملية لديه بعض القيمة vt لتنفيذ العملية. نفترض أن جميع العمليات لها نفس الحجم S (أي نفس الغاز المستخدم في خطوات التحقق والتنفيذ) ، وبالتالي نعبر عن جميع الكميات كأسعار لكل وحدة غاز.

يعبر المستخدمون عن رغبتهم في أن يتم تضمينهم من خلال إصدار عرض BT مع تشغيلهم. في الوقت الحالي ، لا نفترض قواعد نحوية محددة للمستخدم للتعبير عن عرضه للتضمين ، على سبيل المثال ، القدرة على التعبير عن الحد الأقصى للرسوم ورسوم الأولوية جنبا إلى جنب مع تشغيلها ، كما يفعلون مع EIP-1559. يتم جمع عمليات المستخدم في mempool M ، والتي تمثل الحالة المعلقة لهذه العمليات حتى إدراجها.

سوق رسوم EIP-1559 يكشف عن سعر احتياطي r المعروف باسم "الرسم الأساسي"، الذي يجب أن يتحمله المجمعون عند تنفيذ حزمتهم. إذا كانت الحزمة تحتوي على n عمليات، فيجب على المجمع تكبد على الأقل n × S × r. بالإضافة إلى ذلك، نظرًا لأن الحزمة تستهلك "غاز السابق التحقق منه"، فإن المجمع سيدفع إضافيا F × r

. يتم تقديم العمليات المتضمنة في الحزمة من خلال مجموعة B.

وظائف تكلفة الحزمة

نحن الآن ننظر في التكاليف التي يتكبدها المجمعون لتضمين حزمهم في الكتلة.

دالة التكلفة على السلسلة: يقوم المجمع الذي يصدر الحزمة B عندما يكون الرسم الأساسي r بإنفاق تكلفة:

مشكلة المجمع تعكس مشكلة منتج الكتلة المعبرة في[Roughgarden 2021] 3. هناك، كان على منتج الكتلة التأكد من توفير قيمة ما μ لتعويضها عن تكلفة تضمين معاملة إضافية في كتلتهم (على سبيل المثال، قد يعوض μ عن الحمل الإضافي في الكتلة، الذي يؤخر انتشارها وبالتالي يزيد من مخاطر إعادة التنظيم). يجب على سوق رسوم مستوى الكتلة بعد ذلك التأكد من أن منتج الكتلة معوض على الأقل عن التكلفة الإجمالية n × S × μ، في حال قام منتج الكتلة بتضمين n معاملات في كتلته. ستتطلب سوق الرسوم على مستوى المجمع تعويض المجمع على الأقل عن التكاليف الخارجية

السلسلة اللامتناهية التي يتكبدونها من السوق الأكبر للرسوم التي يعتمدون عليها.

يقدم ERC-4337 إمكانية تحميل التكاليف بعيدًا عن مشاركة تكاليف الغاز المسبقة للتحقق. إذا كانت جميع العمليات تستخدم نفس نظام التوقيع لخطوة التحقق الخاصة بها ، فقد يتم توقيع هذه العمليات بـمجمع 2بواسطة الحزمة، بحيث بدلاً من التحقق من n توقيعًا على السلسلة، يمكن التحقق من توقيع واحد. في هذه الحالة، ستحتاج وظيفة تكلفة الحزمة لاحتساب التكاليف الخارج السلسلة التي يتحملها الحزمة عند أداء التجميع. فيما يلي، نفترض أن مثل هذه التكاليف تكون خطية بعدد العمليات، وهو افتراض مماثل ل[Wang et al., 2024] 2, بتكلفة هامشية ω.

نحن أيضًا نأخذ في الاعتبار استهلاك الغاز المخفض لكل عملية، نظرًا للتوفير الناتج عن التجميع. عند التجميع، ليس من الضروري أن تنشر العمليات توقيعها، ولكنها تتطلب عملية تجميع إضافية. في السلاسل حيث تكلفة بيانات الاتصال مكلفة، ولكن عمليات / الحسابات الزواجية رخيصة، يوفر التجميع بالتالي توفيرات لكل عملية. في هذه الحالة، نشير بـ S′ < S إلى الحجم المخفض للمعاملة. كما نحتاج أيضًا إلى مراعاة زيادة استخدام الغاز في مرحلة ما قبل التحقق F′ > F، التي تحتوي الآن على النشر والتحقق من توقيع التجميع الواحد على السلسلة.

وظيفة تكلفة مجمعة: يقوم المجمع بإصدار حزمة B بتوقيعات مجمعة عندما تكون الرسوم الأساسية r وتنفق تكلفة:

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

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

إعادة زيارة كميات سوق الرسوم

يمكننا الآن التعبير رسميا عن المفاهيم ذات الصلة بسوق رسوم مستوى الحزمة، مستمدة من الأدبيات السابقة بشكل مباشر، مع مراعاة الضم وتضمينها.

قاعدة تخصيص مستوى الحزمة: يقرر التخصيص x (على مستوى الحزمة) مجموعة العمليات التي يضمها الحافظ في حزمته، بناءً على مجموعة الذاكرة الحالية M والرسوم الأساسية r.

قاعدة الدفع على مستوى الحزمة: بالنظر إلى مجموعة العمليات المحددة B، تعيين قاعدة الدفع لكل مستخدم مدرج رسماً:

وظيفة فائدة المستخدم:

في المبدأ، يمكننا السماح بوجود قاعدة حرق qt(B) التي تعبر عن حقيقة أن الحزمة قد لا تتلقى مجموع جميع مدفوعات المستخدم المضمنة. ومع ذلك، لا نعتبر ذلك في هذه الملاحظة.

(المتقصر) دالة فائدة للمجمّع:

إذا كان TFM (x، p) على مستوى الحزمة يتوافق مع المحفز للحزم الميوبية (MBIC) ، فإن الحزم الميوبية تحقق أقصى قدر من فائدتها عند اتباع نصيحة قاعدة التخصيص x (أي ، ضبط B = x (M ، r)) ، لكل مجموعة M ورسوم قاعدة r.

تشكيل حزم متعددة

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

يمكننا كتابة مجموعة الحزم الناتجة بواسطة القسم x (M ، β) ك B (x (M ، r)). بشكل حدسي ، تتكون هذه الحزم من العمليات التي لا تنتمي إلى المجموعة المفهرسة 0. بالنظر إلى مجموعة من الحزم B ، فإن قاعدة الدفع هي:

يصبح وظيفة المرافق للمستخدم:

ويصبح وظيفة الأداة المجمعة:

لعبة الباندلر

يجب أن يتم تعويض إدخال المعاملات في الكتل بكمية معينة μ لمنتجي الكتل ، والتي يفترض أنها تكون خطية بالنسبة لحجم المعاملة في على سبيل المثال ،[Roughgarden, 2021] 3. تشير هذه الكمية إلى التكلفة البديلة التي يتحملها منتج الكتلة لإضافة معاملة إضافية إلى كتلته ، على سبيل المثال ، بزيادة تأخير الثرثرة الخاص بهم وبالتالي زيادة فرصهم في إعادة تنظيم الكتلة. في دليل الحصة ، على الرغم من أن جدولة البروتوكول تسمح بوقت كافٍ لنشر كتلة كاملة،ألعاب التوقيتلقد أدى إلى ديناميات انتشار "اللحظة الأخيرة" التي جعلت هذا المعلمة μ مرة أخرى ذات صلة.

في أي حال، قد نلاحظ أن مشكلة تقاسم التكاليف على مستوى الكتلة وعلى مستوى الحزمة مختلفة جدا. على مستوى الكتلة، قد لا تحتاج الصفقة إلى معرفة ماذا يحدث داخل الكتلة لوضع عرض الإدراج الخاص بها وفقًا لـ EIP-1559 (قد ترغب في معرفة ما يحدث فيما يتعلق بـ MEV[البحراني وآخرون، 2024] 9 , ولكننا سنعتبر هذه مسألة منفصلة في الوقت الحالي). على مستوى الحزمة، لم تعد تكاليف رؤوس الأموال خطية بعدد المعاملات، ولكن يمكن تمويل رأس المال الثابت من خلال العديد من المعاملات. علاوة على ذلك، يجب أن تكون تكلفة التجميع لعمليات المستخدم غير خطية بعدد المعاملات (على سبيل المثال، بعض الأدلة فعالة بشكل فعال دون خطية في الحجم الذي يُثبت)، مما يتيح إمكانية تمويل التكلفة الإجمالية على عدة مستخدمين.

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

• يمكن تعيين op.maxPriorityFeePerGas و op.maxFeePerGas وفقًا للتقنيات التي يستخدمها المستخدم في EIP-1559 ، أي أن المستخدم سيقوم بتعيين هذه السمات لمعايرة المبلغ الذي هم على استعداد لدفعه في أسوأ الحالات (maxFee) والمبلغ الذي هم على استعداد لإضافته لدفع منتج الكتلة النهائية (maxPriority). ولكن كيف يجب على المستخدم تقدير الغاز؟
• op.preVerificationGas هي سمة لعملية المستخدم يجب تعيينها للإشارة إلى كمية "الغاز الإضافي" الذي تخطط عملية المستخدم لاستهلاكه. في نموذجنا، نتيح للمستخدمين
• تعني F هذا "فوق الرأس الغاز الثابت". إذا تم تضمين n مستخدمًا في الحزمة ، فيجب على كل مستخدم ضبط preVerificationGas = F / n. ومع ذلك ، إذا قام المستخدم بإعداد عمليته مع سيناريو أسوأ للحالة في الاعتبار ، فسيقوم بضبط preVerificationGas = F.

ثم يكون preVerificationGas الناقل الرئيسي الذي يستخدمه المستخدمون للتوسط في عرضهم ومحاولة تحسين حساب تكاليف الحزمة. لنفترض أن n مستخدمًا يأتون إلى السوق مع عملياتهم، ويتم إقناعهم جميعًا بالمزود للمزايدة في أسوأ الحالات بأن يكونوا وحدهم في الحزمة. سنفترض أيضًا أن المستخدمين يضبطون maxPriorityFeePerGas الخاص بهم على الصفر لأجل هذا المثال. ثم يقوم هؤلاء المستخدمون n جميعًا بضبط preVerificationGas = F، ويتمكن المزود من إنتاج حزمة تعوضهم عنها:

بينما يجب أن يتحملوا تكلفة:

مرة واحدة يقومون بنشر الحزمة التي تقوم بربط جميع العمليات معًا في كتلة. يؤدي هذا إلى تحقيق ربح للمُجمع بقيمة π = (n−1)×F×r.

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

في المرحلة الأولى ، يرسل المستخدمون عملياتهم ، والتي تلتزم بسماتهم مثل preVerificationGas. في المرحلة الثانية ، يقرر المجمع الذي تلقى جميع معاملات المستخدم إخراج حزمة أو مجموعة من الحزم. ومن المثير للاهتمام ، حتى إذا كان المستخدمون يعرفون عدد المستخدمين الآخرين الذين سيلعبون في المرحلة الأولى ، أي حتى لو كانت n معرفة شائعة بين جميع المستخدمين ، فقد يتمكن المجمع من إجبار المستخدمين على تعيين أسوأ الحالات preVerificationGas = F من خلال التهديد باللعب

، أي تهديد بالاحتفاظ بكل مستخدم في حزمة منفصلة له وتحصيل أقصى قدر من الغاز F.

يرجى ملاحظة أن هذا التهديد قد لا يكون موثوقًا به، حيث يتوقع المستخدمون أن يفضل الحزمة النقلية اللعب

، بمعنى آخر، يتم إخراج حزمة واحدة تحتوي على جميع العمليات المذكورة هنا، وتحقق قيمة π. ومع ذلك، قد لا يكون للمستخدمين الوصول إلى القيمة الحقيقية لـ n، وبالتالي فإنهم غير قادرين على ضبط preVerificationGas الخاص بهم بطريقة تجبر المجمع على تجميع جميعها بشكل مثالي.

حالة مثالية: يتم تقسيم التكاليف بين المستخدمين في الحزمة. حالة متشائمة: يدفع المستخدمون مبالغ أكثر مما يجب ولا يتم تقسيم التكاليف. 731 × 755 77.6 كيلوبايت

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

تتوقع أليس أن يظهر 9 مستخدمين آخرين بجانب نفسها، ولذلك تضع قيمتها المسبقة للغاز التحقق عند 1 لأنها تعلم أن F = 10. قيمة أليس وقيمة جميع المستخدمين الآخرين متوافقة مع تعيينهم لقيمة مسبقة للغاز التحقق = 3، لكنها تحاول دفع أقل كمية ممكنة لإدراجها. كما يتبين أنه يظهر فقط 5 مستخدمين في السوق، الذين قاموا جميعًا بتعيين قيمتهم المسبقة للغاز التحقق عند 1 أيضًا. لن يتم تعويض الحزمة عن F = 10 وحدة من الغاز، وبالتالي لا يخرج المجمع بدلًا ويتلقى المستخدمون 0 فائدة. هذا واضح أنه غير مثلى، حيث يمكن للمستخدمين جميعًا تعيين قيمة مسبقة للغاز التحقق = 2 على سبيل المثال وتلقي 1 فائدة (أقصى قيمة مسبقة للغاز التحقق التي كانوا على استعداد لتحديدها ناقص القيمة الفعلية المسبقة للغاز التحقق التي دفعوها ليتم تضمينها).

عمل مستقبلي

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

تنصل:

1. تمت إعادة طبع هذه المقالة من [ethresear], جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [دافيدريزولي]. إذا كان هناك اعتراضات على هذا النشر مرجعين، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتعاملون معه بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك الكاتب ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقالة إلى لغات أخرى من قبل فريق Gate Learn. إلا إذا ذكر ذلك، فإن نسخ أو توزيع أو ارتكاب الانتحال في المقالات المترجمة ممنوع.