רשימת היתר NFT עם עץ מרקל — פיתוח מקצה לקצה

Merkle Tree ל-whitelist של NFT: היכן נשבר הדרופ

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

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

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

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

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

מה נותנת בדיקת הזכות לדרופ במקום רשימות ידניות

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

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

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

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

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

גישות ל-whitelist לדרופ NFT: השוואת מצבים

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

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

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

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

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

מה נשאר במאגר ובתיעוד לאחר המסירה

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

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

מקרה בוחן: דרופ סגור בלי דליפות, בוטים ותיקונים ידניים

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

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

מדדים לפני ואחרי

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

מה לעשות אם whitelist כבר מנוהל ידנית

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

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

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

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

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

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

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

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

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

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

אפשר להשלים את הרשימה אחרי ההתחלה?

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

האם כתובות המשתתפים גלויות בבלוקצ'יין?

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

מה קורה בכשל בהקצאת ההוכחות?

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

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

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

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

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