פיתוח Keno על בלוקצ'יין: VRF, חוזים חכמים, אופטימיזציית גז

פיתוח Keno על הבלוקצ'יין: היכן נשברת הגינות הסיבוב

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

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

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

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

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

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

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

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

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

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

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

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

מצבי השגת אקראיות: רשת, היברידי, מקור חיצוני

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

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

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

שלבי פיתוח המשחק: מסכימת הסיבוב ועד המסירה

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

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

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

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

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

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

מקרה בוחן: העברת ההגרלה לרשת — מטריקות לפני ואחרי

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

שיעור הסיבובים השנויים במחלוקת עמד על 0.4%, וכל בירור עבר להשוואה ידנית של לוגים, שנמשכה מכמה שעות ועד כמה ימים.

מה שינו

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

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

מטריקות אחרי

חישוב הסיבוב אורך 1–2 שניות ללא תלות במספר המשתתפים. תשלומים שנויים במחלוקת — אפס על יותר מ-12,000 סיבובים: השחקן מאמת בעצמו את התוצאה לפי האירוע ולפי הקוד הפתוח של החוזה.

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

במה נבדלת אקראיות ניתנת לאימות ממחולל שרת?

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

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

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

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

התנגדויות טכניות נפוצות וכיצד אנו מסירים אותן

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

האם צריך לעצור את השירות בזמן ההעברה?

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

האם אפשר לשנות את כללי התשלום לאחר ההשקה?

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

נדון במשימה: מה נדרש כדי להתחיל בעבודה

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

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

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