暗号化コントラクトに必要な証拠と開示のルール

Fhenixが2026年10月20日に公開した技術記事は、暗号化された値を扱うコントラクトの安全性を論じている。注目すべき点は、暗号技術に偏りがちな議論をアプリケーション設計へと戻していることだ。Fhenixの技術記事

機密性を備えたオンチェーンアプリを検討する企業は、まず他の参加者に何を知らせないのかを決める必要がある。次に、それでも参加者が何を検証できなければならないのかを決める。この二つの要件は緊張関係にある。調達では競合する入札価格を隠しながら、事前に公表した選定規則に従ったと示す必要がある。価格を隠しても、誰が規則を書き、誰が変更でき、紛争時に誰が結果を確認できるのかという問題は残る。

本稿は分析の枠組みであり、特定の実装に対するセキュリティ評価ではない。アーキテクチャ文書が示すのは設計上の説明であって、実装に欠陥がないことの証明ではない。また、ある種類のシステムを扱う研究から、特定の製品に脆弱性があるとは結論できない。

入札価格を隠しても、取引規則は必要になる

暗号化された入札を使う調達担当者を仮に考えてみよう。供給業者は競合相手が読めない価格を提示し、購入者は納期と品質の条件を満たす最安値を選びたい。機密性には明確な商業上の理由がある。一件の契約を競うためだけに、供給業者が価格戦略全体を明らかにする必要はない。

しかし、最も小さい数値が業務上の正解とは限らない。通貨が違う、送料が含まれない、納期が条件に合わない、といった可能性がある。暗号化された算術が完全に正しくても、比較すべきでない入力同士を比較してしまうことはある。そのため、計算を始める前に有効な提案を定義しなければならない。暗号化は、納品の約束が信頼できるか、仕様が購入者の実際の需要を反映しているかを判断してくれない。

出力にも選択がある。購入者が必要とするのは、落札者と最終支払額だけかもしれない。全参加者に完全な順位を知らせれば、取引に必要な範囲を超えて商業情報を開示することになる。一方、開示が少なすぎれば、落選した業者が一貫性のない判断に異議を申し立てられない。適切な開示方針は、紛争処理を含む取引の目的から導くべきであり、暗号方式だけでは決まらない。

計算の正しさと判断の妥当性を分ける

2023年1月17日に提出された研究論文「Verifiable Fully Homomorphic Encryption」は、計算の完全性を独立した問題として扱い、悪意ある実行への対策を研究している。これは過去の技術研究であり、現在のCoFHE実装についての指摘ではない。研究論文

仮想的な入札では、二種類の保証を分けることが重要になる。技術的な検証は、指定した入力に対して指定した操作が行われたかを問う。業務の審査は、その入力と操作が合意した調達規則を表していたかを問う。前者の証明を、後者の代わりにすることはできない。古い参加資格を正確に実行する暗号化比較は、商業上受け入れられない業者を選びかねない。

この区別は証拠の整理方法も変える。有用な審査記録では、規則の版、受理した入力集合、検証する計算、最終的に開示した結果が結び付いている必要がある。文脈から切り離された暗号学的なチェックは、数学的に意味があっても購買判断の説明には不十分かもしれない。これは証拠設計についての本稿の分析であり、特定のプロトコルがすべての記録を自動的に提供するという主張ではない。

調達チームは稼働前に、その記録を誰が説明するかも合意しておく必要がある。技術担当者はプログラムの動作を確認できても、商業上の例外を解釈する権限を持たないかもしれない。業務責任者は調達目的を説明できても、証明がどの条件を対象にするかを知らないかもしれない。双方の責任を「システム検証済み」という一つのラベルにまとめれば、後の紛争解決は難しくなる。

権限設計も製品の一部である

Zamaの現行ACL文書は、暗号文に対する持続的な権限と、その取引の間だけ有効な権限を区別する。値を公開復号できるようにする権限も別に説明している。これらは異なるアプリケーション上の選択だ。ZamaのACL文書

調達チームは、全プラットフォームが同じ制御を備えると考えずに、この区別を自社の要件整理に使える。計算サービスには一件の処理だけの一時的な権限、監査担当者には特定の委託範囲に限った閲覧、サポート担当者には個別の問い合わせを解決するための情報だけが必要かもしれない。三者に同じ広い権限を与えれば管理は簡単になるが、機密性を採用した当初の目的を損なう。

権限範囲は通常の組織変更にも耐える必要がある。供給業者がアカウントを変更する、監査契約が終わる、購入者が外部運営会社を交代させる、といった変化だ。設計で問うべきなのは、権限を付与できるかだけではない。影響するデータを特定でき、変更にできることとできないことを把握できるかが重要になる。将来のアクセスを止めても、受領者がすでに得た平文を忘れるわけではない。基盤の計算が暗号化されたままでも、出力した報告書や画面の保存は運用上のプライバシー管理に含まれる。

権限の点検を初回の連携で終えることもできない。結果表示だけを目的としたサービスが、後から分析やデータ出力を追加する場合がある。技術的な不具合でなくても、データに触れる人やシステムは変わり得る。企業は以前の審査にいつまでも依存せず、業務範囲の変化を把握したうえで権限を見直すべきか判断する必要がある。

将来構想ではなく現在のシステムを評価する

CoFHEの現行Teecryptor文書は、証明付きの信頼実行環境内で復号すると説明している。複数当事者による閾値復号は、将来の置き換えとして示されている。現在の設計とロードマップは区別すべきだ。CoFHEのTeecryptor文書

この留保は、ハードウェアに関する前提のあるシステムを否定するものではない。企業は利益に見合うなら技術的な依存を受け入れている。必要なのは宣伝上の分類ではなく、実際の依存関係を比べることだ。購入者は、どの部品が稼働し続ける必要があるか、その運用を支える証拠は何か、必要なサービスが結果を返せない場合に何が起きるかを理解する必要がある。

入札では、価格の漏洩も計算ミスもなくても、結果を取得できなければ契約の決定が遅れる。あらかじめ決めた延期や中止の手順は、その場しのぎで開示範囲を広げる対応より有益かもしれない。ただし、供給業者が生産能力を長く確保する必要があるなど、手順にも商業上の費用がある。機密性、可用性、契約の時間条件は、別々のチームが独立に評価して終わるのではなく、前提を突き合わせる必要がある。

暗号化計算の強い利点は、基になるデータをすべて配布しなくても協力できることにある。情報開示自体が競争上の負担を生む場面では、具体的な価値になる。隠す事実、検証できる結論、変更や例外への決定権を保持する人が明確なら、その価値も評価しやすい。

したがって初期導入は、暗号化計算の実演だけでなく、取引全体と現実的な紛争を通して評価すべきだ。無関係な入札価格を暴露せずに争われた結果を説明でき、処理が止まっても当初の開示制限を守れるなら、技術は明確な業務需要に応えている。特定の実装がそこまで達成しているかは、証拠と試験によって判断することであり、FHEという名称から導ける結論ではない。