פיתוח מרקטפלייס NFT: חוזים חכמים, פרונטאנד, פריסה

מדוע פיתוח NFT-מרקטפלייס נשבר כבר בהתחלה

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

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

המוקש השני — ארגון מחדש של הבלוקצ'יין. אירוע Transfer כבר עובד, היתרה במסד הנתונים עודכנה, והשרשרת התגלגלה אחורה כמה בלוקים. בלי אישורים בעומק הנדרש ובלי עיבוד אידמפוטנטי של אירועים, המרקטפלייס מתחיל להציג בעלים שלא קיימים, ולקבל הצעות על טוקנים שכבר נמכרו.

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

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

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

מה מספקת זירת מסחר שתוכננה נכון

זירה שתוכננה נכון נבדלת מ"דמו עובד" בכך שהתנהגותה צפויה בעומסי שיא. המדדים המרכזיים כאן הם הנדסיים: הזמן מהגשת בקשה ועד אישור העסקה, שיעור התנועות שמתבטלות בשלב החתימה או ה-Mint, ואיך המערכת מתנהגת כאשר מגיעים בו-זמנית מאות קונים ל-Drop אחד.

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

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

עלות הפעולות ברשת היא גורם שניתן לשלוט בו, ולא נתון מוכתב. Batching של Mints, הוצאת חישובים כבדים מחוץ לשרשרת, ועבודה מדויקת עם אחסון המטא-דאטה — כל אלה מפחיתים את ההוצאה לפעולה ומסירים מצבים שבהם העמלה אוכלת את השוליים במכירות משניות.

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

עמידות בפני עומס מונחת כבר בשלב הארכיטקטורה: תור לכתיבה, Cache של מטא-דאטה ותמונות, ומעגל נפרד לקריאת הקטלוג. אז עומס שיא על Drop לא מפיל את הוויטרינה, אלא נמתח לאורך זמן. בדיוק השכבה הזו מבדילה בין זירה ששורדת את ההשקה לבין זו שנשברת בגל הראשון. אנו מתכננים ומלווים מערכות כאלה על Ethereum ורשתות תואמות, שבהן מחיר הטעות בחוזה הוא המקסימלי.

אפשרויות ארכיטקטורה: on-chain, היברידי, off-chain

בחירת הארכיטקטורה קובעת לא רק את עלות העסקאות, אלא גם כיצד מרקטפלייס ישרוד גידול בעומס. בפועל יש שתיים וחצי סכמות טהורות: on-chain מלא, off-chain מלא והיברידי, שבו הדברים הקריטיים חיים בבלוקצ'יין והכבדים — מחוצה לו. להלן השוואה בשלושה צירים: היכן נשמרים הנתונים, מי משלם על גז ומה קורה בגידול של פי עשרה בנפח.

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

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

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

פיתוח NFT-מרקטפלייס אינו "לכתוב חוזה ולהרכיב חלון ראווה". כאן יש שלוש שכבות בלתי תלויות: חוזים חכמים שמחזיקים נכסים ועמלות, אינדקסר שאוסף אירועי רשת לנתונים נוחים לממשק, ופרונטאנד עם אימות ארנק.

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

כיצד בנוי התהליך

1. ביקורת דרישות. מפרקים את מודל המסחר: מחיר קבוע, מכירה פומבית, חלקי תמלוגים, מכירות משניות. מגדירים אילו פעולות בתשלום, מי משלם את העמלה ומה קורה בעת ביטול לוט. בפלט — סכימת תפקידים ותרחישים מוסכמת, ולא רשימת משאלות.
2. תכנון חוזים. מפרידים לוגיקה: בנפרד תקן טוקן, בנפרד מרקטפלייס, בנפרד תשלומים. מתכננים יכולת עדכון והרשאות מנהל, כדי לא לתפור את הפלטפורמה בקוד בלתי ניתן לשינוי ללא מוצא.
3. פיתוח ובדיקה מקומית. חוזים נבנים ומורצים על רשת מקומית עם תרחישים אמיתיים: מינט, הצגה, רכישה, ביטול, משיכת כספים. במקביל מרימים אינדקסר ו-API.
4. בדיקות. בדיקות יחידה לכל פונקציית חוזה, תרחישים על סכומי גבול וקריאות חוזרות, בדיקת הרשאות גישה. בנפרד — בדיקות פרונטאנד על חיבור ארנק וחתימת טרנזקציות.
5. ביקורת לפני פרסום. בדיקה בלתי תלויה של חוזים וניתוח ההערות שנמצאו לפני דיפלוי, ולא אחריו.
6. דיפלוי והשקה. פרסום ברשת הראשית, הגדרת אינדקסר, ניטור אירועים והתראות על פעולות חריגות.
7. מסירת תיעוד. סכימות חוזים, תיאור תפקידים והרשאות, הוראות עדכון וניתוח אירועים.

כל שלב מסתיים בארטיפקט שניתן לבדוק: מפרט, סכימה, דוח בדיקות, צ'ק-ליסט ביקורת. זה מאפשר לחזור צעד אחורה בלי לכתוב מחדש את כל הפרויקט.

מה הלקוח מקבל לידיו לאחר מסירת הפרויקט

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

• קוד המקור של החוזים החכמים — חוזים להנפקת טוקנים, מסחר, תמלוגים ומכרזים, עם בדיקות וסקריפטים לפריסה. כל מבקר יכול לשחזר את הבנייה ולאמת את הלוגיקה ללא גישה לנכסים הפנימיים שלנו.
• תרשימי אינטראקציה — כיצד הפרונטאנד מתקשר עם החוזים, הארנקים והאינדקסר: זרימות נתונים, נקודות כשל, התנהגות בעסקה שנדחתה. לפיהם מהנדס חדש נכנס לפרויקט בתוך ימים ולא שבועות.
• מדיניות גישה — תפקידי מנהל, מודרטור קולקציות, מפעיל תשלומים; מה כל אחד רשאי לעשות ואילו פעולות דורשות אישור של אדם נוסף. ההרשאות ניתנות לפי עקרון הצורך המינימלי.
• נהלי תחזוקה — סדר עדכון החוזים, תוכנית חזרה לגרסה קודמת, תגובה לעסקאות תקועות ולעלייה בעלות הפעולות ברשת.
• תיעוד והוראות — תיאור הארכיטקטורה, משתני הסביבה, סדר ההרצה המקומית, רשימת בדיקה לשחרור ולקבלה.
• גישות והעברת תשתית — מאגרי קוד, סביבות, מפתחות פריסה וניטור מועברים לחשבונות שלכם עם רוטציית סודות.
• יומן מגבלות ידועות — רשימה כנה של מה שבכוונה לא נכלל בהיקף ואילו מקומות כדאי לחזק עם גידול העומס.

חבילה כזו מסירה את הסיכון המרכזי: המרקטפלייס מפסיק להיות תלוי באדם אחד ש"יודע איך הכול כאן עובד". תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.

מקרה בוחן: מרקטפלייס עם מחזור של 40,000 עסקאות בחודש

הלקוח הגיע עם מוצר מוכן במודל דומה ל-OpenSea: חלון ראווה, ארנקים, מינט ומכרזים עבדו, אך בעומס שיא הפלטפורמה "קרסה". האינדקסר לא הספיק לעמוד בקצב הבלוקצ'יין, חלון הראווה הציג נתונים מיושנים על הבעלים, והמשתמש נודע על רכישה מוצלחת רק לאחר דקות. שיעור העסקאות הכושלות הגיע ל-18% — אנשים שילמו עמלת רשת על מינט שנדחה ועזבו.

מה שינינו

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

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

מדדים לפני ואחרי

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

במה שונה חוזה חכם של מרקטפלייס מטוקן רגיל

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

לפני תחילת הפיתוח של NFT-מרקטפלייס, לקוחות שואלים לרוב את אותן שאלות — ואלו שאלות נכונות. להלן תשובות קצרות לכל אחד מהסיכונים הטכניים שאנו סוגרים בשלב התכנון, ולא לאחר ההשקה.

עם אילו רשתות המרקטפלייס יהיה תואם?

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

מה יקרה בעת מיגרציה או עדכון של חוזים?

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

כיצד מאורגנת התמיכה לאחר ההשקה?

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

תארו את המשימה — נחזור עם הערכה, תוכנית עבודה וסכמת ארכיטקטורה לתרחיש שלכם.

נדון במשימה שלכם ונחזור עם תוכנית

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

לאחר מכן אנו חוזרים עם תוכנית עבודה: חלוקה לשלבי הטמעה, תרשים אינטראקציה בין הבלוקצ'יין, הבקאנד והפרונטאנד, אפשרויות לאחסון מטא-דאטה ומדיה, מודל הרשאות ועמלות. את ההערכה אנו נותנים לפי שלבים, כדי שתוכלו להשיק בחלקים — תחילה ליבת המסחר, לאחר מכן מכירות פומביות, דרופים ואנליטיקה.

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

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

תארו את המשימה בצורה חופשית — איזה מרקטפלייס, עבור מי, אילו נכסים ומהו זרימת העסקאות הצפויה. אנו נחזור עם הערכה ותוכנית, ולא עם הבטחות כלליות.