אינטגרציה של משחק עם ארנק בלוקצ'יין — Web3 ו-Unity

מדוע אינטגרציה של ארנק בלוקצ'יין במשחק מכשילה את ההשקה

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

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

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

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

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

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

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

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

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

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

התוצאה בפרויקטים: שיעור הפעולות המוצלחות עולה מ-92–94% ל-99.5% ומעלה, אישור הזיכוי מתבצע בשניות במקום דקות, מספר הבירורים הידניים יורד בסדר גודל, וסוג הכשל «טרנזקציה בלי זיכוי» מפסיק להיות נפוץ.

אינטגרציה של ארנק בלוקצ'יין במשחק: מצבי חיבור

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינינו בסכמת הזיכוי

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

מה קרה למטריקות

שיעור הזיכויים המוצלחים עלה מ-71% ל-99.4% מכלל הטרנזקציות החתומות, והשאר הם ביטולים מודעים של השחקן עצמו. הפריט מופיע במלאי בממוצע כעבור 8 שניות מהאישור ברשת, במקום 5–20 דקות קודם, והתוצאה כבר לא תלויה בשאלה אם השחקן משאיר את היישום פתוח.

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

מה קורה אם השחקן דחה טרנזקציה בארנק?

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

מה יקרה לנכסים אם נוותר על החוזה שלנו?

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

מי משלם את עמלת הרשת?

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

מה יהיה עם הנכסים כשמשנים את כללי הכלכלה?

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

נדבר על המשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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