دسامبر 1، 2021
UMA پلتفرمی است که به کاربران امکان می دهد قراردادهای مالی با حداقل اعتماد را در بلاک چین اتریوم وارد کنند. قبلا حسابرسی کردیم اوراکل غیرمتمرکز, یک الگوی قرارداد مالی خاص, برخی از درخواست های کشش موقت, الگوی چند حزبی دائمی و درخواست های مختلف کشش افزایشی در یک تعامل طولانی تر. در این ممیزی، مکانیزم جدیدی برای ارسال سریع توکنها از زنجیره لایه 2 به شبکه اصلی اتریوم و تغییرات مربوط به Optimistic Oracle را بررسی کردیم. بررسی توسط 2 حسابرس طی 3 هفته تکمیل شد.
حوزه
تعهد حسابرسی شده است f24ad501c8e813cf685f72217e7f13c8f3c366df
و دامنه شامل قراردادهای زیر است:
- قراردادها/بیمه پل/* (به استثنای قراردادهای آزمایشی)
- قراردادها-اوم/بیمه-پل/اجرا/*
- contracts/common/implementation/AncillaryData.sol
- contracts/oracle/implementation/SkinnyOptimisticOracle.sol
ما همچنین تغییرات فایل های solidity را بررسی کردیم Pull Request 3445.
همه کدهای خارجی و وابستگیهای قرارداد طبق مستندات کار میکنند.
بررسی اجمالی سیستم
زنجیره های لایه 2 (L2) پشتیبانی شده، Optimism و Arbitrum، مکانیزمی را برای انتقال وجوه به شبکه اصلی اتریوم (L1) ارائه می دهند. با این حال، به دلایل امنیتی، تاخیر قابل توجهی قبل از نهایی شدن این انتقال وجود دارد. برای رفع این مشکل، دارندگان توکن L2 می توانند وجوهی را در یک قرارداد UMA، صندوق سپرده، واریز کنند، زیرا بدانند که توکن ها در نهایت (به صورت دسته ای) به قرارداد L1 UMA، Bridge Pool منتقل می شوند. برای هر توکنی که باید منتقل شود، یک بریج استخر جداگانه وجود دارد.
پس از واریز L2، هر کسی میتواند جزئیات را به L1 Bridge Pool منتقل کند، که در صورتی که کسی بخواهد اطلاعات ارسالی را به چالش بکشد، مدت کوتاهی منتظر میماند. همه اختلافات توسط Skinny Optimistic Oracle رسیدگی می شود (در زیر توضیح داده شده است). قبل از پذیرش رله، ارائهدهندگان نقدینگی باید قرارداد Bridge Pool را در ازای توکنهای LP پیشپرداخت کنند. رلههای بلامنازع معتبر فرض میشوند، و Bridge Pool با استفاده از ذخایر خود، انتقال را تکمیل میکند، جایی که کسری از انتقال به رله منحرف میشود و کسری به عنوان کارمزد نقدینگی باقی میماند. وجوه در نهایت با نهایی شدن سپرده L2 تکمیل می شود و کارمزد نقدینگی به دارندگان توکن LP اختصاص می یابد.
Bridge Pool همچنین به هر کسی اجازه میدهد تا قبل از انقضای دوره اختلاف، در ازای کسری از مبلغ انتقال، بهصورت جداگانه (بدون ذخایر بریج استخر) یک انتقال را تأمین مالی کند. از آنجایی که رله هنوز می تواند مورد مناقشه باشد، اگر رله نادرست تشخیص داده شود، این وجوه از بین می رود. انتظار می رود که در بیشتر موارد، این مکانیسم به کاربران اجازه می دهد تا انتقال سریع توکن L2 به L1 را تجربه کنند.
Skinny Optimistic Oracle از نظر مفهومی بسیار شبیه به Optimistic Oracle موجود است. این یک مکانیسم انگیزشی برای کاربران فراهم می کند تا به سادگی نتیجه یک درخواست اوراکل را اعلام کنند، که اگر مورد مناقشه قرار نگیرد، فرض می شود که دقیق است. اختلافات به مکانیسم کندتر DVM که در گزارش های حسابرسی قبلی ما توضیح داده شده است، منتهی می شوند. تفاوت اصلی این است که نسخه جدید کاربران را ملزم می کند که تمام اطلاعات مربوطه را هنگام اجرای فراخوانی تابع ارائه دهند، بنابراین مقادیر نیازی به ذخیره یا بازیابی از حافظه ندارند. همچنین توانایی درخواست کنندگان برای تغییر پارامترهای پیکربندی در درخواست های فعال را حذف می کند.
ما قبلاً قرارداد جفت بلند-کوتاه را بررسی کردهایم که مکانیزمی کلی برای ایجاد ابزارهای مالی مختلف ارائه میدهد. این قراردادها زمانی قابل حل است که زمان انقضای آنها تمام شود و قیمت تسویه آن مشخص باشد. تغییرات ارائه شده توسط Pull Request 3445 امکان حل و فصل زودهنگام قراردادها را در صورت معلوم بودن قیمت تسویه قبل از زمان انقضا فراهم می کند.
نقش های ممتاز
صندوق های سپرده L2 دارای چندین پارامتر پیکربندی هستند، از جمله توکن های پشتیبانی شده و حداکثر نرخ ارسال توکن های دسته ای از روی پل به L1. آنها همچنین باید برای اطمینان از سازگاری بین قرارداد توکن L1، قرارداد توکن L2 و Bridge Pool مربوطه پیکربندی شوند. این پارامترها توسط یک قرارداد مدیر در L1 تنظیم می شوند که روند حل اختلاف استخرهای پل را نیز پارامتر می کند. انتظار می رود قرارداد توسط مکانیزم حاکمیت UMA کنترل شود، بنابراین کاربران باید برای مدیریت معقول و منصفانه سیستم به این فرآیند اعتماد کنند.
وابستگی های اکوسیستم
همه مؤلفه های بررسی شده از منطق مبتنی بر زمان استفاده می کنند، به این معنی که به در دسترس بودن اتریوم بستگی دارند. به ویژه، اگر معاملات اختلاف به طور قابل توجهی به تاخیر بیفتد، ممکن است رله های نامعتبر یا پیشنهادات قیمت به اشتباه تأیید شوند.
علاوه بر این، پل توکن به طور ضمنی فرض می کند که تمام وجوه ارسال شده به صندوق های سپرده L2 در نهایت به استخر پل L1 مربوطه منتقل می شود. این بر عملکرد صحیح و مستمر پل های خوش بینی و آربیتروم و مکانیسم های حل اختلاف آنها متکی است.
در نهایت، توکن های ارسال شده به صندوق سپرده L2 به بریج استخر در L1 اختصاص داده می شوند، نه گیرنده مورد نظر. برای بازیابی وجوه از استخر، دارندگان توکن L1 ابتدا باید آنها را با توکن های اضافی مطابقت دهند. بنابراین، این مکانیسم به بازار به اندازه کافی عمیق از توکن های L1 متکی است تا اطمینان حاصل شود که همیشه نقدینگی وجود دارد.
مشکلات گزارش شده توسط مشتری
در طول ممیزی، تیم UMA به طور مستقل تعدادی از مسائل و رفتارها را شناسایی کرد که ارزش برجسته کردن دارند:
اگر پارامترهای Optimistic Oracle یا Bridge Admin در طول دوره چالش یک رله تغییر کند، در این صورت بحث در مورد رله باعث حذف رله می شود بدون اینکه هیچ کمک دیگری برای پیشنهاد دهنده یا مناقشه کننده وجود نداشته باشد. به عنوان مثال، تصور کنید که رله برای توکن وثیقه ارسال شده است
TOKEN_A
، اما در وسط رلهTOKEN_A
از لیست سفید وثیقه حذف می شود. اکنون یک اختلاف برمیگردد زیرا نمیتوانید هیچ درخواست قیمتی را برای وثیقه بدون فهرست به OO یا DVM ارسال کنید. از آنجایی که نمیخواهیم درخواستهای اعتراض معتبر را مسدود کنیم،BridgePool
رله معلق برای را حذف می کندTOKEN_A
در صورت اختلاف پیامدهای این تصمیم طراحی عبارتند از:
1. افزایش در هزینه نهایی باعث می شود: هر گونه رله معوق در آن توکن از طریق اختلاف درست یا نادرست «قابل لغو» شود. لغو به نفع هیچ یک از طرفین نیست، بنابراین وجود مخالفان صادقی را فرض می کند که مایلند درخواست بد (نادر) را که اتفاقاً در طول اجرای تغییر هزینه نهایی وجود دارد، از بین ببرند. این همچنین به این معنی است که ممکن است یک فرد غمگین برای لغو رله ها گاز مصرف کند و آنها را مجبور به رله مجدد کند.
2. حذف لیست سفید از شناسه یا نشانه، که نباید اتفاق بیفتد مگر اینکه مشکلی بسیار اشتباه پیش بیاید که باعث شود:
3. یک دوره طولانی درخواست های غیرقابل انکار که در آن هر درخواستی می تواند لغو شود و هیچ انگیزه اقتصادی برای اختلاف وجود ندارد. این به نظر بهتر از جایگزینی برای مسدود کردن کامل اختلافات است، اما مسلماً بسیار بد است، زیرا هر غمگینی می تواند رله ها را به طور نامحدود با پرداخت گاز مسدود کند یا رله های بد را بدون مجازات ارسال کند (به غیر از هزینه گاز).توجه: این جایگزینی برای داشتن OO است که پارامترهایی مانند کارمزد نهایی یا لیست سفید وثیقه را برای مدتی «تجمیع» میکند، اما این امر مستلزم تماسهای اضافی با OO است که برای مسیر شاد پرهزینه خواهد بود.
رله ها را می توان از طریق افزایش سرعت داد
speedUpRelay()
پس از عبور از سرزندگی در حالی که ما هیچ خطری در این مورد نمی بینیم، امکان وام های فلش + افزایش سرعت + تسویه پس از زنده بودن را فراهم می کند و به وام گیرنده فلش هزینه رله فوری را به صورت "رایگان" می دهد. ما در این پیشنهاد از این امر جلوگیری می کنیم PR.
On
settle
، اگرBridgePool
هست یکWETH
استخر و گیرنده قراردادی است که نیستpayable
(نمی توان ETH را قبول کرد)، پسsettle
شکست خواهد خورد. ما قصد داریم این مشکل را برطرف کنیم و پس از ارسال مجددWETH
، اما هنوز کار برجسته ای در این زمینه انجام نشده است.
In
relayDeposit
، بررسی می کنیم کهBridgePool
موجودی بزرگتر از مقداری است که باید به علاوه اوراق پیشنهادی را انتقال داد. این یک چک منسوخ و بسیار محافظه کارانه است زیرا پس از بررسی، اوراق قرضه پیشنهاد دهنده از کاربر خارج می شود. ما در این پیشنهاد به این موضوع می پردازیم PR.
من فقط یک حشره گرفتار که در آن
chainId
inBridgePool
، به عنوان بخشی ازDeposit
ساختار و به عنوان ورودی تابع برای همه توابع مرتبط با رله (به عنوان مثالrelayDeposit
,speedUpRelay
,settle
) نوع استuint8
. این برای رسیدگی به Arbitrum بسیار کوچک است، به عنوان مثال شناسه آن 421611 است. ما در واقع این اشکال را پیدا کردیم و آن را در سمت L2 برطرف کردیم:BridgeDeposit
آن را تنظیم کرده استchainId
تایپ بهuint256
. این روابط عمومی باعث می شودchainId
onBridgePool
مطابق با نوعBridgeDepositBox
: UMAprotocol/protocol#3463
قبلاً، تابع اختلاف مبلغ سپرده را از آن کم نمی کرد
pendingReserves
(این متغیری است که ردیابی می کند که چه مقدار از استخر ذخیره به دلیل رله هایی که هنوز ته نشین نشده اند قفل شده است). نتیجه این بود که هر اختلاف به طور نامحدود مقدار رله را در استخر قفل می کرد. نمی توان آن را توسط LP ها برداشت یا توسط رله های آینده استفاده کرد. رفع مشکل اینجاست: UMAprotocol/protocol#3473.
ما یک اشکال پیدا کردیم
BridgeDepositBox
جایی کهhasEnoughTimeElapsedToBridge
بررسی نمی کند که آیا auint256
ارزش برابر است با0
به صورت پیش فرض: در PR 3484 ثابت شد
روش نرخ مبادله (که تغییر حالت است) بین توکنهایی که به داخل منتقل میشوند و توکنهای LP که در روش addLiquidity در قرارداد بریج استخر ضرب میشوند، فراخوانی میشود. این محاسبه باید به بالای روش منتقل شود. این باعث ایجاد مقادیر حالت بسیار عجیب می شود. به روابط عمومی مراجعه کنید اینجا کلیک نمایید برای تعمیر.
روش مشاهده
liquidityUtilizationPostRelay
(که فقط به صورت غیر زنجیره ای استفاده می شود)، یک شماره استفاده نادرست را گزارش می دهد. مخرج روشن است این خط نباید فقط باشدliquidReserves
، در عوض باید نمایشی از ذخایر استفاده نشده و استفاده شده باشد. درست شد اینجا کلیک نمایید.
بروزرسانی
علاوه بر رفع مشکل، تغییرات تدریجی زیر را نیز بررسی کردیم:
- PR3500 پارامتر توکن اضافی را از
BridgePool
مناسبت ها. - PR3478 هزینه نهایی DVM را به لیست متغیرهای کش محلی اضافه می کند.
- PR3460 یک مورد احتمالی لبه استفاده از نقدینگی منفی را به حساب می آورد (علاوه بر پرداختن به N04)
- PR3482 فایل های اضافی را حذف می کند و ثابت های OVM را مطابق با تغییرات OVM 2.0 به روز می کند.
- PR3585 را به روز می کند
BridgeDepositBox
رابط برای سازگاری و استفاده از OpenZeppelinSafeERC20
کتابخانه
در حین بررسی اصلاحات، مشکل دیگری را شناسایی کردیم. هنگام تعیین ارزش BridgePool
نشانه های LP، وجود دارد محاسبه میانی که می تواند به طور غیرمنتظره ای سرریز منفی کند، که به طور موقت افزودن و حذف نقدینگی را غیرفعال می کند. محاسبه باید دوباره ترتیب داده شود تا قبل از کسر هزینه های توزیع نشده، ذخایر استفاده شده اضافه شود.
شدت بحرانی
[C01] پاداش پیشنهاد دهنده به دام افتاده
La LongShortPair
قرارداد یک جایزه پیشنهاد دهنده را بازیابی می کند از هر آدرسی که باعث انقضا می شود، که برای تشویق پیشنهادات قیمت در Optimistic Oracle استفاده می شود. با این حال LongShortPairCreator
قرارداد نیز وجوه را بازیابی و ارسال می کند از آدرس پخش کننده این وجوه اضافی به Optimistic Oracle منتقل نمی شود، و در عوض در دام می ماند LongShortPair
قرارداد.
حذف انتقال تکراری را در نظر بگیرید.
به روز رسانی: از زمان تعهد ثابت شد 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
شدت بالا
[H01] رله های همزمان ذخایر را تخلیه می کنند
La relayDeposit
عملکرد BridgePool
قرارداد تضمین می کند که قرارداد دارای بودجه کافی است برای اجرای انتقال با این حال، آن را به حساب نمی آورد ذخایر معلق، که وجوهی را که برای رله های فعال در نظر گرفته شده است را ردیابی می کند. بنابراین، چندین رله همزمان ممکن است به یک وجوه متکی باشند، و ممکن است همه آنها بلافاصله قابل تسویه نباشند. به ویژه، با یک جریان ثابت از انتقال، بازگشت رله فوری ممکن است به طور نامحدود به تاخیر بیفتد.
جلوگیری از رله هایی که باعث می شود ذخایر معلق از ذخایر مایع بیشتر شود را در نظر بگیرید.
به روز رسانی: از زمان تعهد ثابت شد 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] مرزهای پارامتر پل زدن مطابقت ندارند
La deposit
تابع از BridgeDepositBox
قرارداد، مستقر در زنجیره های لایه 2، برای پل زدن وجوه بین L2 و L1 استفاده می شود. به طور خاص، رله ها انگیزه دارند رله جزئیات تراکنش در L1 مرتبط BridgePool
. با این حال، صندوق امانات استفاده می کند محدوده های فراگیر برای محدود کردن هزینه های رله، در حالی که استخر پل استفاده می کند محدوده های انحصاری. این بدان معنی است که برخی از سپرده ها (با 25 درصد کارمزد رله) قابل رله نیستند و وجوه در هر دو لایه غیر قابل دسترسی خواهد بود.
برای اطمینان از اینکه همه سپرده های معتبر می توانند رله شوند، اعتبارسنجی ها را در هر دو لایه هماهنگ کنید.
به روز رسانی: در commit ثابت شد 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. این در ابتدا بهعنوان شدت بحرانی طبقهبندی میشد، اما زمانی که تیم UMA اشاره کرد که وجوه بهشدت در دام نمیافتند و در صورتی که رایدهندگان DVM با پذیرش توضیح رله اصلاحشده برای سپردههای تحتتأثیر موافقت کنند، میتوان آن را آزاد کرد.
شدت متوسط
[M01] پاسخ به آدرس اشتباه
La SkinnyOptimisticOracle
در صورت وجود، توابع برگشت به تماس را بر روی درخواست کننده قیمت فراخوانی می کند، بنابراین درخواست کننده می تواند به تغییرات قابل توجه وضعیت پاسخ دهد. با این حال، تماس برگشتی به اشتباه در پیشنهاد دهنده قیمت به جای درخواست کننده قیمت در درخواست کننده است. la proposePriceFor
تابع. این بدان معنی است که درخواست کننده قیمت نمی تواند به پیشنهادات قیمت پاسخ دهد.
خوشبختانه، این ویژگی در کد پایه فعلی استفاده نمی شود. با این وجود، فراخوانی را در نظر بگیرید priceProposed
پاسخ به درخواست کننده
به روز رسانی: در commit ثابت شد 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] عملکرد ضمیمه معیوب
La appendKeyValueBytes32
تابع باید ورودی های خود را در قالب فرمت شده ترکیب کند bytes
آرایه. با این حال currentAncillaryData
is به اشتباه دور انداخته شده است.
از آنجایی که داده های جانبی بر روند حل اوراکل تأثیر می گذارد، یک مقدار نادرست می تواند نتایج اوراکل را تضعیف کند. خوشبختانه فقط وجود دارد یک تماس به appendKeyValueBytes32
در پایگاه کد، و از یک خالی استفاده می کند currentAncillaryData
بافر، بنابراین اشکال بر این مورد تأثیر نمی گذارد.
به روز رسانی را در نظر بگیرید appendKeyValueBytes32
عملکرد به طوری که currentAncillaryData
در آرایه بایت های برگشتی گنجانده شده است.
به روز رسانی: در commit ثابت شد 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] اعتبار سنجی داده های جانبی ناقص
La LongShortPair
سازنده تایید می کند که customAncillaryData
به اندازه کافی کوچک است. با این حال، آن را به حساب نمی آورد زمینه انقضای زودرس. این به معنای اوراکل خوش بینانه است ممکن است به طور غیر منتظره رد کند درخواست قیمت انقضای زودهنگام، که این ویژگی را غیرفعال می کند.
برای در نظر گرفتن فیلد اضافی، اعتبارسنجی را بهروزرسانی کنید.
به روز رسانی: از زمان تعهد ثابت شد 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] مُهر زمان صفر نادرست
در LongShortPair
قرارداد، مهر زمانی صفر انقضا زودرس است به عنوان پرچم استفاده می شود نشان می دهد که هیچ کس مکانیسم انقضای زودهنگام را راه اندازی نکرده است. با این حال، ممکن است آن مکانیسم را فعال کند با مهر زمانی صفر در این سناریو، Optimistic Oracle فراخوانی خواهد شد اما محافظت در برابر درخواست های بعدی قیمت موثر نخواهد بود. خوشبختانه یک بار قیمت تسویه حساب انتخاب می شود، لغو نمی شود، بنابراین به تسویه حساب های ناسازگار منجر نمی شود. با این وجود، درخواست قیمت بعدی می تواند مهر زمان انقضای اولیه ثبت شده را تغییر دهید، حتی اگر از مهر زمانی صفر برای تعیین قیمت تسویه استفاده شود. همچنین می تواند یک رویداد گمراه کننده منتشر کند.
با استفاده از مهر زمانی صفر، از انقضای زودهنگام جلوگیری کنید.
به روز رسانی: از زمان تعهد ثابت شد 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] پیوند صفر احتمالی
La requestPrice
عملکرد SkinnyOptimisticOracle
قرارداد از کارمزد نهایی به عنوان اوراق قرضه استفاده می کند اگر اوراق قرضه مشخص نشده باشد. با این حال requestAndProposePriceFor
تابع ممکن است از پیوند صفر استفاده کند، که با آن در تضاد است @notice
و @param
نظرات. باند صفر انگیزه در برابر پیشنهاد یا اختلافات نامعتبر را تضعیف می کند.
خوشبختانه، فقط به این تابع فراخوانی کنید در پایه کد یک پیوند پیشنهاد دهنده را تنظیم می کند. با این وجود، اگر اوراق قرضه مشخص نشده باشد، از کارمزد نهایی استفاده کنید.
به روز رسانی: از زمان تعهد ثابت شد daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] امتیازات غیر ضروری مدیر
La BridgePool
قرارداد ارث می برد از ExpandedERC20
تا بتواند توکن های LP را برای ارائه دهندگان نقدینگی صادر کند. این کارکرد OpenZeppelin را به ارث می برد ERC20
قرارداد و همچنین امتیازات مدیر را فراهم می کند به توزیع کننده قرارداد، که به آنها امکان می دهد توکن های LP را ضرب و رایت کنند. با این حال، این اختیار لازم نیست و در صورت اعمال، می تواند به طور غیرمنصفانه تامین کنندگان نقدینگی را جریمه کند.
اصلاح را در نظر بگیرید BridgePool
به طور مستقیم از ERC20
بجای ExpandedERC20
.
به روز رسانی: در commit ثابت شد 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
شدت کم
[L01] در زمان انقضا نمی تواند ته نشین شود
La settle
عملکرد LongShortPair
قرارداد شرایط اسکان را در نظر می گیرد زمانی که زمان فعلی کاملاً قبل یا بعد از مهر زمانی انقضا باشد. با این حال، زمانی که زمان فعلی با مهر زمانی انقضا مطابقت داشته باشد، به اشتباه برمیگردد.
برای تطبیق با آن از یک قید فراگیر استفاده کنید postExpiration
تغییر.
به روز رسانی: در commit ثابت شد f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] پیام خطا در عبارت مورد نیاز وجود ندارد
یک بیانیه الزامی در وجود دارد BridgePool
قرارداد بدون پیغام خطا
در تمام عبارات مورد نیاز، پیام های خطای خاص و آموزنده را در نظر بگیرید.
به روز رسانی: از زمان تعهد ثابت شد 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] رشتههای مستند وجود ندارد
مواردی در سرتاسر پایگاه کد وجود دارد که در آن مشخصات طبیعی اتریوم غایب یا ناقص است مثالها عبارتند از:
مستندسازی کامل همه توابع (و پارامترهای آنها) که بخشی از API عمومی قراردادها هستند را در نظر بگیرید.
به روز رسانی: نظرات برجسته شده در commit ثابت شدند e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. ما کامل بودن NatSpec را در بقیه کدهای پایه تأیید نکردیم.
یادداشت ها و اطلاعات تکمیلی
[N01] مقدار برگشتی تماس بررسی نشده است
در deposit
تابع از L2 BridgeDepositBox
قرارداد یک تماس سطح پایین به وجود دارد l2Token
وقتی که l1Token
is l1Weth
. این تماس سطح پایین به deposit()
تابع، که متعلق به WETH رابط. اگر این l2Token
دقیقاً مانند WETH رفتار می کند و هرگز نباید شکست بخورد. اما در مورد l2Token
رفتار متفاوتی دارد و ناموفق است، هیچ بازگشتی وجود نخواهد داشت زیرا پرچم موفقیت این تماس سطح پایین هرگز بررسی نمی شود.
بررسی و واکنش مناسب به مقادیر بازگشتی همه تماسهای سطح پایین را در نظر بگیرید.
[N02] عدم وجود پارامترهای نمایه شده در رویدادها
بسیاری از رویدادهای تعریف شده در این پایگاه کد دارای پارامترهایی هستند که باید ایندکس شوند:
در نظر بگیرید نمایه سازی پارامترهای رویداد برای جلوگیری از ایجاد مانع در جستجوی خدمات خارج از زنجیره و فیلتر کردن رویدادهای خاص.
به روز رسانی: تا حدی در تعهد ثابت شده است d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. chainId
پارامتر از WhitelistToken
آپدیت نشد
[N03] ناسازگاری ریخته گری ضمنی
La LongShortPair
قرارداد به طور کلی با مهر زمانی به عنوان uint64
ارزش، که به طور ضمنی به آن ریخته می شوند uint256
ارزش زمانی که به اوراکل خوش بینانه منتقل شد. با این حال requestTimestamp
پارامتر از la _requestOraclePrice
تابع پیش از موعد به الف ریخته می شود uint256
. این هیچ عواقب عملکردی ندارد.
با این وجود، به منظور سازگاری، استفاده از a را در نظر بگیرید uint64
برای این پارامتر و اجازه می دهد که به طور ضمنی به a فرستاده شود uint256
زمانی که به اوراکل خوش بینانه منتقل شد.
به روز رسانی: در commit ثابت شد 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. مهر زمان اکنون به صراحت ریخته شده است.
[N04] نوع نادرست
La sendMessage
عملکرد iOptimism_CrossDomainMessenger
رابط با استفاده از uint256
حد گاز در حالی که خوش بینی است OVM_CrossDomainEnabled
با استفاده از uint32
حد گاز.
برای ثبات و قابل پیش بینی بودن، به روز رسانی را در نظر بگیرید iOptimisim_CrossDomainMessenger
sendMessage
تابع برای استفاده از a uint32
حد گاز
به روز رسانی: از زمان تعهد ثابت شد 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] عدم اعتبارسنجی
همه توابع در BridgeAdmin
آن تماس _relayMessage
فرض کنید ارزش معامله مطابقت دارد l1CallValue
پارامتر، اما این اعمال نمی شود.
اطمینان از صحیح را در نظر بگیرید msg.value
تنظیم شده است
به روز رسانی: از زمان تعهد ثابت شد f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] خوانایی
La _getDepositHash
تابع از BridgePool
قرارداد باز می شود depositData
struct به interstice l1Token
به عنوان استدلال در ترکیب keccak256
با abi
رمزگذاری این باعث می شود که عملیات به صورت غیر ضروری پرمخاطب باشد و در صورت اجرای مجدد در لایه های دیگر منجر به ایجاد اشکال شود.
ساده کردن آرگومان ها را در نظر بگیرید تا به سادگی جفت مرتب شده باشند depositData
و l1Token
.
به روز رسانی: از زمان تعهد ثابت شد 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] تابع ورود مجدد
La requestAndProposePriceFor
تابع از SkinnyOptimisticOracle
قرارداد با یک غیرقابل اعتماد تماس می گیرد msg.sender
اما توسط a محافظت نمی شود nonReentrant
اصلاح کننده در حالی که، در این مثال، به نظر نمی رسد که این یک نگرانی امنیتی باشد، این می تواند رفتار غیرمنتظره ای را معرفی کند.
اضافه کردن را در نظر بگیرید nonReentrant
تعدیل کننده تمام توابع که با قراردادهای احتمالاً نامعتبر تماس می گیرند.
به روز رسانی: در commit ثابت شد b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
وارد نشده است
La relayMessage
تابع از Arbitrum_Messenger
قرارداد پس از اجرای یک اقدام حساس، رویداد مربوطه را منتشر نمی کند. این relayMessage
تابع به عنوان یک زیر برنامه فراخوانی می شود sentTxToL2NoAliasing
که خود آن را برمی گرداند uint256
ارزش seqNum
، اما این مقدار بازگشتی وارد نشده است relayMessage
تابع.
برای تسهیل ردیابی و اطلاع رسانی به مشتریان خارج از زنجیره پس از فعالیت قرارداد، رویدادهایی را پس از وقوع تغییرات حساس منتشر کنید.
به روز رسانی: از زمان تعهد ثابت شد 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] اشتباهات تایپی
پایگاه کد حاوی اشتباهات املایی زیر است:
برای بهبود خوانایی کد، این اشتباهات تایپی را تصحیح کنید.
به روز رسانی: از زمان تعهد ثابت شد 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] مورد نیاز تایید ERC20 بدون سند
La requestEarlyExpiration
و expire
توابع از LongShortPair
هر یک از قراردادها فرض می کنند که تماس گیرنده به قرارداد کمک هزینه ای اعطا کرده است پاداش پیشنهاد دهنده را بکشید.
برای پیش بینی پذیری، مستند کردن این نیاز را در نظرات تابع در نظر بگیرید.
به روز رسانی: در commit ثابت شد da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] اصلاح کننده استفاده نشده
در BridgePool
قرارداد، onlyFromOptimisticOracle
تغییر تعریف شده است اما هرگز در پایگاه کد استفاده نمی شود و بنابراین باید حذف شود.
به روز رسانی: در commit ثابت شد 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
نتیجه گیری
2 مورد بحرانی و 1 مورد با شدت بالا پیدا شد. برخی تغییرات برای پیروی از بهترین شیوه ها و کاهش سطح حمله احتمالی پیشنهاد شد.
- &
- 7
- حساب
- عمل
- فعال
- Ad
- اضافی
- نشانی
- مدیر سایت
- مزیت - فایده - سود - منفعت
- معرفی
- اجازه دادن
- API
- استدلال
- حسابرسی
- دسترس پذیری
- بودن
- بهترین
- بهترین شیوه
- بلاکچین
- جعبه
- بریج
- اشکال
- اشکالات
- صدا
- موارد
- گرفتار
- علت
- به چالش
- تغییر دادن
- بررسی
- رمز
- نظرات
- پیکر بندی
- شامل
- قرارداد
- قرارداد
- میتوانست
- جاری
- داده ها
- غیر متمرکز
- تاخیر
- طرح
- تعیین
- DID
- اختلاف نظر
- نمی کند
- در اوایل
- اقتصادی
- لبه
- موثر
- ERC20
- ETH
- ethereum
- blockchain اتریوم
- واقعه
- حوادث
- مثال
- تبادل
- انتظار می رود
- تجربه
- ویژگی
- هزینه
- مالی
- نام خانوادگی
- رفع
- فلاش
- به دنبال
- یافت
- تابع
- صندوق
- بودجه
- آینده
- GAS
- هزینه گاز
- دادن
- حکومت
- خوشحال
- داشتن
- اینجا کلیک نمایید
- زیاد
- برجسته
- دارندگان
- چگونه
- HTTPS
- تشویق
- مشمول
- از جمله
- افزایش
- اطلاعات
- علاقه
- رابط
- مسائل
- IT
- شناخته شده
- رهبری
- کتابخانه
- مایع
- نقدینگی
- تأمین کنندگان نقدینگی
- فهرست
- وام
- به صورت محلی
- قفل شده
- LP
- LP ها
- بازار
- مسابقه
- اکثر
- باز کن
- وحی
- دیگر
- سکو
- استخر
- استخرها
- قدرت
- جلوگیری
- قیمت
- روند
- طرح پیشنهادی
- ارائه
- فراهم می کند
- عمومی
- دلایل
- كاهش دادن
- گزارش ها
- REST
- نتایج
- بازده
- این فایل نقد می نویسید:
- خطر
- تیم امنیت لاتاری
- خدمات
- تنظیم
- توافق
- کوتاه
- قابل توجه
- مشابه
- کوچک
- So
- استحکام
- کسی
- چیزی
- سرعت
- خرج کردن
- دولت
- بیانیه
- ذخیره سازی
- موفقیت
- پشتیبانی
- سطح
- سیستم
- آزمون
- از طریق
- سراسر
- زمان
- رمز
- نشانه
- بالا
- پیگردی
- معامله
- معاملات
- اعتماد
- بروزرسانی
- به روز رسانی
- یو پی اس
- کاربران
- ارزش
- چشم انداز
- لیست سفید
- WHO
- در داخل
- بدون
- مهاجرت کاری
- با ارزش
- صفر