פיתוח חוזי Dice עם Chainlink VRF: אקראיות הוגנת וביקורת

פיתוח חוזה חכם dice: היכן נשברת הגינות המשחק

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

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

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

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

מה נותנת אקראיות ניתנת לאימות: אפקט בכשלים ובמחלוקות

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

סוג הכשלים «התוצאה מסובבת» נעלם לחלוטין

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

ערעור על התוצאה מתכווץ לבדיקה אחת

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

החזרים ופיקוח על תשלומים הופכים לספירים

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

האמון במשחק עובר לשחקן

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

חיבור Chainlink VRF: אקראיות ניתנת לאימות במשחק

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

לכן אנו מוציאים את מקור האקראיות החוצה: או לאורקל חיצוני (Chainlink VRF), או שאנו קובעים ערך מראש וחושפים אותו לאחר קבלת ההימורים.

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

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

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

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

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

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

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

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

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

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

ארטיפקטים של מסירה: חוזים, סכמות ומדיניות גישה

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

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

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

מקרה בוחן: כתבנו מחדש את מכניקת ההטלה והסרנו סוג כשלים

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

שיעור ההטלות השנויות במחלוקת הגיע ל-6% מהסיבובים ששוחקו, וטיפול בפנייה אחת ארך לתמיכה עד יומיים — השוו ידנית לוגים, hashes והיסטוריית הימורים.

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

מדדים לאחר כתיבה מחדש של המכניקה: שיעור ההטלות השנויות במחלוקת ירד מ-6% ל-0.3%, טיפול בפנייה התקצר מיומיים ל-15 דקות, מכיוון שהשחקן עצמו רואה קישור לאישור התוצאה. החזרים ידניים על סיבובים שנויים במחלוקת ירדו לאפס, והיקף הפניות לתמיכה בחלק המשחקי ירד פי ארבעה.

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

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

מה לעשות אם החוזה כבר פרוס ועובד

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

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

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

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

תוכנית שחזור שינויים מוכנת לפני ההעברה הראשונה: כתובות, snapshot יתרות, הרשאות מנהל, נקודת חזרה. במקרה של אי-התאמה בחישובים, התעבורה חוזרת לחוזה הקודם — תרחיש השחזור מורץ מראש ברשת בדיקה.

ספקות טכניים שכדאי להסיר לפני ההתחלה

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

מה קורה אם שירות האקראיות אינו זמין?

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

האם ניתן לשנות מגבלות הימור לאחר ההשקה?

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

מי בודק את הקוד מבחוץ ומה בדיוק נבדק?

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

כמה זמן אורכת בדיקת קוד?

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

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

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

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

כדי להתחיל, די לשלוח:

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

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