دسمبر 16، 2021
تعارف
۔ 1inch ٹیم نے ہم سے ان کا جائزہ لینے اور آڈٹ کرنے کو کہا لمیٹ آرڈر پروٹوکول v2 سمارٹ معاہدے۔ ہم نے کوڈ کو دیکھا اور اب اپنے نتائج شائع کرتے ہیں۔
گنجائش
ہم نے کمٹ کا آڈٹ کیا۔ 4d94eea25e4dac6271bfd703096a5c4a4d899b4a
کی 1inch/limit-order-protocol
ذخیرہ دائرہ کار میں درج ذیل معاہدے تھے:
- OrderMixin.sol
- OrderRFQMixin.sol
- PredicateHelper.sol
- RevertReasonParser.sol
- Permitable.sol
- ChainlinkCalculator.sol
- ArgumentsDecoder.sol
- AmountCalculator.sol
- NonceManager.sol
- LimitOrderProtocol.sol
- ImmutableOwner.sol
- InteractiveNotificationReceiver.sol
- AggregatorInterface.sol
- IDaiLikePermit.sol
دیگر تمام پروجیکٹ فائلز اور ڈائریکٹریز (بشمول ٹیسٹ)، بیرونی انحصار اور پروجیکٹس، گیم تھیوری، اور ترغیباتی ڈیزائن کے ساتھ، کو بھی اس آڈٹ کے دائرہ کار سے خارج کر دیا گیا تھا۔ بیرونی کوڈ اور معاہدے پر انحصار کو دستاویزی طور پر کام کرنے کے لیے فرض کیا گیا تھا اور 1 انچ کے ذریعے فراہم کردہ بیک اینڈ سروسز کو پروٹوکول کے بہترین مفاد میں کام کرنے کے لیے فرض کیا گیا تھا۔
مجموعی صحت
عام طور پر، ہم نے پروجیکٹ کے کوڈبیس کو پڑھنے کے قابل اور اچھی طرح سے منظم پایا، حالانکہ یہ زیادہ وسیع دستاویزات سے فائدہ اٹھا سکتا ہے، خاص طور پر اسمبلی کوڈ کے بلاکس، پروٹوکول کے ایج کیسز، اثاثے/پیش گوئی/بیرونی وسائل جو استعمال کیے جائیں گے، فراہم کردہ بیک اینڈ سروس کی ذمہ داریاں/ حدود، اور اداکاروں کے درمیان تعامل۔ پراجیکٹ کارروائیوں کو گیس سے موثر بنانے کے لیے کافی حد تک جاتا ہے، کبھی کبھار کوڈ کے بارے میں استدلال کرنا زیادہ مشکل ہونے کے خطرے میں بھی۔ ہم ذیل میں اس سے متعلق مسائل اٹھاتے ہیں۔ پورے آڈٹ کے دوران، 1 انچ کی ٹیم انتہائی دستیاب، ذمہ دار، اور کام کرنے میں بہت آسان تھی۔
سسٹم کا جائزہ
حد آرڈر پروٹوکول آرڈر کو قابل بناتا ہے۔ makers
ٹوکن سویپ کے لیے آف چین آرڈرز پر دستخط کرنے کے لیے۔ اس کے بعد پروٹوکول پہلے سے دستخط شدہ آرڈرز کو بذریعہ آرڈر بھرنے میں سہولت فراہم کرتا ہے۔ takers
. آرڈرز انتہائی قابل توسیع ہیں، اور آرڈر بھرنے کے پورے عمل کے دوران متعدد پوائنٹس پر بیرونی معاہدوں کو جامد کال کر سکتے ہیں۔ یہ توسیع پذیری پروٹوکول کو افادیت کے ساتھ جذب کرتی ہے، لیکن یہ خود آرڈرز کے لیے پیچیدگی اور زیادہ حملے کی سطح دونوں کا اضافہ کرتی ہے۔
یہ بتانا ضروری ہے کہ آرڈر کی تفصیلات کا کوئی آن چین اسٹوریج نہیں ہے۔ آرڈرز کی فل اسٹیٹ یا منسوخی کی صورتحال صرف آرڈر ہیش کے ذریعے ٹریک کی جاتی ہے۔ اس کے لیے ضروری ہے کہ آرڈرز پیر ٹو پیئر یا کسی مرکزی جماعت کے ذریعے شیئر کیے جائیں۔ اس معاملے میں، 1 انچ کی ٹیم اس مرکزی فریق کے طور پر کام کرنے کا ارادہ رکھتی ہے، دستخط شدہ آرڈرز کو جمع کرنا اور ان آرڈرز کو اپنے دوسرے پروٹوکولز کے لیے لیکویڈیٹی کے ذریعہ استعمال کرنا۔ آرڈرز ان کے اپنے API کے ذریعے شائع کیے جائیں گے تاکہ صارفین ان کے ساتھ بات چیت کر سکیں۔
یہ سنٹرلائزیشن 1 انچ کی ٹیم کو انتہائی کنٹرول فراہم کرتی ہے جس پر آرڈرز شائع ہوتے ہیں اور آخر کار اس پر عمل درآمد ہوتا ہے۔ اس سے انہیں آرڈرز کو سنسر کرنے کی صلاحیت بھی ملتی ہے، جو بدنیتی پر مبنی یا فریب دینے والے آرڈرز کی صورت میں کارآمد ثابت ہو سکتے ہیں، لیکن اس کا غلط استعمال بھی کیا جا سکتا ہے اور انہیں API کے ذریعے نہ دکھا کر موافق آرڈر کی صورت میں کسی دوسرے صارف کو آگے بڑھانے کی اجازت دیتا ہے۔
مراعات یافتہ کردار
اگرچہ کنٹریکٹس جن میں یہ کردار استعمال ہوتا ہے وہ دائرہ کار سے باہر تھے، لیکن ایک مراعات یافتہ کردار کی نشاندہی کی گئی۔ ایک immutableOwner
تعمیر کے وقت پراکسی کنٹریکٹ کے خالق پر سیٹ کیا جاتا ہے، اور پراکسی کی رسائی کو محدود کرنے کے لیے استعمال کیا جاتا ہے۔ external
کام کرتا ہے.
بیرونی انحصار اور اعتماد کے مفروضے۔
اس پروٹوکول کے ڈیزائن کے لیے آف چین اور آن چین اجزاء کی ضرورت ہوتی ہے، اور اس ہائبرڈ ماڈل کو کچھ حملہ آور ویکٹرز کو کم کرنے کے لیے استعمال کیا جا سکتا ہے جن کی ہم اپنی رپورٹ میں شناخت کرتے ہیں، لیکن اس قابلیت کی قیمت 1 انچ ٹیم اور انفراسٹرکچر پر انحصار بڑھاتی ہے۔
مزید برآں، Limit Order Protocol ایسے فنکشنز فراہم کرتا ہے جن کا مقصد Chainlink oracles سے قیمتیں حاصل کرنا ہے۔ ہم نے فرض کیا کہ وہ اوریکلز ایماندار، قابل رسائی، اور مناسب طریقے سے کام کر رہے ہیں۔
مزید برآں، آرڈر کی لچک کی وجہ سے، بیرونی معاہدوں کے ساتھ رابطے کے کئی نکات ہیں جن کی توثیق نہیں کی گئی ہے۔ اس کا مطلب ہے کہ ایک بدنیت صارف اس طرح کی کالوں کا غلط استعمال کر سکتا ہے اور آرڈر بھرنے کے دوران کارروائیوں کو انجام دینے کے لیے بدنیتی پر مبنی معاہدوں کے ساتھ پیشین گوئیوں، اثاثوں یا اوریکلز کی نقالی کر سکتا ہے۔ اگرچہ پروجیکٹ کو کچھ علاقوں میں دوبارہ داخلے کے خلاف تحفظ حاصل ہے، ایسے ویکٹر سروس حملوں یا غیر شناخت شدہ سپیم آرڈرز سے انکار کا سبب بن سکتے ہیں۔ 1 انچ کی ٹیم اس بات سے آگاہ ہے کہ پروٹوکول کے لیے ناواقف معاہدوں کا استعمال کرتے وقت کچھ مسائل ظاہر ہو سکتے ہیں اور اس نے اپنے ارادے کی نشاندہی کی ہے کہ صرف بڑے "بلیو چپ" اثاثوں کو پروجیکٹ کے ذریعے مکمل تعاون حاصل ہوگا۔ تاہم، یہ واضح رہے کہ سب سے زیادہ مقبول اثاثوں کے ساتھ بھی ہر اثاثے کے اندرونی رویے ہوتے ہیں جو پروٹوکول پر مسائل پیدا کر سکتے ہیں جو ان کو ٹھیک طریقے سے حل نہیں کرتے، جیسے USDT کے ساتھ منتقلی کے دوران فیس لینا یا اس کے بجائے غلطی کا کوڈ واپس کرنا۔ cTokens کے ساتھ کامیاب بولین۔
نتائج
یہاں ہم اپنے نتائج پیش کرتے ہیں۔
نازک شدت
کوئی بھی نہیں.
اعلی شدت
[H01] متضاد ڈیٹا منتقل ہوا۔ _makeCall
میں OrderMixin
معاہدہ، _makeCall
فنکشن اثاثوں کی منتقلی کے لیے استعمال ہوتا ہے۔ لینے والے سے بنانے والے تک اور پھر بنانے والے سے لینے والے تک. مؤخر الذکر کی منتقلی میں، _makeCall
فنکشن کو غلط طریقے سے آرڈر پاس کیا گیا ہے۔ makerAsset
آخری پیرامیٹر کے طور پر، جب یہ آرڈر کا ہونا چاہیے۔ makerAssetData
.
نتیجے کے طور پر، کوئی بھی پراکسی فعالیت جو پر انحصار کرتی ہے۔ makerAssetData
دلیل ٹوٹ جائے گی.
پہلے کی کال کے ساتھ مطابقت رکھنے کے لیے _makeCall
اور پراکسی فعالیت کو مکمل طور پر سپورٹ کرنے کے لیے، کو اپ ڈیٹ کرنے پر غور کریں۔ order.makerAsset
کرنے کے لئے پیرامیٹر order.makerAssetData
.
: اپ ڈیٹ کریں میں فکسڈ درخواست # 57 ھیںچو.
[H02] جزوی طور پر بھرے نجی آرڈرز کو کوئی بھی بھر سکتا ہے۔
پروٹوکول نجی اور عوامی احکامات کی تخلیق کی اجازت دیتا ہے۔ نجی احکامات پر، صرف allowedSender
ایڈریس، آرڈر کی تخلیق کے دوران بنانے والے کے ذریعہ بیان کیا گیا ہے، آرڈر کو بھرنے کے قابل ہے۔
تاہم ، میں OrderMixin
معاہدہ ، کے لئے توثیق allowedSender
پتہ غلط طریقے سے دائرہ کار ہے، مطلب یہ ہے کہ اس کا اندازہ صرف اس منطق کے اندر کیا جاتا ہے جو آرڈر کے پہلے فل کو ہینڈل کرتی ہے۔ اگر ایک نجی آرڈر جزوی طور پر بھرا ہوا ہے، تو اس کے لیے چیک allowedSender
ایڈریس اب قابل رسائی نہیں ہے اور آرڈر کسی کے ذریعہ بھرنے کے قابل ہوجاتا ہے۔
اس بارے میں ارادے کو واضح کرنے کے لیے کہ آیا کوئی صارف جزوی طور پر بھرے ہوئے نجی آرڈرز کو پُر کرنے کے قابل ہونا چاہیے یا نہیں، یا تو موجودہ رویے کی وجہ کو دستاویز کرنے یا اس کی توثیق کرنے پر غور کریں۔ allowedSender
پہلے بھرنے کے دائرہ کار سے باہر کا پتہ اس بات کو یقینی بنانے کے لیے کہ جب بھی بھرنے کی کوشش کی جائے گی اس کی توثیق کی جائے گی۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 58 ھیںچو.
[H03] بدنیتی پر مبنی بنانے والا لینے والے کے اثاثوں کو چوری کرنے کے لیے جزوی بھرنے کا فائدہ اٹھا سکتا ہے
کی طرف سے احکامات OrderMixin
معاہدہ جزوی طور پر بھرنے کی صلاحیت رکھتا ہے۔ جزوی فلز کو سپورٹ کرنے کے لیے، پروٹوکول کو تبادلوں کے دونوں اطراف کا حساب لگانے کا طریقہ درکار ہوتا ہے۔ دونوں getMakerAmount
اور getTakerAmount
فیلڈز کی وضاحت اس عین مقصد کے لیے آرڈر بنانے والے کے ذریعے کی گئی ہے۔
آرڈر بھرتے وقت، لینے والوں کو یا تو فراہم کرنا چاہیے۔ makingAmount
یا takingAmount
اقدار کے ساتھ ساتھ a thresholdAmount
قدر. دو مختلف کوڈ راستے ہیں جو لیے جا سکتے ہیں، اگر اس کی بنیاد پر makingAmount
یا takingAmount
فراہم کی گئی تھی۔
پہلا وہ ہے جب makingAmount
پیرامیٹر کی وضاحت کی گئی ہے۔ یہ کر سکتا ہے چھوٹا la makingAmount
قدر اور بھی کا حساب لگائیں takingAmount
اس کے لئے قدر. اس صورت حال میں، thresholdAmount
اس بات کو یقینی بناتا ہے کہ takingAmount
لی گئی قدر ہے غیر متوقع طور پر بڑا نہیں.
دوسرا ہے جب takingAmount
پیرامیٹر کی وضاحت کی گئی ہے۔ ایسی صورت میں، یہ کرے گا کا حساب لگائیں makingAmount
قدر، کے امکان کے ساتھ اسے کاٹنا اور دوبارہ گنتی takingAmount
قدر اگر ایسا ہوتا ہے۔ اس صورت حال میں، thresholdAmount
قدر یقینی بناتی ہے کہ makingAmount
واپس کی گئی قدر ہے غیر متوقع طور پر چھوٹا نہیں.
استحصال کے دو طریقے موجود ہیں، ہر ایک پچھلے ذکر کردہ کوڈ راستوں میں سے ایک سے منفرد ہے۔ استحصال کے ان طریقوں کے لیے بدنیتی کی ضرورت ہوتی ہے۔ getMakerAmount
اور getTakerAmount
افعال. ان افعال کے ایک سادہ نفاذ کا ایک جیسا سلوک ہوگا۔ AmountCalculator
کی getMakerAmount
اور getTakerAmount
فنکشنز، لیکن ایک سخت کوڈ والے سوئچ کے ساتھ جو انہیں ضرورت پڑنے پر حملہ آور کے کنٹرول شدہ قدر واپس کرنے پر مجبور کرے گا۔
پہلے، کم شدید استحصال کے پیٹرن میں پہلا کوڈ پاتھ شامل ہوتا ہے جہاں makingAmount
قدر بیان کی گئی ہے۔ بھرنے کے آرڈر میں۔ ایک بدنیتی پر مبنی بنانے والا فل آرڈر کا انتظار کرے گا جس میں وضاحت کی گئی ہے۔ makingAmount
اسے آگے چلانے کے لیے میمپول میں دکھائی دینا۔ وہ بنانے والے کی طرف سے 1 کے علاوہ تمام قیمت نکال دیں گے اور پھر زبردستی کریں گے۔ _callGetTakerAmount
صارف میں بیان کردہ رقم واپس کرنے کے لیے thresholdAmount
قدر (یا ان کا الاؤنس اگر کم ہے)۔ جب صارف کا لین دین آخر کار گزر جائے گا، تو وہ اپنا پورا بدل لیں گے۔ thresholdAmount
کے قابل takerAsset
کی ایک اکائی کے لیے makerAsset
. یہ استحصال کی طرف سے دی گئی رقم تک محدود ہے۔ thresholdAmount
قدر یا مقدار takerAsset
صارف کو اجازت دی گئی LimitOrderProtocol
معاہدہ.
دوسرا، زیادہ شدید استحصال کے انداز میں دوسرا کوڈ پاتھ شامل ہوتا ہے جہاں takingAmount
قدر بیان کی گئی ہے۔. بدنیتی پر مبنی بنانے والا اسی طرح ایک فل آرڈر کا انتظار کرے گا جس میں a کی وضاحت کی گئی ہو۔ takingAmount
میمپول میں ظاہر کرنے کی قدر۔ وہ لین دین کو آگے بڑھائیں گے اور مجبور کریں گے۔ makingAmount
قدر کی طرف سے واپس _callGetMakerAmount
فنکشن دونوں سے زیادہ ہونا remainingMakerAmount
اور thresholdAmount
. وہ بھی سیٹ کریں گے۔ takingAmount
کی طرف سے قدر واپس _callGetTakerAmount
کی رقم ہونا takerAsset
پر اجازت اثاثہ LimitOrderProtocol
لینے والے کی طرف سے. جب لینے والے کا لین دین ہو جائے گا تو ہو جائے گا۔ کو چھوٹا کریں makingAmount
قدر اور پھر دوبارہ گنتی کریں takingAmount
قدر. تاہم اس دوبارہ گنتی کے کم ہونے کی ضمانت نہیں ہے، اور اس صورت میں لینے والے کو تمام takerAsset
کہ انہوں نے معاہدے پر اجازت دی تھی۔ اس کوڈ پاتھ میں، thresholdAmount
قدر ہے اس بات کو یقینی بنانا کہ makingAmount
بہت کم نہیں ہے، تو تمام لینے والوں کو لے رہا ہے۔ takerAsset
اثاثہ چیک نہیں کیا گیا ہے۔ ضائع ہونے والے فنڈز کی رقم کے پابند ہیں۔ takerAsset
صارف کو اجازت دی گئی اثاثہ LimitOrderProtocol
معاہدہ.
یہ کارنامے جزوی احکامات کے بغیر ممکن نہیں ہیں اور خاص طور پر، بدنیتی پر مبنی جزوی احکامات کے getMakerAmount
اور getTakerAmount
عمل درآمد.
کا بنیادی مسئلہ thresholdAmount
ویلیو چیک یہ ہے کہ یہ سویپ کے صرف ایک طرف کا احاطہ کرتا ہے، لیکن دوسری طرف کو فرنٹرننگ کے ذریعے جوڑ توڑ کیا جا سکتا ہے۔ اس بات کی کوئی یقین دہانی نہیں ہے کہ لینے والے نے اصل میں جو قیمت تجویز کی ہے وہ بدستور برقرار ہے۔ ہٹانے پر غور کریں۔ makingAmount
دونوں کوڈ پاتھوں سے کٹ جانا اور اگر آرڈر درخواست کے مطابق بڑے بھرنے کو سپورٹ نہیں کر سکتا تو واپس جانا۔ ایسا کرنے سے، thresholdAmount
تبادلہ کے دوسرے پہلو کو کافی حد تک محدود کرنے اور غیر متوقع رویے سے بچنے کے لیے استعمال کیا جا سکتا ہے، حتیٰ کہ بدنیتی پر مبنی احکامات میں بھی۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 83 ھیںچو.
درمیانی شدت
متحرک دلائل کے بعد جامد دلائل گزر گئے۔
میں OrderMixin
معاہدہ، getTakerAmount
اور getMakerAmount
بائٹس فیلڈز کو بطور دلیل استعمال کیا جاتا ہے۔ _callGetTakerAmount
اور _callGetMakerAmount
افعال. یہ کالز دوسری طرف کی بنیاد پر سویپ کے ایک طرف کا حساب لگانے کا طریقہ فراہم کرتی ہیں، اور یہ صارفین کو جزوی طور پر آرڈرز بھرنے کی اجازت دیتی ہیں۔
۔ getTakerAmount
/getMakerAmount
فیلڈز متحرک متغیرات ہیں اور کے سامنے پیک ہیں۔ takerAmount
اور makerAmount
میں اقدار _callGetTakerAmount
اور _callGetMakerAmount
افعال. بدنیتی پر مبنی بنانے والے کے لیے یہ ممکن ہے کہ میں توقع سے زیادہ ڈیٹا فراہم کرے۔ getTakerAmount
اورgetMakerAmount
دھکیلنے کے لیے فیلڈز takerAmount
اور makerAmount
بائٹس ماضی میں جہاں اگلے فنکشن میں ڈی کوڈ ہونے پر انہیں سمجھا جاتا ہے۔ اس سے میکر کو پاس ان ٹیکر یا میکر کی رقم کو مکمل بائٹس کے ذریعے دائیں طرف منتقل کرنے کی اجازت ملتی ہے اور یہاں تک کہ اگر 32 بائٹس کا اضافی ڈیٹا فراہم کیا جاتا ہے تو اسے مکمل طور پر تبدیل کر سکتا ہے۔
صارفین کو پہلے ہی دستی طور پر جائزہ لینا ہوگا۔ getTakerAmount
اور getMakerAmount
ترتیب میں فیلڈز، لیکن اس تکنیک کو تلاش کرنا کافی مشکل ہے۔ یہ بھی قابل غور ہے کہ یہ حملہ اندرونی طور پر قابل اعتماد افراد پر بھی لاگو ہوتا ہے۔ getMakerAmount
اور getTakerAmount
افعال. زیادہ تر حملوں کے لیے، مناسب حد کی رقم فراہم کرنے سے فنڈز کے نقصان کو روکا جائے گا۔
اس کو روکنے کے لیے، متحرک دلائل سے پہلے جامد دلائل کو انکوڈنگ کرنے پر غور کریں تاکہ متحرک دلائل کو جامد دلائل کو کنٹرول کرنے کا طریقہ نہ دیا جائے۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم نے کہا:
ہم حاصل کرنے والوں کی توثیق کے ساتھ اضافی خیال رکھیں گے۔ ہم اپنے sdk میں حاصل کرنے والوں کی سنجیدگی کی توثیق کو لاگو کرنے کی کوشش کریں گے جو ممکنہ طور پر بدنیتی پر مبنی آرڈرز کو فلٹر کرنے میں مدد کرے گا۔
[M02] ERC721 آرڈرز میں ہیرا پھیری کی جا سکتی ہے۔
کے ذریعے صرف ERC20s سے زیادہ کا تبادلہ ممکن ہے۔ OrderMixin
ایک معاہدے کی تعیناتی کے ذریعے جو IERC20 کے ایک ہی فنکشن سلیکٹر کا اشتراک کرتا ہے۔ transferFrom
، اور اس معاہدے کو بطور فراہم کرنا makerAsset
یا takerAsset
ایک حکم میں.
دائرہ سے باہر پراکسیز، یعنی، ERC721Proxy
, ERC721ProxySafe
، اور ERC1155Proxy
معاونت فراہم کرنے کے لیے معاہدے اس طرز پر عمل کرتے ہیں۔ ERC721
اور ERC1155
ٹوکن چونکہ پراکسیز کو IERC20 کے پیٹرن کے ساتھ بلایا جانا چاہیے۔ transferFrom
کال کریں، دستخط سے شروع ہونا چاہیے۔ address from
, address to
اور uint256 amount
. کوئی اور چیز جس کی پراکسیوں کو ضرورت ہوتی ہے اسے بعد میں پاس کیا جا سکتا ہے، اور ترتیب میں اس کی وضاحت کی گئی ہے۔ makerAssetData
اور takerAssetData
.
ERC1155s قدرتی طور پر ایک ہی آئی ڈی کے متعدد ٹوکن ایک ساتھ منتقل کر سکتا ہے، جس کا مطلب ہے۔ ERC1155Proxy
معاہدہ کا استعمال کرتا ہے amount
میدان دوسری جانب، ERC721
کے لیے s کا واضح استعمال نہیں ہے۔ amount
میدان چونکہ وہ نان فنگیبل ٹوکن کی نمائندگی کرتے ہیں، اس لیے ایک مخصوص ٹوکن آئی ڈی کا وجود صرف ایک ہوگا، amount
فیلڈ بیکار. اس کی وجہ سے، دونوں کے لئے عمل درآمد ERC721Proxy
اور ERC721ProxySafe
معاہدے کی ضرورت کا استعمال کرتے ہیں amount
میدان کے طور پر tokenId
بجائے.
کی یہ اوورلوڈنگ amount
پیرامیٹر جزوی طور پر بھرنے کا امکان پیدا کرتا ہے۔ ERC721
رعایتی قیمتوں پر الگ سے درج ٹوکن خریدنے کے احکامات۔ مثال کے طور پر، ایک ایسا معاملہ ہو سکتا ہے جہاں ایک صارف کے پاس متعدد ہوں۔ ERC721
اسی معاہدے کے s کو منتقل کرنے کی اجازت ہے۔ ERC721Proxy
معاہدہ کرتا ہے اور انہیں الگ الگ حد کے احکامات میں درج کرتا ہے۔
حد کے احکامات بھی فراہم کرتے ہیں تو getMakerAmount
اور getTakerAmount
فیلڈز، ان کو جزوی طور پر بھرنا ممکن ہو گا۔ ERC721
احکامات. آرڈر کے بعد سے amount
فیلڈ دراصل سے مساوی ہے۔ tokenId
، ایک بدنیتی پر مبنی صارف جزوی طور پر بھر سکتا ہے۔ ERC721
اعلی ٹوکن آئی ڈی کے ساتھ، جس کے نتیجے میں a makingAmount
/takingAmount
کے ERC721
جو کہ کم کے مطابق ہو سکتا ہے۔ tokenId
. نتیجہ یہ ہے۔ ERC721
نچلے حصے کے ساتھ tokenId
کی قیمت پر منتقل کیا جائے گا۔ (higher tokenId price) * (lower tokenId's id) / (higher tokenId's id)
.
اس استحصال کے چند تقاضے ہیں:
- ایک سے زیادہ
ERC721
ایک ہی معاہدے سے دونوں میں سے کسی ایک پر اجازت دی جائے گی۔ERC721
ایک ہی مالک کی طرف سے پراکسی۔ - میں سے ایک کے لیے آرڈر کھولیں۔
ERC721
s یہ سب سے کم نہیں ہے۔tokenId
جن کی اجازت ہے۔ - آرڈر پر جزوی بھرنے کی اجازت ہے۔
مکمل طور پر جزوی کے امکان کو دور کرنے کے لئے ERC721
بھرتا ہے، کو الگ کرنے پر غور کریں۔ amount
اور tokenId
دلائل چاہے دلائل الگ ہوں یا نہیں، اس رویے کے بارے میں صارفین کو متنبہ کرنے اور مستقبل میں اس طرز سے بچنے کے لیے اسے دستاویز کرنے پر بھی غور کریں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 59 ھیںچو.
[M03] غیر دستاویزی اعشاریہ مفروضے۔
۔ LimitOrderProtocol
معاہدہ وراثت میں ملتا ہے۔ ChainlinkCalculator
کے ذریعے معاہدہ OrderMixin
معاہدہ یہ معاہدہ چین لنک اوریکلز کے استعمال کو قابل بنانے کے لیے دو افعال کو ظاہر کرتا ہے۔ predicates چیک اور کی تلاش بنانے والے کی رقم/لینے والے کی رقم.
تاہم، معاہدہ اعشاریوں کی تعداد کے بارے میں غیر دستاویزی مفروضے کرتا ہے جس میں Chainlink oracles کو رپورٹ کرنا چاہیے، نیز اعشاریوں کی تعداد جو فنکشن پیرامیٹرز میں ہونی چاہیے۔ بعض حالات میں، یہ غیر متوقع طرز عمل کا باعث بن سکتا ہے، بشمول اثاثوں کی غلط قیمتوں کا تعین اور فنڈز کا غیر ارادی نقصان۔
مزید خاص طور پر، پورے معاہدے کے دوران مضمر مفروضہ یہ ہے کہ Chainlink اوریکلز 18 اعشاریہ درستگی کے ساتھ رپورٹ کریں گے۔ تاہم، نہیں تمام Chainlink اوریکلز اعشاریہ کے اس نمبر کے ساتھ رپورٹ کریں۔ درحقیقت، اگر اوریکل ایک ٹوکن جوڑے کی اطلاع دیتا ہے جو کرنسی کے لحاظ سے ہے (مثال کے طور پر USD)، تو اس میں صرف 8 اعشاریہ درستگی ہوگی۔ چونکہ اس پر کوئی پابندی نہیں ہے۔ جس اوریکلز کا استعمال کیا جا سکتا ہے، اعشاریہ کی تعداد کے بارے میں مضمر مفروضے نہیں کیے جانے چاہئیں جن کے ساتھ وہ رپورٹ کریں گے۔
متعلقہ طور پر، ایک واضح مفروضہ ہے کہ amount
کے لئے پیرامیٹر ChainlinkCalculator
فنکشنز 18 اعشاریہ کا استعمال کریں گے، ساتھ میں گمراہ کن واضح اعلان کے ساتھ کہ singlePrice
تقریب Calculates price of token relative to ETH scaled by 1e18
. حقیقت میں، یہاں تک کہ ایک اوریکل کے ساتھ کرتا 18 اعشاریہ کے ساتھ رپورٹ، کی واپسی کی قیمت singlePrice
فنکشن کو اعشاریہ کی تعداد سے پیمانہ کیا جائے گا۔ amount
پیرامیٹر، جو ضروری نہیں کہ 18 اعشاریہ ہو۔
اسی طرح، doublePrice
فنکشن فرض کرتا ہے کہ دو Chainlink اوریکلز اعشاریوں کی ایک ہی تعداد کے ساتھ رپورٹ کریں گے، جس کی وجہ سے فنکشن کا نتیجہ توقعات سے ہٹ جائے گا۔
اعشاریہ کی تعداد کے بارے میں واضح طور پر مفروضوں کو دستاویز کرنے پر غور کریں جن کے پیرامیٹرز اور واپسی کی قدریں ہونی چاہئیں۔ مزید برآں، یا تو محدود حسابات پر غور کریں جو ان مفروضوں کو توڑنے والے اوریکلز پر منحصر ہیں، یا متعلقہ حسابات اعشاریوں کی اصل تعداد کو مدنظر رکھتے ہیں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 75 ھیںچو.
کم شدت
[L01] مستقل طور پر واضح طور پر اعلان نہیں کیا گیا ہے۔
کوڈ بیس میں غیر واضح معنی کے ساتھ لغوی اقدار کے استعمال ہونے کے چند واقعات ہیں۔ مثال کے طور پر:
- میں
OrderMixin
معاہدہ،_remaining
میپنگ لفظی طور پر اوورلوڈ ہے (جیسا کہ مسئلہ میں بیان کیا گیا ہے۔ میپنگ کی سیمنٹک اوورلوڈنگ) جزوی طور پر بھرے آرڈر کے لیے باقی ماندہ اثاثوں کی مقدار کا پتہ لگانے کے لیے طور پر اگر آرڈر مکمل طور پر بھرا ہوا ہے۔ خاص طور پر،0
اس کا مطلب ہے کہ کسی آرڈر سے وابستہ کوئی بھرتیاں نہیں کی گئی ہیں،1
اس کا مطلب ہے کہ ایک آرڈر اب بھرا نہیں جا سکتا، اور اس سے بڑی کوئی بھی چیز1
اس کا مطلب ہے کہ آرڈر کے ساتھ وابستہ ایک باقی رقم ہے جو ممکنہ طور پر بھری جا سکتی ہے۔ - میں
ChainlinkCalculator
معاہدہ، لفظی قدر1e18
میں استعمال ہوتا ہےsinglePrice
تقریب.
کوڈ کی پڑھنے کی اہلیت کو بہتر بنانے اور ری فیکٹرنگ کو آسان بنانے کے لیے، ہر جادوئی نمبر کے لیے ایک مستقل کی وضاحت کرنے پر غور کریں، اسے ایک واضح اور خود وضاحتی نام دیں۔ پیچیدہ اقدار کے لیے، ایک ان لائن تبصرہ شامل کرنے پر غور کریں جس میں بتایا جائے کہ ان کا حساب کیسے لگایا گیا یا انہیں کیوں منتخب کیا گیا۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 75 ھیںچو اور درخواست # 76 ھیںچو.
[L02] بدنیتی پر مبنی جماعتیں قابل اجازت احکامات پر عمل درآمد کو روک سکتی ہیں۔
۔ OrderMixin
معاہدہ بنانے والے صارفین کو جمع کرانے کی اجازت دیتا ہے۔ قابل اجازت احکامات تاکہ منظوریوں کے لیے علیحدہ لین دین کرنے کی بجائے ان کو ایک ہی لین دین میں انجام دیا جا سکے۔ اس کے علاوہ، آرڈر لینے والے کر سکتے ہیں اپنا اجازت نامہ جمع کروائیں۔ اسی مقصد کے لیے آرڈر بھرنے کے دوران۔
تاہم، کیونکہ بنانے والے کا اجازت نامہ اندر موجود ہے۔ حکم، بنانے والے اور لینے والے دونوں کے اجازت نامے اس وقت تک قابل رسائی ہوں گے جب کہ آرڈر فل ٹرانزیکشن میمپول میں ہو۔ اس سے کسی بھی بدنیتی پر مبنی صارف کے لیے یہ ممکن ہو جائے گا کہ وہ ان پرمٹس کو لے کر متعلقہ اثاثہ جات کے معاہدوں پر ان پر عمل درآمد کرتے ہوئے فل ٹرانزیکشن کو آگے بڑھائے۔ کیونکہ ان اجازت ناموں میں اے nonce
دوہرے اخراجات کے حملے کو روکنے کے لیے، وہی اجازت نامہ استعمال کرنے کی کوشش کے نتیجے میں آرڈر کا فل ٹرانزیکشن ناکام ہو جائے گا جو ابھی فرنٹ رن کے دوران استعمال ہوا تھا۔
اگرچہ کوئی حفاظتی خطرہ نہیں ہے، اور بنانے والا ایک نیا آرڈر بنا سکتا ہے اور لین دین کو پہلے سے منظور کر سکتا ہے، لیکن یہ حملہ یقینی طور پر قابل اجازت آرڈرز کے استعمال کو متاثر کر سکتا ہے۔ درحقیقت، ایک حوصلہ افزا حملہ آور بلاک کر سکتا ہے۔ تمام اس حملے کے ساتھ قابل اجازت احکامات۔ توثیق کرنے پر غور کریں کہ آیا پرمٹ پہلے ہی جمع کرایا گیا تھا، یا اگر الاؤنس کافی ہے، آرڈر بھرنے کے دوران۔ آرڈر کمپوزیشن کے دوران صارفین کو اس ممکنہ حملے کے بارے میں بتانے پر بھی غور کریں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
ہمارے پاس پہلے بھی منظوری کی جانچ پڑتال تھی لیکن صرف ناکام منظوریوں پر واپس لوٹنے کے لیے اجازت کے بہاؤ کو آسان بنانے کا فیصلہ کیا۔ ہم اس مسئلے کے بارے میں سازوں کو مطلع کرنے کے طریقوں کے بارے میں سوچیں گے۔
[L03] ڈپلیکیٹ کوڈ
کوڈ بیس کے اندر ڈپلیکیٹ کوڈ کی مثالیں موجود ہیں۔ کوڈ کو ڈپلیکیٹ کرنے سے بعد میں ترقیاتی لائف سائیکل میں مسائل پیدا ہو سکتے ہیں اور اس سے پراجیکٹ کو غلطیوں کا سامنا کرنا پڑ سکتا ہے۔ اس طرح کی غلطیاں نادانستہ طور پر متعارف کرائی جا سکتی ہیں جب کوڈ کی تمام مثالوں میں فعالیت کی تبدیلیوں کو نقل نہیں کیا جاتا ہے جو ایک جیسے ہونے چاہئیں۔ نقل شدہ کوڈ کی مثالوں میں شامل ہیں:
کوڈ کو ڈپلیکیٹ کرنے کے بجائے، ڈپلیکیٹ کوڈ پر مشتمل صرف ایک معاہدہ یا لائبریری رکھنے پر غور کریں اور جب بھی ڈپلیکیٹ فعالیت کی ضرورت ہو اسے استعمال کریں۔
: اپ ڈیٹ کریں جزوی طور پر طے شدہ درخواست # 60 ھیںچو.
[L04] غلط یا گمراہ کن ٹیسٹ سویٹ
ٹیسٹ سویٹ میں ایسی مثالیں موجود ہیں جہاں ٹیسٹ اپنے متوقع رویے سے ہٹ جاتے ہیں۔ مثال کے طور پر:
- ۔
ChainlinkCalculator
معاہدہ کی طرف سے وراثت ہےOrderMixin
معاہدہ تاہم، ٹیسٹ کے دورانAmountCalculator.arbitraryStaticCall
فنکشن کو کال کرنے کے لیے استعمال کیا جاتا ہے۔ChainlinkCalculator
ایک بیرونی، آزاد معاہدہ کے طور پر معاہدہ۔ اگرچہ نتیجہ متوقع ہے، ٹیسٹ کو کال کرکے سسٹم کے موجودہ ڈیزائن اور متوقع استعمال کیس کے ساتھ رویے کی عکاسی کرنی چاہیے۔ChainlinkCalculator
صوابدیدی جامد کال کا استعمال کیے بغیر براہ راست کام کرتا ہے۔ - اگرچہ پراکسی معاہدے دائرہ کار سے باہر تھے، ہم نے دیکھا کہ ERC721 اثاثوں کے ساتھ پروٹوکول کی جانچ کرتے وقت،
ERC721Proxy
معاہدہ اس میں اثاثوں کو تبدیل کرنے کے لئے استعمال نہیں کیا جاتا ہے۔ ٹیسٹ سوٹ.
چونکہ ٹیسٹ سویٹ خود اس آڈٹ کے دائرہ کار سے باہر ہے، اس لیے براہ کرم ٹیسٹ سویٹ کا مکمل جائزہ لینے پر غور کریں تاکہ یہ یقینی بنایا جا سکے کہ تمام ٹیسٹ پروٹوکول کی وضاحتوں کے مطابق کامیابی سے چل رہے ہیں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 57 ھیںچو, درخواست # 59 ھیںچو، اور درخواست # 61 ھیںچو.
واقعات میں غلطیاں اور کوتاہیاں
پورے کوڈبیس میں، واقعات عام طور پر تب خارج ہوتے ہیں جب معاہدوں میں حساس تبدیلیاں کی جاتی ہیں۔ تاہم، بہت سے واقعات میں انڈیکس شدہ پیرامیٹرز کی کمی ہے اور/یا اہم پیرامیٹرز غائب ہیں۔ مثال کے طور پر:
ایسی حساس کارروائیاں بھی ہیں جن میں واقعات کی کمی ہے، جیسے:
موجودہ واقعات کو مکمل طور پر ترتیب دینے اور نئے پیرامیٹرز کو شامل کرنے پر غور کریں جہاں ان کی کمی ہے۔ اس کے علاوہ، تمام واقعات کو اس طرح مکمل طور پر خارج کرنے پر غور کریں کہ انہیں آف چین سروسز کے ذریعے معاہدے کی حالت کو دوبارہ بنانے کے لیے استعمال کیا جا سکے۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ تاہم، 1 انچ ٹیم نے ایک اضافہ کیا۔ orderRemaining
پیرامیٹر OrderCanceled
میں واقعہ درخواست # 62 ھیںچو.
1 انچ ٹیم کا کہنا ہے:
ہم نے پایا کہ فرنٹ اینڈ کی ضروریات کو پورا کرنے کے لیے ڈیٹا کا صرف ایک محدود ذیلی سیٹ درکار ہے۔ وسیع تجزیہ کی صورت میں، تمام تجویز کردہ فیلڈز ٹریسنگ کے ذریعے دستیاب ہیں۔ کے لیے
OrderRFQMixin
ہم توقع کرتے ہیں کہ مارکیٹ سازوں سے یہ معلوم کرنے کا اپنا نفیس طریقہ بنایا جائے گا کہ کون سے آرڈر منسوخ کیے گئے ہیں۔
[L06] ایونٹ کے اخراج کے دوران اسٹوریج میں تبدیلی
میں NonceManager
معاہدہ، جب NonceIncreased
واقعہ خارج ہوتا ہے، پیغام بھیجنے والوں کی تعداد بھی بڑھ گئی ہے۔.
ایک ساتھ متعدد کارروائیوں کو انجام دینے سے کوڈبیس کے بارے میں استدلال کرنا مشکل ہو سکتا ہے، غلطیوں کا زیادہ خطرہ، اور آپریشنز کو نظر انداز یا غلط فہمی کا باعث بن سکتا ہے۔
کوڈ کی مجموعی نیت، پڑھنے کی اہلیت اور وضاحت کو بہتر بنانے کے لیے، ایونٹ کو خارج کرنے سے پہلے غیر معمولی قدر کو بڑھانے پر غور کریں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 63 ھیںچو.
متضاد ضابطہ کشائی کے طریقے نتائج میں تضادات کا سبب بن سکتے ہیں۔
اس کی تمام توسیع پذیری اور لچک کو سہارا دینے کے لیے، لمیٹ آرڈر پروٹوکول کو معمول کے مطابق ڈائنامک بائٹس ڈیٹا اور بیرونی معاہدوں سے من مانی واپسی کی قدروں سے نمٹنا پڑتا ہے۔ نتیجے کے طور پر، پروٹوکول میں شامل ہے ArgumentsDecoder
لائبریری کو زیادہ مؤثر طریقے سے ڈائنامک بائٹس کی قدروں کو بنیادی ڈیٹا کی اقسام میں تبدیل کرنا ہے۔ تاہم، یہ لائبریری خصوصی طور پر استعمال نہیں کی جاتی ہے، اور بعض صورتوں میں abi.decode
اس کے بجائے استعمال کیا جاتا ہے. اس کے علاوہ، کچھ معاہدے استعمال کر رہے ہیں abi coder v1
جبکہ دوسرے استعمال کر رہے ہیں۔ abi coder v2
. سابقہ کی طرح زیادہ کارکردگی کا مظاہرہ کرتا ہے۔ ArgumentsDecoder
لائبریری، جب کہ بعد میں ضابطہ کشائی کرتے وقت اضافی چیک کرتا ہے۔
ان مختلف ضابطہ کشائی کے طریقوں کے متضاد استعمال کے نتیجے میں کوڈ بیس کی نیت اور حقیقی رویے کے درمیان ٹھیک ٹھیک تضادات پیدا ہو سکتے ہیں۔
مثال کے طور پر، simulateCalls
فنکشن صرف استعمال کرتا ہے۔ ArgumentsDecoder.decodeBool
تقریب اگر simulateCalls
فنکشن کا استعمال ان کالوں کو چیک کرنے کے لیے کیا جاتا ہے جو کسی آرڈر کے پیش گوئی والے حصے میں کی جائیں گی، پھر اس کے نتائج اس سے ہٹ سکتے ہیں جو حقیقت میں پیش آنے والے حالات کا جائزہ لینے کے وقت ہوتا ہے، کیونکہ مختلف ضابطہ کشائی کے طریقے استعمال کیے جاتے ہیں۔
لہذا، مثال کے طور پر، اگر کوئی پیشین گوئی بیرونی بناتی ہے۔ staticcall
کسی ایسے فنکشن میں جو a واپس کرتا ہے۔ uint256
توقع کے بجائے ایک سے زیادہ قدر bool
، پھر وہ کال واپس آجائے گی، کیونکہ واپسی کی قدر ہے۔ کے ساتھ ڈی کوڈ کیا گیا۔ abi coder v2
کی abi.decode
جو ایسی اقدار کو قبول نہیں کرے گا۔ bool
. تاہم، اگر بالکل اسی کال کے ساتھ کیا جاتا ہے simulateCalls
، پھریہ صرف کے طور پر نشان زد کیا جائے گا true
، کیونکہ decodeBool
صفر سے بڑی کسی بھی قدر کو مانتا ہے۔ true
.
بنانے کے لئے simulateCalls
فنکشن اصل پریڈیکیٹ کالز کے رویے کی مکمل عکاسی کرتا ہے، اسے استعمال کرنے کے لیے تبدیل کرنے پر غور کریں۔ abi.decode
.
: اپ ڈیٹ کریں میں فکسڈ درخواست # 82 ھیںچو.
[L08] ان پٹ کی توثیق کی کمی
۔ fillOrderToWithPermit
اور fillOrderTo
کے افعال OrderMixin
معاہدہ، کے ساتھ ساتھ fillOrderRFQToWithPermit
اور fillOrderRFQTo
کے افعال OrderRFQMixin
معاہدہ، کی توثیق نہیں کرتے target
ایڈریس پیرامیٹر
اس سے صارف کے لیے نادانستہ طور پر زیرو ایڈریس پاس کرنا ممکن ہو جاتا ہے اور اس کے نتیجے میں، ان اثاثوں کو لاک اپ کر دیا جاتا ہے جن کا مقصد آرڈر بھرنے کے بعد وصول کرنا ہوتا ہے۔
اس بات کو یقینی بنانے کے لیے کہ صارفین غلطی سے اپنے فنڈز کو لاک نہ کر دیں، اس کی توثیق کرنے پر غور کریں۔ target
ایڈریس حوالہ کردہ فنکشنز میں صفر ایڈریس کے برابر نہیں ہے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 78 ھیںچو.
[L09] کم یونٹ ٹیسٹ کوریج
پورے پروجیکٹ کے لیے یونٹ ٹیسٹ کی کوریج تقریباً 75% ہے، کچھ معاہدوں کی کوریج خاص طور پر کم ہے۔
کوڈ کی توثیق کرنے کے لیے یونٹ ٹیسٹ کی اہمیت کو مدنظر رکھتے ہوئے اور نئے فیچرز کو ری فیکٹرنگ اور تیار کرتے وقت ریگریشنز کو روکنے کے لیے، ہم یونٹ ٹیسٹ کی کوریج کو کم از کم 95% تک بڑھانے کی حوصلہ افزائی کرتے ہیں، اور اس میں ایج کیسز بھی شامل ہیں جو غیر امکانی حالات کا بھی احاطہ کرتے ہیں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔
[L10] گمراہ کن یا نامکمل ان لائن دستاویزات
پورے کوڈبیس کے دوران، گمراہ کن اور/یا نامکمل ان لائن دستاویزات کی چند مثالوں کی نشاندہی کی گئی تھی اور انہیں درست کیا جانا چاہیے۔
گمراہ کن ان لائن دستاویزات کی مثالیں درج ذیل ہیں:
- میں
ChainlinkCalculator
معاہدہ،singlePrice
افعال نیٹ اسپیک@notice
ٹیگ کہتا ہے کہCalculates price of token relative to ETH scaled by 1e18
، لیکن حقیقت میں، اس کا نتیجہ ہے قیمت ofamount
ٹوکن کی طرف سے سکیل1e18
، جہاں اوریکل ETH کے لحاظ سے رپورٹ نہیں کر سکتا ہے (مثال کے طور پر ETH کو شامل نہ کرنے والے جوڑے کے لیے)۔ - میں
OrderRFQMixin
معاہدہ،invalidatorForOrderRFQ
افعال نیٹ اسپیک@return
ٹیگ گمراہ کن ہے، کیونکہ اقتباس متعلقہ invalidator بٹ کو سیٹ کرنے کے لیے نہیں بھرا گیا ہو گا۔ آرڈر کینسل بھی ہو سکتا ہے۔ - لائنوں پر 147, 165، اور 188 of
OrderMixin.sol
، نیٹ اسپیک@param
ٹیگز غیر گراماتی ہیں۔ - آن لائن 20 of
ERC1155Proxy.sol
،@notice
ٹیگ بتاتا ہے کہ کمپیوٹیڈ ہیش ہیش کرنے کا نتیجہ ہے۔func_733NCGU
فنکشن، جہاں یہ ہونا چاہئےfunc_301JL5R
اس کے بجائے فنکشن.
نامکمل ان لائن دستاویزات کی مثالیں درج ذیل ہیں:
- میں افعال
AmountCalculator
معاہدہ کسی بھی پیرامیٹرز کی وضاحت نہیں کرتا ہے۔ - میں
ChainlinkCalculator
معاہدہ،singlePrice
اورdoublePrice
افعال تمام پیرامیٹرز کی وضاحت نہیں کرتے ہیں۔ - میں
ImmutableOwner
معاہدہ، عوامی متغیر اور ترمیم کنندہ کے پاس کوئی NatSpec نہیں ہے۔ - میں
InteractiveNotificationReceiver
معاہدہ،notifyFillOrder
فنکشن کسی بھی پیرامیٹرز کی وضاحت نہیں کرتا ہے۔ - میں
LimitOrderProtocol
معاہدہ،DOMAIN_SEPARATOR
فنکشن میں کوئی NatSpec نہیں ہے۔ - میں واقعات اور نقشہ جات
NonceManager
کوئی NatSpec نہیں ہے۔ - میں
OrderRFQMixin
معاہدہ ،cancelOrderRFQ*
افعال واپسی کی قدروں کی وضاحت نہیں کرتے ہیں۔ - میں
OrderMixin
معاہدہ، کئی افعال میں مکمل NatSpec کی کمی ہے۔ - آن لائن 168 of
OrderMixin.sol
اور آن لائن 71 ofOrderRFQMixin.sol
، یہ غائب ہے@dev
ٹیگ - میں افعال
PredicateHelper
معاہدہ تمام پیرامیٹرز کی وضاحت نہیں کرتا ہے۔
کوڈ کے ارادوں کا خاکہ پیش کرنے کے لیے صاف ان لائن دستاویزات بنیادی ہیں۔ ان لائن دستاویزات اور نفاذ کے درمیان مماثلت اس بارے میں سنگین غلط فہمیوں کا باعث بن سکتی ہے کہ سسٹم سے کس طرح برتاؤ کی توقع کی جاتی ہے۔ ڈویلپرز، صارفین اور آڈیٹرز کے لیے یکساں الجھنوں سے بچنے کے لیے ان غلطیوں کو ٹھیک کرنے پر غور کریں۔
: اپ ڈیٹ کریں جزوی طور پر طے شدہ۔ گمراہ کن دستاویزات میں خطاب کیا گیا۔ درخواست # 75 ھیںچو اور درخواست # 77 ھیںچو.
1 انچ ٹیم کا کہنا ہے:
ہم نے گمراہ کن دستاویزات کو ٹھیک کر دیا ہے۔ دستاویزات کی تکمیل بعد میں کی جائے گی۔
[L11] ہکس کا استعمال کرتے وقت DoS آرڈر ممکن ہے۔
۔ OrderMixin
معاہدہ عام آف چین سویپ آرڈرز کو بھرنے کے لیے فعالیت کو لاگو کرتا ہے جس میں ان کی کامیابی کے لیے شرائط ہو سکتی ہیں۔ آرڈر بھرنے کے دوران، آرڈر کر سکتے ہیں پہلے سے طے شدہ "predicate" حالات کو چیک کریں۔ پھانسی کے ساتھ جاری رکھنے سے پہلے.
تاہم، چونکہ یہ پیش قیاسی حالات کسی بھی صوابدیدی معاہدے کی منطق کو نشانہ بنا سکتے ہیں، ایک بدنیتی پر مبنی بنانے والا لینے والوں کو یہ یقین دلانے کے لیے دھوکہ دے سکتا ہے کہ آرڈر صحیح طریقے سے برتاؤ کرتا ہے اور یہ کہ جب اسے آف چین چیک کیا جاتا ہے تو یہ درست ہے، لیکن پھر اسی آرڈر کو بھرنے کی کوشش کرتے وقت ناکام ہو جاتا ہے۔ آن چین پیشین گوئی کے رویے میں یہ تبدیلی یا تو کچھ متغیر حالت کو سامنے رکھ کر کی جا سکتی ہے جس پر پیشین گوئیاں انحصار کرتی ہیں، بھیجی گئی گیس کی جانچ کر کے یا کال میں کون سے پتے شامل ہیں، یا کسی اور منطق کے ذریعے۔
مزید برآں، اگر بنانے والے نے a کی وضاحت کی ہے۔ تبادلہ کے دوران تعامل، interactionTarget
کامیاب آرڈر بھرنے سے روکنے کے لیے معاہدہ خود کو واپس لے سکتا ہے یا الاؤنس کو منسوخ کر سکتا ہے، بنیادی طور پر وہی نتیجہ نکلتا ہے جیسا کہ بدنیتی پر مبنی پیشین گوئیاں۔
اگرچہ اثاثے خطرے میں نہیں ہوں گے، لیکن موافق آرڈر تلاش کرنے والے صارفین یا بوٹس پر اس قسم کے اسپام آرڈرز کی نشاندہی کرنے کی کوشش کرنے کا بوجھ بڑھ جائے گا جو سطح پر جائز معلوم ہوتے ہیں۔ اس صورت میں کہ وہ اس قسم کے آرڈرز کی نشاندہی کرنے میں ناکام رہتے ہیں تو وہ ضائع ہونے والی گیس کے اخراجات اٹھائیں گے۔ سپیم آرڈرز کی مقدار کو کم کرنے کے لیے، ان ہکس کے لیے دستیاب اہداف کو محدود کرنے پر غور کریں۔ صارفین کو آرڈرز بھرنے کی کوشش کرنے سے پہلے اس امکان کے بارے میں خبردار کرنے پر بھی غور کریں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
ہم اسے اپنے بیک اینڈ پر ہینڈل کرتے ہیں اور ہم اس مسئلے کے بارے میں ممکنہ لینے والوں کو مطلع کرنے کے طریقوں کے بارے میں سوچیں گے۔
[L12] گول کرنا اس کے لیے ناگوار ہو سکتا ہے۔ taker
میں OrderMixin
اور OrderRFQMixin
معاہدے، جب ایک آرڈر بھرا جا رہا ہے اور لینے والا صرف ایک فراہم کرتا ہے makingAmount
or takingAmount
رقم، پروٹوکول سویپ کی ہم منصب رقم کا حساب لگانے کی کوشش کرتا ہے۔
ان حسابات کے ساتھ دو مسائل ہیں، پہلا یہ کہ اعشاریہ کی تعداد کو محدود کرنے کے لیے کوئی دستاویز یا منطق موجود نہیں ہے جسے رقم کے پیرامیٹرز کو استعمال کرنا چاہیے، جس پر ہم نے توجہ دی ہے۔ غیر دستاویزی اعشاریہ مفروضے۔ مسئلہ.
دوسرا مسئلہ یہ ہے کہ ان حسابات کے دوران پروٹوکول بنانے والے کے حق میں ہوتا ہے۔ راؤنڈنگ کا مسئلہ اس وقت بہت زیادہ بڑھ سکتا ہے جب مضمر اعشاریہ کے مفروضوں کو توڑا جاتا ہے، لیکن یہاں تک کہ جب سب کچھ متوقع شرائط میں ہو، راؤنڈنگ چھوٹی، طاق مقداروں کے ساتھ ہو گی۔
لینے والے کو کم از کم رقم بتانے کی اجازت دینے پر غور کریں۔ makerAsset
اثاثہ جو کہ وہ زیادہ سے زیادہ رقم کے ساتھ مل کر وصول کرنے کو تیار ہیں۔ takerAsset
وہ اثاثہ تبدیل کرنے کو تیار ہیں، تاکہ کسی بھی راؤنڈنگ کی قبولیت زیادہ واضح ہو۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
لینے والے کے تحفظ کے لیے حد کی رقم کافی ہونی چاہیے۔
[L13] پیرامیٹرز کی کمی ہونے پر متضاد ترتیب کو سنبھالنا
میں OrderMixin
معاہدہ، fillOrderTo
فنکشن کو اندرونی کال کرتا ہے۔ _callGetMakerAmount
اور _callGetTakerAmount
کام کرتا ہے جب بھی بھرنے کی کوشش کی جاتی ہے اور یا تو makingAmount
یا takingAmount
پیرامیٹرز صفر ہیں، بالترتیب، یا اگر makingAmount
قدر سے بڑی ہے۔ remainingMakerAmount
قدر.
۔ _callGetMakerAmount
اور _callGetTakerAmount
اگر آرڈر کے ساتھ نہیں بنایا گیا تھا تو کالیں تبدیلی کا باعث بنیں گی۔ getMakerAmount
or getTakerAmount
پیرامیٹرز، بالترتیب، اور ایک جزوی بھرنے کو عمل میں لایا جا رہا ہے۔
An ساتھ ساتھ ان لائن تبصرہ _callGetMakerAmount
اور ایک ساتھ ساتھ ان لائن تبصرہ _callGetTakerAmount
دعوی کریں کہ "صرف مکمل بھرنے کی اجازت ہے" اگر آرڈر اس کے ساتھ نہیں بنایا گیا تھا۔ getMakerAmount
or getTakerAmount
پیرامیٹرز
تاہم، ایسے کوڈ راستے ہیں جن کے لیے یہ لاگو نہیں ہوتا، کیونکہ وہ راستے چیک نہیں کرتے length
دونوں کے s getMakerAmount
اور getTakerAmount
پیرامیٹرز
خاص طور پر، جب ایک taker
وضاحت کرتا ہے a takerAmount
کسی ایسے آرڈر کی قدر جس میں صرف ایک ہو۔ getMakerAmount
، جب تک کہ اس کو کال نہ کریں۔ getMakerAmount
سے بڑی رقم واپس کرتا ہے۔ remainingMakerAmount
, ان لائن دستاویزات کے تضاد میں جزوی بھرنے کو عمل میں لایا جا سکتا ہے۔
اس سے ان کوڈ راستوں کی نیت واضح نہیں ہوتی۔ اگر یہ متوقع رویہ ہے، تو ان لائن دستاویزات میں ترمیم کرنے پر غور کریں تاکہ یہ زیادہ واضح ہو۔ اگر یہ غیر ارادی سلوک ہے تو، ہمیشہ دونوں کی لمبائی کی جانچ کرنے پر غور کریں۔ getMakerAmount
اور getTakerAmount
ایک ساتھ پیرامیٹرز تاکہ عمل درآمد ان لائن دستاویزات کے ذریعہ بیان کردہ طرز عمل کو تقویت بخشے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 79 ھیںچو.
[L14] فرسودہ Chainlink کالز کا استعمال
۔ ChainlinkCalculator
معاہدہ کا مقصد Chainlink oracles سے استفسار کرنے کے لیے استعمال کیا جانا ہے۔ یہ ان کو کال کرنے کے ذریعے ایسا کرتا ہے۔ latestTimestamp
اور latestAnswer
طریقوں ، دونوں کو فرسودہ کر دیا گیا ہے۔. درحقیقت، یہ طریقے اب Chainlink ایگریگیٹرز کے API میں موجود نہیں ہیں۔ ورژن تین کے مطابق.
Chainlink oracles کے ساتھ مستقبل میں ممکنہ عدم مطابقتوں سے بچنے کے لیے، استعمال کرنے پر غور کریں۔ latestRoundData
اس کے بجائے طریقہ.
: اپ ڈیٹ کریں میں فکسڈ درخواست # 67 ھیںچو.
نوٹس اور اضافی معلومات
[N01] انٹرفیس درآمد نہیں کرنا
۔ AggregatorInterface
ایسا لگتا ہے کہ انٹرفیس کوڈ کا سب سیٹ ہے جس سے کاپی کیا گیا ہے۔ ChainLink
کا عوامی کوڈ ذخیرہ. مکمل انٹرفیس شامل ہے۔ ChainLink
کا معاہدہ npm پیکج.
جب ممکن ہو، انٹرفیس کی مماثلت اور نتیجے میں ہونے والے مسائل کے امکانات کو کم کرنے کے لیے، بجائے اس کے کہ کسی دوسرے پروجیکٹ کے انٹرفیس کی دوبارہ وضاحت اور/یا دوبارہ لکھیں، اس کے بجائے ان کے آفیشل این پی ایم پیکجز کے ذریعے انسٹال کردہ انٹرفیس استعمال کرنے پر غور کریں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 66 ھیںچو.
[N02] فرسودہ پروجیکٹ انحصار
کی تنصیب کے دوران منصوبے کے انحصار، NPM نے خبردار کیا ہے کہ انسٹال کردہ پیکیجز میں سے ایک، Highlight
، "مستقبل میں مزید تعاون نہیں کیا جائے گا اور نہ ہی سیکیورٹی اپ ڈیٹس موصول ہوں گے"۔
اگرچہ اس بات کا امکان نہیں ہے کہ یہ پیکیج سیکیورٹی کے خطرے کا سبب بن سکتا ہے، اس انحصار کو اپ گریڈ کرنے پر غور کریں جو اس پیکیج کو برقرار رکھنے والے ورژن میں استعمال کرتا ہے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 64 ھیںچو.
[N03] طریقوں کو دیکھنے کے لیے بیرونی کالیں جامد کالز نہیں ہیں۔
زیادہ تر کوڈبیس میں، پروٹوکول واضح طور پر اوپن زیپلن کے ذریعے بیرونی کال کرتا ہے۔ functionStaticCall
ریاستی تبدیلیوں کے امکان کو محدود کرنے کا طریقہ جب وہ یا تو متوقع نہ ہوں یا مطلوبہ نہ ہوں۔ تاہم، میں ChainlinkCalculator
معاہدہ، صرف بیرونی کال کرنے کے ارادے کے باوجود view
چین لنک اوریکلز پر طریقے، بیرونی کالز میں singlePrice
اور doublePrice
افعال واضح کے ذریعے نہیں بنائے جاتے ہیں۔ staticcall
s.
جب کہ ہم نے اس سے پیدا ہونے والے کسی بھی فوری حفاظتی خدشات کی نشاندہی نہیں کی، حملے کی سطح کو کم کرنے، مستقل مزاجی کو بہتر بنانے اور ارادے کو واضح کرنے کے لیے، واضح استعمال کرنے پر غور کریں۔ staticcall
s، تمام بیرونی کالوں کے لیے view
میں افعال ChainlinkCalculator
معاہدہ.
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
ہمارا خیال ہے کہ نحوی پیچیدگی مستقل مزاجی میں بہتری کو ختم کرتی ہے۔
[N04] غلط آرڈرز کے ساتھ جلد ناکام نہیں ہونا
میں OrderMixin
معاہدہ، fillOrderTo
فنکشن خاص حالت کو سنبھالتا ہے جب کوئی آرڈر پہلے پیش نہیں کیا گیا ہو (remainingMakerAmount == 0
)، لیکن یہ واضح طور پر اس حالت کو نہیں سنبھالتا ہے جب آرڈر اب درست نہیں رہتا ہے (remainingMakerAmount == 1
).
مؤخر الذکر منظر نامے میں، فنکشن بالآخر واپس آجائے گا، لیکن گیس کی غیر معمولی مقدار کو جلانے کے بعد۔ ارادے کو واضح کرنے، پڑھنے کی اہلیت کو بڑھانے اور گیس کے استعمال کو کم کرنے کے لیے، فنکشن کے آغاز میں غلط آرڈر کے منظر نامے کو واضح طور پر سنبھالنے پر غور کریں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 68 ھیںچو.
[N05] مددگار معاہدوں کو خلاصہ کے طور پر نشان زد نہیں کیا گیا ہے۔
سالیڈٹی میں کلیدی لفظ abstract
ان معاہدوں کے لیے استعمال کیا جاتا ہے جو یا تو اپنے طور پر فنکشنل کنٹریکٹ نہیں ہیں، یا اس طرح استعمال کرنے کے لیے نہیں ہیں۔ اس کے بجائے، abstract
نظام کے دوسرے معاہدوں سے معاہدے وراثت میں ملتے ہیں تاکہ اسٹینڈ اکیلے فنکشنل کنٹریکٹس بنائیں۔
پورے کوڈبیس میں، مددگار معاہدوں کی مثالیں موجود ہیں جن پر خلاصہ کے طور پر نشان نہیں لگایا گیا ہے، اس حقیقت کے باوجود کہ ان کا مقصد خود سے تعیناتی نہیں ہے۔ مثال کے طور پر، AmountCalculator
, ChainlinkCalculator
, ImmutableOwner
, NonceManager
، اور PredicateHelper
معاہدے تمام افعال کے بنیادی سیٹ پر مشتمل ہوتے ہیں جن کا مقصد وراثتی معاہدوں کے ذریعے استعمال کیا جانا ہے۔
مددگار معاہدوں کو بطور نشان زد کرنے پر غور کریں۔ abstract
واضح طور پر اس بات کی نشاندہی کرنے کے لیے کہ انہیں مکمل طور پر ان معاہدوں میں فعالیت شامل کرنے کے لیے ڈیزائن کیا گیا ہے جو انھیں وراثت میں ملے ہیں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
ان مددگاروں کو الگ سے تعینات کیا جا سکتا ہے۔ وہ صرف گیس کی بچت کے لیے وراثت میں ملے ہیں۔
[N06] غیر متضاد فنکشن آرڈرنگ
پورے کوڈ بیس میں، فنکشن آرڈرنگ عام طور پر اس کی پیروی کرتی ہے۔ سالیڈیٹی اسٹائل گائیڈ میں تجویز کردہ آرڈر، کونسا: constructor
, fallback
, external
, public
, internal
, private
.
تاہم، میں OrderMixin
معاہدہ، public
checkPredicate
فنکشن اسٹائل گائیڈ سے انحراف کرتا ہے، کو دو حصوں میں تقسیم کرتا ہے۔ external
کام کرتا ہے.
پروجیکٹ کی مجموعی قابلیت کو بہتر بنانے کے لیے، پورے کوڈبیس میں فنکشن آرڈرنگ کو معیاری بنانے پر غور کریں، جیسا کہ سولیڈیٹی اسٹائل گائیڈ نے تجویز کیا ہے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 69 ھیںچو.
[N07] متضاد آرڈر فل فلو
۔ OrderMixin
اور RFQOrderMixin
معاہدے دونوں دستخط شدہ آرڈرز کی بھرائی کو سنبھالتے ہیں، لیکن دونوں معاہدوں کے درمیان عمومی آرڈر کا بہاؤ متضاد ہے۔
OrderMixin
کی fillOrderTo
فنکشن اس عام بہاؤ (سیڈو کوڈ) کی پیروی کرتا ہے:
if ((takingAmount == 0) == (makingAmount == 0))
else if (takingAmount == 0)
else (handle makingAmount == 0) THEN swapTokens
جبکہ RFQOrderMixin
مشابہ ہے۔ fillOrderRFQTo
فنکشن اس بہاؤ کی پیروی کرتا ہے (سیڈو کوڈ):
if (takingAmount == 0 && makingAmount == 0)
else if (takingAmount == 0)
else if (makingAmount == 0)
else revert THEN swapTokens
دستاویزات سے کوئی بصیرت نہیں ہے کہ ان دو افعال میں سے ہر ایک میں پہلا مشروط کیوں مختلف ہے، یا کیوں takingAmount
اور makingAmount
مؤخر الذکر فعل میں دونوں صفر نہیں ہو سکتے۔ اس کے علاوہ، معاملہ جہاں دونوں ایک makingAmount
اور ایک takingAmount
کے بارے میں استدلال کرنا بہت آسان ہے۔ fillOrderRFQTo
فنکشن، کیونکہ یہ فائنل میں واضح طور پر سنبھالا جاتا ہے۔ else
بلاک.
ارادے کو واضح کرنے اور کوڈ کی مجموعی پڑھنے کی اہلیت کو بڑھانے کے لیے، یا تو ان دونوں معاہدوں میں عمومی ترتیب کے بہاؤ کو معیاری بنانے پر غور کریں، یا واضح طور پر اس بات کی دستاویز کریں کہ اختلافات کیوں موجود ہیں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
یہ حد کے آرڈرز میں اپنی مرضی کے مطابق قیمتوں کا تعین کرنے کے افعال کی وجہ سے ہے۔ چونکہ
getMakerAmount
سے ممکنہ طور پر کافی مختلف ہو سکتے ہیں۔getTakerAmount
، ہم نے سوچا کہ لینے والے کے لیے پہلے سے طے شدہ آپشن نہ بنانا بہتر ہے کیونکہ یہ ممکنہ طور پر ان معاملات میں الجھ جائے گا جب وہ حاصل کرنے والے مختلف ہوں گے۔
[N08] خرابی کے پیغامات متضاد فارمیٹ یا گمراہ کن ہیں۔
پورے کوڈ بیس میں، require
اور revert
خرابی کے پیغامات، جن کا مقصد صارفین کو ان مخصوص حالات کے بارے میں مطلع کرنا ہوتا ہے جس کی وجہ سے ٹرانزیکشن ناکام ہو جاتی ہے، ان کو متضاد طور پر فارمیٹ کیا گیا تھا۔
مثال کے طور پر، خطوط پر غلطی کے پیغامات میں سے ہر ایک 85 کا OrderMixin.sol
, 16 کا ERC721ProxySafe.sol
، اور 26 کا Permitable.sol
ایک مختلف انداز استعمال کریں.
مزید برآں، کچھ خرابی کے پیغامات گمراہ کن ہیں:
خرابی کے پیغامات کا مقصد صارفین کو ناکام حالات کے بارے میں مطلع کرنا ہے، اس لیے انہیں کافی معلومات فراہم کرنی چاہیے تاکہ سسٹم کے ساتھ تعامل کے لیے مناسب اصلاحات کی جا سکیں۔ غیر معلوماتی غلطی کے پیغامات صارف کے مجموعی تجربے کو بہت زیادہ نقصان پہنچاتے ہیں، اس طرح سسٹم کا معیار گرتا ہے۔ مزید یہ کہ، متضاد طور پر فارمیٹ شدہ غلطی کے پیغامات غیر ضروری الجھن پیدا کر سکتے ہیں۔ لہذا، ہر ایک کو یقینی بنانے کے لیے پورے کوڈ بیس کا جائزہ لینے پر غور کریں۔ require
اور revert
بیان میں ایک غلطی کا پیغام ہے جو مستقل طور پر فارمیٹ، درست، معلوماتی، اور صارف دوست ہے۔
: اپ ڈیٹ کریں جزوی طور پر طے شدہ درخواست # 81 ھیںچو.
[N09] نامزد واپسی متغیرات کا متضاد استعمال
میں نامزد واپسی متغیرات کا متضاد استعمال ہے۔ OrderMixin
معاہدہ کچھ افعال نامزد متغیرات واپس کریں۔، دوسروں کو واضح اقدار واپس کریں۔، اور دوسرے ایک نامزد واپسی متغیر کا اعلان کریں لیکن اسے اوور رائڈ کریں۔ واپسی کے واضح بیان کے ساتھ۔
تمام نام شدہ واپسی متغیرات کو ہٹا کر، واضح طور پر انہیں مقامی متغیر قرار دے کر، اور جہاں مناسب ہو ضروری واپسی کے بیانات شامل کر کے پورے کوڈبیس میں اقدار کی واپسی کے لیے ایک مستقل نقطہ نظر کو اپنانے پر غور کریں۔ اس سے کوڈ کی واضحیت اور پڑھنے کی اہلیت دونوں میں بہتری آئے گی، اور یہ مستقبل کے کوڈ ریفیکٹرز کے دوران رجعت کو کم کرنے میں بھی مدد کر سکتا ہے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 73 ھیںچو.
[N10] آرڈر کا ہیش کیلکولیشن API کے لیے کھلا نہیں ہے۔
۔ external
افعال remaining
, remainingRaw
اور remainingsRaw
سب کامیاب آپریشن کے لیے آرڈر ہیش کی توقع کرتے ہیں۔
تاہم، مددگار فنکشن _hash
، جو آرڈر کی ہیش واپس کرتا ہے، ہے private
مرئیت اس کا مطلب ہے کہ صارفین کو آرڈر کی ہیش حاصل کرنے کے لیے آرڈرز کے کچھ حصے اور ڈومین سٹرنگز کو دستی طور پر پیک کرنا ہوگا۔
آرڈر ہیش کا حساب لگاتے وقت غلطیوں کے امکان سے بچنے کے لیے اور صارفین کو آرڈر کی متعلقہ ہیش بنانے کا طریقہ فراہم کرنے کے لیے، اس کی مرئیت کو بڑھانے پر غور کریں۔ _hash
فنکشن کے لیے public
اور نام کو ری فیکٹر کرنا hash
باقی کوڈ کے ساتھ مطابقت رکھنے کے لیے۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 74 ھیںچو.
[N11] میپنگ کی سیمنٹک اوورلوڈنگ
۔ _remaining
میں نقشہ سازی OrderMixin
آرڈرز کی حیثیت اور ان آرڈرز کے لیے دستیاب اثاثوں کی بقیہ رقم کو ٹریک کرنے کے لیے کنٹریکٹ کو لفظی طور پر اوورلوڈ کیا جاتا ہے۔
وہ تین حالتیں جو اس پر لگ سکتی ہیں وہ ہیں:
0
: آرڈر ہیش ابھی تک نہیں دیکھا گیا ہے۔1
: آرڈر یا تو منسوخ یا مکمل طور پر بھر دیا گیا ہے۔- کوئی
uint
سے بڑا1
: باقیmakerAmount
آرڈر پلس پر بھرنے کے لیے دستیاب ہے۔1
.
اس سیمنٹک اوور لوڈنگ کے لیے اس قدر کو لپیٹنے اور کھولنے کی ضرورت ہوتی ہے۔ lookup
, cancellation
, initialization
، اور storage
.
سیمنٹک اوورلوڈنگ اور اسے فعال کرنے کے لیے ضروری منطق غلطی کا شکار ہو سکتی ہے اور کوڈ بیس کو سمجھنا اور اس کے بارے میں استدلال کرنا مشکل بنا سکتا ہے، یہ کوڈ کی مستقبل کی اپ ڈیٹس میں رجعت کا دروازہ بھی کھول سکتا ہے۔
کوڈ کی پڑھنے کی اہلیت کو بہتر بنانے کے لیے، الگ میپنگ میں آرڈرز کی تکمیل کی حالت کو ٹریک کرنے پر غور کریں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ کی ٹیم نے حوالہ دیا کہ طے کرنے سے گیس کی قیمتوں میں اضافہ ہوگا۔ fillOrder
تقریب.
[N12] اجازت نامے کے ساتھ آرڈرز صوابدیدی معاہدوں پر کال کرنے کی اجازت دیتے ہیں۔
۔ OrderMixin
معاہدہ وراثت میں ملتا ہے۔ Permitable
ایسے اثاثوں سے بھرنے کے لیے سنگل ٹرانزیکشن آرڈر کی اجازت دینے کا معاہدہ permit
الاؤنسز میں ترمیم کرنے کا مطالبہ
تاہم، کو کال کرتا ہے۔ Permitable
کنٹریکٹ اس بات کی توثیق نہ کریں کہ آیا ہدف ایک قابل اجازت اثاثہ ہے اور نہ ہی اگر یہ ایک اثاثہ بھی ہے، جو ایک بدنیتی پر مبنی صارف کو صوابدیدی معاہدے کا پتہ پاس کرنے کی اجازت دے سکتا ہے جو آرڈر بھرنے سے پہلے ایک اور کال کو انجام دے سکتا ہے۔
حالانکہ معاہدہ ہے۔ دوبارہ داخلہ کے خلاف محفوظ، حملے کی سطح کو کم کرنے اور عملدرآمد کے دوران بیرونی معاہدوں کی کال کو روکنے کی ہمیشہ سفارش کی جاتی ہے۔ پرمٹ میں شامل اثاثہ کو آرڈر میں شامل اثاثوں تک یا پروٹوکول کے لیے اثاثوں کی وائٹ لسٹ تک محدود کرنے پر غور کریں۔
: اپ ڈیٹ کریں طے شدہ نہیں۔ 1 انچ ٹیم کا کہنا ہے:
OrderMixin
اصل ٹوکن کے بارے میں اصل میں معلومات نہیں ہے جیسا کہmakerAsset
اورtakerAsset
بعض اوقات پراکسی یا دوسرے انٹرمیڈیٹ معاہدے ہوتے ہیں اور اصل ٹوکن کے بارے میں معلومات کو کچھ صوابدیدی بائٹس میں محفوظ کیا جاتا ہے۔ لہذا کون سا اثاثہ محدود کرنے کا کوئی قابل عمل طریقہ نہیں ہے۔permit
پر بلایا جاتا ہے.
[N13] solhint
کبھی بھی دوبارہ فعال نہیں کیا جاتا ہے۔
پورے کوڈ بیس میں، ایک جوڑے موجود ہیں۔ solhint-disable
بیانات، خاص طور پر وہ آن لائن 23 اور آن لائن 41 of RevertReasonParser.sol
کے ساتھ ختم نہیں کر رہے ہیں solhint-enable
.
صراحت کے حق میں اور غیر فعال کرتے وقت ہر ممکن حد تک محدود ہونا solhint
، استعمال کرنے پر غور کریں solhint-disable-line
or solhint-disable-next-line
اس کے بجائے، لائن کی طرح 16 اسی فائل کی.
: اپ ڈیٹ کریں میں فکسڈ درخواست # 72 ھیںچو.
[N14] ٹائپ کی غلطیاں
کوڈ بیس میں درج ذیل ٹائپ کی غلطیاں ہیں:
اس کے علاوہ پراجیکٹ کے README
(اس آڈٹ کے دائرہ کار سے باہر) میں درج ذیل ٹائپ کی غلطیاں ہیں:
کوڈ پڑھنے کی اہلیت کو بہتر بنانے کے لیے ان ٹائپوز کو درست کرنے پر غور کریں۔
: اپ ڈیٹ کریں میں فکسڈ درخواست # 71 ھیںچو اور درخواست # 77 ھیںچو.
[N15] کا استعمال uint
بجائے uint256
صراحت کے حق میں، تمام مثالیں uint
کے طور پر اعلان کیا جانا چاہئے uint256
. خاص طور پر، ان میں for
لائنوں پر loops 98 اور 119 of OrderMixin.sol
اور لائنیں 16 اور 30 of PredicateHelper.sol
.
: اپ ڈیٹ کریں میں فکسڈ درخواست # 70 ھیںچو.
نتیجہ
3 زیادہ شدت کے مسائل پائے گئے۔ بہترین طریقوں پر عمل کرنے اور ممکنہ حملے کی سطح کو کم کرنے کے لیے کچھ تبدیلیاں تجویز کی گئیں۔
- &
- 7
- ہمارے بارے میں
- تک رسائی حاصل
- کے مطابق
- اکاؤنٹ
- کے پار
- ایکٹ
- اعمال
- ایڈیشنل
- پتہ
- فائدہ
- تمام
- اجازت دے رہا ہے
- پہلے ہی
- اگرچہ
- مقدار
- تجزیہ
- اے پی آئی
- نقطہ نظر
- دلائل
- ارد گرد
- اثاثے
- اثاثے
- آڈٹ
- پیچھے کے آخر میں
- شروع
- کیا جا رہا ہے
- BEST
- بہترین طریقوں
- بٹ
- خودکار صارف دکھا ئیں
- تعمیر
- فون
- پرواہ
- مقدمات
- کیونکہ
- chainlink
- تبدیل
- جانچ پڑتال
- چیک
- کوڈ
- پیچیدہ
- شرط
- الجھن
- تعمیر
- پر مشتمل ہے
- کنٹریکٹ
- معاہدے
- اصلاحات
- اخراجات
- سکتا ہے
- جوڑے
- خالق
- کرنسی
- موجودہ
- اعداد و شمار
- نمٹنے کے
- سروس کا انکار
- تعینات
- ڈیزائن
- ڈویلپرز
- ترقی
- DID
- مختلف
- مختلف
- ڈومین
- دوگنا
- متحرک
- ابتدائی
- ایج
- کی حوصلہ افزائی
- خاص طور پر
- ETH
- واقعہ
- واقعات
- سب کچھ
- مثال کے طور پر
- ایکسچینج
- توقع
- تجربہ
- دھماکہ
- خصوصیات
- قطعات
- آخر
- پہلا
- درست کریں
- لچک
- بہاؤ
- پر عمل کریں
- ملا
- مکمل
- تقریب
- فنڈز
- مستقبل
- کھیل ہی کھیل میں
- گیس
- جنرل
- دے
- عظیم
- رہنمائی
- ہینڈلنگ
- ہیش
- ہیشنگ
- ہونے
- مدد
- ہائی
- انتہائی
- کس طرح
- HTTPS
- ہائبرڈ
- شناخت
- اثر
- پر عملدرآمد
- اہم
- درآمد
- شامل
- سمیت
- اضافہ
- اضافہ
- معلومات
- معلومات
- انفراسٹرکچر
- بصیرت
- ارادے
- دلچسپی
- انٹرفیس
- ملوث
- مسائل
- IT
- بڑے
- بڑے
- قیادت
- معروف
- لائبریری
- لمیٹڈ
- لائن
- لیکویڈیٹی
- فہرست
- فہرستیں
- مقامی
- دیکھا
- تلاش
- اہم
- میکر
- بنانا
- مارکیٹ
- میمپول
- عکس
- ماڈل
- سب سے زیادہ
- سب سے زیادہ مقبول
- یعنی
- نئی خصوصیات
- غیر فنگبل
- غیر فنگبل ٹوکن
- سرکاری
- کھول
- آپریشنز
- اختیار
- اوریکل
- حکم
- احکامات
- دیگر
- مالک
- پاٹرن
- مقبول
- حال (-)
- کی روک تھام
- قیمت
- قیمتوں کا تعین
- نجی
- عمل
- منصوبے
- منصوبوں
- تحفظ
- پروٹوکول
- فراہم
- فراہم کرتا ہے
- پراکسی
- عوامی
- شائع
- خرید
- معیار
- بلند
- حقیقت
- کو کم
- انحصار
- رپورٹ
- رپورٹیں
- ذخیرہ
- ضروریات
- باقی
- نتائج کی نمائش
- واپسی
- کا جائزہ لینے کے
- رسک
- چکر
- رن
- sdk
- سیکورٹی
- سروسز
- مقرر
- مشترکہ
- حصص
- منتقل
- اسی طرح
- سادہ
- چھوٹے
- ہوشیار
- سمارٹ معاہدہ
- So
- استحکام
- سپیم سے
- خاص طور پر
- خرچ کرنا۔
- کمرشل
- شروع کریں
- حالت
- بیان
- امریکہ
- درجہ
- ذخیرہ
- سٹائل
- جمع کرائی
- کامیابی
- کامیاب
- کامیابی کے ساتھ
- حمایت
- تائید
- سطح
- سوئچ کریں
- کے نظام
- ہدف
- ٹیسٹ
- ٹیسٹنگ
- ٹیسٹ
- کے ذریعے
- بھر میں
- وقت
- مل کر
- ٹوکن
- ٹوکن
- ٹریک
- ٹریکنگ
- ٹرانزیکشن
- بھروسہ رکھو
- منفرد
- تازہ ترین معلومات
- us
- استعمالی
- امریکی ڈالر
- USDT
- صارفین
- کی افادیت
- قیمت
- لنک
- کی نمائش
- انتظار
- کیا
- وائٹسٹسٹ
- کے اندر
- بغیر
- کام
- قابل
- صفر