Provably Fair RNG Açıklandı: Tam Teknik Rehber (2026)

Provably Fair Rastgele Sayı Üretimi Açıklandı (2026)

Az önce bir kripto zar oyununda 0.5 BTC bahis koydunuz. Ekran 37.42 gösteriyor ve kaybediyorsunuz. Adalet panelini açıyorsunuz ve sunucu seed'i hash'ı, istemci seed'iniz ve nonce gösteriyor — hiçbir şeyin manipüle edilmediğini "kanıtlayan" dört değer. Peki bu dört değer nasıl 37.42'ye dönüştü? Rastgele hex karakterleri gerçekte nasıl belirli bir zar sonucuna çevirdi?

İşte burada önemli: tüm "Provably Fair" vaadi bir belirli işlem üzerine kurulu — kriptografik hash çıktısını oyun sonuçlarına dönüştürmek. Bu dönüştürmenin nasıl çalıştığını kaçırırsanız Provably Fair büyüyü andıran pazarlama gibi hissettiriyor. Bunu anlarsanız herhangi bir PF casino'yu yaklaşık 60 saniyede denetleyebilir, sahte uygulamaları bir bakışta görebilir ve protokolün tam olarak hangi saldırılara karşı dirençli olduğunu bilebilirsiniz.

Bu rehber size Provably Fair rastgele sayı üretimi'ni bir geliştirici 2026'da nasıl yapacaksa öyle gösteriyor — kapının altındaki CSPRNG ilkel işlevleri, seed'leri sayılara dönüştüren HMAC-SHA256 formülü, zar, crash ve kartlar için farklı eşleme şemaları, ve matematik kusursuz olsa bile ayakta kalan saldırı yüzeyi. Sonunda PF RNG'lerin neden kriptografik olarak kırılamaz olduğunu, hangi uygulama hatalarının onları mahvettiğini ve blockchain rastgeleliğinin (Chainlink VRF) ne zaman devreye girdiğini bileceksiniz.

Özet — PF RNG'ler Gerçekte Sayıları Nasıl Üretir

Her Provably Fair oyun aynı çekirdek RNG ilkelini kullanır, yalnızca çıktı eşlemesi değişir. İşte 60 saniyelik versiyon.

Matematik şu:

$\text{outcome} = f\big(\text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} : \text{nonce})\big)$

Burada f oyuna özel eşleme fonksiyonu — f_dice 0-99.99 döndürür, f_crash çarpan döndürür, f_cards karıştırılmış deste pozisyonlarını döndürür. HMAC parçası dünyadaki her PF casino'da aynıdır.

Bilmeniz Gereken Kilit Sayılar

• 3 giriş: sunucu seed'i + istemci seed'i + nonce her sonucu üretir
• 64 hex karakter: SHA-256 / HMAC-SHA256 çıktısının uzunluğu
• 128 hex karakter: HMAC-SHA512'nin uzunluğu (BC.Game ve PF blackjack tarafından kullanılır)
• ~2^256 işlem: HMAC-SHA256'yı kırmak için gerekli — astronomik olarak ulaşılamaz
• 0.00-99.99: eşlemeden sonra standart zar aralığı
• 1.00x to ∞: standart crash çarpanı aralığı (pratikte float kesinliği tarafından sınırlı)

Adil ≠ Kârlı

RNG'nin Provably Fair olması sana casino'nun bahis koyduktan sonra sonucu manipüle edemeyeceğini söyler. Bu size şunları söylemez:

• Ev avantajının makul olup olmadığı (RTP'yi ayrı kontrol et)
• Casino'nun çekilişleri onaylatıp onaylamayacağı
• Bonuslar ve bahis terimlerinin dürüst olup olmadığı
• Sunucu seed havuzu taahhüt edilmeden önce tarafsız olup olmadığı

Tüm saldırı yüzeyini aşağıda ele alacağız. Geleneksel sertifikalandırma ile daha geniş bir karşılaştırma için bkz. Provably Fair vs RNG Sertifikalı rehberi.

Bir RNG'yi "Provably Fair" Yapan Nedir?

Formüle geçmeden önce Provably Fair'i daha geniş RNG dünyasından ayırmak yardımcı olur. PF, CSPRNGs'nin yerine geçen bir değil, belirli bir yükseltmedir.

Taahhüt-Ortaya Çıkar İlkeli

Provably Fair'in arkasındaki tüm numara taahhüt-ortaya çıkar adlı kriptografik bir desendir.

Round başlamadan önce casino SHA-256 hash'ini yayınlayarak belirli bir sunucu seed'ine taahhüt eder. Hash, seed'i ortaya çıkarmadan onu benzersiz olarak tanımlayan 64 karakterlik bir parmak izi. SHA-256'nın pratik çarpışma saldırıları olmadığı için casino daha sonra aynı hash'i üreten farklı bir seed bulamaz — kilitlenirler.

Round sonrasında (veya seed'lerinizi döndürdükten sonra) ham sunucu seed açıklanır. Siz bunu kendiniz hash'lersiniz. Hesapladığınız hash, round başlamadan önce yayınlananla eşleşiyorsa casino seed'leri turda değiştirilmediğini kanıtladı. İstemci seed'iniz (önceden bilmedikleri) ile birleştirildiğinde bu, turda sonuç manipülasyonunu kriptografik olarak imkânsız hale getirir.

Taahhüt-ortaya çıkar katmanı PF'yi diğer CSPRNG'den ayıran şeydir. Geleneksel RNG-sertifikalı bir casino de CSPRNG kullanır — ancak hiçbir şey iTech Labs denetimlerinin yalnızca istatistiksel özellikleri kanıtladığı için produksiyonda onu değiştirilmesini engellemez.

HMAC'ı RNG İlkeli Olarak

HMAC-SHA256, her PF turda gerçek rastgele sayı üretecidir. İşte neden çalışır:

• Deterministic: Aynı girdiler verildiğinde HMAC her zaman aynı çıktıyı üretir. Bu seni doğrulamayı sağlayan şeydir.
• Tek yön: Çıktı verildiğinde sunucu seed'ini (anahtarı) kurtaramazsın. Bu sonucu tahmin edilemez yapan şeydir.
• Düzgün: HMAC çıktıları rastgele 256-bit string'lerden ayırt edilemez. Bu oyunu tarafsız yapan şeydir.
• Anahtarlı: Sunucu seed çıktıyı tekrar üretmek için bilinmesi gereken bir sır olarak hareket eder. Bu manipülasyonu önleyen şeydir.

Teknik olarak HMAC-SHA256 kendi başına bir CSPRNG değildir — bu bir mesaj kimlik doğrulama kodudur. Fakat anahtar (sunucu seed'i) gerçek bir entropi kaynağından oluşturulduğunda, yapı pratik amaçlar için bir CSPRNG'ye eşdeğerdir. NIST bunu SP 800-90A Rev 1'de HMAC_DRBG olarak resmiyet verdi ve PF casino'lar bu standardı temel olarak halka açık seed taahhütü eklenerek yeniden uygularlar.

CSPRNGs Neden Önemlidir (Math.random() Değil)

Her meşru PF casino sunucu seed'ini kriptografik olarak güvenli bir RNG ile oluşturur — JavaScript'in Math.random()'u değil. Fark çoğu oyuncunun fark ettiğinden daha önemlidir:

Eğer bir casino gizlice sunucu seed'ini Math.random() ile tohumlarsa, sofistike bir saldırgan yeterli halka açık çıktılardan seed'i yeniden oluşturabilir ve her gelecek turnu tahmin edebilir — HMAC matematik kusursuz olsa bile. İşte bu yüzden casino'nun gerçekten crypto.randomBytes veya eşdeğerini kullandığını kontrol etmek önemlidir; Provably Fair oyunları nedir açıklayıcısı güven zincirininin tamamını kapsar.

Sayı Aslında Nasıl Üretilir

Şimdi gerçek formül. Bu bölüm yer imlerine değer — yukarıdaki her şey bağlam bilgisiydi.

Üç Giriş, Bir Formül

Her provably fair turun şunu hesaplar:

$\text{hex\_output} = \text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} \; : \; \text{nonce})$

Sözde kodda:

function pfHmac(serverSeed, clientSeed, nonce) {
  const message = clientSeed + ':' + nonce
  const hex = hmacSha256(serverSeed, message)  // 64-karakterlik hex string
  return hex
}

: iki nokta üstüste, Stake, Primedice, Rainbet ve çoğu PF kasinoda kanonik ayırıcıdır. Birkaçı (BC.Game, Roobet) farklı ayırıcılar kullanır — tam format için her zaman kasinolar fairness belgelerini kontrol edin.

Çıktı, 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d gibi 64 karakterlik bir onaltılık dizedir. Bu hex, saf rastgeleliktir — 256 bit tahmin edilemezlik, istatistiksel olarak 256 adil para atışından ayırt edilemez.

Adım Adım: HMAC Çıktısından Zar Atışına

Bir turu sondan sona yapalım.

Verilen değerler:

• server_seed = f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• client_seed = player-xyz-42
• nonce = 7

Adım 1 — HMAC'ı Hesapla:

HMAC-SHA256(server_seed, "player-xyz-42:7")
= 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d

Adım 2 — İlk 5 hex karakterini kes:

8b2d4 → onluk sisteme çevir → 569.300

Adım 3 — 0-99.9999 aralığına eşle:

dice = (569_300 % 1_000_000) / 10_000
     = 569_300 / 10_000
     = 56.93

Adım 4 — Bahis mantığını uygula:

"50'nin altında at" bahsi yaptıysan → kaybedersin (56.93 > 50). "60'ın altında at" bahsi yaptıysan → kazanırsın. Tam zar atışı bu üç giriş birleşir birleşmez belirlenmiştir, hiçbir UI animasyonu çalışmadan önce.

Adım 5 — Doğrula:

Turun ardından, açığa çıkarılan server_seed'i alırsın. SHA-256 ile hash et — önceden taahhüt edilen hash eşleşiyor mu? Tamam. 1-3 adımlarını tekrar çalıştır — 56.93'ü yeniden oluşturdun mu? Tamam. Tur kriptografik olarak adil olduğu ispatlanmış.

Kopyala-yapıştır değerleri ve ekran görüntüleriyle tam bir anlatım için bkz. bir provably fair turu nasıl doğrulanır.

Farklı Oyunlar, Farklı Eşlemeler

HMAC çağrısı her zaman aynıdır. Değişen şey adım 3 — hex'in belirli bir oyun sonucuyla nasıl eşleştirildiği.

Her eşleme, çıktı aralığında tekdüze olacak şekilde tasarlanmıştır — tekdüze rastgele bir hex değeri üzerinde modüler aritmetik, tekdüzeliği korur. Bu nedenle PF oyunları, kasino bireysel turları manipüle etmeden dürüst RTP talep edebilir. Eşleme formülü, random sayının kendisi değil, kasinolar tarafından hedef ev avantajını karşılamak için ayarlanır.

Hex Dizesinden Oyun Sonucuna (Matematiğiyle)

Zar eşlemesi, ayrıştırmaya değerdir çünkü en açık durum — ve provably fair zar dağılımlarının doğru şekilde uygulandığında neden gerçekten tekdüze olduğunu gösterir.

Zar Eşlemesi (0-99.9999)

Stake'in zarı ilk 5 hex karakterini kullanır, bu da 20 bit = 1.048.576 olası değer verir. Eşleme şu şekildedir:

$\text{dice} = \frac{(\text{int}(\text{hex}_{0:5}) \; \text{mod} \; 10^6)}{10^4}$

Dilim 1.048.575'e ulaşabiliyorsa neden modulo 1.000.000? Modulo olmadan, 1.000.000-1.048.575 değerleri 100.0000-104.8575'e eşlenirdi, zar aralığının dışında. Modulo bunları geri katlıyor — ama küçük bir önyargı ekliyor (0-48.575 değerleri, 48.576-99.999'dan 2/1 faktörü kadar daha olasıdır). Önyargıyı ortadan kaldırmak için, gerçek uygulamalar 1.000.000'dan büyük dilimleri reddeder ve sonraki hex bloğuna ilerler (karakter 5-10, sonra 10-15, vb.).

Doğru yapılırsa, bu 0.0000-99.9999 arasında mükemmel bir tekdüze dağılım üretir. 10.000 zarı test, essansiyel olarak düz kaplama gösterir — aşağıdaki histogram, herhangi bir yasal PF zar uygulamasıyla göreceğiniz şeyi yeniden üretir.

Crash Eşlemesi (Çarpan)

Crash daha ilginçtir çünkü çıktı tekdüze değildir — dramatik oyun oynaması yaratmak ve hedef ev avantajını korumak için kasıtlı olarak eğrilmiştir.

$\text{crash} = \frac{\left\lfloor \dfrac{100 \cdot 2^{52} - h}{2^{52} - h} \right\rfloor}{100}$

Burada h = int(hex[0:8]) (ilk 8 hex karakterden 32-bitlik bir tamsayı). Bir değişiklikle: eğer h mod 33 == 0 ise, çarpan 1.00x'tir (anında patlar), bu da Stake'in ~%1 ev avantajını oluşturur. Diğer kasinolar farklı bölenler kullanır — 25 (Rainbet ~%4 avantaj), 50 (düşük avantaj varyantları), 100 (çok düşük avantaj).

Bu formülü bir milyon kez çalıştır ve ~%50 turun 2x'nin altında patladığı, ~%10 10x'i geçtiği ve belki %1 100x'e ulaştığı bir dağılım alırsın. Beklenen değer, bahis başına 0.99 olur — eksik olan %1, per-tur manipülasyona değil formül sabitlerindeki ev avantajıdır.

Kart Eşlemesi (Güverte Karıştırmaları)

PF blackjack, poker ve baccarat, HMAC-SHA512 (daha uzun çıktı = hash çağrısı başına daha fazla kart) kullanarak sanal güverteler karıştırır. Fisher-Yates karıştırması standarttır:

for i = 51 down to 1:
  j = hmac_int(i) mod (i + 1)
  swap(deck[i], deck[j])

Her hmac_int(i) çağrısı, 128 karakterlik SHA-512 çıktısının 4 hex karakterini tüketir. Bir turun kartları tamamen bir HMAC çağrısıyla belirlenir, bu nedenle sıklıkla doğrulama panelinde 13+ ondalık dönüştürülmüş tamsayılar görsün — her kart takası başına bir. Stake ve BC.Game'de belirli uygulama için bkz. provably fair blackjack rehberi.

Geleneksel RNG vs Provably Fair RNG

RNG düzeyinde özelde (daha geniş adalet yığınından değil), PF sertifikalı CSPRNG'nin kesin bir üst kümesidir.

Geleneksel RNG'ler Nerede Başarısız Olur

eCOGRA, iTech Labs ve GLI'den sertifikalı RNG'ler hepsi kriptografik olarak güvenlidir — matematik PF'nin kadar güçlüdür. Sorun primitifde değil, çalışma zamanı güven modelinde:

• Sertifikalı RNG, casino'nun sunucusunda yaşar, bir kez denetlenir
• Çıktısını asla doğrudan görmezsiniz, sadece oyunun son durumunu görürsünüz
• Hiçbir şey casino'yu üretimde sertifikalı kodu çalıştırmaya zorlamamaz
• Tur başına bir anlaşmazlık gerçek zamanda çözülemez

Pragmatic Play'in sertifikalı slot motoru sessizce Roobet'in üretiminde eCOGRA'nın test ettiğinden farklı bir RNG çalıştırırsa, hiçbir sertifika kontrolü bunu yakalamaz. Boşluk yalnızca tur başına açık doğrulama ile kapanır.

PF'nin Primitive'e Eklediği Şey

Provably Fair aynı kriptografik temeli alır ve bunu açığa çıkarır. Özel olarak:

• Sunucu seed hash'i bahsinizden önce yayımlanır (taahhüt)
• İstemci seed'iniz HMAC girişine katkıda bulunur (birlikte imzalama)
• Ham sunucu seed'i tur sonra açığa çıkarılır (açıklama)
• Hesaplama deterministiktir ve herhangi bir tarayıcıda yeniden üretilebilir (doğrulama)

Bu tamamen farktır. Aynı HMAC, aynı CSPRNG matematiği — üzerine yerleştirilmiş dört ekstra şeffaflık adımı ile. Her iki modelin nasıl karşılaştırıldığı hakkında daha derinlemesine bir anlatım için bkz. provably fair vs RNG certified.

Blockchain Randomness — Chainlink VRF ve Onchain Oyunlar

PF RNG merkezileştirilmiş kripto casino'ları güzel bir şekilde kapsar. Peki ya tamamen merkezi olmayan uygulamalar — onchain piyangolar, NFT özellik ataması, onchain zar? İşte bu noktada farklı bir çözüm devreye girer.

Blockchainler Neden Güvenli Rastgele Sayılar Üretemez

Her blockchain tasarımı gereği deterministiktir — her doğrulayıcı aynı girdilerden aynı durumu üretmelidir, aksi takdirde fikir birliği bozulur. Bu rastgeleliği yapısal olarak zorlaştırır:

• block.timestamp madenci tarafından birkaç saniye içinde kontrol edilebilir
• block.blockhash madenler tarafından blok tutarak manipüle edilebilir
• block.prevrandao (Merge sonrası Ethereum) daha iyidir ancak yine de doğrulayıcılar tarafından sapma yapılabilir
• Herhangi bir onchain entropi kaynağı, kullanılmadan önce kontrat tarafından okunabilir, amacı bozar

Blockhash kullanan naif dApp piyangolar geçmişte boşaltılmıştır. 1 milyon dolarlık bir jackpot'u manipüle etme ekonomik teşviki bir madenciyi rasyonel olarak bir blok tutmaya yapabilir.

Chainlink VRF Nasıl Çözer

Chainlink VRF (Verifiable Random Function) rastgeleliği çevrimdışı üretir ve bunu kriptografik bir kanıt ile onchain'e sunmuştur. Akış:

1. Akıllı kontrat bir rastgele sayı talep eder
2. Chainlink oracle değeri çevrimdışı olarak özel anahtarı + talep seed'i kullanarak üretir
3. Kanıt, oracle'ın genel anahtarına karşı herkesin doğrulayabileceği bir BLS imzasıdır
4. Hem değer hem de kanıt tek bir işlemde onchain'e geri gönderilir
5. Kontrat değeri kullanmadan önce kanıtı doğrular

Kritik özellik: kanıt rastgele değeri oracle'ın özel anahtarına ve talep seed'ine bağladığı için, oracle uygun değerleri seçemez. Herhangi bir sapma matematiksel olarak tespit edilebilir.

VRF vs HMAC Tabanlı PF Ne Zaman Kullanılır

2026'da çoğu kripto casino HMAC tabanlı PF kullanmaya devam ediyor çünkü hızlı, ucuz ve zaten iyi anlaşılmış. VRF, onchain DeFi, NFT'ler ve tamamen merkezi olmayan oyunlaştırmanın parladığı yerdir. Provably fair Bitcoin oyunları sıralamamız özel olarak her casino'nun hangi PF uygulamasını kullandığına göre filtreler. Bu kavramları canlı bir kumarhanede stres testine tabi tutmak istiyorsanız provably fair dizini yatırım yapmadan inceleyebileceğiniz uygulamaları listeler — çoğu, server-seed hash'lerini açık bir uç noktada yayınlar.

Provably Fair RNG'ların Saldırı Yüzeyi

Kriptografik olarak mükemmel bir Provably Fair RNG bile kötü implementasyon ile kırılabilir. İşte matematiği geçenler.

Önyargılı Seed Pool Saldırısı

En gerçekçi saldırı — ve client seed rotasyonunun önemli olmasının bir nedeni.

Dürüst olmayan bir casino, binlerce aday sunucu seed'ini önceden üretir. Her biri için, yaygın client seed pattern'lerine karşı sonuçları hesaplarlar (varsayılan tarayıcı formatları, sık kullanılan kelimeler). Yalnızca tahmin edilebilir client seed'lerine karşı daha fazla kayıptan kazanç üretecek seed'leri yayınlarlar.

Her yayınlanan seed, önceden taahhüt edilen hash'ine doğru şekilde hash'lenir. Commit-reveal matematiği geçer. Fakat mevcut seed'lerin havuzu, hiçbir oyuncu onları görmeden önceden elendi ve uzun vadeli house edge, belirtilen RTP'yi sessizce aşar.

Rotasyon Bunu Neden Yendiği

Önyargılı seed saldırıları, casinonun server seed'i taahhüt etmeden önce gelecekteki client seed'inizi bilmesini gerektirir. Her 50-100 bahis'te client seed'inizi döndürün ve casinonun ön-hesaplaması işe yaramaz hale gelir — yeni client seed'i bilmeden sunucu seed'i taahhüt ettiler, bu nedenle sonuçları yönlendiremezler.

Bu, meşru casinoların anında rotasyon yapmanıza izin vermesinin nedenidir. Client seed rotasyonu reddeden (veya client seed'i kendi takvimlerinde otomatik olarak yeniden oluşturan, sizin takvimde değil) bir PF casino, saldırı yüzeyinin açık olduğunu işaret ediyor. Client seed vs server seed rehberi tam rotasyon iş akışını kapsar.

Zayıf Entropi Kaynakları

Sunucu seed üretimi tahmin edilebilir entropiye kullanılırsa, commit-reveal protokolü yine de çalışır ancak saldırgan seed'leri tahmin edebilir.

Math.random Tuzağı

JavaScript'in Math.random() doğrusal bir uyumlu üreteci varyasyonudur. Yaklaşık 700 ardışık çıktıyı gözlemledikten sonra, saldırgan tam iç durumu yeniden yapılandırabilir ve sonraki her çıktıyı tahmin edebilir. Bir PF casino sunucu seed üretimi için Math.random kullanırsa:

1. Saldırgan 700+ tur oynar, her açıklanmış sunucu seed'i toplar
2. Saldırgan PRNG durumunu yeniden yapılandırır
3. Saldırgan taahhüt edilmeden önce sonraki hash'lenmiş sunucu seed'i tahmin eder
4. Saldırgan sonucun tam bilgisini kullanarak bahis oynar

Önleme: casinolar crypto.randomBytes(32) (Node.js), crypto.getRandomValues(new Uint8Array(32)) (tarayıcı) veya donanım RNG kullanmalıdır. Fark bir kod satırıdır ama güvenlik boşluğu tamtamdır.

İmplementasyon Uyarı İşaretleri

Bir Provably Fair RNG'nin güvenli olmadığını gösteren kısa kontrol listesi:

• Client seed rotasyon düğmesi yok, veya rotasyon >5 saniye alıyor
• Client seed casino tarafından kendi takvimlerinde otomatik olarak yeniden üretiliyor
• Sunucu seed geçmişi algoritm veya dilim genişliğini göstermiyor
• Doğrulama aracı yalnızca casinonun kendi web sitesinde çalışıyor (yerel olarak değil)
• Yayınlanan hash algoritması yok — "bir yerde SHA-256" yeterli değil; tam formülü gerekli
• Açıklanmış sunucu seed'ler herhangi bir turda önceden taahhüt edilen hash'leriyle eşleşmiyor

Bu işaretlerden herhangi biri, Provably Fair iddiasının normal bir RNG'nin üstüne pazarlama cilası olduğunu önerir. Hangi casinoların fiilen Provably Fair kodlarını yayınladığını yan yana görmek için provably fair Bitcoin oyunları sıralamasına bakın.

Kendiniz Deneyin — İnteraktif Doğrulayıcı

Matematik soyut olmaktan çıkıyor, onu kendi seed'lerinizde çalıştırır çalıştırmaz. Casinonuzun adalet panelinden herhangi dört değeri aşağıdaki doğrulayıcıya yapıştırın — her şey Web Crypto API aracılığıyla tarayıcınızda yürütülür, hiçbir veri sunucumuza gönderilmez.

Pratik bir ipucu: elinizde gerçek bir PF casino bahsi yoksa, doğrulanmış bir turu görmek için bu tek kullanımlık test değerlerini deneyin:

• Sunucu seed hash: bf3c0a9b0f4b3c8e8f4f0c5f0c4e8b7d8f3e2a1c9f6e3b7c4d5a8e2f9b1c6d3a (yalnızca örnek — gerçek hash'lerle eşleşmez)
• Sunucu seed: f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• Client seed: demo-player
• Nonce: 1

Sonuç, hash eşleşmesi artı yeniden yapılandırılmış dice ve crash sonuçlarında GEÇTI / BAŞARISIZ kararını gösterir. Aynı mantık Aviator provably fair hesaplayıcı adlı Spribe'ın crash tarzı oyununda çalışır ve tam doğrulayıcımız provably fair merkezi tüm ana akım PF casinoları kapsar. Bilinen bir RTP'ye karşı bahis boyutlandırmak için RNG'nin meşru olduğunu doğruladıktan sonra, RTP hesaplayıcı, house edge hesaplayıcı ve bankroll hesaplayıcı ile eşleştirin.

Özetle: matematik ancak kumarhane bahisten önce hash'i gerçekten yayınlarsa kurşun geçirmez olur. Her uygulamayı provably fair merkezi ile tekrar doğrulayın — her mekanın seed'i doğru kilitleyip kilitlemediğini ve hash'i nerede açtığını not ediyoruz.

SSS