מערכת הגנה אנטי-בוט להטבעת NFT

מערכת הגנה נגד בוטים להטבעת NFT

קולקציה יוקרתית אחת איבדה 66% מהנפח שלה בדקות הראשונות—בוטים הטביעו כמעט הכל בעוד משתמשים אמיתיים לא הצליחו ללחוץ על "הטבע" בזמן. הצוות שלנו פותר בעיה זו על ידי יישום הגנה רב-שכבתית שנבחנה בקרב על 20+ פרויקטי NFT. על ידי שילוב של רשימת היתרים של Merkle, מגבלות לכל כתובת, והגבלות אצווה מבוססות זמן, אנו מפחיתים את חלק הבוטים ל-5% וחוסכים למשתמשים עד 30% על גז לכל עסקה. עלות הפיתוח מתחילה מ-$3,000 להגנה בסיסית ו-$8,000 למערכת רב-שלבית מלאה. להלן המנגנונים האמיתיים שאנו מבטיחים כדי להבטיח שההטבעה שלך תישאר הוגנת.

סקירה של מנגנוני הגנה נגד בוטים

רשימת היתרים של Merkle: ההגנה הנפוצה ביותר

עץ Merkle של כתובות מורשות. כל כתובת ברשימה יכולה להוכיח חברות על ידי מתן הוכחה של O(log n) hashes. החוזה מאחסן רק שורש אחד (32 בתים), לא את כל הרשימה. אנו משתמשים בספריית OpenZeppelin (ראה תיעוד MerkleProof). גישה זו זולה פי 10 מאחסון הרשימה המלאה על השרשרת ומגנה מפני 95% מהבוטים.

bytes32 public merkleRoot;

function whitelistMint(uint256 quantity, bytes32[] calldata proof) external payable {
    bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
    require(MerkleProof.verify(proof, merkleRoot, leaf), "Not whitelisted");
    require(!_whitelistClaimed[msg.sender], "Already claimed");
    _whitelistClaimed[msg.sender] = true;
    _mint(msg.sender, quantity);
}

יצירת עץ Merkle היא סקריפט TypeScript מחוץ לשרשרת המשתמש ב-bytes32 public merkleRoot; function whitelistMint(uint256 quantity, bytes32[] calldata proof) external payable { bytes32 leaf = keccak256(abi.encodePacked(msg.sender)); require(MerkleProof.verify(proof, merkleRoot, leaf), "Not whitelisted"); require(!_whitelistClaimed[msg.sender], "Already claimed"); _whitelistClaimed[msg.sender] = true; _mint(msg.sender, quantity); } . השורש מתעדכן לפני ההטבעה באמצעות merkletreejs (onlyOwner). ההוכחות מתקבלות דרך API או מתפרסמות מראש ב-IPFS.

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

Commit-Reveal: הגנה מפני Frontrunning להטבעה אקראית

ללא commit-reveal, בוט מנתח את ה-mempool, רואה עסקה עם פרמטרים, ומעתיק אותה עם מחיר גז גבוה יותר—frontrunning. עם commit-reveal, המשתמש מפרסם תחילה setMerkleRoot(), ולאחר מכן לאחר N בלוקים חושף את הסוד. בתוך אותם N בלוקים, העתקה חסרת תועלת—הסוד אינו ידוע.

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

מגבלות לכל כתובת: ההכרח המינימלי

ההגנה הבסיסית ביותר היא מגבלה לכל כתובת:

mapping(address => uint256) public mintedByAddress;
uint256 public constant MAX_PER_ADDRESS = 3;

function mint(uint256 quantity) external {
    require(mintedByAddress[msg.sender] + quantity <= MAX_PER_ADDRESS, "Limit exceeded");
    mintedByAddress[msg.sender] += quantity;
    _mint(msg.sender, quantity);
}

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

מדוע Proof-of-Work משמש לעתים רחוקות?

הרעיון: לפני ההטבעה, המשתמש חייב לפתור משימה חישובית—למצוא nonce כך ש-keccak256(secret + address). זו עבודת CPU/GPU שבוטים עושים מהר יותר, אבל היא יוצרת אילוץ משאבים.

uint256 public mintDifficulty = type(uint256).max / 1000; // 0.1% хэшей проходят

function mint(uint256 nonce) external {
    bytes32 hash = keccak256(abi.encodePacked(msg.sender, nonce, block.number / 100));
    require(uint256(hash) < mintDifficulty, "Invalid proof of work");
    _mint(msg.sender, 1);
}

mapping(address => uint256) public mintedByAddress; uint256 public constant MAX_PER_ADDRESS = 3; function mint(uint256 quantity) external { require(mintedByAddress[msg.sender] + quantity <= MAX_PER_ADDRESS, "Limit exceeded"); mintedByAddress[msg.sender] += quantity; _mint(msg.sender, quantity); } יוצר חלון של ~100 בלוקים (~20 דקות). ה-nonce תקף רק בתוך החלון הזה, ומונע חישוב מראש. הקושי ניתן להתאמה באמצעות keccak256(address + nonce) < difficulty.

בעיה: משתמשים ניידים מבלים 10-30 שניות בחישוב; בוטים עם GPU לוקחים 0.1 שניות (פי 300 מהר יותר). האסימטריה מקפחת משתמשים רגילים. Proof-of-work יעיל רק בשילוב עם רשימת היתרים, שבה בוטים אינם ברשימה מלכתחילה.

עיכובי זמן ומגבלות אצווה

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

uint256 public publicMintStartBlock;

function maxMintForBlock(uint256 _block) public view returns (uint256) {
    if (_block < publicMintStartBlock + 50) return 1; // первые ~10 мин
    return MAX_PER_ADDRESS;
}

השוואת מנגנונים

כיצד לבחור את השילוב הנכון לקולקציה שלך?

קולקציה קטנה (<1000), קהילה סגורה: רשימת היתרים של Merkle + מגבלה לכל כתובת של 2-3.

קולקציה בינונית (1000-10000), הטבעה ציבורית: שלב רשימת היתרים (Merkle) → שלב ציבורי עם מגבלת אצווה מבוססת זמן + מגבלה לכל כתובת.

קולקציה גדולה (>10000), ביקוש גבוה: שלב רשימת היתרים + שלב ציבורי עם proof-of-work או הגרלה דרך VRF.

תהליך הפיתוח

מה כלול בעבודה

• חוזה חכם עם המנגנונים הנבחרים (Solidity, Foundry)
• סקריפט מחוץ לשרשרת ליצירת עץ Merkle (TypeScript)
• API להנפקת הוכחות (Node.js)
• תיעוד אינטגרציה
• ייעוץ להגדרת פרונטאנד (wagmi, RainbowKit)
• תמיכה טכנית במהלך ההשקה
• הטבעה הוגנת מובטחת עם טכניקות מוכחות נגד frontrunning

הערכות זמן

מערכת עם רשימת היתרים של Merkle + מגבלה לכל כתובת: בין יום ליומיים. מערכת רב-שלבית מלאה עם proof-of-work ו-commit-reveal: בין 3 ל-5 ימים.

לצוות שלנו יש 5 שנות ניסיון ב-Web3 ו-20+ קולקציות NFT שהושקו. אנו מספקים פתרון אנטי-בוט מוסמך שפרויקטים מובילים סומכים עליו. צור קשר להערכת פרויקט. הזמן פיתוח הגנה נגד בוטים—קבל ייעוץ והערכה מדויקת.