תארו לעצמכם: השקתם אוסף NFT של 10,000 טוקנים, והכל נמכר. שנה לאחר מכן, מחזיק מנסה לפתוח את המטא-דאטה—אבל זה לא נטען כי השרת שמארח את התמונות מושבת. ה-tokenURI מוביל לשום מקום. המוניטין של הפרויקט שלכם על כף המאזניים. הכאב הזה מוכר לכל מי שמאחסן NFT באירוח מרכזי. הפתרון: אחסון מבוזר על IPFS עם שכפול Filecoin דרך NFT.Storage. בואו נפרק את האינטגרציה מא' עד ת'.
ביותר מ-10 שנים, השלמנו 50+ אינטגרציות עם NFT.Storage, Pinata, ושירותים אחרים, ודחפנו העלאות אצווה עד 10,000 קבצים בסיבוב אחד. להלן פרטים מעשיים שחסכו לנו מאות שעות.
למה להשתמש ב-NFT.Storage לאחסון NFT?
NFT.Storage הוא שירות מ-Protocol Labs המספק אחסון חינמי של נתוני NFT על IPFS ו-Filecoin. טכנית: אתם מעלים קובץ דרך ה-API, מקבלים CID (מזהה תוכן)—hash מסוג SHA-256, מזהה ייחודי. הנתונים משוכפלים על Filecoin לאחסון ארוך טווח (עסקה טיפוסית היא 18 חודשים עם הוכחה קריפטוגרפית). בניגוד לשרתים מרכזיים, התוכן מוגדר לפי תוכן—אם הקובץ משתנה, ה-CID משתנה. זה קריטי ל-NFT: tokenURI כמו ipfs://Qm.../1.json עובד גם אם אתר הפרויקט נעלם.
לפרויקטים חדשים, אנו ממליצים להשתמש בלקוח המודרני w3up (v2)—הוא מטפל באוספים גדולים מהר יותר ויש לו API גמיש יותר. אם כבר יש לכם אינטגרציה legacy עם ה-REST API הישן (v1), זה עדיין עובד, אבל אנו ממליצים לבצע מיגרציה לאמינות טובה יותר.
איך האחסון עובד
IPFS—כתובת תוכן
IPFS משתמש בכתובת תוכן: ה-CID מחושב מ-hash של התוכן. ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/image.png הוא קובץ ספציפי עם hash ספציפי. אי אפשר לשנות את התוכן בלי לשנות את ה-CID—זה מבטיח חוסר שינוי עבור מטא-דאטה של NFT.
Filecoin להתמדה
IPFS לבדו לא מבטיח אחסון: אם אף צומת לא עושה pin לקובץ, הוא נעלם. NFT.Storage יוצר אוטומטית עסקאות Filecoin עבור נתונים שהועלו—אחסון מבוזר ארוך טווח עם הוכחה קריפטוגרפית של אחסון. זה מבדיל אותו משירותי pinning פשוטים של IPFS (Pinata, Infura).
Filecoin הוא בלוקצ'יין לאימות אחסון נתונים. על ידי שימוש בו, אתם מקבלים ערובה שהנתונים יאוחסנו לתקופה מוגדרת (בדרך כלל 18 חודשים), גם אם NFT.Storage יפסק לפעול.
מגבלות והגבלות
לאחר שינויי מדיניות, השירות הפסיק לקבל משתמשים חדשים דרך האתר הראשי שלו, ועבר ל-web3.storage המסחרי עם תוכניות בתשלום. עבור פרויקטים קיימים, הנתונים נשארים נגישים. עבור חדשים, חלופות כוללות Pinata, 4EVERLAND, או צומתי IPFS באירוח עצמי.
לפרויקטי NFT בייצור, אנו ממליצים על גישה היברידית: אחסון ראשי בתוספת שכפול על 2-3 שירותי pinning. זה ממזער את הסיכון לאובדן נתונים.
| שירות | מסלול חינמי | שכפול Filecoin | API |
|---|---|---|---|
| NFT.Storage | 1 GB | כן | REST / w3up |
| Pinata | 1 GB | לא | REST, SDK |
| web3.storage | 5 GB | כן | w3up |
| 4EVERLAND | 1 GB | לא | REST, SDK |
| שיטת העלאה | שימוש | מהירות עבור 10K קבצים | CID |
|---|---|---|---|
| client.store() | אחד אחד | ~שעה | שונה לכל NFT |
| client.storeDirectory() | תיקיית תמונות | ~20 דקות | אחד לתיקייה |
| Pinata batch | דרך SDK | ~15 דקות | אחד לתיקייה |
איך לשלב NFT.Storage בפרויקט
העלאת אוסף
import { NFTStorage, File } from 'nft.storage'
const client = new NFTStorage({ token: process.env.NFT_STORAGE_KEY })
// Загрузка одного NFT с изображением и метаданными
const metadata = await client.store({
name: 'Collection #1234',
description: 'Description here',
image: new File([imageBuffer], 'image.png', { type: 'image/png' }),
attributes: [
{ trait_type: 'Background', value: 'Blue' }
]
})
console.log(metadata.url) // ipfs://Qm.../metadata.json
console.log(metadata.data.image.href) // ipfs://Qm.../image.png
העלאת אצווה לאוסף 10K
לאוספים גדולים—השתמשו ב-import { NFTStorage, File } from 'nft.storage' const client = new NFTStorage({ token: process.env.NFT_STORAGE_KEY }) // Загрузка одного NFT с изображением и метаданными const metadata = await client.store({ name: 'Collection #1234', description: 'Description here', image: new File([imageBuffer], 'image.png', { type: 'image/png' }), attributes: [ { trait_type: 'Background', value: 'Blue' } ] }) console.log(metadata.url) // ipfs://Qm.../metadata.json console.log(metadata.data.image.href) // ipfs://Qm.../image.png כדי להעלות תיקייה שלמה תחת CID אחד:
const files = images.map((buffer, i) => new File([buffer], `${i}.png`, { type: 'image/png' }) )
const imagesCid = await client.storeBlob(new Blob([/* directory */]))
בפועל, שימוש ב-storeDirectory עם העלאת אצווה אמין יותר עבור אלפי קבצים.
איך לוודא העלאה תקינה?
לאחר ההעלאה, חשוב לבדוק זמינות CID דרך שערים ציבוריים: const files = images.map((buffer, i) => new File([buffer], `${i}.png`, { type: 'image/png' }) ) const imagesCid = await client.storeBlob(new Blob([/* directory */])) , pinFileToIPFS, ipfs.io/ipfs/{CID}. אם הקובץ נגיש ב-2 מתוך 3 שערים תוך 30 דקות, ההעלאה הצליחה. תמיד אמתו מטא-דאטה לפני הגדרת cloudflare-ipfs.com/ipfs/{CID} בחוזה.
שיטות עבודה מומלצות
הפרידו תמונות ומטא-דאטה לפי CID—זה מפשט ביקורת ומספק גמישות לאסטרטגיות reveal. העלו תמונות תחילה, קבלו את CID התיקייה. לאחר מכן צרו מטא-דאטה JSON עם gateway.pinata.cloud/ipfs/{CID} והעלו אותם. שינוי מטא-דאטה בלי לשנות את ה-CID הוא בלתי אפשרי—ערובה לקונים.
אחסנו את ה-CID כקבוע בחוזה. לאחר ה-reveal הסופי, ה-baseURI צריך להיות בלתי ניתן לשינוי. אם image: ipfs://{imagesCid}/{tokenId}.png נגיש לבעלים ללא הגבלת זמן, זו הנחת אמון. שקלו baseURI עבור הפונקציה שמשנה URI לאחר reveal.
השתמשו בסכמת IPFS ב-tokenURI. ארנקים ושווקים מצפים לסכמת setBaseURI, לא renounceOwnership. החזירו ipfs://—כל לקוח משתמש בשער שלו.
מה כלול בעבודה
- ניתוח הפרויקט שלכם ובחירת ספק האחסון האופטימלי (NFT.Storage / Pinata / web3.storage).
- פיתוח סקריפטים להעלאת אצווה עבור תמונות ומטא-דאטה.
- הגדרת מפתחות API ואימות CID.
- אינטגרציה עם חוזה חכם: הגדרת baseURI, renounceOwnership.
- תיעוד עם הוראות שלב-אחר-שלב לשימוש חוזר.
- תמיכה טכנית במהלך תקופת העלאת האוסף (1-2 ימים).
תהליך עבודה
- ניתוח (כמה שעות)—בחירת שירות, הערכת נפחים.
- פיתוח סקריפט העלאה (יום)—העלאת אצווה, אימות, יצירת baseURI.
- אינטגרציה עם חוזה (יום)—הגדרת URI, בדיקה על testnet.
- בדיקות—בדיקת זמינות בשערים, סימולציית mint.
- פריסה—העלאה ל-mainnet, reveal.
הערכות זמן
אינטגרציה כחלק מפיתוח אוסף NFT—1-2 ימים. עצמאית—כמה שעות עבור צוות מנוסה.
צריכים אינטגרציה אמינה? צרו קשר—אנו נקים אחסון, נאמת CIDs, ונייעץ בבחירת ספק. הזמינו אינטגרציה היום.