דצמבר 1, 2021
UMA היא פלטפורמה המאפשרת למשתמשים להזין חוזים פיננסיים ממוזערים באמון ב-Ethereum blockchain. ביצענו בעבר ביקורת האורקל המבוזר, תבנית חוזה פיננסי מסוים, כמה בקשות משיכה אד-הוק, התבנית רב-צדדית תמידית ו בקשות משיכה מצטברות שונות במהלך התקשרות ארוכה יותר. בביקורת זו סקרנו מנגנון חדש לשליחת אסימונים מהירה משרשרת שכבה 2 לרשת Ethereum, ושינויים נלווים ל-Oracle האופטימי. הסקירה הושלמה על ידי 2 רואי חשבון במשך 3 שבועות.
היקף
ההתחייבות המבוקרת היא f24ad501c8e813cf685f72217e7f13c8f3c366df
וההיקף כולל את החוזים הבאים:
- חוזים/גשר מבוטח/* (לא כולל חוזי בדיקה)
- חוזים-ovm/מבוטח-גשר/יישום/*
- חוזים/משותף/יישום/AncillaryData.sol
- חוזים/אורקל/יישום/SkinnyOptimisticOracle.sol
סקרנו גם את השינויים בקבצי מוצק ב בקשה למשוך 3445.
ההנחה הייתה שכל הקוד החיצוני וההתלות בחוזה פועלים כפי שתועדו.
סקירת המערכת
רשתות שכבה 2 (L2) הנתמכות, Optimism ו-Arbitrum, מספקות מנגנון להעברת כספים ל-Ethereum mainnet (L1). עם זאת, מסיבות ביטחוניות, קיים עיכוב משמעותי לפני סיום ההעברות הללו. כדי לטפל בזה, מחזיקי אסימון L2 יכולים להפקיד כספים בחוזה UMA, ה-Deposit Box, בידיעה שהאסימונים יועברו בסופו של דבר (כמו אצווה) לחוזה L1 UMA, מאגר הגשר. יש בריכת גשר נפרדת לכל אסימון שיועבר.
לאחר הפקדת L2, כל אחד יכול להעביר את הפרטים למאגר L1 Bridge, אשר ממתין תקופה קצרה למקרה שמישהו ירצה לערער על המידע המועבר. כל המחלוקות מטופלות על ידי ה-Skinny Optimistic Oracle (מתואר להלן). לפני קבלת הממסר, ספקי נזילות חייבים לממן מראש את חוזה ברידג' בתמורה לאסימוני LP. ממסרים ללא עוררין נחשבים תקפים, ומאגר הגשר משלים את ההעברה באמצעות רזרבות משלו, כאשר חלק מההעברה מופנה לממסר וחלק נשמר כעמלות נזילות. הכספים יתמלאו בסופו של דבר כאשר ההפקדה L2 תושלם, ודמי הנזילות יוקצו למחזיקי אסימון ה-LP.
מאגר הברידג' גם מאפשר לכל אחד לממן באופן פרטני העברה (ללא רזרבות ברידג') לפני תום תקופת המחלוקת, בתמורה לשבריר מסכום ההעברה. מכיוון שעדיין ניתן לערער על הממסר, כספים אלה יאבדו אם הממסר ייחשב כלא תקין. צפוי שברוב המקרים, מנגנון זה יאפשר למשתמשים לחוות העברות אסימון L2-to-L1 מיידיות.
ה-Skinny Optimistic Oracle דומה מאוד מבחינה רעיונית לאורקל האופטימי הקיים. הוא מספק מנגנון תמריץ למשתמשים פשוט לטעון את התוצאה של בקשת אורקל, אשר מניחים שהיא מדויקת אם אין עליה מחלוקת. מחלוקות נדחקות למנגנון ה-DVM האיטי יותר שתואר בדוחות הביקורת הקודמים שלנו. ההבדל העיקרי הוא שהגרסה החדשה דורשת מהמשתמשים לספק את כל המידע הרלוונטי בעת ביצוע קריאות לפונקציות, כך שאין צורך לשמור או לאחזר את הערכים מהאחסון. זה גם מסיר את היכולת של מבקשים לשנות פרמטרים של תצורה בבקשות פעילות.
סקרנו בעבר את חוזה Long-Short-Pair, המספק מנגנון גנרי ליצירת מכשירים פיננסיים שונים. חוזים אלו ניתנים לפתרון כאשר מועד פקיעת התוקף שלהם מגיע ומחיר הפשרה ידוע. השינויים שהוכנסו על ידי Pull Request 3445 מציגים את האפשרות לפתור את החוזים מוקדם אם מחיר הפשרה ידוע לפני מועד התפוגה.
תפקידים מיוחסים
לקופסאות ההפקדה של L2 יש מספר פרמטרים של תצורה, כולל האסימונים הנתמכים והקצב המקסימלי לשליחת אסימונים אצווה מעל הגשר ל-L1. יש להגדיר אותם גם כדי להבטיח עקביות בין חוזה האסימון L1, חוזה האסימון L2 ומאגר הגשר המקביל. פרמטרים אלו נקבעים על ידי חוזה מנהל ב-L1, אשר גם קובע את תהליך יישוב המחלוקות של בריכות הגשר. החוזה צפוי להיות בשליטת מנגנון הממשל של UMA, כך שהמשתמשים חייבים לסמוך על תהליך זה לנהל את המערכת בצורה נבונה והוגנת.
תלות במערכת אקולוגית
כל הרכיבים שנבדקו משתמשים בלוגיקה מבוססת זמן, מה שאומר שהם תלויים בזמינות Ethereum. בפרט, אם עסקאות מחלוקת מתעכבות באופן משמעותי, ייתכן שמסרים לא חוקיים או הצעות מחיר יאושרו באופן שגוי.
בנוסף, גשר האסימונים מניח באופן מרומז שכל הכספים שנשלחו לתיבות הפקדה 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
struct וכקלט פונקציה לכל הפונקציות הקשורות לממסר (כלומרrelayDeposit
,speedUpRelay
,settle
) הוא סוגuint8
. זהו סוג קטן מדי כדי לטפל ב-Arbitrum, למשל, המזהה שלו הוא 421611. למעשה תפסנו את הבאג הזה ותיקנו אותו בצד L2:BridgeDeposit
קבע את שלהchainId
הקלד לuint256
. יחסי ציבור זה יהפכו אתchainId
onBridgePool
להתאים את הסוג עלBridgeDepositBox
: UMAprotocol/protocol#3463
בעבר, פונקציית המחלוקת לא הורידה את סכום ההפקדה
pendingReserves
(זה המשתנה שעוקב אחר כמה ממאגר העתודה ננעל עקב ממסרים שעדיין לא התיישבו). התוצאה הייתה שכל מחלוקת תנעל ללא הגבלת זמן את כמות הממסר בבריכה. לא ניתן לבטל אותו על ידי LP או להשתמש בו על ידי ממסרים עתידיים. התיקון נמצא כאן: UMAprotocol/protocol#3473.
מצאנו באג ב
BridgeDepositBox
איפהhasEnoughTimeElapsedToBridge
לא בודק אם אuint256
ערך שווה ל-0
כברירת מחדל: תוקן ב-PR 3484
שיטת שער החליפין (שהיא שינוי מצב) נקראת בין אסימונים המועברים פנימה לבין אסימוני LP שנטבעים בשיטת addLiquidity של חוזה מאגר הגשר. יש להעביר את החישוב הזה לראש השיטה. זה גורם לערכי מדינה מוזרים מאוד. ראה יחסי ציבור כאן לתקן.
שיטת התצוגה
liquidityUtilizationPostRelay
(שנעשה בו שימוש רק ב-offchain), מדווח על מספר שימוש שגוי. המכנה על הקו הזה לא צריך להיות סתםliquidReserves
, במקום זאת זה צריך להיות ייצוג של רזרבות לא מנוצלות ומנוצלות. תוקן כאן.
עדכון
בנוסף לתיקון הבעיות, סקרנו גם את השינויים המצטברים הבאים:
- PR 72 לאקווריום ריף מסיר את פרמטר האסימון המיותר מ
BridgePool
אירועים - PR 72 לאקווריום ריף מוסיף את עמלת ה-DVM הסופית לרשימת המשתנים המאוחסנים במטמון מקומי.
- PR 72 לאקווריום ריף מסביר מקרה אפשרי של ניצול נזילות שלילי (בנוסף לטיפול ב-N04)
- PR 72 לאקווריום ריף מסיר קבצים מיותרים ומעדכן את קבועי OVM בהתאם לשינויים ב-OVM 2.0.
- PR 72 לאקווריום ריף מעדכן את
BridgeDepositBox
ממשק לעקביות ומשתמש ב-OpenZeppelinSafeERC20
סִפְרִיָה.
במהלך סקירת התיקונים זיהינו בעיה נוספת. בעת קביעת הערך של BridgePool
אסימוני LP, יש חישוב ביניים שעלול להציף שלילי באופן בלתי צפוי, אשר ישבית זמנית את הוספה והסרה של נזילות. יש לסדר מחדש את החישוב כדי להוסיף את הרזרבות המנוצלות לפני הפחתת העמלות הלא מחולקות.
חומרה קריטית
[C01] תגמול מציע לכוד
השמיים LongShortPair
חוזה מחזיר פרס למציע מכל כתובת שמפעילה את התפוגה, המשמשת לתמריץ הצעות מחיר באורקל האופטימי. אולם, ה LongShortPairCreator
חוזה גם מחזיר ומעביר את הכספים מכתובת המפיסה. הכספים הנוספים הללו אינם מועברים לאורקל האופטימית, ובמקום זאת נשארים כלואים בתוך LongShortPair
חוזה.
שקול להסיר את ההעברה הכפולה.
עדכון: תוקן מיום ההתחייבות 9bab1ff353a417952ba8c96a098773f340d9da17
in PR 72 לאקווריום ריף.
חומרה גבוהה
[H01] ממסרים במקביל מדללים רזרבות
השמיים relayDeposit
הפונקציה של BridgePool
חוזה מבטיח שלחוזה יש מספיק כספים כדי לבצע את ההעברה. עם זאת, זה לא לוקח בחשבון הרזרבות הממתינות, העוקבת אחר כספים המיועדים לממסרים פעילים. לכן, מספר ממסרים בו-זמניים עשויים להסתמך על אותם כספים, וייתכן שלא כולם ניתנים להסדר באופן מיידי. במיוחד, עם זרם קבוע של העברות, החזרות מיידיות של ממסר עשויות להתעכב ללא הגבלת זמן.
שקול למנוע ממסרים שיגרמו לעתודות הממתינות לחרוג מהעתודות הנוזליות.
עדכון: תוקן מיום ההתחייבות 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR 72 לאקווריום ריף.
[H02] גבולות פרמטר הגישור אינם תואמים
השמיים deposit
פונקציה של BridgeDepositBox
החוזה, הפרוס על שרשראות שכבה 2, משמש לגישור כספים בין L2 ל-L1. בפרט, ממסרים מתמרצים ממסר פרטי העסקה ב-L1 המשויך BridgePool
. עם זאת, תיבת הפיקדון משתמשת גבולות כולל להגביל את דמי הממסר, בעוד בריכת הגשר משתמשת גבולות בלעדיים. המשמעות היא שלא ניתן להעביר חלק מהפקדות (עם 25% עמלות ממסר), והכספים לא יהיו נגישים בשתי השכבות.
שקול לסנכרן את האימותים בשתי השכבות כדי להבטיח שניתן להעביר את כל ההפקדות התקפות.
עדכון: תוקן ב-commit 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR 72 לאקווריום ריף. זה סווג במקור כחומרה קריטית אך הורד את הדירוג לאחור כאשר צוות UMA ציין כי הכספים לא יהיו כלואים בקפדנות ויכולים להשתחרר אם מצביעי ה-DVM יסכימו לקבל תיאור ממסר שונה עבור ההפקדות המושפעות.
חומרה בינונית
[M01] התקשרות לאחור לכתובת שגויה
השמיים SkinnyOptimisticOracle
מפעיל פונקציות התקשרות חוזרת על מבקש המחיר, אם הן קיימות, כך שהמבקש יכול להגיב לשינויי מצב משמעותיים. עם זאת, ההתקשרות חזרה מופעלת באופן שגוי על מציע המחיר במקום על מבקש המחיר ב מה היא proposePriceFor
פונקציה. המשמעות היא שמבקש המחיר אינו יכול להגיב להצעות מחיר.
למרבה המזל, תכונה זו אינה בשימוש בבסיס הקוד הנוכחי. עם זאת, שקול להפעיל את priceProposed
התקשרות חוזרת למבקש.
עדכון: תוקן בעת התחייבות 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR 72 לאקווריום ריף.
[M02] פונקציית הוספה פגומה
השמיים appendKeyValueBytes32
פונקציה צריך לשלב את הקלט שלו לפורמט bytes
מַעֲרָך. אולם, ה currentAncillaryData
is נזרק בצורה לא נכונה.
מאז הנתונים הנלווים משפיע על תהליך פתרון האורקל, ערך שגוי עלול לערער את תוצאות האורקל. למרבה המזל, יש רק שיחה אחת ל appendKeyValueBytes32
בבסיס הקוד, והוא משתמש בקובץ ריק currentAncillaryData
buffer, כך שהבאג אינו משפיע על מקרה זה.
שקול לעדכן את appendKeyValueBytes32
לתפקד כך שה currentAncillaryData
נכלל במערך הבתים המוחזרים.
עדכון: תוקן ב-commit 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR 72 לאקווריום ריף.
[M03] אימות נתונים נלווים לא שלם
השמיים LongShortPair
בנאי מאשר כי customAncillaryData
הוא קטן מספיק. עם זאת, זה לא לוקח בחשבון את שדה תפוגה מוקדמת. זה אומר האורקל האופטימי עלול לדחות באופן בלתי צפוי בקשות מחיר לתפוגה מוקדמת, מה שישבית את התכונה הזו.
שקול לעדכן את האימות כדי להתייחס לשדה הנוסף.
עדכון: תוקן מיום ההתחייבות 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR 72 לאקווריום ריף.
[M04] אפס חותמת זמן שגויה
ב LongShortPair
חוזה, חותמת זמן תפוגה מוקדמת היא אפס משמש כדגל כדי לציין שאף אחד לא הפעיל את מנגנון הפקיעה המוקדמת. עם זאת, אפשר להפעיל את המנגנון הזה עם חותמת זמן אפס. בתרחיש זה, האורקל האופטימי יופעל אך הגנה מפני בקשות מחיר עוקבות לא יהיה יעיל. למרבה המזל, פעם אחת נבחר מחיר ההסדר, זה לא יעקוף, כך שזה לא יוביל להתנחלויות לא עקביות. עם זאת, בקשת מחיר לאחר מכן יכולה שנה את חותמת הזמן של התפוגה המוקדמת שנרשמה, גם אם חותמת האפס משמשת לקביעת מחיר הפשרה. זה יכול גם פולט אירוע מטעה.
שקול למנוע תפוגה מוקדמת באמצעות חותמת האפס.
עדכון: תוקן מיום ההתחייבות 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR 72 לאקווריום ריף.
[M05] קשר אפס אפשרי
השמיים requestPrice
הפונקציה של SkinnyOptimisticOracle
חוזה משתמש בעמלה הסופית כערב אם לא צוין הערבות. אולם, ה requestAndProposePriceFor
פונקציה עשוי להשתמש בקשר אפס, מה שסותר את זה @notice
ו @param
הערות. ערבות אפס מחלישה את התמריץ מפני הצעה או מחלוקות לא חוקיות.
למרבה המזל, התקשר רק לפונקציה הזו בבסיס הקוד קובע קשר למציע. עם זאת, שקול להשתמש בעמלה הסופית אם הערובה לא צוינה.
עדכון: תוקן מיום ההתחייבות daaabfc342ba1395a577159b6eb26adb20fcd232
in PR 72 לאקווריום ריף.
[M06] הרשאות מנהל מיותרות
השמיים BridgePool
חוזה יורש מ ExpandedERC20
כך שהיא תוכל להנפיק אסימוני LP לספקי נזילות. זה יורש את הפונקציונליות של OpenZeppelin ERC20
חוזה וגם מספק הרשאות מנהל לפריסת החוזה, המאפשרת להם להטביע ולשרוף אסימוני LP. עם זאת, סמכות זו אינה נדרשת, ובמידה ויופעל, היא עלולה להעניש ספקי נזילות באופן בלתי הוגן.
שקול לשנות BridgePool
לרשת ישירות ממנו ERC20
במקום ExpandedERC20
.
עדכון: תוקן ב-commit 370e8b21b660543eadbd764fed984a5bdeddce24
in PR 72 לאקווריום ריף.
חומרה נמוכה
[L01] לא ניתן להתיישב עם התפוגה
השמיים settle
הפונקציה של LongShortPair
חוזה שוקל את תנאי ההסדר כאשר השעה הנוכחית היא אך ורק לפני או אחרי חותמת הזמן התפוגה. עם זאת, הוא חוזר באופן שגוי כאשר השעה הנוכחית תואמת את חותמת הזמן התפוגה.
שקול להשתמש בחיבור כולל כדי להתאים את postExpiration
מתקן.
עדכון: תוקן ב-commit f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR 72 לאקווריום ריף.
[L02] הודעת שגיאה חסרה בהצהרת require
יש הצהרת דרישה ב- BridgePool
חוזה ללא הודעת שגיאה.
שקול לכלול הודעות שגיאה ספציפיות ואינפורמטיביות בכל הצהרות הדרוש.
עדכון: תוקן מיום ההתחייבות 67e60faa3a44c842c37211d2e903a983ff192e57
in PR 72 לאקווריום ריף.
[L03] חסרים מחרוזות docstrings
ישנם כמה מקרים ברחבי בסיס הקוד שבהם ה- מפרט טבעי של Ethereum חסר או לא שלם. דוגמאות מכילות:
שקול תיעוד יסודי של כל הפונקציות (והפרמטרים שלהן) שהן חלק מה-API הציבורי של החוזים.
עדכון: ההערות המודגשות תוקנו ב-commit e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR 72 לאקווריום ריף. לא אימתנו את שלמות NatSpec בשאר בסיס הקוד.
הערות ומידע נוסף
[N01] ערך החזרת שיחה לא מסומן
ב deposit
פונקציה של ה- L2 BridgeDepositBox
חוזה יש קריאה ברמה נמוכה ל l2Token
כאשר l1Token
is l1Weth
. השיחה ברמה נמוכה זו היא ל- deposit()
פונקציה, השייכת ל- WETH מִמְשָׁק. אם זה l2Token
מתנהג בדיוק כמו WETH זה לא אמור להיכשל. אבל במקרה של l2Token
מתנהג אחרת ואכן נכשל, לא תהיה חזרה מאחר שדגל ההצלחה של שיחה ברמה נמוכה זו לעולם אינו מסומן.
שקול לבדוק ולהגיב כראוי לערכי ההחזר של כל השיחות ברמה נמוכה.
[N02] היעדר פרמטרים צמודים באירועים
לרבים מהאירועים המוגדרים בבסיס קוד זה יש פרמטרים שיש להוסיף לאינדקס:
לשקול אינדקס פרמטרים של אירועים כדי להימנע מהפרעה במשימה של חיפוש וסינון של שירותים מחוץ לרשת עבור אירועים ספציפיים.
עדכון: קבוע חלקית ב-commit d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR 72 לאקווריום ריף. ה chainId
פרמטר של WhitelistToken
לא עודכן.
[N03] חוסר עקביות ליהוק
השמיים LongShortPair
חוזה בדרך כלל מתייחס לחותמות זמן כמו uint64
ערכים, שנוצקים במרומז ל uint256
ערכים מתי הועבר לאורקל האופטימי. אולם, ה requestTimestamp
פרמטר של מה היא _requestOraclePrice
פונקציה נוצק בטרם עת לא uint256
. אין לכך השלכות תפקודיות.
עם זאת, למען העקביות, שקול להשתמש ב-a uint64
עבור פרמטר זה ומאפשר להטיל אותו באופן מרומז ל-a uint256
כשהועבר לאורקל האופטימי.
עדכון: תוקן ב-commit 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR 72 לאקווריום ריף. חותמת הזמן יצוקה כעת במפורש.
[N04] סוג שגוי
השמיים sendMessage
הפונקציה של iOptimism_CrossDomainMessenger
ממשק משתמש uint256
מגבלת גז בעוד של אופטימיות OVM_CrossDomainEnabled
משתמש uint32
מגבלת גז.
לקבלת עקביות וניבוי, שקול לעדכן את ה iOptimisim_CrossDomainMessenger
sendMessage
פונקציה להשתמש ב-a uint32
מגבלת גז.
עדכון: תוקן מיום ההתחייבות 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR 72 לאקווריום ריף.
[N05] חוסר אימות
כל הפונקציות ב BridgeAdmin
השיחה ההיא _relayMessage
נניח שערך העסקה תואם את l1CallValue
פרמטר, אבל זה לא נאכף.
שקול להבטיח את הנכון msg.value
מוגדר.
עדכון: תוקן מיום ההתחייבות f19b8d04c2343051ff2a8145abd41c39bd025063
in PR 72 לאקווריום ריף.
[N06] קריאות
השמיים _getDepositHash
פונקציה של BridgePool
חוזה פותח את depositData
struct כדי לחלץ את l1Token
כטיעון בהרכב של keccak256
עם abi
הַצפָּנָה. זה הופך את הפעולה למילולית שלא לצורך ועלולה להוביל לבאגים כאשר היא מיושמת מחדש בשכבות אחרות.
שקול לפשט את הטיעונים כדי להיות פשוט הזוג המסודר depositData
ו l1Token
.
עדכון: תוקן מיום ההתחייבות 31754be4a818109fa12131f854c3f70d6c72dba7
in PR 72 לאקווריום ריף.
[N07] פונקציית כניסה חוזרת
השמיים requestAndProposePriceFor
פונקציה של SkinnyOptimisticOracle
החוזה מתקשר לאדם שאינו מהימן msg.sender
אך אינו נשמר על ידי א nonReentrant
מַתקֵן. למרות שבמקרה זה, זה לא נראה כדאגה ביטחונית, זה יכול להציג התנהגות בלתי צפויה.
שקול להוסיף את nonReentrant
משנה לכל הפונקציות המבצעות קריאות לחוזים שאולי לא מהימנים.
עדכון: תוקן ב-commit b744d24e7579b7afa2c778f4dd680f26117b3990
of PR 72 לאקווריום ריף.
[N08] seqNum
לא מחובר
השמיים relayMessage
פונקציה של Arbitrum_Messenger
החוזה אינו פולט אירוע רלוונטי לאחר ביצוע פעולה רגישה. ה relayMessage
קריאות פונקציה כתתי שגרה sentTxToL2NoAliasing
שבעצמו מחזיר את uint256
ערך seqNum
, אך ערך החזרה זה אינו מחובר ב- relayMessage
פונקציה.
שקול פליטת אירועים לאחר התרחשות שינויים רגישים, כדי להקל על המעקב ולהודיע ללקוחות מחוץ לרשת בעקבות פעילות החוזה.
עדכון: תוקן מיום ההתחייבות 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR 72 לאקווריום ריף.
[N09] שגיאות דפוס
בסיס הקוד מכיל את שגיאות ההקלדה הבאות:
שקול לתקן שגיאות הקלדה אלה כדי לשפר את קריאות הקוד.
עדכון: תוקן מיום ההתחייבות 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR 72 לאקווריום ריף.
[N10] דרישת אישור ERC20 לא מתועד
השמיים requestEarlyExpiration
ו expire
פונקציות של LongShortPair
חוזה כל אחד מניחים שהמתקשר העניק לחוזה קצבה למשוך את פרס המציע.
למען הניבוי, שקול לתעד דרישה זו בהערות הפונקציה.
עדכון: תוקן ב-commit da3754f50284480df57b90b80002da06a1ce0d02
in PR 72 לאקווריום ריף.
[N11] משנה לא בשימוש
ב BridgePool
החוזה, onlyFromOptimisticOracle
מתקן מוגדר אך אינו בשימוש בבסיס הקוד ולכן יש להסירו.
עדכון: תוקן ב-commit 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR 72 לאקווריום ריף.
מסקנות
נמצאו 2 בעיות קריטיות ואחת בדרגת חומרה גבוהה. כמה שינויים הוצעו כדי לפעול לפי שיטות עבודה מומלצות ולצמצם את משטח התקיפה הפוטנציאלי.
- &
- 7
- חֶשְׁבּוֹן
- פעולה
- פעיל
- Ad
- נוסף
- כתובת
- מנהל
- יתרון
- תעשיות
- מאפשר
- API
- טיעונים
- בדיקה
- זמינות
- להיות
- הטוב ביותר
- שיטות עבודה מומלצות
- blockchain
- אריזה מקורית
- לְגַשֵׁר
- חרק
- באגים
- שיחה
- מקרים
- נתפס
- לגרום
- לאתגר
- שינוי
- בדיקה
- קוד
- הערות
- תְצוּרָה
- מכיל
- חוזה
- חוזים
- יכול
- נוֹכְחִי
- נתונים
- מבוזר
- עיכוב
- עיצוב
- קביעה
- DID
- מַחֲלוֹקֶת
- לא
- מוקדם
- כַּלְכָּלִי
- אדג '
- אפקטיבי
- ERC20
- ETH
- ethereum
- הבלוק
- אירוע
- אירועים
- דוגמה
- חליפין
- צפוי
- ניסיון
- מאפיין
- אגרות
- כספי
- ראשון
- לסדר
- פלאש
- לעקוב
- מצא
- פונקציה
- קרן
- כספים
- עתיד
- גז
- דמי דלק
- נתינה
- ממשל
- שמח
- יש
- כאן
- גָבוֹהַ
- מודגש
- מחזיקים
- איך
- HTTPS
- לתמרץ
- כלול
- כולל
- להגדיל
- מידע
- אינטרס
- מִמְשָׁק
- בעיות
- IT
- ידוע
- עוֹפֶרֶת
- סִפְרִיָה
- נוזל
- נְזִילוּת
- ספקי נזילות
- רשימה
- הלוואות
- באופן מקומי
- נעול
- LP
- תקליטים
- שוק
- להתאים
- רוב
- לפתוח
- אורקל
- אחר
- פלטפורמה
- בריכה
- ברכות
- כּוֹחַ
- מניעה
- מחיר
- תהליך
- הצעה
- לספק
- מספק
- ציבורי
- סיבות
- להפחית
- דוחות לדוגמא
- REST
- תוצאות
- החזרות
- סקירה
- הסיכון
- אבטחה
- שירותים
- סט
- הֶסדֵר
- קצר
- משמעותי
- דומה
- קטן
- So
- מוּצָקוּת
- מישהו
- משהו
- מְהִירוּת
- לבלות
- מדינה
- הצהרה
- אחסון
- הצלחה
- נתמך
- משטח
- מערכת
- מבחן
- דרך
- בכל
- זמן
- אסימון
- מטבעות
- חלק עליון
- מעקב
- עסקה
- עסקות
- סומך
- עדכון
- עדכונים
- יו פי אס
- משתמשים
- ערך
- לצפיה
- רשימה לבנה
- מי
- בתוך
- לְלֹא
- תיק עבודות
- ראוי
- אפס