ডিসেম্বর 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 ইঞ্চি দল এবং অবকাঠামোর উপর নির্ভরতা বৃদ্ধি৷
অতিরিক্তভাবে, লিমিট অর্ডার প্রোটোকল এমন ফাংশন প্রদান করে যা চেইনলিংক ওরাকল থেকে মূল্য পুনরুদ্ধার করার জন্য। আমরা সেই ওরাকলগুলিকে সৎ, অ্যাক্সেসযোগ্য এবং সঠিকভাবে কাজ করে বলে ধরে নিয়েছি।
অধিকন্তু, একটি আদেশের নমনীয়তার কারণে, বহিরাগত চুক্তির সাথে যোগাযোগের বেশ কয়েকটি পয়েন্ট রয়েছে যা বৈধ নয়। এর মানে হল যে একটি দূষিত ব্যবহারকারী এই ধরনের কলগুলির অপব্যবহার করতে পারে এবং অর্ডার পূরণের সময় ক্রিয়া সম্পাদন করার জন্য দূষিত চুক্তির সাথে পূর্বাভাস, সম্পদ বা ওরাকলের ছদ্মবেশ ধারণ করতে পারে। যদিও প্রকল্পটি পুনঃপ্রবেশের বিরুদ্ধে কিছু এলাকায় সুরক্ষিত, এই ধরনের ভেক্টর পরিষেবা আক্রমণ বা অনাক্ত স্প্যাম আদেশ অস্বীকার করতে পারে। 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
পরামিতি সংজ্ঞায়িত করা হয়। এটা পারে কাটা দ্য 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
মান নির্দিষ্ট করা হয়. দূষিত নির্মাতা একইভাবে একটি ফিল অর্ডারের জন্য অপেক্ষা করবে যা একটি নির্দিষ্ট করে takingAmount
মেমপুলে দেখানোর মান। তারা লেনদেন অগ্রসর হবে এবং জোর করে makingAmount
দ্বারা ফেরত মান _callGetMakerAmount
ফাংশন উভয়ের চেয়ে বেশি হতে হবে remainingMakerAmount
এবং thresholdAmount
. তারাও সেট করবে takingAmount
দ্বারা মান ফেরত _callGetTakerAmount
পরিমাণ হতে takerAsset
উপর অনুমোদিত সম্পদ LimitOrderProtocol
গ্রহণকারী দ্বারা। যখন গ্রহণকারীর লেনদেন হয়ে যাবে, তখন তা হবে ছোট করা makingAmount
মান এবং তারপর পুনরায় গণনা করুন takingAmount
মান এই পুনঃগণনা কম হওয়ার নিশ্চয়তা নেই, এবং এই ক্ষেত্রে সমস্ত গ্রহণকারীকে নিষ্কাশন করবে takerAsset
যে তারা চুক্তিতে অনুমতি দিয়েছে। এই কোড-পথে, thresholdAmount
মান হয় নিশ্চিত করা যে makingAmount
খুব কম নয়, তাই সব গ্রহণকারীর গ্রহণ takerAsset
সম্পদ আনচেক করা হয়। হারানো তহবিল পরিমাণ দ্বারা আবদ্ধ হয় takerAsset
ব্যবহারকারী অনুমোদিত সম্পদ LimitOrderProtocol
চুক্তি।
এই শোষণগুলি আংশিক আদেশ ছাড়া সম্ভব নয় এবং আরও নির্দিষ্টভাবে, দূষিত সহ আংশিক আদেশ getMakerAmount
এবং getTakerAmount
বাস্তবায়ন
এর মূল ইস্যু thresholdAmount
মান পরীক্ষা হল যে এটি শুধুমাত্র অদলবদলের এক দিককে কভার করে, কিন্তু অন্য দিকটি সামনের দৌড়ের মাধ্যমে ম্যানিপুলেট করা যেতে পারে। কোন নিশ্চয়তা নেই যে মূল্য গ্রহণকারী মূলত প্রস্তাবিত মূল্য অপরিবর্তিত থাকে। অপসারণ বিবেচনা করুন makingAmount
উভয় কোড-পাথ থেকে ছেঁটে ফেলা এবং প্রত্যাবর্তন করা যদি অর্ডারটি অনুরোধের মতো বড় পূরণকে সমর্থন করতে না পারে। এটি করার মাধ্যমে, দ thresholdAmount
অদলবদলের অন্য দিকে যথেষ্ট সীমাবদ্ধ করতে এবং অপ্রত্যাশিত আচরণ এড়াতে ব্যবহার করা যেতে পারে, এমনকি দূষিত আদেশেও।
আপডেট: মধ্যে স্থির অনুরোধ #83 টান.
মাঝারি তীব্রতা
[M01] স্ট্যাটিক আর্গুমেন্ট গতিশীল আর্গুমেন্ট পরে পাস
মধ্যে OrderMixin
চুক্তি, getTakerAmount
এবং getMakerAmount
বাইট ক্ষেত্র এর জন্য আর্গুমেন্ট হিসাবে ব্যবহার করা হয় _callGetTakerAmount
এবং _callGetMakerAmount
ফাংশন এই কলগুলি অন্য দিকের উপর ভিত্তি করে অদলবদলের এক দিক গণনা করার একটি উপায় প্রদান করে এবং তারা ব্যবহারকারীদের আংশিকভাবে অর্ডার পূরণ করতে দেয়।
সার্জারির getTakerAmount
/getMakerAmount
ক্ষেত্রগুলি ডায়নামিক ভেরিয়েবল এবং এর সামনে প্যাক করা হয় takerAmount
এবং makerAmount
মান মান _callGetTakerAmount
এবং _callGetMakerAmount
ফাংশন একটি দূষিত নির্মাতার পক্ষে প্রত্যাশার চেয়ে বেশি ডেটা সরবরাহ করা সম্ভব getTakerAmount
এবংgetMakerAmount
ক্ষেত্র ধাক্কা takerAmount
এবং makerAmount
বাইট অতীত যেখানে তারা পরবর্তী ফাংশন ডিকোড করা হচ্ছে অনুমান করা হয়. এটি মেকারকে পাস করা ইন টেকার বা মেকার পরিমাণকে সম্পূর্ণ বাইট দ্বারা ডানদিকে স্থানান্তর করতে দেয় এবং এমনকি যদি অতিরিক্ত 32 বাইট ডেটা সরবরাহ করা হয় তবে সেগুলি সম্পূর্ণরূপে প্রতিস্থাপন করতে পারে।
ব্যবহারকারীদের ইতিমধ্যে ম্যানুয়ালি পর্যালোচনা করতে হবে getTakerAmount
এবং getMakerAmount
ক্রমানুসারে ক্ষেত্র, কিন্তু এই কৌশলটি স্পট করা কঠিন। এছাড়াও লক্ষণীয়, এই আক্রমণটি এমনকি অভ্যন্তরীণভাবে বিশ্বস্তদের ক্ষেত্রেও প্রযোজ্য getMakerAmount
এবং getTakerAmount
ফাংশন বেশিরভাগ আক্রমণের জন্য, একটি যুক্তিসঙ্গত থ্রেশহোল্ড পরিমাণ প্রদান তহবিলের ক্ষতি রোধ করবে।
এটি প্রতিরোধ করার জন্য, গতিশীল আর্গুমেন্টের আগে স্ট্যাটিক আর্গুমেন্ট এনকোড করার কথা বিবেচনা করুন যাতে ডায়নামিক আর্গুমেন্টগুলিকে স্ট্যাটিক আর্গুমেন্টগুলি নিয়ন্ত্রণ করার একটি পদ্ধতি দেওয়া না হয়।
আপডেট: অনির্ধারিত. 1 ইঞ্চি দল বলেছে:
আমরা গেটার যাচাইকরণের সাথে অতিরিক্ত যত্ন নেব। আমরা আমাদের sdk-এ গেটারদের স্যানিটি ভ্যালিডেশন প্রয়োগ করার চেষ্টা করব যা সম্ভাব্য দূষিত অর্ডার ফিল্টার করতে সাহায্য করবে।
[M02] ERC721 অর্ডার ম্যানিপুলেট করা যেতে পারে
এর মাধ্যমে শুধু ERC20 এর চেয়ে বেশি বিনিময় করা সম্ভব 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
একই চুক্তির গুলি দ্বারা হস্তান্তর করার অনুমতি দেওয়া হয়েছে ERC721Proxy
চুক্তি এবং পৃথক সীমা আদেশ তাদের তালিকা.
যদি সীমা আদেশও প্রদান করে getMakerAmount
এবং getTakerAmount
ক্ষেত্র, এটি আংশিকভাবে এই পূরণ করা সম্ভব হবে ERC721
আদেশ অর্ডার এর পর থেকে amount
ক্ষেত্র আসলে অনুরূপ tokenId
, একটি দূষিত ব্যবহারকারী একটি আংশিক পূরণ করতে পারেন ERC721
উচ্চতর টোকেনআইডি সহ, যার ফলে একটি makingAmount
/takingAmount
একজন ERC721
যে একটি নিম্ন অনুরূপ হতে পারে tokenId
. ফলাফল হল ERC721
নিম্নের সাথে tokenId
এর মূল্যে স্থানান্তর করা হবে (higher tokenId price) * (lower tokenId's id) / (higher tokenId's id)
.
এই শোষণের কয়েকটি প্রয়োজনীয়তা রয়েছে:
- বহু
ERC721
s একই চুক্তি থেকে উভয়ের উপর অনুমোদিত হতে হবেERC721
একক মালিক দ্বারা প্রক্সি। - একটির জন্য ওপেন অর্ডার
ERC721
s যে সর্বনিম্ন নয়tokenId
অনুমোদিত বেশী. - অর্ডারে আংশিক ভরাট অনুমোদিত।
সম্পূর্ণরূপে আংশিক সম্ভাবনা অপসারণ ERC721
পূরণ করে, আলাদা করার কথা বিবেচনা করুন amount
এবং tokenId
যুক্তি. যুক্তিগুলি আলাদা করা হোক বা না হোক, ব্যবহারকারীদের এই আচরণ সম্পর্কে সতর্ক করতে এবং ভবিষ্যতে এই প্যাটার্ন এড়াতে এটির নথিভুক্ত করার কথাও বিবেচনা করুন৷
আপডেট: মধ্যে স্থির অনুরোধ #59 টান.
[M03] অনথিভুক্ত দশমিক অনুমান
সার্জারির LimitOrderProtocol
চুক্তি উত্তরাধিকারসূত্রে পায় ChainlinkCalculator
মাধ্যমে চুক্তি OrderMixin
চুক্তি এই চুক্তির সময় চেইনলিংক ওরাকলের ব্যবহার সক্ষম করতে দুটি ফাংশন প্রকাশ করে predicates চেক এবং এর সন্ধান প্রস্তুতকারকের পরিমাণ/গ্রহণকারীর পরিমাণ.
যাইহোক, চুক্তিটি চেইনলিংক ওরাকলের রিপোর্ট করা উচিত এমন দশমিকের সংখ্যা, সেইসাথে ফাংশন প্যারামিটারে থাকা উচিত এমন দশমিকের সংখ্যা সম্পর্কে অনথিভুক্ত অনুমান করে। কিছু পরিস্থিতিতে, এটি অপ্রত্যাশিত আচরণের দিকে নিয়ে যেতে পারে, যার মধ্যে সম্পদের ভুল মূল্য নির্ধারণ এবং তহবিলের অনিচ্ছাকৃত ক্ষতি অন্তর্ভুক্ত।
আরও নির্দিষ্টভাবে, পুরো চুক্তি জুড়ে অন্তর্নিহিত অনুমান হল যে চেইনলিংক ওরাকলগুলি 18 দশমিক সূক্ষ্মতার সাথে রিপোর্ট করবে। যাইহোক, না সমস্ত চেইনলিংক ওরাকল দশমিকের এই সংখ্যা দিয়ে রিপোর্ট করুন। প্রকৃতপক্ষে, যদি ওরাকল একটি মুদ্রার পরিপ্রেক্ষিতে একটি টোকেন জোড়ার প্রতিবেদন করে (উদাহরণস্বরূপ, USD), তবে এটির কেবলমাত্র 8 দশমিকের নির্ভুলতা থাকবে। যেহেতু কোন সীমাবদ্ধতা নেই যে ওরাকল ব্যবহার করা যেতে পারে, তারা যে দশমিক সংখ্যার সাথে রিপোর্ট করবে সে সম্পর্কে অন্তর্নিহিত অনুমান করা উচিত নয়।
সম্পর্কিতভাবে, একটি অন্তর্নিহিত অনুমান আছে যে amount
জন্য পরামিতি ChainlinkCalculator
ফাংশন 18 দশমিক ব্যবহার করবে, একত্রে বিভ্রান্তিকর স্পষ্ট ঘোষণার সাথে যে singlePrice
ক্রিয়া Calculates price of token relative to ETH scaled by 1e18
. বাস্তবে, এমনকি একটি ওরাকল সঙ্গে যে না 18 দশমিক সঙ্গে রিপোর্ট, এর রিটার্ন মান singlePrice
ফাংশন এর দশমিক সংখ্যা দ্বারা স্কেল করা হবে amount
প্যারামিটার, যা অগত্যা 18 দশমিক নাও হতে পারে।
একইভাবে, দী doublePrice
ফাংশন অনুমান করে যে দুটি চেইনলিংক ওরাকল একই সংখ্যক দশমিকের সাথে রিপোর্ট করবে, যার ফলে ফাংশনের ফলাফল প্রত্যাশা থেকে বিচ্যুত হবে।
প্যারামিটার এবং রিটার্ন মান পরিপ্রেক্ষিতে হওয়া উচিত এমন দশমিকের সংখ্যা সম্পর্কিত অনুমানগুলি স্পষ্টভাবে নথিভুক্ত করার কথা বিবেচনা করুন। তদ্ব্যতীত, হয় সীমিত গণনাগুলি বিবেচনা করুন যা সেই অনুমানগুলিকে ভঙ্গকারী ওরাকলের উপর নির্ভর করে, অথবা প্রাসঙ্গিক গণনাগুলি দশমিকের প্রকৃত সংখ্যাকে বিবেচনায় নিয়ে থাকে।
আপডেট: মধ্যে স্থির অনুরোধ #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 টান.
[L05] ইভেন্টগুলিতে ত্রুটি এবং বাদ দেওয়া
কোডবেস জুড়ে, চুক্তিতে সংবেদনশীল পরিবর্তন করা হলে ইভেন্টগুলি সাধারণত নির্গত হয়। যাইহোক, অনেক ইভেন্টে ইনডেক্সড প্যারামিটার নেই এবং/অথবা গুরুত্বপূর্ণ প্যারামিটার নেই। উদাহরণ স্বরূপ:
এছাড়াও সংবেদনশীল ক্রিয়াগুলি রয়েছে যেগুলির ইভেন্টগুলির অভাব রয়েছে, যেমন:
বিদ্যমান ইভেন্টগুলিকে আরও সম্পূর্ণরূপে সূচীকরণ এবং যেখানে তাদের অভাব রয়েছে সেখানে নতুন প্যারামিটার যোগ করার কথা বিবেচনা করুন। এছাড়াও, সমস্ত ইভেন্টকে এমনভাবে সম্পূর্ণরূপে নির্গত করার কথা বিবেচনা করুন যাতে সেগুলি অফ-চেইন পরিষেবাগুলির দ্বারা চুক্তির অবস্থা পুনর্নির্মাণ করতে ব্যবহার করা যেতে পারে।
আপডেট: অনির্ধারিত. তবে, 1 ইঞ্চি দল একটি যোগ করেছে orderRemaining
প্যারামিটার থেকে OrderCanceled
ইভেন্ট ইন অনুরোধ #62 টান.
1 ইঞ্চি দলটি বলে:
আমরা দেখেছি যে ফ্রন্টএন্ডের চাহিদা মেটানোর জন্য ডেটার শুধুমাত্র একটি সীমিত উপসেট প্রয়োজন। বিস্তৃত বিশ্লেষণের ক্ষেত্রে, সমস্ত প্রস্তাবিত ক্ষেত্র ট্রেসিংয়ের মাধ্যমে উপলব্ধ। জন্য
OrderRFQMixin
আমরা আশা করি বাজার নির্মাতারা কি অর্ডার বাতিল করা হয়েছে তা ট্র্যাক করার জন্য তাদের নিজস্ব পরিশীলিত উপায় তৈরি করবে।
[L06] ইভেন্ট নির্গমনের সময় স্টোরেজ পরিবর্তন
মধ্যে NonceManager
চুক্তি, যখন NonceIncreased
ঘটনা নির্গত হয়, বার্তা প্রেরকের ননসও বৃদ্ধি পায়.
একই সাথে একাধিক ক্রিয়াকলাপ সম্পাদন করা কোডবেসকে যুক্তিযুক্ত করে তুলতে পারে, আরও ত্রুটির প্রবণতা তৈরি করতে পারে এবং অপারেশনগুলিকে উপেক্ষা বা ভুল বোঝার কারণ হতে পারে।
কোডের সামগ্রিক উদ্দেশ্যপ্রণোদিততা, পঠনযোগ্যতা এবং স্পষ্টতা উন্নত করতে, ইভেন্টটি নির্গত করার আগে ননস মান বাড়ানোর কথা বিবেচনা করুন।
আপডেট: মধ্যে স্থির অনুরোধ #63 টান.
[L07] অসামঞ্জস্যপূর্ণ ডিকোডিং পদ্ধতি ফলাফলের অসঙ্গতি সৃষ্টি করতে পারে
এর সমস্ত এক্সটেনসিবিলিটি এবং নমনীয়তা সমর্থন করার জন্য, লিমিট অর্ডার প্রোটোকলকে নিয়মিতভাবে ডায়নামিক বাইট ডেটা এবং বাহ্যিক চুক্তি থেকে নির্বিচারে রিটার্ন মানগুলির সাথে মোকাবিলা করতে হবে। ফলস্বরূপ, প্রোটোকল একটি অন্তর্ভুক্ত ArgumentsDecoder
লাইব্রেরি আরও দক্ষতার সাথে গতিশীল বাইট মানগুলিকে মৌলিক ডেটা প্রকারে রূপান্তর করে। যাইহোক, এই লাইব্রেরি একচেটিয়াভাবে ব্যবহার করা হয় না, এবং কিছু ক্ষেত্রে abi.decode
পরিবর্তে ব্যবহার করা হয়। উপরন্তু, কিছু চুক্তি ব্যবহার করা হয় abi coder v1
যখন অন্যরা ব্যবহার করছে abi coder v2
. প্রাক্তন আরো অনুরূপ সঞ্চালন ArgumentsDecoder
লাইব্রেরি, যেখানে পরবর্তীটি ডিকোড করার সময় অতিরিক্ত চেক করে।
এই বিভিন্ন ডিকোডিং পদ্ধতির অসামঞ্জস্যপূর্ণ ব্যবহারের ফলে কোডবেসের উদ্দেশ্য এবং বাস্তব আচরণের মধ্যে সূক্ষ্ম অসঙ্গতি দেখা দিতে পারে।
উদাহরণস্বরূপ, দী simulateCalls
ফাংশন শুধুমাত্র ব্যবহার করে ArgumentsDecoder.decodeBool
ফাংশন যদি simulateCalls
ফাংশনটি একটি অর্ডারের পূর্বনির্ধারিত অংশে করা কলগুলি পরীক্ষা করতে ব্যবহৃত হয়, তারপরে পূর্বনির্ধারিত অবস্থার মূল্যায়ন করার সময় এর ফলাফলগুলি আসলে যা ঘটে তা থেকে বিচ্যুত হতে পারে, কারণ বিভিন্ন ডিকোডিং পদ্ধতি নিযুক্ত করা হয়।
সুতরাং, উদাহরণস্বরূপ, যদি একটি predicate একটি বহিরাগত করে তোলে staticcall
কিছু ফাংশনে যা একটি রিটার্ন করে 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
ট্যাগ বিভ্রান্তিকর, কারণ উদ্ধৃতিটি সংশ্লিষ্ট অবৈধ বিট সেট করার জন্য পূরণ করা হয়নি। আদেশটি বাতিলও হতে পারে। - লাইনে 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" শর্তগুলি পরীক্ষা করুন মৃত্যুদন্ড চালিয়ে যাওয়ার আগে।
যাইহোক, যেহেতু এই ভবিষ্যদ্বাণী শর্তগুলি যেকোন স্বেচ্ছাচারী চুক্তির যুক্তিকে টার্গেট করতে পারে, একজন দূষিত নির্মাতা ক্রেতাদের এই বিশ্বাসে প্রতারণা করতে পারে যে একটি অর্ডার সঠিকভাবে আচরণ করে এবং এটি চেক অফ-চেইন চেক করার সময় এটি বৈধ, কিন্তু তারপর একই আদেশ পূরণ করার চেষ্টা করার সময় ব্যর্থ হয় অন-চেইন ভবিষ্যদ্বাণী আচরণের এই পরিবর্তনটি হয় এমন কিছু পরিবর্তনশীল অবস্থাকে সামনে রেখে করা যেতে পারে যার উপর ভবিষ্যদ্বাণী নির্ভর করে, প্রেরিত গ্যাস পরীক্ষা করে বা এমনকি কোন ঠিকানাগুলি কলের সাথে জড়িত, বা অন্য কোন যুক্তি দ্বারা।
অধিকন্তু, যদি নির্মাতা একটি সংজ্ঞায়িত করে অদলবদলের সময় মিথস্ক্রিয়া, দ্য 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
একটি নির্দিষ্ট করে takerAmount
একটি অর্ডারের মান যার শুধুমাত্র একটি আছে getMakerAmount
, যদি না যে কল getMakerAmount
এর থেকে বড় পরিমাণ ফেরত দেয় remainingMakerAmount
, ইনলাইন ডকুমেন্টেশনের বিপরীতে একটি আংশিক পূরণ করা যেতে পারে।
এটি সেই কোড পাথগুলির ইচ্ছাকৃততাকে অস্পষ্ট করে দেয়। যদি এটি প্রত্যাশিত আচরণ হয়, তাহলে ইনলাইন ডকুমেন্টেশন পরিবর্তন করার কথা বিবেচনা করুন যাতে এটি আরও স্পষ্ট হয়। যদি এটি অনিচ্ছাকৃত আচরণ হয় তবে সর্বদা উভয়ের দৈর্ঘ্য পরীক্ষা করার কথা বিবেচনা করুন getMakerAmount
এবং getTakerAmount
পরামিতি একই সাথে যাতে বাস্তবায়ন ইনলাইন ডকুমেন্টেশন দ্বারা বর্ণিত আচরণকে শক্তিশালী করে।
আপডেট: মধ্যে স্থির অনুরোধ #79 টান.
[L14] বন্ধ করা চেইনলিংক কল ব্যবহার করা
সার্জারির ChainlinkCalculator
চুক্তিটি চেইনলিংক ওরাকলকে জিজ্ঞাসা করার জন্য ব্যবহার করার উদ্দেশ্যে। এটা তাদের কল করার মাধ্যমে তাই করে latestTimestamp
এবং latestAnswer
পদ্ধতি, উভয়ই অবমূল্যায়ন করা হয়েছে. প্রকৃতপক্ষে, চেইনলিংক অ্যাগ্রিগেটরগুলির API-এ পদ্ধতিগুলি আর উপস্থিত নেই৷ সংস্করণ তিন হিসাবে.
চেইনলিংক ওরাকলের সাথে সম্ভাব্য ভবিষ্যতের অসঙ্গতি এড়াতে, ব্যবহার করার কথা বিবেচনা করুন latestRoundData
পরিবর্তে পদ্ধতি।
আপডেট: মধ্যে স্থির অনুরোধ #67 টান.
নোট এবং অতিরিক্ত তথ্য
[N01] ইন্টারফেস আমদানি করা হচ্ছে না
সার্জারির AggregatorInterface
ইন্টারফেস থেকে অনুলিপি করা কোডের একটি উপসেট বলে মনে হচ্ছে ChainLink
এর পাবলিক কোড সংগ্রহস্থল. সম্পূর্ণ ইন্টারফেস অন্তর্ভুক্ত করা হয় ChainLink
এর চুক্তি npm প্যাকেজ.
যখন সম্ভব, ইন্টারফেসের অমিল এবং ফলাফলের সমস্যাগুলির সম্ভাবনা কমাতে, অন্য প্রকল্পের ইন্টারফেসগুলিকে পুনরায় সংজ্ঞায়িত এবং/অথবা পুনরায় লেখার পরিবর্তে, পরিবর্তে তাদের অফিসিয়াল npm প্যাকেজের মাধ্যমে ইনস্টল করা ইন্টারফেসগুলি ব্যবহার করার কথা বিবেচনা করুন।
আপডেট: মধ্যে স্থির অনুরোধ #66 টান.
[N02] অবচিত প্রকল্প নির্ভরতা
ইনস্টলেশনের সময় প্রকল্পের নির্ভরতা, NPM সতর্ক করে যে প্যাকেজগুলির মধ্যে একটি ইনস্টল করা হয়েছে, Highlight
, "আর সমর্থিত হবে না বা ভবিষ্যতে নিরাপত্তা আপডেট গ্রহণ করবে না"।
যদিও এটি অসম্ভাব্য যে এই প্যাকেজটি নিরাপত্তা ঝুঁকির কারণ হতে পারে, এই প্যাকেজটি ব্যবহার করে এমন নির্ভরতা একটি রক্ষণাবেক্ষণ করা সংস্করণে আপগ্রেড করার কথা বিবেচনা করুন।
আপডেট: মধ্যে স্থির অনুরোধ #64 টান.
[N03] পদ্ধতি দেখার জন্য বাহ্যিক কলগুলি স্ট্যাটিককল নয়
বেশিরভাগ কোডবেস জুড়ে, প্রোটোকল স্পষ্টভাবে OpenZeppelin এর মাধ্যমে বাহ্যিক কল করে 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
- সম্পর্কে
- প্রবেশ
- অনুযায়ী
- হিসাব
- দিয়ে
- আইন
- স্টক
- অতিরিক্ত
- ঠিকানা
- সুবিধা
- সব
- অনুমতি
- ইতিমধ্যে
- যদিও
- পরিমাণে
- বিশ্লেষণ
- API
- অভিগমন
- আর্গুমেন্ট
- কাছাকাছি
- সম্পদ
- সম্পদ
- নিরীক্ষা
- ব্যাক-এন্ড
- শুরু
- হচ্ছে
- সর্বোত্তম
- সেরা অভ্যাস
- বিট
- বট
- নির্মাণ করা
- কল
- যত্ন
- মামলা
- কারণ
- chainlink
- পরিবর্তন
- পরীক্ষণ
- চেক
- কোড
- জটিল
- শর্ত
- বিশৃঙ্খলা
- নির্মাণ
- ধারণ
- চুক্তি
- চুক্তি
- সংশোধণী
- খরচ
- পারা
- দম্পতি
- স্রষ্টা
- মুদ্রা
- বর্তমান
- উপাত্ত
- লেনদেন
- সেবা দিতে অস্বীকার করা
- মোতায়েন
- নকশা
- ডেভেলপারদের
- উন্নয়ন
- DID
- ভিন্ন
- বিভিন্ন
- ডোমেইন
- ডবল
- প্রগতিশীল
- গোড়ার দিকে
- প্রান্ত
- উত্সাহিত করা
- বিশেষত
- ETH
- ঘটনা
- ঘটনাবলী
- সব
- উদাহরণ
- বিনিময়
- প্রত্যাশিত
- অভিজ্ঞতা
- কাজে লাগান
- বৈশিষ্ট্য
- ক্ষেত্রসমূহ
- পরিশেষে
- প্রথম
- ঠিক করা
- নমনীয়তা
- প্রবাহ
- অনুসরণ করা
- পাওয়া
- সম্পূর্ণ
- ক্রিয়া
- তহবিল
- ভবিষ্যৎ
- খেলা
- গ্যাস
- সাধারণ
- দান
- মহান
- কৌশল
- হ্যান্ডলিং
- কাটা
- হ্যাশ
- জমিদারি
- সাহায্য
- উচ্চ
- অত্যন্ত
- কিভাবে
- HTTPS দ্বারা
- অকুলীন
- সনাক্ত করা
- প্রভাব
- বাস্তবায়ন
- গুরুত্বপূর্ণ
- আমদানি
- অন্তর্ভুক্ত
- সুদ্ধ
- বৃদ্ধি
- বর্ধিত
- তথ্য
- তথ্য
- পরিকাঠামো
- অর্ন্তদৃষ্টি
- অভিপ্রায়
- স্বার্থ
- ইন্টারফেস
- জড়িত
- সমস্যা
- IT
- বড়
- বৃহত্তর
- নেতৃত্ব
- নেতৃত্ব
- লাইব্রেরি
- সীমিত
- লাইন
- তারল্য
- তালিকাভুক্ত
- পাখি
- স্থানীয়
- তাকিয়ে
- খুঁজে দেখো
- মুখ্য
- সৃষ্টিকর্তা
- মেকিং
- বাজার
- মেমপুল
- আয়না
- মডেল
- সেতু
- সবচেয়ে জনপ্রিয়
- যথা
- নতুন বৈশিষ্ট
- অ fungible
- অ-ছত্রাকযোগ্য টোকেন
- কর্মকর্তা
- খোলা
- অপারেশনস
- পছন্দ
- আকাশবাণী
- ক্রম
- আদেশ
- অন্যান্য
- মালিক
- প্যাটার্ন
- জনপ্রিয়
- বর্তমান
- নিরোধক
- মূল্য
- মূল্য
- ব্যক্তিগত
- প্রক্রিয়া
- প্রকল্প
- প্রকল্প
- রক্ষা
- প্রোটোকল
- প্রদান
- উপলব্ধ
- প্রক্সি
- প্রকাশ্য
- প্রকাশ করা
- ক্রয়
- গুণ
- বৃদ্ধি
- বাস্তবতা
- হ্রাস করা
- নির্ভরতা
- রিপোর্ট
- প্রতিবেদন
- সংগ্রহস্থলের
- আবশ্যকতা
- বিশ্রাম
- ফলাফল
- আয়
- এখানে ক্লিক করুন
- ঝুঁকি
- চক্রের
- চালান
- SDK
- নিরাপত্তা
- সেবা
- সেট
- ভাগ
- শেয়ারগুলি
- পরিবর্তন
- অনুরূপ
- সহজ
- ছোট
- স্মার্ট
- স্মার্ট চুক্তি
- So
- ঘনত্ব
- স্প্যাম
- বিশেষভাবে
- খরচ
- অকুস্থল
- শুরু
- রাষ্ট্র
- বিবৃতি
- যুক্তরাষ্ট্র
- অবস্থা
- স্টোরেজ
- শৈলী
- পেশ
- সাফল্য
- সফল
- সফলভাবে
- সমর্থন
- সমর্থিত
- পৃষ্ঠতল
- সুইচ
- পদ্ধতি
- লক্ষ্য
- পরীক্ষা
- পরীক্ষামূলক
- পরীক্ষা
- দ্বারা
- সর্বত্র
- সময়
- একসঙ্গে
- টোকেন
- টোকেন
- পথ
- অনুসরণকরণ
- লেনদেন
- আস্থা
- অনন্য
- আপডেট
- us
- ব্যবহারযোগ্যতা
- আমেরিকান ডলার
- USDT
- ব্যবহারকারী
- উপযোগ
- মূল্য
- চেক
- দৃষ্টিপাত
- অপেক্ষা করুন
- কি
- পরিচ্ছন্ন তালিকা
- মধ্যে
- ছাড়া
- হয়া যাই ?
- মূল্য
- শূন্য