Cam kết hash chứng minh điều gì, và ba điều nó không thể

Mẹo, gói gọn trong một đoạn

Một hàm băm mật mã học biến bất kỳ đầu vào nào thành một dấu vân tay có độ dài cố định với hai tính chất quan trọng ở đây: bạn không thể làm ngược từ dấu vân tay để ra đầu vào, và bạn không thể tìm ra hai đầu vào có cùng dấu vân tay. Vậy nếu ai đó cho bạn xem dấu vân tay của một bí mật hôm nay và bí mật đó vào ngày mai, bạn có thể băm bí mật đó và kiểm tra xem nó có khớp không. Nếu khớp, bí mật họ vừa cho bạn xem chính là bí mật họ đã có từ hôm qua. Họ không thể đã đổi nó ở giữa, vì một bí mật khác sẽ có dấu vân tay khác, và họ cũng không thể chọn bí mật sao cho khớp với dấu vân tay, vì điều đó đồng nghĩa với việc đảo ngược hàm băm.

Đó chính là một sơ đồ cam kết (commitment scheme), và đó là toàn bộ nội dung mật mã học của “provably fair”. Nhà cái tạo ra một server seed, công bố hash SHA-256 của nó, chơi các vòng được suy ra từ seed, và tiết lộ seed khi cặp seed đó bị nghỉ hưu. Mọi thứ khác chỉ là hệ thống ống dẫn phụ trợ.

ENGINE-VERIFIED_shared/seedApi.ts: getRandomKey trả về {serverSeedHashed, clientSeed, nonce}; renewRandomKey trả về một cặp mới cùng với previousServerSeed và previousServerSeedHashed, phần tiết lộ. _shared/SeedPanel.tsx gắn nhãn trường này là “server seed (sha-256 commitment)”. _shared/rng.ts: sha256Hex() tính dấu vân tay và hmacSha256Utf8() tính hash cho từng vòng, kèm chú thích rằng engine demo “TẠO kết quả bằng cùng các nguyên hàm mà bộ xác minh dùng để KIỂM TRA chúng — một cách triển khai duy nhất, để bản demo không bao giờ lệch khỏi những gì bộ xác minh chấp nhận”.

Ba điều nó chứng minh

Cam kết xác lập điều gì, và cách bạn kiểm tra từng điều

Cả ba phép kiểm tra đều thực hiện cục bộ: chúng chỉ cần seed đã tiết lộ, client seed của bạn, nonce và mã suy ra kết quả, chứ không cần gì từ nhà cái tại thời điểm kiểm tra.

Khẳng định thứ ba là điều mang lại giá trị thực sự cho người chơi, và nó phụ thuộc vào việc công thức suy ra kết quả phải công khai. Một hash của seed không cho bạn biết gì về việc seed đó trở thành một lần tung xúc xắc hay một lá bài như thế nào. Ở đây, hàm đó được đưa vào client, cùng đoạn mã mà bản demo dùng để tạo kết quả và bộ xác minh dùng để kiểm tra chúng, vì vậy việc tính lại một vòng chơi là một phép tính lại thực sự chứ không phải một yêu cầu gửi tới server để nó tự xác nhận chính mình.

ĐÃ ĐƯỢC XÁC MINH BỞI ENGINE_shared/demoLocal.ts: uAt() tính số của mỗi vòng dưới dạng u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), được mô tả là khớp với RandomUtils.generateHash trên server; _shared/rng.ts biến bảy byte đầu tiên của HMAC thành một số đồng nhất trong khoảng [0, 1) “khớp bit-for-bit với cách server làm tròn Long→Double”. Sau đó, module derive của mỗi game sẽ ánh xạ con số đó thành một lượt tung, một lá bài hoặc một hệ số nhân.

Bài hướng dẫn xác minh thực hiện cả ba bước trên một vòng chơi thật. Nếu bạn chưa từng làm điều này, hãy thử một lần; ý nghĩa của cơ chế này không phải là bạn kiểm tra mọi vòng, mà là bạn CÓ THỂ kiểm tra bất kỳ vòng nào, và nhà cái không thể biết trước bạn sẽ kiểm tra vòng nào.

Ba điều nó không thể chứng minh

Nó không thể chứng minh seed là ngẫu nhiên. Một commitment chỉ cố định một seed; nó không nói gì về cách seed đó được chọn. Nếu nhà cái biết client seed của bạn khi tạo server seed, về mặt lý thuyết họ có thể tạo ra nhiều seed cho đến khi tìm được một seed mà các vòng đầu tiên của nó có lợi cho họ, rồi commit vào seed đó. Hash vẫn sẽ khớp hoàn hảo. Biện pháp phòng vệ tiêu chuẩn là thứ tự: server seed được commit trước, và client seed được đặt sau đó, để dù nhà cái đã commit vào gì, họ cũng không biết nó sẽ được kết hợp với gì.

Thứ tự đó chính là nơi bảng điều khiển của trang này có một giới hạn đáng nói rõ. Việc đặt client seed ở đây không giữ nguyên server seed hiện tại; nó xoay vòng cặp seed, và server seed mới được tạo ra bởi cùng yêu cầu mang theo client seed mới của bạn. Từ phía client, không thể chứng minh rằng seed mới đã được cố định trước khi yêu cầu được đọc. Việc server có tạo trước seed tiếp theo hay không, như một số nhà cái làm bằng cách công bố commitment tiếp theo trước, không thể thấy được trong API của client, và không có trường “hash server seed tiếp theo” nào để đối chiếu. Vấn đề này đã được nêu ra với đội ngũ phát triển game, và cách sửa khá đơn giản: commit server seed tiếp theo trước khi client seed sẽ được ghép với nó được chấp nhận, và hiển thị commitment đó trong bảng điều khiển.

ĐÃ ĐƯỢC XÁC MINH BỞI ENGINE_shared/seedApi.ts: setClientSeed(clientSeed) gọi renewRandomKey với client seed mới và trả về một cặp mới ở nonce 0; rotate() gọi cùng endpoint đó mà không có seed. IHouseSeed mang serverSeedHashed, clientSeed và nonce, cùng với cặp trước đó khi xoay vòng; không có commitment cho seed tiếp theo trong type này.

Cho đến khi điều đó xảy ra, phiên bản thực tế của biện pháp phòng vệ chính là thứ mà cơ chế này đã cung cấp ở mọi khía cạnh khác: sự tiết lộ (reveal). Một nhà cái cố gắng “cày” seed chống lại client seed của bạn vẫn phải tiết lộ mỗi seed khi xoay vòng, và mọi vòng dưới seed đó đều có thể được tính toán lại. Ý nghĩa của giới hạn này là một chuỗi kết quả đáng ngờ trong những vòng đầu tiên sau khi đổi seed không thể bị loại trừ chỉ bằng hash; nó chỉ có thể được xem xét, từng vòng một, sau khi tiết lộ.

Nó không thể chứng minh trò chơi công bằng theo nghĩa khác. “Provably fair” nghĩa là tính ngẫu nhiên là trung thực, không phải là tỷ lệ cược cân bằng. Một game xúc xắc có thể hoàn toàn có thể xác minh được và vẫn trả về 99% theo thiết kế; lợi thế nhà cái nằm trong bảng chi trả, đó là một con số được công bố và là một lời hứa riêng biệt. Đạo đức của lợi thế nhà cái nói về lời hứa đó. Commitment không nói gì về nó.

Nó không chứng minh được gì về những vòng mà không ai kiểm tra. Cơ chế này là một biện pháp răn đe, không phải là một bảo đảm. Một vòng bạn không bao giờ tính toán lại là một vòng bạn đã tin tưởng dựa trên niềm tin, đúng như ở bất kỳ nơi nào khác; điều thay đổi là niềm tin đó là tùy chọn, và nhà cái không thể biết khi nào bạn sẽ sử dụng nó. Đó là một cải tiến lớn so với một máy trộn bài mà bạn không thể nhìn thấy bên trong, và là một cải tiến nhỏ hơn so với những gì từ “chứng minh” gợi ý.

Hash là một biên nhận cho tính ngẫu nhiên. Nó không phải là một chứng chỉ cho trò chơi.câu cần nhớ

Điều gì sẽ chứng minh được nhiều hơn

• Một seed tiếp theo được commit trước. Công bố hash của server seed tiếp theo trước khi bất kỳ client seed nào có thể được ghép với nó sẽ khép lại lỗ hổng về thứ tự nói trên. Đó là thay đổi duy nhất có thể khiến bảng điều khiển chứng minh được rằng seed đã được cố định trước khi đầu vào của bạn được biết đến.
• Một nguồn ngẫu nhiên công khai. Việc trộn vào một beacon mà không ai kiểm soát, chẳng hạn như mạng drand, loại bỏ hoàn toàn câu hỏi ai đã chọn seed; bên trong drand mô tả cách điều đó hoạt động và cái giá phải trả.
• Một cách tính toán được công bố, và giữ công khai. Điều này đã đúng ở đây, và là phần dễ mất nhất khi client được viết lại. Người xác minh chỉ trung thực bằng với đoạn code mà nó chạy.

Không điều nào trong số này thay đổi bản chất của hash là gì. Chúng thay đổi hash là dấu vân tay của cái gì, và khi nào. Cơ chế này đủ đơn giản để giới hạn của nó cũng đơn giản, và một người chơi biết ba điều mà nó chứng minh sẽ ở vị thế tốt hơn người được cho rằng nó chứng minh mọi thứ.

Câu hỏi thường gặp

Hash commitment trong một sòng bạc provably fair là gì?

Dấu vân tay SHA-256 của server seed bí mật của nhà cái, được hiển thị trước khi chơi và được đối chiếu với seed khi nó được tiết lộ. Nó chứng minh rằng seed đã được cố định trước các cược của bạn và seed được tiết lộ chính là seed đã được commit.

Một hash khớp có chứng minh trò chơi công bằng không?

Nó chứng minh rằng tính ngẫu nhiên không bị thay đổi sau khi commit và, với một cách tính toán được công bố, mỗi kết quả đều bắt nguồn từ cặp seed. Nó không chứng minh rằng seed được chọn một cách ngẫu nhiên, và nó không nói gì về lợi thế nhà cái, đó là một con số được công bố riêng biệt.

Nhà cái có thể chọn một server seed có lợi cho họ không?

Chỉ khi nó biết trước client seed mà server seed sẽ được ghép cặp vào thời điểm nó chọn. Cách phòng vệ là commit server seed trước khi client seed được thiết lập. Trên trang này, việc thay đổi client seed sẽ xoay vòng cặp seed trong cùng một request, vì vậy thứ tự đó không thể được xác nhận từ phía client; bài viết mô tả ranh giới này và giải pháp đã được đề xuất.

Làm sao để tôi tự kiểm tra một vòng chơi?

Xoay vòng seed để tiết lộ server seed đã nghỉ, hash nó để xác nhận nó khớp với commitment đã hiển thị cho bạn, sau đó tính lại HMAC-SHA256 của server seed trên client seed, nonce và cursor của bạn, rồi đưa kết quả qua công thức derivation đã công bố của game. Bảng seed thực hiện việc tính lại này ngay trong trình duyệt của bạn.

Tại sao mã derivation lại quan trọng?

Vì hash chỉ cố định seed. Việc biến seed thành một lượt quay hay một lá bài là một hàm, và trừ khi hàm đó công khai, một hash khớp không nói lên được gì về việc kết quả có đúng là kết quả mà seed ngụ ý hay không. Ở đây, client sử dụng cùng công thức derivation mà bản demo dùng để tạo kết quả.

Provably fair có tốt hơn kiểm toán RNG có giấy phép không?

Chúng trả lời những câu hỏi khác nhau. Một cuộc kiểm toán chứng nhận hành vi thống kê của một bộ tạo số qua nhiều lượt quay; một commitment cho phép bạn kiểm tra một vòng cụ thể sau khi nó diễn ra. Cái này không thay thế cái kia, và cả hai đều không thay đổi house edge.

NGUỒN & TÀI LIỆU THAM KHẢO

• Wikipedia — Commitment scheme: hiding và binding, và các commitment dựa trên hash
• Wikipedia — HMAC: keyed hashing và việc sử dụng nó như một hàm giả ngẫu nhiên
• Mã nguồn engine Betkyo: _shared/seedApi.ts (commit, reveal và rotation), _shared/rng.ts (sha256Hex, hmacSha256Utf8, số ngẫu nhiên đồng đều 7-byte), _shared/demoLocal.ts (derivation uAt), _shared/SeedPanel.tsx

CÁC GAME TRONG BÀI VIẾT NÀYDice — luật chơi & chơi thử miễn phí →Limbo — luật chơi & chơi thử miễn phí →