פיתוח משחק HiLo על הבלוקצ'יין: היכן נשברת ההגינות
HiLo נשען על הימור אחד: השחקן מנחש אם הקלף הבא יהיה גבוה יותר או נמוך יותר. כל עוד התוצאה מחושבת על ידי מחולל בצד המפעיל, הגינות ניתנת לאימות של הסיבוב אינה ניתנת להשגה — הסוד מונח במסד הנתונים, ומבחוץ אי אפשר להבחין בין תוצאה הוגנת לתוצאה שחושבה מחדש בדיעבד.
מכאן גם הסיבובים השנויים במחלוקת. שחקן ברצף ארוך מבקש אישור, המפעיל מציג לוג שאי אפשר לאמת באופן בלתי תלוי, והתמיכה לא יכולה להוכיח לא החלפת תוצאה ולא את היעדרה. ככל שהרצף גדול יותר, הרעש סביב המחלוקת גובר ויקר יותר לפתור אותו.
Commit-reveal סוגר זאת ברמת החוזה: לפני ההימור מפורסם ההאש של הסוד של השרת, אחרי הסיבוב הסוד נחשף, והתוצאה של HiLo מחושבת מחדש מהסוד, מההימור של השחקן ומהמספר שלו עצמו. המחלוקת הופכת לאריתמטיקה שהשחקן מאמת באופן מקומי, בלי להיכנס לתשתית שלנו.
פיתוח משחק HiLo על הבלוקצ'יין הוא בראש ובראשונה תכנון של סכימה כזו: החוזה שומר על התחייבות, מנהל חישובים ומתעד את היסטוריית הסיבובים כך שאי אפשר לכתוב אותה מחדש בדיעבד. היכן שדרוש מקור אקראיות בלתי תלוי, אנחנו מחברים Chainlink VRF, והתוצאה מפסיקה להיות תלויה אפילו בסוד של המפעיל.
להלן — כיצד זה נבנה שלב אחר שלב: מסכימת ההתחייבות ועד לאימות ההימור על ידי השחקן עצמו.
מה נותנת אקראיות ניתנת לאימות: מהירות ואמון השחקנים
אקראיות ניתנת לאימות מסירה את סיבת המחלוקת עצמה. סכימת commit-reveal מתעדת את ההאש של הסוד של השרת לפני קבלת ההימורים וחושפת אותו אחרי הסיבוב, והתוצאה נבנית מהסוד הזה ומהגרעין של השחקן — ניתן לחשב אותה מחדש באופן מקומי. כללי החישוב מונחים בחוזה פתוח על Ethereum, כך שהאימות אינו דורש אמון בממשק.
סיבובים שנויים במחלוקת מפסיקים להגיע לתמיכה
בעבר פנייה טיפוסית נשמעה כמו "הסבירו למה יצא משהו אחר": הבירור דרש להעלות לוגים, לשחזר את רצף הסיבוב ולהשיב במכתב. כעת השחקן עצמו רואה שההאש תאם, וסוגר את הנושא במקום — שיעור הסיבובים השנויים במחלוקת יורד למקרים בודדים.
מה זה נותן במונחים מדידים
- מהירות החישובים גלויה לשחקן: התוצאה נבנית מהסוד הנחשף מיד לאחר הסיבוב, והבירור של פנייה מתקצר משעות לדקות.
- העומס על התמיכה עובר מתוצאות לכללי המשחק — אותם סוגרת עזרה עצמית בלי מעורבות אנושית.
- אימות אוטומטי מוטמע בממשק: כפתור מחזיר את ההאש, הגרעין והתוצאה, וההשוואה מתבצעת בלי הצד שלנו.
- הזמן לבירור מקרה בודד הופך לצפוי: שני הצדדים מסתכלים על אותו חישוב ניתן לשחזור.
שקיפות הסיבובים פועלת כטיעון שימור: שחקן שבדק פעם אחת את התוצאה חוזר למשחק, ולא להתכתבות עם התמיכה.
אפשרויות הגרלה ב-HiLo: commit-reveal וחלופות
ההגרלה ב-HiLo קובעת אם ניתן להוכיח את הגינות החלוקה לאחר שההימור כבר בוצע — ובמה זה עולה מבחינת השהיה ועומס. הסיבובים קצרים וזורמים ברצף, ולכן סכימה שנבדקת בקליק אחד ושאינה שוברת את קצב המשחק מנצחת סכימה שהיא חסרת דופי פורמלית אך איטית.
הבחירה תלויה במי הוא מקור האקראיות ובאיזו תדירות הסיבוב נרשם ברשת. להלן — ארבע חלופות עובדות ומגבלותיהן.
| אפשרות | מתי מתאימה | מגבלות הסכימה |
|---|---|---|
| Commit-reveal | השרת חייב לתעד את התוצאה לפני ההימור של השחקן | קומיט שלא נחשף — החזרת ההימור חובה; האישור חייב להיות ממש לפני ההימור, אחרת הסכימה מאבדת מערכה |
| מחולל מספרים אקראיים חיצוני | דרוש מקור בלתי תלוי ואימות מהיר של הסיבוב | תלות בזמינות הספק: בעת תקלה הסיבוב נעצר, והאימות דורש אמון במפעיל |
| סכימה מרובת-סיבובים עם שורש משותף | סדרות סיבובים שבהן נבדק שורש אחד לכל הסשן | נפח ההוכחות וזמן האימות גדלים; שגיאה בתחילת השרשרת מבטלת את ערכם של כל הסיבובים |
| הגרלה היברידית | הימורים גבוהים ודרישה לביקורת חיצונית | מורכב יותר למימוש ולתמיכה; יש לתאר במפורש את ההתנהגות בעת אי-התאמה בין המקורות |
המגבלה המשותפת לכל סכימה אינה במתמטיקה, אלא בחשיפה: מבקר חיצוני צריך לשחזר את התוצאה מנתונים פומביים, בלי גישה למאגר שלנו. לכן לרשת עוברות רק התחייבויות, ואת הסיבובים עצמם ואת היסטוריית ההימורים אנחנו מחזיקים מחוצה לה — זה מפחית את העומס ומאפשר חזרה לאחור בלי לכתוב מחדש את המצב.
כיצד אנחנו מנהלים את ההטמעה: מביקורת המכניקה ועד מסירת הקוד
הטמעת HiLo אינה "לכתוב חוזה", אלא לבנות שרשרת מהמתמטיקה של הסיבוב ועד מסירת הקוד לתחזוקה. השלבים מתבצעים ברצף: הבא מתחיל רק לאחר אישור הקודם במתאר הבדיקות, ולכן שגיאה בחלוקת התשלומים נשארת בארגז החול ואינה עוברת לרשת.
- ביקורת המכניקה. מפרקים את כללי הסיבוב: הטווח, צעד ההימור, תנאי הזכייה, רגע חשיפת הסוד. מתעדים את רשימת התוצאות ואת אלו מהן שהשחקן מאמת בעצמו — בלי אמון במפעיל.
- סכימת החוזים. מפרידים בין התפקידים: חוזה הסיבוב, מאגר ההתחייבויות (האש הסוד לפני קבלת ההימור), קופת התשלומים ומרשם ההיסטוריה. ההפרדה נדרשת כדי שעצירה של צומת אחד לא תחסום חישובים עבור סיבובים שהסתיימו.
- מטריצת התשלומים. מרכזים בטבלה את כל הצירופים הימור / תוצאה / מקדם ובודקים אותם מול הכללים. כאן נתפסות פרצות שנותנות לשחקן תוחלת חיובית או שמאפשרות למשוך יותר ממה שהופקד.
- הרכבה והגדרה. כותבים את החוזים, מגבילים את תדירות הסיבובים, קובעים מגבלות הימור ונוהל עצירה חירום. את הגישות לפונקציות הניהול מחלקים לפי תפקידים, כדי שמפתח אחד לא יוכל גם לשנות את הכללים וגם למשוך כספים.
- בדיקה במתאר הבדיקות. מריצים הימורים, ביטולים, חשיפה חוזרת וניסיונות להחליף את הסוד באמצע הסיבוב. בנפרד בודקים הימור אפס והימור מקסימלי.
- מסירת הקוד. מוסרים את הריפוזיטורי, את סכימת החוזים, את מטריצת התשלומים, את סקריפטי הפריסה ואת הערות התפעול. מקיימים סקירה עם הצוות שלכם — בהמשך ניתן לתחזק בכוחות עצמכם.
מה נשאר אצלכם: קונפיגורציות, סכימות, נהלים
אנחנו מוסרים לא משחק מוכן, אלא ערכה שלפיה אפשר להפעיל ולפתח אותו בלעדינו. הכול נמצא בריפוזיטורי ובתיעוד הפרויקט: הסכימות מתעדכנות יחד עם הקוד, ולא חיים בהתכתבות.
- סכימת החוזים — הקשרים בין חוזה המשחק, מאגר הקומיטים וחוזה התשלומים: סדר הקריאות, נקודות בדיקת החתימות, הרכב האירועים בלוג.
- מטריצת התשלומים — מקדמי HiLo לכל צעד וסף הסתברות יחד עם נוסחת החישוב: רואים מאין מגיע המספר וכיצד נלקחה בחשבון העמלה.
- נוהל החשיפה — סדר ה-commit-reveal: מתי נרשם ההאש, באיזה רגע נחשף הגרעין, כיצד מטופלת פקיעת המועד ומה נחשב לסימן להחלפה.
- יומן הבדיקות — היסטוריית הסיבובים עם האש הקומיט, הגרעין הנחשף וקישור לטרנזקציה: מחלוקת של שחקן נסגרת תוך דקות.
- תיעוד החוזים — תיאור המתודות, האירועים ותפקידי הגישה, הוראות פריסה ועדכון בטוח של הלוגיקה.
- הוראות לתמיכה — פניות טיפוסיות: טרנזקציה תקועה, אי-התאמה בתוצאה, חשיפה תקועה — והפעולה של הנציג בכל מקרה.
משלימים במטריצת תפקידים: מי משנה את המקדמים, מי עוצר את המשחק, מי מושך כספים. ערכה כזו מסירה את התלות במהנדס מסוים — המבקר והמפתח החדש מקבלים אותן תשובות לשאלה כיצד זה עובד.
מקרה בוחן: כיצד צמצמו את שיעור התוצאות השנויות במחלוקת לאפס
מה היה לפני
הלקוח הגיע עם משחק HiLo פעיל, שבו תוצאת הסיבוב נחתמה בהאש של השרת כבר אחרי ההימור. השחקן לא יכול היה לשחזר את הרצף מראש, ולכן רצף הפסדים הפך במהרה לפנייה לתמיכה בדרישה "הראו שהחישוב הוגן".
שיעור הסיבובים השנויים במחלוקת עמד על כ-3–4% מהנפח היומי, וטיפול במקרה בודד ארך עד 40 דקות עבודה ידנית: להעלות לוג, להשוות את הגרעין של הסיבוב, לחשב מחדש את התשלום ולהסביר למשתמש את המכניקה.
מה שינו ומה קיבלנו
העברנו את החישוב לסכימת commit-reveal: ההאש של הגרעין האקראי מפורסם בחוזה לפני קבלת ההימור, והגרעין עצמו נחשף לאחר סגירת הסיבוב. השחקן מחשב מחדש את התוצאה באופן מקומי ואינו תלוי במילה שלנו. את החשיפה קישרנו למצב ברשת, כדי שהחלק הצד-שרתי לא יוכל להתאים בדיעבד תוצאה נוחה.
את החוזים החכמים כתבנו ב-Solidity, ואת הלוגיקה של HiLo חילקנו לתיעוד ההאש ולתשלום לפי כללי המכפילים.
מדדים לאחר חודשיים של תצפית: סיבובים שנויים במחלוקת עם אי-התאמה מתועדת — אפס. זמן האימות עבור השחקן התקצר ל-10–15 שניות — סקריפט בדפדפן משווה את הגרעין הנחשף להאש שפורסם. הפניות לתמיכה בנוגע לתוצאות ירדו בכ-70%, והשעות שהתפנו למהנדסים עברו למשימות מוצר במקום להתכתבויות.
האפקט המרכזי — יכולת האימות הפכה לתכונה של המערכת, ולא לשירות של התמיכה. כל סיבוב מותיר עקבות פומביות שאפשר לבדוק מחדש בלי מעורבות שלנו — ולכן כבר אין מה לברר.
במה שונה commit-reveal ממחולל מספרים רגיל?
מחולל מספרים אקראיים רגיל יוצר את התוצאה בצד השרת, והשחקן רואה מספר מוכן. לבדוק מבחוץ אם הוא הותאם להימור אי אפשר: בהיסטוריה נשארת רק התוצאה, ולא התחייבות שניתנה לפני המהלך. בדיוק משום כך במחלוקת אין למפעיל מה להציג — ההוכחה מסתכמת ב"תאמינו, המחולל שלנו הוגן".
Commit-reveal משנה את סדר הפעולות. השרת, לפני קבלת ההימורים, מפרסם את ההאש של ערך סודי — קומיט, הנרשם בחוזה או ביומן סיבובים פומבי. החשיפה (reveal) מתרחשת אחרי המהלך: את הסוד מפרסמים, וכל מי שרוצה משווה את ההאש — התאמה מוכיחה שהמספר נרשם מראש ולא הותאם לתוצאת החלוקה.
הצפויות אינה עולה בעקבות זאת: הקומיט הוא טביעת אצבע חד-כיוונית, ואי אפשר לשחזר ממנה את הסוד. את התוצאה מרכיבים מכמה תרומות — הסוד של המפעיל, הגרעין של השחקן, מונה הסיבובים — ומחשבים אותה מחדש באותו אלגוריתם כמו בחוזה.
כך היכולת להוכיח הופכת לניתנת לשחזור: כל חלוקה ב-HiLo שומרת את נתוני הקלט ואת ההאש SHA-256, ולכן התוצאה נבדקת ללא תלות באתר ובכל עת.
נשאר תרחיש כשל אחד — המפעיל אינו חושף את הסוד; אותו סוגרים בכלל בחוזה: במקרה של אי-חשיפה התוצאה נחשבת לטובת השחקן, וסיבובים שלא נסגרו חוסמים תשלומים.
ספקות נפוצים: ביקורת, עומס, הרחבות
פיתוח משחק HiLo על הבלוקצ'יין כמעט תמיד נתקל בשלוש שאלות: האם החוזה יעמוד בעומס, האם אפשר לשנות את הלוגיקה לאחר ההשקה, ומה יקרה אם סיבוב לא ייסגר. להלן — כיצד זה בנוי אצלנו, עם ציון המצבים שנכללים בקוד מראש.
את הלוגיקה של הסיבוב אנחנו מחזיקים קצרה: בדיקת ההימור, חשיפת הקומיט והתשלום. היסטוריית המשחקים, טבלאות המובילים והאנליטיקה מחושבים מחוץ לשרשרת, ולכן עלות ההימור אינה עולה עם מספר השחקנים.
את הפרמטרים המשתנים — מגבלות, רמות סיכון, השהיה — מוציאים לשכבה מתחלפת, והליבה לפני ההשקה עוברת ביקורת חוזים בלתי תלויה.
האם החוזה יעמוד בעומס במספר רב של שחקנים?
צוואר הבקבוק אינו המשחק עצמו, אלא נפח החישובים בחוזה. שם נשארים רק אימות התוצאה והתשלום, והחשיפות מקובצות: כמה סיבובים יוצאים בטרנזקציה אחת. את פרופיל העומס לוקחים עם מרווח של פי כמה מהשיא הצפוי.
האם אפשר להרחיב משחק שכבר הושק?
כן, אם הארכיטקטורה מחולקת לליבה בלתי ניתנת לשינוי עם כללי החשיפה ולשכבה מתחלפת של פרמטרים. אז מוסיפים מצבי הימור חדשים וממשק בלי הפעלה מחדש ובלי העברת יתרות של שחקנים. אם הליבה עצמה משתנה, מפיקים חוזה חדש, מעבירים את המצב לפי תמונת מצב, ואת הישן משאירים זמין רק למשיכת כספים.
מה יקרה אם שחקן לא יחשוף את הקומיט או שהטרנזקציה תיתקע?
לסיבוב יש חלון חשיפה. אם השחקן פספס אותו או שלח נתונים שגויים, החוזה סוגר את הסיבוב בעצמו ומחזיר את ההימור לפי כלל קבוע — אין צורך בבירור ידני. בעת עומס ברשת חל אותו כלל: הטרנזקציה או מאושרת בתוך החלון או מבוטלת, והמצב נשאר עקבי.
נדון במשימה: אילו נתונים נדרשים להערכה מדויקת
כדי שההערכה תישען על עובדות ולא על השערות, נדרש מינימום של נתוני מקור על המשחק ועל המתאר שבו הוא יפעל. ככל שהנתונים המדויקים יותר, כך יש פחות הנחות בתוכנית העבודה וסדר השלבים אמין יותר — מאב הטיפוס של החוזה ועד ההשקה.
- כללי הסיבוב — טווח המכפילים, צעדי ההימור, רגע חשיפת התוצאה ותנאי עצירת הסדרה;
- נוסחת התשלומים והמרווח לעמלת הרשת שאנחנו מכלילים במקדם;
- סכימת ההגינות: היכן נוצר הערך הצד-שרתי, כיצד מחושב ההאש שלו ומה מפורסם לפני תחילת הסיבוב;
- רשת היעד ומגבלותיה — עלות הטרנזקציה, מהירות האישור, מקור האקראיות הזמין;
- תפקידים והרשאות: מי הבעלים של החוזה, כיצד בנויים הניהול והעצירה החירום;
- לקוח: ווב או מובייל, ארנק משמורן או בלתי משמורן, האם נדרשות כמה רשתות;
- עומס צפוי — כמה סיבובים בדקה וכמה שחקנים בו-זמנית, כדי לכלול מרווח בתפוקה;
- מה כבר קיים: אב טיפוס, ביקורת, חוזים מוכנים או רק תיאור של הרעיון.
תארו את המשימה בצורה חופשית — נחזור עם הערכה, תוכנית עבודה וסדר שלבים. ייתכן שחלק מהרשימה אינו קיים: זה לא חסם, חלק מהנתונים נבהיר בשיחה ונקבע במסמך הדרישות הטכניות.