למה רנדום הוגן שובר את הכלכלה של המשחק Tower
הרנדום בצד השרת במשחקים דמויי Tower בנוי כך: המחולל חי בבקאנד, והשחקן רואה רק את התוצאה. כל עוד נפילת פריט נדיר נקבעת על ידי פונקציה סגורה, סביבה צומח בהכרח שוק של אינסייד — עובדים, קבלני משנה, מישהו עם גישה ללוגים.
די באדם אחד שיודע את התזמון של הנפילה כדי שסכמת «נכנסים לריצה בשנייה הנכונה» תהפוך להמונית. זו לא השערה: בפרויקטים עם רנדום סגור, קנוניה בין שחקנים מתגלה בשבועות הראשונים אחרי ההשקה, ברגע שנוצר שוק משני לפריטים.
מכאן נכנסת הכלכלה. אם הצפיות של הנפילה דולפת החוצה, פריטים נדירים מפסיקים להיות נדירים — מוציאים אותם בכמויות, המחיר בשוק יורד, ואיתו מתבטל כל המשמעות של התקדמות בתשלום. הקהל המשלם הוא הראשון שמבחין שההשקעה שלו איבדה מערכה לא בגלל תחרות הוגנת, אלא בגלל חור במחולל. הנטישה מגיעה לא מקושי המשחק, אלא מתחושה שהחוקים לא עובדים עבור כולם.
הקצה ההפוך — רנדום דטרמיניסטי לחלוטין לפי סיד של השחקן. הוא הוגן על הנייר, אבל יוצר בעיה אחרת: אפשר לסרוק סידים אוף-צ'יין, לחשב רצפים משתלמים מראש, ואז רנדום הוגן הופך לכלי למי שיודע לחשב. בין «השרת משקר» ל«השחקן מחשב קדימה» יש פס צר שבו אי אפשר גם לסובב את הרנדום וגם לא לחזות אותו.
דווקא כאן רנדום הוגן מפסיק להיות פרט טכני והופך לתנאי של כלכלת המשחק. צריך מקור אקראיות שאף אחד מהמשתתפים — לא הצוות ולא השחקן — לא שולט בו ולא יכול לחזות אותו עד רגע החשיפה. נפרק איך זה נסגר בפיתוח של המשחק Tower על בלוקצ'יין ומה בדיוק בודק השחקן כשהוא מטיל ספק בהוגנות הנפילה.
מה נותן רנדום ניתן לאימות על הבלוקצ'יין
אקראיות ניתנת לאימות מסירה את מקור הקונפליקט המרכזי ב-Tower: השחקן אינו רואה כיצד נוצר הדרופ, וברירת המחדל שלו היא לחשוב שתוצאה נדירה עובדה לטובת הבית.
כאשר מקור האקראיות נרשם בבלוקצ'יין וניתן לבדוק אותו בדיעבד, הוויכוח "לא קיבלתי" עובר ממישור האמונה למישור האריתמטיקה — שני הצדדים מסתכלים על אותה תוצאה בדיוק.
המכניקה פשוטה: השרת מפרסם מראש את ההאש של הזרע העתידי, ולאחר הסבב חושף את הזרע עצמו. כל אחד יכול להציב אותו בנוסחה ולהשתכנע שהפריט שנפל הוא תוצאה הוגנת, ולא החלפה לאחר ההימור. זה סוגר מחלקה שלמה של מניפולציות: עריכה של המחולל בדיעבד, התאמת זרע להימור גדול, קנוניה עם המפעיל.
Chainlink VRF נותן בדיוק מקור כזה — האקראיות מגיעה מבחוץ ומאושרת קריפטוגרפית, ולכן אי אפשר לחזות אותה לפני הסבב ואי אפשר לשכתב אותה אחריו. עבור Tower משמעות הדבר היא שדרופים נדירים הופכים לניתנים לערעור במובן הטוב: אפשר להוכיח אותם, ולא רק להצהיר עליהם.
ההשפעות מדידות. שיעור הדרופים השנויים במחלוקת יורד כמעט לאפס — אין על מה להתווכח כאשר התוצאה משוחזרת. שימור השחקנים המשלמים עולה: אדם משקיע ביתר רצון במערכת שבה התוצאה אינה תלויה במצב הרוח של המנהל. והצוות מפסיק לבזבז זמן על טיפול בתלונות "על חוסר הגינות" ועוסק בתוכן, ולא בהתנצלויות.
רווח נפרד — האמון של השחקנים מפסיק להיות הבטחה שיווקית. אפשר להראות אותו: קישור לעסקה, זרע, נוסחה. מי שהטיל ספק, בודק בעצמו ונשאר.
אפשרויות למקור אקראיות: השוואת גישות
מקור אקראיות הוא מה שקובע את הגינותו של כל סיבוב ב-Tower: היכן בדיוק נוצר המספר, מי יכול להשפיע עליו והאם ניתן לאמת את התוצאה בדיעבד. להלן ארבע סכמות שביניהן באמת בוחרים בעת פיתוח משחק Tower על בלוקצ'יין, עם החוזקות והחולשות שלהן.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| יצירה מלאה on-chain | מכניקות פשוטות שבהן האקראיות אינה משפיעה על התשלומים | הוולידטור רואה את תוכן הבלוק ויכול לבחור אותו כך שהתוצאה תהיה משתלמת לו |
| אורקל אקראיות חיצוני | נדרש מקור בלתי תלוי שאינו קשור לרשת | האמון עובר למפעיל האורקל, מתווספים השהיית תגובה ונקודת כשל |
| סכמה היברידית עם מספר אקראי ניתן לאימות | סיבובים עם הימורים ותשלומים אמיתיים | מורכבת יותר למימוש: נדרשים חוזי מאמת וטיפול נכון בפסקי זמן |
| פסאודו-אקראיות בצד השרת | מצבי טיוטה, סביבות בדיקה | השחקן אינו יכול לאמת את ההגינות, כל ביקורת נתקלת באמון במפעיל |
יצירה טהורה on-chain נראית אטרקטיבית עד שמתברר שכורה או ולידטור, היוצר את הבלוק, רואה את כל ההימורים של הסיבוב ויכול לדחות בלוק לא משתלם. אורקל חיצוני פותר בעיה זו, אך מעביר את האמון לצד שלישי: אם תגובתו מתעכבת או חתומה במפתח הלא נכון, הסיבוב נתקע.
הסכמה ההיברידית סוגרת את שתי הנקודות החלשות: המספר האקראי מגיע מבחוץ, והחוזה מאמת את חתימתו ורק לאחר מכן מחשב את התוצאה. השחקן יכול בכל רגע לחשב מחדש את התוצאה לפי נתוני הסיבוב השמורים — זוהי הגינות ניתנת לאימות, שעליה נשען האמון ב-Tower.
כיצד אנו מיישמים רנדום היברידי במשחק Tower
יישום רנדום הוגן מתחיל לא בקוד, אלא בניתוח האופן שבו הדרופ פועל כיום. אנו בוחנים היכן נוצר המספר, מי ובאיזה שלב יכול להשפיע עליו, כיצד התוצאה מגיעה ללוגיקה של המשחק ומה רואה השחקן. לעתים קרובות כבר כאן ניכר נקודת התורפה: המקור צפוי, ובדיקת התוצאה אינה נגישה לא לשחקן ולא לכם.
לאחר מכן אנו מתכננים את סכימת הייצור כך שהאקראיות תיוולד מחוץ לשרת המשחק, וניתן יהיה לבדוק את תוצאתה באופן בלתי תלוי. את המקור אנו מתאימים לתרחיש הדרופ שלכם — נדירות הפריטים, הסיכויים, המגבלות לשחקן.
לאחר ההרכבה אנו מריצים בדיקת צפיות: מדמים סדרות דרופים ומוודאים שההתפלגות תואמת את המוצהר, ושאין אפשרות להחליף את התוצאה מצד השחקן.
- ביקורת הלוגיקה הנוכחית של הדרופ: מאתרים נקודות ייצור, השפעה על התוצאה והפער בין הסיכויים המוצהרים למעשה.
- תכנון סכימת הייצור: מגדירים מה נחשב מחוץ למשחק, כיצד התוצאה נקשרת לדרופ מסוים וכיצד ניתן לבדוק אותה.
- הגדרת מקור האקראיות: מחברים מקור ניתן לבדיקה ומקשרים אותו לכללי הנדירות והמגבלות שלכם.
- בדיקת צפיות: מדמים סדרות דרופים המוניות, משווים את ההתפלגות למוצהר, מחפשים אפשרויות להחלפה.
- אינטגרציה עם הלוגיקה של המשחק: התוצאה מגיעה להנפקת הפריטים ללא השהיות המשפיעות על מהלך המשחק.
- בדיקות בתרחישי קרב: מריצים קונפיגורציות דרופ אמיתיות ומקרי קצה — הנפקות ריקות, פריטים נדירים, ניסיונות חוזרים.
- מסירת תיעוד: מתארים את הסכימה, הגדרות המקור וסדר הבדיקה, כדי שצוותכם ינהל את המשחק בלעדינו.
כל שלב מסתיים בארטיפקט: מפת הלוגיקה הנוכחית, סכימת הייצור, מקור מוגדר, דוח בדיקת צפיות. אתם רואים על מה עומדת הגינות הדרופ, ויכולים לאשר אותה בפני השחקנים. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מדיניות גישה ותפקידים במערך הייצור
ייצור אקראיות הוא אותו אזור שבו טעות בזכויות גישה עולה ביוקר רב ביותר: החלפת קלט או עריכות בעקיפת הנהלים שוברות את יכולת ההוכחה של הסיבוב בדיעבד.
לכן את המערך מפרידים לפי תפקידים, ולא לפי "אנשים מהימנים": לכל תפקיד יש סט פעולות משלו, ואף אחד מהם אינו מכסה את כל המחזור כולו.
את תפקידי הייצור מפרידים כך: יוזם הסיבוב רק מבקש ערך, מפעיל המפתחות חותם על התשובה, שירות המבצע מפרסם את התוצאה, המבקר קורא את היומן ללא זכות כתיבה. מפתחות החתימה מתקיימים באחסון מבודד, והגישה אליהם — באמצעות הפעלות קצרות מועד, ולא באמצעות אסימונים קבועים.
- תצורות מקור האקראיות: פרמטרי הבקשה, ספי האישורים, כללי ייצור מחדש בעת אי-זמינות.
- סכמות זרימות הנתונים: מבקשת הסיבוב ועד פרסום התוצאה, עם נקודות שבהן הערך נקלט והופך לבלתי ניתן לשינוי.
- מדיניות גישה: מטריצת "תפקיד — פעולה", הפרדה בין חתימה לפרסום, איסור על שילוב תפקידים באותו אדם.
- נוהל עדכון: סדר החלפת המפתחות ופרמטרי המקור, חלון תאימות לסיבובים ישנים, תוכנית נסיגה.
- יומן ביקורת: מי, מתי ומה שינה בתצורה, עם קישור לסיבוב מסוים.
- הנחיות למשמרת התורנית: מה לעשות בעת אי-התאמה של התוצאה וכיצד לתעד את האירוע.
- תיעוד לשחזור: כיצד להקים את מערך הייצור מאפס ולבדוק את שלמות ההיסטוריה.
סט כזה מסיר את הסיכון המרכזי — המצב שבו יכול לשנות את הפרמטרים אותו אדם שמפרסם את התוצאה. הלקוח מקבל מערך שנבדק באופן בלתי תלוי, ומועבר לצוות חדש ללא הסכמות בעל-פה.
מקרה בוחן: כיצד רנדומליות היברידית הסירה דרופים שנויים במחלוקת
ללקוח הגיעו עם המשחק Tower: שחקנים עברו קומות, קיבלו דרופים על תוצאות נדירות, וחלק מהקהילה החל לפקפק בפומבי בהגינות הגנרטור. הטענות היו אחידות — "הפרס נפל למישהו אחר", "הפריט הנדיר לא נפל אחרי סדרת מעברים".
בירור כל פנייה ארך שעות: לוגי הייצור היו בצד השירות, השחקן לא יכול היה לבדוק אותם באופן עצמאי, והמחלוקת הצטמצמה ל"אנחנו אומרים שזה הוגן". שיעור הדרופים השנויים במחלוקת הגיע עד 4% מכלל ההנפקות, והבירור ארך בממוצע 6 שעות לפנייה.
העברנו את הייצור לסכמה היברידית: השרת מחשב את התוצאה, אך הזרע האקראי נלקח ממקור אקראיות ציבורי Chainlink VRF. כל הגרלה מקבלת הוכחה ניתנת לאימות, שהשחקן יכול להשוות עם רשומה בבלוקצ'יין — לא ניתן להחליף את התוצאה לאחר הפרסום, והגנרטור עצמו מפסיק להיות נקודת אמון.
בד בבד נסגר סוג שלם של התקפות: חיזוי הזרע לפי תזמון הבקשה ובחירת התוצאה באמצעות כוח גס של בקשות הפכו לבלתי אפשריים.
מה השתנה במספרים
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הדרופים השנויים במחלוקת | ~4% מההנפקות | מתחת ל-0.3% |
| זמן בירור הפנייה | ~6 שעות | דקות, לפי קישור להוכחה |
| שימור שחקנים משלמים | קו בסיס | עלייה בשליש תוך חודשיים |
| סוג התקיפות על הגנרטור | חיזוי ובחירת זרע | נסגר |
אפקט נפרד — העומס שהוסר מהתמיכה: פניות טיפוסיות "תוכיחו שזה הוגן" הוחלפו בקישור ציבורי אחד לבדיקה. שימור השחקנים המשלמים עלה בשליש תוך חודשיים — שקיפות ההנפקה משפיעה ישירות על הנכונות לשלם עבור תוצאות נדירות.
במה שונה רנדום היברידי מ-on-chain טהור
יצירה טהורה של on-chain משמעה שכל מספר אקראי נולד בתוך טרנזקציה: החוזה קורא למקור האקראיות, מאמת אותו ומיד רושם את התוצאה למצב. הסכימה שקופה וניתנת לאימות על ידי כל אחד, אך יש לה מחיר — היצירה מתבצעת בבלוק, ולכן כל סיבוב גורר אחריו גז, ממתין להכללה בבלוק ותלוי בעומס הרשת.
כאשר שחקן פותח סבב ב-Tower, הוא ממתין לא רק לתגובת השרת, אלא גם לאישור הרשת; בעומס שיא ההשהיה מתארכת, ועלות הטרנזקציות הופכת מורגשת בפעולות המוניות.
רנדום היברידי מפריד בין שתי שאלות: היכן נולדת האקראיות והיכן היא נרשמת. מקור האקראיות (ספק VRF) מפיק ערך ניתן לאימות מחוץ לבלוקצ'יין, והחוזה מקבל אותו ורושם את התוצאה עם הוכחה קריפטוגרפית.
השחקן מקבל תגובה מהירה, מכיוון שהשהיית היצירה אינה כבולה לזמן הבלוק, והרשת נטענת רק ברישום הסופי. יכולת האימות נשמרת: ניתן לבדוק מחדש את ההוכחה, ולא ניתן להחליף את התוצאה בדיעבד.
בחירת הסכימה היא שאלה של עדיפות. רנדום היברידי מנצח במקומות שבהם חשובים היענות ונפח: סדרות סבבים, הימורים תכופים, מכניקות עם משוב מהיר.
יצירה טהורה של on-chain מנצחת במקומות שבהם חשובים יותר האוטונומיה המרבית של החוזה ומינימום תלויות חיצוניות — אירועים נדירים, הימורים גדולים, תרחישים שבהם השהיה של כמה בלוקים אינה קריטית.
בפועל בוחרים את הסכימה לפי שלושה צירים: ההשהיה המותרת ביצירה, עלות הטרנזקציות לפעולת משחק אחת ודרישות האמון. אם הסבב צריך להיסגר תוך שניות ויש מאות כאלה בשעה — היברידי; אם האירוע נדיר ומחיר ההשהיה קטן — אפשר להישאר כולו on-chain. אנו מתכננים את שתי האפשרויות ומתאימים את הסכימה למכניקה ספציפית של Tower, ולא לתבנית כללית.
ספקות טכניים לגבי הטמעת רנדומליות ב-Tower
מחולל מספרים אקראיים מורחב אינו סיבה לשכתב את המשחק. אם הרנדומליות כבר פועלת בצד השרת, אנו משאירים אותה כמקור אנטרופיה, ומעליה מוסיפים שכבת יצירה ניתנת לאימות: השרת עדיין מחשב את התוצאה, אך מפרסם התחייבות קריפטוגרפית לפני הסיבוב וחושף אותה לאחריו. לוגיקת המשחק, האיזון והלקוח אינם משתנים — משתנה רק האופן שבו התוצאה נרשמת ומאומתת.
העומס על המשחק גדל לא מהאימות עצמו, אלא מהאופן שבו זרימת הבקשות מאורגנת. האישורים מקובצים לחבילות, ההתחייבויות מחושבות מראש, והאימות של הגינות מועבר לשירות נפרד שאינו חוסם את מחזור המשחק. בפועל מדובר בשברי מילישנייה לסיבוב — השחקן אינו מבחין בהבדל, והשרת אינו נתקל במגבלות.
הגירת סכימת הנתונים מתבצעת ללא עצירת המשחק: שדות חדשים מתווספים לצד הישנים, סיבובים נכתבים בשני הפורמטים כל עוד ההעברה נמשכת. התאימות לארנקים וללקוחות הנוכחיים נשמרת — הכתובות, פורמטי החתימה והרשאות הגישה נשארים כשהיו.
כבר יש לנו מחולל פרוס — האם נצטרך לזרוק אותו?
לא. אנו עוטפים את מקור האנטרופיה הקיים בשכבה ניתנת לאימות: הוא ממשיך להפיק מספרים, אך כל ערך נרשם בהתחייבות לפני הסיבוב ונחשף לאחריו. לא המחולל משתנה, אלא שיטת האימות של ההגינות.
האם המשחק יעמוד בעומס נוסף?
האימות הועבר ממחזור המשחק לשירות נפרד, ההתחייבויות מחושבות בחבילות ומראש. הסיבוב אינו ממתין לאישור — השחקן מקבל את התוצאה מיד, והאימות מתבצע במקביל.
כיצד השחקן ישתכנע שהתוצאה הוגנת?
הוא רואה את ההתחייבות לפני הסיבוב ואת החשיפה לאחריו: על ידי הצבת שני הערכים בנוסחה פתוחה, כל אחד יכול לחשב מחדש את התוצאה ולהשתכנע שהשרת לא החליף את המספר. האימות אינו דורש אמון בנו.
מה עם הארנקים והלקוחות הנוכחיים?
התאימות נשמרת: הכתובות, פורמטי החתימה והרשאות הגישה אינם משתנים. הגירת הסכימה מתבצעת במקביל — סיבובים ישנים וחדשים נכתבים בו-זמנית, ונסיגה אפשרית בכל שלב.
נדון במשימה שלכם בפיתוח משחק Tower בלוקצ'יין
כדי שהשיחה תהיה עניינית ולא "ספרו בשתי מילים", נדרש מינימום בקלט: תיאור המכניקה של Tower (מה בדיוק הרנדום קובע — דרופ, קריט, סדר המגדלים, חלוקת הפרסים), השרשרת ותקן הטוקן, דרישות לאימות התוצאה, וכן מצב ההפעלה — השקה ציבורית או גישה סגורה. אם יש קוד חוזים קיים, סכמות או טיוטת חוקים — שלחו, נבחן כפי שזה.
לאחר מכן אנחנו חוזרים עם הערכה ותוכנית: מפרקים את המשימה לחוזים, אורקל אקראיות, אינטגרציה עם הפרונטאנד ומתאר בדיקות, מראים היכן אנחנו רואים סיכונים (מניפולציה של הרנדום, גז בפעולות המוניות, rollback בעת כשל של האורקל), ומציעים סדר עבודה. הערכה — זה טווח לפי שלבים עם הנחות מפורשות, ולא ספרה אחת "מפתח ביד".
מה הלקוח שולח
- תיאור המכניקה של Tower: כיצד הרנדום משפיע על התוצאה, היכן השחקן מאמת אותו.
- השרשרת היעד, תקן הטוקן ודרישות תאימות לארנקים.
- דרישות להגינות: האם נדרש אימות ציבורי של התוצאה ואחסון הוכחות.
- חומרים קיימים: חוזים, סכמות, חוקים, עבודות קודמות על הממשק.
- מגבלות: לוחות זמנים, עומס, מצב ההשקה, מי אחראי על הביקורת.
מה אנחנו מחזירים ומה מתחיל לאחר אישור
- הערכה לפי שלבים עם הנחות וגבולות עבודה.
- תוכנית: חוזים, אורקל אקראיות, אינטגרציה, מתאר בדיקות, סדר ההשקה.
- סכמת אימות הגינות: כיצד השחקן ישתכנע שהתוצאה לא מסולפת.
- רשימת סיכונים ופתרונות לכל אחד — לפני ההתחלה, ולא תוך כדי.
לאחר אישור מתחילות העבודות: מקבעים חוקים וממשקים, מרימים מתאר בדיקות, בונים חוזים ואורקל, מריצים תרחישי כשל ורק לאחר מכן מוציאים לרשת הראשית. הצעדים הבאים — שיחת זום קצרה על המכניקה ועל החומרים שלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.