İşin püf noktası, bir paragrafta
Kriptografik bir hash, herhangi bir girdiyi iki önemli özelliği olan sabit uzunlukta bir parmak izine dönüştürür: parmak izinden geriye doğru girdiyi bulabilirsiniz ve aynı parmak izine sahip iki girdi bulamazsınız. Yani birisi size bugün bir sırrın parmak izini ve yarın sırrı gösterse, sırrı hash'leyebilir ve eşleşip eşleşmediğini kontrol edebilirsiniz. Eşleşirse, gösterdikleri sır dünkü sırlardır. Arada değiştiremezlerdi, çünkü farklı bir sırın farklı bir parmak izi olurdu ve sırrı parmak izine uyacak şekilde seçemezlerdi, çünkü bu hash'i tersine çevirmek anlamına gelirdi.
Bu bir taahhüt şemasıdır ve "provably fair" in tüm kriptografik içeriğidir. Ev bir sunucu tohumu üretir, SHA-256 hash'ini yayınlar, tohum tarafından türetilen turları oynar ve çifti emekli olduğunda tohumu ortaya çıkarır. Diğer her şey sadece altyapıdır.
ENGINE-VERIFIED_shared/seedApi.ts: getRandomKey returns {serverSeedHashed, clientSeed, nonce}; renewRandomKey returns a fresh pair together with previousServerSeed and previousServerSeedHashed, the reveal. _shared/SeedPanel.tsx labels the field “server seed (sha-256 commitment)”. _shared/rng.ts: sha256Hex() computes the fingerprint and hmacSha256Utf8() the per-round hash, with the comment that the demo engine “GENERATES outcomes with the same primitives the verifier uses to CHECK them — one implementation, so the demo can never drift from what the verifier accepts”.
Kanıtladığı üç şey
| İDDİA | NEDEN TUTUYOR | KONTROL |
|---|---|---|
| Sunucu tohumu bahislerinizden önce belirlenmişti | Tohuma yapılacak herhangi bir değişiklik onun hash'ini değiştirecekti ve hash ilk turdan önce gösterilmişti | Oynamadan önce seed panelindeki taahhüdü göz önünde bulundurun |
| Ortaya çıkarılan tohum taahhüt edilen olandır | Farklı bir tohum aynı SHA-256 parmak izini üretemez | Ortaya çıkarılan tohumu hash'leyin; not ettiğiniz taahhütle karşılaştırın |
| Her sonuç tohum çiftinden ve tur numarasından kaynaklanır | Sonuç HMAC-SHA256(sunucu tohumu, "istemci tohumu-nonce-imleç") olarak hesaplanır ve oyunun yayınlanan türetilmesinden geçirilir | Dört girdiden tur'u tarayıcıda yeniden hesaplayın; panel bunu sizin için yapar |
Üç kontrolün hepsi yereldir: ortaya çıkarılan tohum, istemci tohumu, nonce ve türetme kodu gereklidir ve kontrol sırasında evden hiçbir şey gerekmez.
Üçüncü talep, bir oyuncu için işi yapan ve genel türetilmeye bağlı olan taleptir. Tohum hash'i size tohum nasıl bir zar atışı veya kart haline geleceği hakkında hiçbir şey söylemez. Burada bu işlev istemcide bulunur, demo'nun sonuçları üretmek için kullandığı ve doğrulayıcının bunları kontrol etmek için kullandığı aynı kod, bu nedenle yeniden hesaplanan bir tur, sunucunun kendini doğrulamasını talep etmekten ziyade gerçek bir yeniden hesaplamadır.
ENGINE-VERIFIED_shared/demoLocal.ts: uAt() tur-u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)) olarak tur-u64 türetir, sunucu üzerinde RandomUtils.generateHash ile eşleştiği açıklanır; _shared/rng.ts HMAC'ın ilk yedi baytını "sunucunun Long→Double yuvarlama bit-for-bit ile eşleşen" [0, 1) aralığında tek tip bir sayıya dönüştürür. Her oyunun türev modülü daha sonra bu sayıyı bir rulo, bir kart veya bir çarpana eşler.
Doğrulama yönergesi gerçek bir turda üç adımın tümünü gerçekleştirir. Bunu hiç yapmadıysanız, bir kez yapın; şemanın noktası her turu kontrol etmek değil, herhangi birini kontrol edebilmeniz ve ev hangi turu kontrol edeceğinizi önceden söyleyememesidir.
Kanıtlayamadığı üç şey
Seed'in rastgele olduğunu kanıtlayamaz. Bir taahhüt bir seed'i sabitler; seed'in nasıl seçildiğini söylemez. Ev, sunucu seed'ini oluştururken sizin istemci seed'inizi bilseydi, prensipte seed'leri ilk turları hoşuna gidene kadar oluşturabilir ve o seed'e taahhüt edebilirdi. Hash tam olarak kontrol edilirdi. Standart savunma sıralamadır: sunucu seed'i önce taahhüt edilir ve istemci seed'i daha sonra ayarlanır, böylece ev ne taahhüt ederse etsin, ne ile birleştirileceğini bilmemiştir.
Bu sıralama, bu sitenin panelinin açıkça belirtilmeye değer bir sınırının bulunduğu yerdir. Burada bir istemci seed'i ayarlamak mevcut sunucu seed'ini yerinde bırakmaz; çifti döndürür ve yeni sunucu seed'i yeni istemci seed'inizi taşıyan aynı istekle oluşturulur. İstemciden yeni seed'in istek okunmadan önce sabitlendiğini göstermek mümkün değildir. Sunucunun bir sonraki seed'i önceden oluşturup oluşturmadığı (bazı operatörlerin bir sonraki taahhüdü önceden yayınlayarak yaptığı gibi) istemcinin API'sinde görülmez ve kontrol etmek için "sonraki sunucu seed hash'i" alanı yoktur. Bu, oyun ekibine iletildi ve düzeltme küçüktür: sonraki sunucu seed'e taahhüt edin ve onunla eşleştirilecek istemci seed'i kabul edilmeden önce bu taahhütü panelde gösterin.
ENGINE-VERIFIED_shared/seedApi.ts: setClientSeed(clientSeed) yeni istemci seed'i ile renewRandomKey'i çağırır ve nonce 0'da yeni bir çift döndürür; rotate() aynı endpoint'i seed olmadan çağırır. IHouseSeed serverSeedHashed, clientSeed ve nonce taşır, artı dönüşte önceki çift; type'da sonraki seed taahhüdü yoktur.
O zamana kadar, savunmanın pratik versiyonu, şemanın diğer her yönde size zaten verdiği şeydir: açıklama. Seed'leri sizin istemci seed'inize karşı öğütleyen bir ev, yine de her seed'i dönüşte açıklamak ve bunun altında her tur yeniden hesaplanabilir. Sınırın anlamı, seed değişikliğinden sonraki ilk turlardaki şüpheli bir dizilişin hash yalnızca tarafından dışlanamaması; sadece açıklama sonrasında, tur tur tur incelenebilir.
Oyunun diğer anlamda adil olduğunu kanıtlayamaz. "Provably fair" rastgeleliğin dürüst olduğu anlamına gelir, oranların eşit olduğu değil. Bir zar oyunu mükemmel şekilde doğrulanabilir ve yine de tasarım gereği %99 döndürebilir; kenar ödeme tablosunda yaşar, bu yayınlanan bir sayı ve ayrı bir vaattir. Ev kenarının etiği o vaadin hakkında. Taahhüt konusunda sessizdir.
Hiç kimsenin kontrol etmediği turlar hakkında hiçbir şey kanıtlamaz. Şema bir garanti değil, caydırıcıdır. Asla yeniden hesaplamazsınız turda, başka yerde olacağınız gibi inanç üzerine alacağınız bir turda; değişen şey, inancın isteğe bağlı olması ve ev ne zaman uygulanacağını bilemeyesidir. Bu, içini göremediğiniz bir karıştırma makinesine göre büyük bir iyileşme ve "kanıt" kelimesinin önerdiğinden daha küçük bir iyileşmedir.
Hash rastgelelik için bir makbuzdur. Oyun için bir sertifika değildir. hatırlanması gereken cümle
Daha fazla neyi kanıtlayacak
- Önceden taahhüt edilen bir sonraki seed. Sonraki sunucu seed'inin hash'ini, herhangi bir istemci seed'i onunla eşleştirilmeden önce yayınlamak, yukarıdaki sıralama boşluğunu kapatır. Panel'in seed'in sizin girdiniz bilinmeden önce sabitlendiğini kanıtlamasını sağlayan tek değişikliktir.
- Kamuya açık bir rastgelelik kaynağı. Drand ağı gibi hiç kimsenin kontrol etmediği bir işaret karıştırmak, seed'i kimin seçtiği sorusunu tamamen ortadan kaldırır; drand içinde bunun nasıl çalıştığını ve ne kadara mal olduğunu açıklar.
- Yayınlanan ve halka açık tutulan bir türev. Zaten burada böyle ve istemci yeniden yazıldığında kaybolması en kolay kısım. Doğrulayıcı, çalıştırdığı kod kadar dürüsttür.
Bu değişikliklerin hiçbiri hash'in ne olduğunu değiştirmez. Hash'in parmak izi olduğu şeyi ve ne zaman olduğunu değiştirirler. Şema yeterince basittir ve onun sınırları da öyledir, ve kanıtladığı üç şeyi bilen bir oyuncu, bunu kanıtladığını söylenenden daha iyi bir pozisyondadır.
SSS
Provably fair casinoda hash taahhüdü nedir?
Evin gizli sunucu seed'inin SHA-256 parmak izi, oyundan önce gösterilen ve seed açıklandığında kontrol edilen. Seed'in sizin bahislerinizden önce sabitlendiğini ve ortaya çıkan seed'in taahhüt edilen seed olduğunu kanıtlar.
Eşleşen bir hash oyunun adil olduğunu kanıtlar mı?
Rastgeleliğin taahhütten sonra değiştirilmediğini ve yayınlanan bir türev ile her sonucun seed çiftinden geldiğini kanıtlar. Seed'in rastgele seçildiğini kanıtlamaz ve ayrı yayınlanan bir sayı olan ev kenarı hakkında hiçbir şey söylemez.
Ev tercih ettiği bir sunucu seed'i seçebilir mi?
Yalnızca istemci seed'ini biliyorsa, seçim anında eşleştirilecek sunucu seed'ini seçebilir. Savunma, sunucu seed'ini istemci seed'i ayarlanmadan önce taahhüt etmektir. Bu sitede istemci seed değişikliği aynı istekte çifti döndürür, bu nedenle sıralama istemciden doğrulanamaz; makale sınırı ve önerilen düzeltmeyi açıklar.
Bir turunu kendim nasıl kontrol edebilirim?
Seed'i döndürerek emekli sunucu seed'ini ortaya çıkarın, taahhüdü doğruladığınız şeyle eşleştiğini doğrulamak için hash'leyin, ardından istemci seed'iniz, nonce ve cursor üzerinden sunucu seed'inin HMAC-SHA256'sını yeniden hesaplayın ve sonucu oyunun yayınlanan türetmesine geçirin. Seed paneli tarayıcınızda yeniden hesaplamayı gerçekleştirir.
Türetme kodu neden önemlidir?
Çünkü hash yalnızca seed'i sabitleyor. Seed'i bir ruloya ya da bir karta dönüştürmek bir fonksiyondur ve o fonksiyon halka açık olmadığı sürece, eşleşen bir hash, sonucun seed'in ima ettiği sonuç olup olmadığı hakkında hiçbir şey söylemez. Burada istemci, demodaki rollara sonuçları oluşturmak için kullandığı türetmeyi gönderir.
Provably fair, lisanslı RNG denetiminden daha iyi midir?
Farklı soruları cevaplarlar. Bir denetim, bir jeneratörün birçok çekilişte istatistiksel davranışını onaylar; bir taahhüt, olay sonrası belirli bir turunu kontrol etmenizi sağlar. Hiçbiri diğerinin yerine geçmez ve hiçbiri ev avantajını değiştirmez.
KAYNAKLAR & REFERANSLAR
- Wikipedia — Taahhüt şeması: gizlilik ve bağlayıcılık, ve hash tabanlı taahhütler
- Wikipedia — HMAC: anahtarlı hashing ve sözde rastgele işlev olarak kullanımı
- Betkyo motoru kaynağı: _shared/seedApi.ts (taahhüt, açığa çıkarma ve rotasyon), _shared/rng.ts (sha256Hex, hmacSha256Utf8, 7-baytlık uniform), _shared/demoLocal.ts (uAt türetmesi), _shared/SeedPanel.tsx
BU MAKALEDEKİ OYUNLARDice — kurallar & ücretsiz oyna →Limbo — kurallar & ücretsiz oyna →