تدقيق أوما - المرحلة 6

المُقدّمة

UMA هي عبارة عن منصة تسمح للمستخدمين بإدخال عقود مالية منخفضة الثقة على Ethereum blockchain. قمنا بالتدقيق في وقت سابق الوحي اللامركزي, قالب عقد مالي معين, بعض طلبات السحب المخصصة, نموذج التعددية الدائمة, مختلف طلبات السحب المتزايد على مدى مشاركة أطول و الجسر المؤمن.

في هذا التدقيق ، قمنا بمراجعة عقد اقتراح حوكمة جديد ، وآلية لتوسيع نظام UMA البيئي عبر سلاسل متعددة ، وآلية لتوزيع المكافآت على حاملي الرموز ERC721 وفقًا لمواصفات خارج السلسلة ، وتحديث للجسر المؤمن لدعم WETH في سلسلة التفاؤل.

الالتزام المدقق هو 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc ويشمل النطاق العقود التالية:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (باستثناء عقود الاختبار و Polygon)
• financial-templates/optimistic-rewarder/* (باستثناء عقود الاختبار)

قمنا أيضًا بمراجعة التغييرات التي تم إجراؤها على ملفات الصلابة بتنسيق طلب سحب 3611.

تم افتراض أن جميع تبعيات الكود الخارجي والعقد تعمل كما هي موثقة.

نبذة عن النظام

الحالي Governance يسمح العقد لمؤسسة Risk Labs باقتراح إجراءات حوكمة جديدة يمكن تصديقها من قبل حاملي رمز UMA. الجديد Proposer يهدف العقد إلى أخذ دور مقدم الطلب ، مما يسمح لأي شخص بتقديم مقترحات جديدة طالما أنه يوفر تعهدًا سيتم التضحية به في حالة فشل الاقتراح. لا يوجد حافز محدد لتقديم المقترحات. والقصد من ذلك هو التأكد من أنه سيتم فقط اقتراح الإجراءات التي من المرجح أن يتم قبولها.

تسمح الآلية الجديدة عبر السلسلة بتمرير اقتراح الحوكمة من شبكة Ethereum mainnet إلى سلاسل التفاؤل و Arbitrum. بهذه الطريقة ، يمكن استخدام آلية حوكمة UMA على الطبقة 1 للتحكم في عقود UMA على سلاسل الطبقة 2 المدعومة. تسمح الآلية أيضًا بإعادة توجيه طلبات الأسعار والقرارات بين الطبقات ، لذلك يمكن تأمين Oracles المتفائلة على سلاسل الطبقة 2 بواسطة آلية التحقق من بيانات الشبكة الرئيسية بنفس الطريقة التي يتم بها تأمين الطبقة الأولى من Oracle Optimistic Oracle بواسطة DVM.

تجدر الإشارة إلى أن هذه الرسائل يتم إرسالها باستخدام ميكانيكا الجسر الأصلي ، مما يعني أنها مقيدة بخصائص سلاسل الطبقة 2 ذات الصلة. على وجه الخصوص ، قد تستغرق الرسائل من الطبقة 2 إلى الطبقة 1 أسبوعًا أو أكثر لنقل الجسر. علاوة على ذلك ، تدعم آلية حوكمة UMA المقترحات التي تتضمن العديد من المعاملات المطلوبة ، ولكن هذا يقيد فقط الترتيب الذي يمكن إضافتها إلى الجسر. من الممكن تنفيذ بعض هذه المعاملات بترتيب مختلف ، أو عدم تنفيذها على الإطلاق ، على الطبقة 2.

عقد Optimistic Rewarder يقوم ببساطة بصنع رموز ERC721 لأي ​​شخص يطلبها. كما يسمح لأي شخص بربط البيانات التعسفية بأي رمز ، وإيداع العديد من الرموز المميزة ERC20 لتوزيعها كمكافآت. يتم تحديد تفسير البيانات التعسفية والتوزيع المتوقع للمكافآت بين حاملي الرموز باستخدام إجراء غير محدد خارج السلسلة. يمكن لأي شخص أن يدعي أن رمزًا مميزًا ERC721 مستحقًا مجموعة من المكافآت إذا كان على استعداد لإيداع السند. تُستخدم آلية Oracle Optimistic Standard للسماح لشخص آخر بالاعتراض على المطالبة ، والتي سيتم حلها بواسطة DVM. يُفترض أن المطالبات غير المتنازع عليها في الوقت المناسب صحيحة ، ويوزع العقد المكافآت وفقًا لذلك. القيد الوحيد (لتبسيط المحاسبة) هو أنه لا يمكن استخدام رمز سندات أوراكل كرمز مميز للمكافأة.

أخيرًا ، يعدل PR3611 آلية الجسر المؤمن لتجنب إرسال WETH عبر جسر الرمز المميز للتفاؤل ، وهو غير مدعوم. بدلاً من ذلك ، يتم فك أي L2 WETH المودعة في صندوق ودائع Optimism بـ L2 ETH قبل عبور الجسر. في الطبقة 1 ، يتم تحويل ETH إلى WETH قبل إعادة توجيهه إلى تجمع جسر 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 عقد يمنحها بدل رمزي، حتى تتمكن من سحب مدفوعات السندات. إذا فشل الاقتراح ، تم إلغاء استرداد المكافأة لكن لا يتم إعادة تعيين البدل. لذلك ، ستحتفظ Oracle Optimistic Oracle ببدل متبقي غير ضروري حتى المرة التالية التي يتم فيها بدء النزاع. النظر في إلغاء البدل إذا فشل الاقتراح.

تحديث: تم الإصلاح اعتبارًا من الالتزام c2d444b in PR3698.

[L07] عنوان رد الأموال غير صالح

عنوان L2 المسترد الخاص بـ Arbitrum_ParentMessenger تمت تهيئة لمالك العقد ، والذي يجب أن يكون الحاكم L1. وبالمثل ، فإن setRefundL2Address لديه تعليق ينص على أنه ينبغي تعيينه للمحافظ. ومع ذلك ، عند تمرير الرسائل عبر الجسر ، تكون هذه القيمة تم تعيينه كمستخدم L2، وهو العنوان الموجود على Arbitrum الذي يتلقى الأموال الزائدة بعد حل التذكرة. نظرًا لأن عنوان محافظ L1 لن يكون متاحًا على Arbitrum ، فسيتم فقد أي أموال يتم إرسالها إلى هذا العنوان.

ضع في اعتبارك تعيينه على عنوان L2 صالح.

تحديث: تم الإصلاح اعتبارًا من الالتزام b3f2dd1 in PR3687.

[L08] آلية لتغيير رسل الأطفال

• GovernorSpoke و OracleSpoke تعاقد كل منها على تهيئة برنامج child messenger في المنشئ ، مع عدم وجود آلية لتحديثه. هذا يعني أنه عندما يكون ملف تم تغيير رسول الطفل، وكلاهما تحدث العقد أصبح عفا عليه الزمن.

نظرًا لأن عقد التحدث من المحتمل أن يكون أكثر استقرارًا من الرسل ، ففكر في تضمين آلية لتحديث برنامج المراسلة على المتحدث.

تحديث: تم الإصلاح اعتبارًا من الالتزام 7c9e061 in PR3688.

ملاحظات ومعلومات إضافية

[N01] تغيير رمز السندات

• Proposer يشمل العقد آلية للمالك لتغيير حجم اقتراح السند. ضع في اعتبارك ما إذا كان ينبغي عليهم أيضًا تغيير رمز السند. لاحظ أن هذا قد يتطلب آلية لتحديد عملة السندات الصحيحة عند حل المقترحات الحالية.

تحديث: ليست قضية. بيان اتحاد المغرب العربي حول هذا الموضوع:

توصي N01 بتمكين عقد مقدم العرض من تغيير رمز السند إلى شيء آخر غير UMA. ليس لدينا أي نية لدعم أي رمز مميز بخلاف $ UMA لهذه الوظيفة ولذا فقد اخترنا عدم إجراء أي تغييرات لهذه المشكلة. علاوة على ذلك ، فإن رمزًا واحدًا لكل عقد يبقي هذا المنطق بسيطًا قدر الإمكان. أخيرًا ، إذا كانت هناك حاجة إلى تغيير (في حالة ترحيل الرمز المميز ، على سبيل المثال) ، فيمكننا فقط نشر عقد مقدم عرض جديد مع الرمز المميز الآخر وبدء اقتراح لترحيل النظام لاستخدام ذلك الرمز.

[N02] واجهة غير كاملة

• ChildMessengerInterface لا يحدد أ processMessageFromCrossChainParent الوظيفة ، على الرغم من افتراض وجودها من قبل الرسل الأم. ضع في اعتبارك تضمينها للتأكد من اكتمالها.

تحديث: لم تحل. بيان اتحاد المغرب العربي حول هذا الموضوع:

لقد اخترنا عن قصد ترك هذه الواجهة غير متسقة لأن تنفيذ ذلك داخل ChildMessengerInterface يقطع التوافق مع Polygon_ChildMessenger كطريقة Polygon لمعالجة الرسائل من سلاسل أخرى تتطلب منطقًا مخصصًا إلى حد ما حيث تسمى الطريقة الداخلية _processMessageFromRoot.

[N03] واجهة غير صحيحة

• GovernorSpoke التعاقد بشكل غير صحيح يستخدم ChildMessengerConsumerInterface نوع لوصف لها messenger عامل. ضع في اعتبارك استخدام ChildMessengerInterface بدلا من ذلك.

تحديث: تم الإصلاح اعتبارًا من الالتزام f31a527 in PR3680.

[N04] اسحب الرموز إلى المتجر

في باقة المراجعة السابقة تساءلنا عن الغرض من Store انكماش payOracleFeesErc20 وظيفة (في العدد L19). فريق UMA اختار الحفاظ على الوظيفة لتوحيد الواجهة لإجراء تعديلات مستقبلية محتملة. نظرًا لأن الغرض من الوظيفة غير محدد بالكامل ، فليس من الواضح ما إذا كان يجب تشغيلها عند تشغيل Proposer عقد يصادر سند. من المحتمل أن يتم استخدامه عندما يكون ملف OracleHub يدفع لطلب السعر. ضع في اعتبارك ما إذا كان يجب استخدام الوظيفة في أي من السيناريوهين.

تحديث: أقر. بيان اتحاد المغرب العربي حول هذا الموضوع:

توصي N04 باستخدام طريقة payOracleFeeErc20 الخاصة بالمتجر لدفع الرسوم في كل من عقود مقدم العرض و OracleHub لتكون متوافقة مع استخدام المتجر. لقد اخترنا عدم استخدام هذه الوظيفة لأنها قد تعني الحاجة إلى استيراد واجهة إضافية (للمخزن) وتتطلب تحويل مبلغ السند إلى FixedPoint (الأمر الذي يتطلب أيضًا استيرادًا إضافيًا. للحفاظ على الكود بسيطًا ونظيفًا لقد اخترنا عدم القيام بذلك.كانت ملاحظات OZ على payOracleFeeErc20 في مرحلة التدقيق 1 في أبريل 2020 صالحة لأن هذه الطريقة ليست مفيدة حقًا ، مما يجعل من الصعب التفكير في هذا النوع من التكامل.

[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

• Governor يضمن يتم تنفيذ المعاملات داخل الاقتراح بالترتيب. ومع ذلك ، عندما تتضمن هذه المعاملات معاملات عبر سلسلة ، فإن هذا يضمن فقط وصولها إلى عقد جسر L1 بالترتيب الصحيح. في حالة Arbitrum ، يمكن إعادة ترتيبها قبل الانتهاء منها في L2. لذلك ، يجب وضع مقترحات الحوكمة للسماح بإمكانية إعادة ترتيب معاملات المستوى 2.

تحديث: تم الإصلاح اعتبارًا من الالتزام 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