معمای بقای MEV؛ چرا ارزش ترتیب‌بندی تراکنش‌ها از بین نمی‌رود؟

ارزش قابل استخراج یا MEV یکی از مهم‌ترین مفاهیم برای درک اقتصاد پنهان در شبکه‌های بلاکچینی است. این مفهوم در نگاه اول ممکن است صرفاً به نحوه قرار گرفتن تراکنش‌ها در یک بلاک مربوط به نظر برسد، اما در واقع مسئله بسیار گسترده‌تر است. هر زمان چند تراکنش یا سفارش برای دسترسی به یک فرصت اقتصادی محدود با یکدیگر رقابت کنند و ترتیب اجرای آن‌ها بتواند نتیجه متفاوتی ایجاد کند، اولویت اجرای تراکنش به یک متغیر ارزشمند تبدیل می‌شود. این مسئله فقط به اتریوم، ماینرها یا حتی بلاکچین‌های عمومی محدود نیست و می‌توان نمونه‌های مشابه آن را در شبکه‌های دارای مجوز، صرافی‌های غیرمتمرکز، سامانه‌های معاملاتی پرسرعت و حتی بازارهای مالی سنتی مشاهده کرد. به همین دلیل، برای بررسی MEV نباید فقط به این سؤال پاسخ داد که آیا یک شبکه امکان تغییر ترتیب تراکنش‌ها را فراهم می‌کند یا خیر؛ بلکه باید بررسی کرد چه کسی قدرت تعیین این ترتیب را در اختیار دارد، اولویت چگونه تعیین می‌شود، رقابت برای دستیابی به آن در چه سطحی اتفاق می‌افتد و ارزش حاصل از این رقابت در نهایت به کدام بخش از سیستم منتقل می‌شود.

برای توضیح این موضوع گاهی از تشبیه «پایستگی» استفاده می‌شود. در فیزیک، اصل پایستگی انرژی بیان می‌کند که انرژی از بین نمی‌رود و تنها از شکلی به شکل دیگر تبدیل می‌شود. MEV یک قانون فیزیکی نیست و نمی‌توان گفت مقدار آن در تمام شبکه‌ها ثابت باقی می‌ماند، اما این تشبیه می‌تواند چارچوب مناسبی برای درک ارزش ترتیب‌بندی باشد. یک شبکه می‌تواند مم‌پول عمومی را حذف کند، تراکنش‌ها را رمزنگاری کند، سازنده بلاک را از پیشنهاددهنده جدا کند، برای پردازش سفارش‌ها حراج ایجاد کند یا از معماری دارای مجوز استفاده کند. تمام این تغییرات می‌توانند مقدار و شکل MEV را تغییر دهند و برخی انواع مخرب آن را کاهش دهند، اما اگر ترتیب اجرای درخواست‌ها همچنان بتواند نتیجه اقتصادی متفاوتی ایجاد کند، انگیزه برای دستیابی به اولویت نیز ممکن است در نقطه دیگری از سیستم ظاهر شود. در یک شبکه این رقابت ممکن است میان Searcherها و Builderها شکل بگیرد و در شبکه‌ای دیگر به رقابت برای زیرساخت سریع‌تر، دسترسی بهتر به Sequencer یا پرداخت هزینه مشخص برای اولویت تبدیل شود. بنابراین مسئله اصلی بیش از آنکه «حذف MEV» باشد، نحوه مدیریت ارزش ناشی از ترتیب‌بندی است.

چرا ارزش ترتیب‌بندی به‌سادگی از بین نمی‌رود؟

برای شکل‌گیری ارزش ترتیب‌بندی معمولاً سه عنصر باید هم‌زمان وجود داشته باشند: منبع محدود، رقابت و اهمیت ترتیب اجرا. اگر تعداد نامحدودی از کاربران بتوانند یک فرصت را بدون تأثیر بر یکدیگر استفاده کنند، اولویت اهمیت چندانی نخواهد داشت. اما بسیاری از فعالیت‌های مالی چنین شرایطی ندارند. یک فرصت آربیتراژ ممکن است پس از اولین معامله از بین برود، یک موقعیت مشخص فقط یک بار لیکوئید شود و حجم موجود در یک سطح قیمت نیز محدود باشد. بنابراین هنگامی که چند بازیگر برای استفاده از یک فرصت محدود تلاش می‌کنند، این سؤال مطرح می‌شود که کدام درخواست باید ابتدا پردازش شود و همین اولویت می‌تواند دارای ارزش باشد.

نکته مهم این است که حذف یک روش خاص برای تعیین اولویت الزاماً خود مسئله را حذف نمی‌کند. برای مثال، اگر شبکه‌ای مم‌پول عمومی داشته باشد، کاربران ممکن است تراکنش‌های در انتظار را مشاهده کنند و براساس آن برای قرار گرفتن در موقعیت بهتر رقابت کنند. اگر همان شبکه مم‌پول عمومی را حذف کند، این نوع رقابت می‌تواند کاهش پیدا کند، اما ممکن است شکل دیگری از رقابت ایجاد شود که در آن سرعت رسیدن درخواست به زیرساخت شبکه اهمیت بیشتری پیدا کند. در چنین شرایطی، کاربری که ارتباط سریع‌تر یا مسیر کوتاه‌تری با زیرساخت پردازش دارد می‌تواند از نظر زمانی در موقعیت متفاوتی قرار گیرد. بنابراین ارزش ترتیب‌بندی از بین نرفته است؛ بلکه منشأ رقابت از «مشاهده تراکنش» به «سرعت دسترسی» منتقل شده است.

به همین دلیل، مفهوم «پایستگی MEV» را بهتر است به‌عنوان یک چارچوب تحلیلی در نظر گرفت و نه یک قانون مطلق. معماری شبکه واقعاً می‌تواند مقدار MEV را کاهش دهد، برخی استراتژی‌ها را از بین ببرد یا هزینه اجرای آن‌ها را افزایش دهد. آنچه لزوماً از بین نمی‌رود، انگیزه اقتصادی مرتبط با اولویت در شرایطی است که ترتیب اجرا نتیجه متفاوتی ایجاد می‌کند. این تفاوت بسیار مهم است، زیرا باعث می‌شود به جای تمرکز صرف بر شعار «حذف MEV»، درباره محل شکل‌گیری ارزش ترتیب‌بندی، بازیگران دارای قدرت و نحوه توزیع این ارزش سؤال کنیم.

دسته‌بندی مدل‌های مختلف مدیریت ارزش ترتیب‌بندی

برای مقایسه معماری‌های مختلف می‌توان آن‌ها را براساس نحوه تعیین ترتیب، محل شکل‌گیری رقابت و سرنوشت ارزش حاصل از اولویت دسته‌بندی کرد. این مقایسه به معنای برتری یک مدل بر مدل دیگر نیست، زیرا هر معماری برای اهداف متفاوتی طراحی شده است و محدودیت‌های خاص خود را دارد.

این جدول نشان می‌دهد که ارزش ترتیب‌بندی فقط یک شکل ندارد. در اتریوم، بخش قابل توجهی از رقابت در ساخت بلاک مشاهده می‌شود، در معماری‌های دارای مجوز انتشار اطلاعات محدودتر است، در بازارهای سنتی مسیر ارسال سفارش و latency نقش مهمی دارند و در Hyperliquid بخشی از مفهوم اولویت به‌صورت مستقیم در قواعد پروتکل تعریف شده است. بنابراین برای مقایسه این سیستم‌ها باید به معماری کامل آن‌ها نگاه کرد و صرف وجود یا نبود یک مم‌پول عمومی نمی‌تواند معیار کافی برای قضاوت درباره MEV باشد.

اتریوم؛ زمانی که ترتیب تراکنش‌ها به یک بازار تبدیل می‌شود

اتریوم یکی از شناخته‌شده‌ترین نمونه‌ها برای بررسی MEV است، زیرا تعداد زیادی قرارداد هوشمند و برنامه مالی در یک محیط اجرایی مشترک فعالیت می‌کنند. این ویژگی باعث ایجاد Composability یا ترکیب‌پذیری می‌شود؛ یعنی یک قرارداد می‌تواند در همان محیط با قرارداد دیگری تعامل داشته باشد و وضعیت ایجادشده توسط یک برنامه روی عملکرد برنامه دیگر اثر بگذارد. همین قابلیت یکی از پایه‌های اصلی اکوسیستم مالی اتریوم است، اما در عین حال شرایطی ایجاد می‌کند که ترتیب اجرای تراکنش‌ها اهمیت زیادی پیدا کند. تغییر قیمت در یک صرافی غیرمتمرکز می‌تواند یک فرصت آربیتراژ در صرافی دیگری ایجاد کند، تغییر ارزش وثیقه می‌تواند یک موقعیت را وارد شرایط لیکوئیدیشن کند و اجرای یک تراکنش بزرگ ممکن است وضعیت استخر نقدینگی را برای تراکنش‌های بعدی تغییر دهد.

در اطراف این ساختار، بازیگران تخصصی مختلفی شکل گرفته‌اند. Searcherها شرایط شبکه و برنامه‌های مالی را بررسی می‌کنند و به دنبال موقعیت‌هایی هستند که ترتیب اجرای تراکنش‌ها در آن اهمیت دارد. Builderها مجموعه‌ای از تراکنش‌ها را برای تشکیل یک بلاک کنار یکدیگر قرار می‌دهند و Proposer مسئول پیشنهاد بلاک در فرآیند اجماع است. این تفکیک نقش‌ها باعث شده است MEV فقط یک رفتار پراکنده میان کاربران نباشد و بخشی از آن در قالب یک بازار تخصصی پیرامون ساخت بلاک شکل بگیرد.

مفهوم Proposer-Builder Separation یا PBS نیز از همین مسئله ناشی می‌شود. ایده اصلی PBS این است که وظیفه ساخت بهترین بلاک ممکن از وظیفه پیشنهاد آن به شبکه جدا شود. Builderهای تخصصی می‌توانند برای ساخت بلاک رقابت کنند و Proposer براساس قواعد سیستم یکی از پیشنهادها را انتخاب کند. این طراحی تلاش نمی‌کند ادعا کند که ارزش ناشی از ترتیب تراکنش‌ها کاملاً ناپدید می‌شود، بلکه هدف آن سازمان‌دهی بهتر بازار ساخت بلاک و کاهش برخی فشارهای مرتبط با تخصصی شدن استخراج MEV است. در کنار این ساختار، موضوعاتی مانند تمرکز Builderها، وابستگی به زیرساخت‌های واسط و امکان سانسور نیز مطرح هستند و به همین دلیل توسعه معماری PBS همچنان یکی از موضوعات مهم تحقیق و توسعه در اتریوم محسوب می‌شود.

در نتیجه، اهمیت اتریوم در بحث MEV فقط به حجم فعالیت‌های مالی آن مربوط نیست. این شبکه نمونه‌ای از رویکردی است که بخشی از ارزش ترتیب‌بندی را به رسمیت می‌شناسد و تلاش می‌کند برای آن قواعد و بازار مشخصی ایجاد کند. این رویکرد نیز محدودیت‌های خاص خود را دارد، اما از منظر آموزشی نشان می‌دهد که یک شبکه می‌تواند به جای فرض حذف کامل MEV، درباره نحوه سازمان‌دهی رقابت بر سر آن تصمیم‌گیری کند.

بازارهای مالی سنتی؛ مسئله اولویت پیش از ظهور بلاکچین

رقابت بر سر اولویت بسیار قدیمی‌تر از فناوری بلاکچین است و بازارهای مالی سنتی نمونه روشنی از این موضوع ارائه می‌کنند. معامله‌گران حرفه‌ای مدت‌هاست که به سرعت دریافت اطلاعات، زمان ارسال سفارش و فاصله زیرساخت معاملاتی خود تا موتورهای تطبیق سفارش توجه می‌کنند. حتی تفاوت‌های زمانی بسیار کوچک می‌توانند در برخی استراتژی‌های معاملاتی اهمیت داشته باشند و همین مسئله باعث شکل‌گیری حوزه‌هایی مانند معاملات با فرکانس بالا و سرمایه‌گذاری گسترده در زیرساخت‌های کم‌تأخیر شده است.مفاهیمی مانند Colocation نمونه خوبی از ارزش اقتصادی سرعت هستند. در این مدل، برخی فعالان بازار تلاش می‌کنند زیرساخت پردازشی خود را از نظر فیزیکی به سیستم‌های معاملاتی نزدیک کنند تا زمان انتقال داده کاهش پیدا کند. این مسئله نشان می‌دهد که حتی بدون بلاکچین و مم‌پول نیز ترتیب و سرعت می‌توانند ارزشمند باشند. اگر چند سفارش برای یک فرصت محدود رقابت کنند، سیستمی باید تعیین کند کدام سفارش ابتدا پردازش شود و همین تصمیم می‌تواند بر نتیجه اقتصادی اثر بگذارد.در بازارهای سنتی همچنین سازوکارهایی مانند Payment for Order Flow یا PFOF، استخرهای تاریک یا Dark Pools و مدل‌های مختلف مسیریابی سفارش وجود دارند. این سازوکارها را نباید مستقیماً معادل MEV در بلاکچین دانست، زیرا ساختار فنی و حقوقی متفاوتی دارند، اما مطالعه آن‌ها برای فهم ارزش جریان سفارش و اولویت مفید است. تجربه بازارهای سنتی نشان می‌دهد که اگر ارزش دسترسی سریع یا جریان سفارش در سطح اصلی بازار قیمت‌گذاری نشود، ممکن است بازارهای جانبی برای آن شکل بگیرند. بنابراین یکی از درس‌های مهم TradFi برای تحلیل MEV این است که حذف یک بازار آشکار برای اولویت الزاماً به معنای حذف تقاضا برای اولویت نیست.

زمانی که MEV از پروتکل به زیرساخت منتقل می‌شود

یکی از نتایج مهم تغییر معماری شبکه این است که رقابت می‌تواند از سطح پروتکل به سطح زیرساخت منتقل شود. فرض کنید شبکه‌ای امکان مشاهده عمومی تراکنش‌های در انتظار را حذف کرده و سفارش‌ها براساس زمان دریافت پردازش می‌شوند. در چنین شرایطی کاربران دیگر نمی‌توانند به روش سابق تراکنش‌های دیگران را مشاهده و براساس آن سفارش خود را تنظیم کنند، اما زمان رسیدن درخواست آن‌ها به سیستم اهمیت بیشتری پیدا می‌کند. در نتیجه، زیرساخت ارتباطی سریع‌تر، سرور مناسب‌تر، مسیر شبکه کوتاه‌تر یا نرم‌افزار بهینه‌تر می‌تواند به عامل رقابتی تبدیل شود.از منظر اقتصادی، این وضعیت اهمیت زیادی دارد، زیرا هزینه رقابت همچنان وجود دارد اما مقصد آن تغییر کرده است. در یک بازار مبتنی بر حراج، کاربران ممکن است مستقیماً برای اولویت هزینه پرداخت کنند. در یک سیستم مبتنی بر latency، همان رقابت می‌تواند به هزینه برای سخت‌افزار، ارتباطات و زیرساخت منتقل شود. بنابراین هنگام ارزیابی یک معماری نباید فقط هزینه‌هایی را بررسی کرد که مستقیماً در پروتکل ثبت می‌شوند؛ هزینه‌های خارج از پروتکل نیز می‌توانند بخشی از اقتصاد واقعی ترتیب‌بندی باشند.همین موضوع یکی از دلایلی است که طراحی بازار MEV را پیچیده می‌کند. یک شبکه ممکن است با تغییر قواعد خود یک نوع رقابت را کاهش دهد، اما کاربران حرفه‌ای در صورت وجود ارزش اقتصادی می‌توانند مسیر دیگری برای کسب اولویت پیدا کنند. در نتیجه، مسئله اصلی طراحی این است که مشخص شود کدام شکل از رقابت برای سیستم قابل قبول‌تر، شفاف‌تر و قابل کنترل‌تر است.

Hyperliquid چگونه مسئله اولویت سفارش‌ها را مدیریت می‌کند؟

Hyperliquid نمونه دیگری برای بررسی این مسئله ارائه می‌دهد. در معماری‌هایی که مم‌پول عمومی مشابه اتریوم وجود ندارد، رقابت می‌تواند بیشتر حول سرعت دریافت داده و زمان رسیدن سفارش شکل بگیرد. دو کاربر ممکن است تقریباً در یک زمان یک وضعیت بازار را شناسایی کنند، اما درخواست یکی از آن‌ها زودتر به زیرساخت پردازش برسد. در چنین شرایطی latency به بخشی از فرآیند تعیین اولویت تبدیل می‌شود و همین موضوع نشان می‌دهد که حذف مم‌پول عمومی الزاماً تمام اشکال ارزش ترتیب‌بندی را حذف نمی‌کند.در Hyperliquid مکانیزم Priority Fee برای مدیریت بخشی از اولویت سفارش‌ها تعریف شده است. از منظر بحث MEV، اهمیت این سازوکار به ارزش بازار دارایی مورد استفاده یا عملکرد معاملاتی آن ارتباطی ندارد؛ موضوع اصلی این است که بخشی از ارزش اولویت به‌صورت مستقیم در قواعد پروتکل تعریف می‌شود. به جای آنکه تمام رقابت صرفاً از طریق زیرساخت فنی و کاهش latency انجام شود، کاربر در شرایط مشخص می‌تواند برای اولویت پردازش هزینه تعریف‌شده‌ای پرداخت کند. این موضوع بخشی از رقابت بر سر اولویت را از یک عامل کاملاً زیرساختی به یک متغیر قابل مشاهده در سطح پروتکل تبدیل می‌کند.هزینه‌های Priority در این مدل با HYPE پرداخت و براساس قواعد تعیین‌شده سوزانده می‌شوند. از منظر آموزشی، نکته مهم خود HYPE یا ارزش اقتصادی آن نیست؛ مسئله این است که پروتکل تصمیم گرفته ارزش پرداخت‌شده برای بخشی از اولویت را مستقیماً به اپراتور خاصی منتقل نکند و مکانیزم دیگری برای آن در نظر بگیرد. این نمونه نشان می‌دهد که «سرنوشت ارزش ترتیب‌بندی» خود یکی از تصمیمات مهم طراحی پروتکل است. شبکه‌های دیگر ممکن است همین ارزش را به Validator، Builder، Sequencer، خزانه پروتکل یا سایر بازیگران منتقل کنند.

البته وجود Priority Fee به معنای حذف کامل مزیت‌های زیرساختی نیست. کیفیت ارتباط، موقعیت زیرساخت و زمان انتقال اطلاعات همچنان می‌توانند در سیستم‌های معاملاتی سریع اهمیت داشته باشند. بنابراین Hyperliquid را نیز نباید نمونه‌ای از «حذف MEV» دانست. این معماری بیشتر نمونه‌ای برای بررسی نحوه قیمت‌گذاری و مدیریت صریح بخشی از اولویت است و به همین دلیل مقایسه آن با مدل اتریوم یا بازارهای سنتی می‌تواند تفاوت میان رویکردهای مختلف مدیریت ارزش ترتیب‌بندی را روشن‌تر کند.

آیا سوزاندن Priority Fee باعث حذف MEV می‌شود؟

سوزاندن هزینه اولویت به معنای حذف MEV نیست، زیرا منشأ MEV در اینجا خود هزینه نیست؛ منشأ اصلی، تفاوت نتیجه ناشی از ترتیب اجراست. اگر زودتر پردازش شدن همچنان اهمیت داشته باشد، ارزش اولویت نیز وجود دارد. سوزاندن فقط مشخص می‌کند هزینه‌ای که برای بخشی از این اولویت پرداخت شده است چه سرنوشتی پیدا می‌کند. این تمایز برای درک طراحی مکانیزم اهمیت زیادی دارد.فرض کنید پروتکلی اجازه دهد کاربران برای اولویت هزینه پرداخت کنند. طراح پروتکل باید تصمیم بگیرد این هزینه به کجا منتقل شود. می‌توان آن را به تولیدکننده بلاک، Sequencer، اعتبارسنج یا خزانه شبکه اختصاص داد یا براساس قواعد دیگری مدیریت کرد. هرکدام از این انتخاب‌ها مجموعه متفاوتی از انگیزه‌ها ایجاد می‌کنند. برای مثال، اگر یک اپراتور مستقیماً از فروش اولویت درآمد کسب کند، رابطه اقتصادی میان اپراتور و کاربران متفاوت از سیستمی خواهد بود که این هزینه را از گردش خارج می‌کند. بنابراین بررسی MEV بدون بررسی مقصد ارزش استخراج‌شده ناقص خواهد بود.این مسئله یکی از محورهای اصلی مقایسه معماری‌های مختلف است. صرف وجود یک بازار برای اولویت نه خوب است و نه بد؛ باید بررسی شود این بازار چگونه طراحی شده، چه کسانی امکان مشارکت در آن را دارند، آیا قواعد آن برای همه یکسان است، چه میزان اطلاعات درباره آن در دسترس است و درآمد یا ارزش حاصل از آن به کدام بخش از سیستم منتقل می‌شود.

MEV مفید و MEV مخرب چه تفاوتی دارند؟

یکی از مهم‌ترین نکات آموزشی در بحث MEV این است که نباید تمام اشکال آن را در یک گروه قرار داد. برخی فعالیت‌ها نتیجه طبیعی وجود بازارهای مالی متعدد هستند. آربیتراژ نمونه مشخصی است؛ اگر یک دارایی در دو بازار شرایط متفاوتی داشته باشد، معامله آربیتراژ می‌تواند این اختلاف را کاهش دهد. در پروتکل‌های وام‌دهی نیز لیکوئیدیشن نقش مشخصی در مدیریت وثیقه و جلوگیری از ایجاد بدهی بدون پشتوانه کافی دارد. بنابراین رقابت برای اجرای برخی تراکنش‌ها بخشی از عملکرد طبیعی سیستم است.در مقابل، Sandwich Attack نمونه‌ای است که در آن ترتیب تراکنش‌ها می‌تواند مستقیماً علیه یک کاربر استفاده شود. در این روش، بازیگر دیگری تراکنش کاربر را مشاهده می‌کند و تراکنش‌هایی را قبل و بعد از آن قرار می‌دهد تا از تغییر وضعیت ایجادشده استفاده کند. چنین رفتاری نشان می‌دهد چرا شفافیت مم‌پول در کنار مزایای خود می‌تواند زمینه برخی استراتژی‌های مخرب را نیز فراهم کند.بنابراین هدف واقع‌بینانه‌تر برای طراحی شبکه این نیست که تمام ارزش مرتبط با ترتیب تراکنش‌ها را حذف کند. هدف می‌تواند کاهش MEV مخرب، جلوگیری از تمرکز بیش‌ازحد قدرت ترتیب‌بندی و ایجاد قواعد روشن برای فعالیت‌هایی باشد که برای عملکرد بازار ضروری هستند. این دیدگاه باعث می‌شود MEV به جای یک مشکل واحد، مجموعه‌ای از پدیده‌های اقتصادی متفاوت در نظر گرفته شود که هرکدام به راهکار متفاوتی نیاز دارند.

با این حال، رمزنگاری محتوا به‌تنهایی مسئله ترتیب را از بین نمی‌برد، زیرا سیستم در نهایت باید تعیین کند تراکنش‌های رمزگشایی‌شده با چه ترتیبی اجرا شوند. مدل‌های Batch Auction نیز تلاش می‌کنند وابستگی نتیجه به تفاوت‌های زمانی بسیار کوچک را کاهش دهند و تراکنش‌های یک بازه را به‌صورت گروهی پردازش کنند. PBS، Inclusion List و معماری‌های مبتنی بر Intent نیز هرکدام از زاویه متفاوتی به مسئله قدرت ساخت بلاک و ترتیب اجرا می‌پردازند.در نتیجه، مسیر تحقیقات MEV احتمالاً بیش از آنکه بر یافتن یک راهکار واحد برای «نابودی MEV» متمرکز باشد، به سمت مهندسی بهتر بازار ترتیب‌بندی حرکت خواهد کرد. هر معماری باید مشخص کند چه اطلاعاتی پیش از اجرا قابل مشاهده است، چه کسی اختیار ترتیب‌بندی دارد، کاربران چگونه می‌توانند برای منابع محدود رقابت کنند و ارزش حاصل از این فرآیند چگونه توزیع می‌شود. این تصمیم‌ها فقط مسائل فنی نیستند و مستقیماً ساختار اقتصادی شبکه را شکل می‌دهند.

کلام آخر

MEV را نمی‌توان صرفاً یک مشکل مربوط به ماینرها یا ویژگی مخصوص شبکه اتریوم دانست. هر سیستم مالی که در آن چند درخواست برای دسترسی به منابع محدود رقابت کنند و ترتیب اجرای این درخواست‌ها بتواند نتیجه را تغییر دهد، بالقوه با نوعی ارزش ترتیب‌بندی مواجه است. بلاکچین این مسئله را ایجاد نکرده است؛ بلکه در بسیاری از موارد آن را قابل مشاهده‌تر، قابل اندازه‌گیری‌تر و قابل برنامه‌ریزی کرده است. تجربه بازارهای مالی سنتی نیز نشان می‌دهد که رقابت برای سرعت و اولویت مدت‌ها پیش از ظهور بلاکچین وجود داشته و می‌تواند در قالب‌های مختلف ظاهر شود.از همین منظر، «پایستگی MEV» را می‌توان یک چارچوب آموزشی برای تحلیل شبکه‌ها دانست. این مفهوم به معنای ثابت بودن مقدار MEV یا غیرممکن بودن کاهش آن نیست. طراحی مناسب می‌تواند برخی انواع MEV را محدود کند، مشاهده تراکنش‌ها را کاهش دهد، شرایط Sandwich Attack را دشوارتر کند یا رقابت بر سر ساخت بلاک را سازمان‌دهی کند. با این حال، تا زمانی که ترتیب اجرا بر نتیجه اقتصادی اثر داشته باشد، ارزش اولویت نیز می‌تواند در بخشی از سیستم باقی بماند و شکل متفاوتی به خود بگیرد.اتریوم بخشی از این مسئله را از طریق بازار ساخت بلاک و تفکیک نقش Builder و Proposer مدیریت می‌کند. معماری‌های دارای مجوز مانند Canton تلاش می‌کنند انتشار اطلاعات را محدود کنند و ترتیب پیام‌ها را در ساختاری متفاوت مدیریت کنند. بازارهای مالی سنتی نشان می‌دهند که latency و دسترسی به جریان سفارش حتی بدون بلاکچین نیز می‌توانند ارزشمند باشند. Hyperliquid نیز نمونه‌ای از مدلی است که بخشی از اولویت سفارش را مستقیماً در قواعد پروتکل تعریف می‌کند. هیچ‌کدام از این مدل‌ها به‌تنهایی پاسخ نهایی مسئله MEV نیستند؛ بلکه هرکدام نشان‌دهنده یک روش متفاوت برای مواجهه با مسئله‌ای مشترک هستند.

بنابراین برای ارزیابی MEV بهتر است به جای پرسیدن اینکه «کدام شبکه MEV را حذف کرده است؟» سؤال دقیق‌تری مطرح کنیم: قدرت ترتیب‌بندی در اختیار چه کسی قرار دارد، این قدرت چگونه کنترل می‌شود، رقابت برای اولویت چگونه شکل می‌گیرد و ارزش ایجادشده در نهایت به کدام بخش از سیستم منتقل می‌شود؟ پاسخ به این پرسش‌ها تصویر روشن‌تری از ساختار واقعی یک شبکه ارائه می‌دهد و نشان می‌دهد که MEV بیش از آنکه فقط یک مفهوم فنی باشد، مسئله‌ای درباره طراحی بازار، شفافیت و توزیع قدرت در زیرساخت‌های مالی دیجیتال است.