على حدود ميمبُول التشفير

القيمة التي يمكن استخراجها من خلال تضمين أو استبعاد أو إعادة ترتيب المعاملات في كتلة تُعرف بـ "القيمة القابلة للاستخراج القصوى، أوMEV. تعتبر MEV شائعة في معظم سلاسل الكتل، وقد كانت موضوع اهتمام ونقاش واسع في المجتمع.

ملاحظة: يفترض أن تكون هذه المدونة على دراية أساسية بـ MEV. قد يرغب بعض القراء في البدء بقراءة شرح MEV.

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

لسوء الحظ، لأسباب عملية ونظرية، لا نرى أن المجمعات المشفرة توفر حلاً عالمياً لمشكلة MEV. نستعرض الصعوبات ونستكشف كيف يمكن تصميم المجمعات المشفرة.

كيف تعمل mempool المشفرة

لقد كانت هناك العديد من الاقتراحات لبرك الذاكرة المشفرة، لكن الإطار العام لبرك الذاكرة المشفرة هو كما يلي:

1. يُبث المستخدمون معاملاتم المشفرة.
2. تتم المعاملات المشفرة على السلسلة (في بعض المقترحات بعد أن تكون)مخلط بشكل قابل للإثبات عشوائياً)
3. بعد أن يتم الانتهاء من الكتلة الملتزمة، يتم فك تشفير المعاملات.
4. أخيرًا، يتم تنفيذ المعاملات.

لاحظ أن الخطوة 3 (فك تشفير المعاملة) تشكل تحديًا مهمًا: من يقوم بفك التشفير، وماذا لو لم يتم فك التشفير؟ ستكون الحلول الساذجة أن نقول إن المستخدمين أنفسهم يقومون بفك تشفير معاملاتاتهم (في هذه الحالة لن تكون هناك حاجة حتى للتشفير، ولكن يمكن ببساطة إخفاء الالتزامات). ومع ذلك، فإن هذا النهج ضعيف: يمكن للمهاجم أن يقوم بـ MEV المضاربة.

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

ربما يواجه المستخدمون بعض العقوبات لفشلهم في فك التشفير، لكن هذا أمر معقد للتنفيذ. يجب أن تكون العقوبة هي نفسها لجميع المعاملات المشفرة (لأنها مشفرة وبالتالي غير قابلة للتمييز)، ولكن يجب أن تكون أيضًا كبيرة بما يكفي لردع MEV المضاربة حتى ضد الأهداف ذات القيمة العالية. سيتطلب ذلك ربط رأس المال الكبير، والذي يجب أن يكون مجهول الهوية (لتجنب تسريب المعلومات حول المعاملات التي ينشرها أي من المستخدمين). وسيكلف ذلك المستخدمين الشرفاء في حالة وجود خطأ أو فشل في الشبكة يمنع محاولتهم الشرعية لفك التشفير.

لذا، تقترح معظم الاقتراحات أن يتم تشفير المعاملات بطريقة تضمن إمكانية فك التشفير في مرحلة ما من المستقبل — حتى لو كان المستخدم الذي ينشر غير متصل أو لا يتعاون. يمكن تحقيق ذلك بعدة طرق:

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

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

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

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

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

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

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

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

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

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

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

التحديات الفنية لبرك التشفير الميمبول

تحديات عملية هامة عدة تحد من قدرة الميمبول المشفر على منع MEV. بشكل عام، من الصعب الحفاظ على سرية المعلومات. ومن المثير للاهتمام أن التشفير هو أداة نادراً ما تُستخدم في مجال الويب 3. لكن لدينا عقود من الخبرة العملية التي تُظهر التحديات في نشر التشفير على الويب (TLS/HTTPS) ومن أجل الاتصال الخاص (من PGP إلى منصات المراسلة المشفرة الحديثة مثل Signal أو Whatsapp). بينما يُعتبر التشفير أداة للحفاظ على السرية، إلا أنه لا يضمنها.

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

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

يمكننا اعتبار عدة أنواع من البيانات الوصفية، بعضها يمثل تحديات تقليدية مع التشفير وبعضها فريد ل mempool المشفر.

• حجم المعاملة: التشفير بمفرده لا يخفي حجم النص العادي المشفر. (هناك، بشكل مشهور، استثناء محدد تم عمله في التعريفات الرسمية للأمان الدلالي لاستبعاد إخفاء حجم النص العادي الذي يتم تشفيره.) هذه هي نقطة هجوم كلاسيكية على الاتصالات المشفرة. (في مثال شهير، حتى مع التشفير، يمكن لمتجسسيمكن تحديد ما هو الفيديويتم بثه عبر Netflix في الوقت الفعلي من حجم كل حزمة في تدفق الفيديو.) في سياق mempool المشفر، قد تحتوي أنواع معينة من المعاملات على حجم محدد يكشف المعلومات.

• وقت البث: التشفير لا يخفي أيضًا معلومات التوقيت (أخرىنقطة هجوم كلاسيكية). في سياق الويب 3، قد يقوم بعض المرسلين - على سبيل المثال، في البيع المنظم - بإجراء معاملات في فترات منتظمة. قد يكون توقيت المعاملات مرتبطًا أيضًا بمعلومات أخرى، مثل النشاط في البورصات الخارجية أو الأحداث الإخبارية. طريقة أكثر دقة لاستغلال معلومات التوقيت هي التحكيم بين CEX وDEX. يمكن للترتيب الاستفادة من إدخال معاملة تم إنشاؤها في أقرب وقت ممكن، مستفيدة من المعلومات الأحدث حول أسعار CEX. يمكن لنفس الترتيب استبعاد أي معاملات أخرى (حتى لو كانت مشفرة) تم بثها بعد نقطة زمنية معينة، مما يضمن أن تكون معاملته وحدها هي التي تتمتع بأحدث معلومات الأسعار.

• عنوان IP الأصلي: قد يستنتج الباحثون هوية مرسل المعاملة من خلال مراقبة الشبكة الند للند ومراقبة عنوان IP الأصلي. كانت هذه المشكلة في الواقع تم التعرف عليه منذ أكثر من عشر سنواتفي الأيام الأولى من البيتكوين. يمكن أن يكون هذا مفيدًا للباحثين إذا كان لدى المرسلين أنماط محددة - على سبيل المثال، قد يمكّن معرفة المرسل من ربط عملية مشفرة بمعاملات سابقة تم فك تشفيرها بالفعل.

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

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

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

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

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

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

تعاني العديد من مشاكل mempool المشفرة من مشاكل مشتركة مع سلاسل الكتل التي تهدف إلى ضمان خصوصية المعاملات (مثل Zcash و Monero). إذا كان هناك جانب إيجابي، فهو أن حل جميع التحديات المتعلقة بالتشفير لتقليل MEV سيفتح كعرض جانبي الطريق لخصوصية المعاملات.

التحديات الاقتصادية ل mempool المشفرة

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

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

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

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

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

تحديات الكفاءة الأخرى

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

واحدة من عواقب هذه الكفاءات هي زيادة عدم اليقين في الأسعار، نتيجة التأخير الإضافي الذي تقدمه mempool المشفرة. وبالتالي، من المحتمل أن يزداد عدد حالات فشل التداول بسبب تجاوز حدود انزلاق السعر وإهدار مساحة السلسلة.

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

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

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

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

براناف غاريميديهو باحث مشارك في a16z Crypto. يقوم بإجراء أبحاث حول المشكلات في تصميم الآليات ونظرية الألعاب الخوارزمية كما يتعلق الأمر بأنظمة blockchain. يركز بشكل خاص على كيفية تفاعل الحوافز عبر مجموعة blockchain. قبل a16z، كان براناف طالبًا في جامعة كولومبيا حيث حصل على درجة في علوم الكمبيوتر.

جوزيف بونيو هو أستاذ مشارك في قسم علوم الحاسوب في معهد كورت في جامعة نيويورك، ومستشار تقني لشركة a16z crypto. يركز بحثه على التشفير التطبيقي وأمان البلوكتشين. قام بتدريس دورات حول العملات المشفرة في جامعة ملبورن، وجامعة نيويورك، وستانفورد، وبرينستون، وحصل على درجة الدكتوراه في علوم الحاسوب من جامعة كامبريدج ودرجات بكاليوس/ماجستير من جامعة ستانفورد.

ليوبا هايمباخ هو طالب دكتوراه في السنة الرابعة تحت إشراف البروفيسور الدكتور روجر واتنهوفر في الحوسبة الموزعة (ديسكو)مجموعة في ETH زيورخ. يتركز بحثها حول بروتوكولات البلوكشين مع التركيز على التمويل اللامركزي (DeFi). بشكل خاص، يركز على تمكين نظام بيئي للبلوكشين والتمويل اللامركزي يكون متاحًا، لامركزيًا، عادلًا، وفعالًا. كانت متدربة بحث في a16z crypto خلال صيف 2024.

الآراء المعبر عنها هنا هي آراء الأفراد من AH Capital Management, L.L.C. (“a16z”) المقتبسين، وليست آراء a16z أو شركاتها التابعة. تم الحصول على بعض المعلومات الواردة هنا من مصادر خارجية، بما في ذلك من شركات المحفظة التابعة للصناديق التي تديرها a16z. على الرغم من أن المعلومات مأخوذة من مصادر يُعتقد أنها موثوقة، إلا أن a16z لم تتحقق بشكل مستقل من هذه المعلومات ولا تقدم أي تمثيلات حول دقة المعلومات الحالية أو المستمرة أو ملاءمتها لحالة معينة. بالإضافة إلى ذلك، قد يتضمن هذا المحتوى إعلانات من أطراف ثالثة؛ لم تقم a16z بمراجعة مثل هذه الإعلانات ولا تؤيد أي محتوى إعلاني يتضمنه.

يتم تقديم هذا المحتوى لأغراض إعلامية فقط، ولا ينبغي الاعتماد عليه كنصائح قانونية أو تجارية أو استثمارية أو ضريبية. يجب عليك استشارة مستشارك الخاص بشأن هذه الأمور. الإشارات إلى أي أوراق مالية أو أصول رقمية هي لأغراض توضيحية فقط، ولا تشكل توصية استثمارية أو عرضًا لتقديم خدمات استشارية استثمارية. علاوة على ذلك، فإن هذا المحتوى ليس موجهًا ولا مقصودًا للاستخدام من قبل أي مستثمرين أو مستثمرين محتملين، وقد لا يُعتمد عليه تحت أي ظرف من الظروف عند اتخاذ قرار بالاستثمار في أي صندوق تديره a16z. (سيتم تقديم عرض للاستثمار في صندوق a16z فقط من خلال مذكرة الطرح الخاصة، واتفاقية الاشتراك، وغيرها من الوثائق ذات الصلة لأي صندوق من هذا القبيل ويجب قراءتها بالكامل.) أي استثمارات أو شركات محفظة يتم ذكرها أو الإشارة إليها أو وصفها ليست تمثيلاً لجميع الاستثمارات في الآليات التي تديرها a16z، ولا يمكن ضمان أن تكون الاستثمارات مربحة أو أن الاستثمارات الأخرى التي ستُجرى في المستقبل سيكون لها خصائص أو نتائج مماثلة. تتوفر قائمة بالاستثمارات التي قامت بها الصناديق المدارة بواسطة أندريسن هورويتز (باستثناء الاستثمارات التي لم يمنح المُصدر إذنًا لـ a16z للإفصاح عنها علنًا بالإضافة إلى الاستثمارات غير المعلنة في الأصول الرقمية المتداولة علنًا) في https://a16z.com/investments/.

المحتوى يتحدث فقط اعتبارًا من التاريخ المحدد. أي توقعات أو تقديرات أو تنبؤات أو أهداف أو آفاق و/أو آراء معبر عنها في هذه المواد قابلة للتغيير دون إشعار وقد تختلف أو تكون متعارضة مع الآراء المعبر عنها من قبل الآخرين. يرجى مراجعة https://a16z.com/disclosures لمعلومات مهمة إضافية.

تنبيه:

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