רביית NFT: תכנון גנטיקה, חוזים חכמים וכלכלה

פיתוח מערכת breeding NFT: איפה הלוגיקה נשברת

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

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

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

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

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

מה נותן הוצאת הגנטיקה לכללים ניתנים לאימות

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

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

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

אפשרויות מימוש: שרשרת, שרת, היברידי

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

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

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

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

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

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

תארו את המשימה — נחזור עם הערכת לוחות זמנים ותוכנית עבודה לפי השלבים האלה.

מה אנחנו מוסרים: חוזים, סכמות, נהלים

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

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

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

מקרה בוחן: אוסף עם 40 אלף צאצאים

האוסף Mythic Brood גדל ל-40 000 צאצאים בעונת הרבייה הראשונה. המכניקה המשחקית עבדה, אבל החלק ההנדסי לא עמד בעומס: כללי הורשת התכונות נכתבו עבור המנה הראשונה ולא תוכננו ליצירה המונית של צאצאים.

לפני: סנכרון ידני בכל מנה

הנפקת מנה של 2 500 צאצאים ארכה כשלושה שבועות. החוזה לקח מספר אקראי ברגע ההנפקה, ולכן התצוגה המקדימה אצל הבעלים וסט התכונות הסופי לא התאימו — בכל מנה היו 6–7% צאצאים שנויים במחלוקת.

הצוות טיפל בהם ידנית, ולבעלים הוצעו החלפות מחוץ לחוזה: התכתבות, הנפקות טוקנים ידניות ואובדן מוניטין בקהילה.

אחרי: הורשה דטרמיניסטית

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

מנה של 2 500 צאצאים מונפקת בכמה שעות, שיעור המקרים השנויים במחלוקת ירד מתחת ל-0.5%, והפעולות הידניות יצאו מהתהליך.

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

במה שונה יצירת NFT על השרשרת מחישוב מחוץ לה?

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

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

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

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

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

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

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

שאלות טכניות ששואלים לפני התחלה

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

האם אפשר לשנות כללים של אוסף שכבר הונפק?

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

מה יקרה אם יהיה צורך להעביר את הלוגיקה?

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

למי שייכים המפתחות של החוזים?

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

איך בודקים נדירות לפני הנפקה?

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

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

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

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

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