למה פיתוח קזינו בלוקצ'יין נכשל כבר בסיבוב הראשון
הסבב הראשון כמעט תמיד נשבר באותה נקודה. מחולל המספרים האקראיים והחלוקה עצמה חיים בשרת של המפעיל: התוצאה מחושבת במערכת סגורה, הזרע ההתחלתי נשאר אצל המנהל, והשחקן רואה רק את התוצאה. כל עוד הזכיות קטנות, הסכימה לא מטרידה אף אחד.
ברגע שהזכייה גדולה, מתחיל ויכוח על זיוף התוצאה. המפעיל לא יכול להוכיח שלא שכתב את הרצף, והשחקן — שההימור היה בדיוק כזה. לוגים כאן אינם ראיה: אותם כותבת אותה צד שמעוניינת בתוצאה. מכאן — עיכובים בתשלומים, בירורים, האשמות פומביות, וכל מקרה כזה פוגע באמון חזק יותר מהקודם.
הוגנות ניתנת להוכחה של חלוקות בנויה אחרת. לפני קבלת ההימור מפורסם גיבוב של הזרע הסגור, אחרי הסבב נחשף הזרע עצמו — וכל מי שרוצה מחשב מחדש את התוצאה אצלו בדפדפן.
חוזה חכם מתעד את ההימור, גובה התשלום ואת גבולות הסטייה המותרת, ולכן השקיפות של מכניקת המשחק מפסיקה להיות הבטחה: היא ניתנת לאימות מתמטי, ולא במילים.
עם זאת, לחבר חוזה למחולל הקודם זה לא מספיק — נפרט איך זה נסגר שלב אחר שלב: היכן נשמר הזרע, איך סבבים מתחברים לשרשרת ומה בדיוק השחקן יכול לבדוק.
מה נותנת הוגנות ניתנת להוכחה של חלוקות ותשלומים
הוגנות ניתנת להוכחה היא לא סיסמה, אלא אוסף של טענות ניתנות לבדיקה. אנחנו מתעדים אותן לפני תחילת הפיתוח ואחרי ההשקה מודדים לפי לוגים: כמה סבבים השחקן יכול לבדוק מחדש בעצמו, כמה פניות עוברות לבדיקה ידנית וכמה פעולות נבדקות בלי מעורבות אדם.
- תוצאה ניתנת לבדיקה של הסבב. הסכימה Provably Fair עובדת כך: זרע השרת עובר גיבוב ומפורסם לפני החלוקה, ונחשף אחריה. השחקן משחזר את התוצאה בסקריפט חיצוני ורואה שלא היה זיוף.
- צמצום פניות במחלוקת. המחלוקת עוברת מ"לא היה לי מזל" לפער קונקרטי, ולרוב נסגרת מעצמה: הבדיקה זמינה בממשק, ולא לפי בקשה לתמיכה.
- זמן טיפול בתלונה. במקום התכתבות וייצוא נתונים — מאמת באזור האישי: שני הצדדים מסתכלים על אותם נתונים, והבירור אורך דקות, לא ימים.
- אוטומציה של התאמות. יתרות, התחייבויות והיסטוריית סבבים מותאמות לפי לוח זמנים, ופערים צפים לפני המשיכה, לא אחרי תלונה.
- עמידות התשלומים. קווי פעולה נפרדים — חם וקר, מגבלות ותור עם ניסיונות חוזרים — נותנים סוג כשל צפוי: עיכוב במקום אובדן בקשה.
- מוכנות לביקורת חיצונית. לוגים, נוהל חשיפת הזרע ותיאור הסכימה מועברים לגורם הבודק כפי שהם.
מצבי יצירת אקראיות: חוזה מול שירות הקזינו
מצב יצירת האקראיות קובע מי יוצר את תוצאת הסבב ומה השחקן יכול לבדוק בעצמו, בלי לפנות לתמיכה. הקצוות הם חישוב בחוזה חכם ופנייה לשירות חיצוני; בין לבין פועלות סכימות משולבות עם פרסום הגיבוב לפני ההימור. מהבחירה תלויים האמון של השחקנים, השהיית התגובה ועלות רישום התוצאה.
מגבלות המצב מתגלות תחת עומס: החוזה נתקע בעלות ובזמן אישור, והשירות החיצוני — באמון במפעיל שלו. בדיקת התוצאה על ידי השחקן צריכה להיות ניתנת לשחזור: אותם נתוני קלט נותנים אותה תוצאה, והתוצאה עצמה נרשמת לפני חשיפת ההימורים.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| יצירה בחוזה חכם | נדרשת שקיפות מקסימלית, סבבים נדירים | עלות הרישום וזמן האישור עולים עם הנפח; מכניקות משחק מורכבות לא נוחות לחישוב ברשת |
| שירות אקראיות חיצוני | מהירות וסבבים המוניים, נפח הימורים גדול | אמון בספק השירות; נדרשת בדיקת חתימה ורזרבה לאי-זמינות המקור |
| סכימה משולבת: זרע שרתי פלוס זרע לקוח | צריך גם מהר וגם ניתן לבדיקה על ידי השחקן | הגיבוב מפורסם לפני ההימור, הבדיקה נעשית דרך כלי עזר; דרישות גבוהות יותר לתיעוד |
| שירות קזינו סגור | סבבים מיידיים, ביקורת לא מוצהרת | השחקן לא יאמת הוגנות, ביקורת אפשרית רק לפי לוגים של המפעיל |
בחירת סכימת היצירה נעשית בשלב התכנון: החלפת מצב אחרי ההשקה דורשת בנייה מחדש של לוגיקת הסבבים והגירת היסטוריה. אנחנו מחשבים פרופיל עומס ודרישות בדיקה, ואחר כך מציעים מצב ומתארים מה בדיוק השחקן יאמת בעצמו.
הטמעה שלב אחר שלב: מביקורת הכלכלה ועד העברת הרשאות
פיתוח קזינו בלוקצ'יין מתחיל לא בקוד, אלא בפירוק המכניקה: איך נוצר ההימור, היכן נרשם הגיבוב שלו, באיזה רגע נחשף הזרע ומי בכלל יכול להתערב בתוצאת הסבב. כל עוד זה לא מתואר, כל מימוש של Provably Fair נשאר אוסף הבטחות. סדר השלבים שלהלן זהה לכל מערך משחקים — משתנה רק ההיקף.
- ביקורת מכניקת המשחק — מפרקים את החוקים של כל משחק, הסתברויות התוצאות, ההחזר המוצהר ומצבי קצה: הימור אפס, מגבלות, סבבים במקביל.
- סכימת זרימות הימורים — מתעדים את המסלול מהלקוח עד החישוב: היכן נשמר הגיבוב, היכן נחשף הזרע, איך מטופלים ניתוק, כפילויות ובקשות מאחרות.
- הגדרת צומת האקראיות — יצירה וחשיפה של ערכים, קישור למזהה הסבב, רישום בלתי משתנה של התוצאה לפני התשלום.
- בדיקת ההוכחות — בונים אלגוריתם ציבורי שלפיו השחקן מאמת את התוצאה בעצמו, בלי לפנות למערכות פנימיות.
- בדיקות עומס וקצה — הימורים במקביל, סשנים בשיא, התנהגות המערכת כשקיים פער בנתונים בין צמתים.
- בדיקות קבלה — הרצת תרחישים לכל משחק ולמקרי קצה, השוואת חישובים למודל ייחוס.
- העברת הרשאות — קונפיגורציות, נהלי עדכון, סדר תגובה לאירועים ודיון בהחלטות עם הצוות שלכם.
אחרי ההעברה נשארת תמיכה ותחזוקה: חוקי המשחקים ואלגוריתם הבדיקה עצמם לא משתנים, אבל כל עדכון עובר את אותו מחזור — מביקורת המכניקה ועד קבלה.
ערכת העברה: קונפיגורציות, סכימות ארנקים, נהלים
ערכת ההעברה היא לא ארכיון עם קוד, אלא אוסף ארטיפקטים שלפיהם הצוות שלכם מנהל את הפרויקט בלעדינו. כל מה שקובע את התנהגות המערכת נמצא לצד הקוד ומתעדכן יחד עם הגרסה.
- קונפיגורציה של צומת האקראיות: מקורות הזרע, רגע פרסום הגיבוב של השרת לפני הסבב וסדר החשיפה אחריו — עם קבצי הגדרות מלאים לסביבת בדיקה ולסביבת ייצור.
- מדיניות גישה ותפקידים: מטריצת «תפקיד — פעולה» למפעילים, לתמיכה, למנהלים ולמבקרים חיצוניים, כולל אישור שני לתשלומים.
- סכימת תנועת כספים: המסלול מהפקדה עד תשלום עם נקודות רישום במרשם, מקומות בדיקה והתנהגות המערכת כשסכומים לא תואמים.
- תיעוד טכני: תיאור החוזים והפרמטרים שלהם, מבנה האחסון, פורמטי היומנים, הוראות פריסה וחזרה לגרסה קודמת.
- נוהל אירועים: סוגי תקלות, זמן תגובה, מי עוצר תשלומים, סדר הודעה לשחקנים ובירור אחרי השחזור.
- בדיקות הוגנות לשחקן ולמבקר: איך מאמתים גיבוב וזרע של סבב, ובנוסף אותן בדיקות בסקריפטים בצד שלכם.
- רשימת קבלה והרשאות: רשימת מפתחות, התפקיד של כל אחד, סדר רוטציה ואישור שההרשאות שלנו סגורות.
הערכה מסירה את הסיכון המרכזי בפיתוח בקבלנות — תלות באנשים שכתבו את הקוד. מהנדס חדש נכנס לפרויקט לפי התיעוד, לא לפי התכתבות במסנג'ר, והאירוע נבחן לפי הנוהל.
מקרה בוחן: איך הסרנו סבבים שנויים במחלוקת וצמצמנו זמני השבתה פי שלושה
מפעיל הגיע עם בעיה חוזרת: כל סבב שנוי במחלוקת נבדק ידנית. הזרע השרתי לא פורסם מראש, השחקן לא יכול היה להוכיח את התוצאה, והתמיכה אספה היסטוריית הימורים מהיומנים, השוותה אותה ללוגים של המחולל והשיבה במכתב למחרת.
לזרימת הפניות האלה נצרכה כמעט כל קו התמיכה הראשון, ובזמן רוטציית זרע מתוכננת ההיסטוריה איבדה רציפות — השחזור ארך שעות.
מה שינינו
החלטנו להתבסס על הוכחות ניתנות לבדיקה של הסבב. הגיבוב של זרע השרת מפורסם לפני הסבב, הזרע עצמו נחשף אחריו, אליו מקושרים זרע הלקוח ומונה הסבבים — התוצאה נבדקת בלי תלות בממשק, בסקריפט או ידנית. מקור האקראיות הועבר לאורקל חיצוני ניתן לאימות Chainlink VRF, ויומן הסבבים מועבר כייצוא בפורמט פתוח.
במקביל הותקנה התאמה אוטומטית: תור ההתאמה מחבר בעצמו בין זרעים שנחשפו להימורים ומסמן פערים, ולכן בירור ידני נשאר רק לחריגות, ולא לכל מחלוקת.
מה השתנה
- פניות בנושא הוגנות שמגיעות למהנדס: מ-100% ל-~10%, את השאר סוגרת עמוד בדיקה תוך שניות.
- בירור של סבב שנוי במחלוקת אחד: מ-40 דקות של התאמת לוגים ידנית לבדיקה אוטומטית.
- השבתה בזמן רוטציית זרע מתוכננת: הצטמצמה פי שלושה, סביבת המשחק לא נעצרת.
- עומס על קו התמיכה הראשון בנושא הוגנות: מינוס כ-85%.
הוגנות ניתנת להוכחה מול מחולל רגיל: מה ההבדל?
מחולל מספרים אקראיים רגיל חי בתוך השירות: התוצאה נוצרת בצד המפעיל, והשחקן רואה רק את התוצאה. אי אפשר לשחזר את מהלך ההגרלה בדיעבד — הזרע נשאר סגור, והיומנים נכתבים מחדש לפי הצורך. ההבדל עקרוני: מודל אחד מציע לסמוך, והשני — לבדוק.
בסכימה ניתנת לבדיקה הסבב מחולק לשני שלבים. לפני ההימור מפורסם הגיבוב של הזרע השרתי הסגור, והתוצאה מחושבת משלושה ערכים: זרע שרתי, זרע לקוח ומספר הסבב. אחרי החישוב הזרע השרתי נחשף — השחקן מציב אותו בנוסחה המפורסמת ומקבל את אותו גיבוב ואותה תוצאה. בדיקה בדיעבד נשענת על אריתמטיקה, לא על המוניטין של המפעיל.
שמירת ההוכחות היא קו נפרד. גיבובים וזרעים שנחשפו נאספים ליומן בלתי משתנה, שבו כל רשומה מקושרת לקודמתה: החלפה של אחת שוברת את השרשרת ונראית מיד. קישור לסבב מסוים נשאר פעיל גם אחרי חודשים, והתוצאה משוחזרת בלי גישה למערכות פנימיות.
ביקורת תוצאות היא לא רק בדיקה מדגמית. המפעיל מציג סטטיסטיקה ציבורית: שיעור הסבבים עם חשיפה מאושרת, התפלגות התוצאות, מספר הרשומות השנויות במחלוקת. שחקנים שיש להם כלי בדיקה נוטים פחות ללכת לחפש שולחן "הוגן יותר", והמחלוקת נבחנת לפי רשומות, לא לפי התכתבות.
בפיתוח קזינו בלוקצ'יין ההבדל מצטמצם לשאלה אחת: האם צד שלישי יכול לשחזר את התוצאה בלי גישה לשרת. אם כן — האמון של השחקנים מפסיק להיות עניין של אמונה.
ספקות טכניים: ביקורת, עומס, אינטגרציות
ההתנגדויות ההנדסיות בפרויקטים כאלה הן בדרך כלל אותן התנגדויות: האם המערכת תעמוד בעומס שיא, האם היא תשתלב בסטאק שכבר עובד, איך המבקר ישתכנע בהוגנות החלוקה ומה יקרה להיסטוריית הסבבים כשמחליפים מקור אקראיות. להלן תשובות קצרות לכל סעיף.
מה יקרה לפלטפורמה בשיא הפעילות?
חלוקות ורישום הימורים מתנהלים בזרמים נפרדים מהחישובים: לרשת נכנסת רק קביעת תוצאת הסבב, אישורים נרשמים במנות ולא כפעולה בודדת. צומת קריאה מתרחבים אופקית, הכתיבה עוברת דרך תור, ולכן גידול של פי כמה במספר הסשנים במקביל לא משנה את זמן התגובה של ממשק השחקן.
האם זה תואם לסטאק הנוכחי?
חוזים חכמים חיים בנפרד מהמסד העיקרי וממערכת החיוב, הקשר — דרך ממשק תוכנה. אם אצלכם כבר עובד מודול תשלומים ואזור אישי, הם נשארים במקומם, והשכבה החדשה מתחברת כתרחיש נוסף. נקודות החיבור מתארות לפני תחילת העבודה, והמעבר נעשה בלי לעצור את השירות.
באיזה סדר נעשית בדיקת ההוגנות?
קודם מתעדים את סכימת היצירה ואת כללי חישוב התשלומים, אחר כך בודקים את החוזים באמצעות מבקר בלתי תלוי, ורק לאחר מכן פותחים גישה לשחקנים. לבדיקה עצמאית מפורסמים גיבובים של תוצאות כל סבב: השחקן יכול לחשב מחדש את התוצאה אצלו ולוודא שהיא לא השתנתה אחרי תחילת קבלת ההימורים. אחרי תיקונים הביקורת חוזרת.
אפשר להחליף מקור אקראיות בלי לאבד היסטוריה?
כן, אם הוא מוציא לממשק נפרד. סבבים מתקופות קודמות שומרים קישור לסכימה הקודמת, החדשים פועלים לפי אחרת, ושתיהן נשארות ניתנות לשחזור: אצל המבקר לא נוצר פער שבו אי אפשר לחשב רשומות ישנות לפי הכללים החדשים.
איך מתחברים תרחישי תשלום?
הפקדות ומשיכות עוברות דרך מחברים לשירותי תשלום, תשלומי קריפטו נחשבים מאושרים לפי מספר הבלוקים ברשת. הפעולות אידמפוטנטיות — בקשה חוזרת לא יוצרת זיכוי שני, ומקרים שנויים במחלוקת נבחנים לפי היומן.
נדון במשימה: נבנה סכימה ונחזור עם תוכנית
כדי לחזור עם הערכת היקף העבודה וסדר שלבים ברור, מספיקים לנו נתוני הפרויקט הראשוניים — אין צורך במפרט טכני מוכן. בדרך כלל די בדיון אחד במשימה: מדייקים פרטים ומתעדים היקף שסוגר את המטרה העסקית, בלי בלוקים מיותרים באיטרציה הראשונה.
- רשימת משחקים וכללי חישוב: אילו סבבים, איך מחושבת הזכייה, היכן משתתף מחולל המספרים האקראיים.
- סכימת אישור הוגנות: איך נוצרים הזרע השרתי והזרע של הלקוח, מה מפורסם לפני הסבב ומה נחשף אחריו.
- רשתות ונכסים: אילו רשתות וטוקנים אתם מקבלים, האם נדרשות יתרות פנימיות, איך בנויים הפקדה ומשיכה.
- לוגיקת חוזים חכמים: הימורים, תשלומים, ג'קפוט, תגמולי הפניה, החזקת כספים למשך הסבב.
- דרישות לבדיקות ולביקורת: תחום שיפוט, מה בדיוק צריכה לאשר ביקורת חיצונית, אילו דוחות נדרשים לרגולטור.
- פאנל ניהול ואינטגרציות: ניהול מגבלות, אנטי-פראוד, בדיקת לקוחות, חיבור לשירותי תשלום.
- עומס ולוחות זמנים: כמה שחקנים במקביל, כמה הימורים בשנייה צריך לעמוד בהם, לאיזה תאריך נדרש ההשקה.
אם על חלק מהסעיפים אין עדיין נתונים — בואו עם מה שיש: את החסרים נסגור בדיון במשימה ונשקף בתוכנית העבודה. אישור ההיקף נעשה לפי שלבים, ולכן אפשר להתחיל מליבת ההוגנות והתשלומים, ולהוסיף חלון ראווה, סטטיסטיקה ומשחקים נוספים בשלב הבא.