MEV की शारीरिक रचना: sandwich, frontrunning और mempool का काला जंगल

जब आप किसी decentralized exchange पर एक swap को sign करते हैं और उसे किसी public RPC endpoint पर broadcast करते हैं, तो आपने किसी matching engine को कोई निजी निर्देश नहीं भेजा है। आपने एक global bulletin board पर एक signed, executable इरादे का बयान प्रकाशित किया है, और उसके साथ एक इनाम — gas price — जोड़ दिया है, जो भी उसे execute करने पर राजी हो। हर कोई उस बयान को पढ़ सकता है। किसी पर भी उसे निष्पक्ष रूप से, क्रम में, या बिल्कुल भी execute करने की बाध्यता नहीं है। अन्य transactions के मुकाबले वह जिस क्रम में block में उतरता है, वह आपके submission का कोई गुण नहीं है; यह एक तीसरे पक्ष द्वारा लिया गया निर्णय है, जो इसे आपके खिलाफ़ करके मुनाफ़ा कमाता है।

यही on-chain trading का असहज केंद्र है। Statistical Arbitrage and Pairs Trading in Crypto Markets में हमने प्रसंगवश उल्लेख किया था कि किसी CEX और DEX के बीच position को स्थानांतरित करने में "MEV risk" होता है, और उसे वहीं एक अधूरे शब्द के रूप में छोड़ दिया था। यह लेख उस कर्ज़ को चुकाता है। यह on-chain execution की अर्थव्यवस्था पर एक श्रृंखला का सामने का दरवाज़ा है, और इसका काम है शब्दावली को परिभाषित करना — mempool, bundle, backrun, sandwich, PBS — इतनी सटीकता से कि flash loans के साथ atomic arbitrage और quants के लिए Uniswap v3 concentrated liquidity पर आगे के हिस्से यह मान सकें कि आप इस मशीन को पहले से समझते हैं।

MEV — Maximal (या Maximum) Extractable Value — वह मुनाफ़ा है जिसे कोई पक्ष किसी block के भीतर transactions के inclusion, exclusion और ordering को चुनकर निकाल सकता है, जो मानक block reward और priority fees से परे होता है। यह कोई bug नहीं है; यह इस बात का संरचनात्मक परिणाम है कि permissionless blockchains transactions को किस तरह क्रमबद्ध करते हैं। जब से 2019 में इस तंत्र का औपचारिक रूप से वर्णन किया गया, संचित निकाली गई value अरबों डॉलर तक पहुँच चुकी है, और इसे पकड़ने व पुनर्वितरित करने के लिए एक पूरा उद्योग — searchers, builders, relays, block proposers — खड़ा हो गया है। यदि आप on-chain trade करते हैं, तो या तो आप यह कर चुका रहे हैं या फिर आपने इसे न चुकाने के लिए जानबूझकर कदम उठाए हैं।

1. Transaction का जीवनचक्र: आपका इरादा सार्वजनिक क्यों है

यह देखने के लिए कि value कहाँ रिसती है, किसी transaction को अपने wallet से लेकर एक finalized block तक पीछा करें।

Public mempool

जब आपका wallet किसी transaction को sign करता है और उसे किसी मानक node के RPC endpoint पर submit करता है, तो node उसे validate करता है (signature, nonce, पर्याप्त balance) और, यदि वह पास हो जाता है, तो उसे peer-to-peer network पर अन्य nodes तक gossip कर देता है। हर node इन अभी-तक-शामिल-न-हुई transactions को एक स्थानीय buffer में रखता है जिसे mempool (memory pool) कहते हैं। एक-दो सेकंड के भीतर, network का व्यावहारिक रूप से हर node — जिनमें वे nodes भी शामिल हैं जिनका पूरा कारोबार ही pending transactions से value निकालना है — आपके signed, पूरी तरह decode किए गए transaction की एक प्रति रखता है।

"पूरी तरह decode" यहाँ भार-वहन करने वाला वाक्यांश है। आपका transaction कोई अपारदर्शी blob नहीं है। यह किसी ज्ञात contract को एक ABI-encoded call है। mempool को देखने वाला कोई भी व्यक्ति इसे decode कर सकता है और साफ़ शब्दों में पढ़ सकता है: यह address Uniswap v2 WETH/USDC pool पर 40 ETH को USDC के बदले swap करने वाला है, और यह कम से कम 96,000 USDC स्वीकार करेगा। वह आख़िरी वाक्यांश — न्यूनतम स्वीकार्य output — आपकी slippage tolerance है, और यह कोई संकेत नहीं है। यह एक कठोर parameter है जो calldata में compile किया गया है। हम जल्द ही देखेंगे कि यह हमलावर की budget line भी है।

mempool को कभी-कभी dark forest कहा जाता है, यह नाम Dan Robinson और Georgios Konstantopoulos के 2020 के एक निबंध से आया, जिन्होंने Liu Cixin की रूपक-कल्पना उधार ली थी: एक ऐसा स्थान जहाँ कोई भी दृश्यमान इकाई तुरंत उन शिकारियों द्वारा शिकार बना ली जाती है जिन्हें आप देख नहीं सकते। किसी भोले, मुनाफ़ेदार transaction को public mempool में broadcast कीजिए और शायद वह उस रूप में कभी block तक न पहुँचे जैसा आपने sign किया था — कोई bot उस अवसर को खा चुका होगा और आसपास के block को आपके खिलाफ़ फिर से गढ़ चुका होगा।

Priority queue के रूप में gas price

Ethereum का fee market (EIP-1559 के बाद) gas price को एक protocol base fee में बाँटता है, जिसे जला दिया जाता है, और एक priority fee ("tip") में, जो block proposer को जाती है। जब कोई block बनाया जाता है, तो builder आर्थिक रूप से उन transactions को शामिल करने के लिए प्रेरित होता है जो उसे सबसे अधिक भुगतान करती हैं। पहली अनुमानित तौर पर, mempool एक priority queue है जिसकी कुंजी tip है: जितनी ऊँची tip, उतनी जल्दी inclusion।

यही वह तंत्र है जो ordering को खरीदने योग्य बनाता है। यदि मैं आपका pending swap देखता हूँ और चाहता हूँ कि मेरा transaction ठीक आपसे पहले execute हो, तो मुझे कुछ भी hack करने की ज़रूरत नहीं है। मैं बस एक ऐसा transaction submit करता हूँ जो ऊँची tip देता है। builder, अपने प्रोत्साहन का पालन करते हुए, मेरे वाले को पहले रखता है। ordering कोई निष्पक्षता की गारंटी नहीं है जो protocol प्रदान करता है; यह एक नीलामी है जिसे protocol चलाता है, और जो लॉट नीलाम हो रहा है वह है आपके pending transaction में मौजूद जानकारी पर कार्य करने का अधिकार।

दो तथ्य मिलकर पूरी MEV समस्या बना देते हैं:

1. Pending transactions दृश्यमान हैं (public mempool)।
2. उनकी ordering बिक्री के लिए है (tip-priority नीलामी)।

नीचे जो कुछ भी है, वह एक उपसिद्धांत है।

2. Sandwich का यांत्रिकी, असली गणित के साथ

sandwich किसी swapper के खिलाफ़ प्रामाणिक विषैली MEV रणनीति है, और इस गणित को पीस-पीस कर देखना सार्थक है क्योंकि आँकड़े यह समझाते हैं कि क्यों आपकी slippage setting आपके नियंत्रण में मौजूद अकेली सबसे महत्वपूर्ण रक्षात्मक parameter है।

Constant-product invariant

एक Uniswap v2 pool token X का reserve $x$ और token Y का reserve $y$ रखता है, और हर trade के बाद invariant को लागू करता है

$x \cdot y = k$

(फ़िलहाल fees को नज़रअंदाज़ करते हुए)। यदि कोई trader token X का $\Delta x$ pool में बेचता है, तो नया X reserve $x + \Delta x$ हो जाता है, और $k$ को बनाए रखने के लिए pool को यह देना पड़ता है

$\Delta y = y - \frac{k}{x + \Delta x} = \frac{y \, \Delta x}{x + \Delta x}.$

0.3% वाली Uniswap v2 fee के साथ, input को $\gamma = 0.997$ से scale किया जाता है:

$\Delta y = \frac{y \, \gamma \, \Delta x}{x + \gamma \, \Delta x}.$

मुख्य गुण: आप एक ही दिशा में जितना अधिक ख़रीदते हैं, आपकी marginal price उतनी ही ख़राब होती है। Price impact convex है। यही convexity ठीक वही चीज़ है जिसका हमलावर मुद्रीकरण करता है।

सेटअप

एक WETH/USDC pool लीजिए। आँकड़ों को साफ़ रखने के लिए, ऐसे reserves मान लीजिए जो ETH को लगभग 2,500 USDC पर रखते हैं:

• $x = 10{,}000$ WETH
• $y = 25{,}000{,}000$ USDC
• $k = 2.5 \times 10^{11}$

आप 40 WETH से USDC ख़रीदना चाहते हैं (pool में WETH की एक बिक्री)। उदाहरण के लिए fees को नज़रअंदाज़ करते हुए, एक खाली block में एक ईमानदार fill आपको देगा

$\Delta y = \frac{25{,}000{,}000 \cdot 40}{10{,}000 + 40} = \frac{1{,}000{,}000{,}000}{10{,}040} \approx 99{,}601 \text{ USDC}.$

आपके trade से पहले spot price $25{,}000{,}000 / 10{,}000 = 2{,}500$ USDC/WETH है, इसलिए pre-trade mid पर 40 WETH की "कीमत" 100,000 USDC है। आपको 99,601 मिलते हैं — यह ~399 USDC का अंतर आपका अपना price impact और fees है। अब मान लीजिए आपने 1% slippage tolerance सेट की। आपके transaction का amountOutMin है

$99{,}601 \times 0.99 \approx 98{,}605 \text{ USDC}.$

वह संख्या अब mempool में सार्वजनिक है। यह किसी भी पर्यवेक्षक को बताती है: यह व्यक्ति अपने 40 WETH के बदले कम से कम 98,605 USDC स्वीकार करेगा। एक साफ़ block में आपको जो मिलता (99,601) और आपकी सीमा (98,605) के बीच का अंतर — लगभग 996 USDC — वह गुंजाइश है जिसे आपने स्वेच्छा से उसके हवाले कर दिया है जो भी आपको front-run करता है। यही हमलावर की budget है।

हमला, कदम-दर-कदम

एक searcher तीन transactions बनाता है और उन्हें एक ही block के भीतर इस क्रम में डालने के लिए बाध्य करता है:

1. Front-run (हमलावर पहले ख़रीदता है)। हमलावर आपसे पहले अपने ही WETH को pool में बेचता है, जिससे USDC की price ऊपर (WETH नीचे) चली जाती है, ताकि जब आपका trade उतरे, तो आपको प्रति WETH कम USDC मिलें। हमलावर इसका आकार ऐसा तय करता है कि आपका transaction अब भी आपके amountOutMin को पार कर ले — यदि नहीं, तो आपका swap revert हो जाता है और sandwich करने के लिए कोई शिकार ही नहीं बचता। सर्वोत्तम front-run आकार वह सबसे बड़ा है जो आपको ठीक आपकी सीमा पर छोड़ दे।

मान लीजिए हमलावर अपने ही 40 WETH के साथ front-run करता है। Pool $x = 10{,}040$ पर चला जाता है, और invariant के अनुसार हमलावर को मिलता है

$\frac{25{,}000{,}000 \cdot 40}{10{,}040} \approx 99{,}601 \text{ USDC out},$

जिससे reserves $x = 10{,}040$ WETH, $y \approx 24{,}900{,}399$ USDC रह जाते हैं।

2. शिकार (आपका swap बिगड़े हुए pool में execute होता है)। आपके 40 WETH अब इन reserves के मुकाबले उतरते हैं:

$\Delta y = \frac{24{,}900{,}399 \cdot 40}{10{,}040 + 40} = \frac{996{,}015{,}960}{10{,}080} \approx 98{,}811 \text{ USDC}.$

बाधा को जाँचिए: 98,811 > 98,605, इसलिए आपका transaction revert नहीं होता — आपको fill मिल जाता है, बस बदतर। आपको 99,601 के बजाय 98,811 मिले जो आपको एक साफ़ block में मिलते। आप लगभग 790 USDC से हाथ धो बैठे हैं, और आपको पता ही नहीं कि यह हुआ; आपका swap "सफल" रहा। Pool अब $x = 10{,}080$ WETH, $y \approx 24{,}801{,}588$ USDC है।

3. Back-run (हमलावर वापस बेचता है)। हमलावर अब step 1 में ख़रीदे गए USDC को pool में वापस बेचता है — या समकक्ष रूप से अपने WETH को वापस ख़रीदता है — आपके trade द्वारा बनाई गई बढ़ी हुई price को समेटते हुए। अपने पास मौजूद ~99,601 USDC से WETH वापस ख़रीदते हुए:

$\Delta x = \frac{10{,}080 \cdot 99{,}601}{24{,}801{,}588 + 99{,}601} \approx \frac{1{,}004{,}010{,}080}{24{,}901{,}189} \approx 40.32 \text{ WETH}.$

हमलावर ने step 1 में 40 WETH ख़र्च किए और step 3 में 40.32 WETH वापस पाए — gas से पहले लगभग 0.32 WETH (~800 USDC) का मुनाफ़ा, जो लगभग पूरी तरह आपकी slippage budget से निकाला गया। अपनी slippage को कस लीजिए और वह budget सिकुड़ जाती है; हमलावर का सर्वोत्तम front-run आकार गिर जाता है, और किसी सीमा से नीचे sandwich, gas के बाद, मुनाफ़ेदार रहना बंद कर देता है और searcher आपको छोड़ देता है।

सबक यह नहीं है कि "slippage tolerance बुरी है।" आपको कुछ tolerance चाहिए वरना आपके transactions सामान्य price movement पर ही revert हो जाएँगे। सबक यह है कि slippage tolerance एक सीधे निकाली जा सकने वाली मात्रा है, और इसे किसी आलसी default जैसे 1% पर, या इससे भी बदतर, किसी पतले pool पर "auto" पर सेट करना, उतने ही पैसे को किसी भी देखने वाले के लिए मेज़ पर छोड़ देने के बराबर है। किसी low-liquidity pool पर, जहाँ आपका अपना trade ही price को कई प्रतिशत हिला देता है, एक default slippage आपके notional का एक चौंकाने वाला हिस्सा सौंप सकती है।

एक searcher की profit शर्त का एक न्यूनतम रेखाचित्र:

def sandwich_profit(x, y, gamma, victim_dx, victim_min_out, attack_dx, gas_cost):
    out1 = (y * gamma * attack_dx) / (x + gamma * attack_dx)
    x1, y1 = x + attack_dx, y - out1
    vout = (y1 * gamma * victim_dx) / (x1 + gamma * victim_dx)
    if vout < victim_min_out:
        return None  # victim would revert; no sandwich
    x2, y2 = x1 + victim_dx, y1 - vout
    got_back = (x2 * gamma * out1) / (y2 + gamma * out1)
    return got_back - attack_dx - gas_cost  # profit in WETH

searcher attack_dx पर एक छोटा optimization चलाता है ताकि वह सबसे बड़ा front-run मिल सके जो vout >= victim_min_out बनाए रखे। वह optimum वहीं है जहाँ आपकी slippage सीमा बँधती है — जो यह कहने का एक और तरीक़ा है कि हमलावर की कमाई ठीक उतनी ही गुंजाइश से सीमित है जितनी आपने छोड़ी।

3. MEV का वर्गीकरण: विषैला बनाम सौम्य

"MEV" का इस्तेमाल एक गाली की तरह होता है, पर यह सब किसी शिकार से निष्कर्षण नहीं है। रणनीतियों को इस आधार पर छाँटना मददगार है कि ordering से किसी की स्थिति बदतर होती है या नहीं।

Frontrunning। किसी pending मुनाफ़ेदार transaction को देखें, उसे copy करें या उसके आगे निकल जाएँ, और पहले execute होने के लिए ऊँची tip दें। प्रतीक-रूप है किसी बड़े buy को देखना जो price हिला देगा, और उससे पहले ख़रीद लेना। पूरी तरह विषैला: शिकार को बदतर price मिलती है, या उसका अवसर सरासर चुरा लिया जाता है।

Backrunning। अपने transaction को किसी target transaction के ठीक बाद रखें ताकि उससे बनी state पर कार्य किया जा सके। महत्वपूर्ण रूप से, एक शुद्ध backrun target के execution को ख़राब नहीं करता — यह बाद में चलता है, इसलिए शिकार की price पहले ही लॉक हो चुकी होती है। यदि आपका बड़ा swap WETH/USDC pool को Binance के साथ बेमेल कर देता है, तो एक arbitrageur आपको backrun करके उसे फिर से संरेखित कर देता है और अंतर को जेब में डाल लेता है। आपको कोई नुक़सान नहीं होता; दरअसल यही arbitrage on-chain prices को व्यापक बाज़ार के साथ जोड़े रखता है। Backrunning इस spectrum का सौम्य छोर है, और — जैसा हम देखेंगे — आधुनिक MEV-protection systems ठीक इसीलिए बनाए गए हैं कि backrun का मुनाफ़ा उस user को वापस किया जाए जिसने उसे बनाया।

Sandwiching। एक ही शिकार के इर्द-गिर्द लिपटे एक frontrun और एक backrun, जैसा ऊपर विच्छेदित किया गया। रचना से ही विषैला: frontrun का अस्तित्व केवल इसलिए है कि शिकार का fill बदतर हो सके ताकि backrun उसे काट सके।

Atomic arbitrage। एक ही transaction जो किसी एक venue पर सस्ते में asset ख़रीदती है और दूसरे पर महँगे में बेचती है — मान लीजिए Uniswap पर WETH, Sushiswap की तुलना में सस्ता — एक risk-free मुनाफ़ा कमाते हुए, एक ही transaction के भीतर all-or-nothing (यदि अलाभकारी हो तो revert हो जाता है)। कोई विशिष्ट शिकार नहीं; यह उस price विसंगति को बंद कर रही है जिसे बाज़ार ने खुला छोड़ दिया था। आमतौर पर सौम्य माना जाता है — यह cross-venue price संगति को बेहतर बनाता है — और यह इस श्रृंखला के atomic arbitrage और flash loans हिस्से का विषय है, जहाँ flash loans का "कोई पूँजी आवश्यक नहीं" गुण इसे विशेष रूप से तीखा बना देता है।

Liquidations। जब कोई lending position (Aave, Compound, Maker) अपने collateral threshold से नीचे गिरती है, तो protocol उसे एक bonus देता है जो भी उस ख़राब क़र्ज़ को चुकाकर collateral को हथिया ले। Searchers वही liquidator बनने के लिए मुक़ाबला करते हैं। एक "शिकार" होता है — liquidate किया गया borrower — पर उसे तो protocol के नियमों के अनुसार वैसे भी liquidate किया जा रहा है; MEV मुक़ाबला ज़्यादातर यही तय करता है कि किसे bonus मिलेगा और, मुक़ाबले के ज़रिए, उसे सिकोड़ भी सकता है। बाज़ार की सेहत के लिए इसे तटस्थ-से-सौम्य कहें, borrower के लिए अप्रिय।

एक मोटा नक़्शा:

विषैला/सौम्य की रेखा इसलिए मायने रखती है क्योंकि पूरा आधुनिक MEV-न्यूनीकरण ढाँचा एक प्रयास है कि विषैली रणनीतियों को दबाया जाए जबकि सौम्य को संरक्षित — और पुनर्वितरित — किया जाए। आप ordering खेलों पर उस arbitrage को तोड़े बिना प्रतिबंध नहीं लगा सकते जो DEX prices को ईमानदार रखता है। तरकीब यह है कि विषैली value को उस व्यक्ति के पास वापस भेजा जाए जिससे वह छीनी गई थी।

4. एक संक्षिप्त इतिहास: gas नीलामियों से Flashbots तक

Flash Boys 2.0 और priority gas auctions

इस परिघटना को नाम दिया गया और मापा गया 2019 के पेपर "Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges" में, जिसके लेखक थे Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, और Ari Juels। पेपर ने "miner extractable value" शब्द प्रस्तुत किया (बाद में maximal extractable value के रूप में सामान्यीकृत, जैसे-जैसे उद्योग proof-of-work miners से proof-of-stake proposers की ओर बढ़ा) और priority gas auctions (PGAs) का दस्तावेज़ीकरण किया: bots वास्तविक समय में gas price पर एक-दूसरे को ऊपर चढ़ाते हुए, किसी मुनाफ़ेदार अवसर की ordering जीतने के लिए।

PGAs स्पष्ट रूप से रोगात्मक थे। चूँकि bots के पास एकमात्र लीवर public gas price थी, वे खुली बोली-युद्ध लड़ते थे — उन्हीं कुछ सेकंडों के भीतर बार-बार ऊँची और ऊँची tips के साथ फिर से submit करते हुए — किसी एक arbitrage या liquidation को हथियाने के लिए। दो भद्दे परिणाम निकले। पहला, इसने network को जाम कर दिया और सभी के लिए gas prices को फुला दिया, चाहे वे MEV-संबंधित हों या नहीं। दूसरा, और अधिक चिंताजनक, पेपर ने तर्क दिया कि यदि किसी block में उपलब्ध MEV, block reward से अधिक हो, तो तर्कसंगत miners को chain को पुनर्व्यवस्थित करके उसे चुराने के लिए प्रोत्साहन मिलेगा, जो consensus स्थिरता को ही ख़तरे में डालता है। MEV केवल एक user-निष्पक्षता समस्या नहीं थी; यह chain के लिए एक ख़तरा था।

प्रतिक्रिया के रूप में Flashbots

Flashbots 2020 में PGA को निष्प्रभावी करने के लिए शुरू हुआ। इसकी अंतर्दृष्टि: ordering नीलामी को public mempool से हटाकर एक sealed-bid, off-chain channel में ले जाना। किसी transaction को broadcast करके public gas युद्ध लड़ने के बजाय, एक searcher एक bundle जोड़ता है — transactions की एक क्रमबद्ध सूची जिसे atomically, all-or-nothing, एक विशिष्ट सापेक्ष क्रम में शामिल किया जाना है — और उसे एक बोली के साथ किसी block builder को निजी रूप से submit करता है (अक्सर gas price के बजाय proposer को सीधे स्थानांतरण के रूप में भुगतान)। builder अपने मिले सभी bundles और transactions से सबसे मूल्यवान block जो बना सकता है वह जोड़ता है और उसे proposer को प्रस्तुत करता है।

एक साथ दो चीज़ें बेहतर होती हैं। Searchers public mempool को असफल बोलियों से spam करना बंद कर देते हैं, इसलिए सामान्य users पर gas-price का बाहरी प्रभाव घट जाता है। और जीतने वाला bundle या तो पूरी तरह उतरता है या बिल्कुल नहीं, जिससे वे "असफल frontrun" transactions समाप्त हो जाते हैं जो पहले blocks को जाम कर देते थे। बोली-युद्ध अब भी होता है — बस यह on-chain सार्वजनिक चीख-पुकार के बजाय builder के भीतर एक निजी नीलामी के रूप में होता है।

PBS: proposer-builder separation

Flashbots का architecture proposer-builder separation (PBS) में सामान्यीकृत हुआ, जो आज Ethereum पर प्रमुख मॉडल है। भूमिकाएँ बँट जाती हैं:

• Searchers MEV अवसर ढूँढते हैं और उन्हें bundles में पैक करते हैं।
• Builders bundles और public transactions से एकल सबसे मूल्यवान पूर्ण block जोड़ने के लिए मुक़ाबला करते हैं।
• Relays builders और proposers के बीच बैठते हैं, builders से पूर्ण blocks प्राप्त करते हैं और proposer को केवल block headers तथा एक value बोली देते हैं, ताकि proposer किसी block की सामग्री देखने से पहले उसके प्रति प्रतिबद्ध हो जाए (proposer को MEV सीधे चुराने से रोकते हुए)।
• Proposers (validators) सबसे ऊँची बोली वाला header चुनते हैं, उसे sign करते हैं, और भुगतान वसूलते हैं।

यह protocol से बाहर MEV-Boost के ज़रिए लागू होता है, एक middleware जिसे Ethereum validators का भारी बहुमत चलाता है — लगभग 80–90% blocks external builders के ज़रिए MEV-Boost से बनाए जाते हैं। यह काम करता है, पर यह भरोसेमंद relays पर निर्भर है। अगला कदम, enshrined PBS (ePBS, EIP-7732), proposer-builder separation को सीधे Ethereum protocol में पकाने और भरोसेमंद-relay निर्भरता को हटाने का लक्ष्य रखता है। 2026 के मध्य तक यह Glamsterdam upgrade के लिए निर्धारित है, जिसका लक्ष्य 2026 में बाद में एक mainnet activation है, और समर्थक दावा करते हैं कि यह blocks के प्रतिबद्ध होने के तरीक़े को सुधारकर और विषैली reordering की खिड़की को सँकरा करके users के लिए MEV हानि को काफ़ी हद तक घटा सकता है। जब तक यह उतरे नहीं, सटीक आँकड़ों को आकांक्षात्मक समझिए, पर दिशा स्पष्ट है: protocol उस MEV आपूर्ति श्रृंखला को आत्मसात कर रहा है जिसके अस्तित्व से इनकार करने में उसने वर्षों बिताए।

MEV-Share: value वापस देना

सामान्य traders के लिए सबसे परिणामकारी विकास है MEV-Share, Flashbots की order-flow नीलामी। यह विचार dark forest को उलट देता है। आपका transaction हर शिकारी को दिखने के बजाय, आप उसे निजी रूप से एक MEV-Share node को भेजते हैं, जो उसके बारे में केवल आंशिक संकेत (आप तय करते हैं कि कितने) searchers को उजागर करता है। Searchers आपके transaction को backrun करने के लिए बोली लगाते हैं — याद रखें, एक backrun आपको नुक़सान नहीं पहुँचाता — और परिणामी मुनाफ़े का एक बड़ा हिस्सा आपको वापस कर दिया जाता है, बाक़ी searcher और proposer के बीच बँट जाता है ताकि bundle शामिल हो सके।

आर्थिक पुनर्रचना सुरुचिपूर्ण है। एक बड़ा swap एक backrun अवसर बनाता है; सवाल यह है कि उसे कौन पकड़ता है। dark-forest वाली दुनिया में, searchers और builders उसे पूरा ले लेते हैं। MEV-Share के तहत, आपके अपने transaction द्वारा बनाई गई value काफ़ी हद तक आपको वापस मिल जाती है। Flashbots का उपभोक्ता-मुखी RPC, Flashbots Protect, retail transactions को इस system के ज़रिए भेजता है, और 2025 में इसने उसके ऊपर gas-fee refunds जोड़े, जिससे users को वापस मिलने वाली राशि सार्थक रूप से बढ़ी। यह "सौम्य को पुनर्वितरित करो, विषैले को दबाओ" के सिद्धांत को मूर्त रूप में लाता है।

5. एक trader के लिए व्यावहारिक बचाव

शिकार बनना रोकने के लिए आपको searcher चलाने की ज़रूरत नहीं। प्रभाव के मोटे क्रम में:

slippage को जानबूझकर, प्रति pool सेट करें

Section 2 ने स्थापित किया कि आपकी slippage tolerance ही हमलावर की budget है। इससे दो नियम निकलते हैं। पहला, slippage को pool की वास्तविक liquidity और आपके trade के price impact के अनुसार आकार दें, न कि किसी आदतन 1% के अनुसार। किसी गहरे pool पर 0.1–0.3% tolerance पर्याप्त हो सकती है; किसी पतले पर, या तो स्वीकार करें कि आप आकार में सुरक्षित रूप से trade नहीं कर सकते या फिर छोटे टुकड़ों में बाँट दें। दूसरा, किसी low-liquidity जोड़ी पर कभी "auto"/"unlimited" slippage का इस्तेमाल न करें — यह एक signed blank check है। यदि कोई swap किसी कसी हुई tolerance पर बार-बार revert करता रहे, तो यह बाज़ार का आपको यह बताना है कि आपका trade pool के लिए बहुत बड़ा है, न कि सीमा को ढीला करने का संकेत।

किसी private RPC के ज़रिए route करें

सबसे साफ़ संरचनात्मक समाधान है अपने transaction को public mempool से पूरी तरह बाहर रखना। अपने wallet को किसी private RPC पर लगाएँ जो transactions को gossip करने के बजाय सीधे builders को अग्रेषित करता है:

• Flashbots Protect — आपके transaction को MEV-Share system में भेजता है, इसलिए यह frontrunners को कभी सार्वजनिक रूप से दिखता ही नहीं, और किसी भी backrun value का एक हिस्सा तथा gas refunds वापस करता है।
• MEV Blocker (CoW Protocol और अन्य द्वारा) — एक समान private-RPC सेवा जो frontrunning और sandwiching से बचाव करती है और backrun मुनाफ़ा users को वापस देती है, एक निःशुल्क-उपयोग वाले fee मॉडल के साथ।

चूँकि किसी sandwich के लिए हमलावर को आपका pending transaction देखना और उससे पहले एक frontrun डालना ज़रूरी है, आपके transaction को public mempool से हटाना frontrun अवसर को सीधे ख़त्म कर देता है। Backrun अवसर बना रहता है, पर अब वह चोरी होने के बजाय आपको वापस नीलाम किया जाता है। बदले में RPC operator पर थोड़ा भरोसा और, कभी-कभी, थोड़ा धीमा inclusion — जो आमतौर पर sandwich जोखिम को समाप्त करने के मुक़ाबले नगण्य है। (private-protection RPCs का 2025 का एक benchmark अध्ययन पाया कि उनका वास्तविक-दुनिया settlement हमेशा public submission से सख़्ती से बेहतर नहीं होता, इसलिए प्रभाव मज़बूत है पर सार्वभौमिक नहीं; अधिकांश retail-आकार के DEX swaps के लिए, private routing अब भी सही default है।)

batch-auction और intent-आधारित venues को प्राथमिकता दें

कुछ DEX डिज़ाइन रचना से ही ordering लाभ को हटा देते हैं। CoW Protocol trades को batch auctions में एक uniform clearing price के साथ settle करता है — किसी batch में हर trade एक ही price पर clear होता है, इसलिए शोषण करने के लिए कोई "पहला" और "आख़िरी" स्थान नहीं होता, और solvers आपके इर्द-गिर्द reorder करने के बजाय आपको सर्वोत्तम execution देने के लिए मुक़ाबला करते हैं। Intent-आधारित systems जहाँ आप जो चाहते हैं उसे sign करते हैं और solvers को execution ढूँढने देते हैं, न कि किसी विशिष्ट path को sign करते हैं, इसी तरह sandwich को उसका पैर जमाने से रोक देते हैं। यदि आप आकार में trade कर रहे हैं, तो ये venues किसी भी slippage फेरबदल से अधिक मूल्यवान हैं।

समझें कि L2 अलग क्यों हैं

आज के अधिकांश Ethereum rollups (Arbitrum, Optimism, Base) पर, blocks एक एकल sequencer द्वारा बनाए जाते हैं जिसे rollup टीम संचालित करती है। searchers के देखने के लिए pending transactions का कोई public mempool नहीं होता, और क्रम तय करने वाला एक भरोसेमंद पक्ष होता है। व्यवहार में अधिकांश sequencers transactions को first-come-first-served क्रमबद्ध करते हैं और अपने users के खिलाफ़ sandwich हमले नहीं चलाते, इसलिए इन chains पर protocol परत पर sandwiching बड़े पैमाने पर अनुपस्थित है।

पर बदले को सटीक पढ़ें: जिस कारण आप decentralized MEV निष्कर्षण से सुरक्षित हैं वह यह है कि आप एक केंद्रीकृत orderer पर भरोसा कर रहे हैं कि वह इसे नहीं निकालेगा। sequencer आपको front-run कर सकता है; वह बस (और प्रतिष्ठा से बँधा हुआ) ऐसा न करना चुनता है। यह एक अस्थायी संतुलन है। जैसे-जैसे rollups अपने sequencers को decentralize करते हैं — shared sequencers, based sequencing, L2 पर PBS-शैली की नीलामियाँ — वही mempool दृश्यता और ordering-बिक्री-के-लिए गतिकी फिर से उभर सकती है, और L2 MEV सवाल एक हल हो चुकी समस्या के बजाय एक खुली डिज़ाइन समस्या बन जाता है। यह न मानें कि "मैं L2 पर हूँ" का अर्थ अनिश्चित काल के लिए "MEV मुझे छू नहीं सकता" है; इसका अर्थ है "एक भरोसेमंद पक्ष ने, फ़िलहाल के लिए, ऐसा न करने का वादा किया है।"

बाक़ी श्रृंखला में क्या साथ ले जाएँ

विषय को उसके भार-वहन करने वाले तथ्यों तक छाँट लें:

1. एक public-mempool swap है सार्वजनिक इरादा और एक ख़रीदने योग्य ordering slot। वही संयोजन, न कि कोई एकल bug, पूरी समस्या है।
2. किसी constant-product AMM पर, आपकी slippage tolerance एक ऐसी मात्रा है जिसे हमलावर निकाल सकता है, और किसी sandwich की कमाई ठीक उतनी ही गुंजाइश से बँधी है जितनी आपने छोड़ी। slippage सेट करना एक सुरक्षा निर्णय है, कोई सुविधा टॉगल नहीं।
3. MEV एकाश्म नहीं है: frontruns और sandwiches विषैले हैं; backruns और atomic arbitrage सौम्य हैं और उपयोगी भी, क्योंकि वे on-chain prices को संगत रखते हैं। अच्छा न्यूनीकरण पहले वाले को दबाता है और बाद वाले को पुनर्वितरित करता है।
4. उद्योग की प्रतिक्रिया PGAs (public gas युद्ध, Flash Boys 2.0, 2019) से लेकर Flashbots / bundles / PBS (sealed निजी नीलामियाँ) से MEV-Share (backrun value user को वापस) और, अगला, protocol में enshrined PBS तक चली।
5. एक trader के रूप में, आपके बचाव हैं कसी हुई प्रति-pool slippage, private RPCs (Flashbots Protect, MEV Blocker), और batch-auction venues — और यह जागरूकता कि L2 सुरक्षा फ़िलहाल sequencer में एक भरोसे की धारणा है, कोई भौतिकी का नियम नहीं।

atomic arbitrage और flash loans हिस्सा इस मेज़ में searcher का पक्ष लेता है — सौम्य निष्कर्षण कैसे बनाया जाता है, उधार ली गई पूँजी और atomic reverts को सुरक्षा जाल के रूप में इस्तेमाल करते हुए। Uniswap v3 concentrated liquidity हिस्सा ऊपर के constant-product गणित पर फिर से जाता है और दिखाता है कि concentrated liquidity price-impact curve को — और इसलिए sandwich budget को — कैसे फिर से गढ़ती है, जो हमने यहाँ व्युत्पन्न किया। mempool एक काला जंगल है। अब आप जानते हैं कि उसमें क्या शिकार कर रहा है।

संदर्भ

• Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach, Juels (2019), Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. arXiv:1904.05234.
• Robinson & Konstantopoulos (2020), Ethereum is a Dark Forest.
• Flashbots documentation: MEV-Boost, MEV-Share, Flashbots Protect, MEV refunds (docs.flashbots.net).
• Ethereum PBS / EIP-7732 (enshrined proposer-builder separation), Glamsterdam upgrade materials.
• MEV Blocker (mevblocker.io); CoW Protocol batch-auction design.
• Private MEV Protection RPCs: A Benchmark Study (arXiv:2505.19708, 2025).