פיתוח whitelist/allowlist למינטינג NFT

פיתוח whitelist ל-NFT: היכן נשברת ההרשאה למינט

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

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

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

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

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

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

מה נותנת הרשאה מנוהלת: זמנים, עומס, סיכונים שהוסרו

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה נשאר אצלכם: קונפיגורציות, סכמות, נהלים והרשאות גישה

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

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

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

קייס: איך הסרנו את העומס ממינט והורדנו את שיעור השגיאות

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

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

מטריקות לפני ואחרי

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

במה שונה whitelist מ-allowlist ומה לבחור למינט

בקוד, בתיעוד ובדוחות ביקורת השתרש המונח allowlist — מונח ניטרלי שדחק את whitelist מהנהלים הפנימיים. בהודעות פומביות ובעמודי מינט נשאר לרוב whitelist: הוא מוכר יותר לקהל.

מבחינה פונקציונלית זה אותו דבר — רשימת כתובות שמותר להן למנט, ולכן את ההבדל בין whitelist ל-allowlist מחפשים לא בשם, אלא במכניקת ההרשאה.

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

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

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

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

במסמך הדרישות מתעדים בדיוק את המכניקה — ואז מינט allowlist שורד תיקונים בהרכב ולא תלוי איך קראו לו בהודעה.

ספקות טכניים לפני ההתחלה: שאלות ותשובות

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

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

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

איפה נשמרת רשימת הכתובות ובמה נבדלות האפשרויות?

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

איך הרשימה מוגנת מפני החלפה ודליפה?

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

אם המינט לא הלך כמתוכנן, אפשר להחזיר את המצב?

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

נדון במשימה שלכם: נחזור עם אומדן ותכנית עבודה

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

מה מחזירים בתשובה:

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

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