既知の制約

このページは、daqq の現状の設計における未解決の問題、公平性に関する注意点、セキュリティ上のトレードオフをまとめたものです。各項目は何が問題か、今日どれくらい深刻か、ネットワークが成長したり別のプロブレムクラスが追加されたりすると何が変わるかを記載します。

深刻度の評価：

• Low — 原理的には観測可能だが、現在の規模や出荷済みプロブレムでは現実的な影響なし。
• Medium — 特定の機能（例：提出締切）が導入されると公平性や正しさに影響する可能性あり。
• High — コアな性質（シードの予測不可能性、台帳の整合性等）を壊す。

出荷コードに High 深刻度の問題は現在ありません。以下はすべて Low か Medium であり、将来のコントリビュータが同じ罠を踏まないように文書化されています。

1. 同時性：実際に誰が最初に計算を開始するか？

問題。 ビーコンがブロック H = 50·(R+1) の EndBlocker で Seeds[R] を確定するとき、シードは論理的にすべてのノードで同じ高さで利用可能になります。実際には、すべてのノードはブロック H を CometBFT の p2p ゴシップネットワーク経由で異なる遅延で受け取ります（よく接続されたノードは周辺ノードより数十〜数百ミリ秒早く受け取ります）。ブロック H の処理を最初に終えたノードは、Seeds[R] でシードされた量子アルゴリズムを最初に走らせ始められます。

今日の大きさはどれくらいか？

• 出荷済みの random_circuit プロブレムには提出締切がありません。結果が次のラウンド前（あるいはもっと後）に着く限り、早く始めても何も得られません。深刻度：Low。
• 量子シミュレーション／実行は典型的にはブロック伝搬ジッタ（〜数百ミリ秒）より桁違いに長い時間（秒〜分）かかります。先行きはノイズの中です。
• daqq には報酬がないので、「誰が先か」は経済的な優位に変換されません。

重要になる場合。

• ラウンドごとの提出締切を持つ将来のプロブレムは、中央寄りに位置するノードを有利にします。
• 壁時計の遅延を記録する将来のプロブレム（例：ハードウェア速度を比較するランダム化ベンチマーク）は、「速いハードウェア」と「速いゴシップ経路」を混同します。

もし実際に問題になった場合の緩和策。

• 提出受け付けをシード確定から k ブロック遅らせる。任意の現実的な k≥2 に対して、すべてのノードは H+k までにブロック H を持っているため、ゴシップジッタが隠せます。
• 提出が固定の m でブロック H+m でコミットし、実際のペイロードは H+m+n でリビールするように要求する — つまり結果側でコミット・リビールを鏡映する。
• 遅延に敏感な実験では、各ノードについて (seed_available_at_block, submitted_at_block) を記録し、壁時計ではなくブロック差分を遅延指標とする。

2. シード予測可能ウィンドウ（ブロックオフセット 46 – 49）

問題。 リビールはオフセット 45 以降拒否されますが、シードがオフセット 50 の EndBlocker まで Seeds[roundID] に公式に格納されません。その間の 4 ブロックの間、すべての受理されたリビールはすでにオンチェーンにあり、シードは単に SHA256(XOR(reveals)) です — チェーンが発表する前に誰でもローカルで計算できます。コンセプト → 1 ラウンドのライフサイクル を参照。

今日の大きさはどれくらいか？

• 問題 #1 と同じ論理：出荷済みのプロブレムには締切がないため、「シードが 4 ブロック早い」ことに価値はありません。深刻度：Low。

重要になる場合。

• 問題 #1 と同じ条件（締切または遅延に敏感なプロブレム）。

緩和策。

• RevealEnd を RoundDuration - 1（オフセット 49）に移動して、ギャップをゼロに縮める。
• またはこのウィンドウを受け入れ、すべてのプロブレム提出を Seeds[R] が書き込まれたこと（コードはすでに GetSeed でこれを行っている）にゲートする。

3. ラストリビーラーのwithholding（RANDAO バイアス）

問題。 参加者は、リビールする前に SHA256(XOR(others' reveals XOR my secret)) を計算してシードがどうなるかを見られます。結果を好まない場合、単にリビールしないこともできます。すると彼らの秘密は XOR から除外され、シードは代わりに SHA256(XOR(others)) になります。これは、withholder に自身のアイデンティティごとに二者択一の選択肢を与えます。

今日の大きさはどれくらいか？

• 攻撃者が m 個の管理アイデンティティを持つ場合、ラウンドごとに 2^m 個の可能なシードから選べます。
• 暗号学的な予測不可能性に対する深刻度：Low — 2^m は 2^256 の隣に置けば微小です。
• プロブレム固有のバイアスに対する深刻度：プロブレム次第。random_circuit では、出力分布のバイアスは本質的に検出不可能です。「興味深い結果」がシード空間の小さな部分集合に存在する将来のプロブレムでは、攻撃者がそちらに寄せられます。

緩和策。

• withholder をスラッシュする（ステーク／ペナルティ機構の導入が必要で、daqq の無報酬設計と相容れない）。
• VDF を上に重ねる：シードを VDF(SHA256(XOR(reveals))) とし、リビール窓より長い遅延を入れる。これにより withholder はリビールしないことの結果を決定前に予測できなくなる。MVP では範囲外。

4. 空のラウンド（リビールが全くない）

問題。 あるラウンドが有効なリビール 0 件で閉じる場合、abci.go は Seeds.Set 呼び出しを完全にスキップします — そのラウンドの Seeds[roundID] は単に存在しません。そのラウンドへのプロブレム提出は ErrSeedNotReady で拒否されます。

今日の大きさはどれくらいか？

• 深刻度：Low。チェーンは進行し続けます；そのラウンドだけがシードを生成せず、したがってプロブレム結果も出ません。ラウンド R+1 はすぐに始まります。
• これは無言です：今のところ「ラウンドスキップ」の明示的イベントはありません。

重要になる場合。

• 「1 ラウンド = 1 シード」を仮定する統計分析は、欠損ラウンドをフィルタする必要があります。
• 長時間実行ツールは、スキップされたラウンドの Seeds[R] を無限に待つべきではありません。

緩和策。

• count == 0 のとき EndBlocker で RoundSkipped{R} イベントを発行する。
• 連続性を仮定するコードを追加する前に、SDK クライアントに「スキップされたラウンド」のセマンティクスを文書化する。

5. ラウンドごとの参加コスト

問題。 参加するすべてのノードは、実際の量子計算をする前に、シードに寄与するためだけにラウンドごとに2 つのトランザクション（MsgCommit 1 つ、MsgReveal 1 つ）をブロードキャストする必要があります。RoundDuration = 50 と数秒のブロック時間で、それは数分ごとに 1 ラウンドです — 管理可能ですが無料ではありません。

今日の大きさはどれくらいか？

• 小さな実験ネットワークでの深刻度：Low。tx ボリュームはコミット/リビールではなくプロブレム提出が支配的です。
• daqq には手数料市場がないため、コストは金銭的ではなく運用的（稼働時間、鍵の管理）です。

重要になる場合。

• 数千のバリデータを持つネットワークでは、オンチェーンの状態が比例して増えます。Commits と Reveals のコレクションは (ラウンド × 参加者) で成長します。

緩和策。

• Seeds[r] が確定した後に Commits[r] と Reveals[r] をプルーンする（シードだけが永続的な成果物）。
• 複数ラウンドにわたるバッチコミット・リビールを許す。

6. プロブレムモジュールに提出締切がない

問題。 random_circuit.MsgSubmitResult は、Seeds[R] が存在する限り、ラウンド R の結果を後の任意のブロックで受理します。遅延カットオフはありません。

今日の大きさはどれくらいか？

• 深刻度：Low。台帳が最大限に包括的になります：オフラインだったノードでも来週ラウンド 42 の分布をバックフィルできます。状態ストレージのコストだけが下手な点です。

重要になる場合。

• 「ライブ」な結果を比較するプロブレム（例：量子ハードウェアの利用可能ウィンドウ）は締切を望みます。

緩和策。

• x/problems にプロブレムごとの submission_deadline_blocks パラメータを追加する。導入時は先に問題 #1 と #2 を読むこと — 締切が現実になった瞬間、それらは Medium 深刻度になります。

7. リビールのハッシュ規約

問題。 msg_server_reveal.go は sha256.Sum256([]byte(msg.Secret)) を計算します — つまり、生の 32 バイトではなく秘密のhex 文字列のバイトをハッシュします。次に abci.go の集約は、XOR のために同じ秘密を 32 生バイトに hex デコードします。つまりオンチェーンのチェックは「hex 文字列にコミットしたか？」で、オンチェーンの利用は「生バイトを XOR する」です。機能的には整合的ですが、二つの表現が混在しています。

今日の大きさはどれくらいか？

• 深刻度：Low。動作はします。セキュリティの損失なし — hex 形式にコミットすることは生形式にもコミットすることと同じです。
• リスクは明確さにあります：「コミットは生バイトをカバーする」と仮定する将来のコントリビュータがひそかにプロトコルを壊す可能性があります。

緩和策。

• 一つの表現（生バイト推奨）を選び、keeper の中ではなく SDK の境界で変換する。
• commit = sha256_hex(secret_hex) を固定するテストを追加して、規約をロックする。

8. バリデータのオンボーディングと stake 供給

問題。 新しいバリデータが合意に参加するには bonded な stake が必要ですが、genesis は初期 stake の全量を少数の固定アカウント（alice / bob / carol）に配分しています。新規参加者に自動で stake を渡す経路は組み込まれておらず、「N 番目のバリデータはどうやって stake を得るのか」は、解決済みの仕組みではなく未解決のガバナンス問題です。

さらにややこしいことに、このチェーンは現在Cosmos SDK 標準の mint モジュールをインフレ有効のまま動かしています（約13%/年、年間で数千万 stake 規模を新規発行し、そのうち2%が community_tax 経由で community pool に流入）。ここから2つの誤解しやすい事実が導かれます：

• stake は固定ではない — 供給は毎ブロック増える。だから「配る stake が枯渇する」という素朴な心配は、今日時点では文字通りには当てはまりません。
• しかし新規発行分は新規参加者には届かない。 デフォルトでは、発行されたインフレ分は既に bonded なバリデータ／委任者に、その保有比率で配分されます。放置すれば新規バリデータの資金にはならず、genesis アカウントに stake が集中（rich-get-richer）します。

加えて明記すべき設計上の不整合があります：daqq は無報酬チェーンと説明されていますが、実際にはインフレが動いて本物のステーキング報酬を支払っています。ここでの「無報酬」は「stake に市場価値が無い／取引可能な資産ではない」という意味に読むべきで、「発行が起きない」という意味ではありません。コードと理念の折り合いはまだ付いていません。

今日どれくらい大きいか？

• 深刻度：中 — コードのバグではなく、台帳の完全性やシード予測不可能性への影響もありませんが、「誰でもバリデータになれる」方向を塞ぎ、経済モデルを未規定のままにしています。
• 現在の規模（bonded バリデータ2つ）では見えませんが、独立したバリデータをオンボードしたい瞬間に現実になります。

いつ問題になるか。

• permissionless もしくは準オープンな検証への移行時（Issue #3 も参照 — オープンなバリデータ集合は RANDAO の withholding を安くします）。
• 長期の分散化：オンボーディング経路が無ければ、バリデータ集合は genesis アカウントに固定されたままになります。

緩和策／方向性。

• community pool からガバナンスで新規に交付する。 MsgCommunityPoolSpend により、通常の提案→投票→支払いで新規バリデータへ bonded stake を交付できます。これは既に存在する中で最も permissionless に近い入口で、2% の community_tax がプールを補充し続けます。
• stake を報酬ではなく参加トークンとして扱う。 無報酬の意図を文字通り貫くなら、インフレを 0 にして genesis 供給を凍結し、審査済みバリデータへ定額の「入場券」をガバナンス経由で発行する（経済的ゲートではなく ID／Sybil コストによるゲート）。これがコードと設計思想を整合させ、permissionless の議論とも噛み合います。
• いずれにせよ docs とパラメータを整合させる。 (A) ゼロインフレ＋ガバナンス発行の参加トークン、か、(B) インフレ維持＋community pool をオンボーディング資金とみなす、を明示的に選び、Cosmos のデフォルト任せの偶然にしないよう文書化する。

範囲外／問題ではないもの

読者がときどき尋ねるが、ここでは問題ではないこと：

• proof-of-quantumness なし。 daqq は参加者が実際に量子計算機を走らせたかを検証しません；提出されたものを記録するだけです。これは意図的です — 価値は共有された再現可能な記録であり、判定ではありません。
• バリデータの中央集権化。 Cosmos SDK のガバナンス／ステーキングは通常通り適用されます。daqq は標準的なバリデータ経済性を継承します；新規バリデータへの資金供給（と、それが無報酬の理念とどう折り合うか）は「報酬が無いから関係ない」と手を振って済ませるのではなく、上記 Issue #8 として扱います。
• ネイティブトークンなし。 バグではなく機能として扱われます — stake は市場価値を意図しない参加／合意トークンです。概要 → なぜ報酬がないのか？ と Issue #8 を参照してください。