DAY0

רשומת מוצר / DAY0

Testnet לפני נזילות: כיצד מוצר DeFi מרוויח את הזכות לעלות לאוויר

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

דור ארדכ־7 דקות קריאהEnglish
איור DAY0 מקורי של ארבעה שערי אימות ב־testnet המובילים למאגר נזילות מוגן
איור מקורי עבור DAY0

לעיתים מתייחסים ל־testnet כמקום שבו מוכיחים שחוזה חכם מתקמפל וטרנזקציה מצליחה. זה הכרחי, אך רחוק מלהספיק. מוצר DeFi הוא מערכת הפעלה מחוברת: חוזים, ארנקים, ממשקים, ספקי RPC, אינדקסרים, תמחור, הרשאות, תמיכה ונוהלי treasury צריכים להסכים על מה שקרה. מטרת שלב ה־testnet היא לבדוק את המערכת תחת כשל—לא לבצע חזרה גנרלית לדמו מושלם.

ארבעה עקרונות להשקה

  1. 01אין כתובת מאומתת—אין טרנזקציה.
  2. 02טרנזקציה מוצלחת אינה בהכרח תוצאה מוצלחת למשתמש.
  3. 03תמיכה מרובת רשתות נרכשת מחדש בכל רשת; היא אינה הצהרה חד־פעמית.
  4. 04פותחים נזילות רק כאשר הצוות מסוגל להסביר ולשחזר כל מצב.

1. להגדיר מה שלב ה־testnet חייב להוכיח

תוכנית testnet שימושית מתחילה בטענות, לא ברשימת פיצ׳רים. הצוות כותב מה חייב להיות נכון לפני שכסף אמיתי נכנס למערכת. ב־DAY0 אלה יכולים להיות היצע token קבוע, תצורת router מאומתת, טרנזקציות שאושרו בארנק, slippage מוגבל, deadline ברור והבחנה גלויה בין פעולה שאינה זמינה לבין פעולה שנכשלה. לכל טענה נדרשת ראיה שמישהו מלבד המפתח שכתב את הקוד מסוגל לשחזר.

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

קריטריוני היציאה צריכים להיות מדידים. בדיקות החוזה עוברות על ה־build המדויק המיועד לפריסה. הכתובות מאומתות ב־explorer ונכנסות דרך תצורה מבוקרת. לזרימות הקריטיות יש receipts ולוגים. הממשק מציג אותו מצב גם לאחר refresh. runbook מגדיר מי מטפל בכל התראה שחוסמת השקה ומה עליו לעשות. אלה אותות חזקים יותר מתאריך במפת דרכים.

2. להפריד בין נכונות החוזה לנכונות המוצר

בדיקות חוזה עונות אם הקוד שומר על invariants: ההיצע אינו יכול לעבור את התקרה, גורם לא מורשה אינו יכול להנפיק tokens, העברות מעדכנות יתרות ומקרי קצה נעצרים כנדרש. תיעוד Hardhat מדגיש בדיקות אוטומטיות משום שכספי משתמשים נמצאים בסיכון. רשת מקומית הופכת את הבדיקות למהירות ודטרמיניסטיות, וסביבת fork מאפשרת לשחזר מצב שרשרת נבחר.

נכונות המוצר שואלת שאלות רחבות יותר. האם בקשת הארנק מתארת את הפעולה שהממשק הבטיח? האם האפליקציה מזהה טרנזקציה שהוחלפה? מה קורה אם ה־RPC קיבל submission אך החיבור בממשק נפל? האם אפשר לשלוח אותה פעולה פעמיים? האם simulation שנכשל עוצר חתימה? האם פעולה ברשת הלא נכונה נשארת מופרדת מהכוונה המקורית? unit tests ב־Solidity אינם מוכיחים אף אחת מהתוצאות האלה לבדם.

שתי השכבות נפגשות ב־trace שניתן להרצה. פעולת מוצר יוצרת intent עם רשת, חוזה, פונקציה, סכום, slippage ו־deadline. סימולציה מאמתת אותו, הארנק מאשר, האפליקציה שומרת hash, צופה ב־receipt, מפרשת את האירוע הצפוי ומעבירה את ה־intent למצב סופי. אם חוליה כלשהי אינה מסכימה, המערכת נעצרת ושומרת ראיות במקום לנחש.

3. כל רשת היא סביבת תפעול נפרדת

תאימות EVM מצמצמת עבודת אינטגרציה, אך אינה הופכת רשתות לזהות. chain IDs, נכסי gas, מגבלות RPC, explorers, זמני בלוק, הנחות finality וזמינות faucets שונים. Ethereum ממליצה כיום על Sepolia לבדיקת חוזים ו־dapps. Base מתעדת את Base Sepolia ב־chain ID 84532. Polygon מתעדת את Amoy ב־chain ID 80002 עם POL כנכס gas. BNB Chain מתעדת את BSC Testnet ב־chain ID 97 עם tBNB.

הפרטים האלה שייכים לקטלוג רשתות בעל גרסאות, לא לקבועים המפוזרים בתוך components. כל רשומה כוללת chain ID, ספקי RPC, explorer, נכס gas, חוזים צפויים, מדיניות confirmations מינימלית וסטטוס תפעולי. הממשק צריך להפיק את שם הרשת ואת יעד הטרנזקציה מאותו קטלוג שבו משתמשת שכבת הביצוע.

DAY0 חושף כיום adapters ל־BSC Testnet, Ethereum Sepolia, Base Sepolia ו־Polygon Amoy. זהו משטח בדיקה, לא הבטחה שנזילות או חוזי token פעילים בכל רשת. הביצוע נשאר חסום עד להגדרת כתובות מאומתות ותצורת router נדרשת. ההבחנה מכוונת: מודעות לרשת אינה הכרזה על שוק פעיל.

4. לבדוק כשל כמסע משתמש מלא

רוב הדגמות המוצר עוברות במסלול השמח: connect, approve, swap, success. בדיקות ה־testnet בעלות הערך הגבוה ביותר עושות את ההפך. הן מחליפות רשת בארנק באמצע quote, דוחות approval, מקטינות יתרה, מנתקות RPC, גורמות ל־deadline לפוג, משנות slippage, שולחות פעמיים, מרעננות בזמן confirmation וחוזרות לאחר כמה ימים ממכשיר אחר.

כל כשל צריך מצב למשתמש ואבחון למפעיל. “משהו השתבש” אינו מספיק. המשתמש צריך לדעת אם לא נשלחה טרנזקציה, הארנק דחה אותה, הרשת אינה זמינה, הטרנזקציה reverted או שהאישור עדיין ממתין. המפעיל צריך chain ID, intent ID, תשובת RPC, hash כשקיים וקטגוריית שגיאה יציבה—ללא חשיפת מידע פרטי מהארנק.

מטריצת כשלים הופכת זאת לנוהל חוזר. בכל שלב—חיבור, quote, approval, שליחה, confirmation ואינדוקס—מתעדים את הכשל הצפוי, התגובה הבטוחה, כלל ה־retry והראיות. מריצים את המטריצה בכל רשת נתמכת. התוצאה אינה רק כיסוי QA; היא השלד של תיעוד התמיכה ותגובה לאירועים.

5. לאמת את שכבת הנתונים, לא רק את נתיב הכתיבה

ממשק DeFi כותב באמצעות טרנזקציות, אך מרוויח אמון באמצעות קריאות. יתרות, allowances, reserves, positions וסטטוס טרנזקציות מגיעים מ־RPC או indexers. endpoints ציבוריים שימושיים לפיתוח, אך ספקים עשויים להגביל קצב. Base מציינת במפורש שה־endpoints החינמיים שלה מוגבלים ואינם מיועדים לאפליקציות production. יש לצפות למגבלות תפעוליות מקבילות גם ברשתות אחרות.

תוכנית ה־testnet צריכה לכלול כמה ספקי RPC, תקציבי timeout, כללי retry ובדיקות עקביות. יתרה ישנה מוצגת עם זמן המדידה. subscription לבלוקים מתאושש לאחר ניתוק. אינדוקס אירועים ממשיך מ־checkpoint עמיד ומתמודד עם reorganisations. הממשק אינו הופך read חסר ליתרה אפס, מפני ש־unknown ו־zero הם מצבים פיננסיים שונים לחלוטין.

גם ביצועים חשובים. מודדים זמן לחיבור, סימולציה, submission, הופעת receipt ורענון portfolio; מפרידים לפי רשת וספק. ממוצעים מסתירים את הזנב הארוך שבו המשתמשים נתקלים. מוכנות להשקה דורשת יעד שירות מוגדר ו־degraded mode כן כאשר אי אפשר לעמוד בו.

6. לבצע חזרה תפעולית על פתיחת נזילות

פתיחת pool אינה עוד פקודת deployment. היא יוצרת שוק, קובעת משטח מחיר וחושפת החלטות treasury לביצוע ציבורי. לפני mainnet, הצוות מתרגל מי מספק את הנכסים הראשונים, כיצד מאשרים את היחס הראשוני, איזה wallet או multisig חותם, כיצד הכתובות מאומתות ואיך מנטרים את הפוזיציה שנוצרה.

החזרה כוללת טעויות שבקרות production צריכות למנוע: סדר tokens הפוך, רשת שגויה, decimals בלתי צפויים, router לא מאומת, מחיר פתיחה קיצוני, gas חסר ו־submission כפול. מפעיל שני צריך לבצע את ה־runbook ולהגיע לתוצאה זהה. צילום מסך אינו ראיה מספקת; שומרים inputs, receipts, events וגרסת תצורה.

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

7. שערים מדורגים במקום מתג השקה יחיד

שחרור חזק מתקדם דרך gates. הראשון מוכיח את החוזה מקומית וב־testnet ציבורי. השני מוכיח wallet, simulation וטיפול במצבי טרנזקציה. השלישי מוכיח reads, אינדוקס, ניטור ותמיכה. הרביעי מתרגל treasury ונזילות. רק אז תצורת mainnet זכאית לאישור.

לכל שער יש owner, ראיות, תוקף ונתיב rollback. לראיות יש תוקף מוגבל מפני שרשתות, dependencies ותצורה משתנים. בדיקה שעברה מול build אחד אינה מאשרת build אחר. endpoint שהיה טוב בחודש שעבר עלול לא להתאים היום. אימות מחדש הוא חלק מהמערכת, לא סימן שהבדיקה נכשלה.

הגישה המוצרית של דור ארד עבור DAY0 היא לשמור על שקיפות לגבי מצב ה־testnet וה־pre-deployment כל עוד שערי ההשקה אינם שלמים. זו אינה מגבלה שמסתירים, אלא הבטחת מוצר: הממשק לא יהפוך התקדמות תכנונית להזמנה להעביר כסף אמיתי.

8. החלטת השקה היא סקירת ראיות

ישיבת go-live אינה צריכה להישען על ביטחון או מומנטום. היא בוחנת חבילת ראיות קצרה: build ותוצאות בדיקות חוזה, כתובות מאומתות, גרסת קטלוג רשתות, traces מקצה לקצה, תוצאות מטריצת כשלים, ביצועי RPC, dashboards לניטור, אישורי treasury, runbook תמיכה וסיכונים לא פתורים. חריגים נכתבים עם owner ומועד.

ההחלטה עדיין יכולה להיות לא. testnets חשובים גם מפני שהם הופכים דחייה לזולה. אם המערכת אינה מבדילה בין pending ל־failed, אם מפעיל אינו יכול לבצע reconciliation לפוזיציה או אם לתלות רשת אין fallback, הימנעות מפתיחת נזילות שומרת על האפשרויות העתידיות של הפרויקט.

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

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

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

  1. Ethereum.org — רשתות ו־testnets מומלצים לאפליקציותנבדק ב־8 בספטמבר 2026
  2. BNB Chain — נקודות JSON-RPC ו־chain IDs של BSCנבדק ב־8 בספטמבר 2026
  3. Base — חיבור ל־Base ול־Base Sepoliaנבדק ב־8 בספטמבר 2026
  4. Polygon — נקודות RPC של Polygon ושל Amoyנבדק ב־8 בספטמבר 2026
  5. Hardhat — בדיקת חוזים13 באוגוסט 2025

DAY0 נמצא בשלב testnet ציבורי ו־pre-deployment. הממשק אינו מזמין או מאפשר פעילות בכסף אמיתי ללא תצורת חוזים ונזילות מאומתת. המאמר הוא ניתוח מוצרי וטכנולוגי ואינו ייעוץ השקעות.