چه اثبات عادلانه است و چگونه برای تست صداقت از بازی

منصفانه (PF)

Provably Fair یک پروتکل است که به شما اجازه می دهد تا به صورت رمزنگاری تأیید کنید که نتیجه دور تصادفی بوده و پس از شرط بندی نمی تواند توسط اپراتور جایگزین شود.

ایده: ابتدا یک کامیت منتشر می شود (hash از بذر سرور پنهان)، سپس پس از شرط بندی یک revil نشان داده می شود (بذر سرور خود)، و هر کسی می تواند هش را بررسی کند و RNG را بازتولید کند، با توجه به بذر مشتری و شناسه های دور بازیکن.

پروتکل پایه: تعهد → شرط → آشکار

1. تعهد: قبل از شروع دور، سرور یک «server _ seed» تصادفی تولید می کند و هش آن را منتشر می کند:


تعهد = SHA-256 (server_seed        نمک )//یا Keccak-256

Commit را می توان در تاریخچه/blockchain/مجله نمایش داد.

2. شرط: بازیکن 'client _ seed' خود را انتخاب یا تأیید می کند (از UI یا خود)، شرط را با:


client_seed، گرد، nonce

3. آشکار کردن: پس از بستن شرط ها، سرور «server _ seed» (و «salt» اگر وجود داشته باشد) را نشان می دهد تا همه بتوانند بررسی کنند:


SHA-256 (server_seed)        salt) = = تعهد/بررسی یکپارچگی

4. RNG: تعداد تصادفی بودن قطعی و قابل بازتولید است:


rng = HMAC-SHA256 (key = server _ seed, msg = client _ seed)        شناسه دور        نانس)
rng = SHA-256 (server_seed        client_seed        شناسه دور        نانس)

5. نقشه برداری به نتیجه: تبدیل 'rng' به محدوده بازی بدون جابجایی (پایین را ببینید).

💡 چرا نانس ؟ به طوری که با یک «server _ seed» شما می توانید چندین دور را بدون خطر پیش بینی صرف کنید: «nonce» هر دور/شرط را افزایش می دهد.

چگونه یک شماره رایگان رایگان دریافت کنیم

اشتباه است که «rng% N» را بگیریم - اگر 2 ^ k مضربی از N نباشد، یک افست ماژولار ایجاد می کند. درست است - نمونه برداری رد:

شبه
// rng_bytes = 32 بایت هش → uint256 x = uint256 (rng_bytes)

limit = floor (2 ^ 256/N) N در حالی که x> = limit:
rng_bytes = SHA-256 (rng_bytes )//» مخلوط« دوباره به طور قطعی x = uint256 (rng_bytes)

نتیجه = x٪ N

بنابراین ما یک توزیع یکنواخت بر روی نتایج N (سلول های رولت، نمادهای درام و غیره) دریافت می کنیم.

نمونه کوچک (تأیید گام بازیکن)

فرض کنید:


server_seed = «B2C6» e9 "//نشان داده شده پس از دور (hex/utf8)
client_seed = «my-client-seed «//من roundId را انتخاب کردم = »R-2025-10-17-001«
nonce = 42 commit = «c9a1» f3 "//publ. پیشاپیش

1) بررسی کنید

SHA-256 (server_seed) را بشمارید و مطمئن شوید که با commit مطابقت دارد.

2) RNG قطعی

تعداد:


rng = HMAC-SHA256 (key = server _ seed, msg = client_seed         ":"         شناسه دور         ":"         نانس)

3) تبدیل به نتیجه

برای رولت (37 عدد) → N = 37، نمونه گیری رد را اعمال کنید و «x٪ 37» را بگیرید.

برای یک اسلات، از چندین قطعه RNG برای تعریف قرقره ها/نمادها با توجه به جدول تخصیص استفاده کنید.

4) بررسی در برابر نتیجه در تاریخ

این سایت باید همان ورودی هایی را که در محاسبه استفاده می شود نشان دهد: «server _ seed»، «client _ seed»، «roundId»، «nonce»، «hashAlgo»، «rngAlgo»، «mappingVersion».

جایگزین/افزایش: VRF (تابع تصادفی قابل تایید)

به جای یک مرتکب، اپراتور می تواند (یا به صورت اختیاری) از VRF استفاده کند:

1. یک قرارداد هوشمند یا رجیستری عمومی از ارائه دهنده درخواست «VRF (seed)» می کند.

2. منتشر شده توسط «(تصادفی، اثبات)».

3. هر کسی می تواند «اثبات» توسط همان جفت کلید VRF عمومی را بررسی کند.

4. بعد، همان نقشه برداری RNG به نتیجه می رسد.

مزایا: اعتماد کمتر به اپراتور معایب: وابستگی به ارائه دهنده/زنجیره VRF و هزینه احتمالی.

چگونه یک کازینو باید PF را به درستی اجرا کند

قرارداد (قرارداد داده PF)

حاشیه ها در تاریخ دور:

'serverSeedHash'، 'serverSeedReveal'، 'clientSeed'، 'roundId'، 'nonce'، 'hashAlgo'، 'rngAlgo'، 'mappingVer'، 'proofUrl' (опц.) ، «کالک ور».
مقادیر - در ذخیره سازی WORM (تغییر ناپذیر)، با تمبر زمان (UTC).

تولید بذر

'سرور _ seed' توسط PRNG رمزنگاری (OS CSPRNG/HSM) تولید می شود.

SIDS هرگز نباید بین سری (چرخش) تکرار شود.

«client _ seed» - انتخاب شده توسط بازیکن یا تولید شده در مشتری و تایید شده است.

تعهدات انتشار

Commit ها قبل از شرط بندی (تاریخچه، RSS، on-chain-anchor) در دسترس هستند.

برای بسیاری، شما می توانید درخت merkley مرتکب با ریشه روزانه منتشر شده استفاده کنید.

آشکار کردن

قبل از انتشار نتیجه، «server _ seed» گسترش یافته و وارد سیستم می شود.

برای یک سری از دور در یک صندلی - افشای پس از پایان سری (نشان می دهد سیاست در پیش).

نقشه برداری شفاف

نسخه الگوریتم نقشه برداری ('mappingVer') ثابت است.

هر تغییری ('mappingVer '/' rngAlgo') - فقط با یک اعلامیه و یک سری جدید از commits.

حسابرسی و اختلافات

ورودی های خام + رکورد محاسبات ذخیره شده ؛ هنگام بحث، یک گزارش تولید می شود: ورودی → RNG → نقشه برداری → نتیجه.

جریان/زنده: فروشگاه CV/RFID رویداد هش لنگر، ویدئو در WORM.

چگونه یک بازیکن می تواند صداقت را بررسی کند (چک لیست)

1. تاریخچه دور را باز کنید و کپی کنید: «serverSeedReveal»، «clientSeed»، «roundId»، «nonce»، «hashAlgo»، «rngAlgo»، «mappingVer».

2. هش «سرور SeedReveal» را شمارش کنید و با «serverSeedHash» مقایسه کنید.

3. RNG را با توجه به الگوریتم مشخص شده (ورودی HMAC/Hash +) محاسبه کنید.

4. اعمال نقشه برداری «بی طرفانه» (نمونه برداری رد) به تعداد نتایج.

5. اطمینان حاصل کنید که نتیجه همان است که نشان داده شده است.

6. اگر VRF اعلام شده است، دکمه «proof» («Verify» یا independent script/block explorer) را بررسی کنید.

خطاهای معمول (ضد الگوهای)

'rng٪ N' without نمونه گیری رد → احتمالات مغرضانه.

«client _ seed» مخفی یا در حال تغییر (تولید شده توسط سرور بدون مشارکت بازیکن).

تولید مجدد «سرور _ بذر» پس از شرط بندی (مرتکب تغییرات عطف به ماسبق).

الگوریتم مات بدون نسخه/انتشار تغییر می کند.

پخش از طرف بین سری.

فقدان WORM/تمبر زمان - منظور از حوادث را نمی توان ثابت کرد.

مخلوط کردن PF و منطق کسب و کار (به عنوان مثال، پاداش به گونه ای اعمال می شود که فضای نتیجه را تغییر می دهد، اما این در mappingVer شرح داده نشده است).

سوالات متداول (کوتاه)

آیا می توان اسلات را بررسی کرد، نه فقط رولت ؟

بله، داشتم. PF به دنباله انتخاب اعمال می شود (به عنوان مثال، شاخص نماد در حلقه). مهم است که جداول احتمال RNG و دستور خواندن مستند شوند.

و اگر من «client _ seed» را وارد کردم، اپراتور هنوز می تواند «server _ seed» را انتخاب کند ؟

نه اگه تعهد قبل از پيشنهاد پست شده باشه این «server _ seed» را رفع می کند و اجازه نمی دهد که آن را به عقب بر گرداند.

چرا گاهی اوقات دو طرف را در دسته ها نشان می دهند ؟

به طوری که امکان «مرتب کردن» دانه در سری وجود نداشت. این قابل قبول است اگر تعهد در پیشبرد منتشر شده و سیاست افشای شفاف است.

فرمت های مینی مرجع

برچسب ها: SHA-256 یا Keccak-256

RNG: HMAC-SHA256 SHA-256 یا الحاق

شناسه ها: «roundId» (UTC-stamp + game + increment)، «nonce» (شمارنده شرط در سری).

Версии: 'rngAlgo = HMAC-SHA256 @ 1', 'mappingVer = رولت. v2 ',' calcVer = کیف پول-7. 2`.

چک لیست اجرای اپراتور PF

رمزنگاری و SIDS

CSPRNG/HSM ؛ منحصر به فرد 'server _ seed'، چرخش مستند.
'client _ seed' - توسط بازیکن کنترل می شود، در تاریخ ذخیره شده است.

انتشارات و ذخیره سازی

متعهد به شرط بندی، دسترسی به تاریخ/کانال انتشار/لنگر.
ذخیره سازی WORM، تمبر UTC، دسته مرکل برای مقیاس.

الگوریتم ها

RNG و نقشه برداری بدون تعصب ؛ versioning 'rngAlgo/mappingVer'.
اسکریپت/صفحه «بررسی صداقت» (منبع باز مطلوب است).

زنده و ترکیبی

CV/RFID/دور لنگر هش فاز، ورود «زمانی که پنجره شرط بندی بسته شد».
روش اختلاف (vkhodov → گزارش iskhod, لینک به تعهد/VRF).

امنیت و حسابرسی

ممیزی مستقل از پروتکل PF، جایزه اشکال.
گزارش های تصمیم گیری تغییر ناپذیر است ؛ تست های پخش منظم.

«Trust Us» را به «check it yourself» تبدیل می کند. "با استفاده از commit/revil یا VRF، RNG قطعی و نقشه برداری صحیح بدون افست، هر دور قابل تجدید و قابل اثبات است. برای یک بازیکن، این شفافیت و اعتماد است. برای اپراتور - جنجال کمتر، نام تجاری قوی تر و انطباق با الزامات قانونی. نکته اصلی نظم و انضباط است: انتشار تعهد در پیشبرد، رفع نسخه از الگوریتم، ذخیره شواهد همواره و به کاربر یک ابزار تایید ساده است.