עודכן לאחרונה ב- 27 באוקטובר 2025 על ידי קיסר פיקסון
כלי אימות הוגן להוכחה מתאים למשתמשים שיכולים להזין את קוד השרת (server seed) ואת קוד הלקוח (client seed) של משחק כדי לאמת הוגנות ערבוב; זה מושך שחקני קזינו קריפטו ובונה סמכות במשחקי בלוקצ'יין.
כלי חינמי לאימות הוגן מוכח
אימות הוגן שניתן להוכיח (HMAC-SHA256):
אימות זרעים, שחזור תוצאות, הוכחת שלמות
דף זה מאפשר לשחקנים, בודקים וצוותי תאימות אימות משחקים הוגנים שניתן להוכיח על ידי בדיקת ה- commit של שרת seed (SHA-256), שילובו עם ה- זרעי לקוח ו שליח, ו חישוב מחדש של התוצאהבלי קופסאות שחורות, בלי ויברים - רק HMAC-SHA256 דטרמיניסטי וניתן לשחזור RNG.
מה המשמעות של "הוגן להוכחה" בפועל
- קומיט סיד של השרת (לפני המשחק)המפעיל מפרסם גיבוב SHA-256 של זרע שרת סודי.
- לְשַׂחֵק: התוצאה נגזרת מ HMAC-SHA256(server_seed, pattern(client_seed, nonce)).
- גילוי (אחרי המשחק)המפעיל חושף את קוד השרת; commit חייב להתאים.
- אימותכל אחד יכול לשחזר תוצאות עם אותם קלטים. אם זה לא תואם, זה לא הוגן.
תגיות: קזינו הוגן להוכחה, התחייבות ל-HMAC-SHA256, גילוי זרעי שרת, זרעי לקוח, שליח, RNG דטרמיניסטי, כלי אימות הוגנות.
משחקים נתמכים וטווחי פלט
| משחק | מקור האקראיות | טווח פלט | הערות |
|---|---|---|---|
| קוביות | אינטס בלתי מוטים מזרם HMAC | 0–99 או 0–99.99 | ניתן לבחירה בדיוק. |
| רולטה (האיחוד האירופי) | מוד אינטרנט בלתי משוחד 37 | 0-36 | גלגל אפס יחיד. |
| רולטה (ארה"ב) | מוד אינטרנט בלתי משוחד 38 | 0–36 + 00 | 37 מפות עד "00". |
| קריסה (גנרית) | 52 סיביות ראשונות → r; mult=(1−edge)/(1−r) | ≥ 1.00× | ניתן להגדרה של קצה ומספרים עשרוניים. |
| ערבוב קלפים | פישר-ייטס דטרמיניסטי | תמורה של 52 קלפים | פלט כרטיסי N עליונים. |
כיצד לאמת (שלב אחר שלב)
- פסטה זרעי שרת (נחשפו) ו לבצע גיבוב מסופק לפני המשחק.
- פסטה זרעי לקוח ו מתחיל נון; בחר ספירת סיבובים.
- בחר את מִשְׂחָקהתאם את הדיוק/הקצה במידת הצורך.
- נְקִישָׁה אימות ויצירה.
- השווה את תוצאות הכלי ליומן המשחק של המפעיל. ה-Commit חייב להתאים ו יציאות עגולות חייבות להיות מיושרות בדיוק.
למה ההתחייבות חשובה
ללא א גיבוב מראש, המפעיל יכול להחליף זרעי שרת לאחר מכן כדי להתאים לתוצאות חיוביות. SHA-256 להתחייב → לחשוף ערבויות התחייבות מוקדמת: ה-seed שנחשף או מבצע hashing ל-commit המקורי (כנה) או שהוא לא (נתפס).
מודל אבטחה: מה מובטח (ומה לא)
- מוּבטָח: אין התעסקות לאחר המשחק אם ה-commit תואם והתוצאות מחושבות מחדש ביט אחר ביט.
- לא מובטח: מדיניות תשלום, RTP, כללי עיגול, אינטגרציות של צד שלישי או מלחים מחוץ לשרשרת שמפעיל לא פרסם. יש לוודא תמיד את דפוס הודעה מדויק (לְמָשָׁל,
{client}:{nonce}) וכל מלחים מסמכי המפעיל.
מלכודות נפוצות
- טעות דפוס הודעה (סדר אסימונים, מפרידים).
- משתמש ב חוסר התאמה (מבוסס 0 לעומת מבוסס 1).
- השוואה שגויה בין רולטה של האיחוד האירופי לאמריקאית (טיפול 00).
- קריסת מספרים עשרוניים/קצה לא תואמים לחוקי הבית.
- בלבול בין Hex לבין UTF-8 עבור זרעים (על המפעילים להשתמש זרעי טקסט, לא כתמי hex - כלי זה מצפה למחרוזות UTF-8).
יתרונות תאימות ואמון
- מסלול ביקורתלשחזר סבבים היסטוריים עבור חקירות KYC/RG.
- יישוב סכסוכיםהוכחה קריפטוגרפית עולה על צילומי מסך.
- משאב ראוי לקישורבלוגים של שותפים ובלוגים של ציות מצטטים באופן טבעי אימות הוגן להוכחה דפים עם כלים.
רשימת בדיקה לפתרון בעיות
- האם
SHA256(server_seed)שווה ל- פרסום commit? - האם שלך זרעי לקוח זהה (רישיות/רווחים)?
- האם ה שליח אותו דבר כמו ביומן המשחק?
- האם דפוס הודעה תואם למפרט של המפעיל?
- האם התוצאות עבור סבבי קבוצה, סיבוב אחר סיבוב, מתאימות?
שאלות נפוצות (עבור Rich Snippets)
מהו גיבוב commit הוגן להוכחה?
A גיבוב SHA-256 של זרעי השרת מתפרסם לפני המשחק. זה מוכיח שהזרע היה קיים ולא ניתן היה לשנותו מאוחר יותר מבלי לשבור את הגיבוב.
באיזה גיבוב/HMAC הכלי הזה משתמש?
SHA-256 עבור התחייבויות ו HMAC-SHA256 (seed של השרת כמפתח) לאקראיות לכל סיבוב - גישה סטנדרטית בתעשייה.
האם אני יכול לאמת מכפילי קריסות?
כן. הכלי גוזר r מ-52 הביטים הראשונים של פלט HMAC ומחשבים mult = (1 − edge) / (1 − r). הגדר קצה הבית ו עשרוניות כדי להתאים לאופרטור.
מה קורה אם אופרטור משתמש בפורמט שונה?
השתמש ב"מתקדם" כדי להגדיר את דפוס הודעה (לְמָשָׁל, {client}|{nonce}) ולכלול כל מלח נוסף שהמפעיל מתעד.
האם זה מוכיח את ה-RTP?
לא. זה מוכיח שלמות התוצאה, לא מתמטיקה של תשלומים. החזר כספי (RTP) הוא סטטיסטי ותלוי במדיניות.
