פיתוח פלטפורמת מוזיקת NFT עם תמלוגים מחייבים

פיתוח פלטפורמת מוזיקת NFT

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

למה תמלוגים סטנדרטיים לא עובדים ואיך אנחנו מתקנים זאת

הדרך הקלה היא ERC-2981 עם royaltyInfo(). זה עובד רק על פלטפורמות שתומכות בכך. לאכיפה קשיחה, אנו משתמשים במסנן מפעילים המעוצב לפי Operator Filter Registry של OpenSea אך בשליטתנו. החוזה עוקף את _beforeTokenTransfer ובודק אם msg.sender נמצא ברשימת המפעילים המאושרים. העברות שנכשלות במסנן המפעילים נחסמות.

יישום דרך ERC721C מ-LimitBreak — הרחבה של התקן שמגדירה מדיניות העברה ברמת החוזה. שלושה מצבים: DEFAULT, LEVEL_ONE (בעלים בלבד), LEVEL_TWO (מפעילים מאושרים בלבד). עבור פלטפורמת מוזיקה, אנו משתמשים ב-LEVEL_ONE עם רשימה לבנה של השוק שלנו ופלטפורמות שותפות. בבדיקות שלנו, גישה זו אמינה פי 3 מתקן ERC-2981 מבחינת אכיפה.

איך אנו מיישמים חוזי חלוקה לשיתוף פעולה ביצירה

רצועה שהוקלטה על ידי שלושה אמנים — כל מכירה חייבת לפצל את התשלום אוטומטית. תבנית: כל NFT של הרצועה מפעיל חוזה PaymentSplitter נפרד (OpenZeppelin) בעת ההטבעה. כתובת החלוקה מוגדרת כ-royaltyReceiver ב-ERC-2981.

פתרון חסכוני יותר בגז הוא פרוטוקול 0xSplits. במקום להפעיל חוזה חדש לכל רצועה, נוצר Split דרך מפעל. כל התשלומים מצטברים ומחולקים כאשר נקרא distribute(). חיסכון בהפעלה: כ-100k גז לעומת 500k עבור PaymentSplitter אישי. הנה סכמה פשוטה:

// Упрощённая схема создания split при минте
function mintTrack(
    address[] calldata recipients,
    uint32[] calldata allocations,
    string calldata tokenURI
) external returns (uint256 tokenId) {
    address splitAddress = splitsFactory.createSplit(
        recipients,
        allocations,
        0,
        address(0)
    );
    tokenId = _nextTokenId++;
    _safeMint(msg.sender, tokenId);
    _setTokenURI(tokenId, tokenURI);
    _setTokenRoyalty(tokenId, splitAddress, royaltyBps);
}

מכניקת תמלוגי סטרימינג: מחוץ לרשת + הוכחת מרקל

חשבונאות על-רשתית לכל השמעה אינה מציאותית מבחינת גז. גישה עובדת: חשבונאות מחוץ לרשת + הסדר תקופתי. אירועי סטרימינג נרשמים במסד נתונים מרכזי או חצי-מבוזר (The Graph לאינדוקס, או backend משלנו). תשלומים מצטברים ניתנים לתביעה על ידי אמנים באמצעות סכמת הוכחת מרקל — בדומה לחלוקת airdrop של UNI מ-Uniswap:

1. ה-backend בונה עץ מרקל מזוגות // Упрощённая схема создания split при минте function mintTrack( address[] calldata recipients, uint32[] calldata allocations, string calldata tokenURI ) external returns (uint256 tokenId) { address splitAddress = splitsFactory.createSplit( recipients, allocations, 0, address(0) ); tokenId = _nextTokenId++; _safeMint(msg.sender, tokenId); _setTokenURI(tokenId, tokenURI); _setTokenRoyalty(tokenId, splitAddress, royaltyBps); } לתקופה
2. השורש מתפרסם בחוזה המפיץ
3. האמן קורא ל-(address, amount) — החוזה מאמת את ההוכחה ושולח טוקנים

תדירות פרסום: שבועית או בהגעה לסף של $100. גז לתביעה: כ-50k, שבמחיר גז של 30 gwei הוא כ-$1.50.

אחסון תוכן ורישוי

IPFS + Filecoin + הצפנה

קובץ האודיו לא חייב להיות נגיש לציבור ללא אימות בעלות. תבנית:

• הרצועה מוצפנת עם מפתח סימטרי (AES-256)
• הקובץ המוצפן מועלה ל-IPFS/Filecoin דרך NFT.Storage
• מפתח ההצפנה מאוחסן ב-Lit Protocol — ניהול מפתחות מבוזר
• תנאי גישה ב-Lit: claim(proof, amount)

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

לתצוגה מקדימה (דגימה של 30 שניות) — קובץ לא מוצפן בנפרד ב-IPFS. ה-URI של הקובץ המלא מאוחסן במטא-דאטה מוצפן או בחוזה נפרד עם בקרת גישה.

טוקני רישיון

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

חוזה ownerOf(tokenId) == requestAddress ממפה LicenseRegistry עם דגלים לשימוש מסחרי, יצירות נגזרות, הגבלות טריטוריאליות.

פרונטאנד: נגן אודיו עם תוכן מוגן ארנק

טכנולוגיות: Next.js + wagmi + viem. רכיב מפתח: נגן אודיו עם בדיקת בעלות. בניסיון לנגן רצועה מלאה:

1. tokenId => LicenseTerms struct — בדוק useContractRead
2. אם המשתמש הוא הבעלים: בקש מ-Lit Protocol לפענח את המפתח
3. קבל את הקובץ המוצפן מ-IPFS, פענח בדפדפן
4. צור כתובת Blob, העבר לאלמנט ownerOf(tokenId)

קריטי: הפענוח מתרחש בצד הלקוח, השרת אף פעם לא רואה את המפתח. זה מגן מפני דליפות גם אם ה-backend נפרץ. ויזואליזציית גלים: WaveSurfer.js עם עיבוד מותאם אישית. למניעת הקלטה: השתמש ב-Web Audio API עם AudioContext.

פונקציונליות שוק

מכירות ראשוניות: מחיר קבוע או מכירה פומבית. למכירות פומביות — חוזה מכירה פומבית אנגלית עם מנגנון נגד סנייפינג (אם מונחת הצעה ב-15 הדקות האחרונות, הזמן מתארך ב-15 דקות). מכירות משניות: אם משתמשים בשוק שלנו, השתמש ב-Seaport (פרוטוקול OpenSea) כבסיס. קוד פתוח, מבוקר, תומך במילוי חלקי, חבילות, הזמנות מבוססות קריטריונים. חוסך 3-6 חודשי פיתוח בהשוואה לחוזה שוק מותאם אישית. רישום מחוץ לרשת (חתימת hash הזמנה), ביצוע על-רשתי דרך <audio>.

אינדוקס ואנליטיקה

The Graph — רכיב חובה. Subgraph מתעד אירועי העברה, מכירה ותביעה. אמנים רואים לוח מחוונים עם נתונים אמיתיים: כמה פעמים הרצועה החליפה ידיים, באיזה מחיר, כמה תמלוגי סטרימינג מצטברים זמינים לתביעה. כל הנתונים מגיעים מה-subgraph דרך GraphQL, ללא עומס על ה-backend הראשי.

רשתות וגז

Base או Polygon למכירות מהדורות — גז הטבעה בסביבות $0.01-0.05, וזה מקובל. Ethereum mainnet ל-Master NFTs של אמנים בעלי ערך גבוה שבהם היוקרה גוברת על עלות העסקה. ארכיטקטורת רב-רשת: חוזים נפרסים באופן עצמאי, אימות בעלות חוצה-רשתות דרך LayerZero או CCIP אם נדרשים תרחישי גישור.

תהליך ומה כלול

אנו עובדים בשלבים: אנליטיקה (בעלי עניין, דרישות תמלוגים, היבטים משפטיים) → עיצוב ארכיטקטורה (בחירת תקן, אופטימיזציית גז) → פיתוח חוזה חכם ופרונטאנד → ביקורת (Slither + אימות פורמלי) → בדיקות testnet → פריסה + הגדרת אינדוקס. מסגרת זמן משוערת: 3 עד 6 חודשים בהתאם למורכבות. עלות מחושבת באופן אישי — צור קשר לדיון מפורט בפרויקט שלך.