למה פיתוח launchpad נתקע: צווארי בקבוק בארכיטקטורה
ברגע תחילתו של סבב, העומס לא גדל בהדרגה אלא בזינוק: תור העסקאות להטענת יתרה ולרכישת נתח נתקע בצומת ארכיטקטורה אחד או שניים. צווארי הבקבוק של החוזים החכמים נראים כאן מיד — חישוב מחדש של מכסות לכל משתתף בתוך עסקה אחת, בדיקת מכסה לפי רשימת ארנקים, כתיבות חוזרות לאותו מצב.
אם הפעולות האלה לא הוצאו אל מחוץ לעסקה המבוצעת, חלק מהתשלומים המאושרים לא מגיעים לרכישה, והאדם רואה סירוב כשהכספים כבר ירדו.
צוואר הבקבוק השני — תשלומים. קבלת כספים בכמה רשתות בלי מרשם אחיד הופכת להתאמות ידניות: מהנדס משווה העברות נכנסות מול מסד הנתונים, ופער באישור אחד שובר גם את הרישום וגם את חלוקת הנתחים.
אפילו חוזים המבוססים על OpenZeppelin עם מודולים מאומתים לא עוזרים אם מודל חלוקת הנתחים מחושב מחוץ לרשת — המשתתף לא יכול להוכיח למה קיבל דווקא את המכסה שלו.
המחיר של ארכיטקטורה כזו הוא לא ממשק איטי אלא סבב שנכשל: נתחים שנמכרו מחושבים מחדש ביד, החזרים מגיעים בגל, והסבב הבא כבר לא אוסף ביקוש.
בהמשך נפרק איך פיתוח launchpad סוגר את הצמתים האלה: היכן עובר הגבול בין הרשת לשירותים חיצוניים, איך נבנה תור הבקשות ומה נקבע בחוזה כדי שחלוקת הנתחים תהיה ניתנת לאימות.
מה משתנה אחרי ההטמעה: אפקט מדיד לפלטפורמה
האפקט של הטמעת launchpad נמדד במחזור הסבב: כמה זמן עובר מהחלטה על הנפקה עד להופעת הסבב בוויטרינה. במצב ידני אלה התאמות של רשימות משתתפים, עריכות קונפיגורציה והעלאה של גרסה חדשה בלילה — כמה ימי זמן קלנדרי. כל עריכה בוויטרינה חיה בנפרד מהחוזה, וכאן בדיוק נוצר המקור העיקרי לפערים.
לאחר העברת הלוגיקה לחוזים ולפאנל הניהול, פרמטרי הסבב — לוח זמנים, מכסות, רשימה לבנה, חלוקת נתחים — מוגדרים במקום אחד. מהירות ההשקה של סבב הנפקה יורדת לשעות, וחלק מהפעולות נסגרות בלי מעורבות אדם: בדיקת ארנק, זיכוי נתח, החזר במקרה של אי-הגעה ליעד.
- מהירות ההשקה של סבב הנפקה: במקום כמה ימים של הכנה ידנית — ריצה אחת של פרמטרים והצגה בוויטרינה באותו יום.
- שיעור הפעולות שנסגרות אוטומטית: בדיקות, זיכויים והחזרים יוצאים מהמסלול הידני, ותמיכה נשארת עם טיפול במקרים שנויים במחלוקת.
- צמצום כשלים בפלטפורמה: נעלם סוג התקלות שבו מכסות המשתתף חושבו מחדש ידנית כבר במהלך הסבב.
- עומס על פלטפורמת ההנפקה: בקשות נאגרות ומעובדות בתור, ושיא הדקות הראשונות לא מפיל את הוויטרינה ואת האזור האישי.
פורסים על Ethereum ורשתות תואמות — החוזים יורשים את מודל האבטחה שלהן, ולא מודל תוצרת בית. התוצאה לפלטפורמה: התנהגות צפויה בשיא, פחות פעולות ידניות בתוך הסבב ויומן שקוף של מה שקורה עם נתחי המשתתפים.
פורמטים של פיתוח launchpad למודלים שונים של הנפקה
הפורמט של launchpad נקבע לפי מודל הנפקת הטוקנים, ולא להפך.
מחיר קבוע עם מכסה לארנק, חלוקה פרופורציונלית במקרה של ביקוש יתר, גישה בהגרלה, סבב הנפקה פרטי לפי רשימה לבנה — כל סכמה מציבה דרישות משלה לחוזה: איך מחושבת ההקצאה, היכן נשמרת הזכות לרכישה, ולפי איזה לוח זמנים הטוקנים משוחררים.
ההסתעפות השנייה — להשלים תבנית ניתנת לקונפיגורציה או לכתוב חוזה הנפקה מאפס. התבנית מכסה סבב ציבורי טיפוסי באמצעות הגדרות, אבל נוסחת חלוקה לא סטנדרטית, צילומי מצב ידניים של יתרות ותשלומים בכמה רשתות לא נכנסים בה — זו כבר פיתוח, לא קונפיגורציה.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| תבנית ניתנת לקונפיגורציה | סבב ציבורי: מחיר קבוע, מכסה לארנק | חלוקה לא סטנדרטית דורשת התאמה של הליבה |
| חוזה לפי מודל חלוקה | ביקוש יתר: רישום, הגרלה, רמות גישה | יותר תרחישי קצה בבדיקות, נדרשים צילומי מצב |
| סבב הנפקה פרטי לפי רשימה לבנה | משקיעים מוקדמים, מעגל משתתפים מצומצם | רישום זכויות ולוחות שחרור — פעולות ידניות |
| סכמת חלוקה עצמאית | כמה רשתות, vesting, החזרים במקרה של אי-הגעה ליעד | מחזור ארוך: ביקורת וניטור אחרי ההשקה |
יוצאים מהכלכלה של ההנפקה: כמה סבבים, מי משתתף בהם, מה קורה בביקוש יתר ובאי-הגעה ליעד. בהמשך משאירים קונפיגורציה מינימלית שעומדת בזה — מנגנונים מיותרים מגדילים את משטח התקיפה ואת נפח התמיכה אחרי ההשקה.
שלבי העבודה: מביקורת דרישות ועד מסירת הפלטפורמה
את העבודה מובילים באיטרציות: קודם מקבעים את מודל ההנפקה במפרט, אחר כך כותבים קוד, ורק לאחר בדיקות מוציאים את הפלטפורמה למסלול הפעלה. סדר כזה מפחית את הסיכון לעבודות מחדש: שינוי כללי סבבים בשלב התכנון עולה שעות, ואחרי ביקורת חוזים חכמים — זה כבר מחזור בדיקות חדש. להלן שלבי יצירת launchpad כפי שאנחנו עוברים אותם.
- ביקורת דרישות ומודל ההנפקה. מפרקים סבבים, מכסות לארנק, רשימות לבנות, כללי הקצאה והתחייבויות כלפי שותפים. התוצאה — מפרט שלפיו אפשר להעריך את היקף העבודה.
- תכנון סכמת הסבבים והחלוקה. מגדירים לוח זמנים לשחרור טוקנים, תקופות המתנה, מכניקת קליים וסדרי ניהול דרך מולטיסיג. את הסכמה מאשרים לפני שורת הקוד הראשונה.
- פיתוח חוזים חכמים. חוזים לסבבים, חישוב הקצאות, החזקת כספים ותפקידי מנהל. כל חוזה מכסים בבדיקות לתרחישי קצה.
- ביקורת חוזים חכמים. ניתוח פנימי של הלוגיקה בתוספת בדיקה בלתי תלויה, דוח עם רמות סיכון, תיקונים ובדיקה חוזרת של התיקונים. בלי דוח סגור לא מוציאים לפעולה.
- הטמעת launchpad והגדרת מסלולים. מסלול בדיקות, אינטגרציה של אימות זהות ותשלומים, אזור אישי למשתתף, פאנל ניהול לניהול סבבים. הרשאות מחלקים לפי תפקידים.
- בדיקות פלטפורמת ההנפקה. ריצות עומס: רכישות במקביל באותו בלוק, כשלים בשכבת התשלומים, הפעלה מחדש של שירותים, בדיקת מכסות ועסקאות חוזרות.
- קבלה ומסירה. מוסרים תיעוד, הרשאות ונוהל תגובה, ומאמנים את הצוות שלכם. בנפרד מקבעים את סדר הוצאת הפלטפורמה משימוש ואת החזרת השינויים.
מה נשאר אצל הלקוח: קונפיגורציות, סכמות, נהלים
אנחנו מחשיבים פרויקט כמושלם לא ברגע שהפלטפורמה עברה הפעלה ניסיונית, אלא כשהצוות שלכם מנהל אותה בלי המעורבות שלנו. לכן לקראת הסיום נאסף סט ארטיפקטים: קונפיגורציות מסלולים, סכמות תנועת כספים, מטריצת תפקידים ותיעוד launchpad.
- קונפיגורציות מסלולים — בדיקות, טרום-מכירה וציבורי: פרמטרי סבבים, מכסות למשתתף, כללי חלוקה, תנאי החזר כספים.
- סכמות תנועת כספים: המסלול מהטענה של משתתף ועד לקופה ולתשלומים, עם נקודות חיבור של שער תשלומים ואימות זהות.
- מטריצת תפקידי גישה והרשאות מנהל: מי מהעובדים שלכם מפעיל סבבים, מי מאשר תשלומים, מי יכול להשהות חוזה, מי רואה אנליטיקה.
- נהלי עדכון חוזים: בנפרד למודולים ניתנים לעדכון ולמודולים בלתי משתנים — אילו עריכות עוברות בלי מיגרציה, ואילו דורשות העברת מצב ואישור של כמה חתימות.
- תיעוד launchpad: תיאור מודולים, פרמטרי קונפיגורציה, נקודות אינטגרציה ותרחישי הפעלה טיפוסיים.
- הוראות לאירועים: מה לעשות בזרימת בקשות חריגה, איך מטפלים בעסקאות תקועות, ובאילו תנאים מופעלת עצירה.
- חומרים למסירת הפלטפורמה ללקוח: מאגרי קוד, מפתחות, פאנל ניטור והדרכת מנהלים עם ריצה של הפעלה טיפוסית בידיים שלהם.
הסט סוגר את הסיכון העיקרי בתחזוקה: את השינויים מבצע הצוות שלכם, לא קבלן חוץ.
מקרה בוחן: איך פלטפורמת הנפקה נפטרה מהתאמות ידניות
פלטפורמת הנפקה קיימה סבבים כל שבוע, אבל נשענה על פעולות ידניות: בקשות נאספו בטבלאות, נתחים חושבו ידנית, ובדיקות משתתפים עברו בתור. ברגע ההתחלה העומס זינק פי כמה — המפעילים לא הספיקו לטפל בזרם, ובסוף הסבב הופיעו במרשם הנתחים פערים שחיפשו אותם בדיעבד.
מה שינו
מרשם הנתחים הפך למקור האמת היחיד: נתח קשור לכתובת של המשתתף ומקובע בחוזה, ולכן עריכה ידנית הפכה לאירוע נפרד עם רישום ביומן. בדיקות המשתתפים מתבצעות מראש — כללי הקבלה יוצרים רשימה של אלה שעברו, וברגע ההתחלה נשאר רק לאשר שהם ברשימה, במקום לטפל בתור.
חישוב החלוקה עבר לחוזה על Polygon: בקשה מתקבלת, הנתח מחושב לפי נוסחה קבועה, ומכסות למשתתף ולסבב נבדקות בכניסה. המפעיל מתערב רק במקרים שנויים במחלוקת.
הפעולות הידניות לסבב הצטמצמו פי עשרה, וההתאמה הראשונית אורכת 20 דקות במקום יום עבודה. אחרי חמישה עשר סבבים מאז ההעברה — אף פער אחד ברישום הנתחים, 96% מהבקשות עוברות בלי מעורבות מפעיל, ושיא ההתחלה כבר לא משפיע על מהירות הקבלה.
את הזמן שהתפנה משקיע הצוות של הלקוח בבחירת פרויקטים, ולא בהתאמות. בנפרד הושאר מסלול החזרה: בעת החלפת חוזה סבב, הנתחים והיסטוריית הבדיקות מועברים בלי אובדן נתונים.
במה מודל קסטודיאלי שונה ממודל לא-קסטודיאלי?
ההבדל בין מודל קסטודיאלי למודל לא-קסטודיאלי של launchpad מסתכם בכך מי מחזיק במפתחות הפרטיים של המשתתף. בסכמה קסטודיאלית הפלטפורמה מחזיקה בהם, והזכות לפעול בכספים נשארת בידי המפעיל.
בסכמה לא-קסטודיאלית המפתחות לא עוזבים את המכשיר של המשתמש: הפלטפורמה מרכיבה את העסקה, והחתימה נעשית בידי המשתתף עצמו.
ההבדל הזה קובע את סוג הכשלים, לא את נוחות הממשק. מודל קסטודיאלי מאפשר לבטל פעולות שגויות ולבצע החזרים, אבל פגיעה באחסון המפתחות מאפסת את כל הכתובות בבת אחת. מודל לא-קסטודיאלי מסיר נקודת כשל יחידה, אבל הפלטפורמה לא יכולה להקפיא נכסים ולא לשחזר גישה למשתתף.
| אפשרות | אחסון מפתחות | זכויות פעולה | מתי מתאים | מגבלות |
|---|---|---|---|---|
| קסטודיאלי | הפלטפורמה, מסלולים חמים וקרים | בידי המפעיל | קמעונאות, תשלומי פיאט, החזרים | נקודת כשל יחידה, דרישות מחמירות להגנת האחסון |
| לא-קסטודיאלי | אצל המשתתף, הפלטפורמה לא רואה אותם | אצל המשתתף, חתימה לכל פעולה | הנפקות ציבוריות | אין החזרים ופעולות כפויות, עומס גבוה יותר על התמיכה |
| היברידי | מולטיסיג של הפלטפורמה והקופה | חתימה משותפת | הקצאות גדולות, משתתפים מוסדיים | לוגיקה מורכבת יותר, אונבורדינג ארוך יותר, נדרשים נהלי חתימות |
את המודל בוחרים לפני תכנון החוזים: ממנו תלויים סכמת הארנקים, התפקידים בחוזה החכם והיקף הדיווח. מודל היברידי נלקח במקומות שבהם צריך גם אונבורדינג אוטומטי וגם שליטה בהקצאות גדולות.
ספקות טכניים של לקוחות: מפרקים לפי סעיפים
שאלות על launchpad מגיעות לא על עצם ההשקה אלא על סיכונים: מה יקרה לפלטפורמה כשאלפי ארנקים ילחצו בו-זמנית על «לקנות», והאם אפשר להתאים חוזה שנכתב לפני כן. בדרך כלל זו אותה רשימה קצרה של ספקות — משתנה רק הסדר שבו הלקוח שואל אותן.
חלק מהן מוסרות לפני תחילת העבודה, וחלק בשלב תכנון סכמת החלוקה. להלן ארבע מהנפוצות ביותר, עם תשובה ברמת הארכיטקטורה, לא הבטחות.
האם אתם מבצעים ביקורת לחוזה הנפקה אם הפלטפורמה לא נכתבה על ידכם?
כן, וזו עבודה נפרדת שמתבצעת לפני כל התאמה. בודקים חלוקת הרשאות תפקידים, לוגיקת מכסות לארנק, סדר הוצאת הכספים שנאספו וטיפול בעסקה שנכשלה; בפלט — רשימת חולשות עם הערכת חומרה ותוכנית תיקונים. בלי השלב הזה כל התאמה עלולה לקבע חור קיים בחוזה.
אפשר להתאים חוזה של מישהו אחר בלי להפעיל מחדש את המכירה?
תלוי אם הוא ניתן לעדכון או לא. אם הפריסה נעשתה דרך פרוקסי ניתן לעדכון, אנחנו מחליפים את הלוגיקה במודולים נפרדים, תוך שמירה על הכתובת ועל בסיס המשתתפים שכבר נאסף.
אם החוזה בלתי משתנה — מעבירים את המצב לסכמה חדשה, שומרים את היסטוריית הרכישות ומפרסמים מראש את הכתובות כדי שהמשתתפים יראו לאן להעביר נכסים.
מה יקרה בעומס שיא על הפלטפורמה ברגע ההתחלה?
עומס שיא הוא קודם כל סדר הכניסה של עסקאות לבלוק, לא כוח השרתים. אנחנו מפזרים את מסירת הרשאות הגישה, חישוב המכסות וכתיבת המצב, שמים תור בצד האפליקציה ועוקבים אחרי עלות ביצוע הפעולה בדקות הראשונות. צוואר הבקבוק בפועל הוא קטע אחד בחוזה שכולם כותבים אליו בו-זמנית — אותו אנחנו מייעלים.
אפשר להרחיב את סכמת החלוקה בשלב מאוחר יותר?
כן, כל עוד בחוזה מונחים מודולים לשחרור וחלוקה לפי סבבים. אפשר להוסיף מאגר חדש, לשנות את לוח השחרור או לחבר קטגוריית משתתפים נוספת בלי לחלק מחדש טוקנים שכבר הונפקו. אם נשמר מראש מרווח במבנה ובתפקידים, ההרחבה לא דורשת מיגרציה.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
כדי לדון במשימה באופן ענייני ולחזור עם הערכת פרויקט הנפקת טוקנים, ולא עם מילים כלליות, צריך סט התחלתי של נתונים — הוא שקובע את ארכיטקטורת החוזים ואת היקף העבודה.
- רשת ותקן טוקן: לאן מונפק הנכס ואילו ארנקים צריכים להיות נתמכים בהתחלה.
- מודל סבבים וחלוקה: מחיר קבוע, מכרז, הגרלה או רמות לפי גודל החזקה; מכסות לארנק וכללי קבלת כתובות.
- לוגיקת שחרור: תקופת נעילה, צעד ושיעור הזמין בתחילת המסחר, גורל ההקצאות שלא נרכשו.
- אימות משתתפים (KYC): תחומי שיפוט חסומים, רשימות סנקציות, אחסון נתונים אישיים מחוץ לרשת.
- הרשאות מנהל: ארנקי מולטיסיג, השהיית ביצוע, תפקידים לעצירה ולהוצאה חירום — מה מותר לשנות אחרי ההשקה.
- אינטגרציות: צמתי גישה לרשת, שערי מחירים, אנליטיקה, קבלת כספים וסכמת תשלומים לפרויקט.
לפי הנתונים האלה אנחנו מרכיבים סכמת חוזים, תוכנית עבודה לפלטפורמה, מודל בדיקות והיקף בדיקה בלתי תלויה של הקוד — עם שלבים, לוחות זמנים ותחומי אחריות. תארו את המשימה בצורה חופשית: זה מספיק כדי לחזור עם הערכת פרויקט הנפקת טוקנים ותוכנית עבודה לפלטפורמה.