פיתוח סלוטים על בלוקצ'יין: היכן הכלכלה נשברת
כלכלת הסלוט נשברת לא על טבלת התשלומים, אלא על הגבול בין שרת המשחק לשרשרת. תוצאת הסיבוב מחושבת בחוץ, ההימור נגבה בפנים — ושני היומנים מתחילים לסטות: אצל השחקן על המסך קומבינציה אחת, אצל המפעיל במסד הנתונים אחרת.
כל עוד הסטייה נקודתית, סוגרים אותה ידנית; כשהיא חוזרת על עצמה בזרם, התשלומים הידניים הופכים לסעיף נפרד בהוצאות התפעול.
הסיבה בדרך כלל אחת — יצירת האקראיות נמצאת מחוץ לחוזה החכם של מכונת הסלוט. החוזה מקבל את ההימור, אך אינו יכול להוכיח שהקומבינציה שנפלה לא הותאמה לתוצאה ידועה מראש.
זה נסגר באמצעות מקור אקראיות ניתן לאימות: ההתחייבות לזרע המקורי נרשמת לפני ההימור, החשיפה מתרחשת לאחריו, וכל משתתף יכול לחשב את הסיבוב בעצמו. כאן מתאים Chainlink VRF כמקור שמחזיר ערך יחד עם הוכחת אימות על השרשרת.
סיבובים שנויים במחלוקת יקרים יותר מהתשלומים עצמם. כל פנייה היא התכתבות, ייצוא יומנים, בדיקה ידנית והחלטה 'לשלם או לסרב', שהתקבלה ללא קריטריון חד-משמעי.
אם תוצאת הסיבוב משוחזרת מנתוני השרשרת, המחלוקת עוברת ממישור המשא ומתן למישור האריתמטיקה: הצד либо מציג חישוב ניתן לאימות, либо לא.
צוואר בקבוק נפרד — יתרת הבונוס. זיכויים, תנאי מחזור ותוקף הבונוס נמצאים לעתים קרובות במערכת החשבונאית של המפעיל, ולא בחוזה. השחקן רואה מספר שאינו ניתן לאימות, והמפעיל אינו יכול להוכיח שהוא זוכה לפי הכללים.
העברת לוגיקת הבונוסים לחוזה הופכת את היתרה לניתנת לאימות, אך מחייבת לתאר ביושר מה קורה עם מה שכבר זוכה.
להלן נבחן את נקודות הכשל הללו אחת לאחת ונראה כיצד כל אחת נסגרת ברמת החוזה, סכימת הנתונים ותקנון התשלומים.
האפקט: הגינות הסיבובים, מהירות התשלומים, זמן השבתה
התוצאה המדידה הראשונה — הגינות הסיבובים. כל הגרלה נשענת על מקור אקראיות ניתן לאימות, ולכן השחקן יכול להשתכנע באופן עצמאי שהקומבינציה שנפלה לא הוחלפה בדיעבד. שיעור הסיבובים שעבורם אישור כזה זמין מובא לכיסוי מלא — זה מסיר את הטיעון המרכזי במחלוקות עם שחקנים ובבדיקות מצד הפלטפורמות.
השנייה — מהירות התשלומים. הזמן מהסיבוב ועד זיכוי הזכייה מתקצר מדקות של המתנה ואישורים ידניים לשניות: החוזה החכם יוזם את הזיכוי מיד עם סיום הסיבוב, ולא המפעיל לפי בקשה. השחקן רואה את היתרה כמעט באופן מיידי, ופניות מסוג 'איפה הזכייה שלי' פוחתות פי כמה.
השלישי — זמן השבתה של מכונת הסלוט והפחתת פעולות ידניות. בעבר סטיית יתרה או כשל בתשלום עצרו את המכונה עד להתערבות התורן; כעת השחזור מתבצע לפי תרחיש שנכתב מראש, ושיעור הפעולות הדורשות אדם יורד לחריגים נדירים — בדיקת מגבלות וטיפול בסיבובים שנויים במחלוקת.
הרביעי — מחלקה של כשלים שהוסרו. נעלמות משפחות שלמות: זיכוי כפול של סיבוב אחד, החלפת תוצאה לאחר הצגתה, הימור תקוע בעת ניתוק הקשר. אמון השחקנים נשען לא על הבטחות תמיכה, אלא על כך שכל תוצאה וכל תשלום ניתנים לאימות, והשבתות של המכונה אינן דורשות הסברים בהתכתבות.
סלוטים: חוזה אחיד או מפעל מכונות
הבחירה בין 'חוזה אחד למכונה' ל'מפעל חוזים' קובעת את מחיר עדכון לוגיקת המשחק. חוזה מבודד מתוקן נקודתית, אך הסדרה מתפרקת לאוסף כתובות המנוהלות בגרסאות בנפרד. המפעל פורס מכונה בקריאה אחת עם פרמטרי תצורה ושומר את הקוד המשותף במקום אחד.
האפשרות השלישית — חוזה אחיד, שבו המכונות נבדלות רק בתצורה: טבלאות תשלומים, משקולות סמלים, מגבלות הימור. לתחזק אותו קל יותר, אך תיקון הלוגיקה נוגע בכל הסדרה, והעומס הכולל על הרשת גדל עם כל קריאה.
שלוש סכימות להשקת סדרה
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חוזה אחד למכונה | סדרה קטנה עם מכניקה שונה מהותית | עדכון לוגיקה — מהדורה נפרדת לכל כתובת |
| מפעל חוזים | הסדרה גדלה: עשרות מכונות לפי תבנית אחת | קוד משותף — נקודת כשל, החלפת תבנית מחייבת העברת מכונות שכבר נוצרו |
| חוזה אחיד עם תצורה | מכונות נבדלות רק בפרמטרים | לוגיקה אחת לכולן, מצב משותף |
בפועל, את הסדרה מרכיבים באופן היברידי: המפעל יוצר מכונות, התצורה נשמרת מחוץ לקוד, ויצירת האקראיות מועברת למודול נפרד — החלפתה אינה מחייבת הנפקה מחדש של המכונות. את הסכימה בודקים בריצת עומס לפני מהדורה: בוחנים כיצד גדלים מספר הקריאות ועלות העבודה על התחזוקה כאשר הסדרה מוכפלת.
סדר העבודות: ממודל הכלכלה ועד להשקה
סלוט על בלוקצ'יין הוא קודם כל כלכלה הסתברותית התפורה לתוך קוד בלתי ניתן לשינוי: טעות בטבלת התשלומים אינה מתוקנת בתיקון, אלא גוררת את יתרת המאגר למטה בכל הסיבובים הבאים. לכן את הקוד כותבים אחרון — סדר העבודות בנוי כך שכל החלטה נשענת על נתון שכבר נבדק.
- ביקורת כלכלה. מנתחים את התפלגות התשלומים, תדירות הפעלת הבונוסים והחזקת המאגר לטווח ארוך. התוצר — מרווח יעד וטווח ירידות מותר שהחוזה חייב לעמוד בהם.
- מודל מתמטי של הסלוט. מאחדים טבלאות תשלומים, סיכויים והתנהגות בסדרות נדירות למודל אחד. מריצים אותו על זרמים היסטוריים וסינתטיים, עד שהתוצאות מפסיקות לסטות מהחישוב.
- סכימת חוזים. לפני הקוד מתארים מה אחראי למה: מאגר, תשלומים, מקור אקראיות, הרשאות מנהל. קובעים את הקשרים ואילו חלקים ניתנים לעדכון ואילו לא.
- מימוש והגדרה. כותבים חוזים לפי הסכימה, מחברים מקור אקראיות ניתן לאימות ומגבלות על משיכה. מפרידים תפקידים כך שמפתח אחד לא יוכל לשנות גם את הכללים וגם את היתרה.
- בדיקה ברשת בדיקה. מריצים תרחישים עם כשלים, סיבובים חוזרים וניסיונות למשוך יותר ממה שהמודל מתיר. כל פער שנמצא נסגר לפני העברה למתאר הראשי.
- קבלה ומסירה. בודקים את התוצאה מול המודל לפי רשימת תיוג, מוסרים תיעוד וניתוח חוזים, ומאמנים את הצוות. השליטה במפתחות ובעדכונים עוברת ללקוח.
מסירה: קוד מקור של חוזים, סכימות, תקנונים
מסירה היא לא ארכיון קוד, אלא ערכה שלפיה צוות אחר מנהל את הפרויקט בלעדינו. לכן החבילה כוללת לא רק את קוד המקור, אלא גם החלטות שבדרך כלל נשארות בראשו של המפתח: מדוע נבחר מסלול התשלומים הזה, מי רשאי להשהות את החוזה, מה לעשות במקרה של סטיית מצב.
- קוד מקור של חוזים — מאגר עם היסטוריית שינויים, מחולק לפי מתארים: יצירת אירועים אקראיים, לוגיקת הימורים, קופה, בונוסים. מוסרים את הגרסה שעברה בדיקה לפני ההשקה.
- סכימת ארכיטקטורה — קשרי חוזים, מקורות אקראיות, ארנקים ותפקידים, גבולות אמון. ממנה רואים מה ניתן לשנות ומה שובר את האינווריאנטים.
- מטריצת הרשאות גישה — 'תפקיד → פעולה → תנאי': מי מוציא כספים, מי משנה מגבלות, מי עוצר סיבוב, היכן נדרשות כמה חתימות.
- תקנון תשלומים — סדר זיכוי ומשיכה, עמלות, מגבלות, טיפול בפעולות תקועות ושנויות במחלוקת, פעולות התורן בעת סטיית יתרות.
- תקנון עדכונים — כיצד מכינים ופורסים גרסה חדשה, היכן נשמרים המפתחות, כיצד לחזור לקודמת בלי לאבד מצב.
- תיעוד לתמיכה — פניות אופייניות, שאילתות אבחון, רשימת תיוג לתורן, סדר הסלמה.
אנו מחשיבים את החבילה כמקובלת כאשר היא עוברת בדיקה שלכם, ולא שלנו: פורסים במתאר בדיקה, מריצים תשלומים ועדכון, ורק אז סוגרים את העבודות.
מקרה בוחן: כיצד הסרנו סיבובים שנויים במחלוקת ותשלומים ידניים
סלוט עם כמה אלפי סיבובים ביום נשען על בדיקה ידנית: תוצאה חושבה על ידי סקריפט נפרד, בונוסים המפעיל זיכה בייצוא, והתשלום יצא לאחר בדיקת רשימה.
כל אי-סנכרון ביומנים הפך למחלוקת — שיעור הסיבובים השנויים במחלוקת הגיע ל-3-4%, תשלומים התעכבו בשעות, וטיפול בפנייה אחת ארך עד חצי שעה של עבודה ידנית של המפעיל.
מה הועבר לחוזה
חישוב התוצאה וזיכוי הבונוסים הועברו לחוזה חכם: תוצאת הסיבוב נרשמת באירוע, מקור האקראיות — אורקל ניתן לאימות Chainlink VRF, התשלום לפי החוזה מתבצע אוטומטית עם אישור הסיבוב. ידני נשאר רק תהליך ההסלמה: תיקון כפוי מבוצע עם אישור דו-שלבי ורישום ביומן בלתי ניתן לשינוי.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור סיבובים שנויים במחלוקת | 3-4% | 0.2% |
| זמן תשלום לאחר סיבוב | 6-8 שעות | עד דקה |
| פעולות הדורשות ידיים | כל תשלום | כ-4% מהנפח |
| טיפול בסיבוב שנוי במחלוקת | עד 30 דקות | 3-5 דקות לפי יומן אירועים |
בתקנון המפעיל עוגנו שלושה סעיפים: מחלוקת נדונה רק לפי יומן האירועים של החוזה, תיקון ידני אינו אפשרי בלי מאשר שני ורישום ביומן, והחלפת פרמטרים של רשת הבונוסים מתבצעת באישור נפרד עם השהיה בכניסה לתוקף. זה הסיר את האזור האפור שבו ניתן היה לערער על תוצאת הסיבוב במילים, ולא בנתונים.
במה שונה אקראיות ניתנת לאימות מאקראיות שרתית
מחולל בצד השרת הוא פונקציה של זרע מקורי, זמן מערכת ומונה הימורים. הוא מהיר וצפוי במובן הטוב, אך את תוצאתו יודע מי ששולט בשרת: הזרע נשאר ביומנים או במסד הנתונים, ולכן למפעיל יש גם אפשרות טכנית ליצור מחדש את התוצאה לפני הרישום באחסון, וגם סיבה לעשות זאת.
אקראיות ניתנת לאימות בנויה אחרת: הערך מתבקש ממקור חיצוני ומגיע יחד עם הוכחה קריפטוגרפית. השחקן או מבקר עצמאי מחשב אותה מחדש לפי הנתונים שפורסמו ומשתכנע שהמספר נקבע לפני ההימור, ולא הותאם לו. החלפת התוצאה הופכת מ'שאלת אמון בממשק הניהול' לפעולה שאי אפשר לבצע מבלי ששמים לב.
אנו מחברים אורקלים חיצוניים — למשל, Chainlink VRF — ומספקים מקור גיבוי למקרה שהראשי אינו זמין, כדי שהסיבוב לא ייתקע בהמתנה.
ביקורת הגינות נשענת על שלושה דברים: האש הבקשה נרשם בחוזה לפני החשיפה, התוצאה נרשמת בבלוקצ'יין יחד עם ההוכחה, ויומן הסיבובים נשאר ציבורי ובלתי ניתן לשינוי. מחלוקת על סיבוב מסוים נפתרת בחישוב מחדש לפי נתונים אלה, ולא בייצוא ממסד נתונים פנימי.
מחיר הפתרון מתבטא בשני מקומות — מקור חיצוני מוסיף סיבוב המתנה לתגובה, אך לעומת זאת מוציא ממודל האיומים מחלקה שלמה של קנוניות ומניפולציות מצד המפעיל. להלן נבחן כיצד אנו בוחרים מצב בהתאם לעומס ומה אנו עושים עם ההשהיה.
ספקות לפני ההתחלה: אקראיות, בונוסים, הרשאות
מגבלות החוזים הן סיבה לתכנן את הסכימה מראש, ולא מכשול: לאחר הפרסום הלוגיקה אינה ניתנת לשינוי. פרמטרים שהעסק ישנה — מגבלות בונוסים, שיעורי ניכוי, כתובות אוצר — מוציאים לאחסון נפרד, ולצדם מחזיקים תפקידים ומצב השהיה.
כיצד לעדכן חוזה שכבר נפרס?
דרך שכבת מתווך: הכתובת נשארת קבועה, ומאחוריה מוחלפת גרסת הלוגיקה, את המצב לפני ההחלפה בודקים לפי סכומי ביקורת. תיקונים גדולים מוציאים כגרסה חדשה לצד — סיבובים לא גמורים מסתיימים לפי הכללים הקודמים, וההיסטוריה נשארת ניתנת לאימות.
מה יקרה אם מקור האקראיות אינו זמין?
הימורים נרשמים בעסקה אחת, המספר האקראי מגיע באישור נפרד — אי אפשר להשפיע על התוצאה. אם התגובה לא הגיעה בחלון המוסכם, הסיבוב נסגר עם החזר הימורים. הגינות מאושרת בפרסום ההאש לפני החשיפה: כל המעוניין יכול לחשב מחדש את התוצאה.
האם מכניקות בונוס לא יהפכו לדליפה?
בונוסים חיים במודול נפרד עם גבולות צבירה ומחזור. לפני ההשקה מריצים תרחישים על המודל: קומבינציות נדירות, זיכויים חוזרים, משיכת יתרת בונוס. האינווריאנט 'סכום הזיכויים אינו גבוה מהרזרבה' נבדק אוטומטית בעת שינוי פרמטרים.
כיצד בנויה משיכת כספים?
מאגר התשלומים מופרד מלוגיקת המשחק, ולכן סיבובים אינם תלויים במועד יציאת התשלום. בקשות עוברות בתור עם מגבלה על פעולה, סכומים גדולים — עם השהיה ואישור. רזרבת כיסוי ועצירת חירום מאפשרים לטפל באירוע בלי להפסיק את קליטת ההימורים.
נדון במשימה: היקף העבודה ונקודות בקרה
כדי לחזור עם הערכה ותוכנית עבודה, איננו צריכים כרך של מפרט טכני, אלא תשובות לכמה שאלות קונקרטיות. את היקף העבודה אנו מחלקים לפי מודולים — יצירת סיבוב, כלכלת תשלומים, אינטגרציות, תשתית פריסה — וכל אחד מחשבים בנפרד. נקודות הבקרה נקבעות לפני ההתחלה: אתם רואים מראש באיזה שלב מה יוצג ולפי אילו קריטריונים הוא מתקבל.
- רשת ומודל ביצוע: רשת יעד, תאימות חוזים, האם נדרשת תמיכה במספר רשתות בו-זמנית;
- מקור אקראיות: מחולל ניתן לאימות עצמאי, אורקל חיצוני או סכימה עם חשיפת זרע — מכך תלויים גם לוגיקת הסיבוב וגם דרישות הבדיקה;
- כלכלה: הימורים, מכפילים, מכניקות בונוס, מגבלות תשלום, כללי הפקדה לאוצר והגנה מפני ריקון המאגר;
- הרשאות ומפתחות: מי מחזיק במפתחות הניהול, האם נדרש מולטיסיג, כיצד מופרדות ההרשאות לעדכון חוזים ולמשיכת כספים;
- מערכות חיצוניות: ספק תשלומים, קופה, ערוצי פיאט, דרישות לאימות שחקנים — כל מה שמתממשק לחוזה;
- דרישות לבדיקות: האם נדרשת ביקורת עצמאית, אילו תרחישים אנו מחשיבים כחובה במתאר בדיקה;
- תוכנית השקה: תאריך קשיח להשקה ציבורית או מרווח לאיטרציות, מי מטעם הלקוח מקבל את השלבים.
סדר ההערכה פשוט: מנתחים את נתוני הקלט, מרכיבים סכימת סיבוב ותפקידים, מעריכים כל מודול בנפרד, ואז מאחדים לתוכנית אחת עם שלבים ונקודות בקרה.
בקרה שמים לאחר אישור סכימת הסיבוב, לאחר אב הטיפוס במתאר הבדיקה, לפני ביקורת ולפני השקה ברשת הראשית — בכל נקודה הדגמה ודוח קצר, ולא בירור פרטים בסוף.
תארו את המשימה בצורה חופשית וציינו מה מהרשימה כבר הוחלט — נחזור עם הערכה, היקף עבודה ולוח זמנים.