ゼロ知識証明技術をオープンに
引用元：https://news.ycombinator.com/item?id=44457390
GoogleのGitHubリポジトリはこちらだよ→ https://github.com/google/longfellow-zk
非対話ゼロ知識証明（NIZK）の直感的な説明が欲しいな。対話型のは分かりやすい記事があったんだけど、NIZKのは見つけられなくてさ。Vitalikのブログ記事もピンと来なかったんだ。
年齢証明の例について詳しく知りたいな。誰が検証データを用意するの？どんな形式？誰がデータを持つ？誰が検証ソフトを動かすの？特定の「認定された」実装じゃないとダメ？
質問に答えるね。(1)発行者（DMVとか）が情報を提供。(2)MDOCみたいな既存規格を使う。(3)ユーザーがデバイスだけに保持。デバイス上で証明を生成。(4)サイト側が検証ソフトを動かす。(5)互換性があるなら、どんな実装でもOKだよ。仕様は公開してる。
地域差はあるけど大体こんな感じだよ。政府がMDOCみたいな標準形式の書類をくれる。それをスマホがセキュアエレメントと連携して保管。証明の検証はアクセス先のサイトがやるんだ。政府がどのウォレットに書類を渡すか決めるよ（Google Walletの場合もそうでない場合もある）。
直感的には、ウォーリーの場所を明かさずに、写真の中で見つけたと証明する感じ。デジタルウォレットは署名スキームみたいなもの。レンジ証明は、例えば0か1かを明かさずに証明できるよ。Bulletproofsで効率化されてる。でも、同じ証明を使い回すと追跡される課題があるね。
ありがとう。でも、セキュアエレメントが必要ってことは、GoogleとかAppleがデータを扱う、特定の「認定された」実装が必要になるってこと？自分でドキュメントを持って、信用できるオープンソースクライアントで証明を出すのは無理なの？
返信ありがとう。つまり、MDOCファイルをデスクトップに保存して、動作を確認できるオープンソースライブラリを使って、ウェブブラウザ経由で証明を出せるってことだよね？それならいいな。
チップでリモートコード実行ができちゃったら、プロトコルはまだ安全？もしそうなら、なんでセキュアエレメントで動かす必要あるの？もし安全じゃないなら、一番弱いチップみたいに、どれか一つの秘密鍵が漏れたら、偽の証明をいくらでも作れちゃうんじゃない？
セキュアエレメントの役割は、資格情報をデバイスに「紐づける」だけだよ。コピーしても使えなくするため。ZKPライブラリは普通のCPUで動くんだ。SEが出すECDSA署名とか、発行者の署名とかが有効だって証明を作るの。ZKPライブラリが破られても、間違った証明は検証に失敗するよ。
ウォーリーの例えについて説明するね。ウォーリーの絵が描かれたページと、ウォーリーの形にくり抜かれた大きな紙を想像して。くり抜きの中にウォーリーの絵を見せることで、どこにいるか場所を明かさずに証明できるんだ。これがゼロ知識証明だよ。
もしペンキ缶みたいなレベルの例えを探してるなら、Matthew Greenさんの「クレヨンと帽子」って記事がいいと思うよ: https://blog.cryptographyengineering.com/2014/11/27/zero-kno…
いや、MDOC（モバイル運転免許証）を使うにはスマホのハードウェアセキュリティキーからの署名が必要なんだ。多くの複雑さは、自分を特定するプライベートキーを漏洩させない方法にあるんだよ。
うーん、それは良くないね。僕のスマホはクローズドソースで、ソフトは広告会社が提供してる。それが常に僕の利益になるように振る舞うとは信用できないな。
それは対話型証明の場合だけだよ。コメント主と同じで、僕はそういうのは理解するのに問題ないんだけど。
それは現地の規制によるね。欧州では何らかのウォレットの認可が必要になるみたいだよ。はっきり言うと、政府が独自のアプリを開発するだろうし、Googleが認可されるかは分からないね。僕たち（Google）はプライバシー向上のために無償でコードを提供してるんだ。
理解合ってるかな？
州のDMV（陸運局）から一度証明書をもらったら、その後ウェブサイトに年齢を証明したい時は、デバイスとウェブサイトの間だけでやり取りするの？DMVは僕がどのサイトでその証明書を使ったか、いつ使ったかも知らないの？もしサイトとDMVが協力しても、誰かがその時DMVからの証明書を使ったってことしか分からない？
年齢確認システムの設計を考えたことあるんだけど、毎回DMVが関わる仕組みになっちゃって、タイミング攻撃が問題だったんだ。サイトがトークンを発行し、それをDMVの「この人は18歳以上」サービスに盲目署名してもらって、サイトに返すって流れ。これでもいけると思うけど、サイトとDMVが協力したら、タイミング比較で匿名の利用者特定できちゃう可能性高いんだよね。
DMVから証明書を設定したら、その後DMVが関係なくなるってのは、その問題をうまく解消してくれるね。
ふむ。これってプロトコルに第三者、具体的にはウォレット開発者が入ってくるんだよね？ユーザー、ウォレット開発者、そして証明書を確認する側の3者がいることになる。このゼロ知識証明プロトコルは、確認する側だけでなく、ウォレット開発者からもユーザーのプライバシーを守るのかな？
つまり、プロトコルはウォレットに確認する側に関する情報へのアクセスを許可するの？例えば、僕がコントロールしてないこのウォレットは、その持ち主とか政府に、僕が特定のウェブサイトにアクセスするのに使ってるって教えられるの？
その通りだよ。サイトとDMVが共謀してもあなたを特定できない性質を「非連結性（unlinkability）」って言うんだ。僕が知る限り、ゼロ知識証明なしでは実現できないね。この問題についての議論はここを見て: https://github.com/user-attachments/files/15904122/cryptogra…
ただし、DMVが証明書を失効させられるようにすると、タイミング攻撃がまた問題になるんだ。失効の方法がどうなるかが重要だよ。証明書を提示する時に、失効してないかDMVに連絡する必要があるソリューションには強く反対してるけど、これはプライバシーとセキュリティの間の避けられないトレードオフがある微妙な議論なんだ。
代替案としては、クレジットカードサイズのプラスチックカードにセキュアチップを入れる方法もあるけど、誰もそのアイデアは好きじゃないみたいだね。僕たち（Google）がこういう選択をするわけじゃないんだ。
対話型証明を非対話型にするトリックがあるよ。プロバーが最初に回答をハッシュして、それを検証者の最初の質問として使うんだ。これを繰り返して会話をシミュレートするんだよ。検証者は途中のハッシュをチェックして不正がないか確認できる。重要なのは、結果を操作できない暗号的に安全なハッシュ関数を使うことだよ。
悪意のあるウォレットが情報を漏らす可能性はあるね。だから一部の政府は認定ウォレットだけ使うように言うんだ。でも、ウォレットとゼロ知識証明の組み合わせは、平文のMDOCを送るより断然マシだよ。この分野に完璧な解決策はなくて、トレードオフがあるだけ。議員さんたちはそのうちの一つを選んだってことだね。
別の方法としては、自分が信頼してるブラウザみたいなコンポーネントが仲介役になって、信頼できないウォレットやサイトには必要な情報だけ渡すのはどうかな？ウォレットは誰が証明を求めてるか知る必要ないんじゃない？
それは残念だね。プロトコルがその点を考慮して設計されてたらよかったのに。GoogleやAppleみたいな企業製の独自ソフトを信じて、自分のデジタルアイデンティティを全部任せるなんて、かなりひどい方向性だと思うよ。
これって対話型の例だよね？ SNARKsとかSTARKsみたいな、検証者がリアルタイムでやり取りしない非対話型証明を理解するのには役立たないんじゃないかな？
言いたいことはわかるよ。一番の問題は、書類を他の人に渡せないようにする方法なんだ。今は、認定されたスマホにセキュリティキーと生体認証を組み合わせる方向に収束してきてるね。
欧州連合での詳細については、このGitHubリポジトリを見てね。
https://github.com/eu-digital-identity-wallet/eudi-doc-archi…
他の地域は違う課題や解決策があるよ。もっといいアイデアがあったらメールして！
ウォーリーじゃなくて、未知の形をシルエットだけで探すのを想像してみて。シルエットの中身を描けたら、どこか言わずに見つけたことを高い確実性で証明できるんだ。ノイズ画像や量子測定の例えもできるよ。PoWにも応用できるかもね。
非対話性の部分は、’Fiat Shamir heuristic’を見るとわかるよ。
これは基本的に、証明者が検証者のコイン投げじゃなくて、公開された入力のハッシュからランダムな挑戦を得るって仕組みなんだ。
こんなのがZK proofって言えるのかな？
https://crypto.stackexchange.com/questions/96232/zkp-prove-t…
もっとコメントを表示（1）
年齢確認は、政府が（企業を代理として）ネットを使うための許可証につながる入り口になるだろうね。
確かにそうだけど、10歳の子供がウェブブラウザを開いて40秒以内にハードコアなBDSMや近親相姦フェチのポルノに直面できるのが健康的だとは到底思えないんだ。これは嫌だけど、ポルノ業界の自主規制以外に解決策がないのが現状で、それもあまり期待できないんだよね。
必ずしもそうじゃないよ。ウガンダは2018年からエンドユーザーにソーシャルメディア税を課税してるんだ。ソーシャルメディアサイトにアクセスすると、携帯電話の請求に自動的に追加されるんだ。1日あたり約2.7セントね。[1]
事実上、誰もがユーザーの住んでる国で規制されてるISPからインターネットを使ってる。アメリカで許可システムを実装する技術的な障壁はないんだ。利用ベースの税金があれば、接続を実際の人に紐づけるのは自己強制されることになるね。[1] https://www.africanews.com/2018/04/13/uganda-s-social-media-…
じゃあ、”WireGuardで別の国に接続してるからトラフィックは見えないよ”っていう主張に対するこの仕組みの答えって知ってる？
十分な人口がそこまでやらないだろうから、収益システムとしては大きく損なわれないだろうけど、税金じゃなくて身元特定を避けるのが目的なら、その努力をするだけの価値は十分あるかもね。
保護者がいる子供については、保護者が子供がアクセスできるものをコントロールできるようにして、その権限を与えるのが答えだよ。
なぜか、インターネットアクセスのような一部の分野では、親／保護者から責任が不適切にシフトしちゃってるんだよね。
他の分野、例えば子供を一人で外に行かせることなんかでは、妥当な介護者の行動を犯罪にしちゃったりしてる。
本当にワイルドな世界だよ。
それは、タバコ会社が同時に子供向けにマーケティングしてたのに「親が子供をタバコから遠ざけるべきだ」って言ってたのと同じ論法じゃない？
それに、親は子供を24時間見張ってるわけじゃないよ。学校はどこでもタブレットやノートパソコンを提供してる傾向があるし、コンテンツフィルターみたいなものが、子供たちが不快なポルノや、女性蔑視などを教えるヘイトサイトなどにアクセスするのを十分に防げると、親はどれだけ信頼すればいいのさ？
＞ WireGuardで別の国に接続してるからトラフィックは見えないよ
WGのトラフィックは簡単に見分けられるしブロックできるよ。VPNを禁止してる国でやってることだね。
まーね、でもネットは国際的だから、これでも限界あるわ。GFWよりずっと高度なシステムが必要になるっしょ。
＞”親が子供をタバコから遠ざけろ”ってタバコ会社が言ってるのと同じ？”ってさ、ほとんどの人がタバコと画像は全然違うって思うんじゃね？
＞そして親は24時間子供を見れない？ 学校がタブレットとか提供するし、コンテンツフィルターが不適切なポルノや misogyny を教えるサイトから守ってくれるって、どれだけ親は信用すべきなの？
同意だな。
親や保護者は、学校にどんなインターネットフィルターがあるか、絶対に知っておくべきだし気にかけるべきだわ。
別の見方するとさ、有害コンテンツから子供を守る責任を親に押し付けるってことは、”ちゃんとした親”がいる子供しか守らないって決めるようなもんだよな。
児童ポルノに関してはなぜかできてるんだよな、技術はもうあるの。例えばDiscordやCloudflareはメッセージとかスキャンしてるし。つまり、他のコンテンツを消さないのは、強制されるか世論に押されるかしないと興味ないってことだろ。
まあ、でもそれやると全部のコンテンツがアウトになるわ、未成年向けだけじゃなく。
アホみたいだけど、北朝鮮、イラン、中国では機能してるぜ。死刑とか懲役10年とか。レイプ被害者とかも守れる。”金銭的なプレッシャーによるレイプ”もな。
代わりに、親がフィルターつける責任を負って、他の奴らはネットで自由に、履歴とかID共有せずに暮らすって方法もある。
実際TikTokとかもかなりトラウマになるコンテンツあるけど、子供やティーンは夢中になってんじゃん？ IDつけても解決しないけど、良い親なら解決できるわ。
その点では Shadowsocks みたいな方が効果的だろうし、問題はまだ残るって話だわ。
同意だわ、それはうまくいくんだけど、 audience size とか the much more severe real harm caused by its production and distribution とか、そこを強く取り締まる価値がある tradeoff にするような違うパラメーターがあるんだよね。
大人はポルノ見ていいはずだよ。CPは子供虐待だから別格で、 incitement to violence とも言える。
親が監視すべきだけど、非技術者には難しいし、友達の家とかで簡単に見れる。業界は親を支援しないんだ。彼らは子供を早期に hook したいからね。
今のポルノは engagement 稼ぎで”edgier”になってて、 simulated incest, simulated rape, extreme BDSM ばっか。小さい子供が適切に contextualize できない内容だよ。大人と子供じゃ線引き違うし。
今の若い子が野放しでポルノ見て育った結果は、例えば Reddit の女性向けスペース行ってみ？ なんで男がガールフレンドの首絞めたがるか、ってスレッド見てみなよ。この急な choking fetish どっから来たんだよ？
法を回避する政治的な答えって、だいたい罰則だよ。これは weird technical solutions よりずっと簡単なんだわ。
まあ、他に解決策がないからって、提示されたものが正しいとは限らないでしょ。全然そうじゃないわ。
結構な人たちが Napster で低音質 Mp3 ダウンロードしたり、 video codec 調べたり、ゲーム機 modding してタダでゲーム手に入れたり、面倒でもやってきたじゃん？ 必要性が高ければ、ユーザーはやり方見つけ出すんだよ、どんなに friction 高くてもさ。
技術的な腕がある奴は自分でやるし、賢い奴はネットで情報探すし、残りは友達に聞くか、近所の IT 業者に金払ってセットアップしてもらうんだわ。
この記事は問題そのものの解決策を示してるわけじゃないよ。世界中の政府、特にヨーロッパでは法律で解決策を決めちゃったけど、それはプライバシーにとって悪夢なんだ。この記事はプライバシーの問題を解決していて、今の状況よりはるかに優れてる。僕たちGoogleは、何を規制すべきかを決める立場じゃないよ。
だから、もっと先に進む必要があるんだ！
https://vitalik.eth.limo/general/2025/06/28/zkid.html
今日はアダルトコンテンツの年齢制限だけど、次の手はLGBTQのサイトを年齢制限することだろうね。‘わいせつ’の定義を気に入らない誰かに変えられてさ。放置して反対されなければ、避妊や異人種間結婚についての議論だって、大人限定にしちゃうだろうね。
＞ reasonable
俺が思う本当の問題は、”妥当な”の定義が主観的で、時代や文化、その時々の権力者によってしょっちゅう変わるってことだよ。
これで世界を築けるね。個人識別情報（PII）を過剰共有しなきゃいけないせいで、プライバシー面で多くのことが壊れてるんだ。例えばSSN（社会保障番号）とかね。
同意。ここではこれに関してネガティブな意見が多いけど、全体的に見れば素晴らしいことだと思うよ。
これ、すごいね。David Chaumがゼロ知識証明（ZKPs）のクールな使い方全部特許で囲っちゃったときはマジむかついた。DigiCashの連中はドットコムバブルの強欲タイプで、ビジネスモデルが「全てのトランザクションから大金を得るから、評価額は世界GDPの1％であるべき！」だったけど、世間は「そんなの無しね」って応じたんだ。Andy Birrellsの”マイクロセント”もすごく好きだったな。MD5ハッシュを簡単に逆算できないのを利用して、安価で信頼性の高い低額トランザクションを高速にやるやつ。これも残念ながら広まらなかった。90年代のZKP IDカードやZKP通貨は、実際に見てみたい面白いものだよ。想像してみて、ネットワークなしで携帯同士で、二重支払いできない通貨で支払いできるって。それがDigiCashの約束だった。政府はそれを嫌がってたけど :-) シリアル番号で銀行が出した、受け入れた、は追跡できたけど、その間どこに行ったかは追跡できなかったんだ。現金みたいだったね。面白い時代だった。この技術の上に、俺のZKPアイデアのいくつか作れるか見てみなきゃ。
＞ これすごいね。
それがさ、全てのユーザーが自分のプライベートデータをApple、Google、Microsoftのどれか一つに管理させるって、ハード要件になるって知ってもそう思う？これとかPasskeysにはワクワクしたいんだけど、この分野で働いてる人たちはどうもヘマし続けてるんだよ :(
[1] ”MDOCを使うには電話のハードウェアセキュリティキーからの署名が必要” https://news.ycombinator.com/item?id=44458417
パスキーのプライベートデータはパスワードマネージャーで管理できるよ。いくつかパスキー対応してるのがあって、1PasswordやBitwardenみたいにLinuxで動くものもあるから、家が完全にApple、Microsoft、Googleフリーでもパスキー使えるよ。
https://github.com/keepassxreboot/keepassxc/issues/10407#iss…
＞正直なところ、リライイングパーティにKeePassXCをブロックされるリスクがあるね
大手テックが”公式に”パスキー標準で大手テックの関与を求めなくても、銀行みたいな保守的なビジネスは大手テックの実装しか受け入れない可能性がすごく高いと思うんだ。そうなったら、もうダメじゃん。
同じように、OpenIDが”Sign in with AppleGooFaceSoft”になっちゃったの見てみろよ。
このZKP＋ハードウェアセキュアエレメントのやつはもっと悪いみたいだね。古いハードウェアとかフリーソフトウェア、オープンなデバイスでどうやって動かすつもりなの？
＞ 大手テックが”公式に”パスキー標準で大手テックの関与を求めなくても、銀行みたいな保守的なビジネスは大手テックの実装しか受け入れない可能性がすごく高いと思うんだ。
まさにそうだね。これは理論上の懸念じゃなくて、仕様の作者自身が”問題のあるクライアントリスト”を管理してるんだよ：https://passkeys.dev/docs/reference/known-issues/
＞ このZKP＋ハードウェアセキュアエレメントのやつはもっと悪いみたいだね。古いハードウェアとかフリーソフトウェア、オープンなデバイスでどうやって動かすつもりなの？
それは好きじゃないけど、こういう財産証明的なものは確かに secure area にあって、承認されたソフトウェアに裏打ちされるべき、っていう議論は理解できるんだ。だってそれは政府公認の、ある人物や組織に関する法的な主張をするものだからね。Passkeysとは違って、それは”あなたの”データっていうより、政府が実際に手続きに関わらなくても、法的に裏付けられた情報を誰かに提供する方法なんだ。この大手テック依存の解決策としては、政府が、大手テックを信頼したくないユーザーのために、検証可能な独自のソリューション（オープンなソフトウェアが入った物理的なIDカードとか）を提供する義務があるべき、って俺は主張するかな。
ZKP仕様の作者がしくじった点は、ウォレットプロバイダーをトランザクションの当事者として考慮しなかったことだよ。あの第三者はユーザーの利益と一致しない利害を持ってるかもしれないんだ。
俺たちが開発中のサービスこれだよ！見てみて！
https://paygo.wtf/https://x.com/0x_Osprey/status/1925299005191577921
オフラインで取引するとダブルスペンドのリスクがあるんだよね。DigiCashモデルだと後で検知するしかないみたい。Ecashモデルの研究が進んでて、CashuとかFedimintプロジェクトが復活してきてるよ。Cashuは送り主はオンラインで受け取り側がオフラインってアプローチだって。
詳細はこちら
https://chaum.com/wp-content/uploads/2021/12/Untraceable_Ele…
https://x.com/CashuBTC/status/1901240537866273252
もっとコメントを表示（2）
他人の認証済み秘密鍵を使ったPCとかスマホを使うとか、怪しいフォーラムから鍵をダウンロードするとか、VPN使って年齢確認不要な国のサイトにアクセスするとか、そういう不正行為にはどう対応するの？
認証情報は公開鍵を持ってて、秘密鍵はSecure Element（SE）っていう安全なハードウェアに保管されるんだ。SEはスマホに入ってたり、YubiKeyみたいな外部デバイスにもできるよ。使うにはSEが必要だから、他人からPCだけ買ったり、鍵ファイルだけダウンロードしても使えない。不正利用対策として、指紋とか生体認証でSEをアンロックする必要があるんだけど、これは認証情報発行時に登録したものと一致しないといけないんだ。これでどの程度防げるかは詳細次第だけどね。
PasskeysとかMFAみたいに、Secure Element以外の”何か”ってソフトウェアでもいいの？自動化できちゃうんじゃない？
例えば、Linux上でVMwareとか使ってWindows 11を動かして、softu2fでTPM 2.0をエミュレートできるけど、Windowsは普通に動いちゃうよね。
政府がどうやって偽造できないIDを渡すかってのが問題だよね。政治的な問題でもあるけど、多くの人は偽造困難であるべきだと考えてる。現実的には、偽造できないハードウェアに紐付けるしかないんだよ。だから、ソフトウェアエミュレーションで作られた署名なんて誰も信用しない。政府発行のYubiKeyとか、チップ入りのカードとかを想定してる。EUの考え方はこっちを見て。
https://github.com/eu-digital-identity-wallet/eudi-doc-archi…
あと、これはあくまで西側視点の話で、インドみたいに柔軟性を優先する国もあるよ。
デバイスが”偽造困難”であることより、”タンパー耐性”（不正操作への耐性）の方が重要だと思うんだよね。アルゴリズム自体はソフトでもできるけど、Secure Elementの決定的な違いは、データの物理的な分離と、不正操作を検知したらデバイスを使えなくする仕組みがあるってことなんだ。
こういう技術は結局、法を守って生産的な市民をさらに管理するために使われるんだよ。上の0.1%とか下の20%とかはどっちみち制御できないしね。
将来的には、インターネットにアクセスしてIPアドレスを得るのに、個人情報/KYC付きの署名済み証明書が必要になるかも。中国はもうその方向だし、西側も乗り気になってきてるよ。
いいね。ZKPは分散型アイデンティティ証明にいい方法だよ。
デジタルウォレットでのZKPs活用や、PIIなしで政治的な所属を証明して独立した電子民主主義サービスに参加する、なんて使い方も考えられるね。
委員会がこれをやり遂げたのはいいことだ、ISDN以来、プロトコルの分野でこれほど目にするのは久しぶりかも。
オープンソースなのはいいことだね
ゼロ知識証明に興味ある人は、ZK版ハッカーニュースみたいなサイト https://news.zksecurity.xyz/ を見てみてね！
彼らの技術を最新のZK-p研究と比較してくれる人いない？なんで聞くかっていうと、b-word分野で働いてる多くのチームが定期的にすごい進歩してるの知ってるからさ。
だから、この成果が本当に目新しいか／役に立つか、それともGoogleがすでに古くなったものを出してるだけなのか、気になってるんだ。
システム作ったGoogleの者だけど、この議論にはあんまり関わりたくないな。
ただ、b-システムは別の問題を解決してるし、うちのシステムが解決する問題には今のところ他に解決策はないよ、とだけ言っておこう。
Ethereum FoundationのYing Tongさんたちと話したんだけど、彼らはデジタル認証に最適なZK技術を調査するプロジェクトをやってて、https://hackmd.io/@clientsideproving/zkIDBenchmarks でいくつかのベンチマークを実行してるんだ。
参考までに、うちの実装は同じハードウェアで約200msでベンチマークをクリアするよ。
ETHFの人たちはうちのコードにしばらくアクセスできてたから、この結果には同意してるんだけど、Googleのコードがオープンソースになるまで数字は公開しないことにしたみたい。
だから、うちのシステムはこの問題に対して最も近い競合より約10倍速いってことだね。
誰が誰より優れてるか、なんて一般的な主張はしたくないよ。
うちのシステムはうちの問題のために設計されてるから、別の問題のために設計されたシステムがうちの問題でパフォーマンス悪いのは当然だ。
IrreducibleのDiamondとPosenによるBiniusシステムの大ファンで、将来的にはBiniusの方がうちのよりうまくいく可能性もある。
でも、今はまだそうじゃない。
どのハードウェアを使うかにも注意が必要だよ。
うちの実装はシングルスレッドでGPUなし、だって世界中のどこでも全てのスマホで動く必要があるからね。
ハイエンドGPUでもっとうまくできるかどうかはうちにとって関係ない。
どっちにしろ，”陳腐化してる”なんて言葉は使わないな。
俺が使う言葉は”今日動く”だよ。
ブロックチェーン界隈の人たちは、Ligeroを今でも使える現代的な構造だと考えてるよ。
少なくとも半年前はそうだった。
この成果は車輪の再発明じゃなくて、実用的なシステムに役立つ良い問題に取り組んでるみたいだね。
作者の出身国も、イタリア人はZK分野で最高ってみんな知ってるから、より正当に見えるよ。
これはすごく面白いソリューションで、マルチショー非連動性を既存のECDSAハードウェアキーを使ったハードウェア結合と組み合わせられるんだ。
年齢確認だけじゃなく、どんな属性にも応用できるよ。
でも、これは信じられないほど複雑なソリューションでもある [1] [2]。
世界中でもこれを理解できる人はほんの一握りだろうね。
IdemixやBBS+みたいな既存ソリューションよりもずっと複雑で、既存ハードウェアでのハードウェア結合は彼らにはない。
プライバシーを保った年齢確認は今すごくホットな話題だけど、どんなに一般的な匿名ブーリアンでも、かなり些細な方法でバイパスできちゃう可能性は常にあるよ。
例えば、本物の属性を公開するためのオープンプロキシを立てるとか。
プライバシー保護の緩和策もいくつかあって、例えば一定期間にk回以上公開するとリンク可能になる暗号化とか、対面での公開シナリオで光速より遅い公開を検出するとかだね。
でも、これらの緩和策が完全に安全になることはない。
もしバイパスできない年齢確認だけが”十分”だと期待されるなら、最初のプロダクションアプリでのインシデントを待つだけで、セキュリティの名のもとにオープンソースとプライバシーの話は捨てられちゃうだろうね。
[1] https://eprint.iacr.org/2024/2010.pdf
[2] https://eprint.iacr.org/2022/1608.pdf
