MiMCハッシュ

MiMCハッシュとは？

MiMCハッシュは、ゼロ知識証明システムやその他の算術回路環境で効率よく動作するよう設計された暗号学的ハッシュ構成です。

MiMCはMinimal Multiplicative Complexityの略です。

この名称は、回路内で表現した場合に、従来のハッシュ関数と比べて乗算演算を非常に少なくするという主な設計目標を表しています。

暗号資産分野では、MiMCハッシュはSNARK、STARK、MPCシステム、プライバシー重視のブロックチェーンアプリケーション向けのZKフレンドリーなハッシュ関数として論じられることが多くあります。

ASIACRYPT 2016のMiMC論文情報では、MiMCは乗算の計算量を抑えたブロック暗号および暗号学的ハッシュ関数の提案として説明されています。

SHA-256やKeccakとは異なり、MiMCは通常のソフトウェアにおけるCPU上のハッシュ速度を主な目的として設計されたものではありません。

すべての乗算制約が証明生成コストを増やす可能性のある環境向けに設計されました。

このため、MiMCはプライベートデータを明かさずに命題を証明するゼロ知識証明を利用するブロックチェーンシステムにとって重要です。

暗号資産におけるMiMCハッシュの重要性

暗号資産の多くのアプリケーションでは、ゼロ知識回路内でハッシュ関数を使う必要があるため、MiMCハッシュは重要です。

ゼロ知識回路を使うと、ユーザーが秘密を知っていること、コミットメントを所有していること、Merkleツリーに含まれていること、スマートコントラクトのルールに従っていることなどを、秘密の入力を明かさずに証明できます。

従来のハッシュ関数は、多くの有限体ベースの証明システムでビット演算を効率よく扱えないため、回路内で高いコストがかかる場合があります。

MiMCは、多くの証明システムで使われる数学的環境である有限体上で自然に動作するよう設計されています。

MiMCのリファレンスページでは、MiMCはSNARKアプリケーション向けに特化して設計されたブロック暗号およびハッシュ関数ファミリーと説明されています。

ハッシュ回路のコストが低ければ、証明生成時間の短縮、証明コストの削減、プライバシーアプリケーションの実用性向上につながる可能性があります。

MiMCハッシュは、ZKフレンドリーなハッシュ関数という広い分野の形成に寄与しました。

新しいZKフレンドリーハッシュが選ばれる場合でも、MiMCは歴史があり、研究が進み、広く参照されているため重要です。

MiMCハッシュの仕組み

MiMCハッシュは、有限体上の単純な代数演算で構成されます。

有限体とは、加算、減算、乗算、除算が厳密な剰余演算のルールに従う数学的な集合です。

中核となる考え方は、ラウンド定数や鍵に似た値を使って、単純なべき乗関数を繰り返し適用することです。

MiMCのリファレンスページでは、中核となる処理は有限体上で計算される関数

と説明されています。

実装によっては、体やセキュリティ要件に応じて

やなど、別の指数を使う場合があります。

入力は複数のラウンドで変換されます。入力と出力の内部的な関係を知らなければ、最終出力は予測できないように見えるはずです。

MiMCをハッシュ関数として使う場合、スポンジ構成に組み込まれることがよくあります。

スポンジ構成では、入力の有限体要素を内部状態に吸収し、その状態から出力の有限体要素を絞り出します。

circomlibのMiMCSponge回路は、スポンジ構成を用いたハッシュとしてMiMC-2n/nを実装しています。

MiMCハッシュと最小乗算計算量

最小乗算計算量とは、関数を表すために必要な乗算演算の数を減らすことを目指す設計方針です。

多くのゼロ知識証明システムでは、回路コストを乗算に似た制約の数で測るため、これは重要です。

通常のプログラミング環境では、ビット演算型のハッシュ関数が高速で実用的な場合があります。

一方、ZK回路では、各演算が正しく実行されたことを証明する必要があるため、ビット演算のコストが高くなる場合があります。

MiMCは、より少ない制約で表現できる単純な代数的べき乗写像を使います。

MiMCの論文情報では、線形計算のコストが比較的低いMPC、完全準同型暗号、ゼロ知識証明の用途を念頭に、乗算計算量を抑える設計が提案されたと説明されています。

簡単に言えば、MiMCは証明の中でコストの高い部分を小さくすることを目指しています。

そのため、MiMCは単に高速なハッシュではなく、ZKフレンドリーなハッシュと呼ばれます。

MiMCハッシュとゼロ知識証明

ゼロ知識証明では、ある当事者が、命題の根拠となる秘密データを明かさずに、その命題が真であることを証明できます。

コミットメント、Merkleパス、ヌリファイア、非公開のアカウントデータを含む命題では、ゼロ知識証明内でMiMCハッシュを使うことができます。

2024年のMiMCの高速化に関するAMAZE論文では、MiMCは単純な代数構造を持ち、ZKP用途に適した、成熟したZKフレンドリーハッシュと説明されています。

ZK回路では、秘密の入力が公開コミットメントにハッシュされることを証明するためにMiMCを使う場合があります。

公開するMerkleパス全体を明かさずに、リーフがMerkleツリーに含まれることを証明するために使うこともできます。

MiMCは算術演算に適しているため、主にビットレベルのソフトウェア性能を目的に構築されたハッシュよりも、制約の数を減らせる場合があります。

制約数が少なくなれば、証明生成の高速化やコスト削減につながる可能性があります。

証明時間や検証コストが実際のユーザー体験に影響するブロックチェーンシステムでは、特に重要です。

MiMCハッシュとSNARK

SNARKはゼロ知識証明システムの一種で、多くの場合、計算を算術回路として表現します。

多くのSNARK環境では、加算や定数演算に比べ、乗算制約のコストが高くなります。

ZKフレンドリーハッシュ関数に関する調査記事では、R1CSベースのSNARK環境におけるコストは制約の数によって決まると説明されています。

MiMCは制約数を抑えるよう設計されました。

そのため、繰り返しハッシュ処理を行う必要があるSNARK回路に適しています。

Merkleツリーの証明、プライベート送金システム、認証情報システム、匿名メンバーシップシステムでは、繰り返しハッシュがよく使われます。

ハッシュ1回あたりのわずかな節約でも、回路内で数百回、数千回とハッシュ処理を行う場合には大きな削減になります。

MiMCがSNARKに適しているのは、証明システムが自然に表現できる数学を使っているためです。

MiMCハッシュとSTARK

STARKもゼロ知識証明システムの一種で、代数的な実行トレースと多項式制約を使います。

MiMCは単純な代数的ラウンド構造を持つため、STARKの文脈でも取り上げられることがあります。

MiMCのリファレンスページは、SNARK、STARK、MPCに適した共通鍵暗号を扱う広範なサイト上に掲載されています。

STARK型システムでは、制約の次数や実行トレースのサイズが性能に大きく影響する場合があります。

べき乗を使うシンプルなラウンド関数は、ビット演算の多い従来型ハッシュ関数よりも表現しやすい場合があります。

ただし、MiMCが常にSTARKに最適なハッシュであるという意味ではありません。

MiMCは、算術化を念頭に置いた暗号プリミティブの広い設計群に属するということです。

開発者は、証明システム、体、セキュリティレベル、実装の成熟度に合ったハッシュを選択する必要があります。

MiMCハッシュと有限体

MiMCハッシュは、通常の無限整数ではなく有限体上で動作します。

有限体は、値が素数体または二元体の大きさに応じて循環する、固定された数学的領域を回路に提供します。

MiMCのリファレンスページによると、MiMCの計算は

上で行われ、またはとなります。

多くのブロックチェーン証明システムが楕円曲線に関連する素数体を使うため、この点は重要です。

MiMCの実装では、体のパラメーターを慎重に選ぶ必要があります。

ラウンド関数で使う指数も、望ましい暗号学的特性を持つ写像となるよう、その体に適合させる必要があります。

ある体で安全なMiMC設計を、別の体にそのまま流用してはいけません。

体の選択、指数の選択、ラウンド数、定数は、いずれもセキュリティ設計の一部です。

MiMCハッシュとラウンド定数

ラウンド定数とは、MiMCの置換または暗号の各ラウンドで加算される固定値です。

ラウンドが過度に対称的になったり、予測しやすくなったりするのを防ぐ役割があります。

開発者や監査担当者が、悪意のある方法で選ばれたものではないと信頼できるよう、適切な定数は透明性のある方法で生成される必要があります。

多くの実装では、標準的なハッシュ関数を使い、公開シード文字列から定数を生成します。

ZKフレンドリーハッシュ関数の調査記事によると、実装では

やなどの文字列からMiMCのラウンド定数を生成することがよくあります。

開発者は定数の生成方法を正確に文書化してください。

監査担当者は、実装が意図された定数を正しい順序で使用しているか確認する必要があります。

文書化されていない定数があると、暗号実装の信頼性を判断しにくくなります。

MiMCハッシュとスポンジ構成

スポンジ構成は、置換からハッシュ関数を構築する一般的な方法です。

吸収フェーズと絞り出しフェーズで構成されます。

吸収時には、入力値が内部状態の一部に混ぜ込まれます。

絞り出し時には、変換された状態から出力値が生成されます。

ZKフレンドリーハッシュに関する調査記事では、MiMCハッシュは、メッセージブロックを状態の一部に吸収し、MiMC置換で変換するスポンジの枠組みに基づくと説明されています。

スポンジ構成は、可変長の入力と柔軟な出力長に対応できるため有用です。

暗号回路では、複数の有限体要素を一つのコミットメントまたはダイジェストにハッシュするのに役立ちます。

ただし、レート、容量、体のサイズ、ラウンド数などのスポンジパラメーターは慎重に選ぶ必要があります。

MiMCハッシュとSHA-256の比較

MiMCハッシュとSHA-256はどちらも暗号学的ハッシュ関数ですが、異なる環境に最適化されています。

SHA-256は、従来型のソフトウェア、ハードウェア、Proof-of-Workシステムで広く使われています。

MiMCハッシュは、算術回路や有限体ベースの証明システム向けに最適化されています。

SHA-256はビット演算、ローテーション、ブール論理を使うため、回路にすると多数の制約が必要になる場合があります。

MiMCの演算は有限体の算術に適合するため、多くのSNARK環境では回路コストを大幅に抑えられる場合があります。

だからといって、MiMCをあらゆる場面でSHA-256の代わりに使うべきという意味ではありません。

ハッシュをZK回路内で証明する必要がある場合、MiMCの方が適している可能性があるということです。

通常のオフチェーンでのファイルハッシュや、幅広い標準規格との互換性が必要な場合は、従来のハッシュ関数の方が適切な場合もあります。

MiMCハッシュとKeccakの比較

Keccakは、Ethereum型のスマートコントラクトシステムで汎用ハッシュプリミティブとして広く使われています。

MiMCは、ゼロ知識回路内で効率よくハッシュを実行したい場合に選ばれることが一般的です。

既存のアドレス、署名、コントラクトのロジックに合わせる場合、Keccakとの互換性が役立つことがあります。

算術回路で非公開データ間の関係を証明する場合、MiMCの効率性が役立つことがあります。

互換性と効率的な証明の両方が必要な設計では、回路の外側でKeccakを使い、回路内ではMiMCを使う場合があります。

異なるハッシュは異なるコミットメントと信頼の前提を生むため、この使い分けは慎重に設計する必要があります。

MiMCのダイジェストとKeccakのダイジェストが相互に置き換え可能だと考えてはいけません。

適切な選択は、ハッシュをどこで計算し、何を検証する必要があるかによって異なります。

MiMCハッシュとPoseidonの比較

MiMCとPoseidonはどちらもZKフレンドリーなハッシュ関数です。

MiMCはより古く、歴史的に重要なハッシュです。

Poseidonは、算術化を念頭に置いて設計された新しいハッシュであり、入力や証明システムによってはより効率的なため、現代のZKシステムで選ばれることがよくあります。

ZKフレンドリーハッシュ関数の調査記事では、MiMCを最初のZKフレンドリーハッシュ関数と説明し、その後、新しいZKフレンドリーハッシュが提案されたとしています。

ただし、これによってMiMCがあらゆる場合に時代遅れになるわけではありません。

開発者はセキュリティ分析、回路コスト、ライブラリのサポート、監査実績、有限体との互換性、エコシステムの要件を比較する必要があります。

既存のプロトコルでは、導入済みのコミットメントやMerkleルートとの互換性を保つためにMiMCを使い続ける場合があります。

新しいプロトコルでは、ベンチマークと監査を踏まえて、別のZKフレンドリーハッシュを選ぶ場合があります。

MerkleツリーにおけるMiMCハッシュ

MiMCハッシュは、ゼロ知識システムのMerkleツリーでよく使われます。

Merkleツリーは、ノードのペアを繰り返しハッシュすることで、多数の値を一つのルートに集約します。

ユーザーはMerkleパスを示して、リーフがツリーに含まれることを証明できます。

ZK回路では、不要な個人データを明かさずにパスの有効性を証明できます。

ツリーの各階層でビット演算の多い一般的なハッシュを使うと、証明コストが高くなる場合があります。

MiMCを使えば、各ハッシュ処理の制約コストを減らせる可能性があります。

このためMiMCは、プライバシー、ID、投票、メンバーシップ証明の設計で使われます。

Merkleツリーのセキュリティは、正しいハッシュ、正しいツリー構築、正しい回路制約にも依存します。

コミットメントにおけるMiMCハッシュ

コミットメントを使うと、ユーザーは値をすぐに公開せずに固定できます。

秘密の値とランダム性からコミットメントを作るためにMiMCハッシュを使うことができます。

たとえば、プロトコルは秘密のノートの値、所有者キー、ランダムなソルトをハッシュして公開コミットメントを作成する場合があります。

その後、ユーザーはZK回路内で非公開データを知っていることを証明できます。

ハッシュとプロトコルが適切に設計されていれば、公開コミットメントから秘密の入力は明らかになりません。

このパターンは、プライバシー保護型の暗号資産システムでよく使われます。

回路内でコミットメントのハッシュを効率よく検証できることが、MiMCを使う利点です。

少数の秘密の値を推測する攻撃を防ぐため、コミットメント方式には十分なランダム性も必要です。

ヌリファイアにおけるMiMCハッシュ

ヌリファイアとは、元の秘密を明かさずに二重支払いまたは二重請求を防ぐために使われる値です。

MiMCハッシュを使うと、秘密鍵、ノート、IDの値からヌリファイアを導出できます。

非公開の操作を実行する際、プロトコルはヌリファイアを公開できます。

他のユーザーは、同じヌリファイアが以前に使われていないか確認できます。

ゼロ知識証明では、元の秘密を明かさずに、ヌリファイアが正しく導出されたことを示せます。

これは、プライベート送金、非公開の請求、匿名メンバーシップの操作で重要です。

ヌリファイアのハッシュ処理に誤りがあると、ユーザーが二重支払いを行ったり、プライバシーを失ったりする可能性があります。

MiMCはヌリファイアの検証を効率化できますが、プロトコル全体のロジックは慎重に監査する必要があります。

スマートコントラクトにおけるMiMCハッシュ

スマートコントラクトは、MiMCハッシュのコミットメントやMerkleルートを含む証明を検証する場合があります。

コントラクトは隠された値をすべて再計算しなくても、MiMC演算を含む回路から生成された証明を検証できます。

オンチェーンでのハッシュ計算が必要な場合、コントラクトにMiMCを直接実装することもあります。

コントラクトでZKフレンドリーなハッシュと有限体演算が必要な場合、オンチェーンのMiMCが役立つ可能性があります。

ただし、暗号処理のスマートコントラクト実装は、小さなミスでもセキュリティを損なう可能性があるためリスクを伴います。

可能であれば、レビュー済みのライブラリと監査済みの実装を使用してください。

オンチェーン関数が回路内の関数と完全に一致することも確認してください。

回路内のMiMCとコントラクト内のMiMCが一致しないと、証明が失敗したり、セキュリティ上の欠陥が生じたりする可能性があります。

MiMCハッシュとCircom

Circomは、ゼロ知識証明向けの算術回路を記述するために使われる言語です。

circomlibリポジトリには、暗号プリミティブやその他の回路コンポーネントの再利用可能なテンプレートが含まれています。

circomlibには、MiMCSponge回路の実装が含まれています。

多くのZK開発者がすべてのプリミティブを一から作るのではなく、回路ライブラリを利用するため、これは重要です。

ライブラリを使うと開発時間を短縮できますが、監査が不要になるわけではありません。

ライブラリのバージョン、パラメーター、制約、有限体がプロトコル設計と一致していることを確認してください。

最新のライブラリの動作を確かめずに、古いチュートリアルのコードをそのままコピーするのも避けてください。

ZK開発では、ライブラリ関数は回路全体の中で正しく使われて初めて安全になります。

MiMCハッシュと制約不足の回路

制約不足の回路とは、証明すると主張する計算を完全には強制できていないZK回路です。

MiMCなどのハッシュを回路内で使う場合、これは最も深刻なリスクの一つです。

MiMCハッシュの制約バグに関するZK監査チュートリアルでは、制約演算子の代わりに代入演算子を使ったために、MiMCハッシュ回路の制約が不足していた事例が説明されています。

問題は、MiMCの数学的設計が自動的に破られていたことではありません。

回路が出力を意図したハッシュ計算に結びつける制約を欠いていたことが問題でした。

この教訓は、あらゆるZKプロトコルに当てはまります。

回路が実際にハッシュ関数の実行を強制していなければ、強力なハッシュ関数でもプロトコルを保護できません。

ZK開発者は制約をテストし、監査を受け、実用的な場合は形式検証やプロパティベースの検証を行う必要があります。

MiMCハッシュのセキュリティ特性

MiMCハッシュは、選択したパラメーターのもとで、衝突耐性や原像計算困難性などの暗号学的ハッシュのセキュリティ特性を提供することを目的としています。

衝突耐性とは、異なる2つの入力から同じハッシュ出力を見つけることが困難である性質です。

原像計算困難性とは、ハッシュ出力から入力を復元することが困難である性質です。

第二原像計算困難性とは、既知の入力のハッシュ出力と一致する別の入力を見つけることが困難である性質です。

これらの特性は、MiMCの具体的なバリアント、体、指数、ラウンド数、定数、構成方法に依存します。

MiMCのリファレンスページによると、掲載された分析時点では、完全なラウンド数を使うMiMC-n/nまたはMiMC-p/pに対する攻撃は見つかっていません。一方、一部のFeistelブロック暗号バリアントについては問題が指摘されています。

強い暗号学的根拠がない限り、制約を減らすためにラウンド数を削減しないでください。

専門家のレビューなしにパラメーターを変更すると、セキュリティが弱まる可能性があります。

MiMCハッシュとラウンド数

ラウンド数とは、MiMCのラウンド関数を適用する回数です。

ラウンド数を増やすと、通常、暗号解析への耐性が高まる一方で、回路コストも増加します。

ラウンド数を減らすと性能が向上する場合がありますが、セキュリティが低下する可能性があります。

MiMCのパラメーターは通常、有限体のサイズ、指数、セキュリティ分析、構成方法に基づいて選ばれます。

circomlibのMiMCSponge実装には、特定の素数体と指数の選択に対するラウンド数の計算例を示すコメントが含まれています。

だからといって、あらゆるMiMC実装で同じラウンド数を無条件に使うべきという意味ではありません。

ラウンド数は、使用する有限体、指数、構成方法、セキュリティ目標に適合させる必要があります。

監査担当者やユーザーが確認できるよう、プロトコルではMiMCのパラメーターを文書化してください。

MiMCハッシュと指数

指数とは、

、、など、非線形のラウンド関数で使われるべき乗です。

MiMCの元の設計は、

を使って説明されることがよくあります。

一部の有限体では、べき乗写像が適切に機能するよう、異なる指数が必要になります。

ZKフレンドリーハッシュ関数の調査記事では、特定の体を選ぶ場合、

のSボックスをまたはに置き換えることがあると指摘されています。

これは、一般的なペアリングフレンドリー曲線の体上に構築された回路でよく見られます。

すべてのMiMCバリアントが同じものだと考えてはいけません。

指数を変えると暗号学的関数が変わり、必要なセキュリティ分析も変わります。

実装間の互換性を保つには、どの箇所でも同じ指数と定数を使う必要があります。

MiMCハッシュとドメイン分離

ドメイン分離とは、同じハッシュ関数を異なるプロトコル用途で混同を招く形で再利用しないようにすることです。

プロトコルでは、コミットメント、ヌリファイア、Merkleノード、チャレンジ値にMiMCを使う場合があります。

用途ごとに分離せず、すべてが同じ入力形式を共有すると、予期しない衝突やプロトコル上の混乱が生じる可能性があります。

ドメイン分離には、固定プレフィックス、タグ、異なる定数、異なる鍵、構造化された入力形式を使う方法があります。

具体的な方法は、証明システムと有限体の表現に適合させる必要があります。

適切なドメイン分離は、プロトコル監査を容易にします。

ある文脈で有効な値が、別の文脈で危険な形で再利用される可能性も減らせます。

MiMCはプリミティブであり、安全なプロトコルには、そのプリミティブを使う際の慎重な入力設計が必要です。

MiMCハッシュと有限体要素のエンコード

MiMCハッシュが通常受け取るのは有限体要素であり、任意のテキスト文字列を直接処理するわけではありません。

そのため、データのエンコード方法を決める必要があります。

開発者は、バイト列、アドレス、金額、識別子、公開鍵を有限体要素に変換する方法を定める必要があります。

不適切なエンコードは、曖昧さ、切り捨て、オーバーフロー、プロトコル間の混乱を引き起こす可能性があります。

たとえば、プロトコル設計で許容されていない限り、異なる2つのバイト列が同じ有限体要素の列に誤って対応してはいけません。

必要に応じて、入力の長さをエンコードするか、別の方法で曖昧さをなくす必要があります。

すべての実装で、エンディアン、パディング、法による剰余計算、有限体の境界を統一してください。

MiMCのバグの多くは、ハッシュ自体の考え方ではなく、統合作業のミスに起因します。

MiMCハッシュの性能

MiMCハッシュは、コストの高い乗算に似た演算を最小限にするため、算術回路内で効率的に動作します。

これにより、証明生成時間や回路サイズを削減できる可能性があります。

2024年のAMAZE論文では、SHA-2などの標準的な暗号学的ハッシュ関数はZKP分野では非効率となる場合があり、ZKフレンドリーハッシュはZKPの効率を念頭に構築されていると述べています。

同論文は、ZK用途に向けたハードウェア最適化MiMC実装も提示し、テスト環境において標準的なCPU実装を上回る性能向上を報告しています。

これは、現在のZKハードウェアや性能研究においてもMiMCが関係していることを示しています。

ただし、性能は実際に使用するシステムで測定する必要があります。

ある証明システムで効率的なハッシュが、別の証明システムでも最適とは限りません。

ベンチマークでは、証明者の処理時間、検証コスト、制約数、メモリ、実装の成熟度、監査実績を含めて評価してください。

MiMCハッシュの監査要件

本番環境の暗号資産システムで使う場合、MiMCハッシュを監査する必要があります。

監査担当者は、数学的パラメーター、回路制約、入力エンコード、ドメイン分離、実装言語、スマートコントラクトの検証ロジックを確認してください。

回路の出力が、意図したMiMC計算に確実に結びつけられていることを確認する必要があります。

オフチェーンコード、回路コード、オンチェーンコードで、テストベクトルが一致するか比較してください。

定数が正しく生成・保存されているか確認してください。

ラウンド数が有限体と指数に適合しているか検証してください。

ゼロ入力、最大有限体要素、反復入力、可変長データなどのエッジケースをテストしてください。

暗号プリミティブは、実装全体が安全な場合にのみ安全です。

MiMCハッシュとテストベクトル

テストベクトルとは、実装が正しく動作するか確認するための、既知の入出力の例です。

MiMCの実装では、使用するバリアントに正確に対応したテストベクトルを公開または同梱する必要があります。

テストベクトルを使うと、開発者は回路、JavaScript、Rust、Solidity、バックエンドの証明者による実装を比較できます。

同じ入力で2つの実装から異なる出力が得られた場合、少なくとも一方のパラメーターが異なるか、バグがあります。

テストベクトルには、通常の入力、ゼロ入力、境界値、複数入力のスポンジ例を含めてください。

有限体、指数、ラウンド数、定数、入力順序、出力順序、エンコード方法も明記する必要があります。

テストベクトルがなければ、統合作業のミスを見つけにくくなります。

ZKシステムでは、テストベクトルは基本的なエンジニアリング上の必須事項です。

MiMCハッシュと暗号資産ウォレットの安全性

多くの暗号資産ユーザーがMiMCハッシュを直接扱うことはありません。

MiMCを非公開のZK回路内で利用するアプリケーションを使う場合があります。

ウォレットには、証明の生成、請求の実行、プライベート取引の実行だけが表示されることがあります。

MiMCについて学んだり、ZKアプリケーションを使ったりするために、シードフレーズや秘密鍵を提供する必要はありません。

FTCの暗号資産詐欺に関するガイダンスは、詐欺師が偽の案件や暗号資産の支払い要求を使って資金を盗むと警告しています。

偽の証明生成ツール、偽のプライバシーツール、偽のウォレットサポートページに注意してください。

正規のZKアプリケーションがウォレットのリカバリーフレーズを求めることはありません。

MiMCハッシュは暗号ツールであり、ウォレットの秘密情報を知らないソフトウェアに預ける理由にはなりません。

MiMCハッシュと税務上の扱い

MiMCハッシュ自体が課税対象となる取引を発生させることはありません。

これはソフトウェアやプロトコルの内部で使われる暗号プリミティブです。

ただし、MiMCを使うZKアプリケーションでの取引に、デジタル資産が関わる場合があります。

公式のIRSのデジタル資産ページでは、デジタル資産の取引は申告が必要となる場合があり、デジタル資産からの所得は課税対象となる可能性があると説明されています。

暗号資産アプリケーションを使う際は、送金、スワップ、請求、報酬、手数料、タイムスタンプ、ウォレットアドレス、トランザクションハッシュの記録を保管してください。

プライバシー重視のツールを使う場合、自分で記録を保存しないと、個人の取引記録の管理が難しくなる可能性があります。

ゼロ知識取引によって申告義務がなくなると考えてはいけません。

相応の暗号資産取引がある場合は、資格を持つ税務専門家に相談してください。

MiMCハッシュのメリット

MiMCハッシュは、多くのゼロ知識回路内でのハッシュ処理コストを削減できる可能性があります。

SNARK型の制約に適した単純な有限体演算を使います。

乗算計算量の低さを明確な設計目標としています。

Merkleツリー、コミットメント、ヌリファイア、プライベートなメンバーシップ証明に利用できます。

ASIACRYPT 2016での発表以来、研究が続けられています。

ZK回路ライブラリに実用的な実装があります。

現在のZK高速化研究でも引き続き取り上げられています。

主な利点は、算術回路内でハッシュを証明する必要がある場合に、暗号学的ハッシュを効率よく実行できることです。

MiMCハッシュのリスクと制限

MiMCハッシュは、あらゆるハッシュ関数に置き換えられる汎用的な関数ではありません。

一般的なソフトウェア環境では、広く使われている従来型ハッシュほど標準化されていません。

有限体、指数、ラウンド数、定数、構成方法を慎重に選ぶ必要があります。

対象となる有限体を理解せずに実装をコピーすると、安全でない場合があります。

回路の制約が不足している場合も、安全でない可能性があります。

オフチェーンとオンチェーンの実装が完全に一致していない場合も、安全ではない可能性があります。

現代の一部の証明システムでは、新しいZKフレンドリーハッシュの方が効率的な場合があります。

最大の制限は、「MiMC」という名称だけで安全性が決まるのではなく、正しい使い方に依存することです。

暗号資産プロジェクトにおけるMiMCハッシュの評価方法

まず、プロジェクトがどのMiMCバリアントを使っているか確認してください。

有限体、指数、ラウンド数、定数、レート、容量、出力長を確認してください。

レビュー済みのライブラリを使っているか、独自コードを使っているかを確認してください。

回路とスマートコントラクトの実装に対応する公開テストベクトルを確認してください。

プロジェクトがゼロ知識回路に詳しい監査担当者による監査を受けているか確認してください。

MiMCをコミットメント、Merkleツリー、ヌリファイア、署名、ランダムチャレンジ、その他のどの用途に使っているか調べてください。

ドメイン分離と曖昧さのない有限体要素への変換を使って、入力をエンコードしているか確認してください。

MiMCのパラメーターを明確に説明できないプロジェクトには、慎重に対応してください。

MiMCハッシュでよくある間違い

よくある間違いの一つは、すべてのMiMC実装に互換性があると考えることです。

セキュリティレビューをせずに有限体や指数を変更することも避けてください。

制約を減らすためにラウンド数を削減するのも間違いです。

文書化されていないラウンド定数を使わないでください。

プロトコル内の用途間でドメイン分離を忘れないでください。

回路コードとスマートコントラクトコードの不一致にも注意が必要です。

回路制約が必要な箇所で代入を使うことも誤りです。

ZK以外の用途で、MiMCを標準化されたハッシュ関数の汎用的な代替と捉えないでください。

開発者向けのベストプラクティス

MiMCは、証明システムとプロトコルの要件に適合する場合に限って使用してください。

可能な限り、レビュー済みの実装を使用してください。

有限体、指数、定数、ラウンド数、スポンジパラメーター、エンコードルールを文書化してください。

対応するすべての実装についてテストベクトルを公開してください。

すべての回路出力に適切な制約が設定されていることを確認してください。

プロトコル内の異なる用途にはドメイン分離を使ってください。

暗号設計と実装の詳細の両方を監査してください。

新しいプロトコルで採用する前に、MiMCと他のZKフレンドリーハッシュをベンチマークで比較してください。

MiMCハッシュのSEO・AEO概要

MiMCハッシュは、乗算計算量の低さを目指して設計されたZKフレンドリーな暗号学的ハッシュ関数ファミリーです。

MPC、完全準同型暗号、ゼロ知識証明などの環境で、暗号化とハッシュ処理を効率化するために提案されました。

MiMCは有限体上で動作し、体やバリアントに応じて

、、などの単純なべき乗関数を使います。

MiMCハッシュは、入力の有限体要素を吸収し、出力の有限体要素を絞り出すスポンジ構成で構築されることがよくあります。

暗号資産分野では、ZKフレンドリーなMerkleツリー、コミットメント、ヌリファイア、メンバーシップ証明、プライバシー保護プロトコルにMiMCが使われます。

MiMCは、通常のビットレベルのソフトウェア処理ではなく算術回路向けに最適化されている点で、SHA-256やKeccakと異なります。

MiMCの主なリスクには、パラメーターの誤り、制約不足の回路、不適切な定数、弱いエンコード、ドメイン分離の欠如、実装の不一致があります。

MiMCハッシュを安全に使うには、監査済みのパラメーター、レビュー済みのライブラリ、公開テストベクトル、完全な回路制約を利用してください。

よくある質問

MiMCハッシュとは何ですか？

MiMCハッシュは、ゼロ知識証明回路やその他の算術環境で効率よく動作するよう設計された暗号学的ハッシュ構成です。

MiMCは何の略ですか？

MiMCはMinimal Multiplicative Complexityの略です。

MiMCハッシュがZKフレンドリーと呼ばれるのはなぜですか？

多くのゼロ知識証明回路内で効率よく表現できる算術演算を使っているため、MiMCハッシュはZKフレンドリーと呼ばれます。

MiMCハッシュはSHA-256と同じですか？

いいえ。MiMCハッシュは有限体回路向けに設計されています。一方、SHA-256は通常のソフトウェアやProof-of-Workシステムで広く使われる従来型のビット演算ベースのハッシュ関数です。

暗号資産分野ではMiMCハッシュはどこで使われますか？

MiMCハッシュは、Merkleツリー、コミットメント、ヌリファイア、メンバーシップ証明、プライバシー保護アプリケーションのロジックを実装するZK回路で使われます。

MiMCハッシュは有限体上で動作しますか？

はい。MiMCハッシュは、多くの証明システムで使われる素数体などの有限体上で動作するよう設計されています。

MiMCハッシュは常に安全ですか？

いいえ。MiMCの安全性は、具体的なバリアント、有限体、指数、ラウンド数、定数、構成方法、実装の正確さに依存します。

スマートコントラクトでMiMCハッシュを使えますか？

はい。スマートコントラクトシステムにMiMCを実装したり、MiMCを検証したりできます。ただし、オンチェーン実装は回路内の実装と完全に一致する必要があります。

回路内でMiMCハッシュを使う場合の主なリスクは何ですか？

主なリスクの一つは、証明が意図したMiMCハッシュの計算を実際には強制していない、制約不足の回路です。

新しいZKプロジェクトは必ずMiMCハッシュを使うべきですか？

いいえ。新しいZKプロジェクトは、MiMCと他のZKフレンドリーハッシュを比較し、セキュリティ、性能、有限体との互換性、ライブラリのサポート、監査要件に基づいて選択してください。

まとめ

MiMCハッシュは、ゼロ知識を活用する暗号資産システムの歴史と実務において重要な暗号プリミティブです。

乗算の多い演算を最小限にすることで、算術回路内のハッシュ処理コストを減らすよう設計されました。

このため、SNARK、STARK関連の設計、MPCシステム、コミットメント、Merkleツリー、ヌリファイア、プライベートなメンバーシップ証明で役立ちます。

MiMCの強みは、有限体上のシンプルな代数処理と、ZK効率を重視した設計にあります。

一方、あらゆるパラメーターと実装の詳細が重要である点には注意が必要です。

MiMCの実装では、適切な有限体、指数、ラウンド数、定数、スポンジパラメーター、入力エンコード、ドメイン分離を選ぶ必要があります。

MiMCを使うZK回路では、計算が正しく制約されていなければなりません。

ユーザーにとって、MiMCは通常アプリケーションの証明システム内部で動作するため、目にすることはほとんどありません。

開発者にとって、MiMCは慎重なエンジニアリングと監査を要する強力なツールです。

MiMCハッシュは、暗号資産プロトコルが非公開の計算を効率よく証明するための特殊なZKフレンドリーハッシュ関数です。ただし、パラメーターと回路制約を正確に実装することが前提となります。