ビタリック・ブテリンは、取引シミュレーションがユーザーの意図とオンチェーンの結果とのギャップを埋め、暗号セキュリティを根本から再構築できる可能性を示唆している。
イーサリアムの共同創設者ビタリック・ブテリンは、暗号セキュリティに対する新たな考え方を提案している。それはコードから始まるのではなく、意図から始まる。
Xに投稿した中で、ビタリック・ブテリンはセキュリティとユーザー体験は全く別の分野ではないと主張した。両者とも、ユーザーが実際に望むこととシステムが実際に行うこととの間のギャップを縮めることに関係しているのだ。違いは、セキュリティはそのギャップの最悪のケース、すなわち敵対的な行動によって乖離のコストが非常に高くなる状況を扱う点にある。
この議論は、多くの暗号開発者が当然のことと考えていることに切り込んでいる。
ブテリンはXで、完璧なセキュリティは不可能だと述べた。機械の故障やエンジニアのミスではなく、人間の意図があまりにも複雑で、完全に符号化しきれないからだ。
彼はシンプルな例を挙げた。ユーザーが1 ETHをボブに送ることを望むのは明らかに思えるが、「ボブ」は数学的に定義できない。公開鍵が間違っている可能性もある。ブロックチェーンがフォークすることもある。「ETH」という言葉も主観的になり得る。そのため、ユーザーの現実のイメージとシステムの数学的表現との間に生じるギャップこそがリスクの所在だ。
プライバシーの目標になると、さらに複雑になる。メッセージの暗号化だけでは十分に思えるが、メタデータやタイミングパターン、通信グラフは大量の情報漏洩を引き起こす可能性がある。何が些細な露出で、何が壊滅的な露出かを判断する明確な公式は存在しない。
彼が指摘する解決策は、単一のより強固なロックではなく、重複した仕様の重ね合わせだ。複数の意図の記述が一致したときにのみ、システムは動作する。
彼はすでに実践されているこのパターンの例をいくつか挙げた。プログラミングの型システムは、開発者にコードの動作と各データ構造の形状の両方を書かせる。これら二つの記述が一致しなければコンパイルされない。形式検証は数学的証明に似たことを行う。マルチシグウォレットは、複数の鍵が合意しないと資金が動かせないようにしている。支出制限の警告は、異常な動きがあったときに発動する。
取引のシミュレーションも同じ論理に適合する。ビタリック・ブテリンによると、ユーザーはまずアクションを指定し、その後にオンチェーンで実際に何が起こるかのシミュレーションプレビューを見る。シミュレーションを確認またはキャンセルするクリックは、二つ目の仕様となる。両者は同じ方向を指している必要がある。
取引の事後検証はさらに進む。取引自体がアクションとその予想される効果の両方をエンコードし、実行時に一致しなければ取引は失敗する。
あなたも興味があるかもしれません: npm Wormが暗号鍵を盗み、19のパッケージを標的に
ブテリンは従来のツールにとどまらず、この枠組みとAI言語モデルの暗号セキュリティにおける適切な使い方とそうでない使い方を直接結びつけた。
彼はXの投稿で、汎用の大規模言語モデル(LLM)は人間の常識の影のようなものだと述べた。特定のユーザーの行動に微調整されたモデルは、そのユーザーが何を普通とし、何を異常とみなすかの感覚を近似する。これにより、意図を推定する角度が一つ増えることになる。これは、正式なコードや暗号署名とは全く異なる角度だ。冗長性は、全く異なる方向から仕様を検証できるときに最も効果的に働く。
ただし、彼はその限界も明確にした。LLMは、トランザクションがユーザーの意図を反映しているかどうかを判断する唯一のものとして使うべきではない。それは、全体のアプローチに依存する冗長性を崩壊させてしまうからだ。
読む価値あり: ビタリックのサイファーパンク層計画はイーサリアムを永遠に変える可能性がある
ブテリンが指摘した一つのポイントは、注目に値する。良いセキュリティは、ユーザーにすべてをより頻繁に確認させることを意味しない。それは一つの問題を別の問題に置き換えるだけだ。
彼がXで述べたように、実際の目標は、リスクの低い操作を簡単または自動化し、危険な操作を難しくすることだ。そのバランスこそが、真の設計上の課題だ。誤った場所で摩擦を生じさせると、ユーザーを警告を読まずにクリックさせるだけになり、保護にならない。
この観察は、イーサリアムウォレットの構築方法に直接影響を与える。オペレーティングシステムからスマートコントラクトの検証、ハードウェアに至るまで、すべての層に共通する原則だ。
関連記事: ビットコインETFが8800万ドルを集める一方、イーサリアムの資金流入はほぼゼロに近づいている
ブテリンの枠組みは、解決済みの問題を約束するものではない。むしろ、解決不能な問題についてより良い考え方を提案している。ユーザーの意図の単一の仕様は決して完全にはなり得ない。重要なのは、システムが動作する前に何通りの角度から検証できるかということだ。