Så fungerar provably fair på Rust-sajter och hur du kontrollerar dina slag

Alla tio sajter i vår ranking listar sina spel som provably fair. Frasen har en exakt betydelse, och kontrollen bakom den är något du kan köra själv med ett gratis hashverktyg eller några rader kod. Mycket få spelare gör det någonsin. Den här guiden förklarar vad systemet bevisar, vad det lämnar utanför och hur du verifierar ett slag från början till slut.

Kortversionen: innan du satsar låser sajten in ett hemligt värde och visar dig ett fingeravtryck av det. Du lägger till en egen indata. Efter insatserna avslöjar sajten hemligheten, och du kan bekräfta att fingeravtrycket stämmer och att varje resultat följer av indatan. Om siffrorna går ihop kunde sajten inte ha ändrat ett utfall efter att ha sett din insats.

Problemet som provably fair löser

På en skinsajt bestämmer servern varje resultat. När du öppnar ett case, flippar ett mynt eller väntar på en crash-multiplikator tittar du på en animation av ett tal som producerats på en maskin du inte kan granska. Utan någon form av bevis litar du på att operatören inte i tysthet knuffar slagen mot dig när din insats är stor.

Licensierade onlinecasinon svarar oftast på det med tillsynsmyndigheter och granskningar av slumptalsgeneratorer från tredje part. De flesta skinsajter förlitar sig i stället på en kryptografisk metod. Den har en stor fördel för spelare: du behöver inte lita på en granskare, eftersom du kan upprepa beräkningen på din egen dator.

Idén kallas ett åtagandeschema (commitment scheme). Tänk dig att sajten skriver sin hemlighet på ett kort, försluter kortet i ett kuvert och ger dig kuvertet innan spelet börjar. Den kan inte byta kortet senare utan att du märker det, och du kan inte läsa kortet i förväg.

De tre ingredienserna: server seed, client seed och nonce

Nästan varje provably fair-system på Rust-sajter använder samma ingredienser. Etiketterna varierar något mellan sajter, men rollerna förblir desamma.

Server seed

En lång slumpmässig sträng som genereras av sajten. Den hålls hemlig medan du spelar, eftersom den som kände till den kunde förutsäga varje resultat. Det du ser i stället är dess hash, oftast framtagen med SHA-256. En hash är ett enkelriktat fingeravtryck. Samma indata ger alltid samma utdata på 64 tecken, att ändra ett enda tecken i indatan ändrar utdatan helt, och det finns inget praktiskt sätt att räkna baklänges från hashen till seeden.

Client seed

En sträng som kommer från din sida. Sajter genererar en standardsträng åt dig, och de flesta låter dig redigera den i fairness- eller inställningspanelen. Dess uppgift är att hindra sajten från att välja en server seed som är dålig just för dig. Sajten förband sig till sin seed innan den visste vad du skulle skriva, så den hade inget sätt att trimma den ena mot den andra.

Nonce

En räknare som startar på 0 eller 1 och ökar med ett för varje insats du gör på samma seed-par. Den låter dig återanvända en server seed och en client seed för hundratals insatser och ändå få ett nytt resultat varje gång.

När du vill kontrollera dina resultat ber du sajten rotera seeden. Den avslöjar den gamla server seeden i klartext, visar dig hashen av en ny och nollställer noncen. Allt du spelade på den gamla seeden kan nu verifieras.

Så blir indatan ett resultat

Det vanligaste receptet är HMAC-SHA256. HMAC är ett standardsätt att kombinera en hemlig nyckel med ett meddelande för att få fram en hash. På de flesta Rust-sajter är server seeden nyckeln, och meddelandet är client seeden och noncen hopsatta, ofta med ett kolon, som clientseed:nonce. Vissa sajter lägger till ett rundnummer eller ett spel-ID, så läs alltid den exakta formeln på sajtens egen fairnesssida.

Utdatan är en hexadecimal sträng på 64 tecken. Sajten gör sedan om en del av strängen till ett tal mellan 0 och 1. En typisk metod tar de första åtta hextecknen (32 bitar), omvandlar dem till ett heltal och delar med 4 294 967 296, vilket är 2 upphöjt till 32. Det decimaltalet mappas sedan på spelet:

• Dice och upgrader: multiplicera med 100 för att få ett slag från 0,00 till 99,99 och jämför det sedan med målet.
• Roulette: multiplicera med antalet rutor på hjulet och avrunda nedåt för att välja en ruta.
• Cases: multiplicera med det totala antalet biljetter i caset, så att ett skin som äger 1 % av biljetterna vinner på 1 % av slagen.
• Crash: mata in talet i en formel som gör om det till en multiplikator, med house edge inbyggd. Vår guide om crashstrategi går igenom den formeln och vad den betyder för uttagsmål.

Ett räkneexempel du kan återskapa

Seedsen nedan är påhittade för det här exemplet, så att du kan kontrollera vår aritmetik med vilken HMAC-SHA256-kalkylator som helst.

1. Server seed: example-server-seed-01. Dess SHA-256-hash börjar a5275da7ccca3f73. Den hashen är vad sajten skulle visa dig innan du spelar.
2. Client seed: my-own-client-seed. Nonce: 1. Meddelandet är alltså my-own-client-seed:1.
3. HMAC-SHA256 med server seeden som nyckel och det meddelandet som indata ger ett resultat som börjar med 4cdcf221.
4. Hex 4cdcf221 är 1 289 548 321 i decimal. Delat med 4 294 967 296 blir det ungefär 0,30025.
5. På en dice-skala från 0 till 100 är det ett slag på 30,02. På ett roulettehjul med 15 rutor är 0,30025 gånger 15 ungefär 4,5, vilket avrundas nedåt till ruta 4 (när den första rutan räknas som 0).

Kör samma seeds med nonce 2 och du får en helt annan hash, som börjar 6486ccbd och blir ungefär 0,3927. Ingenting om det första slaget säger något om det andra. Det oberoendet är hela poängen: det finns inget mönster att läsa i en insatshistorik, eftersom varje resultat är en ny hash.

Så verifierar du ett slag själv, steg för steg

Den första fullständiga kontrollen tar en stund. Därefter är det några minuter av kopierande och inklistrande. Gör det med ett litet saldo först, så att du kan processen innan ett resultat faktiskt spelar roll för dig.

1. Öppna fairnesspanelen innan du satsar. Den är oftast länkad från spelskärmen, sidfoten eller dina profilinställningar. Spara den hashade server seeden någonstans utanför sajten, som en anteckning i mobilen eller en skärmdump.
2. Sätt din egen client seed. Byt ut standardvärdet mot något du själv skrivit. Hamra på tangentbordet. Den behöver inte vara minnesvärd.
3. Spela och notera insatserna du bryr dig om. Skriv ner noncen som visas vid varje insats, eller hitta den senare i din insatshistorik.
4. Rotera seeden. Sajten avslöjar den gamla server seeden. Kopiera den.
5. Kontrollera åtagandet. Kör den avslöjade server seeden genom valfritt SHA-256-verktyg. Utdatan måste stämma med hashen du sparade i steg 1, tecken för tecken.
6. Räkna om slaget. Använd HMAC-SHA256 med den avslöjade server seeden, din client seed och noncen, och tillämpa sedan omvandlingen som sajten publicerar. I PHP är det ett enda anrop till hash_hmac, och Pythons hmac-modul gör samma sak på ett par rader.
7. Jämför. Talet du räknar fram måste ge utfallet som står i din historik.

De flesta sajter erbjuder också en inbyggd verifierare där du klistrar in seedsen. Den är praktisk, men den körs på operatörens egen kod. För en kontroll som inte beror på sajten alls, använd ett oberoende verktyg eller ditt eget skript minst en gång.

Delade spel fungerar lite annorlunda

Spellägen för en spelare, som dice, upgrader och cases som du öppnar själv, kan köras på ditt personliga seed-par. Spel där många spelare delar ett resultat, som jackpot, coinflip, case battles, roulette-rundor och crash, kan inte låta en spelares client seed avgöra allas utfall. Sajter hanterar det på några vanliga sätt.

• En hashkedja. Vanligt i crash. Sajten genererar en lång kedja av hashar i förväg, där varje rundas hash är SHA-256 av nästa rundas. Den publicerar kedjans sista hash innan första rundan spelas, och du kan kontrollera att varje avslöjad runda hashas tillbaka till den före. Varje resultat i kedjan var bestämt innan någon lade en insats.
• En publik seed utifrån. Sajten förbinder sig till sin server seed och blandar sedan in ett värde som ingen kunde känna till i förväg, som hashen av ett framtida block på en publik blockkedja. Eftersom det blocket inte fanns när sajten förband sig kunde den inte trimma sin seed mot det.
• Åtaganden per runda. I jackpot och coinflip visas rundans hashade seed när rundan öppnar, och den vanliga seeden plus den vinnande biljetten visas när den slutar.

Verifieringsidén är densamma i varje fall. Hitta åtagandet som var publikt före rundan, bekräfta att det avslöjade värdet stämmer med det och räkna sedan om resultatet. För hur en vinnande biljett blir en vinnare i en gemensam pott, se vår guide om odds i coinflip och jackpot. Case battles blandar båda metoderna, vilket vi tar upp i case battles förklarade.

Vad provably fair inte bevisar

Ett verifierat slag bevisar en snäv sak: resultatet kom från indata som sajten förband sig till innan du satsade. Det är användbart, men spelare läser ofta in mycket mer i märket än det stöder.

• Det säger ingenting om house edge. Ett crash-spel med stor fördel kan vara fullt provably fair. Fördelen sitter i den publicerade formeln som gör om slumptalet till en multiplikator eller en vinstchans. Rättvist betyder att sajten följde sina egna regler, och de reglerna gynnar fortfarande sajten över tid.
• Det kontrollerar inte priser. Om ett case listar ett skin till ett värde långt över vad det skulle säljas för på Steam Community Market kan slaget vara rättvist medan caset ändå är dåligt värde. Vår guide om upgrader visar hur föremålens prissättning i tysthet förskjuter de verkliga oddsen.
• Det omfattar inte uttag. En sajt kan köra felfria seeds och ändå försena utbetalningar, frysa konton eller skriva om sina villkor. Därför är rättvisa bara en av insatserna i så betygsätter vi sajter, vid sidan av utbetalningshastighet och förtroende.
• Det fungerar bara om någon kontrollerar. Ett åtagande som ingen jämför är bara en sträng av tecken på en sida.

Varningsflaggor på en fairnesssida

Att verifiera seeds är ett rutinsteg när vi testar en sajt. Det här är sakerna som gör oss misstänksamma, ungefär från milda till allvarliga.

Om du någonsin träffar den sista raden, spara ditt underlag: den sparade hashen, den avslöjade seeden, insats-ID:n och tidpunkten för varje insats. En enda avvikelse kan vara en visningsbugg, men det är precis den sortens trovärdiga spelarrapport som får oss att kontrollera en sajt på nytt.

En rimlig rutin för vanliga spelare

Du behöver inte verifiera varje insats. En lätt rutin fångar de flesta problem utan att göra ett pass till läxor.

• Sätt en ny client seed varje gång du börjar spela på en ny sajt.
• Ta en skärmdump av den hashade server seeden innan du spelar.
• Rotera efter passet och kontrollera åtagandet, vilket är en SHA-256-beräkning.
• Räkna om det eller de två resultat som betydde mest, som en stor förlust i upgrader eller en battle du var säker på att du borde ha vunnit.
• Upprepa då och då hela kontrollen med ett oberoende verktyg i stället för sajtens verifierare.

En ren verifiering betyder att förlusterna du tar är de som den publicerade matematiken förutsäger, och inga fler. Fördelen finns kvar vid varje slag. Nästa praktiska steg är att i förväg bestämma hur mycket av de förväntade förlusterna du är beredd att betala för underhållningen; vår sida om ansvarsfullt spelande tar upp enkla gränser och verktygen som hjälper dig hålla dig till dem.