Hoe provably fair werkt op Rust-sites en hoe je je worpen controleert

Alle tien de sites in onze ranglijst vermelden hun games als provably fair. De term heeft een precieze betekenis, en de controle erachter kun je zelf uitvoeren met een gratis hashtool of een paar regels code. Heel weinig spelers doen dat ooit. In deze gids lees je wat het systeem bewijst, wat het weglaat en hoe je een worp van begin tot eind verifieert.

De korte versie: voordat je inzet, legt de site een geheime waarde vast en toont je er een vingerafdruk van. Jij voegt een eigen invoer toe. Na de inzetten onthult de site het geheim, en kun je bevestigen dat de vingerafdruk klopt en dat elke uitslag uit de invoer volgt. Als de getallen kloppen, kon de site geen uitkomst veranderen nadat hij jouw inzet had gezien.

Het probleem dat provably fair oplost

Op een skinsite bepaalt de server elke uitslag. Als je een case opent, een munt opgooit of op een crashmultiplier wacht, kijk je naar een animatie van een getal dat is gemaakt op een machine die je niet kunt inspecteren. Zonder een vorm van bewijs vertrouw je erop dat de exploitant de worpen niet stilletjes tegen je bijstuurt als je inzet groot is.

Vergunde online casino's beantwoorden dit meestal met toezichthouders en audits van hun random number generators door derden. De meeste skinsites vertrouwen in plaats daarvan op een cryptografische aanpak. Die heeft voor spelers één groot voordeel: je hoeft geen auditor te vertrouwen, want je kunt de berekening op je eigen computer herhalen.

Het idee heet een commitment scheme. Stel je voor dat de site zijn geheim op een kaart schrijft, de kaart in een envelop verzegelt en je de envelop geeft voordat het spel begint. Hij kan de kaart later niet verwisselen zonder dat jij het merkt, en jij kunt de kaart niet vroeg lezen.

De drie invoeren: server seed, client seed en nonce

Bijna elk provably fair-systeem op Rust-sites gebruikt dezelfde ingrediënten. De labels verschillen een beetje per site, maar de rollen blijven gelijk.

Server seed

Een lange willekeurige reeks die door de site wordt gegenereerd. Hij blijft geheim terwijl je speelt, want wie hem kent, kan elke uitslag voorspellen. Wat je in plaats daarvan ziet, is de hash, meestal gemaakt met SHA-256. Een hash is een eenrichtingsvingerafdruk. Dezelfde invoer geeft altijd dezelfde uitvoer van 64 tekens, één teken in de invoer veranderen verandert de uitvoer compleet, en er is geen praktische manier om van de hash terug te rekenen naar de seed.

Client seed

Een reeks die van jouw kant komt. Sites genereren er standaard een voor je, en de meeste laten je hem aanpassen in het fairness- of instellingenpaneel. Zijn taak is te voorkomen dat de site een server seed kiest die specifiek voor jou slecht is. De site legde zich vast op zijn seed voordat hij wist wat jij zou typen, dus hij kon de een niet op de ander afstemmen.

Nonce

Een teller die bij 0 of 1 begint en bij elke inzet op hetzelfde seedpaar met één omhooggaat. Daardoor kun je één server seed en één client seed voor honderden inzetten hergebruiken en toch elke keer een nieuwe uitslag krijgen.

Wil je je uitslagen controleren, dan vraag je de site de seed te roteren. Hij onthult de oude server seed in leesbare tekst, toont je de hash van een nieuwe en zet de nonce terug. Alles wat je op de oude seed speelde, kan nu worden geverifieerd.

Hoe de invoer een uitslag wordt

Het gangbaarste recept is HMAC-SHA256. HMAC is een standaardmanier om een geheime sleutel met een bericht te combineren tot een hash. Op de meeste Rust-sites is de server seed de sleutel, en het bericht is de client seed en de nonce aan elkaar geplakt, vaak met een dubbele punt, zoals clientseed:nonce. Sommige sites voegen een rondenummer of game-ID toe, dus lees altijd de exacte formule op de eigen fairnesspagina van de site.

De uitvoer is een hexadecimale reeks van 64 tekens. De site maakt van een deel van die reeks een getal tussen 0 en 1. Een typische methode neemt de eerste acht hextekens (32 bits), zet ze om in een geheel getal en deelt door 4.294.967.296, oftewel 2 tot de macht 32. Dat decimaal wordt daarna op de game afgebeeld:

• Dice en upgrader: vermenigvuldig met 100 voor een worp van 0,00 tot 99,99 en vergelijk die daarna met de target.
• Roulette: vermenigvuldig met het aantal slots op het wiel en rond af naar beneden om een slot te kiezen.
• Cases: vermenigvuldig met het totale aantal tickets in de case, zodat een skin die 1% van de tickets bezit op 1% van de worpen wint.
• Crash: voer het getal in een formule die er een multiplier van maakt, met de house edge erin verwerkt. In onze crashstrategiegids lopen we die formule door en wat ze betekent voor cash-outtargets.

Een uitgewerkt voorbeeld dat je kunt nabootsen

De onderstaande seeds zijn voor dit voorbeeld verzonnen, zodat je onze rekensom met elke HMAC-SHA256-calculator kunt controleren.

1. Server seed: example-server-seed-01. Zijn SHA-256-hash begint met a5275da7ccca3f73. Die hash zou de site je tonen voordat je speelt.
2. Client seed: my-own-client-seed. Nonce: 1. Het bericht is dus my-own-client-seed:1.
3. HMAC-SHA256 met de server seed als sleutel en dat bericht als invoer geeft een uitkomst die begint met 4cdcf221.
4. Hex 4cdcf221 is decimaal 1.289.548.321. Gedeeld door 4.294.967.296 is dat ongeveer 0,30025.
5. Op een diceschaal van 0 tot 100 is dat een worp van 30,02. Op een roulettewiel met 15 slots is 0,30025 maal 15 ongeveer 4,5, wat naar beneden afrondt op slot 4 (het eerste slot als 0 geteld).

Draai dezelfde seeds met nonce 2 en je krijgt een compleet andere hash, die begint met 6486ccbd en neerkomt op ongeveer 0,3927. Niets aan de eerste worp zegt iets over de tweede. Die onafhankelijkheid is het hele punt: in een inzetgeschiedenis valt geen patroon te lezen, want elke uitslag is een verse hash.

Zo verifieer je zelf een worp, stap voor stap

De eerste volledige controle kost wat tijd. Daarna is het een paar minuten kopiëren en plakken. Doe het eerst met een klein saldo, zodat je het proces kent voordat een uitslag er echt toe doet.

1. Open het fairnesspaneel voordat je inzet. Het is meestal gelinkt vanaf het gamescherm, de footer of je profielinstellingen. Bewaar de gehashte server seed ergens buiten de site, zoals in een notitie op je telefoon of een screenshot.
2. Stel je eigen client seed in. Vervang de standaardwaarde door iets wat je zelf hebt getypt. Rammel maar wat op het toetsenbord. Hij hoeft niet makkelijk te onthouden te zijn.
3. Speel, en noteer de inzetten waar je om geeft. Schrijf de nonce op die bij elke inzet staat, of zoek hem later op in je inzetgeschiedenis.
4. Roteer de seed. De site onthult de oude server seed. Kopieer hem.
5. Controleer de commitment. Haal de onthulde server seed door een SHA-256-tool. De uitvoer moet teken voor teken overeenkomen met de hash die je in stap 1 bewaarde.
6. Bereken de worp opnieuw. Gebruik HMAC-SHA256 met de onthulde server seed, je client seed en de nonce, en pas daarna de omzetting toe die de site publiceert. In PHP is dat één aanroep van hash_hmac, en de hmac-module van Python doet hetzelfde in een paar regels.
7. Vergelijk. Het getal dat je berekent moet de uitslag opleveren die in je geschiedenis staat.

De meeste sites hebben ook een ingebouwde verifier waarin je de seeds plakt. Dat is handig, maar hij draait op de eigen code van de exploitant. Gebruik voor een controle die helemaal niet van de site afhangt minstens één keer een onafhankelijke tool of je eigen script.

Gedeelde games werken iets anders

Singleplayermodi zoals dice, upgrader en solo case openings kunnen op je persoonlijke seedpaar draaien. Games waarbij veel spelers één uitslag delen, zoals jackpot, coinflip, case battles, roulette-rondes en crash, kunnen de client seed van één speler niet over ieders uitkomst laten beslissen. Sites pakken dit op een paar gangbare manieren aan.

• Een hashketen. Gebruikelijk bij crash. De site genereert vooraf een lange keten van hashes, waarbij de hash van elke ronde de SHA-256 is van die van de volgende ronde. Hij publiceert de laatste hash van de keten voordat de eerste ronde wordt gespeeld, en jij kunt controleren dat elke onthulde ronde terughasht naar de vorige. Elke uitslag in de keten stond vast voordat iemand een inzet deed.
• Een openbare seed van buiten de site. De site legt zich vast op zijn server seed en mengt er daarna een waarde doorheen die niemand vooraf kon weten, zoals de hash van een toekomstig blok op een openbare blockchain. Omdat dat blok niet bestond toen de site zich vastlegde, kon de site zijn seed er niet op afstemmen.
• Commitments per ronde. Bij jackpot en coinflip verschijnt de gehashte seed van de ronde wanneer de ronde opent, en worden de leesbare seed en het winnende ticket getoond als hij eindigt.

Het verificatie-idee is in elk geval hetzelfde. Zoek de commitment die vóór de ronde openbaar was, bevestig dat de onthulde waarde ermee overeenkomt en bereken dan de uitslag opnieuw. Hoe een winnend ticket in een gedeelde pot een winnaar wordt, lees je in onze gids over coinflip- en jackpotkansen. Case battles mengen beide aanpakken, wat we behandelen in case battles uitgelegd.

Wat provably fair niet bewijst

Een geverifieerde worp bewijst één smalle zaak: de uitslag kwam voort uit invoer waarop de site zich vastlegde voordat je inzette. Dat is nuttig, maar spelers lezen vaak veel meer in de badge dan die ondersteunt.

• Het zegt niets over de house edge. Een crashgame met een grote edge kan volkomen provably fair zijn. De edge zit in de gepubliceerde formule die het willekeurige getal omzet in een multiplier of winkans. Fair betekent dat de site zijn eigen regels volgde, en die regels bevoordelen de site op termijn nog steeds.
• Het controleert geen prijzen. Vermeldt een case een skin tegen een waarde die ver boven wat hij op de Steam Community Market zou opbrengen, dan kan de worp eerlijk zijn terwijl de case toch slechte waarde biedt. In onze upgradergids zie je hoe itemprijzen de echte kansen ongemerkt verschuiven.
• Het dekt geen opnames. Een site kan foutloze seeds draaien en toch uitbetalingen vertragen, accounts bevriezen of zijn voorwaarden herschrijven. Daarom is fairness maar één van de invoeren in hoe wij sites beoordelen, naast uitbetalingssnelheid en vertrouwen.
• Het werkt alleen als iemand controleert. Een commitment die niemand vergelijkt, is slechts een reeks tekens op een pagina.

Rode vlaggen op een fairnesspagina

Seeds verifiëren is een routinestap als we een site testen. Dit zijn de dingen die ons achterdochtig maken, ruwweg van mild naar ernstig.

Kom je ooit bij de laatste rij uit, bewaar dan je bewijs: de bewaarde hash, de onthulde seed, de inzet-ID's en het tijdstip van elke inzet. Eén afwijking kan een weergavefout zijn, maar het is precies het soort geloofwaardige melding van een speler waardoor wij een site opnieuw controleren.

Een verstandige routine voor gewone spelers

Je hoeft niet elke inzet te verifiëren. Een lichte routine vangt de meeste problemen op zonder van een sessie huiswerk te maken.

• Stel een nieuwe client seed in wanneer je op een nieuwe site gaat spelen.
• Maak een screenshot van de gehashte server seed voordat je speelt.
• Roteer na de sessie en controleer de commitment, wat één SHA-256-berekening is.
• Bereken de een of twee uitslagen die het meest telden opnieuw, zoals een groot upgraderverlies of een battle waarvan je zeker wist dat je hem had moeten winnen.
• Herhaal af en toe de volledige controle met een onafhankelijke tool in plaats van de verifier van de site.

Een schone verificatie betekent dat de verliezen die je lijdt die zijn die de gepubliceerde wiskunde voorspelt, en niet meer. De edge is nog steeds aanwezig bij elke worp. De praktische volgende stap is van tevoren bepalen hoeveel van die verwachte verliezen je bereid bent te betalen voor het vermaak; op onze pagina over verantwoord gokken staan eenvoudige limieten en de tools die je helpen je eraan te houden.