DAY0

ארכיטקטורת סיכון / DAY0

אורקל הוא לא מספר: כך מתכננים DeFi למחיר מיושן, השבתת Sequencer ונתונים שגויים

ארכיטקטורה מעשית לאימות נתוני מחיר ב־DeFi, טיפול במידע מיושן ובהשבתת Sequencer, והכלת כשל לפני חשיפת נזילות אמיתית.

דור ארדכ־10 דקות קריאהEnglish
איור DAY0 מקורי של אות שוק זוהר העובר דרך שערי זמן, אימות ומפסק חירום לפני הגעה לנזילות מוגנת
איור מקורי עבור DAY0

אורקל מחיר אינו מספק אמת. הוא מספק תצפית חתומה עם יחידת מידה, חותמת זמן, מדיניות עדכון, הקשר רשת ומשטח כשל. פרוטוקול שקורא רק את הערך המספרי עדיין לא שילב אורקל; הוא רק העביר החוצה הנחה קריטית. לפני שמוצר DeFi מקבל פיקדונות, מעריך בטוחות או מאפשר liquidation, עליו להגדיר מה הופך מחיר לשמיש, מה קורה כשהתנאים אינם מתקיימים וכיצד מפעילים ומשתמשים מבחינים בין המצבים.

חמישה כללים לפני נזילות

  1. 01מאמתים את התצפית כולה, לא רק את המספר.
  2. 02רעננות היא מדיניות לכל feed, לא timeout גלובלי.
  3. 03השבתת Sequencer משנה נגישות והוגנות בשוק.
  4. 04Fallback חייב להיכשל באופן עצמאי ולא לשכפל אותה חולשה.
  5. 05לכל פעולה שנחסמה דרושים סיבה נצפית וכלל התאוששות.

1. מחיר הוא חוזה נתונים, לא scalar

ההפשטה הנוחה היא `assetPrice = oracle.latestAnswer()`. ההפשטה הבטוחה יותר היא תצפית מחיר: ערך, decimals, מזהה round, זמן תצפית, תצורת מקור ורשת. ממשק EVM של Chainlink מחזיר דרך `latestRoundData()` את `roundId`, `answer`, `startedAt`, `updatedAt` ו־`answeredInRound`. השדות האלה אינם קישוט. הם מאפשרים לצרכן לדחות תשובה שאינה חיובית, שלא אותחלה, הגיעה מ־feed לא צפוי או ישנה מדי לפעולה המבוקשת.

מומלץ להחזיר תוצאת אימות מפורשת במקום לפזר בדיקות בין פונקציות lending, swap וחשבונאות. adapter פנימי אחד מנרמל את התשובה ומחזיר מחיר מאומת עם זמן התצפית, או כשל מסוג `PRICE_STALE`, `PRICE_INVALID`, `SEQUENCER_DOWN` או `FEED_UNAVAILABLE`. הלוגיקה העסקית צורכת רק את התוצאה המאומתת ולעולם לא aggregator גולמי. כך תלות סמויה הופכת לגבול אבטחה שאפשר לסקור.

כתובת ה־feed היא חלק מהגבול. התיעוד מפרסם חוזים שונים לפי רשת וצמד נכסים. לכן התצורה צריכה לקשור chain ID, נכס בסיס, נכס ציטוט, כתובת, decimals צפויים, גיל מקסימלי וסטטוס תפעולי ברשומה אחת בעלת גרסה. כתובת נכונה ברשת הלא נכונה היא עדיין אינטגרציה שגויה. סקריפט deployment צריך לסרב לתצורה שאינה תואמת לקטלוג המאושר.

2. רעננות אינה מספר קסם

ההגנה הנפוצה הראשונה היא `block.timestamp - updatedAt <= maxAge`. היא הכרחית, אך בחירת `maxAge` דורשת שיקול דעת מוצרי. feed-ים מתעדכנים בהתאם לשוק ולתצורה שלהם, לרוב על בסיס תנאי deviation ו־heartbeat. בשוק שקט אותו ערך יכול להישאר תקין; בשוק מהיר גם תצפית עדכנית יחסית עלולה להיות מסוכנת לפעולה ממונפת. timeout אחד שמועתק לכל הצמדים מסתיר את ההבדלים.

יש להגדיר מדיניות רעננות לכל feed ולכל סוג פעולה. מסך portfolio יכול להציג מחיר מאוחר עם חותמת זמן ברורה, בעוד liquidation או פתיחת חוב חדש דורשים גבול מחמיר יותר. הפרוטוקול לא צריך להשתמש בשקט בערך שהממשק מסמן כמיושן. החוזה, המוצר והניטור חייבים לקרוא מאותה מדיניות; אחרת dashboard יכול להיראות תקין בזמן שהביצוע כבר דוחה משתמשים, או שהביצוע ממשיך אחרי שהניטור סימן סכנה.

בדיקות זמן צריכות לדחות גם `updatedAt` אפס, זמן עתידי וערך מבוגר מהמגבלה. בבדיקות מתקדמים בדיוק מעבר לסף. יש לכסות גם מצב שבו ערך תקין אינו משתנה בין rounds, משום ש'לא השתנה' ו'לא זמין' אינם אותו דבר. רעננות מתארת מתי נוצרה התצפית, לא האם השוק נע.

3. Decimals הם חלק מהמשמעות הכלכלית

ערכי oracle, יתרות ERC-20 וחשבונאות הפרוטוקול עשויים להשתמש בדיוק שונה. הנחה שכל המחירים הם fixed point של 18 decimals עלולה ליצור שגיאות גדולות מספיק כדי לעקוף מגבלות בטוחה או לחסל position בריא. ה־adapter צריך לקרוא או לאמת את decimals של ה־feed, לבצע scaling בחשבון בדוק ולחשוף לשאר הפרוטוקול precision יחיד ומתועד. גם כיוון העיגול הוא החלטת סיכון: ערך בטוחה בדרך כלל לא יעוגל כלפי מעלה, וחוב לא יעוגל כלפי מטה.

בצמדים נגזרים מתווספת שכבה. אם TOKEN/USD נגזר מ־TOKEN/ETH ומ־ETH/USD, שתי התצפיות זקוקות לאימות עצמאי, זמנים תואמים וכיוון base/quote נכון. המחיר המשולב רענן רק כמו הרגל הישנה ביותר. כפל לפני חילוק עלול לגרום overflow; חילוק לפני כפל עלול לאבד precision מהותי. יש להשתמש במתמטיקה מלאה שנבדקה ולבחון את הערכים הקטנים והגדולים ביותר, לא רק tokens שלמים ונוחים.

בדיקות תצורה צריכות לזהות טעות יחידות לפני deployment. מזינים מחיר של דולר אחד, סנט אחד וערך שוק קיצוני ומאמתים תוצאה פנימית מדויקת. דוח deployment קריא צריך להדפיס כתובת, צמד, decimals, מגבלת רעננות ודוגמת ערך מנורמל. סוקר אנושי יזהה טעות של פי מיליארד בדוח מהר יותר מאשר ב־payload הקסדצימלי.

4. סטטוס Sequencer הוא אות לנגישות שוק

ב־rollup אופטימי או מבוסס zero knowledge, ה־sequencer הוא חלק מהמסלול הרגיל לשליחת טרנזקציות ולצפייה במצב עדכני. Chainlink מפעילה L2 Sequencer Uptime Feeds משום שהשבתה משנה מי מסוגל לפעול. משתמשים מתקדמים מסוימים עשויים עדיין להגיע ל־rollup דרך L1 בזמן שמשתמש רגיל אינו יכול להשתמש בממשק. אם liquidations ממשיכים באי־סימטריה הזאת, המספר יכול להיות תקין והליך השוק עדיין לא הוגן.

הצרכן צריך לבדוק את uptime feed הרלוונטי לפני שימוש במחיר בפעולה רגישה. במוסכמה המתועדת, `answer = 0` משמעו sequencer פעיל ו־`answer = 1` משמעו מושבת. מצב down עוצר פעולות שתלויות בגישה בזמן. החוזה גם צריך לדחות סטטוס שלא אותחל ולתעד סיבה ברורה במקום להפוך את ההשבתה לשגיאת oracle כללית.

התאוששות אינה הרגע שבו הסטטוס חוזר ל־up. הדוגמה של Chainlink משתמשת בתקופת חסד של שעה לאחר שינוי הסטטוס, כדי לתת למשתמשים ולתשתיות זמן להתחבר מחדש לפני חזרת liquidations. משך החסד הוא החלטת סיכון, אך עליו להיות מפורש, ניתן לבדיקה וגלוי. pause ללא יציאה מוגדרת יכול להפוך למשבר governance; חזרה מידית יכולה להפוך התאוששות טכנית לחלון ניצול.

5. Circuit breaker צריך להכיל נזק, לא ליצור עמימות

כאשר האימות נכשל, הפרוטוקול זקוק למטריצת פעולות. חסימת הכול עלולה ללכוד משתמשים; מתן אפשרות להכול עלול להפוך הפסד פרטי לחוב משותף. תכנון סביר מפריד בין פעולות שמגדילות סיכון לבין פעולות שמקטינות אותו. פתיחת חוב, הגדלת מינוף ו־liquidations יכולים להיעצר, בעוד החזר חוב, הוספת בטוחה ומשיכה שאינה פוגעת בכושר הפירעון נשארים זמינים. המטריצה תלויה בפרוטוקול, אך יש לכתוב אותה לפני האירוע.

OpenZeppelin מתארת `Pausable` כמנגנון תגובת חירום נפוץ עד להשלמת תיקון. ה־primitive שימושי, אך מבנה הסמכות חשוב יותר מה־modifier. צריך להגדיר מי רשאי לעצור, אילו פונקציות מכוסות, האם unpause דורש תפקיד אחר או timelock ואיזה event ציבורי מוכיח את השינוי. ארנק חם בעל כוח pause ו־unpause אוניברסלי רק מחליף סיכון נתונים בסיכון מפתח.

גם מפסק המבוסס על deviation דורש זהירות. השוואת oracle ל־TWAP של DEX יכולה לזהות פער, אך ה־DEX עלול להיות דל נזילות, ניתן למניפולציה או תלוי באותו נכס. תפקיד המפסק הוא לזהות מחלוקת ולהעביר את המערכת למצב מוגבל, לא להכריז אוטומטית איזה מקור צודק. יש לשמור את שתי התצפיות, החלונות והסף כדי לאפשר אבחון ללא שחזור בדיעבד.

6. Fallback הוא תלות חדשה, לא הצלה בחינם

צוותים מציעים לעיתים oracle שני כאילו redundancy מצמצם סיכון מעצם קיומו. הוא עוזר רק כאשר הוא נכשל באופן אחר. שני ספקים שתלויים בסוף באותה בורסה, bridge, stablecoin או sequencer עשויים להיכשל יחד. fallback של DEX עלול להיות מעגלי כאשר liquidation או מצב הנזילות של הפרוטוקול עצמו מזיזים את מחיר ה־DEX.

לכל fallback דרושה הערכת עצמאות: מקור הנתונים, מסלול העדכון, governance, תלות ברשת, הנחות נזילות ועלות מניפולציה. אחר כך מגדירים מתי מותר להשתמש בו. דפוס שמרני אחד משתמש במקור משני רק כגבול sanity ועוצר בעת מחלוקת, במקום להחליף סמכות בשקט. דפוס אחר מגביל כמה fallback רשאי להזיז את הערך התקין האחרון בחלון קצר. אין פתרון אוניברסלי; שני הדפוסים מחייבים את הצוות להצהיר איזה הפסד הוא מוכן לשאת.

מחיר ידני מסוכן במיוחד. אם governance יכולה לפרסם ערך חירום, הטרנזקציה צריכה להיות שקופה, מושהית ככל האפשר, מצומצמת בזמן ובהיקף. הממשק חייב לסמן שהפרוטוקול פועל תחת מקור חירום. גם ערך נכון שהוזן בידי גורם מורשה מייצג מודל אמון שונה מ־feed אוטומטי.

7. בודקים state machine לפני mainnet

בדיקת oracle צריכה להיות מטריצת מצבים ולא happy path יחיד. מכסים תשובה חיובית ורעננה, אפס ושלילי, timestamp אפס, timestamp עתידי, גבול הרעננות המדויק, תצפית מיושנת, decimals לא צפויים, קצוות overflow, revert של feed, sequencer down, התאוששות בתוך תקופת החסד ואחריה. במחיר נגזר מכשילים כל רגל בנפרד. ב־circuit breaker מוכיחים שכל פונקציה מוגנת נכנסת למצב הרצוי.

Property tests צריכים לבטא invariants: שום פעולה שמגדילה סיכון אינה מצליחה ללא מחיר מאומת; עצירת market אחד אינה משבשת חשבונאות אחרת; התיישנות נתונים לעולם אינה מגדילה ערך בטוחה; והחלפת מקור אינה יוצרת קפיצה בלתי מוגבלת. fork tests מאמתים ממשקים וכתובות אמיתיים, אך mocks מקומיים חיוניים משום ש־feeds אמיתיים כמעט אינם מייצרים כל כשל לפי דרישה.

גם המוצר נבדק לצד החוזה. הממשק מציג את זמן התצפית, מצב degraded ופעולה מושבתת בלי להציג portfolio מיושן כעדכני. simulation בארנק צריכה להיכשל לפני חתימה ככל האפשר. כלי התמיכה צריכים להשתמש באותו error code של החוזה או ה־API. היעד הוא מצב incident אחיד, לא שלושה הסברים שונים מהחוזה, dashboard והתמיכה.

8. ניטור הוא חלק מהאינטגרציה

feed יכול לעבור את כל בדיקות ה־deployment ולהיכשל תפעולית חודשים לאחר מכן. יש לנטר גיל תשובה, סימן הערך, התקדמות round, סטטוס sequencer, deviation ממקור עצמאי, קריאות שנכשלו ומספר הטרנזקציות שנחסמו בכל guard. מתריעים עוד לפני חציית מגבלת הרעננות; אחרת האות הראשון עשוי להיות גל טרנזקציות משתמשים שחזרו ב־revert.

לכל alert דרושים runbook, בעלים, חומרה והחלטה. ה־runbook מבחין בין השבתת ספק, השבתת רשת, טעות תצורה, תנועת שוק חריגה אך תקינה וכשל RPC מקומי. הוא מפרט אילו פעולות כבר חסומות on-chain, אילו דורשות מפעיל, כיצד מודיעים למשתמשים ואילו ראיות נדרשות לחזרה. dashboard ללא מסלול החלטה הוא תצפית, לא בקרה.

שינוי feed, סף או adapter הוא release. מתעדים סיבה, reviewer, block כניסה לתוקף ותוכנית rollback. מריצים שוב את מטריצת האימות על ה־bytecode והתצורה המדויקים. אם ספק מחליף aggregator מאחורי proxy, הניטור צריך לזהות את השינוי הפנימי גם כאשר כתובת הצרכן נשארת קבועה.

9. שער ההשקה הוא ראיות, לא ביטחון עצמי

לפני ש־DAY0 או כל מוצר DeFi פותח נזילות אמיתית, חבילת הראיות צריכה לכלול קטלוג feeds מאושר, בדיקות נרמול decimals, מדיניות רעננות, התנהגות sequencer ותקופת חסד, מטריצת פעולות, ניתוח fallback, הרשאות circuit breaker, dashboards, runbook ו־traces מקצה לקצה מכל רשת נתמכת. חריגים ידועים מקבלים בעלים ותאריך תפוגה.

הגישה אינה מבטיחה ש־oracle לעולם לא יטעה. היא הופכת את תגובת הפרוטוקול לאי־ודאות למפורשת. משתמש צריך לדעת אם מחיר חי, מאוחר, שנוי במחלוקת או לא זמין. מפעיל צריך להכיל סיכון בלי להמציא התנהגות חוזה בזמן שוק תנודתי. governance צריכה לדעת איזו הנחה בדיוק היא משנה.

הלקח המוצרי העמוק פשוט: איכות נתונים הופכת להתנהגות פרוטוקול. timestamp קובע אם אפשר לפתוח הלוואה. דגל sequencer קובע אם liquidation הוגן. הגדרת decimals משנה solvency. התייחסות לעובדות האלה כדרישות מוצר ולא כצנרת היא הדרך שבה מערכת DeFi מרוויחה את הזכות לטפל בערך.

מקורות ראשוניים

התיעוד הטכני נבדק ב־20 בספטמבר 2026. תאריך מצוין כאשר המקור מפרסם אותו.

  1. Chainlink — שימוש ב־Data Feeds ברשתות EVMנבדק ב־20 בספטמבר 2026
  2. Chainlink — L2 Sequencer Uptime Feedsנבדק ב־20 בספטמבר 2026
  3. Aave V3 — חוזי Oracleנבדק ב־20 בספטמבר 2026
  4. OpenZeppelin Contracts 5.x — Pausableנבדק ב־20 בספטמבר 2026
  5. Sky — סיכוני משתמש, לרבות כשלי oracle ו־keeperעודכן ב־28 באוגוסט 2026

DAY0 עדיין בשלב public testnet ו־pre-deployment. המאמר מתאר מסגרת סיכון מוצרית והנדסית; הוא אינו טוען שתצורת oracle מסוימת פעילה בייצור ואינו ייעוץ השקעות.