מדוע השקת טוקן על מפעל מוכן נשברת על עקומת החיבור
עקומת החיבור של טוקן היא לא "נוסחת מחיר", אלא מצב: יתרות המאגר, סך ההנפקה במחזור וסף ההגירה צריכים להתכנס בטרנזקציה אחת. כאשר צוות בונה מפעל טוקנים בעצמו, לרוב נשבר בדיוק החיבור: חוזה העקומה מחשב את היתרה לפי עיגול אחד, ואילו מאגר הנזילות בעת ההגירה מקבל כבר מספר אחר.
על הנייר הפער ביחידות בודדות, בפועל — הקונים הראשונים מקבלים מחיר נמוך מהמחושב, ואינם יכולים למכור במחיר הצפוי.
הכשל הטיפוסי השני — הגירת נזילות תקועה. הגעה לסף והעברת הכספים למאגר מתבצעות בשני שלבים, ואם השני לא עובר (לא הספיק gas לקריאה יקרה, revert בגלל מגבלת slippage, הרשאה שנשללה), הטוקן נשאר במצב "עקומה סגורה, מאגר ריק".
המסחר נעצר, ואי אפשר להחזיר את החוזה למצב תקין בלי ענף rollback שהוטמע מראש — רק טיפול ידני וקריאה חוזרת מכתובת אחרת.
השלישי — היעדר הגנה מפני frontrunning בהשקת הטוקן. כל עוד טרנזקציית היצירה תלויה ב-mempool, הבוט רואה את הפרמטרים ומכניס את הקנייה שלו לפניה: המחיר לאחרים מתחיל כבר מוזז, והצוות לומד על כך מהגרף.
זה נסגר על ידי הצמדה ל-block, שליחה פרטית ומגבלה על הקנייה הראשונה — אבל רק אם הוטמע בחוזה מראש, ולא נוסף בדיעבד אחרי תקרית.
פיתוח פלטפורמה בסגנון pump.fun נתקע לא בממשק, אלא בשלושת המקומות האלה: עקביות העקומה והמאגר, אטומיות ההגירה, התחלה הוגנת. להלן נפרט כיצד כל אחד מהם נסגר ברמת החוזים ומה לבדוק לפני ההשקה.
איך בנויה הפלטפורמה: העקומה, המיגרציה, המפעל
פיתוח פלטפורמת pump.fun מצטמצם לשלושה צמתים שקובעים אם המוצר ישרוד תחת עומס: עקומת ה-bonding, המיגרציה אל מאגר הנזילות ומפעל הטוקנים. כל צומת פותר משימה הנדסית משלו, וכשל באחד מהם נראה למשתמש מיד — עסקה שנתקעה, מיגרציה שתלויה, כפילות של חוזה.
עקומת ה-bonding: מחיר ללא מרקט-מייקר חיצוני
העקומה קובעת את המחיר כפונקציה של נפח הטוקנים שהונפקו, ולכן הרכישות הראשונות מתבצעות במחיר נמוך, וכל רכישה נוספת מזיזה אותו כלפי מעלה. חישוב המחיר והעמלה מתבצע בחוזה חכם אחד, ללא פנייה למקורות חיצוניים — העסקה אינה תלויה בזמינות של אורקל ואינה נמתחת על פני כמה טרנזקציות. בפועל זה נותן החלקה (slippage) צפויה: המשתמש רואה את המחיר הסופי לפני האישור, ולא אחריו.
מיגרציה אל מאגר נזילות: יציבות המעבר
כאשר העקומה מגיעה לסף, הנזילות עוברת אל המאגר, והטוקן מתחיל להיסחר בפלטפורמה חיצונית. הקריטי כאן הוא אטומיות: או שהמיגרציה עוברת במלואה, או שהמצב נשאר על העקומה, בלי טוקנים "חצי-מוגרים" עם מאגר מרוח.
אנחנו מכניסים אידמפוטנטיות של הפעולה, כך שקריאה חוזרת לא תיצור מאגר שני ולא תחסום את המסחר. זה מסיר מחלקה שלמה של כשלים שבגללם פרויקטים מאבדים נזילות כבר בהתחלה.
מפעל הטוקנים: הנפקה בטרנזקציה אחת
המפעל פורש את חוזה הטוקן לפי תבנית עם פרמטרים מוגדרים ומקשר אותו מיד לעקומה. התבנית מקבעת את תקן הטוקן, ההרשאות ולוגיקת העמלות, ולכן כל הנפקה חדשה אינה דורשת הרכבה ידנית ובדיקה מאפס.
הרישום האוטומטי לאחר המיגרציה מסיר את הצעד הידני — הטוקן מופיע במאגר בלי מעורבות מפעיל, ולכן בלי עיכובים ובלי טעויות אנוש.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חוזה משותף אחד עם מרשם טוקנים | הנפקות רבות, לוגיקת עמלות אחידה | קשה יותר לבודד כשל של טוקן בודד |
| חוזה נפרד לכל טוקן | נדרשת עצמאות של פרמטרים | יותר טרנזקציות לפריסה |
| היברידי: מפעל + לוגיקת פרוקסי | איזון בין מהירות לגמישות | דורש ניהול הרשאות קפדני |
את לוגיקת חישוב העקומה וספי המיגרציה נוח להשוות עם מימושים פתוחים — אנחנו נשענים על גישות מוכחות OpenZeppelin לתקני טוקן ולבקרת גישה.
מה אתם מקבלים בסוף: מהירות ההנפקה נמדדת במספר הטוקנים לדקה בלי גידול בפעולות ידניות, יציבות המיגרציה — בשיעור המעברים המוצלחים בלי קריאות חוזרות, והמחלקה שהוסרה של כשלים — בהיעדר כפילויות של מאגרים ומצבים תלויים. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לכל אחד משלושת הצמתים.
שלבי הרכבת הפלטפורמה: מתרשים ועד מסירה
פיתוח פלטפורמה בסגנון pump.fun אינו "לכתוב חוזה טוקן", אלא להרכיב מכלול: עקומת מחיר, מפעל השקות, מנגנון הגירה לבריכה חיצונית והגנה מפני התקפות טיפוסיות.
סדר העבודות כאן חשוב יותר מהמהירות: טעות בנוסחת הרכישה או בהרשאות המפעל מתגלה לא ברשת הבדיקות, אלא בכסף אמיתי של משתמשים, ואי אפשר לבטל אותה — החוזה בלתי ניתן לשינוי. לכן אנו מנהלים את הפרויקט בשלבים, כאשר כל צעד הבא נשען על הקודם שנבדק.
- אפיון דרישות וכלכלה. מקבעים פרמטרים: צעד מחיר, היצע התחלתי, עמלת פרוטוקול ויוצר, סף יציאה לבריכה. מחשבים תרחישים — רכישה חדה, מכירה גורפת, התקפת sniper בבלוק הראשון. בפלט — מפרט עם נוסחאות, ולא "בערך כמו אצל המתחרים".
- תכנון עקומת בונדינג. בוחרים סוג עקומה (לינארית, חזקה, סיגמואידית) ובודקים אותה בסימולציות: כיצד מתנהג המחיר בביקוש אחיד ובביקוש פאני, היכן נקודת האיזון לרוכשים מוקדמים. את הנוסחה מאשרים לפני כתיבת הקוד.
- פיתוח חוזים חכמים. מרכיבים את הטוקן, העקומה, המפעל והקופה כמודולים נפרדים עם הרשאות ברורות. המפעל יוצר זוגות לפי תבנית, לכן השקה חדשה אינה דורשת התערבות ידנית ואינה גוררת אחריה טעות העתקה-הדבקה.
- בדיקות הגירה. מריצים את המעבר לבריכה חיצונית בפורק של רשת אמיתית: בודקים שהנזילות עוברת כולה, שהמחזיקים אינם מאבדים יתרה, ושהמחיר אינו קופץ בתפר. בנפרד — תרחישים עם רכישה חלקית וביטול.
- ביקורת חוזה. מבקרים חיצוניים ופאזינג פנימי מחפשים reentrancy, מניפולציות עם אורקל, עקיפת מגבלות. את ההערות סוגרים לפני הדיפלוי, ולא אחריו.
- דיפלוי ומסירת הפלטפורמה. פורסים ברשת הראשית, מוסרים מפתחות ניהול, תיעוד פרמטרים, סקריפטים לניטור והוראות לעצירת חירום.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מפרט, דוח סימולציות, כיסוי בדיקות, חוות דעת ביקורת. סדר כזה מסיר את הסיכון העיקרי — לגלות בעיה בעקומה כבר אחרי שכסף עבר דרכה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים אלה.
במה נבדלת עקומת בונדינג ממאגר נזילות?
עקומת בונדינג היא פונקציה מתמטית שקובעת את מחיר הטוקן בהתאם לנפח המטבעות שהונפקו: ככל שנקנה יותר, כך המחיר הבא גבוה יותר. החוזה עצמו משמש כמוכר וכקונה, והנזילות בהתחלה נוצרת אוטומטית מהרזרבה המוטמעת בעקומה.
מאגר נזילות פועל אחרת: המחיר נקבע לפי היחס בין שני נכסים ברזרבה, ומישהו צריך תחילה להקים את הרזרבה הזו ולהפקיד אותה.
ההבדל מתבטא בשליטה על תמחור. העקומה קובעת גרף צפוי מראש: ידוע כמה טוקנים צריך לקנות כדי שהמחיר יעלה בגובה נתון, וכמה יחזור בעת מכירה. המאגר אינו נותן הבטחה כזו — כשרזרבה דקה, הזמנה גדולה מזיזה את המחיר באופן לא פרופורציונלי, והמכירה הראשונה כבר מפילה את הציטוט.
עבור השקת טוקן חדש זה קריטי: הנזילות בהתחלה או שאינה קיימת, או שהיא כה קטנה שכל כניסה הופכת למניפולציה.
את התנודתיות שתי המודלים עוברים באופן שונה. העקומה מחליקה תנועות חדות: קניות ומכירות פועלות מול אותה רזרבה, והמחיר אינו יכול לרדת לאפס כל עוד יש כספים בחוזה. המאגר תלוי בספקי נזילות חיצוניים — בעת פאניקה הם מושכים את חלקם, העומק יורד, והחלקה גדלה באופן מפולות.
בדיוק משום כך בשלב המוקדם העקומה יציבה יותר, והמאגר נפתח מאוחר יותר, כאשר מופיע ביקוש אורגני ונפח מסחר.
יש גם צד הפוך. העקומה מגבילה את התקרה: לאחר מעבר דרכה הטוקן או נודד למאגר, או מפסיק לגדול לפי הנוסחה הנתונה. המאגר מתרחב בחופשיות ומאפשר לחבר מקורות נזילות חיצוניים, אך דורש בקרה מתמדת של העומק.
הבחירה בין המודלים היא בחירה בין צפויות מראש בהתחלה לבין גמישות למרחק, ולרוב הפלטפורמה משלבת את שני השלבים: עקומה להשקה, מאגר למסחר בוגר.
מקרה בוחן: פלטפורמה עם מפעל והגירה תחת עומס
הלקוח הגיע עם אב-טיפוס עובד: המפעל הנפיק טוקנים, עקומת החיבור חישבה את המחיר, אך בזמן השקות שיא הפלטפורמה ספגה ירידה בביצועים. עסקאות רכישה נתקעו בממפול, חלק מההנפקות עברו עם פער בשער, וההגירה לבריכה חיצונית נכשלה — הנזילות לא עברה במלואה, והטוקן נותר "נעול" בין העקומה לבריכה. אנו מנתחים מקרה בוחן של פיתוח פלטפורמה, שבו כתבנו מחדש את הליבה והצגנו מדדים לפני ואחרי.
מה היה לפני העיבוד מחדש
הנפקת טוקן ארכה דקות: המפעל פרס את החוזה ואתחל את העקומה בקריאות עוקבות, שכל אחת מהן המתינה לאישור. בעת השקה בו-זמנית של עשרות טוקנים התור גדל, וחלק מהפעולות בוטלו עקב פסק זמן. שיעור ההגירות המוצלחות עמד על כשני שלישים — את השאר היה צריך להשלים ידנית.
מה שינו
צמצמנו את ההנפקה לעסקה אחת: המפעל יוצר את חוזה הטוקן, מאתחל את פרמטרי עקומת החיבור ורושם אותו במרשם באופן אטומי. את ההגירה עשינו דו-שלבית — תחילה נקבע סף המילוי של העקומה, לאחר מכן הנזילות עוברת לבריכה ורק לאחר האישור הטוקן מסומן כמי שהיגר. את מצב העקומה הוצאנו לאחסון נפרד עם בדיקת אינווריאנטים בכל שלב.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן הנפקת טוקן | דקות, היה תלוי בתור | שניות, עסקה אחת |
| שיעור הגירות מוצלחות | ~2/3, השאר ידנית | יציב מעל 95% |
| כשלים בפעילות שיא | ביטולי רכישה המוניים | בודדים, מטופלים בריטריי |
את עומס השיא על המפעל אנחנו מנטרלים באמצעות באצ'ינג: הבקשות מקובצות ולא מתחרות על אותו סלוט. את יציבות החוזה אישרנו בהרצת תרחישים עם השקה והגירה בו-זמנית — האינווריאנטים של העקומה לא הופרו אף פעם.
Solidity
ספקות לפני התחלה: תאימות, שחזור, הרשאות גישה
לפני תחילת הפיתוח של pump.fun, המזמין בדרך כלל שואל שלוש שאלות: כיצד החוזה יתאים לרשת הנבחרת, מה יקרה לטוקנים שכבר נוצרו בעת עדכון הלוגיקה, ומי יקבל את זכויות הניהול לאחר המסירה. נבחן כל נושא לגופו.
מה אם הרשת אינה תומכת בפרימיטיבים הנדרשים? עקומת הבונדינג ומפעל הטוקנים נשענים על יכולות ספציפיות של המכונה הווירטואלית: יצירת חשבונות בתוך טרנזקציה אחת, חישוב עמלות, מגבלות על גודל המצב.
לפני תחילת העבודה אנו משווים את רשת היעד לסט זה ומתעדים פערים — אם משהו חסר, חלק מהלוגיקה מועבר לשכבת השרת, והדבר בא לידי ביטוי בארכיטקטורה מראש, ולא באמצע הספרינט.
מה אם יידרש שחזור שינויים בחוזה? החוזה בבלוקצ'יין בלתי ניתן לשינוי, ולכן השחזור מתוכנן לפני הפריסה: הלוגיקה מוצאת אל מחוץ לשכבת ה-proxy, פרמטרים קריטיים (צעד העקומה, סף ההגירה, עמלת המפעל) נשמרים באחסון נפרד ומשתנים ללא הנפקה מחדש. זה מאפשר עדכון מבוקר ומסלול חזרה צפוי במקרה של שגיאה בחישובים.
מי מקבל את זכויות הגישה? התפקידים מופרדים: מנהל פרמטרים, מפעיל השהיות, גזברות העמלות. המפתחות מועברים למזמין, החתימה המרובה (multisig) מוגדרת בהתאם לתהליכים שלו, והמהנדסים שלנו לאחר המסירה אינם שומרים גישה.
מה ייכלל במסירה לאחר מסירת הפלטפורמה?
סט מלא: קוד המקור של החוזים והשירותים, תרשים ארכיטקטורה פרוס, קונפיגורציות סביבות, מדיניות הרשאות גישה וניהול מפתחות, תיעוד של פרמטרי העקומה וההגירה, הוראות פריסה ושחזור, תוצאות בדיקות אבטחה.
מה אם יידרש פיתוח נוסף מאוחר יותר? המבנה המודולרי והתיעוד מאפשרים להרחיב את המפעל והעקומה ללא כתיבה מחדש של הליבה — פונקציונליות חדשה מתווספת כמודולים נפרדים.
המזמין מקבל לידיו:
- קוד המקור של החוזים וה-backend עם היסטוריית שינויים;
- תרשים ארכיטקטורה וזרימות נתונים;
- קונפיגורציות של רשתות וסביבות;
- מדיניות תפקידים וניהול מפתחות;
- תיעוד של פרמטרי עקומת הבונדינג וההגירה;
- הוראות פריסה, ניטור ושחזור;
- דוח בדיקות אבטחה.
תארו את המשימה שלכם — נחזור עם הערכה, תוכנית עבודה והרכב ארטיפקטים עבור הפרויקט שלכם.