Provably Fair nedir ve oyunun bütünlüğünü nasıl test edersiniz

Kanıtlanabilir Adil (PF)

Provably Fair, yuvarlak sonucun rastgele olduğunu ve bahisten sonra operatör tarafından değiştirilemeyeceğini kriptografik olarak doğrulamanızı sağlayan bir protokoldür.

Fikir: Önce bir taahhüt yayınlanır (gizli sunucu tohumunun karması), daha sonra bahisten sonra bir revil ortaya çıkar (sunucu tohumunun kendisi) ve oyuncunun istemci tohumu ve yuvarlak tanımlayıcıları göz önüne alındığında, herkes karmayı kontrol edebilir ve RNG'yi yeniden üretebilir.

Temel protokol: commit - bet - reveal

1. Commit: turlar başlamadan önce, sunucu rastgele bir 'server _ seed' oluşturur ve hash'ini yayınlar:


commit = SHA-256 (server_seed        tuz )//veya Keccak-256

Commit tarih/blockchain/dergide görüntülenebilir.

2. Bahis: oyuncu 'client _ seed' (UI veya kendi) seçimini yapar veya onaylar, bir bahis gönderir:


client_seed, roundId, nonce

3. Reveal: Bahisleri kapattıktan sonra, sunucu herkesin kontrol edebilmesi için 'server _ seed' (ve varsa 'salt') ortaya çıkarır:


SHA-256 (server_seed        Tuz) = = commit//integrity check

4. RNG: rastgelelik sayısı deterministik ve tekrarlanabilir:


rng = HMAC-SHA256 (key = server _ seed, msg = client _ seed        YuvarlakId        nonce)
//veya rng = SHA-256 (server_seed        client_seed        YuvarlakId        nonce)

5. Sonuca eşleme: 'rng'yi yer değiştirmeden oyun aralığına dönüştürün (aşağıya bakın).

💡 Neden nonce? Böylece bir 'server _ seed'ile öngörülebilirlik riski olmadan birçok tur geçirebilirsiniz: Her turda/bahiste' nonce 'artışları.

Önyargısız bir sayı nasıl elde edilir

'Rng % N' almak yanlıştır - bu, 2 ^ k N'nin bir katı değilse modüler bir ofset verir. Bu doğru - reddetme örneklemesi:

pseudo
// rng_bytes = 32 bayt özet = uint256 x = uint256 (rng_bytes)

Limit = zemin (2 ^ 256/N) N iken x> = limit:
rng_bytes = SHA-256 (rng_bytes )//" mix" tekrar deterministik olarak x = uint256 (rng_bytes)

Sonuç = x % N

Böylece N çıktıları üzerinde tekdüze bir dağılım elde ederiz (rulet hücreleri, davul sembolleri, vb.).

Mini Örnek (Oyuncu Adımı Doğrulama)

Varsayalım:


server_seed = "b2c6... e9 "//turdan sonra ortaya çıktı (hex/utf8)
client_seed = "my-client-seed "//Seçili roundId = "R-2025-10-17-001"
nonce = 42 commit = "c9a1... f3 "//publ. Önceden

1) Onay taahhüdü

'SHA-256 (server_seed)' değerini sayın ve 'commit'ile eşleştiğinden emin olun.

2) Deterministik RNG

Kont:


rng = HMAC-SHA256 (key = server _ seed, msg = client_seed         ":"         YuvarlakId         ":"         nonce)

3) Sonuca dönüşüm

Rulet için (37 sayı) - N = 37, reddetme örneklemesi uygulayın ve 'x %37' alın.

Bir yuva için, ayırma tablosuna göre makaraları/sembolleri tanımlamak için birden fazla RNG parçası kullanın.

4) Tarihteki sonuca karşı kontrol edin

Site, hesaplamada kullanılan girdilerin aynısını göstermelidir: 'server _ seed', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternatif/Kazanç: VRF (Doğrulanabilir Rastgele Fonksiyon)

Bir taahhüt yerine, operatör (veya isteğe bağlı olarak) VRF'yi kullanabilir:

1. Akıllı bir sözleşme veya kamu sicili, sağlayıcıdan 'VRF (tohum)' ister.

2. Tarafından yayınlandı '(random, proof)'.

3. Herkes aynı genel VRF anahtar çifti tarafından 'kanıtı' kontrol edebilir.

4. Ardından, aynı RNG eşlemesi sonuca adım atar.

Artılar: Operatöre daha az güven. Dezavantajları: VRF sağlayıcısına/zincirine bağımlılık ve olası maliyet.

Bir kumarhane PF'yi nasıl doğru bir şekilde uygulamalıdır?

Sözleşme (PF veri sözleşmesi)

Yuvarlak tarihteki kenar boşlukları:

'ServerSeedHash', 'serverSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer', 'proofUrl' (опц.) , 'calcVer'.
Değerler - WORM depolamada (değişmez), zaman damgaları (UTC) ile.

Tohum üretimi

'server _ seed', kriptografik PRNG (OS CSPRNG/HSM) tarafından oluşturulur.

Sids asla seri (rotasyon) arasında tekrarlanmamalıdır.

'client _ seed' - oyuncu tarafından seçilir veya müşteri tarafından oluşturulur ve onaylanır.

Yayınlama taahhütleri

Taahhütler bahislerden önce kullanılabilir (geçmiş, RSS, zincir-çapa).

Lots için, günlük yayınlanan kök ile commit merkley ağacı kullanabilirsiniz.

Ortaya çıkarmak

Sonucu yayınlamadan önce, 'server _ seed' genişletilir ve günlüğe kaydedilir.

Bir koltukta bir dizi tur için - serinin bitiminden sonra açıklama (politikayı önceden belirtin).

Saydam eşleme

Haritalama algoritması sürümü ('mappingVer') sabittir.

Herhangi bir değişiklik ('mappingVer'/' rngAlgo') - sadece bir duyuru ve yeni bir taahhüt serisi ile.

Denetim ve anlaşmazlıklar

Ham girişler + hesaplama kaydı kaydedildi; Tartışırken bir rapor oluşturulur: girdiler - RNG - haritalama - sonuç.

Akışlar/Canlı: CV/RFID olay hash çapaları, WORM'de video depolayın.

Bir oyuncu dürüstlüğü nasıl kontrol edebilir (kontrol listesi)

1. Turun geçmişini açın ve kopyalayın: 'ServerSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. Hash 'serverSeedReveal' değerini sayın ve 'serverSeedHash'ile karşılaştırın.

3. Belirtilen algoritmaya göre RNG'yi hesaplayın (HMAC/Hash + girişleri).

4. Sonuç sayısına "tarafsız" haritalama (reddetme örneklemesi) uygulayın.

5. Sonucun gösterilenle aynı olduğundan emin olun.

6. VRF bildirilirse, 'prova' ("Doğrula" düğmesi veya bağımsız komut dosyası/blok gezgini) seçeneğini işaretleyin.

Tipik hatalar (anti-desenler)

'rng % N' out reddetme örneklemesi - önyargılı olasılıklar.

Gizli veya değişen 'client _ seed' (oyuncunun katılımı olmadan sunucu tarafından oluşturulur).

Bahisten sonra 'server _ seed'in yeniden oluşturulması (değişiklikleri geriye dönük olarak taahhüt edin).

Opak algoritma sürüm/yayın olmadan değişir.

Seriler arasındaki kenarların tekrarı.

WORM/zaman damgalarının eksikliği - olayların sırası kanıtlanamaz.

PF ve iş mantığını karıştırma (örneğin, bonus, sonuç alanını değiştirecek şekilde uygulanır, ancak bu 'mappingVer'de açıklanmamıştır).

SSS (kısa)

Sadece rulet değil, yuvaları kontrol etmek mümkün mü?

Evet. PF, seçim sırasına uygulanır (örneğin, makaradaki sembol dizini). RNG olasılık tablolarının ve okuma sırasının belgelenmesi önemlidir.

Ve eğer 'client _ seed'imi girersem, operatör hala' server _ seed'i 'alabilir'mi?

Eğer taahhüt tekliften önce yayınlanmadıysa. 'Server _ seed'i düzeltir ve geriye dönük olarak değiştirilmesine izin vermez.

Neden bazen partiler halinde tarafları ortaya çıkarıyorlar?

Böylece serideki tohumu "ayırmak" mümkün değildi. Bu, taahhüt önceden yayınlanırsa ve açıklama politikası şeffafsa kabul edilebilir.

Mini referans formatları

Hash: SHA-256 veya Keccak-256.

RNG: HMAC-SHA256 veya bitiştirme SHA-256.

Tanımlayıcılar: 'RoundId' (UTC-stamp + oyun + artış), 'nonce' (serideki bahis sayacı).

Версии: 'rngAlgo = HMAC-SHA256 @ 1', 'mappingVer = rulet. v2 ',' calcVer = cüzdan-7. 2`.

Operatör PF Uygulama Kontrol Listesi

Kriptografi ve Sids

CSPRNG/HSM; Benzersiz 'server _ seed', belgelenmiş rotasyon.
'client _ seed' - oyuncu tarafından kontrol edilir, tarihte kaydedilir.

Yayınlar ve depolama

Bahisleri taahhüt eder, tarih/yayın kanalı/çapa erişim.
WORM depolama, UTC pulları, ölçekler için merkley partileri.

Algoritmalar

RNG ve önyargısız haritalama; 'rngAlgo/mappingVer'.
Komut dosyası/sayfa "Dürüstlüğü kontrol et" (açık kaynak istenir).

Canlı ve Hibrit

CV/RFID/yuvarlak fazlı hash çapaları, "bahis penceresi kapatıldığında" günlüğe kaydedin.
Anlaşmazlık prosedürleri (vkhodov ^ iskhod report, links to commits/VRF).

Güvenlik ve denetim

PF protokolünün bağımsız denetimi, bug bounty.
Karar günlükleri değişmezdir; Düzenli tekrar testleri.

Kanıtlanabilir Adil,'bize güvenin'i "kendiniz kontrol edin'e dönüştürür. "Commit/revil veya VRF, deterministik RNG ve doğru ofset olmayan haritalama ile herhangi bir tur tekrarlanabilir ve doğrulanabilir hale gelir. Bir oyuncu için bu şeffaflık ve güvendir. Operatör için - daha az tartışma, daha güçlü marka ve yasal gerekliliklere uygunluk. Önemli olan disiplindir: önceden taahhütleri yayınlayın, algoritmaların sürümlerini düzeltin, kanıtları her zaman saklayın ve kullanıcıya basit bir doğrulama aracı verin.