উমা অডিট - পর্যায় 6

ভূমিকা

uma এটি এমন একটি প্ল্যাটফর্ম যা ব্যবহারকারীদের ইথেরিয়াম ব্লকচেইনে আস্থা-নিম্নকৃত আর্থিক চুক্তিতে প্রবেশ করতে দেয়। আমরা আগে অডিট করেছি বিকেন্দ্রীভূত ওরাকল, একটি নির্দিষ্ট আর্থিক চুক্তি টেমপ্লেট, কিছু অ্যাডহক পুল অনুরোধ, চিরস্থায়ী বহুদলীয় টেমপ্লেট, একটি দীর্ঘ ব্যস্ততা উপর বিভিন্ন ক্রমবর্ধমান টান অনুরোধ এবং বীমাকৃত সেতু.

এই অডিটে আমরা একটি নতুন গভর্নেন্স প্রস্তাব চুক্তি পর্যালোচনা করেছি, একাধিক চেইন জুড়ে UMA ইকোসিস্টেমকে প্রসারিত করার একটি প্রক্রিয়া, একটি অফ-চেইন স্পেসিফিকেশন অনুযায়ী ERC721 টোকেন হোল্ডারদের পুরস্কার বিতরণ করার একটি প্রক্রিয়া এবং WETH-কে সমর্থন করার জন্য বীমাকৃত সেতুর একটি আপডেট। আশাবাদ চেইনে।

নিরীক্ষিত প্রতিশ্রুতি হয় 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc এবং সুযোগের মধ্যে নিম্নলিখিত চুক্তিগুলি অন্তর্ভুক্ত রয়েছে:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (পরীক্ষা এবং বহুভুজ চুক্তি ব্যতীত)
• financial-templates/optimistic-rewarder/* (পরীক্ষা চুক্তি ব্যতীত)

আমরা সলিটি ফাইলের পরিবর্তনগুলিও পর্যালোচনা করেছি৷ অনুরোধ 3611 টানুন.

সমস্ত বাহ্যিক কোড এবং চুক্তি নির্ভরতা নথিভুক্ত হিসাবে কাজ করে বলে ধরে নেওয়া হয়েছিল।

সিস্টেমের সংক্ষিপ্ত বিবরণ

বর্তমান Governance চুক্তি রিস্ক ল্যাবস ফাউন্ডেশনকে নতুন প্রশাসনিক কর্মের প্রস্তাব করার অনুমতি দেয় যা UMA টোকেন হোল্ডারদের দ্বারা অনুমোদিত হতে পারে। নতুন Proposer চুক্তিটি প্রস্তাবকের ভূমিকা নেওয়ার উদ্দেশ্যে করা হয়েছে, যে কাউকে নতুন প্রস্তাব দেওয়ার অনুমতি দেয় যতক্ষণ না তারা একটি বন্ড প্রদান করে যা প্রস্তাব ব্যর্থ হলে বলি দেওয়া হবে। প্রস্তাব করার জন্য কোন নির্দিষ্ট প্রণোদনা নেই। অভিপ্রায়টি নিশ্চিত করা যে কেবলমাত্র সেই ক্রিয়াগুলি যা গ্রহণযোগ্য হওয়ার সম্ভাবনা রয়েছে প্রস্তাবিত হবে।

নতুন ক্রস-চেইন প্রক্রিয়া ইথেরিয়াম মেইননেট থেকে অপ্টিমিজম এবং আরবিট্রাম চেইনে গভর্নেন্স প্রস্তাব পাস করার অনুমতি দেয়। এইভাবে, লেয়ার 1-এর UMA গভর্নেন্স মেকানিজম সমর্থিত লেয়ার 2 চেইনে UMA চুক্তিগুলি পরিচালনা করতে ব্যবহার করা যেতে পারে। প্রক্রিয়াটি স্তরগুলির মধ্যে মূল্য অনুরোধ এবং রেজোলিউশনগুলিকে ফরোয়ার্ড করার অনুমতি দেয়, তাই লেয়ার 2 চেইনের আশাবাদী ওরাকলগুলিকে মেইননেট ডেটা যাচাইকরণ প্রক্রিয়া দ্বারা সুরক্ষিত করা যেতে পারে যেভাবে স্তর 1 অপটিমিস্টিক ওরাকল DVM দ্বারা সুরক্ষিত।

এটি লক্ষণীয় যে এই বার্তাগুলি নেটিভ ব্রিজ মেকানিক্স ব্যবহার করে পাঠানো হয়, যার অর্থ তারা প্রাসঙ্গিক স্তর 2 চেইনের বৈশিষ্ট্য দ্বারা সীমাবদ্ধ। বিশেষ করে, লেয়ার 2 থেকে লেয়ার 1 পর্যন্ত বার্তাগুলি সেতুটি ট্রানজিট করতে এক সপ্তাহ বা তার বেশি সময় নিতে পারে। অধিকন্তু, UMA গভর্নেন্স মেকানিজম এমন প্রস্তাবগুলিকে সমর্থন করে যাতে একাধিক আদেশকৃত লেনদেন অন্তর্ভুক্ত থাকে, কিন্তু এটি শুধুমাত্র সেই ক্রমকে সীমিত করে যাতে সেগুলি সেতুতে যোগ করা যেতে পারে। এই লেনদেনের কিছুর জন্য লেয়ার 2-এ ভিন্ন ক্রমে সম্পাদিত হওয়া সম্ভব, বা একেবারেই নয়।

অপটিমিস্টিক রিওয়ার্ডার চুক্তি যে কেউ তাদের অনুরোধ করে তাদের জন্য ERC721 টোকেনগুলি সহজভাবে মিন্ট করে। এটি যেকোনও ব্যক্তিকে যেকোনো টোকেনের সাথে নির্বিচারে ডেটা সংযুক্ত করতে এবং পুরস্কার হিসাবে বিতরণ করার জন্য বিভিন্ন ERC20 টোকেন জমা করার অনুমতি দেয়। নির্বিচারে ডেটার ব্যাখ্যা এবং টোকেন হোল্ডারদের মধ্যে পুরস্কারের প্রত্যাশিত বন্টন একটি অনির্দিষ্ট অফ-চেইন পদ্ধতি ব্যবহার করে নির্ধারিত হয়। যে কেউ একটি দাবি করতে পারে যে একটি নির্দিষ্ট ERC721 টোকেন একটি বন্ড জমা দিতে ইচ্ছুক হলে পুরস্কারের একটি সেট পাওনা। স্ট্যান্ডার্ড অপটিমিস্টিক ওরাকল মেকানিজম অন্য কাউকে দাবির বিরোধ করার অনুমতি দেওয়ার জন্য ব্যবহার করা হয়, যা ডিভিএম দ্বারা সমাধান করা হবে। সময়মত বিতর্কিত নয় এমন দাবিগুলিকে বৈধ বলে ধরে নেওয়া হয় এবং চুক্তি সেই অনুযায়ী পুরস্কার বিতরণ করে। একমাত্র সীমাবদ্ধতা (অ্যাকাউন্টিং সহজ করার জন্য) হল ওরাকল বন্ড টোকেন পুরস্কার টোকেন হিসাবে ব্যবহার করা যাবে না।

শেষ অবধি, PR3611 আশাবাদ টোকেন সেতু জুড়ে WETH-কে পাঠানো এড়াতে বীমাকৃত সেতুর প্রক্রিয়া পরিবর্তন করে, যা সমর্থিত নয়। পরিবর্তে, অপটিমিজম ডিপোজিট বাক্সে জমা করা যেকোন L2 WETH ব্রিজটি ট্রানজিট করার আগে L2 ETH-এ খুলে ফেলা হয়। লেয়ার 1-এ, WETH ব্রিজ পুলে ফরোয়ার্ড করার আগে ETH WETH-এ রূপান্তরিত হয়।

সমালোচনামূলক তীব্রতা

[C01] অবৈধ পুরস্কারের বিরোধ করা যাবে না

একটি পুরষ্কার অনুরোধ বিতর্ক করার সময়, OptimisticRewardBase প্রথম চুক্তি একটি প্রস্তাব ট্রিগার উপরে SkinnyOptimisticOracle এবং তারপর যে প্রস্তাব বিরোধিতা. তবে প্রস্তাব মেয়াদ শেষ হওয়ার সময় নির্ধারণ করে বর্তমান (বিরোধ) সময় থেকে অফসেট হিসাবে, বিরোধের সময় মেয়াদ নির্দিষ্ট করে মূল পুরস্কার অনুরোধের সময় থেকে অফসেট হিসাবে। বেশিরভাগ ক্ষেত্রে, এই অসঙ্গতি ওরাকলকে বিতর্কিত হওয়ার প্রস্তাব সনাক্ত করতে বাধা দেবে, যার মানে বৈধ বিরোধগুলি প্রক্রিয়া করা হবে না এবং অবৈধ পুরস্কারের অনুরোধগুলি গ্রহণ করা হবে।

বিবাদের প্রস্তাবটি সঠিকভাবে উল্লেখ করার জন্য বিবাদ আহ্বান আপডেট করার কথা বিবেচনা করুন।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 9e15557 in PR3690.

[C02] বারবার প্রস্তাবগুলি সমাধান করুন

সার্জারির resolveProposal এর ফাংশন Proposer চুক্তি সহজভাবে যাচাই করে যে ওরাকল সমাধান করেছে, কিন্তু বন্ড বিতরণ করা হয়েছে কিনা তা পরীক্ষা করে না। এর মানে হল একই প্রস্তাব একাধিকবার সমাধান করা যেতে পারে, যার ফলে ডুপ্লিকেট বন্ড পেমেন্ট হয়। বিদ্যমান প্রস্তাবগুলি সমাধান হয়ে গেলে পতাকাঙ্কিত বা মুছে ফেলার কথা বিবেচনা করুন৷

আপডেট: প্রতিশ্রুতি হিসাবে স্থির b152718 in PR3689.

উচ্চ তীব্রতা

কোনটিই নয়।

মাঝারি তীব্রতা

[M01] ভুল ইভেন্ট প্যারামিটার

সার্জারির OptimisticRewarderBase চুক্তি একটি সংজ্ঞায়িত করে Requested ঘটনা যা থেকে নির্গত হয় requestRedemption একটি খালাস অনুরোধ করা হলে ফাংশন. এই ঘটনা নির্গত সংজ্ঞায়িত করা হয় খালাসের মেয়াদ শেষ হওয়ার সময় এর শেষ প্যারামিটার হিসাবে। যাহোক, যখন ঘটনা নির্গত হয়, এর শেষ প্যারামিটারটি ভুলভাবে সেট করা হয়েছে বর্তমান সময়.

একইভাবে Redeemed ঘটনা রেকর্ডটি মুছে ফেলার পরে মেয়াদ শেষ হওয়ার সময় পড়ে, তাই এটি ভুলভাবে শূন্যে সেট করা হবে।

প্রদত্ত যে এই ইভেন্টটি অফ-চেইন গণনা ট্রিগার করতে ব্যবহার করা যেতে পারে, নির্গত মান যথাযথভাবে আপডেট করার কথা বিবেচনা করুন।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির f04eef9 in PR3694.

কম তীব্রতা

[L01] একটি খালাস বিতর্কের পরে ইভেন্ট নির্গমনের অভাব

সার্জারির OptimisticRewarderBase চুক্তি একটি সংজ্ঞায়িত করে Disputed ঘটনা যদি একটি খালাস বিতর্কিত হয় তাহলে এটি ট্রিগার করার উদ্দেশ্যে করা হয়৷ যাইহোক, এই ঘটনা ভিতরে বা বাইরে নির্গত হয় না OptimisticRewarderBase চুক্তি।

সংবেদনশীল পরিবর্তন সঞ্চালিত হওয়ার পরে ইভেন্ট নির্গত বিবেচনা করুন dispute ক্রিয়া, ট্র্যাকিং সহজতর করতে এবং চুক্তির কার্যকলাপ অনুসরণ করে অফ-চেইন ক্লায়েন্টদের অবহিত করতে।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির c275e92 in PR3695.

[L02] অসামঞ্জস্যপূর্ণ পুনঃপ্রবেশ গার্ড

সার্জারির Optimism_ParentMessenger এবং Arbitrum_ParentMessenger চুক্তিগুলি অসামঞ্জস্যপূর্ণভাবে প্রয়োগ করে nonReentrant সংশোধক সব পাবলিক ফাংশন এটি অন্তর্ভুক্ত বিবেচনা করুন.

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 6275c39 in PR3677.

[L03] বিভ্রান্তিকর মন্তব্য

এখানে কিছু বিভ্রান্তিকর মন্তব্য রয়েছে যা আমরা আমাদের পর্যালোচনার সময় চিহ্নিত করেছি:

• ChildMessengerConsumerInterface.sol:
  • লাইন 5 "শিশু মেসেঞ্জার" এর পরিবর্তে "পিতা-মাতার বার্তাবাহক" বলে
• GovernorSpoke.sol:
  • লাইন 49-51 একটি লিঙ্ক Gnosis ফাইল যদিও মন্তব্য বলছে স্নিপেটটি থেকে কপি করা হয়েছে Governor.sol. অতিরিক্তভাবে, স্নিপেটটি একটির সাথে অভিন্ন নয়৷ Governor.sol

আপডেট: প্রতিশ্রুতি হিসাবে স্থির cc350f9 in PR3678.

[L04] অনুপস্থিত আনুষঙ্গিক ডেটা স্ট্যাম্প

একটি মূল্য অনুরোধ করার সময় OracleSpoke চুক্তি, প্রদত্ত আনুষঙ্গিক তথ্য স্ট্যাম্প করা হয় চাইল্ড চেইন শনাক্তকারীর সাথে। তবে hasPrice এবং getPrice মূল্য অনুরোধ সনাক্ত করার সময় ফাংশন আনুষঙ্গিক ডেটা স্ট্যাম্প করে না। এটি কলিং চুক্তিগুলিকে নিজেরাই স্ট্যাম্প প্রয়োগ করতে বাধ্য করে, যা মূল্য অনুরোধ এবং মূল্য পুনরুদ্ধার প্রক্রিয়ার মধ্যে একটি অসঙ্গতি সৃষ্টি করে। মধ্যে স্ট্যাম্প প্রয়োগ বিবেচনা করুন hasPrice এবং getPrice ফাংশন।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির fdb845d in PR3668.

[L05] NatSpec প্যারামিটার অনুপস্থিত

অনেক ফাংশন OptimisticRewarderBase চুক্তি অনুপস্থিত @return তাদের প্রাকৃতিক স্পেসিফিকেশন মন্তব্যে প্যারামিটার। সম্পূর্ণতার জন্য এটি অন্তর্ভুক্ত বিবেচনা করুন.

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 8920f38 in PR3679.

[L06] অবশিষ্ট ভাতা

আশাবাদী ওরাকল আহ্বান করার জন্য, OptimisticRewarderBase চুক্তি এটি একটি টোকেন ভাতা প্রদান করে, তাই এটি বন্ড পেমেন্ট টানতে পারেন. প্রস্তাব ব্যর্থ হলে, পুরষ্কার খালাস বাতিল করা হয়েছে কিন্তু ভাতা রিসেট করা হয় না. অতএব, পরের বার বিবাদের সূত্রপাত না হওয়া পর্যন্ত আশাবাদী ওরাকল একটি অপ্রয়োজনীয় অবশিষ্ট ভাতা বজায় রাখবে। প্রস্তাব ব্যর্থ হলে ভাতা প্রত্যাহার বিবেচনা করুন.

আপডেট: প্রতিশ্রুতি হিসাবে স্থির c2d444b in PR3698.

[L07] অবৈধ ফেরত ঠিকানা

ফেরত L2 ঠিকানা Arbitrum_ParentMessenger আরম্ভ করা হয় চুক্তির মালিকের কাছে, যা L1 গভর্নর হওয়া উচিত। একইভাবে, দ setRefundL2Address একটি মন্তব্য আছে এটা গভর্নর সেট করা উচিত বলে. যাইহোক, সেতুর উপর বার্তা পাস করার সময়, এই মান L2 ব্যবহারকারী হিসাবে সেট করুন, যা আরবিট্রামের ঠিকানা যা টিকিটের সমাধান হওয়ার পরে অতিরিক্ত তহবিল পায়। যেহেতু L1 গভর্নরের ঠিকানা Arbitrum-এ অ্যাক্সেসযোগ্য হবে না, তাই এই ঠিকানায় পাঠানো যেকোনো তহবিল হারিয়ে যাবে।

এটিকে একটি বৈধ L2 ঠিকানায় সেট করার কথা বিবেচনা করুন৷

আপডেট: প্রতিশ্রুতি হিসাবে স্থির b3f2dd1 in PR3687.

[L08] শিশু বার্তাবাহক পরিবর্তন করার প্রক্রিয়া

সার্জারির GovernorSpoke এবং OracleSpoke কন্ট্রাক্ট প্রত্যেকটি কনস্ট্রাক্টরে চাইল্ড মেসেঞ্জারকে ইনিশিয়ালাইজ করে, এটিকে আপডেট করার কোনো ব্যবস্থা ছাড়াই। এর মানে হল যে যখন শিশু বার্তাবাহক পরিবর্তন করা হয়, উভয় স্পোক চুক্তি অপ্রচলিত হয়ে.

যেহেতু স্পোক কন্ট্রাক্ট সম্ভবত মেসেঞ্জারদের চেয়ে বেশি স্থিতিশীল, তাই স্পোকে মেসেঞ্জার আপডেট করার জন্য একটি মেকানিজম অন্তর্ভুক্ত করার কথা বিবেচনা করুন।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 7c9e061 in PR3688.

নোট এবং অতিরিক্ত তথ্য

[N01] বন্ড টোকেন পরিবর্তন করুন

সার্জারির Proposer চুক্তি অন্তর্ভুক্ত একটি প্রক্রিয়া মালিকের প্রস্তাব বন্ডের আকার পরিবর্তন করার জন্য। তারা বন্ড টোকেন পরিবর্তন করতে সক্ষম হবে কিনা তা বিবেচনা করুন। নোট করুন যে বিদ্যমান প্রস্তাবগুলি সমাধান করা হলে সঠিক বন্ড মুদ্রা সনাক্ত করার জন্য এটির একটি প্রক্রিয়া প্রয়োজন।

আপডেট: কোনো সমস্যা নয়। এই সমস্যার জন্য UMA এর বিবৃতি:

N01 প্রস্তাবকারী চুক্তিকে UMA ছাড়া অন্য কিছুতে বন্ড টোকেন পরিবর্তন করতে সক্ষম করার সুপারিশ করে। এই ফাংশনের জন্য $UMA ব্যতীত অন্য কোনো টোকেনকে সমর্থন করার কোনো অভিপ্রায় আমাদের নেই এবং তাই এই সমস্যার জন্য কোনো পরিবর্তন না করা বেছে নিয়েছি। অধিকন্তু, চুক্তি প্রতি একটি একক টোকেন এই যুক্তিটিকে যতটা সম্ভব সহজ রাখে। অবশেষে, যদি একটি পরিবর্তনের প্রয়োজন হয় (উদাহরণস্বরূপ, একটি টোকেন স্থানান্তরের ক্ষেত্রে), আমরা অন্য টোকেনের সাথে একটি নতুন প্রস্তাবক চুক্তি স্থাপন করতে পারি এবং সেটি ব্যবহার করার জন্য সিস্টেমটিকে স্থানান্তর করার প্রস্তাব শুরু করতে পারি।

[N02] অসম্পূর্ণ ইন্টারফেস

সার্জারির ChildMessengerInterface একটি নির্দিষ্ট করে না processMessageFromCrossChainParent ফাংশন, যদিও এটি অভিভাবক বার্তাবাহকদের দ্বারা বিদ্যমান বলে ধরে নেওয়া হয়। সম্পূর্ণতার জন্য এটি অন্তর্ভুক্ত বিবেচনা করুন.

আপডেট: অনির্ধারিত. এই সমস্যার জন্য UMA এর বিবৃতি:

আমরা ইচ্ছাকৃতভাবে এই ইন্টারফেসটিকে অসামঞ্জস্যপূর্ণ রেখেছি কারণ ChildMessengerInterface-এর মধ্যে এটি প্রয়োগ করার ফলে Polygon_ChildMessenger-এর সাথে সামঞ্জস্যতা ভেঙে যায় কারণ অন্যান্য চেইন থেকে বার্তাগুলি প্রক্রিয়া করার জন্য পলিগনের পদ্ধতিতে কিছুটা কাস্টম যুক্তির প্রয়োজন যেখানে একটি অভ্যন্তরীণ পদ্ধতিকে _processMessageFromRoot বলা হয়৷

[N03] ভুল ইন্টারফেস

সার্জারির GovernorSpoke ভুল চুক্তি ব্যবহার করে ChildMessengerConsumerInterface আদর্শ তার বর্ণনা করতে messenger পরিবর্তনশীল ব্যবহার বিবেচনা করুন ChildMessengerInterface পরিবর্তে.

আপডেট: প্রতিশ্রুতি হিসাবে স্থির f31a527 in PR3680.

[N04] স্টোরে টোকেন টানুন

একটি ইন পূর্ববর্তী নিরীক্ষা আমরা এর উদ্দেশ্য নিয়ে প্রশ্ন তুলেছি Store চুক্তি payOracleFeesErc20 ক্রিয়া (ইস্যু L19 এ)। UMA দল ফাংশন রাখা বেছে নেওয়া হয়েছে সম্ভাব্য ভবিষ্যত পরিবর্তনের জন্য ইন্টারফেসকে মানসম্মত করতে। যেহেতু ফাংশনের উদ্দেশ্যটি সম্পূর্ণরূপে নির্দিষ্ট করা হয়নি, তাই এটি ট্রিগার করা উচিত কিনা তা স্পষ্ট নয় যখন Proposer চুক্তি একটি বন্ড বাজেয়াপ্ত করে. এটি সম্ভবত ব্যবহার করা উচিত যখন OracleHub একটি মূল্য অনুরোধের জন্য অর্থ প্রদান করে. উভয় পরিস্থিতিতে ফাংশন ব্যবহার করা উচিত কিনা তা বিবেচনা করুন।

আপডেট: স্বীকৃত. এই সমস্যার জন্য UMA এর বিবৃতি:

N04 প্রস্তাবকারী এবং OracleHub উভয় চুক্তিতে ফি প্রদানের জন্য স্টোরের payOracleFeeErc20 পদ্ধতি ব্যবহার করে স্টোর ব্যবহারের সাথে সামঞ্জস্যপূর্ণ হওয়ার পরামর্শ দেয়। আমরা এই ফাংশনটি ব্যবহার না করার সিদ্ধান্ত নিয়েছি কারণ এর অর্থ একটি অতিরিক্ত ইন্টারফেস (স্টোরের জন্য) আমদানি করতে হবে এবং একটি ফিক্সডপয়েন্টে বন্ডের পরিমাণ কাস্ট করতে হবে (যার জন্য একটি অতিরিক্ত আমদানিরও প্রয়োজন হবে৷ কোডটি সহজ এবং পরিষ্কার রাখতে) আমরা এটি না করার সিদ্ধান্ত নিয়েছি। এপ্রিল 20-এ অডিট ফেজ 1-এ payOracleFeeErc2020-এর উপর OZ প্রতিক্রিয়াটি বৈধ ছিল যে এই পদ্ধতিটি সত্যিই কার্যকর নয়, এই ধরনের একীকরণকে যুক্তিযুক্ত করা কঠিন করে তোলে।

[N05] কোডে TODOs

কোড বেসে "TODO" মন্তব্য রয়েছে যা প্রকল্পের সমস্যা ব্যাকলগে ট্র্যাক করা উচিত। উদাহরণ স্বরূপ:

• লাইন 37 of Arbitrum_ParentMessenger চুক্তি
• লাইন 25 of Optimism_ChildMessenger চুক্তি
• রেখাসমূহ 83 এবং 146 of OracleHub চুক্তি।

বিকাশের সময়, "টুডো" মন্তব্যগুলি ভালভাবে বর্ণনা করা হলে তা ট্র্যাকিং এবং সমাধানের প্রক্রিয়াটিকে সহজ করে তুলবে৷ সেই তথ্য ব্যতীত, এই মন্তব্যগুলি পচে যেতে পারে এবং সিস্টেমের সুরক্ষার জন্য গুরুত্বপূর্ণ তথ্যগুলি উত্পাদনে প্রকাশের সময় ভুলে যেতে পারে।

এই TODO মন্তব্যগুলিতে মুলতুবি থাকা টাস্কের একটি সংক্ষিপ্ত বিবরণ এবং প্রকল্পের সংগ্রহস্থলে সংশ্লিষ্ট সমস্যার একটি লিঙ্ক থাকা উচিত।

এই তথ্য যোগ করার জন্য TODO মন্তব্য আপডেট করার কথা বিবেচনা করুন। সম্পূর্ণতা এবং সন্ধানযোগ্যতার জন্য, একটি স্বাক্ষর এবং একটি টাইমস্ট্যাম্প যোগ করা যেতে পারে। উদাহরণ স্বরূপ:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 5d57b5b in PR3684.

[N06] টাইপোগ্রাফিক ত্রুটি

কোডবেসে নিম্নলিখিত টাইপোগ্রাফিক ত্রুটি রয়েছে:

• মধ্যে Admin_ChildMessenger চুক্তি, impleenting হতে হবে implementing
• মধ্যে OptimisticRewarderBase চুক্তি, timestap হতে হবে timestamp.
• মধ্যে OptimisticRewarderBase চুক্তি, liveness liveness হতে হবে liveness.
• মধ্যে GovernorSpoke চুক্তি, only called হতে হবে only be called.
• মধ্যে Optimism_ChildMessenger চুক্তি:

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 9b92b0b in PR3681.

[N07] অব্যবহৃত আমদানি

কোডের পঠনযোগ্যতা উন্নত করতে, নিম্নলিখিত অব্যবহৃত আমদানিগুলি সরানোর কথা বিবেচনা করুন:

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 40b7221 in PR3682.

[N08] L2 লেনদেনের আদেশ

সার্জারির Governor নিশ্চিত একটি প্রস্তাব মধ্যে লেনদেন ক্রম নির্বাহ করা হয়. যাইহোক, যখন এই লেনদেনে ক্রস-চেইন লেনদেন জড়িত থাকে, তখন এটি শুধুমাত্র নিশ্চিত করে যে তারা সঠিক ক্রমে L1 সেতু চুক্তিতে পৌঁছেছে। আরবিট্রাম ক্ষেত্রে, তারা L2 এ চূড়ান্ত হওয়ার আগে তাদের পুনরায় সাজানো হতে পারে। তাই, L2 লেনদেন পুনর্বিন্যাস করার সম্ভাবনার অনুমতি দেওয়ার জন্য গভর্নেন্স প্রস্তাবগুলি তৈরি করা উচিত।

আপডেট: প্রতিশ্রুতি হিসাবে স্থির 0fb2e7b in PR3703. দ্য GovernorHub এখন L2 লেনদেনের একটি অ্যারে রিলে করতে পারে।

উপসংহার

কোডবেসে দুটি জটিল সমস্যা পাওয়া গেছে। একটি মাঝারি তীব্রতার সমস্যা এবং বেশ কয়েকটি ছোটখাটো দুর্বলতা পাওয়া গেছে এবং সমাধানের জন্য সুপারিশ করা হয়েছে।

সূত্র: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6