משחקי PvP בבלוקצ'יין: מדוע יתרות המשחקים אינן תואמות
במשחק PvP הבלוקצ'יין אחראי רק לאחסון המצב ולזיכוי פרסים, בעוד שהקרב עצמו מחושב בשרת המשחק. בין שני העולמות הללו אין מקור אמת единый: הלקוח מציג תוצאה אחת, השרת קובע אחרת, והחוזה החכם ל-PvP מבצע שלישית — זו שאליה הגיעה העסקה באיחור המתאים.
מכאן שלוש תקלות אופייניות. חוסר סנכרון ביתרות המשחקים: השחקן רואה ניצחון ופריט מתכלה שנגרע, אך החוזה מזכה פרס לפי מצב מיושן — היתרה אינה תואמת את היסטוריית הקרבות, והפער מצטבר בכל סיבוב. החלפת תוצאת הקרב: מזהה או חתימת המשחק נעשה בהם שימוש חוזר, ולרשת נשלחת תוצאה שלא הייתה.
עיכוב בתשלומים: בזמן שהשרת והחוזה מסתנכרנים, הפריטים תלויים באוויר — אי אפשר למכור אותם או להשתמש בהם במשחק הבא.
כאב נפרד — סיבוב זירה שנוי במחלוקת. לא לשחקן ולא למפעיל יש הוכחה משותפת: יומני השרת במקום אחד, העסקה במקום אחר, ושחזור תמונת הקרב בדיעבד כמעט בלתי אפשרי. טיפול בפנייה אחת נמשך ימים, והתמיכה הופכת לביקורת יומנים ידנית במקום עבודה על המוצר.
זה נסגר לא באמצעות "כתיבה מחדש של המשחק על בלוקצ'יין", אלא בחוזה לקיבוע התוצאה: חישוב דטרמיניסטי של פרסים, חתימות של שני הצדדים בסיום המשחק וכללי חזרה אחורה מפורשים לסיבובים שנויים במחלוקת. נסביר איך זה בנוי.
מה נותן חישוב משחקים בחוזה חכם
חישוב משחק בחוזה אינו רישום לוג, אלא ביצוע כללים: החוזה מקבל תוצאות סיבוב חתומות, משווה אותן לפי סכימה קבועה ומזכה בעצמו את הפרסים לזוכה. הפרסים נשארים בחוזה, ולא בארנק של המנהל, לכן זמן תשלום הפרסים נמדד בבלוקים, ולא בזמן שבו לצוות יהיו ידיים פנויות לבדיקה ידנית.
ערעור על תוצאות סיבוב מובנה באותה לוגיקה: לאחר האישור נפתח חלון שבו השחקן מגיש ראיות — חתימות הצדדים וגיבובי מצב המשחק. המחלוקת נבחנת לפי כלל שנקבע לפני ההתחלה, ולא לפי התכתבות בתמיכה, לכן שיעור הסיבובים המעורערים יורד: שני הצדדים רואים מראש שהתוצאה ניתנת לאימות, והחלפה לא תעבור.
את הרשת אנו בוחרים לפי פרופיל המשחק: לסיבובים קצרים ותכופים ניקח את Polygon, שבו האישור נכנס לשניות, וחישוב הסיבוב אינו נתקע בתור.
מלאי השחקן שאינו ניתן לשינוי — תוצאה של אותה מודל: פריטים, פרסים וסטטיסטיקה נמצאים ברשומות שאי אפשר לשכתב בדיעבד, לא דרך ממשק הניהול ולא דרך שחזור מסד נתונים.
זה מסיר סוג שלם של כשלים — "פריטים נעלמו לאחר שחזור מגיבוי", "הפרסים לא הגיעו לזוכה". נשאר מקור שגיאות אחד: כלל החישוב עצמו, ואותו אנו מסירים בבדיקות על עותק של הרשת לפני ההשקה.
את האפקט אנו מודדים במספרים: הזמן מהזיכוי ועד הקליטה, שיעור הסיבובים שהגיעו למחלוקת, ושיעור התשלומים שעברו ללא התערבות ידנית.
השוואת ארכיטקטורות: חישוב בצד השרת, היברידי, מלא ברשת
חישוב המשחק יכול להימצא בשרת המשחק, בחוזה חכם, או להתחלק ביניהם. בחירה זו קובעת את תפוקת הזירה, את היענות הקרב, ואת מה שהשחקן יוכל להוכיח לאחר אפיזודה שנויה במחלוקת.
ארכיטקטורת מצב PvP היא לעיתים רחוקות בחירה של "או-או": קצב הקרב ודרישות ההוכחה מושכים לכיוונים שונים. להלן שלוש אפשרויות עבודה, והנקודה שבה כל אחת מתחילה להיתקע.
| אפשרות | כיצד מחושב המשחק | מתי מתאימה | היכן המגבלות |
|---|---|---|---|
| חישוב בצד השרת | את הקרב מנהל השרת, לחוזה נשלחת התוצאה וגיבוב יומן האירועים | קרבות מהירים, זירות גדולות | ניתנות ההוכחה נשענת על פרסום היומן ועל אמון במפעיל |
| חישוב משחקים היברידי | השרת מנהל את הקרב, החוזה בודק אירועי מפתח ואת התוצאה | מצבי דירוג עם פרסים | כללי בדיקה מורכבים יותר: שגיאה פותחת פתח להחלפת התוצאה |
| חישוב מלא ברשת | כל פעולה מאושרת ברשת, המצב משוחזר מההיסטוריה | מצבי תורות, אונליין קטן | תפוקת הזירה מוגבלת בהשהיה לאישור |
בפועל הגבול עובר לפי תדירות שינויי המצב: ככל שהקרב משתנה לעתים קרובות יותר, כך פחות הגיון לאשר כל צעד ברשת. האפשרות ההיברידית נותנת תוצאה ניתנת להוכחה במקום שבו היא חשובה, ואינה משלמת על כך בהשהיה בכל פגיעה — לכן לזירות תחרותיות אנו בדרך כלל מתכננים דווקא אותה.
שלבי הפיתוח: ממודל הכלכלה ועד העברת השליטה
סדר העבודה במשחק PvP בבלוקצ'יין שונה מפרויקט רגיל: אי אפשר לכוונן את כלכלת המשחק לאחר ההשקה — כללי חישוב הפרסים והדירוג מוטבעים בחוזים וגלויים לשחקנים. לכן אנו הולכים מהמכניקות לקוד, ולא להפך: כל שלב הבא נשען על החלטות שאושרו בשלב הקודם.
-
ניתוח מכניקות המשחק. מגדירים מה נחשב לתוצאה: תוצאת הקרב, ניקוד, רצף, יציאה מוקדמת. מכאן — רשימת האירועים שהחוזה חייב לקבל משרת המשחק, ורשימת מה שעליו לדחות.
-
תכנון כלכלת המשחקים. מחשבים זרימות ערך בתוך המשחק ובין משחקים: הימור, עמלת הזירה, תשלום לזוכה, החזר בעת ביטול. בודקים שבכל תרחיש היתרה מתאזנת והחוזה לא נכנס למינוס.
-
מימוש חוזים ותפקידי גישה. מפרידים חישוב, אחסון תוצאות ותשלומים למודולים שונים: שרת המשחק לא צריך להיות יכול למשוך כספים או לשכתב את היסטוריית הקרבות.
-
ביקורת חוזים. בודקים הגשה חוזרת של תוצאה, סדר קריאות, עיגולים בחלוקת פרסים, התנהגות בעת ביטול. את מה שנמצא סוגרים לפני ההשקה, ולא אחרי התקרית הראשונה.
-
בדיקת עומס לזירה. מריצים סיום משחקים המוני בו-זמנית ובודקים היכן נוצרת תור עסקאות וכיצד זה משתקף בזמן זיכוי הפרס.
-
העברת השליטה בחוזים. מעבירים בעלות ללקוח: גישות, מפתחות, נוהל עדכון ותוכנית פעולה בעת תקלה — עם הרצה ברשת בדיקה.
מה מוסרים לידיים: חוזים, סכימות ונוהלים
המסירה אינה מסתיימת באב-טיפוס עובד: לצוות הלקוח נשאר סט מלא של ארטיפקטים, שלפיהם אפשר לפתח ולתחזק משחק PvP בבלוקצ'יין בלעדינו. כל סעיף ניתן לבדיקה — לפיו אפשר לבנות את הפרויקט, לחזור על חישוב הסיבוב ולנתח תוצאה שנויה במחלוקת.
- קוד המקור של החוזים עם הערות וסביבת בדיקות פרוסה — הבנייה והבדיקות משוחזרות בפקודה אחת.
- סכימת זרימות הפרסים: מתוצאת הסיבוב ועד הזיכוי — היכן מקובעת התוצאה ומה קורה בעת אי-התאמה בנתונים.
- מדיניות גישה לניהול: מי משנה פרמטרים של המשחק, כמה אישורים נדרשים, מה אסור לשנות לאחר ההשקה.
- תיעוד חישוב המשחקים: נוסחאות דירוג, חלוקת פרסים, טיפול בתיקו וביציאות מוקדמות של שחקן.
- נוהל לניתוח סיבובים שנויים במחלוקת: מועדים, מי מקבל החלטה, אילו רשומות משמשות כהוכחה, סדר הערעור.
- סכימת יומן האירועים: בכל רשומה רואים איזה סיבוב הושלם ולפי איזה כלל, ושום דבר אינו נכתב מחדש בדיעבד.
- הוראות עדכון: הוצאת גרסה חדשה, העברת מצב, חזרה לגרסה קודמת בעת תקלה.
סט כזה מסיר את הסיכון המרכזי — תלות בקבלן. המסירה מתבצעת עם הסבר: מהנדסי הלקוח עוברים על כל ארטיפקט ומחזירים בעצמם את חישוב הסיבוב השנוי במחלוקת על נתוני בדיקה.
מקרה בוחן: זירה 1 על 1 עם תשלום פרסים דרך חוזה
פרויקט — Duel Arena: דו-קרבות אחד על אחד עם הימור, שבהם הזוכה לוקח את הקופה. חישוב הפרסים חי מחוץ למשחק: מפעילים השוו יומני משחקים, אישרו ידנית את התוצאה ושליחו תשלומים. בקנה מידה זה יצר עיכובים ומרחב לערעורים.
מה היה לפני
כ-6% מהסיבובים הסתיימו במחלוקת: שחקן הצהיר שהתוצאה הוחלפה או שהפרס לא הגיע. תשלום ארך בין כמה שעות ליומיים, ובערבי שיא בתור לעיבוד ידני המתינו עד 400 בקשות. התמיכה בדקה כל אחת לפי יומנים, וסוף התור לא נראה באופק.
מה שינו
את תוצאת הסיבוב חותמים שני הצדדים, והחוזה מקבל אותה רק אם החתימות תואמות — אי-התאמה עוברת אוטומטית לבדיקה לפי היומן, ולא להתכתבות. קרן הפרסים ננעלת בכניסה לדו-קרב ומחולקת באותה קריאה שמקבעת את התוצאה: אין יותר שלב נפרד של "לשלם", וגם לא אפשרות לערוך את התוצאה ידנית.
מה קרה אחרי
- תשלום — בתוך דקה במקום שעות ויממה; תור העיבוד הידני נעלם.
- שיעור הסיבובים השנויים במחלוקת — 0.3% לעומת 6%; הנותרים נבחנים לפי יומן שאינו ניתן לשינוי.
- עומס שיא — החישוב מתבצע במקביל בכל הדו-קרבות, אין צורך במפעיל במשמרת.
צוות הפרויקט קיבל לא רק מהירות, אלא גם את תפקיד הבורר הוסר ממנו: כללי הדו-קרב מתוארים בחוזה ואחידים לכולם.
מה לעשות אם הפרויקט כבר הושק בלי בלוקצ'יין?
אין צורך לאתחל מחדש את המשחק ולהעביר אותו לארכיטקטורה חדשה. שכבת החישוב מתחברת מהצד: השרת הנוכחי נשאר מקור האמת למכניקת הקרב, ואל השרשרת עוברות הבעלות על פריטים והתשלומים לפי תוצאות המשחקים. זה מהיר יותר ממעבר מלא ואינו שובר את מה שכבר עובד אצל השחקנים.
שלב ראשון — הוצאת הפרסים בלבד. השרת בסיום המשחק יוצר תוצאה חתומה, החוזה ברשת הציבורית Ethereum בודק את החתימה, הרכב המשתתפים ואת האידמפוטנטיות של הקריאה: שליחה חוזרת של אותה תוצאה אינה יוצרת תשלום שני. השחקן רואה זיכוי רגיל, ורק מקור החישוב משתנה.
שלב שני — העברת מלאי השחקנים. נלקחת תמונת מצב לתאריך מוסכם, הפריטים מונפקים בקבוצות לבעלות, וטבלת התאמה מקשרת מזהים ישנים לחדשים. המלאי נשאר בתוך המשחק, אך מפסיק להיות תלוי בשרת אחד: אפשר לבדוק פריט ולהעביר אותו.
תאימות עם השרת הנוכחי — תנאי הכרחי: המכניקות והאיזון אינם נכתבים מחדש. הפניות לשרשרת עוברות דרך שירות מתווך שמנהל תור, שומר מצב במטמון ומחזיר על פעולות שנדחו. אם הרשת אינה זמינה, המשחקים ממשיכים להתקיים, והחישובים מושלמים מאוחר יותר.
סדר השלבים מותאם למשחק: לעיתים די בתשלומים, ולעיתים ישר צריך העברת פריטים עם אפשרות מכירה. מתחילים בניתוח מודל הנתונים הנוכחי והנקודה שבה נוצר אמון בין השחקנים, ואחר כך — הטמעת חישוב בשלבים בלי לעצור את השירות.
ספקות טכניים: עיכובים, אקראיות, חזרה אחורה של סיבובים
לקוחות של משחקי PvP בודקים לא את התמונה, אלא את התנהגות הסיבוב תחת עומס: כמה מהר נסגר ההימור, האם אפשר לחזות את ההגרלה, מה קורה למשחק בעת תקלה ואיך משנים כללים כשהמשחק כבר הושק ויש בו הימורים חיים. להלן ארבעה ספקות שצפים לרוב לפני ההתחלה.
כמה זמן להמתין לאישור הסיבוב?
הסיבוב אינו ממתין לסופיות של הרשת הראשית: ההימורים מתקבלים בשכבה פנימית, ואל השרשרת עוברת תוצאה מסכמת. האישור נכנס לשניות, ובמקביל חישוב הפרסים נשאר ניתן לאימות.
איך להוכיח שההגרלה הוגנת?
האקראיות נבנית מתרומות השחקנים: כל אחד קודם מקבע את התרומה שלו, אחר כך חושף אותה, והתוצאה מחושבת לפי כולם יחד עם מקור חיצוני. לא המפעיל ולא השחקן יכולים להתאים לעצמם את התוצאה — אי-התאמה נראית בבדיקה.
מה קורה למשחק בעת תקלה?
חזרה אחורה של סיבוב — זו חזרה למצב ההתחלתי, ולא שכתוב ההיסטוריה: ההימורים מוחזרים, הדירוג לא משתנה, האירוע נשאר ביומן עם סימון. סיבוב חוזר מתחיל עם סט חדש של תרומות, ולכן אי אפשר להחליף את התוצאה.
האם אפשר לשנות כללים לאחר ההשקה?
הכללים וטבלאות התשלומים מנוהלים בגרסאות. מהדורה חדשה חלה מהסיבוב הנקוב ואינה משכתבת משחקים שעברו — בכל אחד רואים לפי איזו גרסה הוא חושב.
נדון במשימה: ננתח את מודל המשחקים והסיכונים שלכם
כדי לדון במשימת PvP בלי לחזור על מצגת, כדאי להתחיל מהחומרים שלכם — לפיהם ניתוח מכניקת המשחק מתבצע באופן ענייני, ולא לפי ניחושים. שלחו את מה שכבר קיים, אפילו בטיוטה:
- כללי המשחק: איך מורכב זוג היריבים, לפי אילו תנאים מחושבת התוצאה, מה נחשב לתיקו ואיך נפתרת סיטואציה שנויה במחלוקת;
- סכימת מצב: מה נשמר בחוזה, מה נשאר מחוץ לרשת, מי ובאיזה רגע רושם את התוצאה;
- כלכלה: בגין מה מזכים ומחייבים נכסים פנימיים, אילו מגבלות, עמלות וכללי משיכה;
- תפקידים וגישות: מי חותם על עסקאות, האם נדרש ארנק ריבוי-חתימות, מי יכול לעצור משחק;
- סביבת בדיקה או אב-טיפוס ויומן תקלות אחרונות — לפיו רואים אילו תרחישים כבר נשברו;
- תרחישי סשן מהכניסה ועד התשלום וטיוטות ממשק;
- ציפיות לעומס: כמה משחקים מתקיימים בו-זמנית ומה קריטי בזמן התגובה.
בהמשך — ראיון טכני עם הצוות: מנתחים היכן משתתף יכול להשפיע על התוצאה, מה יקרה בעת ניתוק או עיכוב ברישום התוצאה, וכיצד נבדקת הגינות החלוקה. חוזרים עם הערכה ותוכנית עבודה: סדר השלבים, מה בודקים ראשון, אילו מנגנונים כותבים מחדש ואילו משאירים, והיכן נותרו סיכונים.