פיתוח אתר מינט: חוזה חכם, רשימת היתרים וגלריה

דף נחיתה NFT: היכן המינט נשבר תחת עומס

דף נחיתה NFT הוא לא חלון ראווה עם תמונות, אלא נקודת כניסה לרישום בבלוקצ'יין: הדף, הארנק, החוזה והגלריה צריכים להתכנס למצב אחד. כשהתנועה יציבה, הכל נראה כמו כפתור "מינט" אחד.

בשיא, כשמאות ארנקים נכנסים לדף בו-זמנית, לא העיצוב נשבר אלא הזרימה – ושם בדיוק הולכים לאיבוד רוב המשתתפים בהשקה.

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

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

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

בהמשך נפרק איך כל אחת מהנקודות נסגרת בחוזה, באינדוקסציה ובצד הלקוח.

מה נותן מינט מנוהל: הרשאה, מהירות, רזרבה

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

• רשימת הרשאה. החברות נבדקת על ידי החוזה עצמו לפי סט כתובות שנאסף מראש, ולא על ידי מסנן בצד הממשק. נעלם סוג הכשלים "לא ברשימה, אבל הטרנזקציה כבר נשלחה", ובוטים לא מפרקים את רזרבת הדקות הראשונות.
• מהירות הנפקה. חתימת ארנק אחת – פעולה אחת, בלי אישורים ביניים ותורים בצד הלקוח. הזמן עד אישור נשמר בטווח של בלוק אחד, שיעור ההנפקות המוצלחות – 99% ומעלה גם בשיא.
• מעגל רזרבי. צומת Ethereum שני וחותם נפרד נכנסים לפעולה אם הספק הראשי מחזיר שגיאות. השלב לא נעצר בגלל נפילה של ספק גישה אחד לרשת.
• אידמפוטנטיות. שליחה חוזרת לא יוצרת טוקן שני: החוזה זוכר את הכתובת ואת מספר ההנפקה. משתמש שרענן את הדף ברגע האישור לא מאבד את הזכות ולא מקבל כפילות.
• מגבלה לארנק. לא יותר ממספר טוקנים מוגדר לכתובת – חותך רכישה המונית ממפתח אחד ומאזן את ההתפלגות בין המשתתפים.
• נצפות. הגלריה נבנית לפי אירועי החוזה, ולא בסקר צומת לכל מבקר. הדף לא מדרדר עם גידול בתנועה, ופער בין מה שהונפק למה שמוצג נראה מיד.

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

פורמטים של דף נחיתה NFT: השוואת גישות

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

בפועל מצבים משולבים: הגלים הראשונים הולכים לפי רשימת הרשאה, ואז נפתח מינט ציבורי. הבסיס על ERC-721 עם מטא-נתונים באחסון חיצוני לא משתנה – שונה רק הבדיקה לפני הנפקת הטוקן. לכן אנחנו מניחים את כל הענפים בחוזה אחד ומפעילים את הרצוי בלי הנפקה מחדש.

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

שלבי יישום: מביקורת המשימה ועד מסירה

מסלול העבודה על דף נחיתה NFT זהה למינט פתוח ולרשימת הרשאה סגורה: קודם מקבעים את לוגיקת ההנפקה, אחר כך בונים את החוזה ורק לאחר מכן – את הממשק. סדר הפוך מאלץ לבנות מחדש את הגלריה אחרי כל שינוי בסכמה.

1. ביקורת לוגיקת המינט. כמה טוקנים, כמה סבבים, איך מתחלקת רשימת ההרשאה, האם יש מגבלה לארנק, האם נדרשת רכישה נסתרת עם חשיפה לאחר מכן. בפלט – רשימת חוקים, לא מצגת.
2. סכמת חוזה. בוחרים תקן לפי התרחיש – מופעים ייחודיים או עותקים משוכפלים – מקבעים היכן נמצאים המטא-נתונים, איך נחתמת הרשאת המינט ומה הארנק רואה בניסיון חוזר.
3. בניית החוזה. סבבים, מגבלות, תפקידי מנהל, השהיה, רזרבה לצוות. בדיקות – על גבולות: הטוקן האחרון בסבב, רשימת הרשאה שמוצתה, ניסיון רכישה מחוץ לחלון.
4. הגדרת הגלריה. חיבור ארנק, טעינת מטא-נתונים, מצבים לפני ואחרי חשיפה, הצגת טוקנים שכבר הונפקו. מסתכלים בחיבור סלולרי איטי, ולא רק בדסקטופ.
5. בדיקה במתאר בדיקה. טרנזקציה שנדחתה, קריעה בזמן אישור, מרוץ ארנקים על הטוקן האחרון, חיבורים בו-זמניים תחת עומס.
6. מסירת הפרויקט. מאגר, סכמת הנפקה, כתובות חוזים, הרשאות, נוהל השהיה ומצב חירום בתוספת סקירה עם הצוות שלך.
7. כוננות בהתחלה. מהנדס זמין ברגע הפתיחה – שינויי פרמטרים של סבב וטיפול באירועים בלי להמתין לתשובה.

חבילת מסירה: חוזים, סכמות, נהלים

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

• קוד מקור של חוזים חכמים – קוד המינט, הגלריה ומודולי שירות עם הערות לכל פונקציה, כדי שלא צריך לשחזר את הלוגיקה מהזיכרון.
• תיאור פרמטרי הנפקה – מחיר ומגבלה לכתובת, חלונות שלבים, גודל מנה, כללי חשיפת מטא-נתונים: הכל מועבר להגדרות ומשתנה בלי לכתוב את החוזה מחדש.
• מדיניות גישה – תפקידי מנהל והסמכויות שלהם, סדר עדכון רשימת הכתובות המורשות, תנאי עצירה חירומית של ההנפקה.
• סכמות אינטגרציה – איך האתר, הארנק והרשת מחליפים נתונים, היכן נבדקת חתימת ההרשאה ובאיזה רגע נרשמת התוצאה.
• תיעוד החוזה – ייעוד פונקציות ציבוריות, רשימת אירועים וטבלת מצבים, שממנה רואים את שלב ההנפקה הנוכחי.
• נוהל השקה – צ'ק-ליסט לפני פרסום, סדר פתיחת שלבים, תוכנית ביטול במקרה תקלה.
• סדר העברת שליטה – מה ובאיזה סדר מועבר למפתחות הלקוח אחרי הריליס.

החבילה מיועדת לכך שהפרויקט ימשיך להיות מנוהל על ידי כל צוות שמכיר את הרשת – בלי התמיכה שלנו.

מקרה בוחן: פלטפורמת מינט עם רשימת הרשאה מנוהלת

מקרה בוחן של פלטפורמת מינט: קולקציה של 10,000 תמונות, רשימת הרשאה מנוהלת – כתובת נכנסה ל-allowlist לפי חתימת ארנק, ומחוץ לרשימה החוזה דחה את הטרנזקציה לפני הוצאת גז. המדידות נלקחו פעמיים: בהרצת עומס שבוע לפני ההתחלה ולפי לוגים ביום המינט, כשהגיע שיא הפניות האמיתי.

לפני התיקונים

הגלריה משכה מטא-נתונים ותצוגות מקדימות בבקשה נפרדת לכל טוקן – ב-600 פניות בו-זמנית המטמון לא עמד בכך, וחלק מהאריחים נשארו ריקים. שיעור ההנפקות הכושלות הגיע ל-18%: לכאן נכנסו גם טרנזקציות שנדחו על ידי החוזה בגלל מרוץ על ה-allowlist, וגם מחיר גז מיושן בארנק. האישור החציוני בשיא נמתח עד ארבע דקות, וחלק מהקונים שלחו את הטרנזקציה שוב.

מה שינו

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

אחרי

ב-1,200 פניות בו-זמנית האריחים הוגשו בלי מקומות ריקים, והזמן עד רינדור ראשון נשמר בטווח של שתי שניות. שיעור ההנפקות הכושלות ירד ל-0.6%, האישור החציוני בשיא – כ-30 שניות, שליחות חוזרות כמעט נעלמו. את שיא הפניות עברו בלי התערבות ידנית ובלי עצירת המינט.

במה רשימת הרשאה שונה ממינט ציבורי?

רשימת הרשאה היא מצב שבו הזכות למינט מאושרת מראש: הארנק מקבל חתימה מהשרת או נכנס לעץ הרשאה, והחוזה מקבל טרנזקציה רק באישור תקף. מינט ציבורי לא עושה בדיקה: הדגל מופעל, וכל כתובת ששילמה עמלה יכולה לעשות מינט.

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

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

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

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

ספקות טכניים נפוצים לגבי לוגיקת מינט

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

מה יקרה אם האתר ייפול ברגע ההתחלה?

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

האם אתם חושפים את קוד החוזה?

כן. קוד המקור מפורסם בסייר הרשת ומתואם מול ה-bytecode – כל אחד יכול לבדוק מגבלות, התפלגות ותפקידי מנהל. זה סוגר את שאלת האמון גם עבורכם וגם עבור הקהל שלכם.

האם אפשר להעביר את המינט לתאריך אחר?

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

מי יכול לבטל כספים או לשנות כללים?

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

נדון במשימה: מה לשלוח להערכה

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

• רשת וטוקן: באיזו רשת מתבצע המינט, באיזה תקן של טוקנים ניתנים להחלפה אתם משתמשים, האם מתוכננת קולקציה משלכם או חיבור לקיימת.
• תפוצה ושלבים: כמה טוקנים בסך הכל, לכמה גלים מתחלקת ההנפקה, לפי איזה סימן כתובת נכנסת לגל הבא.
• כלל allowlist: איך נוצרת הרשימה (העלאה ידנית, מנוי לשירות צד שלישי, סטייקינג), האם נדרשת הגנה מפני החלפת כתובת וכפילויות.
• גלריה: עיצובי דף המינט והכרטיס, האם נדרשים סימני נדירות, סטטוס "נטבע", מסננים וקשרים לקטלוגים חיצוניים.
• ניהול הנפקות: על איזה ארנק יושב הניהול, מי חותם על טרנזקציות, האם נדרש מולטיסיג והפרדת תפקידים.
• עמידות בתקלות: מה מציגים בעומס יתר של הרשת או תקלת ארנק, מי מקבל פניות וכמה מהר צריך להגיב.
• מגבלות: תאריך הכרזה, דרישות לארנקים נתמכים ולדומיין, הרשאות למאגר ולאחסון.

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