1 اینچ حسابرسی مبادله نرخ ثابت

معرفی

تیم 1Inch از ما خواسته است تا قراردادهای هوشمند مبادله نرخ ثابت خود را بررسی و ممیزی کنیم. ما به کد نگاه کردیم و اکنون نتایج خود را منتشر می کنیم.

محدوده

ما متعهد B1600F61B77B6051388E6FB2CB0BE776C5BCF2D1 از مخزن 1Inch/Fix-Rate-SWAP. در دامنه قرارداد زیر بود:

سایر پرونده ها و دایرکتوری های پروژه ، از جمله تست ها ، وابستگی های خارجی و پروژه ها ، تئوری بازی و طراحی تشویقی ، از دامنه این ممیزی خارج شدند. کد خارجی و وابستگی های قرارداد فرض شده است که طبق مستند کار می کند.

سلامت کلی

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

همه گفتند ، تیم 1Inch همیشه آماده رسیدگی به هرگونه سؤال در حین ممیزی بود و کار با آنها بسیار آسان بود. آنها به بازخورد و پیشنهادات برای بهبود مستمر پذیرای هستند.

ملاحظات مصرف گاز

برخی از قسمت های مخصوص گاز از پایگاه کد وجود دارد ، مانند عملکرد _powerhelper و جستجوهای باینری ، که ما در بعضی موارد لبه با استفاده از بیش از 400K گاز مشاهده کردیم. با توجه به ماهیت پروتکل و سکه های پایدار که قصد مقابله با آن را دارد ، میزان مصرف بالای گاز که پیچیدگی پروژه منجر به هدف این پروتکل می شود و مطمئناً می تواند بر قابلیت استفاده عمومی آن تأثیر بگذارد.

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

پروتکل مبادله نرخ ثابت یک سازنده بازار اتوماتیک (AMM) است که از یک منحنی قیمت ثابت برای تسهیل مبادلات بین دارایی هایی که قیمت آنها برای یکدیگر پایدار است استفاده می کند. همچنین یک مکانیسم هزینه متغیر را اجرا می کند که به طور کلی 0. 01 ٪ را به عنوان هزینه شارژ می کند. هنگامی که توازن توکن AMM به شرایط شدید می رود ، بسته به اینکه فعالیت مطلوب باشد یا نه ، به ترتیب ، برای ترکیب دارایی استخر ، به 0 ٪ کاهش می یابد یا تا 0. 2 ٪ افزایش می یابد. چنین هزینه هایی در استخر نگهداری می شود ، جایی که ارائه دهندگان نقدینگی با نگه داشتن سهام (نشانه ERC20 LP خود AMM) از آنها بهره مند می شوند.

نقش های ممتاز

هیچ نقش ممتازی در نسخه حسابرسی شده پروتکل وجود ندارد.

وابستگی های خارجی و فرضیات اعتماد

این پروتکل قصد پشتیبانی از نشانه های ERC20 را ندارد که هزینه انتقال را پرداخت می کنند.

همچنین ، لازم به ذکر است که ممکن است دارایی هایی وجود داشته باشد که بسته به ماهیت آنها ، می توانند رفتارهای غیر منتظره ای مشابه آنچه در این گزارش شرح داده شده است ، به عنوان مثال. سکه های پایدار با تعداد نامحدود اعشار بین یکدیگر یا دارایی هایی که می توانند وام های فلش بدون مرز را امکان پذیر کنند.

یافته ها

در اینجا یافته های خود را ارائه می دهیم.

بروزرسانی: تیم 1Inch بر اساس توصیه های ما چندین اصلاح را اعمال کرده و مجموعه ای از تعهدات را برای ما فراهم کرده است که موضوعات مربوطه را پیدا کرده است. این تعهدات در مورد هر شماره مربوطه بیان شده است و ما به اصلاحات معرفی شده در هر تعهد فردی می پردازیم. با این حال ، ما فقط تکه های خاص را به موضوعاتی که گزارش دادیم مرور کردیم. پایگاه کد تغییرات دیگری را که ما حسابرسی نکرده ایم انجام داده است و توصیه می کنیم که این تغییرات در حسابرسی آینده به طور عمیق مورد بررسی قرار گیرد.

شدت بحرانی

شدت

شدت متوسط

[M01] فقدان حفاظت از خروجی می تواند منجر به از دست دادن بودجه شود

قرارداد FixtratesWap مبادله یک سکه پایدار را برای دیگری تسهیل می کند ، و همچنین به کاربران امکان می دهد دارایی های "سهام" استخر نقدینگی (نشانه های LP) را واریز و برداشت کنند.

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

استخر هزینه های متغیر را بر اساس چگونگی تأثیر تعامل بر ترکیب استخر ارزیابی می کند. با این وجود ، با این طرح ، از آنجا که هزینه های ارزیابی شده مستقیماً به دارندگان سهم استخر می رود ، انگیزه اقتصادی برای دارنده سهام اکثریت به مبادلات بزرگ پیشرو وجود دارد و ترکیب استخر را به منظور مجبور کردن هزینه های بالاتر دستکاری می کند.

به طور مشابه ، می توان از جلو همچنین برای استفاده از پروتکل دور در محاسبات خروجی توکن استفاده کرد. اگرچه با توجه به وضعیت فعلی اکوسیستم در رابطه با سکه های پایدار محبوب بعید به نظر می رسد ، اگر از تعادل یک نشانه در استخر می توان به ترتیب 1E36 * inputamount برای هر مبادله معین دستکاری کرد ، پس این خط از عملکرد _getRetu خواهد بودبه صفر کوتاه می شود و منجر به خروجی با ارزش صفر می شود.

با این حال ، از آنجا که مبادلات با ارزش صفر در برابر محافظت می شوند ، کوتاه شدن در محاسبه خروجی قبل از بدترین ورودی ها رخ می دهد. به طور خاص ، از تعادل در هر نقطه در محدوده [1E26 تا 1E35] * مقدار ورودی می تواند منجر به کوتاه شدن و کاهش خروجی شود که می تواند برای دارندگان سهم استخر با هزینه کاربران سودآور باشد.

اگرچه چنین سناریویی ممکن است در حال حاضر بعید باشد ، اما اکوسیستم آینده و وام های فلش بدون مرز می تواند این را به یک بردار حمله مناسب تر تبدیل کند.

برای جلوگیری از از دست دادن غیر عمدی وجوه و کاهش حملات احتمالی جلو ، در نظر بگیرید که به کاربران اجازه دهید حداقل ارزش بازده قابل قبول را برای هرگونه تعامل با پروتکل که پیامدهای پولی دارد ، مشخص کنند.

بروزرسانی: در Comment EA75A86 ثابت شده است. با این حال ، هیچ آزمایش خاصی برای تأیید اعتبار این امر اضافه نشده است که اجرای رفع این حمله از این حمله جلوگیری می کند.

شدت کم

[L01] سپرده می تواند به زیر جریان برگردد

اگر استخر به طور چشمگیری نامتعادل باشد ، سپرده ها در حین محاسبه متغیر تغییر در عملکرد _getVirtualAmountsfordePositimpl باز می گردند ، مگر اینکه مقدار کل سپرده شده بیشتر از 1/1000 از تعادل موجود در استخر باشد.

به عنوان مثال ، تلاش برای واریز نسبت نشانه های کل کمتر از 10 ، در استخر با مانده های موجود 10،000 Token0 و . 0001 Token1 ، باز می گردد. واریز مبلغ بیشتر موفق خواهد شد.

این می تواند برای ایجاد مانعی برای جلوگیری از پیوستن سایر کاربران به استخر استفاده شود. در چنین سناریویی ، هنوز هم می توان از طریق استخر از طریق استخر خارج و مبادله کرد. همچنین می توان دقیقاً با همان نسبت استخر واریز کرد. اگر استخر تغییر کند تا یک طرفه کمتر باشد ، پس رسوبات کوچکتر دوباره امکان پذیر می شوند.

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

[L02] انتشار ناقص رویداد

رویداد مبادله هر بار پروتکل مبادله توکن را تسهیل می کند.

با این حال ، چندین روش عمومی برای اجرای تعویض توکن در دسترس است. توابع SWAP0TO1 و SWAP1TO0 نتیجه مبادله را مستقیماً به msg. sender ارسال می کنند ، اما توابع swap0to1for و swap1to0for نتایج مبادله را به آدرس مشخص شده توسط پارامتر به پارامتر ارسال می کنند.

از آنجا که در هر صورت ، در هر دو حالت ساطع می شود ، احزاب خارج از زنجیره هیچ راهی برای تشخیص اینکه کدام نوع مبادله اعدام شده است ، یا نتیجه مبادله به چه کسی تحویل داده شده است.

به طور مشابه ، رویدادهای سپرده و برداشت فقط یک پارامتر آدرس کاربر واحد را می پذیرند ، حتی اگر در توابع موجود در آن نیز منتشر شود.

در نظر بگیرید که یک پارامتر آدرس گیرنده شاخص را به رویدادها اضافه کنید تا آنها بتوانند به طور کامل آنچه را که توسط پروتکل انجام می شود ، انتقال دهند.

بروزرسانی: تصدیق شده و برطرف نمی شود.

[L03] عدم اعتبار ورودی

عملکرد عمومی GetRetu فاقد اعتبار ورودی است. به طور مشخص:

• اعتبارسنجی نمی کند که آدرسهای توکن و توکنتو نشانه هایی هستند که استخر را تشکیل می دهند.
• تأیید نمی کند که پارامتر InputAmount غیر صفر است.
• تأیید نمی کند که مقدار متعادل + تعادل غیر صفر است.

علاوه بر این ، نه برداشت و نه توابع خروج ForwithRatio اگر کاربر سهام کافی برای برداشت مبلغ درخواست شده خود داشته باشد ، محاسبه نمی کند. در هر صورت ، در صورت عدم رضایت شرط ، یک عقب نشینی برمی گردد ، اما پیام های خطا نامشخص هستند و فقط پس از مصرف گاز غیر ضروری ساطع می شوند.

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

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

بروزرسانی: تا حدی در تعهد 63B6A95 ثابت شده و مرتکب 7C0ADE7 شوید. این تنها درصورتی تأیید شده است که مقدار ورودی صفر باشد و سفارش عملیات را در هنگام سوزاندن نشانه های LP برای کاهش هزینه گاز انجام داده است. بیانیه تیم 1 اینچ برای این شماره:

اعتبارسنجی tokenFrom و tokenTo اجباری نیست زیرا در روش swap آنها از ثابت ها جایگزین می شوند.

[L04] ثابت هایی که اعلام نشده یا به وضوح نام گذاری نشده اند

در قرارداد FixedRateSwap، مقادیر تحت اللفظی 998، 1000 و 1002، که برای گذر از کارمزدها در توابع _getRealAmountsForWithdrawImpl و _getVirtualAmountsForDepositImpl استفاده می شوند، هیچ توضیح یا مستندات درون خطی ندارند.

علاوه بر این، فقدان اسناد درون خطی نیز بر ثابت های نام گذاری مبهم که در محاسبات در سرتاسر پایگاه کد استفاده می شوند، تأثیر می گذارد.

برای بهبود خوانایی کد و تسهیل بازآفرینی، یک ثابت برای هر «مقدار جادویی» تعریف کنید و اطمینان حاصل کنید که همه ثابت ها دارای نام های واضح و قابل توضیح هستند. برای مقادیر پیچیده، اضافه کردن اسناد درون خطی را در نظر بگیرید که توضیح می دهد چگونه آنها محاسبه شده اند یا چرا انتخاب شده اند.

[L05] اسناد درون خطی گمراه کننده یا ناقص

در سرتاسر پایگاه کد، چند نمونه از اسناد درون خطی گمراه کننده و/یا ناقص شناسایی شد و باید اصلاح شود.

موارد زیر مواردی از مستندات خطی ناقص است:

• تمام ثابت ها، رویدادها و متغیرهای قرارداد FixedRateSwap.
• بازگردان اعشار و تابع سازنده.

موارد زیر مواردی از اسناد درون خطی گمراه کننده هستند:

• محاسبات تابع خصوصی _powerHelper به صراحت بیان نمی کند که حاصل ضرب بر 1e18 تقسیم می شود تا از تغییر مقیاس دو برابری مقدار جلوگیری شود. علاوه بر این، توان ضریب مقیاس بندی نیز با توان داده شده توسط تابع مطابقت دارد، که در صورت عدم توجه می تواند سردرگمی بیشتری ایجاد کند.

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

بروزرسانی: تصدیق شده و برطرف نمی شود.

[L06] گزارش پوشش قابل دسترسی وجود ندارد

اگرچه فایل README به گزارش پوشش اشاره می کند، اما غیرقابل دسترسی است.

علاوه بر این، هیچ دستورالعملی برای اجرای اسکریپت های پوشش تست وجود ندارد.

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

به روز رسانی: تا حدی ثابت شده است. گزارش پوشش اکنون در دسترس است، با این حال فایل README هنوز نحوه اجرای اسکریپت ها را توضیح نمی دهد.

[L07] ریاضی بررسی نشده بالقوه ناامن

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

مواردی از محاسبات کنترل نشده که به طور بالقوه می توانند سرریز/سرریز شوند شناسایی شدند. مثلا:

• تابع _getRetu می تواند در چندین مکان سرریز شود و به طور بالقوه خروجی مقدار بسیار کم تری را برمی گرداند.
• تابع _checkVirtualAmountsFormula می تواند سرریز شود.
• تابع _powerHelper می تواند سرریز شود، اما فقط توسط تابع _getRetu خصوصی استفاده می شود.

مقادیر لازم برای سرریز شدن این محاسبات، همراه با اعتبارسنجی های معقول در سرتاسر پایگاه کد، اغلب از دستیابی به این سرریزها در عمل جلوگیری می کند، اما از نظر تئوری هنوز امکان پذیر است. به منظور جلوگیری از نتایج غیرمنتظره و کاهش سطح حمله کلی پروتکل، از ریاضیات بررسی نشده استفاده نکنید، مگر زمانی که امکان سرریز به طور کامل رد شود.

بروزرسانی: تصدیق شده و برطرف نمی شود.

[L08] ریخته گری صریح ناامن اعداد صحیح

رویداد Swap یک آدرس و دو پارامتر int256 می گیرد و در توابع swap0To1، swap1To0، swap0To1For و swap1To0For منتشر می شود.

با این حال، در طول انتشار، مقادیر عدد صحیحی که به رویداد منتقل می شوند به صراحت از مقادیر uint256 به مقادیر int256 ریخته می شوند.

اگرچه بعید است که امروزه در عمل مشکل ساز باشد، اما پیشرفت های اکوسیستم مانند وام های فلش نامحدود دارایی های استیبل کوین می تواند باعث شود این طرح در آینده رفتارهای نامطلوبی از خود نشان دهد. در یک مقدار uint256 به اندازه کافی بزرگ، ریختن صریح به یک نوع int256 مقدار آن را کوتاه می کند. در نتیجه، سیستم های خارج از زنجیره، وابسته به دقت انتشار رویداد، ممکن است گمراه شوند.

تعریف مجدد رویداد Swap را در نظر بگیرید تا مستقیماً با مقادیر uint256 سروکار داشته باشد تا توابعی که رویداد را منتشر می کنند بتوانند از ارسال های صریح صرف نظر کنند.

به روز رسانی: در commit 8436c6c رفع شد. تیم 1inch کتابخانه OpenZeppelin's SafeCast را وارد کرد تا با خیال راحت موارد ذکر شده را پخش کند.

[L09] فرآیند برداشت می تواند منجر به کف سازی شود

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

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

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

بروزرسانی: تصدیق شده و برطرف نمی شود.

یادداشت ها و اطلاعات اضافی

[N01] وابستگی های پروژه کاهش یافته

در حین نصب وابستگی های پروژه ، NPM هشدار می دهد که یکی از بسته های نصب شده ، برجسته ، "دیگر پشتیبانی نمی شود یا به روزرسانی های امنیتی را در آینده دریافت می کند".

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

بروزرسانی: در تعهد 0A2B55D ثابت شده است. با این حال ، نصب اکنون به استفاده از پرچ م-force در نسخه های فعلی LTS گره برای موفقیت نیاز دارد.

[N02] هزینه استخر ممکن است سپرده های نامتوازن را تحریک کند

هنگام واریز به قرارداد FixtratesWap ، عملکرد _getVirtualAmountSfordePosit ارزش مجازی سپرده را محاسبه می کند. مبلغ مجازی پس از شارژ هزینه با توجه به نسبت دارایی فعلی استخر ، مبلغ اصلی مقیاس شده است.

اگر کاربر با نسبت فعلی دارایی های موجود در استخر ، وجوه خود را واریز کند ، هزینه های آن هزینه نمی شود. در غیر این صورت ، آنها بر اساس تفاوت بین نسبت سپرده آنها و نسبت دارایی فعلی استخر ، هزینه های آن را شارژ می کنند.

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

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

بروزرسانی: تصدیق شده و برطرف نمی شود.

[N03] الزامات تأیید ضمنی بدون مدارک

قرارداد FixifratesWap به طور ضمنی فرض می کند که قبل از اجرای مبادله و سپرده که لزوماً نشانه ها را منتقل می کنند ، کمک هزینه مناسبی دریافت کرده است.

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

بروزرسانی: تصدیق شده و برطرف نمی شود.

[N04] اعتبار سنجی ضمنی OutputAmount

عملکرد GetRetu سه پارامتر ارائه شده است ، یعنی نشانه ای برای مبادله از (TokenFrom) ، نشانه مبادله به (Tokento) و مقدار ورودی (مقدار ورودی دارایی توکن). مقدار خروجی مربوطه (مبلغ حاصل برای دارایی توکنتو) سپس محاسبه و بازگردانده می شود.

قبل از محاسبه ، این عملکرد نیاز دارد که مقدار InputAmount کمتر از یا مساوی با تعادل توکن استخر دارایی توکنتو باشد. با این حال ، مقدار OutputAmount ، مطمئناً مقدار شهودی تر برای بررسی در برابر تعادل دارایی Tokento ، هرگز به صراحت برای همان شرایط بررسی نمی شود.

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

با این حال ، عمد این رفتار نامشخص است ، یعنی مشخص نیست که آیا این طرح فقط به معنای شکست بیشتر در حین اجرای برای کاهش هزینه گاز است یا خیر. در نظر بگیرید که صریحاً استدلال را برای بررسی دقیق مورد استفاده قرار دهید. علاوه بر این ، اعتبار سنجی را در نظر بگیرید که آیا تعادل دارایی TO بیشتر از مقدار OutputAmount است بر خلاف مقدار InputAmount.

[N05] نامگذاری ناسازگاری

قرارداد FixifratesWap یک جفت صریح از نشانه ها را تنظیم می کند که تعویض ، برداشت و عملیات سپرده گذاری به منظور کار با آن انجام می شود. در طول پایگاه کد ، این نشانه ها با شاخص 0 یا 1 ، مانند Token0 و Token1 برچسب گذاری شده اند. توابعی که به صورت توصیفی برای انتقال جزئیات در مورد استفاده نامگذاری شده اند ، همچنین از آن شاخص های نشانه مانند عملکرد SWAP0TO1 استفاده می کنند.

با این حال ، برای عملکرد عقب نشینی ، پارامتری که نسبت به دریافت Token0 در برابر Token1 را مشخص می کند ، FirstTokenShare نامگذاری شده است که می تواند سردرگمی را نشان دهد که در آن به دارایی Token1 اشاره دارد و نه دارایی Token0.

برای بهبود خوانایی کلی و کاهش سردرگمی احتمالی ، نگه داشتن کنوانسیون های نامگذاری را در کل پایگاه کد در نظر بگیرید.

[N06] بازگشت پیام ها به طور متناقض قالب بندی شده اند

اظهارات مورد نیاز در سازنده قرارداد FixtratesWap متفاوت از سایر موارد دیگر به اظهارات در قرارداد نیاز دارد.

همانطور که پیام های بازگرداندن متناقض می توانند سردرگمی غیر ضروری را معرفی کنند ، اطمینان حاصل کنید که همه اظهارات نیاز به پیام هایی دارند که به طور مداوم فرمت شده ، دقیق ، آموزنده و کاربر پسند هستند.

[N07] استفاده متناقض از متغیرهای برگشتی نامگذاری شده

استفاده متناقض از متغیرهای برگشتی نامگذاری شده در قرارداد FixtratesWap وجود دارد.

به طور خاص ، در حالی که بیشتر توابع متغیرها به نام ، اعشار ، _getVirtualAmountSfordePositImpl ، _getRealAmountSforWithDrawimpl و _checkVirtualAmountSformula به مقادیر صریح باز می گردند.

با از بین بردن کلیه متغیرهای برگشتی ، صریحاً آنها را به عنوان متغیرهای محلی اعلام کنید و در صورت لزوم ، یک رویکرد مداوم برای بازگشت مقادیر در سراسر پایگاه کد را در نظر بگیرید. این امر هم صریح بودن و هم خوانایی کد را بهبود می بخشد ، و همچنین ممکن است به کاهش رگرسیون در طول اصلاحات کد آینده کمک کند.

بروزرسانی: تصدیق شده و برطرف نمی شود.

[N08] بهینه سازی گاز

در قرارداد FixtratesWap ، فرصت هایی برای کاهش مصرف گاز ساده وجود دارد. برای مثال:

• عملکرد خصوصی _getVirtualAmountSfordePosit فقط از یک مکان در پایگاه کد فراخوانی شده است ، و این عملکرد سپرده است. در عملکرد سپرده گذاری برای توکن 0. Balanceof (آدرس (این)) و token1. balanceof (آدرس (این)) وجود دارد. با این حال ، این تماس های دقیقاً مشابه در بالای عملکرد _getVirtualAmountsfordePosit انجام می شود. عملکرد دوم به جای خواندن مانده ها دو بار در هر تماس ، می تواند مقادیر مورد نیاز را منتقل کند.
• در عملکرد خصوصی _getRealAmountSforWithDrawImpl ، متغیر SecondTokenShare به عنوان _one - firstTokenShare تعریف شده است. در خط بعدی ، دقیقاً همان تفریق دوباره انجام می شود که می تواند به سادگی از متغیر SecondTokenShare استفاده کند.

برای کاهش هزینه های گاز و ساده تر کردن پایگاه کد ، پرداختن به نمونه های مطرح شده در بالا را در نظر بگیرید.

[N09] دید نادرست عملکرد

عملکرد RusriveWithRatio توسط هیچ یک از کارکردهای موجود در قرارداد FixtratesWap در داخل کشور نامیده نمی شود. به جای عموم ، دیدگاه خارجی را در نظر بگیرید.

[N10] اعتماد به اعشار ممکن است مشکل ساز باشد

این پروتکل به طور ضمنی مستلزم آن است که هر دو نشانه در داخل یک استخر از روش اعشار برای موفقیت در استخر پشتیبانی کنند. در واقعیت ، این روش تقریباً فراگیر است ، اما از نظر فنی یک مؤلفه اختیاری از مشخصات ERC20 است که در آن صریحاً بیان شده است که قراردادها "نباید انتظار داشته باشند که این مقادیر وجود داشته باشند". در حال حاضر ، هر نشانه ای که از روش اعشار اختیاری پشتیبانی نمی کند ، در پروتکل قابل استفاده نخواهد بود.

شاید از نظر مشکل ساز تر ، به عنوان بخشی از این تماس ها برای نشان دادن اعشار ، پروتکل بیشتر مستلزم آن است که هر دو توکن مقادیر یکسان را برگردانند.

با این حال ، فضای پایدار سکه از این نظر همگن نیست. این شامل بسیاری از نشانه ها است که انواع مختلفی از مقادیر مختلف را برای اعشار برمی گرداند. به عنوان مثال ، در حالی که USDT و USDC 6 اعشار را گزارش می دهند ، DAI از 18 اعشار خبر می دهد.

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

بروزرسانی: در Comment B49D808 ثابت شده است. مستندات درون خطی اضافه شد.

[N11] خطای تایپی

ما خطای تایپوگرافی زیر را در پایگاه کد شناسایی کردیم:

• پیام بازگشت در خط 92 FiredRatesWap. sol بدون نامه بزرگ شروع می شود و این امر را با بقیه کد مغایر می کند.

برای بهبود قوام و خوانایی کلی پایگاه کد ، اصلاح این و هرگونه خطای تایپوگرافی دیگر را در کل پایگاه کد در نظر بگیرید.

[N12] عملکرد غیر ضروری مجازی

قرارداد FixtratesWap از قرارداد ERC20 OpenZeppelin به ارث می برد اما عملکرد ERC20. Decimals خود را نادیده می گیرد. این امر لازم است زیرا نشانه استخر نقدینگی FixratesWap ، وابسته به اعشار دارایی هایی است که استخر را تشکیل می دهند ، لزوماً پویا است.

با این حال ، حتی اگر این اجرای مهم عملکرد باید نهایی باشد ، با کلمه کلیدی مجازی تعریف می شود ، و این سیگنال می دهد که لزوماً یک اجرای نهایی نیست و اجازه می دهد تا دوباره آن را نادیده بگیرد.

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

نتیجه گیری

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