Provably Fair: מה זה, איך בודקים סיבוב, ומה זה לא מבטיח

במשחקי קראש ובמשחקים מהירים רבים מופיע הכיתוב Provably Fair ("הוגן באופן מוכח"). יש לידו אייקון של מגן, היסטוריה של סיבובים ומחרוזות ארוכות של אותיות ומספרים. ברשת אפשר גם למצוא "Provably Fair Predictor", כלים שמבטיחים לחזות את הסיבוב הבא בעזרת אותן מחרוזות.

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

הרעיון בשפה פשוטה: מעטפה סגורה

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

זה העיקרון שנקרא commit-reveal (התחייבות וחשיפה):

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

במקום מעטפה, משתמשים בפונקציית hash.

מה זה hash

פונקציית hash לוקחת כל קלט (מילה, משפט, קובץ) ומחזירה מחרוזת באורך קבוע. NIST, המכון האמריקאי לתקנים, מגדיר בתקן FIPS 180-4 את משפחת SHA, ומסביר שטביעות האצבע האלה משמשות "כדי לזהות אם הודעה שונתה מאז שנוצרה טביעת האצבע".

שלוש תכונות חשובות:

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

– SHA-256 של `abc` מתחיל ב-`ba7816bf8f01cfea…` – SHA-256 של `abd` מתחיל ב-`a52d159f262b2c6d…`

אות אחת שונה, ו-hash שאין לו שום קשר לקודם.

• אי אפשר ללכת אחורה. מה-hash אי אפשר לשחזר את הקלט, ולכן ה"מעטפה" נשארת סגורה עד שהמפעיל חושף את הסיד.

SHA-256 ו-SHA-512 הם שני חברים באותה משפחה. ההבדל העיקרי הוא אורך הפלט (256 ביט מול 512 ביט). לצורך ההבנה של Provably Fair, שניהם עושים את אותה עבודה.

Server seed, client seed ו-nonce

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

איך זה עובד אצל Spribe (Aviator ומשחקים נוספים)

לפי דף ה-Provably Fair של Spribe:

1. המפעיל יוצר server seed של 16 תווים אקראיים.
2. גרסה מוצפנת (hash) של הסיד מוצגת לפני שהסיבוב מתחיל.
3. client seed נוצר בצד של כל שחקן, ולפי Spribe אפשר לשנות אותו בהגדרות ה-Provably Fair.
4. ה-server seed וה-client seeds משולבים ועוברים SHA-512.
5. התוצאה נגזרת מה-hash הזה.
6. את ה-server seed של הסיבוב הבא אפשר לראות כ-SHA-256 בהגדרות ה-Provably Fair.

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

מדריך: לבדוק סיבוב מההיסטוריה

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

1. פתחו את היסטוריית הסיבובים (בדרך כלל אייקון של שעון או היסטוריה).
2. בחרו סיבוב ופתחו את חלון ה-Provably Fair שלו. יופיעו בו ה-server seed (שכבר נחשף), ה-client seeds, ה-hash המשולב והתוצאה.
3. בדקו את ההתחייבות: חשבו בעצמכם SHA-256 של ה-server seed שנחשף, למשל בכלי מקומי, והשוו ל-hash שהוצג לפני הסיבוב. אם הם זהים, הסיד לא הוחלף.
4. בדקו את השילוב: חשבו SHA-512 של הצירוף כפי שהמשחק מתאר אותו, והשוו ל-hash המשולב.
5. התוצאה: את המעבר מה-hash לתוצאה עצמה אפשר לבדוק רק אם הספק מפרסם את הנוסחה. אם הוא לא מפרסם, הבדיקה שלכם מוכיחה ששרשרת ה-hash עקבית, אבל לא את החישוב האחרון.

מה Provably Fair כן מוכיח

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

מה Provably Fair לא מוכיח

זה החלק שרוב ההסברים מדלגים עליו:

Provably Fair מול RNG מאושר מעבדה

רוב משחקי הקזינו אונליין (סלוטים, רולטה ובלאק ג'ק RNG) לא משתמשים ב-Provably Fair, אלא ב-RNG שנבדק על ידי מעבדות בדיקה ומפוקח על ידי רגולטורים.

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

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

למה "Provably Fair Predictor" הוא סתירה

אם היה אפשר לחזות את התוצאה מה-hash שמוצג לפני הסיבוב, המנגנון כולו היה חסר ערך, כי המפעיל לא היה יכול "להתחייב" לשום דבר בלי לחשוף אותו. כל הרעיון הוא שה-hash לא מגלה את הסיד. וגם מי שיודע את ה-server seed לא יודע מראש את ה-client seeds שיצטרפו.

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

שאלות נפוצות

קריאה נוספת

• יתרון הבית
• משחקי קראש