الگوریتم Provably Fair در بازی انفجار چگونه کار می‌کند؟

هر دور بازی انفجار روی ۱.۰۰x شروع می‌شود، بالا می‌رود و یک جایی می‌ترکد. سؤالی که بعد از هر ترکیدن باقی می‌ماند این است: این عدد همین حالا و بعد از دیدن شرط من ساخته نشد؟ الگوریتم Provably Fair دقیقاً برای پاسخ دادن به همین سؤال طراحی شده است، نه برای پیش‌بینی دور بعد.

در این متن می‌بینید هش بازی، seed سرور و seed کلاینت چطور به هم می‌خورند، چرا افشای seed بعد از چرخش اهمیت دارد، و چطور در چند دقیقه صحت یک دور را خودتان بازسازی کنید. اگر تازه با این بازی آشنا شده‌اید، اول راهنمای بازی انفجار را بخوانید و بعد به این صفحه برگردید.

Provably Fair چیست؟

Provably Fair یعنی «قابل اثبات منصفانه»: مجموعه‌ای از قواعد رمزنگاری که به شما اجازه می‌دهد بعد از پایان هر دور، مستقلاً بررسی کنید نتیجه از قبل تعیین شده و دستکاری نشده است. این با جمله «ما عادل هستیم» فرق دارد. حتی با گزارش یک شرکت حسابرسی هم فرق دارد؛ آن گزارش می‌گوید کد در لحظه آزمون سالم بود، اما اثبات منصفانه به شما اجازه می‌دهد خودِ همان دور را با همان ورودی‌ها دوباره بسازید.

سه پایه دارد و اگر یکی نباشد، چیزی که می‌بینید فقط ادعاست:

• تعهد قبل از دور: پلتفرم هش seed سرور را قبل از شروع دور منتشر می‌کند.
• ورودی شما: seed کلاینت را خودتان تعیین می‌کنید و یک شمارنده به نام nonce هر دور را یکتا می‌کند.
• افشا بعد از دور: پس از چرخش seed، مقدار واقعی آن منتشر می‌شود تا محاسبه قابل بازسازی باشد.

نکته‌ای که باید از اول روشن شود: این سازوکار گذشته را اثبات می‌کند، نه آینده را. هیچ بخشی از آن به شما نمی‌گوید دور بعد روی چه ضریبی می‌ترکد. کسی که خلاف این را بفروشد، دارد چیزی را می‌فروشد که وجود ندارد.

هش، seed و نقش آن‌ها

Seed یک رشته داده است که به‌عنوان ورودی تصادفی به تابع تولید عدد داده می‌شود. در بازی انفجار سه ورودی داریم و تفاوت آن‌ها کل ماجرا را می‌سازد.

ورودی	چه کسی تعیین می‌کند	قبل از دور دیده می‌شود؟	نقش
server seed	پلتفرم	فقط هش آن	منبع اصلی تصادف، مخفی تا زمان چرخش
client seed	خود شما	بله	جلوگیری از تعیین نتیجه فقط توسط سرور
nonce	شمارنده خودکار	بله، در تاریخچه دورها	یکتا کردن ورودی هر دور

هش بازی خروجی تابع SHA-۲۵۶ روی server seed است. این تابع یک‌طرفه است: از seed به هش می‌رسید، اما از هش نمی‌توانید seed را بسازید. همین ویژگی، هش را به یک «تعهد» قابل استفاده تبدیل می‌کند. پلتفرم قبل از دور می‌گوید «seed من هشی دارد که با این رشته شروع می‌شود» و بعد از دور seed را نشان می‌دهد. اگر seed افشاشده هش متفاوتی بدهد، یعنی چیزی عوض شده است.

تغییر یک کاراکتر در seed، هش را کاملاً دگرگون می‌کند. این خاصیت به شما اطمینان می‌دهد که پلتفرم نمی‌تواند بعد از باخت شما seed دیگری بسازد که هم نتیجه دلخواهش را بدهد و هم هش قبلی را حفظ کند. پیدا کردن چنین seed‌ای از نظر محاسباتی عملاً ناممکن است.

چرا seed کلاینت لازم است؟

اگر فقط server seed وجود داشت، پلتفرم می‌توانست هر seed‌ای را انتخاب کند که برایش سودآور است. با اضافه شدن client seed، نتیجه به ورودی‌ای وابسته می‌شود که شما کنترل می‌کنید.

اما دقت کنید: چون هش قبل از انتخاب شما منتشر شده، سرور نمی‌تواند seed خود را با seed شما هماهنگ کند. ترتیب زمانی، همان چیزی است که این سازوکار را معتبر می‌کند. اگر پلتفرمی اجازه دهد هش را بعد از شرط ببینید، یا هش را برای چند دور مختلف یکسان نگه دارد، اثبات منصفانه بودن آن دور عملاً بی‌معناست.

یک دور کامل: از تعهد تا افشا

بیایید یک دور را قاب به قاب دنبال کنیم.

قبل از دور. پلتفرم یک server seed تصادفی می‌سازد، آن را در جای امن نگه می‌دارد و هش SHA-۲۵۶ آن را در صفحه بازی یا API عمومی منتشر می‌کند. شما این هش را می‌بینید، می‌توانید کپی کنید و کنار بگذارید.

لحظه شرط. شما مبلغ را وارد می‌کنید و seed کلاینت خود را تعیین می‌کنید. اگر seed را عوض نکنید، همان مقدار قبلی با nonce جدید استفاده می‌شود. nonce یک شمارنده است که با هر دور یکی بالا می‌رود و تضمین می‌کند ورودی هر دور با دور قبل یکسان نباشد.

محاسبه. پلتفرم با استفاده از HMAC-SHA256 روی server seed، client seed و nonce یک عدد می‌سازد و از آن ضریب انفجار را درمی‌آورد. این محاسبه قبل از شروع انیمیشن انجام می‌شود؛ انیمیشن فقط نمایش است. ضریب از قبل قطعی است و هیچ ورودی جدیدی وسط دور اضافه نمی‌شود.

بعد از دور. ضریب و نتیجه در تاریخچه شما ثبت می‌شود. تا اینجا همه‌چیز قابل بررسی است، اما هنوز یک حلقه کم است: شما seed واقعی سرور را ندیده‌اید و نمی‌توانید محاسبه را تکرار کنید.

چرخش seed و لحظه افشا

پلتفرم هر چند دور یا با درخواست شما، seed سرور را عوض می‌کند. در همان لحظه، seed قدیمی افشا می‌شود و هش جدید برای دورهای بعدی منتشر می‌شود. این نقطه، پایان چرخه اعتماد است: با seed افشاشده می‌توانید همه دورهایی که با آن seed انجام شده‌اند را بازسازی کنید، از اول تا آخر.

یک قاعده ساده برای خودتان بسازید: تا وقتی seed افشا نشده، نتیجه آن دور «تأییدنشده» است. بعد از افشا، تأیید یا رد آن چند ثانیه کار دارد. اگر پلتفرمی هیچ‌وقت seed را افشا نمی‌کند، ادعای Provably Fair آن ارزش عملی ندارد.

تجربه: بیشتر بازیکنان هش را کپی می‌کنند و هیچ‌وقت چک نمی‌کنند. همان کپی کردن هم بی‌فایده نیست، چون سابقه‌ای می‌سازد که بعداً می‌توانید با آن اختلاف را نشان دهید، اما تأیید واقعی فقط با محاسبه انجام می‌شود.

فرمول پشت ضریب

حالا برویم سر اصل مطلب. محاسبه در نسخه‌های رایج بازی انفجار چنین شکلی دارد:

“`text

h = HMAC-SHA256(key = server_seed, message = client_seed + ":" + nonce)

n = عدد صحیح ۱۳ کاراکتر اول h در مبنای ۱۶ (بازه ۰ تا ۲^۵۲)

اگر n % ۳۳ == ۰ → ضریب = ۱.۰۰

در غیر این صورت → ضریب = floor((۱۰۰ × ۲^۵۲ − n) / (۲^۵۲ − n)) / ۱۰۰

“`

سه چیز در این فرمول مهم است.

اول، HMAC-SHA256 است، نه یک تولیدکننده ساده عدد تصادفی. HMAC یک کلید (server seed) و یک پیام (client seed و nonce) را ترکیب می‌کند و خروجی ۲۵۶ بیتی می‌دهد. بدون دانستن کلید، پیش‌بینی خروجی ممکن نیست؛ با دانستن کلید، محاسبه برای هر کسی قابل تکرار است. همین دو ویژگی، پایه اثبات است.

دوم، ۱۳ کاراکتر هگز معادل ۵۲ بیت است. تقسیم بر ۲ به توان ۵۲ عددی بین صفر و یک می‌دهد که با آن فرمول به ضریب تبدیل می‌شود. این فرمول توزیعی می‌سازد که در آن ضریب‌های کوچک بسیار بیشتر از ضریب‌های بزرگ اتفاق می‌افتند: تقریباً نیمی از دورها زیر ۲x تمام می‌شوند و رسیدن به ۱۰x حدود یک بار در ده دور است.

سوم، شرط n % ۳۳ == ۰. این همان «انفجار فوری» روی ۱.۰۰x است و در نسخه‌ای که RTP آن حدود ۹۷٪ است، تقریباً یک دور از هر ۳۳ دور را می‌سازد. در نسخه‌های ۹۹٪ این نسبت به یک از ۱۰۱ تغییر می‌کند و شکل فرمول هم کمی تفاوت دارد. به همین دلیل نمی‌شود یک عدد ثابت را به همه پلتفرم‌ها نسبت داد؛ باید نسخه و RTP همان بازی را دید.

نکته‌ای که خیلی‌ها اشتباه می‌فهمند: خروجی همیشه تا دو رقم اعشار پایین گرد می‌شود. پس ضریب ۲.۳۴۹… به ۲.۳۴ تبدیل می‌شود، نه ۲.۳۵. اگر بازسازی شما ۲.۳۴۹ شد و سایت ۲.۳۴ نشان داد، اختلاف نیست؛ همان نتیجه است.

یک مثال برای اینکه حس عددی بگیرید. شرط ۱۰۰ هزار تومان است و روی ۱.۸x خارج می‌شوید؛ دریافتی ۱۸۰ هزار تومان است. روی ۱.۵x خارج شوید، ۱۵۰ هزار. اما اگر ضریب انفجار همان دور ۱.۷۹ باشد، ۱.۸x هرگز نمی‌آید و کل ۱۰۰ هزار از دست می‌رود. تفاوت ۱.۷۹ و ۱.۸۰ در این بازی تفاوت برد و باخت است و همین است که محاسبه را تا دو رقم اعشار جدی می‌کند.

چطور خودتان صحت یک دور را بررسی کنید

این کار به یک مرورگر و یک ترمینال نیاز دارد، نه بیشتر. مراحل را دقیقاً به همین ترتیب بروید.

1. هش را قبل از شرط بردارید. هش seed فعلی را از بخش «انصاف» یا «Provably Fair» کپی کنید و جایی ذخیره کنید، همراه با شماره دور.
2. seed کلاینت و شماره nonce را ثبت کنید. هر دو باید در تاریخچه دور یا پنل seed دیده شوند. اگر پلتفرم nonce را نشان نمی‌دهد، همان‌جا یک علامت سؤال بزرگ بگذارید.
3. بازی کنید و ضریب اعلامی را یادداشت کنید. مثلاً دور شماره ۴۱۲ با ضریب ۲.۳۴x.
4. بعد از چرخش، seed افشاشده را بردارید. آن را در تابع هش بگذارید و با هش مرحله اول مقایسه کنید. اگر یکی نبود، همان‌جا متوقف شوید؛ بقیه محاسبات بی‌معنی است.
5. ضریب را بازسازی کنید. با همان seed افشاشده، client seed و nonce محاسبه را تکرار کنید و نتیجه را با عدد اعلامی بسنجید.

برای مرحله چهارم، در ترمینال لینوکس یا مک کافی است بنویسید:

“`bash

printf '%s' "SERVER_SEED_HERE" | sha256sum

“`

خروجی باید با هشی که قبل از دور دیدید کاراکتر به کاراکتر یکی باشد. برای مرحله پنجم یک اسکریپت کوتاه پایتون کافی است:

“`python

import hmac, hashlib

server_seed = "seed افشاشده"

client_seed = "seed شما"

nonce = 412

msg = f"{client_seed}:{nonce}".encode()

h = hmac.new(server_seed.encode(), msg, hashlib.sha256).hexdigest()

n = int(h[:13], 16)

e = 2**52

crash = ((100 * e – n) // (e – n)) / 100

print(crash)

“`

اگر خروجی ۲.۳۴ بود و سایت هم ۲.۳۴ اعلام کرده بود، آن دور تأیید می‌شود. اگر تفاوت داشت، اول گرد کردن اعشار را چک کنید، بعد ترتیب client seed و nonce را، و در آخر نسخه فرمول. فقط بعد از این سه بررسی است که می‌توان گفت اختلاف واقعی است.

سه خطای رایج در بازسازی

• گذاشتن هش به‌جای seed. تابع HMAC باید seed واقعی و افشاشده را بگیرد. اگر هش SHA-۲۵۶ را داخل آن بگذارید، خروجی عددی بی‌ربط می‌شود و به اشتباه فکر می‌کنید سایت دستکاری کرده است.
• جابه‌جا کردن ورودی‌ها. در این فرمول server seed کلید است و client seed بخشی از پیام. جابه‌جا کردنشان خروجی کاملاً متفاوتی می‌دهد و شایع‌ترین علت «اختلاف» در بازسازی‌های دستی است.
• استفاده از seed اشتباه. هر بار که seed سرور چرخیده، دورهای قبل با seed قدیمی حساب می‌شوند. اگر seed جدید را روی دور قدیمی بگذارید، جواب نمی‌گیرید.

هشدار: هیچ‌کس برای بررسی صحت یک دور لازم نیست رمز عبور، کد دو مرحله‌ای یا کلید کیف پول شما را ببیند. هر سایتی که برای «تأیید انصاف» این‌ها را خواست، در حال فیشینگ است.

الگوریتم Provably Fair چه چیزی را اثبات می‌کند و چه چیزی را نه

این تفکیک، مهم‌ترین بخش این مقاله است. Provably Fair یک ابزار دقیق است، اما فقط برای یک سؤال مشخص.

اثبات می‌کند	اثبات نمی‌کند
نتیجه قبل از شرط شما تعیین شده بود	اینکه دور بعد چه ضریبی دارد
نتیجه بعد از شرط دستکاری نشده است	اینکه بازی سودده است
ورودی شما در محاسبه نقش داشته	اینکه RTP واقعی همان چیزی است که ادعا می‌شود
seed افشاشده با هش منتشرشده می‌خواند	اینکه دورها به هم وابسته‌اند

ردیف آخر را جدی بگیرید. حتی اگر همه محاسبات درست باشد، هر دور از دور قبلی مستقل است. توزیع احتمال حافظه ندارد. پنج بار ترکیدن روی ۱.۰۲x احتمال ترکیدن ششم روی ۱.۰۲x را کمتر نمی‌کند و احتمال آمدن ۵۰x را بیشتر نمی‌کند. این توهم که «الگوریتم بدهکار شده» یکی از گران‌ترین خطاهای ذهن است و در تحلیل آماری ضرایب با عدد و نمودار بازش کرده‌ایم.

چرا «الگوریتم‌شکن» و «سیگنال» کار نمی‌کند

حالا می‌توانید خودتان جواب این بازار را بدهید. اگر کسی می‌توانست ضریب دور بعد را از هش یا از seed بخواند، باید HMAC-SHA256 را بدون دانستن کلید بشکند. چنین چیزی تا امروز برای هیچ‌کس اتفاق نیفتاده و اگر افتاده بود، کل امنیت اینترنت فرو می‌ریخت، نه فقط یک بازی.

پس آن گروه‌های تلگرامی چه می‌فروشند؟ چند الگوی ساده روی تاریخچه، چند اسکرین‌شات از بردهای انتخابی، و یک قیمت اشتراک. بعضی‌شان هم فقط دنبال دسترسی به حساب شما هستند. فایل APK «هک بازی انفجار» در بهترین حالت یک تبلیغ است و در بدترین حالت بدافزاری که پیامک‌های بانکی را می‌خواند.

تجربه: اگر گروهی واقعاً می‌توانست ضریب را بخواند، لازم نبود اشتراک بفروشد. این ساده‌ترین آزمون برای هر «سیگنال» است.

شفافیت ضرایب و نقش الگوریتم Provably Fair در عمل

شفافیت ضرایب سه چیز قابل مشاهده می‌خواهد: هش قبل از دور، تاریخچه کامل دورها با nonce، و افشای منظم seed. اگر یکی از این‌ها پنهان باشد، بقیه هم ارزش کمی دارند.

چند سؤال عملی که قبل از اعتماد به هر پلتفرمی می‌توانید بپرسید: هش seed را کجا منتشر می‌کند؟ چند دور یک seed را نگه می‌دارد؟ آیا می‌توانید seed کلاینت را خودتان عوض کنید؟ آیا nonce در تاریخچه دور دیده می‌شود؟ پاسخ‌ها را با آنچه در پنل می‌بینید مقایسه کنید، نه با آنچه در صفحه تبلیغات نوشته شده.

یک نکته درباره حساب: بررسی صحت دورها به سابقه‌ای نیاز دارد که به حساب شما گره خورده است. همان‌طور که در راهنمای واریز و برداشت با ارز دیجیتال توضیح داده‌ایم، بهتر است تراکنش‌ها و سابقه بازی را جداگانه ذخیره کنید، چون بعضی پلتفرم‌ها بعد از مدت محدودی تاریخچه را کوتاه می‌کنند.

فاصله چرخش seed هم مهم است. اگر پلتفرم هر هزار دور یک بار seed را عوض کند، صدها دور بین دو افشا می‌مانند که تا آن لحظه قابل بررسی نیستند. چرخش کوتاه‌تر، شفافیت بیشتری می‌دهد و کار بررسی را سبک‌تر می‌کند. بعضی سایت‌ها چرخش دستی هم می‌گذارند تا اگر خواستید، خودتان seed را ببندید و هش جدید بگیرید. این گزینه کوچک، نشانه جدی بودن پلتفرم در شفافیت ضرایب است.

استقلال دورها و نقش RTP

RTP در بازی انفجار معمولاً بین ۹۷ تا ۹۹ درصد است، یعنی خانه حدود ۱ تا ۳ درصد لبه دارد. این عدد از توزیع ضریب می‌آید، نه از تنظیم دستی هر دور. در نسخه‌های رایج این بازی معمولاً حدود ۹۷٪ گزارش می‌شود و همان یک از ۳۳ انفجار فوری، بخش اصلی این لبه را می‌سازد.

RTP یک میانگین بلندمدت است. با ۲۰ دور نمی‌شود آن را دید، با ۲۰۰ هزار دور می‌شود. در یک نشست کوتاه، واریانس چیزی است که تجربه شما را می‌سازد، نه RTP. دو نفر با یک استراتژی یکسان و یک بازی یکسان می‌توانند نتیجه‌های کاملاً متفاوتی بگیرند، چون مسیر رسیدن به میانگین برای هرکس متفاوت است.

همین استقلال، معنای «کش‌اوت» را هم روشن می‌کند. تصمیم شما درباره زمان خروج، تنها متغیری است که در کنترل شماست و روی توزیع دور بعد اثری ندارد. اگر ضریب هدف را از قبل انتخاب کرده‌اید، Provably Fair هیچ کمکی به بهتر شدن آن انتخاب نمی‌کند؛ فقط مطمئن می‌شوید بازی با شما سرِ راست بازی کرده است.

و یک یادآوری صادقانه: هیچ‌کدام از این‌ها بازی را کم‌ریسک نمی‌کند. پولی که وارد می‌کنید باید پولی باشد که از دست دادنش زندگی‌تان را تغییر نمی‌دهد، و توقف روی حد ضرر از هر تحلیل الگوریتمی مهم‌تر است.

سوالات متداول

🛡️

تیم تحریریه سایت شرط بندی

مقالات با بررسی عملی ثبت نام، واریز، برداشت و بازی ها نوشته و به صورت دوره ای به روزرسانی می شوند. هدف ما راهنمای دقیق، شفاف و مسئولانه برای کاربران سایت شرط بندی است.