یونیسواپ v4 ہُک کے ذریعے قابل پروگرام لیکویڈیٹی فراہم کرتا ہے، لیکن اجازت کوڈنگ، ایکسس کنٹرول وغیرہ کی کمیوں کی وجہ سے حملوں کا مرکز بن گیا ہے؛ Async ہُک اور اکاؤنٹنگ منطق کے غلط استعمال کے خطرے کو نظرانداز نہ کریں۔

مضمون کا مصنف، ذریعہ: Beosin

Uniswap v4 کے مین نیٹ پر لانچ کے بعد، ہُک میکنزم DeFi کا ایک سب سے زیادہ توجہ کا مرکز تبدیل ہو گیا۔ Base چین پر، میم کوائن لانچنگ پلیٹ فارم Flaunch نے فکسڈ پری سیل قیمت اور آٹو میٹک کلیئرنگ لانچ میکنزم کو ہُک کا استعمال کرتے ہوئے ممکن بنایا ہے؛ لیکویڈٹی پروٹوکول Bunni v2 نے ہُک کا استعمال کرتے ہوئے قابل پروگرام لیکویڈٹی اور ری مارجیننگ ماڈل تعمیر کیا ہے؛ اس سال، SATO، uPEG (Unipeg)، Slonks جیسے ہُک کے ارد گرد بنائے گئے ٹوکن نے مختصر عرصے میں دس گنا تک کا فائدہ حاصل کیا۔

ہوک ایکوسسٹم کی خوشحالی کے دوسرے پہلو پر، ہوک کے عمل میں خامیوں کا استعمال کرتے ہوئے حملوں میں نمایاں اضافہ ہوا ہے۔ اس مضمون میں، ہم یونی سوواپ v4 کے ہوک میکنزم سے شروع کرتے ہوئے، اس کے مرکزی کال اسٹیک کا تجزیہ کریں گے تاکہ پروجیکٹس کو ممکنہ خامیوں کو سمجھنے میں مدد ملے۔

یونیسواپ v4 ہُک سیکورٹی

یونیسواپ v4 کا v3 کے مقابلے میں سب سے اہم آرکیٹیکچرل تبدیلی ہک (Hook) مکینزم کا تعارف ہے: جس سے ڈویلپرز کو لیکویڈٹی پول کے لائف سائکل واقعات پر کسٹم کنٹریکٹس منسلک کرنے کی اجازت ہوتی ہے، جہاں swap، لیکویڈٹی جوڑنا یا کم کرنا، اور شروع کرنا جیسے نوڈس پر کوئی بھی منطق شامل کیا جا سکتا ہے۔

v4 کے کچھ اہم تبدیلیاں درج ذیل ہیں:

Singleton ماڈل: تمام پولز کی حالت ایک منفرد PoolManager کنٹریکٹ کے ذریعے مرکزی طور پر منتظم ہوتی ہے، جس کے تحت ہر پول کے لیے الگ کنٹریکٹ نہیں ڈپلوی کیے جاتے۔

- فلیش اکاؤنٹنگ: ٹریڈنگ کے دوران درمیانی بیلنس کے تبدیلیوں کو صرف عارضی ذخیرہ میں ریکارڈ کیا جاتا ہے، اور صرف ٹریڈ ختم ہونے پر ایک ساتھ结算 کیا جاتا ہے

- ہُک میکنزم: ہر پول ایک ہُک کنٹریکٹ سے بندھا جا سکتا ہے، جس پر PoolManager اہم نکات (beforeInitialize، beforeSwap، afterAddLiquidity وغیرہ) پر کال بیک کرتا ہے۔

- ہُک تبدیل نہیں کیا جا سکتا: جب پول شروع ہو جائے، تو منسلک ہُک ایڈریس ہمیشہ کے لیے ثابت ہو جاتا ہے (پول سے منسلک ہُک ایڈریس تبدیل نہیں کیا جا سکتا، لیکن ہُک کنٹریکٹ کا اپ گریڈ ہونا اس کے عمل پر منحصر ہے)

v3 کے دوران، ڈیولپرز کو صرف یونیسواپ پروٹوکول پر اعتماد کرنا تھا؛ جبکہ v4 کے دوران، ہر پول کی سلامتی اس سے جڑے ہوئے ہک پر منحصر ہے۔ ہک نے AMM کو ایک مخصوص فنانشل پریمیٹ سے لے کر ایک قابل پروگرام فنانشل انفراسٹرکچر میں تبدیل کر دیا، لیکن سلامتی ماڈل بھی "پروٹوکول لیول" سے "پول لیول" تک ٹوٹ گیا۔

2. ہُک آرکیٹیکچر 2.1 پول مینیجر اور انلاک/کال بیک ماڈل

v4 کا مرکزی معاہدہ ایک منفرد PoolManager ہے۔ کسی بھی پول کی حالت میں تبدیلی (swap، لیکویڈٹی جوڑنا یا کم کرنا) کے لیے پہلے PoolManager.unlock() کو کال کرنا ضروری ہے، جس کے بعد ایک بار کے لیے کال بیک کا اجازت نامہ حاصل ہوتا ہے، اور unlockCallback() میں عملی تبدیلیاں کی جاتی ہیں۔ پورے عمل کے ختم ہونے پر، PoolManager چیک کرتا ہے کہ کیا لیجر متوازن ہے:

jab NonzeroDeltaCount != 0 ہو تو فوری طور پر revert کر دیں، یہ v4 فلیش اکاؤنٹنگ کا مرکزی پابندی ہے۔ کوئی بھی Hook اپنے عمل کے دوران اکاؤنٹ کو عدم توازن میں ڈال سکتا ہے، لیکن ٹریڈ کے ختم ہونے سے پہلے اسے خود settle کرنا ہوگا، ورنہ پوری ٹریڈ منسوخ ہو جائے گی۔

ہر پول PoolKey سٹرکچر سے منفرد طور پر شناخت کیا جاتا ہے، جس میں hooks فیلڈ شامل ہے:

PoolId keccak256(PoolKey) کے ذریعے حساب لگایا جاتا ہے، اس لیے مختلف hooks ایڈریس مختلف پولز کا باعث بنتے ہیں۔ اس کا مطلب یہ بھی ہے کہ PoolManager کوئی جانچ نہیں کرتا کہ کیا کوئی Hook ایڈریس پہلے کسی اور پول کے لیے استعمال ہو چکا ہے، ایک ہی Hook معاہدہ کئی پولز کے ساتھ одно وقت منسلک ہو سکتا ہے۔

2.2 ہُک اجازت بٹ کوڈنگ پتے میں

v4 کا ایک غیر متوقع ڈیزائن یہ ہے کہ ہُک کی اجازت کسی کنٹریکٹ کے اندر کے کسی متغیر سے نہیں بلکہ ہُک کنٹریکٹ کے ڈیپلومنٹ ایڈریس سے طے ہوتی ہے۔

PoolManager، ہک ایڈریس کے کم 14 بٹس کو چیک کرکے فیصلہ کرتا ہے کہ کیا ہک کو کسی زندگی کے مراحل پر بلایا جانا چاہیے:

مثال کے طور پر، BEFORE_SWAP_FLAG = 1 << 7۔ اگر ہُک ایڈریس کا 7ویں بٹ 1 ہے، تو PoolManager swap سے پہلے اس ہُک کی beforeSwap() فنکشن کو کال کرے گا؛ ورنہ، چاہے ہُک کنٹریکٹ beforeSwap() کو کیسے ہی ایمپلیمنٹ کرے، PoolManager کبھی بھی اسے کال نہیں کرے گا۔

اس کا مطلب یہ ہے کہ Hook کو ڈیپلوی کرتے وقت CREATE2 + salt کے ذریعے ایڈریس کو کیلکولیٹ کرنا ہوگا، تاکہ ایک ایسا ایڈریس بنایا جا سکے جس کے کم تر بٹس مقصد اجازتوں کے مکمل طور پر مطابق ہوں۔ Uniswap کی طرف سے اس مقصد کے لیے HookMiner ٹول دستیاب ہے:

جب اجازت بٹس اور فنکشن کی ت realised سازی میں عدم مطابقت ہو تو دو قسم کے مسائل پیدا ہوتے ہیں:

(1) ایک ہوک فنکشن کو لاگو کیا گیا، لیکن ایڈریس کو متعلقہ اجازت بٹس کے ساتھ اینکوڈ نہیں کیا گیا — PoolManager کبھی بھی اس فنکشن کو کال نہیں کرے گا، منطق بے کار ہے

(2) پتہ میں کسی اجازت بٹ کو کوڈ کیا گیا ہے، لیکن ہُک نے متعلقہ فنکشن کو نہیں لاگو کیا ہے — PoolManager کال بیک کے دوران ریورٹ ہو سکتا ہے، جس سے DOS حملہ یا ریٹرن ویلیو چیک فیل ہو سکتا ہے، جس کی وجہ سے متعلقہ آپریشنز نہیں چل سکتے۔

یہ Hook کے اپگریڈ کا ایک قدرتی رکاوٹ بھی ہے: اگر Hook کو پروکسی کے ذریعے اپگریڈ کیا جا سکتا ہے، تو ڈیپلویمنٹ ایڈریس اپگریڈ کے دوران نہیں بدلتا، اس لیے اپگریڈ کے بعد صرف موجودہ Hook فنکشنز کے ایمپلیمنٹیشن کو تبدیل کیا جا سکتا ہے، نئے Hook قسمیں شامل نہیں کی جا سکتیں۔ مستقبل کے وسعت کے لیے پہلے سے تیار رہنے کے لیے، ابتدائی ڈیپلویمنٹ کے دوران تمام ممکنہ اجازت بٹس پہلے سے ہی مختص کر لینے چاہئیں۔

2.3 BaseHook اور ایک عام طور پر نظر انداز کیا جانے والا ایکسیس کنٹرول کا شکار

یونیسواپ v4 کے پیرفیری کے پرانے ورژن میں فراہم کیا گیا BaseHook ایبسٹریکٹ کنٹریکٹ، جسے ڈویلپرز اپنے مخصوص Hook کو لاگو کرنے کے لیے ورثہ دے سکتے ہیں۔ BaseHook کا ایک اہم کردار unlockCallback() فنکشن کے لیے onlyPoolManager مودیفائر فراہم کرنا ہے:

لیکن — یہاں ایک بہت آسانی سے نظرانداز کیا جانے والا ڈیزائن جال ہے — BaseHook کے ابتدائی ورژن نے صرف unlockCallback کے لیے onlyPoolManager شامل کیا تھا، دیگر ہوک کال بیکس (beforeSwap، afterSwap، beforeAddLiquidity وغیرہ) کے لیے کوئی حفاظت نہیں تھی۔ ان فنکشنز کا ایکسیس کنٹرول ہوک ڈویلپر کو خود ظاہر طور پر شامل کرنا ہوگا۔

ایک 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: ہُک اس سویپ میں مخصوص ٹوکن اور غیر مخصوص ٹوکن کے ڈیلٹا ایڈجسٹمنٹس کو تبدیل کرتا ہے

- uint24: ڈائنامک LP فیس ریٹ کا کوریج ویلیو (صرف اس صورت میں جب پول میں ڈائنامک فیس سکیم سرگرم ہو)

BeforeSwapDelta ایک int256 کا مترادف ہے، جس کے اعلیٰ 128 بٹس مخصوص ٹوکن کا ڈیلٹا (یعنی صارف کی طرف سے مخصوص مقدار والے ٹوکن) ہوتا ہے، اور کم 128 بٹس غیر مخصوص ٹوکن کا ڈیلٹا ہوتا ہے:

نوٹ کریں کہ BeforeSwapDelta کا مطلب یہ ہے کہ ہُک کو فیس وصول کرنے پر مثبت قیمت واپس کرنی چاہیے اور ٹوکن واپس کرنے پر منفی قیمت۔ ڈویلپرز آسانی سے علامت الٹا دے دیتے ہیں؛ ساتھ ہی، مخصوص اور غیر مخصوص کا تعلق params.zeroForOne اور amountSpecified کے علامت پر منحصر ہے، جس کی تحریر میں تھوڑی سی غلطی سے ٹوکن کا تبادلہ ہو سکتا ہے۔

پول مینیجر beforeSwap سے واپس آنے والے specifiedDelta کو amountToSwap پر براہ راست جمع کر دے گا:

یا لائن ایک اہم مفہوم کو ظاہر کرتی ہے: ہُک swap رقم کو روک سکتا ہے۔ جب hookDeltaSpecified، -params.amountSpecified کے برابر ہو، تو amountToSwap فوراً صفر ہو جاتا ہے، جس سے ہُک پورے swap پر مکمل کنٹرول حاصل کر لیتا ہے—یہی Async Hook یا Custom Curve Hook کہلاتا ہے۔

Async Hook v4 میں سب سے زیادہ خطرناک ڈیزائن پیٹرن ہے: یہ بنیادی طور پر Uniswap کے swap منطق کو اپنے ہی Hook منطق سے تبدیل کرتا ہے۔ اگر Hook میں کوئی خامی ہے یا یہ خود بخود بری نیت کا ہے، تو صارفین کے فنڈز Uniswap کے اصل قیمت تعیناتی منطق کے تحت نہیں رہیں گے، بلکہ ان پر مکمل طور پر Hook کے اپنے عمل کی درستگی انحصار کرے گی۔

3.3 ڈیلٹا سیٹلمنٹ اور NonzeroDeltaCount

beforeSwap اور afterSwap کے ذریعے واپس کیا گیا delta فوری ٹرانسفر کو ٹرگر نہیں کرتا، بلکہ اسے PoolManager کے اندری لیجر میں ریکارڈ کیا جاتا ہے:

جب کسی ٹوکن کا کل مجموعی ڈیلٹا صفر سے غیر صفر ہو جائے، تو NonzeroDeltaCount بڑھ جاتا ہے؛ جب دوبارہ صفر ہو جائے، تو یہ کم ہو جاتا ہے۔ جیسا کہ 2.1 میں بیان کیا گیا ہے، اگر unlock() کے ختم ہونے پر NonzeroDeltaCount != 0 ہے، تو پورا ٹرانزیکشن revert ہو جائے گا۔

ہوک اپنا ڈیلٹا settle() (PoolManager کو ٹرانسفر کرکے) اور take() (PoolManager سے نکال کر) کے ذریعے توازن میں رکھتا ہے:

اس مکینزم کے ذریعے حاصل ہونے والا سیکیورٹی مطلب واضح ہے: تمام لوگوں کو آخرکار اپنا اکاؤنٹ بند کرنا ہوگا۔ لیکن یہ صرف "اکاؤنٹ کا توازن" یقینی بناتا ہے، "اکاؤنٹ کی درستگی" نہیں۔ اگر Hook beforeSwap میں ایک بدسلوکی سے تیار کیا گیا delta واپس کرے، تو PoolManager اس delta کو بے نقاب طور پر ریکارڈ کر دے گا، اور جب تک آخر میں settle ہو جائے، تجارت کامیاب ہو جائے گی—حتیٰ کہ اس کا مطلب ہو سکتا ہے کہ Hook جعلی بزنس حالت کے ذریعے سسٹم کو یہ غلط فہمی دے سکتا ہے کہ حملہ آور کے پاس کچھ اثاثوں کے حقوق ہیں، جبکہ PoolManager اس بزنس لیول کی غلطی کو شناخت نہیں کر سکتا۔

پہلے کورک پروٹوکول کی سیکیورٹی واقعہ اس کے ہوک میں خامی کی وجہ سے ہوا، اور حملے سے پہلے اسے چار آڈٹ کمپنیوں نے جانچ لیا تھا۔ واقعہ کے بعد جائزہ لینے پر ہم نے پایا:

چار آڈٹ میں سے تین کے دائرہ کار میں کورکہوک کنٹریکٹ شamil نہیں ہے

CorkHook کا صرف ایک ہی آڈٹ کیا گیا، جس نے کچھ کوڈ کے مسائل کی شناخت کی اور بہتری کے تجاویز پیش کیے، لیکن ایکسیس کنٹرول کے مسائل تک مکمل طور پر نہیں پہنچا۔

ایک اور آڈیٹر نے اپنی رپورٹ میں واضح طور پر تجویز کی کہ: "ایک دلچسپ مزید معاہدہ یہ ہوگا کہ کورکہوک فنکشنز کے لیے انویریئنٹس ثابت کیے جائیں جنہیں اس معاہدے کے دائرہ کار کے اندر تصدیق شدہ مختلف کمپوننٹس فعال کرتے ہیں۔" اس تجویز کا پس منظر میں جائزہ لینے پر بہت زیادہ متعلقہ ہونے کا ثبوت ہے۔

یہ v4 ہُک کے دور میں ایک نیا آڈٹ کا خلا ظاہر کرتا ہے: پروٹوکول کی پیچیدگی کا تیزی سے بڑھنا scope کے تعین کو ایک سیکورٹی فیصلہ بناتا ہے۔ ہُک اور پروٹوکول کے دیگر معاہدوں کے درمیان تفاعل کا سلسلہ بہت لمبا ہوتا ہے؛ صرف ہُک کنٹریکٹ کا آڈٹ کرنا کراس-کنٹریکٹ کے ترکیبی مسائل کو دریافت نہیں کر سکتا؛ اور اس کے برعکس، اگر آپ دیگر معاہدوں کا آڈٹ کریں اور ہُک کو scope سے باہر رکھ دیں، تو v4 دور کا سب سے بڑا حملے کا نقطہ نظر چھوٹ جائے گا۔

پروٹوکول میکانزم اور کورک حملے کو ایک ساتھ جانچنے سے، v4 Hook سیکورٹی ماڈل کے کچھ مرکزی نکات قائم ہو جاتے ہیں:

(1) اگر Hook کال بیک فنکشن PoolManager کی فراہم کردہ کال کنٹیکس پر منحصر ہے، تو اسے صرف PoolManager کے ذریعہ کال کیے جانے کے لیے واضح طور پر محدود کیا جانا چاہیے۔ BaseHook ڈویلپر کے لیے یہ کام نہیں کرے گا، یہ v4 اور عام کنٹریکٹ اڈٹ کے تجربے کے درمیان سب سے زیادہ تنازعہ پیدا کرنے والا ڈیزائن جال ہے۔

(2) ہوک اور پول کے درمیان کنکشن PoolManager کے پابند نہیں ہے۔ ڈویلپرز کو beforeInitialize میں پول وائٹ لسٹ یا ایکل پول بائنڈنگ خود ایمپلیمنٹ کرنا ہوگا۔

(3) ہُک ایڈریس کے اجازت بٹس کو فنکشن کی تعمیر کے ساتھ سختی سے مطابقت رکھنا چاہیے۔ حساب لگائے گئے ایڈریس میں مستقبل میں ممکنہ طور پر توسیع کے لیے تمام اجازت بٹس پہلے سے شamil کر لینے چاہئیں

(4) Async / Custom Curve Hook بنیادی طور پر مکمل طور پر کسٹمائز سویپ ایمپلیمنٹیشن ہے۔ اس میں Uniswap پروٹوکول کے کسی بھی سطح پر حفاظت نہیں ہے، اور اسے "مکمل خود مختار فنانشل کنٹریکٹ" کے معیار کے مطابق آڈٹ کیا جانا چاہیے۔

(5) ڈیلٹا اکاؤنٹنگ کا "برقرار رکھنا" "درست" کے برابر نہیں ہے۔ NonzeroDeltaCount == 0 صرف یہ یقینی بناتا ہے کہ اکاؤنٹنگ بالآخر متوازن ہے، لیکن یہ یہ نہیں بتاتا کہ اکاؤنٹنگ کا مواد بے ایمانی سے مانیپولیٹ نہیں ہوا۔

(6) کراس مارکیٹ ٹوکن کے قسم کا الجھنا v4 کے دور کا ایک نیا حملے کا نقطہ ہے۔ جب پروٹوکول صارفین کو مارکیٹ بنانے کی اجازت دے، تو ٹوکن کی معنائی تصدیق ضروری ہے، صرف انٹرفیس چیک پر انحصار نہیں کیا جانا چاہئے

ہر ہُک ایک الگ اعتماد کا علاقہ ہے، اور ہر پول کی حفاظت اس کے منسلک ہُک پر منحصر ہے۔ اس لیے ہُک کی سیکیورٹی آڈٹ کی پیچیدگی اب "ایک کوڈ کا آڈٹ" نہیں بلکہ "ایک مکمل سب پروٹوکول کا آڈٹ" بن گئی ہے — یہ تبدیلی منصوبہ سازوں اور آڈٹرز دونوں کے لیے طریقہ کار میں ارتقاء کا مطلب رکھتی ہے۔

(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

بیوسن، جو بلاکچین سیکیورٹی کے شعبے میں فارمل ویریفیکیشن کے لیے عالمی سطح پر پہلی ٹیم میں سے ایک ہے، "سیکیورٹی + کمپلائنس" کے مکمل ایکوسسٹم کی فراہمی پر توجہ مرکوز کرتا ہے، جس نے دنیا بھر کے 10 سے زائد ممالک اور علاقوں میں شاخیں قائم کی ہیں۔ اس کی سروسز میں پروجیکٹس کے لانچ سے پہلے کوڈ سیکیورٹی آڈٹ، پروجیکٹ کے عمل کے دوران سیکیورٹی خطرات کی نگرانی اور روک تھام، چوری شدہ اثاثوں کی واپسی، ورچوئل اثاثوں کے خلاف دھوکہ دہی (AML) اور مقامی ریگولیٹری ضوابط کے مطابق کمپلائنس ایوالویشن جیسے "ایک ہی جگہ" بلاکچین کمپلائنس پروڈکٹس اور سیکیورٹی سروسز شامل ہیں۔ براہ راست ہمارے گوگل پر لائف بکس میں پیغام بھیج کر ہم سے رابطہ کریں۔