Uma Audit – فاز 6

معرفی

UMA پلتفرمی است که به کاربران امکان می دهد قراردادهای مالی با حداقل اعتماد را در بلاک چین اتریوم وارد کنند. قبلا حسابرسی کردیم اوراکل غیرمتمرکز, یک الگوی قرارداد مالی خاص, برخی از درخواست های کشش موقت, الگوی چند حزبی دائمی, درخواست های مختلف کشش افزایشی در یک تعامل طولانی تر و پل بیمه شده.

در این ممیزی ما یک قرارداد پیشنهادی حاکمیتی جدید، مکانیزمی برای گسترش اکوسیستم UMA در چندین زنجیره، مکانیزمی برای توزیع جوایز به دارندگان توکن ERC721 مطابق با مشخصات خارج از زنجیره، و به‌روزرسانی پل بیمه‌شده برای پشتیبانی از WETH را بررسی کردیم. در زنجیره خوش بینی

تعهد حسابرسی شده است 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc و دامنه شامل قراردادهای زیر است:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (به استثنای قراردادهای تست و چند ضلعی)
• financial-templates/optimistic-rewarder/* (به استثنای قراردادهای آزمایشی)

ما همچنین تغییرات فایل های solidity را بررسی کردیم Pull Request 3611.

همه کدهای خارجی و وابستگی‌های قرارداد طبق مستندات کار می‌کنند.

بررسی اجمالی سیستم

در حال حاضر Governance قرارداد به بنیاد آزمایشگاه های ریسک اجازه می دهد تا اقدامات حاکمیتی جدیدی را پیشنهاد کند که می تواند توسط دارندگان توکن UMA تأیید شود. جدید Proposer قرارداد برای ایفای نقش پیشنهاد دهنده در نظر گرفته شده است، و به هر کسی اجازه می دهد پیشنهادات جدیدی ارائه دهد تا زمانی که آنها تعهدی ارائه دهند که در صورت شکست پیشنهاد قربانی خواهد شد. هیچ انگیزه خاصی برای ارائه پیشنهاد وجود ندارد. هدف این است که اطمینان حاصل شود که فقط اقداماتی پیشنهاد می شود که احتمال قبولی آنها بسیار زیاد است.

مکانیسم زنجیره متقابل جدید اجازه می دهد تا پیشنهاد حاکمیتی از شبکه اصلی اتریوم به زنجیره های Optimism و Arbitrum منتقل شود. به این ترتیب، مکانیسم حاکمیت UMA در لایه 1 می تواند برای کنترل قراردادهای UMA در زنجیره های لایه 2 پشتیبانی شده استفاده شود. این مکانیسم همچنین اجازه می‌دهد تا درخواست‌ها و رزولوشن‌های قیمت بین لایه‌ها ارسال شوند، بنابراین اوراکل‌های خوش‌بینانه در زنجیره‌های لایه ۲ می‌توانند توسط مکانیسم تایید داده‌های شبکه اصلی به همان روشی که لایه اول Optimistic Oracle توسط DVM ایمن می‌شود، ایمن شوند.

شایان ذکر است که این پیام ها با استفاده از مکانیک پل بومی ارسال می شوند، به این معنی که با ویژگی های زنجیره لایه 2 مربوطه محدود می شوند. به طور خاص، پیام های لایه 2 تا لایه 1 ممکن است یک هفته یا بیشتر طول بکشد تا از پل عبور کند. علاوه بر این، مکانیسم حاکمیت UMA از پیشنهادهایی پشتیبانی می‌کند که شامل چندین تراکنش سفارش‌داده‌شده است، اما این صرفاً ترتیب اضافه شدن آنها به پل را محدود می‌کند. این امکان وجود دارد که برخی از آن تراکنش ها با ترتیب متفاوتی یا اصلاً در لایه 2 اجرا نشوند.

قرارداد Optimistic Rewarder به سادگی توکن های ERC721 را برای هر کسی که درخواست می کند، ضرب می کند. همچنین به هر کسی اجازه می دهد تا داده های دلخواه را با هر توکن مرتبط کند و توکن های مختلف ERC20 را برای توزیع به عنوان پاداش سپرده گذاری کند. تفسیر داده های دلخواه و توزیع مورد انتظار جوایز بین دارندگان توکن با استفاده از یک رویه خارج از زنجیره نامشخص تعیین می شود. هرکسی می‌تواند ادعا کند که یک توکن خاص ERC721 مجموعه‌ای از پاداش‌ها را مدیون است، اگر مایل به سپرده‌گذاری اوراق قرضه باشد. مکانیسم استاندارد Optimistic Oracle برای اجازه دادن به شخص دیگری برای مخالفت با ادعا استفاده می شود که توسط DVM حل خواهد شد. ادعاهایی که به موقع مورد مناقشه قرار نگرفته اند معتبر فرض می شوند و قرارداد بر این اساس پاداش ها را تقسیم می کند. تنها محدودیت (برای ساده‌سازی حسابداری) این است که توکن اوراق قرضه اوراکل نمی‌تواند به عنوان نماد پاداش استفاده شود.

در نهایت، PR3611 مکانیسم پل بیمه‌شده را تغییر می‌دهد تا از ارسال WETH از طریق پل توکن Optimism جلوگیری کند، که پشتیبانی نمی‌شود. در عوض، هر L2 WETH سپرده شده در جعبه سپرده Optimism قبل از عبور از پل به L2 ETH باز می شود. در لایه 1، ETH قبل از ارسال به استخر پل WETH به WETH تبدیل می شود.

شدت بحرانی

[C01] نمی توان با پاداش نامعتبر اعتراض کرد

هنگام بحث در مورد درخواست پاداش، OptimisticRewardBase اول قرارداد پیشنهادی را آغاز می کند در SkinnyOptimisticOracle و پس از آن با آن پیشنهاد مخالفت می کند. با این حال، پیشنهاد زمان انقضا را تعیین می کند به عنوان یک جبران از زمان (اختلاف) فعلی، در حالی که اختلاف انقضا را مشخص می کند به عنوان جبران از زمان درخواست پاداش اولیه. در بیشتر موارد، این اختلاف باعث می‌شود که اوراکل نتواند پیشنهاد مورد مناقشه را شناسایی کند، به این معنی که اختلافات معتبر پردازش نمی‌شوند و درخواست‌های پاداش نامعتبر پذیرفته می‌شوند.

برای مشخص کردن صحیح پیشنهاد مورد مناقشه، فراخوان اختلاف را به‌روزرسانی کنید.

به روز رسانی: از زمان تعهد ثابت شد 9e15557 in PR3690.

[C02] پیشنهادات را به طور مکرر حل کنید

La resolveProposal عملکرد Proposer قرارداد به سادگی تایید می کند که اوراکل حل کرده است، اما بررسی نمی کند که آیا اوراق قرضه توزیع شده است یا خیر. این بدان معنی است که یک پیشنهاد می تواند چندین بار حل شود و در نتیجه پرداخت های اوراق قرضه تکراری شود. پس از حل شدن، پیشنهادات موجود را پرچم گذاری یا حذف کنید.

به روز رسانی: از زمان تعهد ثابت شد b152718 in PR3689.

شدت بالا

ندارد.

شدت متوسط

[M01] پارامترهای رویداد نادرست

La OptimisticRewarderBase قرارداد الف را تعریف می کند Requested واقعه که از آن ساطع می شود requestRedemption عملکرد زمانی که بازخرید درخواست می شود. این رویداد برای انتشار تعریف شده است زمان انقضای بازخرید به عنوان آخرین پارامتر آن با این حال، زمانی که رویداد منتشر می شود، آخرین پارامتر آن به اشتباه روی عدد تنظیم شده است زمان کنونی.

به طور مشابه Redeemed واقعه زمان انقضا را پس از حذف رکورد می خواند، بنابراین به اشتباه روی صفر تنظیم می شود.

با توجه به اینکه می توان از این رویداد برای محاسبات خارج از زنجیره استفاده کرد، مقدار منتشر شده را به طور مناسب به روز کنید.

به روز رسانی: از زمان تعهد ثابت شد f04eef9 in PR3694.

شدت کم

[L01] عدم انتشار رویداد پس از بحث در مورد بازخرید

La OptimisticRewarderBase قرارداد الف را تعریف می کند Disputed واقعه در صورتی که بازخرید مورد مناقشه باشد، در نظر گرفته شده است که راه اندازی شود. با این حال، این رویداد در داخل یا خارج از آن منتشر نمی شود OptimisticRewarderBase قرارداد.

بعد از اینکه تغییرات حساسی در آن اتفاق افتاد، رویداد را منتشر کنید dispute تابع، برای تسهیل ردیابی و اطلاع مشتریان خارج از زنجیره به دنبال فعالیت قراردادها.

به روز رسانی: از زمان تعهد ثابت شد c275e92 in PR3695.

[L02] گارد ورود مجدد ناسازگار

La Optimism_ParentMessenger و Arbitrum_ParentMessenger قراردادها به طور متناقض اعمال می شود nonReentrant اصلاح کننده در نظر بگیرید که آن را در همه عملکردهای عمومی قرار دهید.

به روز رسانی: از زمان تعهد ثابت شد 6275c39 in PR3677.

[L03] نظرات گمراه کننده

در اینجا برخی از نظرات گمراه کننده وجود دارد که در طول بررسی خود شناسایی کردیم:

• ChildMessengerConsumerInterface.sol:
  • خط 5 به جای «فرزند پیام‌رسان» می‌گوید «پیام‌رسان والدین»
• GovernorSpoke.sol:
  • خطوط 49-51 پیوندهایی به a 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 قرارداد کمک هزینه ای نمادین به آن می دهد، بنابراین می تواند پرداخت اوراق قرضه را بکشد. اگر پیشنهاد شکست بخورد، بازخرید پاداش لغو می شود اما کمک هزینه تنظیم مجدد نمی شود. بنابراین، Optimistic Oracle تا دفعه بعدی که اختلاف ایجاد شود، مقدار اضافی باقیمانده غیرضروری را حفظ خواهد کرد. در صورت عدم موفقیت پیشنهاد، کمک هزینه را لغو کنید.

به روز رسانی: از زمان تعهد ثابت شد c2d444b in PR3698.

[L07] آدرس بازپرداخت نامعتبر است

آدرس L2 بازپرداخت Arbitrum_ParentMessenger مقداردهی اولیه می شود به صاحب قرارداد، که باید فرماندار L1 باشد. به طور مشابه، setRefundL2Address نظر دارد بیان می کند که باید به استاندار تنظیم شود. با این حال، هنگام ارسال پیام از روی پل، این مقدار است به عنوان کاربر L2 تنظیم کنید، که آدرس Arbitrum است که پس از حل شدن بلیط، وجوه اضافی دریافت می کند. از آنجایی که آدرس فرماندار L1 در Arbitrum قابل دسترسی نخواهد بود، هرگونه وجوه ارسال شده به این آدرس از بین خواهد رفت.

آن را روی یک آدرس L2 معتبر تنظیم کنید.

به روز رسانی: از زمان تعهد ثابت شد b3f2dd1 in PR3687.

[L08] مکانیسم تغییر پیام‌رسان‌های کودک

La GovernorSpoke و OracleSpoke هر یک از آنها پیام رسان فرزند را در سازنده قرارداد، بدون هیچ مکانیزمی برای به روز رسانی آن. این بدان معنی است که زمانی که پیام رسان کودک تغییر کرده است، هر دو قرارداد اسپیکر منسوخ می شوند.

از آنجایی که قرارداد اسپیکر احتمالاً پایدارتر از پیام رسان ها است، مکانیسمی را برای به روز رسانی پیام رسان در پره ها در نظر بگیرید.

به روز رسانی: از زمان تعهد ثابت شد 7c9e061 in PR3688.

یادداشت ها و اطلاعات تکمیلی

[N01] رمز اوراق قرضه را تغییر دهید

La Proposer قرارداد شامل یک مکانیسم برای مالک برای تغییر اندازه اوراق قرضه پیشنهاد. در نظر بگیرید که آیا آنها همچنین باید بتوانند توکن اوراق قرضه را تغییر دهند یا خیر. توجه داشته باشید که این امر مستلزم مکانیزمی برای شناسایی ارز صحیح اوراق قرضه در هنگام حل و فصل پیشنهادات موجود است.

به روز رسانی: مسئله ای نیست بیانیه UMA برای این موضوع:

N01 پیشنهاد می کند که قرارداد پیشنهاد دهنده را قادر سازد تا توکن اوراق قرضه را به چیزی غیر از UMA تغییر دهد. ما هیچ قصدی برای پشتیبانی از هیچ توکن دیگری به جز $UMA برای این عملکرد نداریم و بنابراین تصمیم گرفته‌ایم که هیچ تغییری برای این مشکل ایجاد نکنیم. علاوه بر این، یک توکن در هر قرارداد این منطق را تا حد امکان ساده نگه می‌دارد. در نهایت، اگر تغییری مورد نیاز بود (مثلاً در مورد مهاجرت توکن)، ما فقط می‌توانیم یک قرارداد پیشنهادی جدید با توکن دیگر مستقر کنیم و پیشنهادی را برای انتقال سیستم برای استفاده از آن آغاز کنیم.

[N02] رابط ناقص

La ChildMessengerInterface الف را مشخص نمی کند processMessageFromCrossChainParent عملکرد، حتی اگر توسط پیام رسان های والدین وجود داشته باشد. برای کامل بودن آن را در نظر بگیرید.

به روز رسانی: درست نشد. بیانیه UMA برای این موضوع:

ما عمداً تصمیم گرفتیم که این رابط را ناسازگار بگذاریم زیرا اجرای آن در ChildMessengerInterface سازگاری با Polygon_ChildMessenger را به هم می زند زیرا روش Polygon برای پردازش پیام های زنجیره های دیگر به منطق سفارشی نیاز دارد که در آن یک روش داخلی _processMessageFromRoot نامیده می شود.

[N03] رابط نادرست

La GovernorSpoke قرارداد نادرست با استفاده از ChildMessengerConsumerInterface نوع برای توصیف آن messenger متغیر. استفاده از را در نظر بگیرید ChildMessengerInterface به جای آن.

به روز رسانی: از زمان تعهد ثابت شد f31a527 in PR3680.

[N04] توکن‌ها را به فروشگاه بکشید

در یک ممیزی قبلی ما هدف را زیر سوال بردیم Store قرارداد payOracleFeesErc20 تابع (در شماره L19). تیم UMA انتخاب کرد که عملکرد را حفظ کند برای استانداردسازی رابط برای تغییرات احتمالی آینده. از آنجایی که هدف تابع به طور کامل مشخص نشده است، مشخص نیست که آیا باید زمانی که Proposer قرارداد وثیقه را مصادره می کند. احتمالاً باید زمانی استفاده شود که OracleHub برای درخواست قیمت پرداخت می کند. در نظر بگیرید که آیا تابع باید در هر دو سناریو استفاده شود یا خیر.

به روز رسانی: تصدیق کرد. بیانیه UMA برای این موضوع:

N04 استفاده از روش payOracleFeeErc20 فروشگاه را برای پرداخت هزینه در هر دو قرارداد Proposer و OracleHub توصیه می‌کند تا با استفاده از فروشگاه سازگار باشد. ما تصمیم گرفته‌ایم از این تابع استفاده نکنیم، زیرا به این معنی است که باید یک رابط اضافی (برای فروشگاه) وارد کنیم و مقدار اوراق قرضه را به یک FixedPoint ریخته‌ایم (که به واردات اضافی نیز نیاز دارد. برای ساده و تمیز نگه داشتن کد ما تصمیم گرفتیم که این کار را انجام ندهیم.

[N05] TODO در کد

نظرات "TODO" در پایه کد وجود دارد که باید در مشکلات پروژه ردیابی شوند. مثلا:

• لاین 37 of Arbitrum_ParentMessenger قرارداد
• لاین 25 of Optimism_ChildMessenger قرارداد
• خطوط 83 و 146 of OracleHub قرارداد.

در طول توسعه، توصیف خوب نظرات "TODO" روند ردیابی و حل آنها را آسان تر می کند. بدون این اطلاعات، این نظرات ممکن است پوسیده شوند و اطلاعات مهم برای امنیت سیستم ممکن است تا زمانی که برای تولید منتشر شود فراموش شوند.

این نظرات 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

La 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