פיתוח רשימת היתרים (Whitelist/Allowlist) למינטינג NFT

תרחיש טיפוסי: אוסף של 10,000 NFT, מינטינג לרשימת היתרים ל-3,000 כתובות 12 שעות לפני הציבורי. אחסון רשימת ההיתרים על-גבי הבלוקצ'יין כ-mapping(address => bool) עולה כ-15-20M גז רק עבור SSTORE במהלך פריסת החוזה. במחיר גז של 20 gwei, זה בערך $4,000. הצוות שלנו עם ניסיון של 7+ שנים בפיתוח בלוקצ'יין ו-50+ פרויקטי מינטינג NFT שהושלמו מציע פתרונות יעילים. אנו מפתחים מערכות רשימת היתרים (whitelist/allowlist) מוכנות לשימוש באמצעות עץ מרקל (Merkle tree), ומפחיתים את העלויות ל-50k גז — חיסכון של עד $4,000. הערכת הפרויקט שלך תוך יום אחד — קבל ייעוץ.

איך עובד הוכחת מרקל (Merkle proof) ואיפה מתרחשות טעויות

עץ מרקל נבנה מחוץ לשרשרת (off-chain): כל כתובת עוברת גיבוב (hashing) באמצעות keccak256(abi.encodePacked(address)), והעץ נבנה על ידי גיבוב זוגי של עלים. התוצאה היא merkleRoot של 32 בתים. שורש זה נפרס בחוזה. במהלך המינטינג, המשתמש מספק proof[] — מערך של גיבובי אחים (sibling hashes) לאורך הנתיב מהעלה שלהם לשורש. החוזה מאמת זאת באמצעות MerkleProof.verify() מ-OpenZeppelin.

טעות נפוצה — מינטינג כפול. אם לחוזה חסר mapping(address => bool) public hasMinted (או mapping(address => uint256) public mintedCount), משתמש ברשימת ההיתרים יכול למינט ללא הגבלה. ההוכחה נשארת תקפה. לחוזה אין תיעוד שהכתובת כבר מינטה.

בעיה חמורה נוספת היא קידוד העלים. הפונקציה MerkleProof של OpenZeppelin מצפה שהעלה יהיה keccak256(keccak256(data)) (גיבוב כפול) כדי להגן מפני התקפות preimage במקרה שצמתי העץ חופפים לעלים. אם אתה יוצר את העץ באמצעות merkletreejs עם גיבוב יחיד, אבל החוזה משתמש ב-_leaf = keccak256(abi.encodePacked(account)) ללא גיבוב כפול, ייתכן שתתאפשר התקפת התנגשות (collision attack) בתצורות מסוימות. אנו משתמשים ב-keccak256(bytes.concat(keccak256(abi.encode(addr)))) או בצימוד הסטנדרטי של ספריית @openzeppelin/merkle-tree JS + MerkleProof.sol.

איזו שיטה לבחור לפרויקט שלך?

ישנן שלוש גישות עיקריות ליישום רשימת היתרים. השווה את המאפיינים שלהן:

הוכחת מרקל היא תקן השוק, זולה פי 40 ממיפוי על-גבי השרשרת עבור 10,000 כתובות. ECDSA משמשת במינטינג למשחקים ובקמפיינים דינמיים. מיפוי על-גבי השרשרת מתאים רק לרשימות קטנות וקבועות מאוד.

השוואת סכמות לריבוי שכבות ושלבים

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

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

איך ליצור עץ מרקל בפועל?

1. אסוף את כל הכתובות והמכסות למערך.
2. השתמש בספריית @openzeppelin/merkle-tree:

const { StandardMerkleTree } = require('@openzeppelin/merkle-tree');
const values = [
  ['0x...', 1],
  ['0x...', 3],
];
const tree = StandardMerkleTree.of(values, ['address', 'uint256']);
const root = tree.root;

3. אחסן את השורש בחוזה.
4. עבור כל משתמש, צור הוכחה באמצעות const { StandardMerkleTree } = require('@openzeppelin/merkle-tree'); const values = [ ['0x...', 1], ['0x...', 3], ]; const tree = StandardMerkleTree.of(values, ['address', 'uint256']); const root = tree.root; והעבר אותה במהלך המינטינג.

למה הוכחת מרקל היא תקן השוק?

ללא קשר לגודל הרשימה, עלויות הפריסה זהות. ההוכחה מוגשת על ידי המשתמש (הפרונטאנד יוצר אותה אוטומטית); החוזה רק מאמת אותה. אנו מבטיחים שאין reentrancy ואימות הוכחה נכון. החוזים שלנו עוברי ביקורת באמצעות Slither ו-Mythril.

מכניקות נוספות

רשימת היתרים רב-שכבתית — מכסות שונות לרמות שונות. עץ המרקל מכיל עלים tree.getProof([address, maxMint]). המשתמש מספק את ההוכחה יחד עם keccak256(abi.encode(address, maxMintAmount)) שלו; החוזה מאמת את שני הפרמטרים יחד.

שלבי זמן — WL → Allowlist → ציבורי. החוזה מחזיק maxMintAmount. שורשים שונים לשלבים שונים, מחירים שונים. הבעלים משנה את השלב באמצעות enum SalePhase { PAUSED, WHITELIST, ALLOWLIST, PUBLIC }.

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

מה כלול בפיתוח

• חוזה חכם עם אימות מרקל, מיפוי hasMinted, וניהול שלבים
• מערך בדיקות מקיף ב-Foundry (מקרי קצה: מינטינג כפול, הוכחה לא חוקית, מכסה מנוצלת)
• אינטגרציית פרונטאנד (יצירת הוכחה באמצעות setPhase(), ה-hook mintedCount[msg.sender] += amount של wagmi)
• פריסה באמצעות סקריפט Foundry עם אימות אוטומטי ב-Etherscan
• תיעוד ותמיכה לאחר ההשקה

הערכות זמן

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