Რა არის Provably Fair და როგორ უნდა შეამოწმოთ თამაშის გულწრფელობა

რა არის Provably Fair (PF)

Provably Fair არის პროტოკოლი, რომელიც საშუალებას გაძლევთ კრიპტოგრაფიულად შეამოწმოთ, რომ რაუნდის შედეგი შემთხვევითი იყო და არ შეიძლება შეიცვალოს ოპერატორის მიერ განაკვეთის შემდეგ.

იდეა: ჯერ გამოქვეყნდა კომუნა (დამალული სერვერის ჰეშტი), შემდეგ განაკვეთის შემდეგ გამოვლენილია შურისძიება (თავად სერვერი seed), ხოლო ყველას შეუძლია შეამოწმოს hash და რეპროდუცირება RNG, მოთამაშის კლასიფიკაციისა და რაუნდის იდენტიფიკატორის გათვალისწინებით.

ძირითადი პროტოკოლი: commit - bet - reveal

1. Commit: რაუნდის დაწყებამდე, სერვერი წარმოქმნის შემთხვევითი 'სერვერის _ seed' და აქვეყნებს მის ჰეშს:


commit = SHA-256(server_seed         salt )//ან Keccak-256

კომუნის განთავსება შესაძლებელია ისტორიაში/blockchain/ჟურნალი.

2. განაკვეთი: მოთამაშე ირჩევს ან დაადასტურებს თავის „client _ seed“ (UI- დან ან საკუთარი), აგზავნის ფსონს:


client_seed, roundId, nonce

3. Reveal: განაკვეთების დახურვის შემდეგ, სერვერი ავლენს 'server _ seed' (და 'salt', თუ ის იყო), რათა ყველას შეამოწმოს:


SHA-256(server_seed         salt) = commit//მთლიანობის შემოწმება

4. RNG: შემთხვევების რაოდენობა დეტერმინირებულია და რეპროდუცირებულია:


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
//ან rng = SHA-256 (server _ seed         client_seed          roundId          nonce)

5. Mapping შედეგი: ჩვენ „rng“ - ს გადავაქცევთ თამაშის დიაპაზონს გადაადგილების გარეშე (იხ. ქვემოთ).

💡 რატომ nonce? ასე რომ, ერთი 'სერვერის _ seed' - ით შესაძლებელი გახდა მრავალი რაუნდის ჩატარება პროგნოზირების რისკის გარეშე: 'nonce' იფარება თითოეული რაუნდი/კურსი.

როგორ მივიღოთ ნომერი გადაადგილების გარეშე (bias-free)

არასწორია 'rng% N' - ის მიღება - ეს იძლევა მოდულურ გადაადგილებას, თუ 2 ^ k არ არის N.- ის განმეორებით. მართალია - გამარტივება:

pseudo
//rng _ bytes = 32 ჰეშის ბაიტი, uint256 x = uint256 (rng _ bytes)

limit = floor(2^256 / N) N while x >= limit:
rng _ bytes = SHA-256 (rng _ bytes )//„ აურიეთ “კვლავ დეტერმინირებული x = uint256 (rng _ bytes)

result = x % N

ასე რომ, ჩვენ ვიღებთ ერთგვაროვან განაწილებას N შედეგების მიხედვით (რულეტის უჯრედები, დრამის სიმბოლოები და ა.შ.).

მინი მაგალითი (მოთამაშის ეტაპობრივი გადამოწმება)

დავუშვათ:


server _ seed = „b2c6... e9 “//გაიხსნა რაუნდის შემდეგ (hex/utf8)
client _ seed = „my-client-seed “//მე შევარჩიე roundid =„ R-2025-10-17-001 “
nonce = 42 commit = „c9a1... f3 “//გამოცემა. წინასწარ

1) შეამოწმეთ კომუნა

გაანგარიშება 'SHA-256 (სერვერი _ თესლი)' და დარწმუნდით, რომ იგი ემთხვევა 'commit- ს ".

2) დეტერმინირებული RNG

დათვლა:


rng = HMAC-SHA256(key=server_seed,          msg= client_seed          ":"          roundId          ":"          nonce)

3) გარდაქმნა

რულეტისთვის (37 ნომერი), N = 37, გამოიყენეთ rejection sampling და მიიღეთ 'x% 37'.

სლოტისთვის: გამოიყენეთ RNG რამდენიმე ნაწილი დრამის/სიმბოლოების დასადგენად განაწილების ცხრილის მიხედვით.

4) შეამოწმეთ შედეგი ისტორიაში

საიტმა უნდა აჩვენოს იგივე შესასვლელი, რომელიც გამოიყენა გაანგარიშებაში: 'სერვერი _ თესლი', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

ალტერნატივა/გაძლიერება: VRF (Verifiable Random Function)

კომიტის ნაცვლად, ოპერატორს (ან დამატებით) შეუძლია გამოიყენოს VRF:

1. სმარტ კონტრაქტი ან საჯარო რეესტრი ითხოვს „VRF (თესლი)“ პროვაიდერს.

2. გამოქვეყნებულია '(random, proof)'.

3. ყველას შეუძლია შეამოწმოს იგივე საზოგადოებრივი საკვანძო წყვილი VRF.

4. შემდეგი არის იგივე ნაბიჯები RNG mapping შედეგში.

დადებითი: ნაკლები ნდობა ოპერატორისადმი. უარყოფითი მხარეები: დამოკიდებულება VRF პროვაიდერზე/ჯაჭვზე და შესაძლო ღირებულებაზე.

როგორ უნდა შემოიღოს კაზინომ PF სწორად

ხელშეკრულება (PF მონაცემთა ხელშეკრულება)

ველები რაუნდის ისტორიაში:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
მნიშვნელობები - WORM საცავში (immutable), დროის კლიშეებით (UTC).

სიდრის თაობა

'server _ seed' წარმოიქმნება კრიპტოგრაფიული მდგრადი PRNG (OS CSPRNG/HSM).

სავარძლები არასოდეს უნდა განმეორდეს სერიებს შორის (როტაცია).

'client _ seed' - შეირჩევა მოთამაშის მიერ ან წარმოიქმნება კლიენტზე და დასტურდება.

კომიტების გამოქვეყნება

კომიტები ხელმისაწვდომია ფსონებამდე (ისტორია, RSS, წამყვანი).

ლოტებისთვის შეგიძლიათ გამოიყენოთ მერკლის ხე, რომელსაც აქვს ფესვის ყოველდღიური გამოქვეყნება.

გამჟღავნება

შედეგის გამოქვეყნებამდე, „სერვერი _ თესლი“ იხსნება და გამოსწორებულია.

ერთ ადგილზე რაუნდის სერიისთვის - სერიის დასრულების შემდეგ გამჟღავნება (წინასწარ მიუთითეთ პოლიტიკა).

გამჭვირვალე მაპინგი

დაფიქსირებულია mappingVer ალგორითმის ვერსია.

ნებისმიერი ცვლილება ('mappingVer '/' rngAlgo') მხოლოდ გამოცხადებით და ახალი კომიქსების სერიით.

აუდიტი და დავები

ნედლეული შეყვანა + გამოთვლების ჩანაწერი დაცულია; დავის დროს წარმოიქმნება მოხსენება: შესასვლელი - RNG - გამოცემა - შედეგი.

Strimes/Live: შეინახეთ CV/RFID მოვლენების ჰაში, ვიდეო WORM- ში.

როგორ უნდა შეამოწმოს მოთამაშემ პატიოსნება (ჩეკების სია)

1. შეამოწმეთ რაუნდის ისტორია და დააკოპირეთ: 'SeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. გამოთვალეთ hash 'SeedReveal' და შეადარეთ 'Servert SeedHash'.

3. გამოთვალეთ RNG მითითებული ალგორითმის მიხედვით (HMAC/Hash + შესასვლელი).

4. გამოიყენეთ „შეუზღუდავი“ შეფერხება შედეგებს შორის.

5. დარწმუნდით, რომ შედეგი ემთხვევა იმას, რაც ნაჩვენებია.

6. თუ VRF გამოცხადებულია, შეამოწმეთ 'proof' (ღილაკი „Verify“ ან დამოუკიდებელი სკრიპტი/ბლოკის ექსპლორერი).

ტიპიური შეცდომები (ნიმუშები)

'rng% N' rejection sampling- ის გარეშე გადაადგილების ალბათობა.

ფარული ან ცვალებადი „client _ seed“ (წარმოიქმნება სერვერის მიერ მოთამაშის მონაწილეობის გარეშე).

'server _ seed' გადაკეთება განაკვეთის შემდეგ (კომუნა რეტროაქტიულად იცვლება).

ალგორითმების გაუმჭვირვალე ცვლილებები ვერსიის/გამოქვეყნების გარეშე.

სერიებს შორის სიდების გამეორება.

WORM/დროის კლიშეების არარსებობა არ შეიძლება დაამტკიცოს მოვლენების რიგი.

PF და ბიზნეს ლოგიკის ნაზავი (მაგალითად, პრემია გამოიყენება შედეგების სივრცის შეცვლისთვის, მაგრამ ეს არ არის აღწერილი 'mappingVer- ში ").

FAQ (მოკლედ)

შესაძლებელია სლოტების შემოწმება და არა მხოლოდ რულეტი?

დიახ. PF გამოიყენება არჩევნების თანმიმდევრობით (მაგალითად, ბარაბანზე სიმბოლოების ინდექსი). მნიშვნელოვანია, რომ დაფიქსირდეს ალბათობის ცხრილი და RNG კითხვის წესი.

და თუ მე შევიტანე ჩემი "client _ seed", ოპერატორს მაინც შეუძლია "შეარჩიოს" სერვერი _ seed "?

არა, თუ კომუნა გამოქვეყნდა ფსონზე. ის აფიქსირებს 'სერვერს _ seed' და არ იძლევა მის რეტროაქტიულად შეცვლას.

რატომ ზოგჯერ სავარძლები ჩანთაში ვლინდება?

ისე, რომ სერიალში არ იყოს შესაძლებელი სიდის „ამოღება“. ეს დასაშვებია, თუ კომუნა წინასწარ ქვეყნდება, ხოლო გამჟღავნების პოლიტიკა გამჭვირვალეა.

ფორმატის მინი რეფერენდუმი

Heshi: SHA-256 ან Keccak-256.

RNG: HMAC-SHA256 (სერვერის Sid, როგორც გასაღები) ან SHA-256 შეჯამება.

იდენტიფიკატორები: 'roundId' (UTC ბეჭედი + თამაში + შემცირება), 'nonce' (სერიაში განაკვეთების მრიცხველი).

Версии: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette. v2`, `calcVer=wallet-7. 2`.

ოპერატორისთვის PF განხორციელების ჩამონათვალი

კრიპტოგრაფია და სავარძლები

CSPRNG/HSM; უნიკალური 'server _ seed', დოკუმენტირებული როტაცია.
'client _ seed' - მოთამაშის მიერ კონტროლირებადი, ისტორიაში შენარჩუნებულია.

პუბლიკაციები და შენახვა

ფსონები, პუბლიკაციების ისტორიის/არხის წვდომა/წამყვანი.
WORM საცავი, UTC კლიშეები, Markley Batch მასშტაბებისთვის.

ალგორითმები

RNG და mapping გადაადგილების გარეშე; ვერსია 'rngAlgo/mappingVer'.
სკრიპტი/გვერდი „პატიოსნების შემოწმება“ (ღია წყარო სასურველია).

ცოცხალი და ჰიბრიდი

Hash წამყვანი CV/RFID/რაუნდის ფაზები, ჟურნალი „როდესაც მათ დახურეს განაკვეთების ფანჯარა“.
დავის პროცედურები (შეყვანის ანგარიში - შედეგი, ბმულები კომუნებზე/VRF).

უსაფრთხოება და აუდიტი

PF პროტოკოლის დამოუკიდებელი აუდიტი, bag bounty.

გადაწყვეტილების ლოგიკა უცვლელია; რეგულარული რეპროდუქციის ტესტები.

Provably Fair გადააქცევს „დაგვიჯერეთ“ „შეამოწმეთ საკუთარი თავი“. Commit/revil ან VRF, დეტერმინირებული RNG და სწორი mapping, ნებისმიერი რაუნდის გადაადგილების გარეშე, ხდება რეპროდუცირებული და დამოწმებული. მოთამაშისთვის ეს არის გამჭვირვალობა და ნდობა. ოპერატორისთვის - ნაკლები დავა, უფრო ძლიერი ბრენდი და რეგულატორების მოთხოვნების დაცვა. მთავარია დისციპლინა: წინასწარ გამოაქვეყნოთ კომუნები, დააფიქსიროთ ალგორითმების ვერსიები, შეინახოთ მტკიცებულებები უცვლელად და მომხმარებელს მისცეს მარტივი გადამოწმების ინსტრუმენტი.