לנדינג Web3 של טוקן-סייל: היכן נשברים רישום המכסות וההרשאה
השלב הציבורי של מכירת הטוקן נשבר לא בעמוד עצמו — הוא סטטי וצפוי. התקלות מגיעות מהצד השני: המשתתפים נכנסים בבת אחת בדקות הראשונות, ולנדינג ה-Web3 של הטוקן-סייל מתחיל לבדוק מכסות והרשאה במצב שהממשק לא ערוך לו. מה בדיוק נקרע כאן נראה בשלושה צמתים.
הראשון — רישום המכסות. משתמש פותח שני לשוניות, הארנק חותם על שתי עסקאות עם אותו מספר, אחת מהן מחליפה את השנייה. הממשק כבר הציג הצלחה ברגע החתימה, אבל ברשת נרשמה רכישה אחת.
אותו אפקט נוצר בחזרה על בקשה בזמן timeout: צומת הרשת לא השיב, הלקוח שלח את הבקשה שוב — והמכסה לכתובת נוצלה פעמיים או לא נוצלה כלל.
השני — רשימת ההרשאה. כל עוד היא חיה בטבלה, עורכים אותה ידנית: מוסיפים כתובות, משנים את רמת המכסה, תופסים כפילויות ברישיות שונות. מודרציה ידנית לא עומדת בעומס, ותיקון לאחר פרסום שורש עץ ה-Merkle מאפס את ההוכחה — המשתתף מקבל «אינך ברשימה» כשהכתובת נכונה לכאורה. השגיאה שקטה: לא מייל, לא שורה בלוג.
השלישי — פניות בו-זמנית למאגר המכסות המשותף. את היתרה קוראים ממספר מקורות, המטמון חי חיים משל עצמו, והמספר בממשק סוטה ממצב החוזה. בהמשך נפרט כיצד זה נסגר ברמת הבדיקות, ולא ברמת הקוסמטיקה.
מה משתנה לאחר ההטמעה: לוחות זמנים, עומס, מחלקת הכשלים
כל עוד רשימת המשתתפים חיה בטבלה, השקת הטוקן-סייל היא השוואת כתובות ידנית ופריסה בלילה ברגע הפתיחה. לאחר המעבר לעץ Merkle מספיק לקבע את השורש בחוזה: הלנדינג מוסר לכל ארנק הוכחת שייכות, ותיקונים ברשימה כבר לא דורשים בנייה מחדש ופריסה חוזרת.
ההכנה להשקה מתקצרת משבועות לכמה ימים, וההתנעה מפסיקה להיות תלויה בכך שמישהו הספיק לייצא את הגרסה המעודכנת של הקובץ.
השיא — אלפי ארנקים בדקות הראשונות. חתימת העסקה מתרחשת בצד הלקוח, הלנדינג רק מרכיב את הנתונים ועוקב אחר האישור ברשת Ethereum באמצעות מינוי על אירועים.
פרופיל העומס משתנה: התשתית משרתת קריאה וזרימת סטטוסים, ולא כתיבות המוניות, ולכן העמוד לא מדרדר בשיא, ואת המכסה לכתובת וחלון הזמן בודק החוזה עצמו.
העיקר — נעלם מחלקת כשלים שלמה: זיכוי כפול, תיקון של רשימה שכבר נפתחה, אובדן בקשה בעת ניתוק הקשר, מרוץ אחרי המכסה. בדיקה אטומית דוחה עסקה שגויה בשלמותה, בלי להשאיר מצב המבוצע חלקית. אם צריך להחזיר את הקונפיגורציה, החזרה לאחור אורכת דקות: משנים פרמטר או מצביע, בלי שחזור מגיבויים.
עבור הצוות זה חיזוי: מטריקות ברורות לפי שלבים, התראות על אירועי החוזה, תרחיש זהה ברשת הבדיקות וברשת העבודה.
אפשרויות מימוש הלנדינג: מה לוקחים מוכן ומה כותבים
עמוד הטוקן-סייל הוא שני חלקים: הלנדינג עצמו (ארנק, בקשה, סטטוס) ולוגיקת ההרשאה. ההרשאה נבנית לרוב על עץ Merkle: הרשימה המלאה של הכתובות מקובעת בשורש אחד, המשתתף מציג ענף — והבדיקה בחוזה לא מתייקרת עם גדילת הרשימה. מידת החופש לשכתב את הלוגיקה הזו תלויה בגישה לבנייה.
בונה מוכן סוגר מכירות טיפוסיות במהירות, אבל מכתיב גם את צורת בדיקת ההרשאה וגם את רגע עדכון הסטטוס. בנייה עצמאית מסירה את המגבלות האלה — במחיר של תחזוקה, ניטור ובדיקות חוזרות של החוזה בכל שינוי של כללים.
שלושה מסלולים והמחיר שלהם
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בונה מוכן | מכירה לפי סכימה סטנדרטית, רשימת הרשאה קבועה, השקה בלוח זמנים צפוף | בדיקת ההרשאה והמכסות — כמו בתבנית; הסטטוס מתעדכן באיחור; אי אפשר לשכתב את הממשק; תמיכה רק דרך הספק |
| תבנית פתוחה עם התאמות | נדרש עיצוב משלנו, אין חוקי חלוקה לא סטנדרטיים | את הפורק מתחזקים בעצמנו: עדכוני אבטחה מגיעים לעיתים רחוקות, חלק מבדיקות ההרשאה נכתבות מחדש ידנית |
| בנייה עצמאית של העמוד והחוזה | סבבים לא סטנדרטיים, מכסות דינמיות, סטטוס חי, מספר מקורות הרשאה | זמן ארוך יותר עד ההשקה; נדרשים ביקורת חוזה, ניטור ובדיקות רגרסיה על כל שינוי |
אפשרות משולבת היא פשרה נפוצה: העמוד שלנו, החלוקה על חוזה מבוקר.
שלבי העבודה: מניתוח מודל החלוקה ועד המסירה
סדר העבודה כאן חשוב יותר מהמהירות: חזית הלנדינג והחוזה החכם יוצאים ברייליז אחד, ואם קודם בונים את הממשק ואחר כך משנים את מודל החלוקה, צריך לשכתב את שני השכבות. לכן הולכים מהכלכלה של ההנפקה לקוד, ומקבעים בכל שלב מה בדיוק בודקים.
- ניתוח מודל החלוקה. מאחדים סבבים, מכסות לארנק, vesting וחוקי החזר לטבלת מצבים אחת — היא הופכת למקור האמת גם לחוזה וגם לחזית.
- סכימת ההרשאה. מגדירים מי קונה ובאילו תנאים: עץ Merkle לרשימות, חתימת שרת לחלונות פתוחים, שלבים נפרדים לקבוצות שונות.
- הגדרת החוזה. מעבירים את הטבלה לפרמטרים: משך השלבים, תקרות, השהיה, אירועים שהפרונטנד נרשם אליהם. לכל אירוע יש בדיוק צרכן אחד בממשק.
- בניית חזית בזמן אמת. מינוי לאירועי הרשת, טיפול במצבי ביניים של העסקה ובחזרות בלוקים נדירות — מונה הנמכר לא «מרצד» ולא נסוג לאחור לנגד עיני הקונה.
- בדיקה בעומס. מריצים תרחיש רכישה בו-זמנית: מאות כתובות בחלון אחד, תחרות על המכסה, התנהגות בעת הצפת הסבב. בודקים איפה התור גדל ומה האדם רואה באותו רגע.
- העברת השליטה. מחלקים תפקידים לפי ריבוי חתימות, מבטלים הרשאות מיותרות, מוסרים גישות, סכימת פריסה והוראות לפעולות חירום — צוות הלקוח יכול לשנות פרמטרים בלעדינו.
סדר כזה מסיר את הסיכון המרכזי של ההשקה: פער בין מה שהלנדינג מציג לבין מה שבאמת נמצא ברשת.
ערכת המסירה: סכימות הרשאה, כללים, נהלים
לאחר המסירה נשאר לצוות הלקוח לא ארכיון קוד מקור, אלא ערכה עובדת: לפיה אפשר להריץ את לנדינג הטוקן-סייל באופן עצמאי — לשנות תנאי סבב, להוסיף משתתפים, לעדכן את החוזה ולהבין מה קורה ברגע של עומס שיא. להלן מה בדיוק נכלל במסירה ולמה כל ארטיפקט נדרש בפועל.
- סכימת ההרשאה — כיצד נוצרת רשימת הכתובות, מי ומטעם מה מכניס משתתף, היכן נשמרת ההוכחה לזכות הרכישה וכיצד היא נבדקת בכל פנייה.
- חוקי החלוקה — מכסות למשתתף ולשלב, סדר ההנפקה בעת עומס יתר ברשת, התנהגות במילוי חלקי ובסגירה מוקדמת של הסבב.
- קונפיגורציית סביבות — פרמטרים של הרשתות, כתובות החוזים שנפרסו, מפתחות גישה לצמתים ולשירותי ניטור, מופרדים בין סביבת הבדיקות לסביבת העבודה.
- נוהל עדכונים — סדר התיקונים: מי מכין, מי מאשר, כיצד נבדק בסביבת הבדיקות, כיצד מתבצעת החזרה לאחור אם הבדיקה לא עברה.
- תיעוד החוזה — ייעוד המתודות, רשימת האירועים, מגבלות והנחות ידועות, כדי שמפתח חדש ייכנס לפרויקט בלי לפנות אלינו.
- הוראות לאירועים חריגים — סימנים לתקלות טיפוסיות, נקודות בקרה, סדר הפעולות לכל תרחיש והגבול שמעבר לו מתחבר המהנדס שלנו.
- מרשם הגישות — חשבונות, תפקידים והרשאות עם ציון הבעלים של כל סעיף, כדי שהגישות לא יאבדו עם החלפת עובד.
בנפרד אנחנו מוסרים יומני ריצות עומס: הם מראים באיזה מספר פניות בו-זמניות הלנדינג מתחיל להאט והיכן נכנסים לפעולה מנגנוני ההגנה.
מקרה בוחן: עומס שיא בלי מודרציה ידנית של משתתפים
בפרויקט Aurum Launchpad לפני ההשקה ההרשאה לרשימה הלבנה נשענה על מודרציה ידנית. הרכז השווה כתובות ארנקים מול הטבלה והכניס אותן לחוזה בקריאות נפרדות — בשיא זרם הבקשות הגיע לכמה אלפי פניות בדקה, העיבוד לא הספיק, התור להרשאה גדל, וחלק מהמשתתפים ראו שגיאה ופשוט סגרו את העמוד.
כל תיקון דרש התערבות אנושית: סיכון להכניס כתובת זרה, להשאיר כפילות או לפספס בוט, ובדיקת בקשות שנויות במחלוקת ארכה עד יממה.
מה בדיוק שינו
את ההרשאה העבירו לבדיקה אוטומטית. הארנק חותם על הודעה ומאשר בעלות על הכתובת, השירות בתגובה מנפיק אישור חתום, והחוזה בודק אותו בעת הנפקת הטוקנים — אדם בשרשרת כבר לא משתתף. רשימת המורשים נאספת מראש לעץ, ולרשת נשלח רק השורש שלו, ולכן תיקונים המוניים הפסיקו לדרוש עסקאות.
התור מגביל את קצב העיבוד בשיא, בקשות חוזרות נחסמות לפי מפתח הבקשה, וכתובות בלי היסטוריה ברשת נפסלות במסנן בכניסה.
מדדים לפני ואחרי
שיא של אחד-עשר אלף פניות בעשר הדקות הראשונות עבר בלי כשלים: כל הבקשות התקינות אושרו אוטומטית, אפס תיקונים ידניים. הזמן החציוני מהחתימה ועד ההרשאה התקצר מארבע דקות לשלוש שניות, ופניות לתמיכה בנוסח «אני לא מצליח להיכנס לרשימה» — פי שישה פחות. שגיאות הרשאה (כתובת זרה, כפילות, בוט שעבר את המסנן) נעלמו כמחלקה.
החוזה נשאר בלתי ניתן לשינוי לאחר ההתנעה, ומפתח הנפקת האישורים הועבר לשירות נפרד עם יומן: בעת אירוע חריג ההרשאה מונפקת מחדש בלי תיקוני קוד. את אותו קו מתאר אנחנו פורסים גם לאיסוף בקשות, לחלוקת נתחים וללוח שחרור הטוקנים — תארו את המשימה, נחזור עם הערכה ותוכנית.
מה לעשות אם החוזה כבר נפרס ואי אפשר לשנות אותו
אי אפשר לשנות קוד בכתובת שנפרסה: הבייטקוד ברשת בלתי ניתן לשינוי, ואם שכבת proxy לא הונחה בפריסה, אין מה לתקן. המגבלה נוגעת רק לכתובת, לא למערכת — אפשר להוציא את הלוגיקה לחוזה נפרד ולהשאיר את הישן כמאגר מצב ונקודת כניסה. אז עדכון הלוגיקה הופך לפריסה חדשה ולהחלפת קריאות, ולא לשכתוב ההיסטוריה.
הסיכון המרכזי כאן הוא תאימות מאגר המצב. סדר השדות והטיפוסים שלהם נקבעו ברגע הפריסה: תכניסו משתנה לאמצע המבנה — הערכים הישנים ייקראו כערכים זרים, והרישום ייצא מכלל שליטה.
לכן שדות חדשים מוסיפים רק בסוף, ולקיימים ניגשים דרך getters מפורשים: כך התיקון לא נוגע ביתרות ובסטטוסים שכבר נרשמו.
הגירת הנתונים מתחילה בסנאפשוט: מצלמים את המצב לפי אירועי החוזה, משווים לקריאה ישירה של מאגר המצב ומקבעים סכומי ביקורת. עבור ה-whitelist זה שלב נפרד — מעבירים את הזכויות לשורש Merkle, מפרסמים אותו ומאפשרים למשתתפים לבדוק את ההוכחות שלהם לפני תחילת המכירה, ולא ברגע הרכישה.
הלאה סדר הפעולות הוא כזה: ביקורת המצב הנוכחי, העברת הלוגיקה, ריצה חוזרת של תרחישים על פורק של הרשת, ואז החלפת הלנדינג והאינדקסר. בזמן המעבר סופרים פעולות בשני החוזים ומשווים את הסיכומים שורה-שורה — פער נראה מיד, ולא אחרי ההנפקה. חזרה לסכימה הקודמת נשארת אפשרית כל עוד החוזה הישן לא הוצא משימוש.
שאלות טכניות נפוצות: הרשאה, עומס, עדכונים
הרשאת משתתף, עמידות בעומס ועדכון כללים — שלוש שאלות שבגללן לנדינג הטוקן-סייל נבנה מחדש לרוב כבר אחרי תחילת המכירות. להלן כיצד כל אחת מהן נסגרת ברמת החוזה והקונפיגורציה, ולא בפעולות ידניות ברגע השיא.
כיצד נבדקת ההרשאה אם הרשימה הלבנה נאספה ידנית?
רשימת הכתובות המורשות נשמרת בקובץ, ממנו מחשבים עץ האשים, ובחוזה נשאר רק השורש. המשתתף מציג הוכחה קצרה, החוזה משווה אותה לשורש — הבדיקה עולה אותו דבר גם למאה כתובות וגם לעשרות אלפים. השלמת הרשימה משמעה חישוב מחדש של השורש ועדכון משתנה אחד.
האם העמוד יעמוד בכניסה בו-זמנית של אלפי משתתפים?
תחילת המכירה היא פרץ: העמוד נפתח אצל כולם באותה דקה, אבל רכישה מבצעים בודדים. תוכן סטטי מוגש ממטמון בקצה, כתיבה מתבצעת רק ברגע הרכישה, ולכן הכניסות לא הופכות לתור עסקאות. התקדמות הגיוס והסטטוס של המשתתף נמשכים מהאינדקסר, ובכשל של צומת הבקשה עוברת לגיבוי.
האם נוכל לשנות את כללי המכירה בעצמנו?
כן, אם הפרמטרים מוצאים ל-constructor של החוזה: משך השלבים, טווחי החלוקה, המכסות וההשהיות משתנים בתפקיד אדמיניסטרטיבי בלי בנייה מחדש. גבולות התיקון נכתבים מראש — מה משתנה, עד מתי ומה מתקבע אחרי הרכישה הראשונה. את תפקיד האדמין אפשר להחזיק בריבוי חתימות או תחת time lock.
נדבר על המשימה: נחזור עם הערכה ותוכנית עבודה
כדי לחזור עם הערכה ותוכנית, ולא עם שאלות הבהרה, אנחנו צריכים נתוני בסיס על המשימה. להלן מה שבדרך כלל קובע את היקף העבודה על לנדינג Web3 של טוקן-סייל: ממודל החלוקה ועד להתנהגות החוזה החכם בדקות הראשונות לאחר פתיחת הסבב. אם חלק מהסעיפים עדיין לא סגורים — זה בסדר, נעבור עליהם יחד ונקבע אותם בתוכנית.
- מטרת הגיוס ומודל החלוקה: נתחים, מכסות לארנק אחד, למי ובאיזה סדר נפתחת הגישה.
- כללי הסבב: מחיר קבוע או טווח, מועד ההתנעה והסגירה, מה קורה אם לא מגיעים ליעד.
- רשימת הכתובות המורשות: כמה הן, מאיפה מגיעות, האם נדרש שורש Merkle ובאיזו תדירות הוא מתעדכן.
- רשת ונכסים: היכן מונפק הטוקן, האם מקבלים נכס מקורי או stablecoin, האם נדרש החזר כספים.
- מה מציגים בזמן אמת: התקדמות הגיוס, מונה משתתפים, טיימר, סטטוס הארנק המחובר.
- גישות וניהול: מי חותם על הפריסה, האם נדרש ריבוי חתימות והשהיה למקרה של אירוע חריג.
- עומס צפוי: כמה אנשים ייכנסו בדקות הראשונות, האם נדרשות הגבלות קצב על פניות לחוזה.
- מה כבר מוכן: מסכים, דומיין, אנליטיקה, נוסחים משפטיים בעמוד.
שלחו את מה שיש — טיוטת כללים, ייצוא כתובות, קישורים למסכים. נדבר על המשימה, נחזור עם הערכה ותוכנית עבודה לפי שלבים ומיד נציין את הצעד הבא.