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

מדוע יצירת משחק בלוקצ'יין נתקלת ביצירת אקראיות

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

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

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

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

השחקן רואה את ה-hash של הבקשה לפני ההימור ואת המספר עצמו לאחריו, ואין אפשרות להחליף את התוצאה בדיעבד — היא כבר נרשמה בשרשרת.

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

מה משתנה לאחר העברת לוגיקת הסיבובים לחוזה חכם

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

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

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

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

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

השוואת גישות: בלוקצ'יין, סכימה היברידית, שרת

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

מה ניקח לעבודה

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

שלבי ההטמעה: מביקורת המכניקה ועד מסירת המערכת

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

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

מה נשאר בצוות הלקוח לאחר מסירת הפרויקט

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

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

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

מקרה בוחן: סיבוב עם אקראיות ניתנת לאימות ותשלומים בשרשרת

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

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

מה נבנה מחדש

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

מה השיגו

• שיעור הסיבובים השנויים במחלוקת: 2.4% → 0.01%. כל נקודת קריסה מאושרת برשומה פומבית, ואין מה לברר.
• זמן חישוב התשלום: שעות של השוואה ידנית → שניות, התשלום יוצא באותה טרנזקציה שסוגרת את הסיבוב.
• פעולות תמיכה ידניות: 30-40 בירורים בשבוע → פניות בודדות, היקף העבודה הצטמצם בסדר גודל.

אותה מערכת מועברת לכל מכניקה שבה התשלום תלוי בתוצאה אקראית.

במה שונה חוזה הסיבוב ממחולל מספרים אקראיים בשרת

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

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

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

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

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

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

עמלות הרשת אוכלות את התשלומים?

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

מי אחראי על מפתחות חתימת התשלומים?

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

מה יקרה בעת כשל של צומת?

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

האם ביקורת חוזה חכם היא חובה?

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

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

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

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

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