רשימת לבנים ל-NFT עם עץ מרקל — פיתוח סוהר

אחסון רשימות לבנות לקולקציות NFT על הבלוקצ'יין הוא יקר ומאט את תהליך ה-minting. אנחנו מפתחים חוזים חכמים חסכוניים ב-gas המבוססים על Merkle Tree, המאפשרים בדיקת גישה ל-minting ללא הוצאות נוספות. הצוות שלנו מספק פרויקטים turnkey—מבניית העץ ויצירת ה-proofs ועד לאינטגרציה של ה-frontend—תוך הבטחת הגנה אמינה מפני התקפות ותמיכה מתמשכת.
11+שנות ניסיון900+פרויקטים שהושלמו100+עובדים במשרד19+שותפים
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1305 השירותים
רשימת לבנים ל-NFT עם עץ מרקל — פיתוח סוהר
בינוני
~2-3 ימים

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אתר חברה B2B ADVANCE
    פיתוח אתר חברה B2B ADVANCE
    1481
  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1335
  • פיתוח אתר עבור BELFINGROUP
    פיתוח אתר עבור BELFINGROUP
    1034
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1293
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    738
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1031
הצג עוד עבודות

אוסף של 10,000 NFTs עם רשימת הרשאות (whitelist) של 3,000 כתובות. אחסון רשימת ההרשאות במיפוי on-chain פירושו 3,000 פעולות SSTORE במהלך ההתקנה — בסביבות 0.5–0.8 ETH ($1,500) בגז. רשימת הרשאות מבוססת Merkle Tree פותרת זאת: עסקה אחת לשורש, 3–5k גז לכל אימות הטבלה (mint). חיסכון אמיתי של פי 10 או יותר. החוזים החכמים המבוקרים שלנו מבטיחים הגנה מפני התקפות double-leaf ותמיכה מרובת-רמות — אתגר שאנחנו פותרים כבר למעלה מ-5 שנים ביותר מ-30 פרויקטים. הזמינו פיתוח turnkey — אתם מקבלים חוזה חכם מאובטח, מחולל הוכחות, וחזית (frontend).

איך לבנות Merkle Tree לרשימת הרשאות

עלי העץ הם hashes מסוג keccak256 של כתובות (לפעמים עם נתונים נוספים: keccak256(abi.encodePacked(address, maxMintAmount))). העץ נבנה מלמטה למעלה: עלים סמוכים מחוברים ומעובדים (hashed). השורש הוא bytes32 יחיד המאוחסן בחוזה.

import { MerkleTree } from 'merkletreejs'
import { keccak256, encodePacked } from 'viem'

const leaves = whitelist.map(addr => keccak256(encodePacked(['address'], [addr])) )
const tree = new MerkleTree(leaves, keccak256, { sortPairs: true })
const root = tree.getHexRoot() // → bytes32 для контракта

import { MerkleTree } from 'merkletreejs' import { keccak256, encodePacked } from 'viem' const leaves = whitelist.map(addr => keccak256(encodePacked(['address'], [addr])) ) const tree = new MerkleTree(leaves, keccak256, { sortPairs: true }) const root = tree.getHexRoot() // → bytes32 для контракта הוא קריטי. הוא מבטיח בניית עץ דטרמיניסטית ללא קשר לסדר העלים. בלעדיו, אותה רשימת הרשאות מייצרת שורשים שונים עם סדר כתובות שונה.

אימות בחוזה 
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

bytes32 public merkleRoot;

function mint(uint256 amount, bytes32[] calldata proof) external payable {
    bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
    require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
    // ... mint logic
}

ספריית OpenZeppelin MerkleProof מספקת יישום סטנדרטי עם מורכבות O(log n). עבור 3,000 כתובות — הוכחה של 12 hashes (log2(3000) ≈ 12). עבור 100,000 כתובות — 17 hashes. עלות הגז גדלה לאט.

איך להתגונן מפני התקפות Double-Leaf ו-Double-Mint

בעיה קלאסית של Merkle Tree בחוזים חכמים: אם עלה אינו ייחודי, הוכחה אחת יכולה לאמת מספר עלים. ספריית MerkleProof של OpenZeppelin מטפלת בכך מאז גרסה 4.7, ובודקת ש-sortPairs: true. אמצעי הגנה נוסף: hash כפול של העלה — import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol"; bytes32 public merkleRoot; function mint(uint256 amount, bytes32[] calldata proof) external payable { bytes32 leaf = keccak256(abi.encodePacked(msg.sender)); require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof"); // ... mint logic } . זה הופך התנגשויות עלים עם צמתים פנימיים לבלתי אפשריות כמעט.

רשימת הרשאות מורחבת: רמות והקצאות

רשימת הרשאות פשוטה רק בודקת אם כתובת קיימת. עבור רשימות הרשאות מדורגות (רמה 1: 2 NFTs, רמה 2: 1 NFT), כללו את הנתונים בעלה:

bytes32 leaf = keccak256(abi.encodePacked(msg.sender, maxAmount));
require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
require(amount <= maxAmount, "Exceeds allocation");

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

הגנה מפני Mint כפול

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

mapping(address => uint256) public mintedAmount;

function mint(uint256 amount, uint256 maxAmount, bytes32[] calldata proof) external {
    require(mintedAmount[msg.sender] + amount <= maxAmount, "Exceeds allocation");
    mintedAmount[msg.sender] += amount;
    // ...
}

MerkleProof.verify() מבצע SSTORE רק ב-mint הראשון של משתמש — זה אחסון O(unique_minters), לא O(whitelist_size).

הפצת הוכחות Off-Chain

שלוש גישות מוכחות למשתמשים לקבלת ההוכחה שלהם. JSON סטטי על IPFS/CDN — פשוט, ללא backend: leaf != internal_node נוצר פעם אחת, מתפרסם על CDN. API backend מציע גמישות להוספת כתובות אך דורש שרת. אירועים on-chain דרך The Graph מספקים ביזור אך מוסיפים מורכבות. עבור רוב הפרויקטים, JSON סטטי על CDN עובד הכי טוב.

שיטת הפצה מורכבות גמישות עלות
JSON סטטי (IPFS/CDN) נמוכה נמוכה מינימלית
API backend בינונית גבוהה בינונית
The Graph (subgraph) גבוהה בינונית בינונית

עדכון רשימת ההרשאות לאחר הפריסה

אם החוזה מאפשר שינוי keccak256(keccak256(abi.encodePacked(addr))) (דרך bytes32 leaf = keccak256(abi.encodePacked(msg.sender, maxAmount)); require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof"); require(amount <= maxAmount, "Exceeds allocation"); ), ניתן לעדכן את רשימת ההרשאות ללא פריסה מחדש. תרחיש: רשימת הרשאות ראשית + הוספות ברגע האחרון. בנו עץ חדש עם ההוספות, עדכנו את השורש דרך mapping(address => uint256) public mintedAmount; function mint(uint256 amount, uint256 maxAmount, bytes32[] calldata proof) external { require(mintedAmount[msg.sender] + amount <= maxAmount, "Exceeds allocation"); mintedAmount[msg.sender] += amount; // ... } . חשוב: לאחר שינוי השורש, הוכחות ישנות מפסיקות לעבוד. משתמשים עם הוכחות שמורות במטמון יקבלו revert. תקשרו את העדכון.

למה Merkle Tree עדיף על מיפוי

השוואת גז לפרויקט טיפוסי עם 3,000 כתובות:

שלב מיפוי (3,000 כתובות) Merkle Tree (3,000 כתובות)
התקנה 3,000 SSTORE (≈0.5–0.8 ETH, ~$1,500) 1 SSTORE (≈0.0001 ETH, ~$0.20)
Mint (אימות אחד) 1 SLOAD + 1 SSTORE (≈5,000 גז) 12 hashes + 1 SSTORE (≈3,000 גז)
עדכון רשימת הרשאות כתיבת כל הכתובות מחדש (יקר) עסקה אחת (≈0.0001 ETH, ~$0.20)

Merkle Tree יעיל פי 10+ בהתקנה ופי 1.5–2 בכל mint. עבור אוסף של 10,000 טוקנים עם רשימת הרשאות של 3,000 כתובות, הגז שנחסך במהלך ההתקנה הוא 0.5–0.8 ETH (~$1,500).

מה כלול בפיתוח Turnkey של רשימת הרשאות

התהליך המוכח שלנו כולל את השלבים הבאים:

  1. ניתוח דרישות: רמות, מגבלות, תקן ERC-721, צורך בעדכונים.
  2. פיתוח חוזה חכם עם אימות הוכחת Merkle (Solidity, OpenZeppelin).
  3. יצירת Merkle Tree והוכחות באמצעות סקריפט Node.js (merkletreejs).
  4. API או JSON סטטי להפצת הוכחות.
  5. אינטגרציית חזית (wagmi, RainbowKit) עם אימות בצד הלקוח.
  6. בדיקות יסודיות (Foundry: בדיקות יחידה, הוכחות נכונות/שגויות, הגנה מפני double-mint).
  7. תיעוד פריסה ואינטראקציה.

לוח זמנים ועלות משוערים

יישום בסיסי של Merkle whitelist — 2–3 ימים. עם רמות, API להוכחות, ואינטגרציית חזית — עד 5 ימים. העלות מחושבת באופן אישי לאחר ניתוח הפרויקט שלכם. אנו מבטיחים הערכות מדויקות — צרו קשר לייעוץ ונכין הצעה מסחרית.

למה להפקיד את הפיתוח בידינו?

הניסיון שלנו בפיתוח blockchain (Ethereum, Polygon, Arbitrum, Solana) משתרע על פני למעלה מ-5 שנים עם רקורד מוכח של 30+ פרויקטים מצליחים. כל חוזה חכם מבוקר עובר בדיקת קוד פנימית ואימות פורמלי של פונקציות קריטיות. אנו מבטיחים פתרונות מאובטחים וחסכוניים בגז. קבלו ייעוץ — המהנדסים המוסמכים שלנו מוכנים לנתח את הפרויקט שלכם ולהציע את הפתרון האופטימלי.