ハッシュコミットメントが証明すること、そして証明できない3つのこと

仕組みは一段落で言える

暗号学的ハッシュは、どんな入力も固定長の指紋に変換します。ここで重要な性質は2つあります。指紋から入力へ逆算することはできない、そして同じ指紋を持つ2つの異なる入力を見つけることもできない、という点です。だから、誰かが今日ある秘密の指紋を見せ、翌日その秘密自体を見せたなら、その秘密をハッシュ化して一致するか確認できます。一致すれば、見せられた秘密は昨日持っていたものと同じです。途中で入れ替えることはできません。異なる秘密なら異なる指紋になるからです。また指紋に合わせて秘密を選ぶこともできません。それはハッシュを逆算することを意味するからです。

これがコミットメントスキームであり、「provably fair（証明可能な公正性）」の暗号学的な内容のすべてです。ハウスはサーバーシードを生成し、そのSHA-256ハッシュを公開し、そのシードから導出されたラウンドをプレイし、シードペアが引退する際にシードを公開します。それ以外はすべて配管作業です。

ENGINE-VERIFIED_shared/seedApi.ts: getRandomKeyは{serverSeedHashed, clientSeed, nonce}を返します。renewRandomKeyは新しいペアとともにpreviousServerSeedとpreviousServerSeedHashed、つまり公開情報を返します。_shared/SeedPanel.tsxではこのフィールドを「server seed (sha-256 commitment)」とラベル付けしています。_shared/rng.ts: sha256Hex()が指紋を計算し、hmacSha256Utf8()が各ラウンドのハッシュを計算します。コメントには、デモエンジンが「検証者が結果をCHECKするのと同じプリミティブでオッチCOMEを生成する — 実装は1つだけなので、デモが検証者の受け入れる内容から逸脱することは決してない」とあります。

証明される3つのこと

コミットメントが何を確立し、それぞれをどう検証するか

この3つの確認はすべてローカルで行える。公開されたシード、あなたのクライアントシード、ナンス、そして導出コードさえあれば良く、確認時にハウスから何かを取得する必要はない。

3つ目の主張こそがプレイヤーにとって意味を持つものであり、それは導出処理が公開されていることに依存します。シードのハッシュだけでは、そのシードがどのようにサイコロの出目やカードになったのかは何もわかりません。ここではその関数がクライアント側に組み込まれており、デモが結果を生成するのに使うのと同じコードを検証者もチェックに使います。だから再計算されたラウンドは、サーバーに自己確認を依頼するのではなく、本物の再計算なのです。

エンジン検証済み_shared/demoLocal.ts: uAt() は各ラウンドの数値を u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)) として導出し、これはサーバー側の RandomUtils.generateHash と一致するとされている。_shared/rng.ts は HMAC の最初の7バイトを [0, 1) の範囲の一様な数値に変換し、「サーバーの Long→Double の丸め処理とビット単位で一致する」とされている。各ゲームの導出モジュールは、その数値をロール、カード、または倍率にマッピングする。

検証手順は、実際のラウンドでこれら3つのステップすべてを行う。まだやったことがなければ、一度試してみてほしい。この仕組みのポイントは、あなたが毎ラウンド確認することではなく、いつでも確認できるということであり、ハウス側はあなたがいつ確認するか事前に知ることができない、という点にある。

証明できない3つのこと

シードがランダムであったことを証明できない。コミットメントはシードを固定するが、そのシードがどのように選ばれたかについては何も語らない。もしハウスがサーバーシードを生成する時点であなたのクライアントシードを知っていたなら、原理的には気に入った最初のラウンド結果になるまでシードを生成し続け、そのシードをコミットすることができてしまう。ハッシュは完璧に一致するだろう。標準的な防御策は順序である。サーバーシードが先にコミットされ、クライアントシードはその後に設定される。これにより、ハウスが何をコミットしたにせよ、それが何と組み合わされるかを事前に知ることはできない。

その順序こそが、このサイトのパネルにおいて明確に指摘すべき境界線がある部分だ。ここでクライアントシードを設定しても、現在のサーバーシードがそのまま残るわけではない。ペアがローテーションされ、新しいサーバーシードはあなたの新しいクライアントシードを運ぶのと同じリクエストによって生成される。クライアント側からは、新しいシードがリクエストが読み取られる前に固定されていたことを示すことはできない。一部の運営者が行っているように、サーバーが次のコミットメントを事前に公開する形で次のシードを事前生成しているかどうかは、クライアントのAPIからは見えず、照合できる「次のサーバーシードハッシュ」フィールドも存在しない。この点はゲームチームに提起済みであり、修正は小さなもので済む。ペアとなるクライアントシードが受け入れられる前に次のサーバーシードをコミットし、そのコミットメントをパネルに表示すればよい。

エンジン検証済み_shared/seedApi.ts: setClientSeed(clientSeed) は新しいクライアントシードで renewRandomKey を呼び出し、nonce 0 の新しいペアを返す。rotate() はシードなしで同じエンドポイントを呼び出す。IHouseSeed には serverSeedHashed、clientSeed、nonce に加え、ローテーション時の直前のペアが含まれるが、次のシードコミットメントはこの型に含まれていない。

それまでの間、実用的な防御策は、この仕組みが他のあらゆる面ですでに提供しているものと同じだ――公開だ。あなたのクライアントシードに対してシードをグラインドするハウスであっても、ローテーション時には各シードを公開しなければならず、そのシードの下でのすべてのラウンドは再計算可能だ。この境界線が意味するのは、シード変更直後の最初のラウンドにおける疑わしい連続結果は、ハッシュだけでは排除できないということだ。それは公開後に、ラウンドごとに検証することでしか調べられない。

別の意味でゲームが公正であることを証明できない。「プロバブリーフェア」とはランダム性が誠実であったことを意味するのであり、オッズが五分五分であることを意味するのではない。サイコロゲームは完全に検証可能でありながら、設計上99%のRTPを返すこともあり得る。エッジは公開されているペイアウトテーブルに存在し、それは別の約束事だ。ハウスエッジの倫理はその約束についてのものであり、コミットメントはそれについて何も語らない。

誰も確認しないラウンドについては何も証明しない。この仕組みは抑止力であって、保証ではない。あなたが一度も再計算しないラウンドは、他のどこでもそうであるように、信頼に基づいて受け入れたラウンドだ。変わったのは、その信頼が任意であり、ハウスがあなたがいつそれを行使するかを知ることができない、という点だ。これはあなたが中を見ることができないシャッフルマシンに対する大きな改善だが、「証明」という言葉が示唆するほどのものではない。

ハッシュはランダム性に対する領収書だ。ゲームに対する証明書ではない。覚えておくべき一文

何がより多くを証明するか

• 事前にコミットされた次のシード。クライアントシードとペアになる前に次のサーバーシードのハッシュを公開することで、上記の順序に関するギャップが閉じられる。これはパネルが、あなたの入力が知られる前にシードが固定されていたことを証明できるようにする、唯一の変更点だ。
• 公開されたランダム性の源。drand ネットワークのような誰も制御できないビーコンを混ぜることで、誰がシードを選んだかという問題そのものがなくなる。drand の内部ではその仕組みとコストについて説明されている。
• 公開され、公開され続ける導出方法。これはすでにここで実現されていることであり、クライアントが書き換えられたときに最も失われやすい部分でもある。検証者は、それが実行するコードと同じだけしか誠実になれない。

これらの変更はいずれも、ハッシュが何であるかを変えるものではない。変えるのは、ハッシュが何の指紋であるか、そしていつの指紋であるか、ということだ。この仕組みはシンプルであるがゆえに、その限界もシンプルだ。それが証明する3つのことを知っているプレイヤーは、すべてを証明すると言われたプレイヤーよりも有利な立場にいる。

よくある質問

プロバブリーフェアなカジノにおけるハッシュコミットメントとは何か？

プレイ前に表示され、公開時にシードと照合される、ハウスの秘密のサーバーシードのSHA-256の指紋のことだ。これは、あなたの賭けの前にシードが固定されていたこと、そして公開されたシードがコミットされたものと同一であることを証明する。

一致するハッシュはゲームが公正であったことを証明するか？

それは、コミットメント後にランダム性が改ざんされなかったこと、そして公開された導出方法があれば各結果がシードペアから導かれることを証明する。シードがランダムに選ばれたことは証明しないし、ハウスエッジについては何も語らない。それは別に公開されている数値だ。

ハウスは自分に有利なサーバーシードを選べるのか?

選ぶ際にペアとなるクライアントシードを知っている場合のみ可能です。防御策は、クライアントシードが設定される前にサーバーシードをコミットすることです。このサイトではクライアントシードの変更が同一リクエスト内でペアをローテーションするため、その順序をクライアント側から確認することはできません。この記事では、その境界線と提案されている修正方法について説明します。

自分でラウンドを検証するにはどうすればいいですか?

シードをローテーションして引退したサーバーシードを明らかにし、それをハッシュ化して提示されたコミットメントと一致するか確認します。次に、サーバーシードを鍵としてクライアントシード、ノンス、カーソルに対するHMAC-SHA256を再計算し、その結果をゲームの公開された導出方法に通します。シードパネルはこの再計算をあなたのブラウザ内で実行します。

導出コードが重要なのはなぜですか?

ハッシュはシードを固定するだけだからです。シードをロールやカードに変換するのは関数であり、その関数が公開されていない限り、ハッシュが一致していても結果がそのシードが示すものだったかどうかは何もわかりません。ここではクライアントがデモで結果を生成するのと同じ導出コードを配布しています。

プロヴァブリーフェアはライセンス済みRNG監査より優れていますか?

それぞれ異なる問いに答えるものです。監査は多数の抽選にわたる生成器の統計的挙動を証明するものであり、コミットメントは事後に特定のラウンドを検証できるようにするものです。どちらも他方の代わりにはならず、どちらもハウスエッジを変えるものではありません。

出典と参考文献

• Wikipedia — コミットメントスキーム:隠蔽性と拘束性、およびハッシュベースのコミットメント
• Wikipedia — HMAC:鍵付きハッシュとその疑似乱数関数としての利用
• Betkyoエンジンのソース: _shared/seedApi.ts(コミット、リビール、ローテーション)、_shared/rng.ts(sha256Hex、hmacSha256Utf8、7バイトの一様分布)、_shared/demoLocal.ts(uAt導出)、_shared/SeedPanel.tsx

この記事で扱うゲームDice — ルール&無料プレイ →Limbo — ルール&無料プレイ →