Wat een hash-commitment bewijst, en de drie dingen die het niet kan

De truc, in één alinea

Een cryptografische hash zet elke invoer om in een vingerafdruk met vaste lengte, met twee eigenschappen die hier van belang zijn: je kunt niet vanaf de vingerafdruk terugwerken naar de invoer, en je kunt geen twee invoeren vinden met dezelfde vingerafdruk. Dus als iemand je vandaag de vingerafdruk van een geheim laat zien en morgen het geheim zelf, kun je het geheim hashen en controleren of het overeenkomt. Als dat zo is, is het geheim dat ze je toonden hetzelfde als dat ze gisteren hadden. Ze konden het er tussentijds niet voor hebben verwisseld, want een ander geheim zou een andere vingerafdruk hebben, en ze konden het geheim niet hebben gekozen om bij de vingerafdruk te passen, want dat zou betekenen dat ze de hash moesten omkeren.

Dat is een commitment-schema, en het is de volledige cryptografische inhoud van “provably fair”. Het huis genereert een server seed, publiceert de SHA-256-hash ervan, speelt rondes af die van de seed zijn afgeleid, en onthult de seed wanneer het paar wordt uitgefaseerd. Al de rest is bijzaak.

ENGINE-GEVERIFIEERD_shared/seedApi.ts: getRandomKey retourneert {serverSeedHashed, clientSeed, nonce}; renewRandomKey retourneert een vers paar samen met previousServerSeed en previousServerSeedHashed, de onthulling. _shared/SeedPanel.tsx labelt het veld als “server seed (sha-256 commitment)”. _shared/rng.ts: sha256Hex() berekent de vingerafdruk en hmacSha256Utf8() de per-ronde hash, met de opmerking dat de demo-engine “uitkomsten GENEREERT met dezelfde primitieven die de verifier gebruikt om ze te CONTROLEREN — één implementatie, zodat de demo nooit kan afwijken van wat de verifier accepteert”.

Drie dingen die het bewijst

Wat het commitment vaststelt, en hoe je elk daarvan controleert

Alle drie de controles zijn lokaal: ze hebben de onthulde seed, jouw client seed, de nonce en de afleidingscode nodig, en niets van het huis op het moment van controleren.

De derde bewering is degene die het werk doet voor een speler, en die hangt af van het feit dat de afleiding openbaar is. Een hash van de seed vertelt je niets over hoe de seed een dobbelsteenworp of een kaart werd. Hier wordt die functie meegeleverd in de client, dezelfde code die de demo gebruikt om resultaten te genereren en die de verifier gebruikt om ze te controleren, zodat een herberekende ronde een echte herberekening is in plaats van een verzoek aan de server om zichzelf te bevestigen.

ENGINE-GEVERIFIEERD_shared/demoLocal.ts: uAt() leidt het per-ronde getal af als u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), beschreven als overeenkomend met RandomUtils.generateHash op de server; _shared/rng.ts zet de eerste zeven bytes van de HMAC om in een uniform getal in [0, 1) “dat bit-voor-bit overeenkomt met de Long→Double afronding van de server”. De derive-module van elk spel zet dat getal vervolgens om in een worp, een kaart of een multiplier.

De verificatiewandeling doorloopt alle drie de stappen op een echte ronde. Als je dit nog nooit hebt gedaan, doe het dan één keer; het punt van het systeem is niet dat je elke ronde controleert, maar dat je er elke zou kunnen controleren, en het huis kan niet van tevoren weten welke.

Drie dingen die het niet kan bewijzen

Het kan niet bewijzen dat de seed willekeurig was. Een commitment legt een seed vast; het zegt niets over hoe de seed gekozen werd. Als het huis jouw client seed al kende toen het de server seed genereerde, zou het in principe seeds kunnen genereren totdat het er een vond waarvan het de eerste ronden beviel, en zich daaraan committeren. De hash zou perfect kloppen. De standaardverdediging is volgorde: de server seed wordt eerst vastgelegd, en de client seed wordt daarna ingesteld, zodat wat het huis ook vastlegde, het niet wist waarmee het gecombineerd zou worden.

Die volgorde is waar het paneel van deze site een grens heeft die het waard is om duidelijk te benoemen. Het instellen van een client seed hier laat de huidige server seed niet ongewijzigd; het roteert het paar, en de nieuwe server seed wordt gegenereerd door dezelfde aanvraag die je nieuwe client seed draagt. Vanuit de client is het niet mogelijk om aan te tonen dat de nieuwe seed vastgezet was voordat de aanvraag gelezen werd. Of de server de volgende seed vooraf genereert, zoals sommige operators doen door de volgende commitment vooraf te publiceren, is niet zichtbaar in de API van de client, en er is geen veld “volgende server seed hash” om tegen te controleren. Dit is aangekaart bij het gameteam, en de oplossing is klein: leg de volgende server seed vast voordat de client seed die ermee gepaard zal worden geaccepteerd wordt, en toon die commitment in het paneel.

ENGINE-GEVERIFIEERD_shared/seedApi.ts: setClientSeed(clientSeed) roept renewRandomKey aan met de nieuwe client seed en geeft een vers paar terug bij nonce 0; rotate() roept hetzelfde endpoint aan zonder seed. IHouseSeed bevat serverSeedHashed, clientSeed en nonce, plus het vorige paar bij rotatie; er is geen volgende-seed-commitment aanwezig in het type.

Tot dan is de praktische versie van de verdediging degene die het systeem je al op elke andere manier geeft: de onthulling. Een huis dat seeds tegen jouw client seed aan het malen is, zou nog steeds elke seed bij rotatie moeten onthullen, en elke ronde eronder kan opnieuw berekend worden. Wat de grens betekent is dat een verdachte reeks in de eerste ronden na een seedwissel niet alleen door de hash uitgesloten kan worden; het kan alleen onderzocht worden, ronde voor ronde, na de onthulling.

Het kan niet bewijzen dat het spel eerlijk is in de andere zin. “Provably fair” betekent dat de willekeur eerlijk was, niet dat de kansen gelijk zijn. Een dobbelspel kan perfect verifieerbaar zijn en toch met opzet 99% teruggeven; de edge zit in de uitbetalingstabel, wat een gepubliceerd getal is en een aparte belofte. De ethiek van de house edge gaat over die belofte. De commitment zegt er niets over.

Het bewijst niets over rondes die niemand controleert. Het systeem is een afschrikmiddel, geen garantie. Een ronde die je nooit herberekent, is een ronde die je op vertrouwen hebt aangenomen, precies zoals je overal elders zou doen; wat verandert is dat het vertrouwen optioneel is, en het huis kan niet weten wanneer je het zult toepassen. Dat is een grote verbetering ten opzichte van een schudmachine waar je niet in kunt kijken, en een kleinere dan het woord “bewijs” suggereert.

De hash is een bewijs van ontvangst voor de willekeur. Het is geen certificaat voor het spel. de zin om te onthouden

Wat meer zou bewijzen

• Een vooraf vastgelegde volgende seed. Het publiceren van de hash van de volgende server seed voordat er een client seed mee gepaard kan worden, sluit de bovengenoemde volgordekloof. Het is de enige verandering die het paneel zou laten bewijzen dat de seed vastgezet was voordat jouw invoer bekend was.
• Een publieke bron van willekeur. Het mengen van een baken dat niemand controleert, zoals het drand-netwerk, verwijdert de vraag wie de seed koos volledig; inside drand beschrijft hoe dat werkt en wat het kost.
• Een gepubliceerde afleiding, publiek gehouden. Hier al het geval, en het deel dat het makkelijkst verloren gaat wanneer een client herschreven wordt. De verifier is slechts zo eerlijk als de code die hij draait.

Niets hiervan verandert wat een hash is. Ze veranderen waar de hash een vingerafdruk van is, en wanneer. Het systeem is eenvoudig genoeg dat de beperkingen ervan ook eenvoudig zijn, en een speler die de drie dingen kent die het bewijst, staat er beter voor dan iemand die verteld is dat het alles bewijst.

FAQ

Wat is een hash-commitment in een provably fair casino?

De SHA-256 vingerafdruk van de geheime server seed van het huis, getoond vóór het spelen en gecontroleerd tegen de seed wanneer deze onthuld wordt. Het bewijst dat de seed vastgezet was voordat je inzette en dat de onthulde seed degene is waaraan gecommitteerd werd.

Bewijst een overeenkomende hash dat het spel eerlijk was?

Het bewijst dat de willekeur niet gewijzigd is na de commitment en, met een gepubliceerde afleiding, dat elk resultaat volgt uit het seedpaar. Het bewijst niet dat de seed willekeurig gekozen was, en het zegt niets over de house edge, wat een apart gepubliceerd getal is.

Kan het huis een serverseed kiezen die in zijn voordeel is?

Alleen als het de clientseed kent waarmee de serverseed gekoppeld zal worden op het moment van kiezen. De verdediging is om de serverseed vast te leggen (committen) voordat de clientseed wordt ingesteld. Op deze site roteert een wijziging van de clientseed het paar binnen hetzelfde verzoek, waardoor die volgorde niet vanaf de client bevestigd kan worden; het artikel beschrijft de zwakke plek en de voorgestelde oplossing.

Hoe controleer ik zelf een ronde?

Roteer de seed om de teruggetrokken serverseed te onthullen, hash deze om te bevestigen dat hij overeenkomt met de commitment die je te zien kreeg, en herbereken vervolgens HMAC-SHA256 van de serverseed over jouw clientseed, de nonce en de cursor, en voer het resultaat door de gepubliceerde afleiding van het spel. Het seedpaneel voert de herberekening uit in je browser.

Waarom is de afleidingscode belangrijk?

Omdat de hash alleen de seed vastlegt. Het omzetten van de seed in een worp of een kaart is een functie, en tenzij die functie openbaar is, zegt een overeenkomende hash niets over of het resultaat was wat de seed impliceerde. Hier levert de client dezelfde afleiding als die de demo gebruikt om uitkomsten te genereren.

Is provably fair beter dan een gelicentieerde RNG-audit?

Ze beantwoorden verschillende vragen. Een audit certificeert het statistische gedrag van een generator over veel trekkingen; een commitment laat je achteraf een specifieke ronde controleren. Geen van beide vervangt de ander, en geen van beide verandert het house edge.

BRONNEN & REFERENTIES

• Wikipedia — Commitment scheme: hiding en binding, en hash-gebaseerde commitments
• Wikipedia — HMAC: keyed hashing en het gebruik ervan als pseudorandom functie
• Betkyo engine bron: _shared/seedApi.ts (commit, reveal en rotatie), _shared/rng.ts (sha256Hex, hmacSha256Utf8, de 7-byte uniform), _shared/demoLocal.ts (uAt afleiding), _shared/SeedPanel.tsx

DE SPELLEN IN DIT ARTIKELDice — regels & gratis spelen →Limbo — regels & gratis spelen →