Uniswap v4 के Hook के माध्यम से प्रोग्रामेबल लिक्विडिटी को सक्षम किया गया है, लेकिन अधिकार कोडिंग, एक्सेस कंट्रोल आदि दोषों के कारण यह हमलों का प्रमुख केंद्र बन गया है; Async Hook और अकाउंटिंग लॉजिक के गलत उपयोग के जोखिम के प्रति सावधान रहें।

लेखक, स्रोत: Beosin

Uniswap v4 के मुख्य नेटवर्क पर लॉन्च के बाद, Hook मैकेनिज्म DeFi का सबसे अधिक चर्चित नवाचार बन गया है। Base चेन पर memecoin लॉन्च प्लेटफॉर्म Flaunch Hook का उपयोग स्थिर प्री-सेल कीमत और स्वचालित क्लीयरेंस लॉन्च मैकेनिज्म को सक्षम करने के लिए करता है; लिक्विडिटी प्रोटोकॉल Bunni v2 Hook का उपयोग प्रोग्रामेबल लिक्विडिटी और पुनर्प्रतिभूति मॉडल बनाने के लिए करता है; इस साल SATO, uPEG (Unipeg), Slonks जैसे Hook-आधारित टोकन्स ने कुछ ही समय में दहाई गुना की वृद्धि की है।

हुक इकोसिस्टम की समृद्धि के दूसरे पहलू में, हुक के लागू करने की त्रुटियों का उपयोग करके हमले में उल्लेखनीय वृद्धि हुई है। इस लेख में, हम Uniswap v4 के हुक मैकेनिज़म से शुरू करते हुए, इसके कोर कॉल स्टैक का विश्लेषण करेंगे, ताकि प्रोजेक्ट टीमें इसमें संभावित दुर्बलताओं को समझ सकें।

Uniswap v4 हुक सुरक्षित

Uniswap v4 में v3 की तुलना में सबसे महत्वपूर्ण आर्किटेक्चरल परिवर्तन Hook (हुक) मैकेनिज्म का परिचय है: जो डेवलपर्स को लिक्विडिटी पूल के लाइफसाइकिल इवेंट्स पर कस्टम कॉन्ट्रैक्ट्स माउंट करने की अनुमति देता है, और swap, लिक्विडिटी जोड़ना/घटाना, इनिशियलाइज़ेशन जैसे बिंदुओं पर कोई भी लॉजिक इंजेक्ट कर सकता है।

v4 के कुछ प्रमुख परिवर्तन निम्नलिखित हैं:

- सिंगलटन पैटर्न: सभी पूल की स्थिति को एकल PoolManager कॉन्ट्रैक्ट द्वारा केंद्रीय रूप से प्रबंधित किया जाता है, प्रत्येक पूल के लिए अलग-अलग कॉन्ट्रैक्ट तैनात नहीं किए जाते हैं

- फ्लैश अकाउंटिंग: लेनदेन के दौरान मध्यवर्ती शेष बदलाव केवल अस्थायी स्टोरेज में दर्ज किए जाते हैं और केवल लेनदेन के अंत में एक साथ सेटल किए जाते हैं

- हुक तंत्र: प्रत्येक पूल एक हुक कॉन्ट्रैक्ट से बंधा जा सकता है, जिसे PoolManager कीव पॉइंट्स (beforeInitialize, beforeSwap, afterAddLiquidity आदि) पर कॉलबैक किया जाएगा।

- हुक अपरिवर्तनीय है: एक बार पूल इनिशियलाइज़ हो जाने के बाद, बाइंड किया गया हुक पता स्थायी रूप से निर्धारित हो जाता है (पूल से बाइंड किया गया हुक पता बदला नहीं जा सकता, लेकिन हुक कॉन्ट्रैक्ट की अपग्रेड करने की क्षमता इसके लागू होने पर निर्भर करती है)

v3 अवधि में, डेवलपर्स को केवल Uniswap प्रोटोकॉल पर भरोसा करना था; जबकि v4 अवधि में, प्रत्येक पूल की सुरक्षा उससे बंधे Hook पर निर्भर करती है। Hook ने AMM को एक स्थिर वित्तीय प्राइमिटिव से एक प्रोग्रामेबल वित्तीय बुनियादी ढांचे में विस्तारित कर दिया है, लेकिन सुरक्षा मॉडल भी “प्रोटोकॉल-स्तरीय” से “पूल-स्तरीय” तक टुकड़े-टुकड़े हो गया है।

2. हुक आर्किटेक्चर 2.1 पूलमैनेजर और अनलॉक/कॉलबैक मॉडल

v4 का कोर कॉन्ट्रैक्ट एकल-उदाहरण PoolManager है। किसी भी पूल की स्थिति में परिवर्तन (swap, लिक्विडिटी जोड़ना/घटाना) के लिए पहले PoolManager.unlock() को कॉल करना आवश्यक है, जिससे एक-बार के कॉलबैक अधिकार को प्राप्त किया जा सके, और फिर unlockCallback() में विशिष्ट कार्रवाई पूरी की जाए। पूरी प्रक्रिया समाप्त होने पर, PoolManager जाँच करता है कि लेखा संतुलित है या नहीं:

जब NonzeroDeltaCount != 0 हो, तो सीधे revert कर दें, यह v4 flash accounting का मुख्य प्रतिबंध है। कोई भी Hook निष्पादन के दौरान असंतुलित खाते को अस्थायी रूप से बना सकता है, लेकिन लेनदेन के अंत से पहले इसे स्वयं settle करना होगा, अन्यथा पूरा लेनदेन रद्द हो जाएगा।

प्रत्येक पूल PoolKey संरचना द्वारा अद्वितीय रूप से पहचाना जाता है, जिसमें hooks क्षेत्र शामिल है:

PoolId keccak256(PoolKey) द्वारा गणना किया जाता है, इसलिए अलग-अलग hooks पते अलग-अलग पूल उत्पन्न करते हैं। इसका अर्थ यह भी है कि PoolManager कोई जांच नहीं करता कि किसी Hook पते का पहले किसी अन्य पूल के लिए उपयोग किया गया था या नहीं, एक ही Hook स्मार्ट कॉन्ट्रैक्ट को एक से अधिक पूल द्वारा साथ में बांधा जा सकता है।

2.2 हुक अधिकार बिट कोडिंग पते में

v4 का एक अनपेक्षित डिज़ाइन यह है: हुक के अधिकार को कॉन्ट्रैक्ट के अंदर किसी चर द्वारा निर्धारित नहीं किया जाता है, बल्कि हुक कॉन्ट्रैक्ट के डिप्लॉयमेंट पते द्वारा निर्धारित किया जाता है।

PoolManager, Hook पते के निचले 14 बिट्स की जांच करके यह निर्धारित करता है कि क्या किसी जीवनचक्र बिंदु पर इस Hook को कॉल किया जाना चाहिए:

उदाहरण के लिए, BEFORE_SWAP_FLAG = 1 << 7। यदि Hook पते का 7वां बिट 1 है, तो PoolManager swap से पहले इस Hook की beforeSwap() को कॉल करेगा; अन्यथा, भले ही Hook कॉन्ट्रैक्ट ने beforeSwap() को लागू किया हो, PoolManager इसे कभी नहीं कॉल करेगा।

इसका अर्थ है कि Hook के डिप्लॉय करते समय CREATE2 + salt का उपयोग करके पता की गणना की जानी चाहिए, ताकि एक ऐसा पता बनाया जा सके जिसके निम्न बिट्स लक्ष्य अधिकारों के पूर्ण रूप से संगत हों। Uniswap ने इस उद्देश्य के लिए HookMiner उपकरण प्रदान किया है:

जब अनुमति बिट्स और फ़ंक्शन कार्यान्वयन असंगत होते हैं, तो दो प्रकार की समस्याएँ उत्पन्न होती हैं:

(1) किसी hook फ़ंक्शन को लागू किया गया है, लेकिन पते को संबंधित अनुमति बिट्स के लिए एन्कोड नहीं किया गया है — PoolManager कभी भी इस फ़ंक्शन को नहीं बुलाएगा, तार्किक रूप से अनावश्यक है

(2) पता में किसी अधिकार बिट को कोड किया गया है, लेकिन hook ने संबंधित फ़ंक्शन को लागू नहीं किया है—PoolManager कॉलबैक के दौरान revert हो सकता है, जिससे DOS हो सकता है या रिटर्न वैल्यू की जांच विफल हो सकती है, जिसके कारण संबंधित ऑपरेशन नहीं निष्पादित हो सकते।

यह एक साथ हुक अपग्रेड की प्राकृतिक बाधा भी है: यदि हुक को प्रॉक्सी के माध्यम से अपग्रेड किया जा सकता है, तो डिप्लॉयमेंट एड्रेस अपग्रेड के दौरान अपरिवर्तित रहता है, इसलिए अपग्रेड के बाद केवल मौजूदा हुक फ़ंक्शन के कार्यान्वयन को ही संशोधित किया जा सकता है, न कि नए हुक प्रकार जोड़े जा सकते हैं। भविष्य के विस्तार की क्षमता को सुरक्षित रखने के लिए, प्रारंभिक डिप्लॉयमेंट के समय सभी संभावित अधिकार बिट्स को पहले से ही आवंटित करना आवश्यक है।

2.3 BaseHook और एक आम तौर पर नजरअंदाज किए जाने वाले एक्सेस कंट्रोल जाल

Uniswap v4 पेरिफरी द्वारा प्रदान किया गया BaseHook अमूर्त स्मार्ट कॉन्ट्रैक्ट, जिसे डेवलपर्स अपने स्वयं के Hook को लागू करने के लिए विरासत में ले सकते हैं। BaseHook का एक महत्वपूर्ण कार्य unlockCallback() फ़ंक्शन के लिए onlyPoolManager मॉडिफायर प्रदान करना है:

लेकिन—यहाँ एक ऐसा डिज़ाइन जाल है जिसे अक्सर नज़रअंदाज़ किया जाता है—प्रारंभिक संस्करण BaseHook ने केवल unlockCallback के लिए onlyPoolManager जोड़ा, अन्य hook कॉलबैक (beforeSwap, afterSwap, beforeAddLiquidity आदि) के लिए कोई सुरक्षा नहीं। इन कार्यों के एक्सेस नियंत्रण को Hook विकासक को स्वयं स्पष्ट रूप से जोड़ना होगा।

एक exact-input swap के उदाहरण के साथ, नीचे उपयोगकर्ता द्वारा लेनदेन शुरू करने से लेकर निपटान तक की पूरी कॉल स्टैक का विश्लेषण किया गया है।

3.1 पूल इनिशियलाइजेशन और हुक बाइंडिंग

कोई भी PoolManager.initialize() को कॉल करके नया पूल बना सकता है:

isValidHookAddress केवल पते के अधिकार बिट और शुल्क क्षेत्र की संगतता की जांच करता है, यह यह नहीं जांचता कि Hook पहले से किसी अन्य पूल में उपयोग किया जा रहा है या नहीं, और न ही यह जांचता है कि Hook इस PoolKey को स्वीकार करने के लिए तैयार है या नहीं। यदि Hook के डिज़ाइन में beforeInitialize में सफेद सूची या एकल पूल बाइंडिंग तर्क शामिल नहीं किया गया है, तो कोई भी व्यक्ति समान Hook का उपयोग करते हुए, लेकिन token pair के साथ कोई भी नया पूल बना सकता है और Hook के सभी बाद के कॉलबैक्स को ट्रिगर कर सकता है।

3.2 beforeSwap और BeforeSwapDelta

स्वैप प्रक्रिया का प्रवेश बिंदु PoolManager.swap() है, जो मूल स्वैप तर्क को निष्पादित करने से पहले Hooks.beforeSwap() को कॉल करता है:

beforeSwap का रिटर्न मान एक ट्रिपल (bytes4, BeforeSwapDelta, uint24) है:

- bytes4: IHooks.beforeSwap.selector के बराबर होना चाहिए, अन्यथा PoolManager सीधे revert कर देगा

- BeforeSwapDelta: हुक द्वारा इस swap में निर्दिष्ट टोकन और अनिर्दिष्ट टोकन के लिए डेल्टा समायोजन

- uint24: डायनामिक LP शुल्क दर कवर मान (केवल तभी लागू होता है जब पूल में डायनामिक शुल्क सक्षम हो)

BeforeSwapDelta एक int256 का बाइन्डिंग है, जिसके उच्च 128 बिट specified token के डेल्टा (अर्थात् उपयोगकर्ता द्वारा निर्दिष्ट मात्रा वाला token) के लिए होते हैं, और निम्न 128 बिट unspecified token के डेल्टा के लिए होते हैं:

ध्यान दें, BeforeSwapDelta का अर्थ है कि Hook द्वारा शुल्क वसूले जाने पर धनात्मक मान लौटाया जाना चाहिए और Hook द्वारा टोकन वापस दिए जाने पर ऋणात्मक मान लौटाया जाना चाहिए। डेवलपर्स आसानी से संकेत उल्टा कर देते हैं; साथ ही, specified और unspecified का संगतन params.zeroForOne और amountSpecified के चिह्न पर निर्भर करता है, जिसका सही तरीके से लिखना न होने पर token का गलत स्थान हो सकता है।

PoolManager द्वारा beforeSwap द्वारा लौटाए गए specifiedDelta को amountToSwap पर सीधे जोड़ दिया जाता है:

इस पंक्ति में एक महत्वपूर्ण अर्थ निहित है: Hook swap राशि को रोक सकता है। जब hookDeltaSpecified, -params.amountSpecified के बराबर होता है, तो amountToSwap सीधे शून्य हो जाता है, जिससे Hook पूरी तरह से इस swap को नियंत्रित कर लेता है—इसे Async Hook या Custom Curve Hook कहा जाता है।

Async Hook v4 में सबसे अधिक जोखिम वाला डिजाइन पैटर्न है: यह मूल रूप से Uniswap के swap लॉजिक को Hook के अपने लॉजिक से बदल देता है। यदि Hook में कोई दरार है या यह स्वयं ही दुष्ट है, तो उपयोगकर्ता की राशि Uniswap के मूल मूल्य निर्धारण लॉजिक से अब बंधी नहीं होगी, बल्कि मुख्य रूप से Hook के स्वयं के कार्यान्वयन की सही प्रक्रिया पर निर्भर करेगी।

3.3 डेल्टा सेटलमेंट और NonzeroDeltaCount

beforeSwap और afterSwap द्वारा लौटाया गया डेल्टा तुरंत ट्रांसफर को ट्रिगर नहीं करता, बल्कि PoolManager के आंतरिक लेज़र में रिकॉर्ड किया जाता है:

जब किसी टोकन की संचयी डेल्टा शून्य से गैर-शून्य हो जाती है, तो NonzeroDeltaCount बढ़ जाता है; जब यह फिर से शून्य हो जाता है, तो यह घट जाता है। जैसा कि 2.1 में बताया गया है, unlock() के समाप्त होने पर यदि NonzeroDeltaCount != 0 है, तो पूरी लेनदेन revert हो जाती है।

Hook, settle() (PoolManager को ट्रांसफर करके) और take() (PoolManager से निकालकर) के माध्यम से अपना डेल्टा संतुलित करता है:

इस तंत्र द्वारा प्रदान की गई सुरक्षा अर्थव्यवस्था स्पष्ट है: सभी को अंततः अपने खाते संतुलित करने होंगे। लेकिन यह केवल “खाता संरक्षण” की गारंटी देता है, न कि “खाता सही है”। यदि Hook beforeSwap में एक दुरुपयोगपूर्ण रूप से निर्मित डेल्टा लौटाता है, तो PoolManager उस डेल्टा के अनुसार विश्वासपूर्वक लेखा करेगा, जब तक कि अंततः settle द्वारा संतुलित न हो जाए—यहां तक कि यदि इसका अर्थ है कि Hook बिजनेस स्टेट को झूठा बनाकर सिस्टम को यह गलत धारणा दे सकता है कि हमलावर के पास कुछ संपत्ति के हिस्से हैं, जबकि PoolManager इस बिजनेस-लेवल की गलती को पहचान नहीं सकता।

पहले कॉर्क प्रोटोकॉल की सुरक्षा घटना इसलिए घटी क्योंकि उसका हुक दोषपूर्ण था, और इस पर हमले से पहले इसे चार ऑडिट कंपनियों द्वारा ऑडिट किया जा चुका था। घटना के बाद हमने समीक्षा की कि:

चार में से तीन ऑडिट में CorkHook कॉन्ट्रैक्ट का स्कोप शामिल नहीं है

- केवल एक ऑडिटर ने CorkHook की ऑडिट की, जिसने कुछ कोड समस्याओं की पहचान की और सुधार के सुझाव दिए, लेकिन एक्सेस कंट्रोल समस्याओं को पूरी तरह से कवर नहीं किया।

एक अन्य ऑडिटर ने अपनी रिपोर्ट में स्पष्ट रूप से सुझाव दिया: "एक दिलचस्प अनुगामी एंगेजमेंट यह होगा कि इस एंगेजमेंट के दायरे के भीतर सत्यापित विभिन्न घटकों द्वारा कॉल किए जा रहे CorkHook फ़ंक्शन्स के लिए अपरिवर्तनीयता सिद्ध की जाए।" इस सुझाव की पश्चात् समीक्षा के दृष्टिकोण से उचितता है।

यह v4 Hook पीढ़ी के लिए एक नया ऑडिट अंधबिंदु उजागर करता है: प्रोटोकॉल की जटिलता में विस्फोटक वृद्धि के कारण, स्कोप की परिभाषा स्वयं एक सुरक्षा निर्णय बन गई है। Hook और प्रोटोकॉल के अन्य स्मार्ट कॉन्ट्रैक्ट्स के बीच इंटरैक्शन चेन बहुत लंबी होती है; केवल Hook कॉन्ट्रैक्ट की समीक्षा करने से क्रॉस-कॉन्ट्रैक्ट संयोजन समस्याओं का पता नहीं चलता; दूसरी ओर, आसपास के कॉन्ट्रैक्ट्स की समीक्षा करना और Hook को स्कोप से बाहर रखना v4 पीढ़ी के सबसे बड़े हमले के क्षेत्र को छोड़ देता है।

प्रोटोकॉल मैकेनिज्म और Cork हमले की समीक्षा को समानांतर रूप से देखने से, v4 Hook सुरक्षा मॉडल के कुछ केंद्रीय बिंदुओं को सारांशित किया जा सकता है:

(1) यदि Hook कॉलबैक फ़ंक्शन PoolManager द्वारा प्रदान किए गए कॉल कंटेक्स्ट पर निर्भर करता है, तो इसे स्पष्ट रूप से केवल PoolManager द्वारा ही कॉल किए जाने के लिए सीमित किया जाना चाहिए। BaseHook इसे डेवलपर के लिए नहीं करेगा, यह v4 और सामान्य स्मार्ट कॉन्ट्रैक्ट ऑडिट अनुभव के बीच सबसे आसानी से टकराने वाला डिज़ाइन जाल है।

(2) हुक और पूल के बंधन का नियंत्रण PoolManager द्वारा नहीं होता। डेवलपर्स को beforeInitialize में पूल व्हाइटलिस्ट या सिंगल पूल बाइंडिंग अपने आप लागू करनी होगी।

(3) हुक एड्रेस के परमिशन बिट्स को फंक्शन इम्प्लीमेंटेशन के साथ सख्ती से मेल खाना चाहिए। गणना किए गए एड्रेस में भविष्य में संभावित विस्तार के लिए सभी परमिशन बिट्स पहले से शामिल होने चाहिए।

(4) असिंक / कस्टम कर्व हुक मूल रूप से पूरी तरह से कस्टमाइज़ किए गए स्वैप इम्प्लीमेंटेशन है। इसमें Uniswap प्रोटोकॉल स्तर की कोई सुरक्षा नहीं है, और इसे "पूर्णतः स्वायत्त वित्तीय अनुबंध" मानक के अनुसार ऑडिट किया जाना चाहिए।

(5) डेल्टा अकाउंटिंग का “संरक्षण” “सही” होने के समान नहीं है। NonzeroDeltaCount == 0 केवल यह गारंटी देता है कि लेजर अंततः संतुलित होगा, लेकिन यह यह गारंटी नहीं देता कि लेजर की सामग्री को दुरुपयोगपूर्ण ढंग से नियंत्रित नहीं किया गया है।

(6) क्रॉस-मार्केट टोकन प्रकार का भ्रम v4 एरा का एक नया हमले का क्षेत्र है। जब प्रोटोकॉल उपयोगकर्ताओं को बाजार बनाने की अनुमति देता है, तो टोकन की अर्थशास्त्रीय जांच आवश्यक है, केवल इंटरफेस जांच पर निर्भर नहीं करनी चाहिए।

प्रत्येक Hook एक स्वतंत्र विश्वास क्षेत्र है, और प्रत्येक पूल की सुरक्षा उससे बंधे Hook द्वारा निर्धारित होती है। इसलिए Hook सुरक्षा ऑडिट की जटिलता अब “एक कोड की समीक्षा” नहीं, बल्कि “एक पूर्ण उप-प्रोटोकॉल की समीक्षा” है—यह परिवर्तन प्रोजेक्ट टीम और ऑडिटर दोनों के लिए विधि में उन्नति का अर्थ है।

(1) कॉर्क प्रोटोकॉल। “28 मई 2025 एक्सप्लॉइट पोस्ट-मॉर्टम।” 2025-06-04. https://www.cork.tech/blog/post-mortem

(2) OWASP स्मार्ट कॉन्ट्रैक्ट सुरक्षा शीर्ष 10 2026, SC01: एक्सेस कंट्रोल वल्नरेबिलिटीज। https://scs.owasp.org/sctop10/SC01-AccessControlVulnerabilities/

(3) यूनिस्वैप v4 व्हाइटपेपर। https://app.uniswap.org/whitepaper-v4.pdf

(4) यूनिस्वैप v4-core. https://github.com/Uniswap/v4-core

(5) यूनिस्वैप v4-पेरिफरी। https://github.com/Uniswap/v4-periphery

Beosin, जो फॉर्मल वेरिफिकेशन में विश्व की पहली ब्लॉकचेन सुरक्षा कंपनियों में से एक है, “सुरक्षा + अनुपालन” पूरे पारिस्थितिकी तंत्र की सेवाएं प्रदान करती है। यह दुनिया भर के 10 से अधिक देशों और क्षेत्रों में शाखाएं स्थापित करती है, और इसकी सेवाएं प्रोजेक्ट लॉन्च से पहले कोड सुरक्षा ऑडिट, प्रोजेक्ट चलाने के दौरान सुरक्षा जोखिम मॉनिटरिंग और रोकथाम, चोरी हुए संपत्ति की वापसी, वर्चुअल संपत्ति धोखाधड़ी रोकथाम (AML), और स्थानीय नियामक आवश्यकताओं के अनुसार अनुपालन मूल्यांकन जैसी “एक-स्टॉप” ब्लॉकचेन अनुपालन उत्पादों और सुरक्षा सेवाओं को शामिल करती है। कृपया हमसे संपर्क करने के लिए हमारे गूगल प्रोफाइल के संदेश बॉक्स पर क्लिक करें।