קריפטו-קזינו: ארכיטקטורת הפקדות ומשיכות

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

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

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

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

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

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

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

מה נותנת חשבונאות עסקאות מנוהלת ובקרת מגבלות

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

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

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

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

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

אפשרויות ארכיטקטורת הפקדות לקזינו: השוואה

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

בפועל הבחירה מצטמצמת לשלוש אפשרויות לארגון ארנק הקזינו.

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

שלבי היישום: מביקורת הזרימות ועד למסירה

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

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

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

מערך התיעוד והנהלים במסירה

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

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

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

מקרה בוחן: הסרנו משיכות תלויות ואי-התאמות בחשבונאות

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

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

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

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

במה נבדלת סכמה קסטודיאלית מלא-קסטודיאלית

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

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

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

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

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

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

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

כמה משיכות יישארו לטיפול ידני?

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

מי מחליט על המפתחות והרשאות המפעילים?

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

כיצד מותאמות היתרות בכמה רשתות?

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

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

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

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

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