1 بوصة تدقيق مبادلة معدل ثابت

المُقدّمة

• 1inch طلب منا فريق العمل مراجعة ومراجعة العقود الذكية لمبادلة السعر الثابت. نظرنا إلى الكود ونشرنا نتائجنا الآن.

مجال

دققنا الالتزام b1600f61b77b6051388e6fb2cb0be776c5bcf2d1 ل 1inch/fixed-rate-swap مخزن. في النطاق كان العقد التالي:

- FixedRateSwap.sol

تم استبعاد جميع ملفات وأدلة المشروع الأخرى ، بما في ذلك الاختبارات والاعتمادات الخارجية والمشاريع ونظرية اللعبة وتصميم الحوافز ، من نطاق هذا التدقيق. تم افتراض أن الكود الخارجي وتبعيات العقد تعمل كما هي موثقة.

الصحة العامة

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

بعد ما قيل ، كان فريق 1inch مستعدًا دائمًا للإجابة على أي أسئلة أثناء المراجعة وكان من السهل جدًا التعامل معهم. إنهم يتقبلون التعليقات والاقتراحات من أجل التحسين المستمر.

اعتبارات استهلاك الغاز

هناك بعض الأجزاء كثيفة الاستخدام للغاز بشكل خاص من قاعدة البيانات ، مثل _powerHelper عمليات البحث الوظيفية والثنائية ، والتي لاحظناها باستخدام أكثر من 400 كيلو غاز في بعض حالات الحافة. نظرًا لطبيعة البروتوكول والقطع النقدية المستقرة التي ينوي التعامل معها ، فإن الاستهلاك العالي للغاز الذي يؤدي إليه تعقيد المشروع يمكن أن يقوض غرض البروتوكول ويمكن أن يؤثر بالتأكيد على قابليته للاستخدام العام.

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

بروتوكول مبادلة السعر الثابت هو صانع سوق تلقائي (AMM) يستخدم منحنى سعر المجموع الثابت لتسهيل المقايضات بين الأصول التي تكون أسعارها مستقرة مع بعضها البعض.
كما أنها تطبق آلية رسوم متغيرة على العموم يتقاضى 0.01٪ كرسوم. عندما تذهب أرصدة رمز AMM إلى الظروف القصوى ، يتم تخفيض الرسوم إلى 0٪ أو رفعها إلى 0.2٪ اعتمادًا على ما إذا كان النشاط مرغوبًا أم لا ، على التوالي ، لتكوين الأصول للمجموعة. يتم الاحتفاظ بهذه الرسوم في المجمع ، حيث سيستفيد موفرو السيولة منها من خلال حيازة الأسهم (ملكية AMM الخاصة ERC20 رمز LP).

أدوار مميزة

لا توجد أدوار مميزة في الإصدار المدقق من البروتوكول.

التبعيات الخارجية وافتراضات الثقة

لا ينوي البروتوكول دعم ERC20 الرموز المميزة التي تفرض رسومًا على التحويل.

أيضًا ، من الجدير بالذكر أنه قد تكون هناك أصول ، بناءً على طبيعتها ، يمكن أن تنتج سلوكيات غير متوقعة مماثلة لتلك الموضحة في هذا التقرير ، على سبيل المثال العملات المعدنية المستقرة التي تحتوي على عدد غير متناسب من الكسور العشرية بين بعضها البعض أو الأصول التي يمكن أن تسمح بقروض سريعة غير محدودة .

النتائج

هنا نقدم النتائج التي توصلنا إليها.

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

شدة حرجة

لا شيء.

خطورة شديدة

لا شيء.

شدة متوسطة

[M01] قد يؤدي الافتقار إلى ضمانات المخرجات إلى خسارة الأموال

• FixedRateSwap العقد يسهل مبادلة من عملة ثابتة مقابل عملة أخرى ، ويسمح أيضًا للمستخدمين الايداع و سحب أصول "أسهم" مجمع السيولة (رموز LP).

ومع ذلك ، لا المبادلات أو عمليات السحب أو الإيداعات توفر آلية للمستخدمين لتعيين الحد الأدنى من قيم العائد المقبولة من التفاعلات مع المجمع.

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

وبالمثل ، يمكن أيضًا استخدام التشغيل الأمامي للاستفادة من تقريب البروتوكول ضمن حسابات مخرجات الرمز المميز. على الرغم من أنه من غير المحتمل نظرًا للحالة الحالية للنظام البيئي فيما يتعلق بالعملات المعدنية المستقرة الشائعة ، إذا كان fromBalance من رمز مميز داخل التجمع يمكن معالجته ليكون بأمر من 1e36 * inputAmount لأي مقايضة معينة ، إذن هذا الخط ل _getReturn سيتم اقتطاع الوظيفة إلى zero، مما يؤدي إلى قيمة صفرية outputAmount.

ومع ذلك ، ل مقايضات القيمة الصفرية محمية ضد، اقتطاع داخل outputAmount سيحدث الحساب قبل مدخلات الحالة الأسوأ. على وجه التحديد ، أ fromBalance في أي مكان في نطاق [1e26 إلى 1e35] * the input amount يمكن أن يؤدي إلى اقتطاع وتقليل outputAmount يمكن أن يكون مربحًا لأصحاب الأسهم المجمعة على حساب المستخدمين.

على الرغم من أن مثل هذا السيناريو قد يكون غير مرجح في الوقت الحالي ، إلا أن التغييرات المستقبلية في النظام البيئي والقروض السريعة غير المحدودة قد تجعل هذا الأمر أكثر قابلية للتطبيق.

لتجنب الخسارة غير المقصودة للأموال والتخفيف من الهجمات الأمامية المحتملة ، ضع في اعتبارك السماح للمستخدمين بتحديد الحد الأدنى لقيمة الإرجاع المقبولة لأي تفاعل مع البروتوكول له آثار مالية.

تحديث: الثابتة في ارتكاب ea75a86. ومع ذلك ، لم تتم إضافة أي اختبار محدد للتحقق من أن تطبيق الإصلاح يمنع هذا الهجوم.

شدة منخفضة

[L01] يمكن أن يعود الإيداع عند التدفق السفلي

إذا كان المجمع غير متوازن بشكل كبير ، فسوف تعود الودائع أثناء حساب ال shift متغير في _getVirtualAmountsForDepositImpl وظيفة ما لم يكن إجمالي المبلغ المودع أكبر من 1/1000 من الرصيد الحالي في المجمع.

على سبيل المثال ، محاولة إيداع نسبة من الرموز التي يبلغ مجموعها أقل من 10 ، في مجمع بأرصدة حالية تبلغ 10,000 token0 و .0001 token1، سيعود. إيداع مبلغ أكبر سينجح.

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

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

تحديث: الثابتة في ارتكاب 4aa5210.

[L02] انبعاثات الأحداث غير المكتملة

• Swap يتم إصدار الحدث في كل مرة يسهل فيها البروتوكول تبادل الرمز المميز.

ومع ذلك ، هناك العديد من الطرق العامة المتاحة لتنفيذ مقايضات الرمز المميز. ال swap0To1 و swap1To0 دالات ترسل نتيجة المبادلة مباشرة إلى msg.sender، ولكن swap0To1For و swap1To0For الدالات ترسل نتائج المبادلة إلى عنوان محدد صراحة من قبل to المعلمة.

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

وبالمثل، فإن Deposit و Withdrawal الأحداث تقبل واحد فقط user العنوان ، على الرغم من أنها تنبعث أيضًا في الوظائف حيث يكون msg.sender قد تكون مختلفة عن الطرف الذي يتلقى الرموز المميزة.

ضع في اعتبارك إضافة ملف recipient معلمة العنوان للأحداث حتى يتمكنوا من نقل الإجراءات التي يتخذها البروتوكول بشكل كامل.

تحديث: أقر ، ولن يتم إصلاحه.

[L03] عدم التحقق من صحة الإدخال

• public getReturn وظيفة تفتقر إلى بعض التحقق من صحة الإدخال. خاصة:

• لا يتحقق ذلك من أن tokenFrom و tokenTo العناوين هي الرموز المميزة التي يتألف منها التجمع.
• لا يتحقق ذلك من أن inputAmount المعلمة ليست صفرية.
• لا يتحقق ذلك من أن fromBalance + toBalance القيمة ليست صفرية.

بالإضافة إلى ذلك ، لا withdrawFor ولا withdrawForWithRatio تحسب الدالات ما إذا كان لدى المستخدم مشاركات كافية لسحب المبلغ المطلوب. في كلتا الحالتين ، سيعود السحب إذا لم يتم استيفاء الشرط ، لكن رسائل الخطأ غير واضحة ولا تنبعث إلا بعد استهلاك غاز غير ضروري.

وأخيرا، فإن withdrawForWithRatio تتجاهل الدالة التأكد من أن القيم المستخدمة في حسابات الرصيد الافتراضية أقل من أو تساوي الأرصدة الفعلية للعقد. مثل هذا السيناريو من شأنه أن يؤدي إلى عودة حسابية غامضة عند الحساب balanceX و balanceY ل _getRealAmountsForWithdrawImpl وظيفة.

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

تحديث: ثابت جزئيًا في ارتكاب 63b6a95 و ارتكاب 7c0ade7. تم التحقق من صحتها فقط إذا كان inputAmount القيمة صفر وقد تم نقل ترتيب العمليات للفشل مبكرًا عند حرق الرموز LP لتقليل تكلفة الغاز. بيان فريق بحجم 1 بوصة لهذه المشكلة:

tokenFrom و tokenTo عملية التحقق من الصحة ليست إلزامية كما هو الحال في طريقة المبادلة يتم استبدالها من الثوابت

[L04] لم يتم التصريح عن الثوابت أو تسميتها بوضوح

في مجلة FixedRateSwap العقد ، القيم الحرفية 998, 1000و 1002، والتي تُستخدم لتخطي الرسوم في _getRealAmountsForWithdrawImpl و _getVirtualAmountsForDepositImpl الوظائف ، ليس لها تفسير مصاحب أو وثائق مضمنة.

علاوة على ذلك ، يؤثر نقص الوثائق المضمنة أيضًا على ملف الثوابت المسماة بشكل غامض والتي تستخدم في العمليات الحسابية في جميع أنحاء قاعدة البيانات.

لتحسين قراءة الكود وتسهيل إعادة البناء ، ضع في اعتبارك تحديد ثابت لكل "قيمة سحرية" والتأكد من أن جميع الثوابت لها أسماء واضحة وواضحة. للقيم المعقدة ، ضع في اعتبارك إضافة وثائق مضمنة تشرح كيفية حسابها أو سبب اختيارها.

تحديث: الثابتة في ارتكاب 7091076.

[L05] وثائق مضمنة مضللة أو غير كاملة

في جميع أنحاء قاعدة البيانات ، تم تحديد عدد قليل من حالات التوثيق المضمّن المضلل و / أو غير المكتمل ويجب إصلاحها.

فيما يلي أمثلة على الوثائق المضمنة غير المكتملة:

فيما يلي أمثلة على التوثيق المضمّن المضلل:

• • الحسابات من الوظيفة الخاصة _powerHelper لا تذكر صراحة أن نتيجة الضرب مقسومة على 1e18 لمنع التحجيم المزدوج للقيمة. علاوة على ذلك ، يتطابق أس عامل القياس أيضًا مع القدرة التي توفرها الوظيفة ، مما قد ينتج عنه ارتباك إضافي إذا ترك دون ملاحظة.

يعد التوثيق الواضح المضمّن أمرًا أساسيًا لتحديد مقاصد الكود. يمكن أن يؤدي عدم التطابق بين الوثائق المضمنة والتنفيذ إلى مفاهيم خاطئة خطيرة حول الطريقة التي يُتوقع أن يتصرف بها النظام. ضع في اعتبارك إصلاح أي أخطاء وإضافة وثائق إضافية عند تحديدها لتجنب الارتباك للمطورين والمستخدمين والمدققين على حد سواء.

تحديث: أقر ، ولن يتم إصلاحه.

[L06] لا يوجد تقرير تغطية يمكن الوصول إليه

على الرغم من أن README ملف يشير إلى تقرير التغطية، لا يمكن الوصول إليه.

بالإضافة إلى ذلك ، لا توجد تعليمات لتشغيل البرامج النصية للتغطية الاختبارية.

ضع في اعتبارك إتاحة الوصول إلى تقرير التغطية وتوثيق كيفية تشغيل البرامج النصية للتغطية التجريبية بشكل صريح.

تحديث: تم إصلاحه جزئيًا. تقرير التغطية يمكن الوصول إليه الآن ، ولكن README لا يزال ملف لا يشرح كيفية تشغيل البرامج النصية.

[L07] يحتمل أن تكون الرياضيات غير آمنة

في جميع أنحاء FixedRateSwap العقد ، هناك العديد من الاستخدامات unchecked الرياضيات. السبب الرئيسي لاستخدام unchecked تهدف الرياضيات إلى إزالة عمليات التحقق من تجاوز / تجاوز التدفق في الحالات التي تعتمد إما على مثل هذا السلوك أو المعروف عنها عدم تجاوزها / تجاوزها. هذا له فائدة في توفير الغاز ، ولكن إذا تم استخدامه بشكل غير صحيح ، يمكن أن يؤدي إلى نتائج غير متوقعة ونقاط ضعف محتملة.

حالات unchecked تم تحديد العمليات الحسابية التي يمكن أن تكون تحت / تجاوز. علي سبيل المثال:

غالبًا ما تمنع القيم الضرورية المطلوبة لتجاوز هذه الحسابات ، المقترنة بعمليات التحقق المعقولة في جميع أنحاء قاعدة الكود ، هذه الفائض من أن تكون قابلة للتحقيق في الممارسة ، لكنها لا تزال كذلك نظريا المستطاع. ضع في اعتبارك عدم استخدام unchecked الرياضيات إلا عندما تكون إمكانية حدوث فيضان تماما مستبعد ، من أجل منع النتائج غير المتوقعة وتقليل سطح الهجوم الكلي للبروتوكول.

تحديث: أقر ، ولن يتم إصلاحه.

[L08] صب صريح غير آمن للأعداد الصحيحة

• Swap يستغرق الحدث address واثنين int256 المعلمات وينبعث في swap0To1, swap1To0, swap0To1Forو swap1To0For الوظائف.

أثناء الإرسال ، ومع ذلك ، يتم إرسال قيم الأعداد الصحيحة التي يتم تمريرها إلى الحدث بشكل صريح من uint256 إلى int256 القيم.

على الرغم من أنه من غير المحتمل أن تكون مشكلة في الممارسة العملية اليوم ، إلا أن تطورات النظم البيئية مثل القروض السريعة غير المحدودة لأصول العملات المستقرة قد تتسبب في أن يُظهر هذا التصميم سلوكيات غير مرغوب فيها في المستقبل. على ما يكفي كبيرة بما فيه الكفاية uint256 قيمة ، تحويل صراحة إلى ملف int256 النوع سيقتطع قيمته. ونتيجة لذلك ، يمكن تضليل الأنظمة خارج السلسلة ، التي تعتمد على دقة انبعاث الحدث.

النظر في إعادة تعريف Swap حدث للتعامل معه مباشرة uint256 القيم بحيث يمكن للوظائف التي تصدر الحدث أن تتخلى عن عمليات التمثيل الصريحة.

تحديث: الثابتة في ارتكاب 8436c6c. فريق 1 بوصة استيراد ملفات OpenZeppelin SafeCast مكتبة يلقي الحالات المذكورة بأمان.

[L09] يمكن أن تؤدي عملية السحب إلى الأرضيات

عندما يستخدم صاحب السهم إما withdraw أو ال withdrawFor وظائف ، العقد بحساب كمية الأصول أنه يحق لهم الحصول على كمية الأسهم. ثم يتم نقل هذه الأصول إلى المستلم المحدد.

لكن منذ if يتم استخدام البيانات بدلا من require بيانات للتحقق مما إذا كان يجب إرسال أي أصل إلى المستلم ، إذا كان المجمع غير متوازن وكانت كمية الأسهم صغيرة ، يمكن أن يحدد العقد القيمة التي سيتم إرسالها لأي من الأصول أو لكليهما.

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

تحديث: أقر ، ولن يتم إصلاحه.

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

[N01] تبعيات مشروع مهملة

أثناء تثبيت ملف تبعيات المشروع، يحذر NPM من أن إحدى الحزم المثبتة ، Highlight، "لن يتم دعمها أو تلقي تحديثات أمنية في المستقبل".

على الرغم من أنه من غير المحتمل أن تتسبب هذه الحزمة في مخاطر أمنية ، ففكر في ترقية التبعية التي تستخدم هذه الحزمة إلى إصدار تم الحفاظ عليه.

تحديث: الثابتة في ارتكاب 0a2b55d. ومع ذلك ، يتطلب التثبيت الآن استخدام ملف -force علامة على إصدارات LTS الحالية من العقدة من أجل النجاح.

[N02] قد تحفز رسوم المجمع على الودائع غير المتوازنة

عند الإيداع في FixedRateSwap العقد _getVirtualAmountsForDeposit دالة بحساب القيمة الافتراضية للإيداع. المبالغ الافتراضية هي المبالغ الأصلية التي تم قياسها ، بعد تحصيل الرسوم وفقًا لنسبة الأصول الحالية للمجمع.

إذا قام المستخدم بإيداع الأموال في النسبة الحالية للأصول داخل المجمع ثم لا يتم فرض رسوم عليهم. بخلاف ذلك ، يتم تحصيل رسوم عليهم بناءً على الفرق بين نسبة الودائع ونسبة الأصول الحالية للمجمع.

يشير هذا التصميم إلى أنه عندما تكون نسبة الأصول داخل المجمع غير متوازنة ، فسيتم تحفيز المستخدمين على الإيداع بنفس النسبة غير المتوازنة ، بدلاً من الإيداع بنسبة تجعل المجمع أكثر توازناً.

لتشجيع تجمع أكثر توازناً ، فكر في تحفيز الودائع التي توازن المجمع بدلاً من معاقبتهم. بدلاً من ذلك ، إذا لم يكن ذلك ممكنًا ، ففكر في شرح السبب في وثائق المشروع.

تحديث: أقر ، ولن يتم إصلاحه.

[N03] متطلبات الموافقة الضمنية غير الموثقة

• FixedRateSwap يفترض العقد ضمنيًا أنه قد تم منحه بدلًا مناسبًا قبل التنفيذ التبادل و الودائع التي تنقل الرموز بالضرورة.

لصالح الوضوح ولتحسين الوضوح العام لقاعدة التعليمات البرمجية ، ضع في اعتبارك توثيق جميع متطلبات الموافقة في الوثائق المضمنة للوظائف ذات الصلة.

تحديث: أقر ، ولن يتم إصلاحه.

[N04] الخلط بين التحقق الضمني من outputAmount

• getReturn يتم توفير وظيفة ثلاث معاملات ، وهي الرمز المميز للمبادلة من (tokenFrom) ، رمز للمبادلة بـ (tokenTo) ومقدار إدخال (inputAmount قيمة tokenFrom أصل). المناظرة outputAmount القيمة (المبلغ الناتج لـ tokenTo الأصول) هو إذن محسوب وعاد.

قبل الحساب ، وظيفة يتطلب أن inputAmount تكون القيمة أقل من أو تساوي رصيد الرمز المميز للمجمع لـ tokenTo أصل. ومع ذلك ، فإن outputAmount القيمة ، يمكن القول إنها القيمة الأكثر بديهية للتحقق مقابل tokenTo رصيد الأصول ، لا يتم التحقق منه صراحةً لنفس الحالة.

في الواقع، الرياضيات المستخدمة في الحساب outputAmount قيمنا يضمن أنه سيكون بدقة أقل من أو يساوي inputAmount .

ومع ذلك ، فإن القصد من هذا السلوك غير واضح ، بمعنى أنه ليس من الواضح ما إذا كان هذا التصميم يهدف فقط إلى الفشل بسرعة أكبر أثناء التنفيذ لتقليل تكلفة الغاز أم لا. ضع في اعتبارك التوثيق الصريح لأسباب الفحص الدقيق المستخدم. بالإضافة إلى ذلك ، ضع في اعتبارك التحقق مما إذا كان رصيد to الأصل أكبر من outputAmount قيمة مقابل inputAmount .

تحديث: الثابتة في ارتكاب 10f4d9c.

[N05] تسمية غير متسقة

• FixedRateSwap يحدد عقد صريح زوج من الرموز التي من المفترض أن تعمل بها عمليات المبادلة والسحب والإيداع. في جميع أنحاء مصدر الشفرة ، يتم تصنيف هذه الرموز المميزة بفهرس لأي منهما 0 or 1، كما في token0 و token1. الوظائف التي تم تسميتها بشكل وصفي لنقل التفاصيل حول الاستخدام تستفيد أيضًا من مؤشرات الرمز المميز ، مثل swap0To1 وظيفة.

ومع ذلك ، بالنسبة لـ withdrawForWithRatio دالة ، المعلمة التي تحدد النسبة المطلوب استلامها token0 ضد token1 يدعى firstTokenShare مما قد يؤدي إلى حدوث ارتباك في إشارة إلى token1 الأصول وليس token0 الأصول.

لتحسين إمكانية القراءة الإجمالية وتقليل الالتباس المحتمل ، ضع في اعتبارك الحفاظ على اتساق اصطلاحات التسمية في جميع أنحاء قاعدة التعليمات البرمجية بأكملها.

تحديث: الثابتة في ارتكاب 57ad4cd.

[N06] تم تنسيق رسائل التراجع بشكل غير متسق

• require البيانات في المنشئ ل FixedRateSwap تم تنسيق العقد بشكل مختلف عن الآخر require البيانات في العقد.

نظرًا لأن رسائل العودة المنسقة بشكل غير متسق يمكن أن تسبب ارتباكًا لا داعي له ، ضع في اعتبارك التأكد من ذلك كله require تقوم العبارات بإرجاع الرسائل المنسقة والدقيقة والمفيدة وسهلة الاستخدام بشكل متسق.

تحديث: الثابتة في ارتكاب 0aa4e9d.

[N07] استخدام غير متسق لمتغيرات الإرجاع المسماة

يوجد استخدام غير متسق لمتغيرات الإرجاع المسماة في ملف FixedRateSwap العقد.

على وجه التحديد ، بينما تُرجع معظم الدالات متغيرات مسماة ، فإن ملف decimals, _getVirtualAmountsForDepositImpl, _getRealAmountsForWithdrawImplو _checkVirtualAmountsFormula ترجع الدالات قيمًا صريحة.

ضع في اعتبارك اعتماد نهج ثابت لإرجاع القيم في جميع أنحاء قاعدة التعليمات البرمجية عن طريق إزالة جميع متغيرات الإرجاع المسماة ، والإعلان عنها صراحةً كمتغيرات محلية ، وإضافة عبارات الإرجاع الضرورية عند الاقتضاء. سيؤدي ذلك إلى تحسين كلاً من الوضوح وسهولة قراءة الكود ، وقد يساعد أيضًا في تقليل الانحدار أثناء عمليات إعادة بناء الكود في المستقبل.

تحديث: أقر ، ولن يتم إصلاحه.

[N08] تحسينات الغاز

ضمن FixedRateSwap العقد ، هناك فرص لإجراء بعض التخفيضات البسيطة في استهلاك الغاز. على سبيل المثال:

• • _getVirtualAmountsForDeposit private لا يتم استدعاء الوظيفة إلا من مكان واحد في مصدر البرنامج ، وهذا هو depositFor وظيفة. في حدود depositFor وظيفة هناك مكالمات ل token0.balanceOf(address(this)) و token1.balanceOf(address(this)). ومع ذلك ، يتم إجراء تلك المكالمات نفسها في الجزء العلوي من _getVirtualAmountsForDeposit وظيفة. يمكن ببساطة تمرير الوظيفة الأخيرة بالقيم المطلوبة ، بدلاً من قراءة الأرصدة مرتين لكل depositFor مكالمة.
• ضمن _getRealAmountsForWithdrawImpl private وظيفة، و secondTokenShare يتم تعريف المتغير على أنه _ONE - firstTokenShare. على السطر التالي، يتم إجراء عملية الطرح نفسها مرة أخرى عندما يمكن ببساطة استخدام secondTokenShare المتغير.

لتقليل تكاليف الغاز وزيادة تبسيط قاعدة الشفرة ، ضع في اعتبارك معالجة الحالات التي أثيرت أعلاه.

تحديث: الثابتة في ارتكاب 34974ee.

[N09] رؤية وظيفية غير صحيحة

• withdrawWithRatio لا يتم استدعاء الوظيفة داخليًا بواسطة أي من الوظائف الموجودة في FixedRateSwap عقد. ضع في اعتبارك تعيين الرؤية لـ external بدلا من public.

تحديث: الثابتة في ارتكاب cb852f5.

[N10] الاعتماد على المطابقة decimals قد تكون مشكلة

بروتوكول يتطلب ضمنيًا أن كلا الرمزين المميزين داخل التجمع يدعمان decimals طريقة لنجاح بناء المسبح. في الواقع ، هذه الطريقة منتشرة في كل مكان تقريبًا ، لكنها من الناحية الفنية ، مكون اختياري لمواصفات ERC20 حيث يُنص صراحةً على أن العقود "يجب ألا تتوقع وجود هذه القيم". حاليًا ، أي من الرموز المميزة التي لا تدعم الخيار الاختياري decimals لن تكون الطريقة قابلة للاستخدام داخل البروتوكول.

ربما يكون الأمر الأكثر إشكالية ، كجزء من هذه المكالمات token decimals، يتطلب البروتوكول كذلك أن كلا الرمزين يعيدان قيمًا متطابقة.

ومع ذلك ، فإن مساحة الرمز المميز للعملة الثابتة ليست متجانسة في هذا الصدد. وهي تتألف من العديد من الرموز المميزة التي ترجع مجموعة متنوعة من القيم المختلفة لـ decimals. على سبيل المثال ، بينما USDT و USDC تقرير 6 كسور عشرية ، DAI تقارير 18 عشرية.

إذا كانت هذه قيودًا متعمدة للبروتوكول ، ففكر في لمسها صراحة وتقديم مبررات قصيرة عبر التوثيق المضمّن. ضع في اعتبارك أيضًا تقديم رسائل خطأ أفضل في وقت الإنشاء للرموز المميزة التي لا تدعم decimals طريقة. بدلاً من ذلك ، ضع في اعتبارك جعل البروتوكول أكثر قوة ، بحيث يمكنه التعامل مع الرموز المميزة التي لا تدعم decimals طريقة أو أزواج الإبلاغ متباينة decimals داخل نفس البركة.

تحديث: الثابتة في ارتكاب b49d808. تمت إضافة الوثائق المضمنة.

[N11] خطأ مطبعي

حددنا الخطأ المطبعي التالي في قاعدة الشفرة:

• تم تشغيل رسالة التراجع خط 92 of FixedRateSwap.sol يبدأ بدون حرف كبير ، مما يجعله غير متوافق مع باقي الكود.

لتحسين الاتساق الكلي وقابلية القراءة لقاعدة الشفرات ، ضع في اعتبارك تصحيح هذا وأية أخطاء مطبعية أخرى في جميع أنحاء قاعدة التعليمات البرمجية.

تحديث: الثابتة في ارتكاب a92d16a.

[N12] بلا داع virtual وظيفة

• FixedRateSwap يرث العقد من أوبن زيبلين ERC20 العقد ولكن ذلك يتجاوز الخاص به ERC20.decimals وظيفة. هذا مطلوب لأن FixedRateSwapرمز تجمع السيولة الخاص بـ decimals من الأصول التي يتألف منها المجمع ، ديناميكية بالضرورة.

ومع ذلك ، على الرغم من أن هذا التنفيذ المهيمن للوظيفة يجب أن يكون نهائيًا ، فهو كذلك معرّف بـ virtual الكلمة، مما يشير إلى أنه ليس بالضرورة تنفيذًا نهائيًا والسماح بتجاوزه مرة أخرى.

لتجنب الالتباس وتوضيح النية ، ضع في اعتبارك إزالة virtual كلمة مفتاحية أو توثيق أسباب الاحتفاظ بها.

تحديث: الثابتة في ارتكاب 8bce5ec.

استنتاجات

لم يتم العثور على مشاكل عالية الخطورة. تم اقتراح بعض التغييرات لاتباع أفضل الممارسات وتقليل سطح الهجوم المحتمل.

• كوينسمارت. أفضل بورصة للبيتكوين والعملات المشفرة في أوروبا.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. دخول مجاني.
• كريبتوهوك. الرادار. تجربة مجانية.
• المصدر: https://blog.openzeppelin.com/1inch-fixed-rate-swap-audit/؟utm_source=rss&utm_medium=rss&utm_campaign=1inch-fixed-rate-swap-audit