From the Kelp DAO Incident to Verifiable UI: Why 「Verifiable Interfaces」 Could Be the New Decentralized Security Baseline?
- Core Insight: Due to Kelp DAO's LayerZero routing configuration being set to single-point verification (1-of-1 DVN), an attacker forged cross-chain messages to steal 116,500 rsETH, with the maximum potential bad debt reaching $230 million. This incident exposes the structural risk of the DeFi industry outsourcing security to a handful of trusted intermediary layers, prompting a re-evaluation of the verifiability of user interfaces (UI).
- Key Elements:
- The attacker exploited Kelp DAO's LayerZero bridge, which used a 1-of-1 DVN configuration (no optional verifiers). This meant only a single node signature was required to validate cross-chain messages, a vulnerability that remained unpatched for 15 months.
- The incident impacted protocols like Aave, as the collateral rsETH's peg was broken. Aave faced a potential bad debt range of approximately $123.7 million to $230.1 million, leading to an emergency freeze of the relevant markets.
- The incident exposed a double layer of single-point risk: verification single point (DVN configuration) and reserve single point (rsETH's reliance on a single mainnet anchor), with risks transmitted through DeFi composability.
- The industry has long overlooked the issue of "interaction verifiability": the calldata signed by users may not match what is displayed on the frontend, making the interface a trusted but unverified single point.
- Verifiable UI aims to establish a checkable link between the interface display and on-chain execution, ensuring users understand and verify transaction intent, rather than relying on the frontend's interpretation.
- As agent-driven intent-based interactions become more common, wallets need to transform from simple signature tools into deterministic checkpoints before execution, to address security challenges where paths and parameters are abstracted away.
チェーン上のDeFiの世界で、またもや数億ドル規模のセキュリティインシデントが発生しました。
4月18日、攻撃者はKelp DAOのLayerZeroルートにおける1-of-1 DVN（オプショナルな検証者が設定されていない状態）の設定を悪用し、クロスチェーンメッセージを偽造して契約に誤って116,500 rsETHをリリースさせました。これにより、損失分担のシナリオによって異なりますが、Aaveが直面する潜在的な不良債権の範囲は約1億2370万ドルから2億3010万ドルに上ります。
客観的に見て、これは2026年以降最大のDeFiセキュリティ事件であるだけでなく、より重要なのは、業界全体がこれまで暗黙のうちに受け入れてきたアーキテクチャ上の前提を打ち破ったことです。効率性、流動性、収益のために、ますます多くのセキュリティを、少数のデフォルトで信頼されるミドルウェア層に静かに委ねるという前提です。
一、Kelp DAO 事件の背後にある、分散化メカニズムの崩壊
Kelp DAO 事件を単なるありふれたオンチェーンセキュリティ事故と捉えるだけでは、DeFi全体の構造的リスクに対する警告としての重要性を過小評価することになりかねません。
Kelp DAOは、イーサリアムエコシステムにおけるLiquid Restaking（流動性再ステーキング）プロトコルです。理論上、ユーザーがETHを預け入れると、その証明としてrsETHを受け取ることができます。この証明書はメインネット上で流通するだけでなく、LayerZeroのOFT標準によってラップされ、Base、Arbitrum、Linea、Blast、Mantle、Scrollなど20以上のチェーンにデプロイされています。
つまり、イーサリアムメインネット側のクロスチェーン契約にはすべてのETH準備金が保持されており、他のチェーン上のrsETHは本質的に「メインネット準備金に対する引き換え券」に過ぎません。これは、このシステムが成立するための前提が、「メインネット上のロック量が常にL2チェーン上の鋳造量以上である」というアンカー関係が破壊されないことにあることを意味します。
攻撃者が突破したのは、まさにこの一見シンプルながら極めて重要な基盤的制約でした。彼は「正当な」LayerZeroクロスチェーンメッセージを直接偽造し、メインネットのブリッジコントラクトに、それが他のチェーンからの正当な引き換え指示であると信じ込ませ、116,500 rsETHのリリースを許可させたのです。
問題の核心は、LayerZeroの検証設定にありました。Kelp DAOは1/1 DVN（分散型検証者ネットワーク）構成を採用しており、たった1つの検証ノードの署名でクロスチェーンメッセージのリリースが許可されてしまったのです！ LayerZeroは公式には2/2以上のマルチ検証者による冗長性を推奨しており、この1/1のリスクは2025年1月にセキュリティ研究者によってすでに公開で指摘されていましたが、15ヶ月間修正されませんでした！
だからこそ、今回の事件を単に「ブリッジがハッキングされた」とか「あるプロトコルのリスク管理が不十分だった」と分類するのは難しいのです。この事件が明らかにしたのは、実際には2層に重なった単一障害点のリスクです。
- 第一層は検証の単一障害点：DVNは理論上、X-of-Y-of-Nという構成可能なセキュリティモデルとして設計され、複数の独立した検証を用いて様々なセキュリティ要件を満たすことを目的としています。しかし、Kelp DAOにおけるメッセージ全体の正当性は、「1つの検証ノードが問題を起こさない」というたった一つの前提に圧縮されていました。
- 第二層は準備金の単一障害点：一旦このメインネットの準備金プールが突破されると、他のチェーン上のrsETHは即座にクロスチェーン資産ではなくなり、単一のメインネットアンカーに依存する単なるIOU（借用証書）に過ぎないという本質が露呈します。
検証の単一障害点と準備金の単一障害点が重なると、リスクはもはや単一のプロトコル内部にとどまらず、DeFiのコンポーザビリティに沿って外部へ波及していきます。
これが、Aaveが事故後、複数のチェーン上のrsETH/wrsETH市場を緊急凍結し、WETHの金利モデルを調整し、さらに複数のWETH市場を凍結して、圧力が他の資産に拡散するのを防いだ理由です。Aave自体はハッキングされていませんでしたが、担保の価値の歪み、清算の妨害、借り手の健全性の低下により、結局プロトコルは実質的な不良債権リスクを負うことになりました。
さらに視野を広げてみると、「セキュリティを単一障害点に外部委託する」というこの論理は、ブリッジや検証器にのみ存在するわけではなく、ユーザーが毎日直面しながらもほとんど正面から議論されることのない場所、すなわちインターフェースにも潜んでいます。
二、「資産の自己管理」から「インタラクションの検証可能性」へ：最も見落とされがちな単一障害点への信頼
Web3コミュニティには古くから「Don't trust, Verify」という言葉があります。
イーサリアム公式がノードを紹介する際のこの言葉の説明は非常に率直です。「自分のノードを運用することは、他人から伝えられた結果を信頼する必要がないことを意味します。なぜなら、自分でデータを検証できるからです。ネットワークの真実の判断を、中央集権的なデータプロバイダーに外部委託する必要はありません」
この原則は、ウォレットとDeFiのインタラクションにも同様に当てはまります。
imTokenのようなノンカストディアルウォレットは、本質的にユーザーがアカウントにアクセスするためのツールであり、「資産を確認し、取引を送信し、アプリケーションにログインする」ための窓口です。ウォレット自体はユーザーの資金を管理せず、秘密鍵もプラットフォームの手中にはありません。過去数年で、業界は「資産の自己管理」の重要性を徐々に受け入れ、真の分散化とは単にコインをチェーン上に置くことではなく、資産の管理権をユーザー自身に取り戻すことであると理解する人も増えてきました。
しかし問題は、資産の面では「自己管理」をますます強調している一方で、インタラクションの面では依然として、より隠れた外部委託を大量にデフォルトで行っていることです。すなわち、取引の意味の理解、呼び出し結果の判断、インターフェースの真正性への信頼を、目の前のフロントエンド層に委ねているのです。
これこそが、今日のDeFiにおいて最も見落とされがちなリスクの層です。ユーザーが署名したものは、本当に自分が署名したと思っている取引なのでしょうか？
日常のオンチェーンインタラクションにおいて、ユーザーが直面するのはほとんどの場合、チェーンそのものではなく、何層にもわたってラップされたインターフェースです。例えば、DAppのウェブフロントエンド、ウォレットのポップアップ、アグリゲーターが示すパスの説明、そして将来的にはエージェントが自動生成する呼び出しと結果確認などです。これらはユーザーにこう伝えます。「あなたは今100 ETHをある戦略に預け入れようとしています」、「あなたはある年率の収益を得られます」、「あなたは単なる通常の承認を行っています」。
しかし、最終的に実際に署名され、ブロードキャストされ、チェーン上で実行されるcalldataが一体何なのか、フロントエンドの説明と基盤となる実行が厳密に一致しているのかどうか、大多数のユーザーは独立して確認する能力を持っていません。
これこそが、歴史的に繰り返されてきたフロントエンドの乗っ取り、アドレス置き換え、悪意ある承認の偽装が、表面的には異なるタイプのセキュリティ事故に見えながらも、その根底では常に同じ問題、すなわちユーザーが署名したものが、自分が署名したと思っている取引とは限らないという問題を指している理由です。
この観点から見ると、Kelp DAO 事件が暴露したのは、ブリッジパスにおける単一障害点の検証問題だけではありません。この事件は、業界全体に、長い間過小評価されてきた別の事実も同時に気づかせました。すなわち、多くのオンチェーンインタラクションにおいて、インターフェース自体がデフォルトで信頼されながら、ほとんど検証されることのない単一障害点であるということです。あなたが「確認」をクリックした瞬間、あなたはこの呼び出しの正しさを、「インターフェースが嘘をついていない」という前提に賭けているのです。
ここから、「Verifiable UI」という概念が導き出されます。
「Verifiable UI」とは、直訳すれば「検証可能なインターフェース」です。その核心は、フロントエンドをより美しくすることでも、署名ポップアップをより分かりやすくすることでもありません。そうではなく、インターフェースが提示する内容と、チェーン上で実際に実行される呼び出しとの間に、ユーザーが照合でき、ウォレットが検証でき、事後的に追跡可能な接続を確立しようとすることです。
言い換えれば、これが解決しようとしているのは「情報が表示されているかどうか」ではなく、「表示されているものが、チェーン上で実際に起ころうとしていることに本当に対応しているかどうか」です。これは以下を意味します。
- ウォレットは署名の前に、ユーザーに16進数のデータの羅列だけを見せるべきではなく、フロントエンドが一方的に生成した説明文をそのまま伝えるだけでもなく、可能な限りcalldataを人間が読めて、意味が明確な操作意図に変換する必要があります。
- インターフェースが説明する各ステップは、チェーン上で検証可能な証拠にマッピング可能でなければならず、「ユーザーが信じれば成立する」という説明の論理に留まってはなりません。
- そうして初めて、「自分がやっていると思っていること」と「チェーン上で実際に起こっていること」の間に、越え難い認知のギャップが存在しなくなります。
これが確立されれば、インターフェースはもはや、ユーザーが盲目的に信じるしかなく、独立して確認できないガラス窓ではなく、ユーザー自身が確認し、後から振り返って追跡できる実行説明書のようなものになります。
今日のDeFiだけを見れば、インターフェースの検証可能性は依然として深刻に過小評価されているトピックです。しかし、時間軸を少し長く取れば、これはすぐに「議論に値するセキュリティ最適化」から「もはや先延ばしにできない基本機能」へと変わります。なぜなら、イーサリアムとのインタラクション経路が、静かでありながらも意義深い移行を遂げつつあるからです。
三、Verifiable UI が新たなセキュリティ境界となる理由
Kelp DAO 事件が暴露したのが旧世代のDeFiアーキテクチャに長年存在してきた単一障害点への信頼問題だとすれば、「Verifiable UI」が対応するのは、まさに到来しつつある新しい段階です。
ETHUX（イーサリアムUXマップ）は、今日のオンチェーンインタラクションにおける核心的な問題点を非常に明確に整理しています。Transaction Clarity、Cross-chain Flow、Safety & Securityは常に最も核心的な痛点カテゴリーであり、blind signing、signing fatigue、bridging pain、asset fragmentationといった問題は、ほぼすべての古参ユーザーにとって馴染み深いものです。
この背後にあるのは「ユーザー教育が不十分」ということではなく、より本質的な事実です。オンチェーンの世界では、UXとセキュリティは決して別物ではないのです。
言い換えれば、多くの場合、「理解できない」ことこそが、最大のセキュリティリスクなのです。
そして、インタラクションのパラダイムが「ユーザーがDAppのフロントエンドで一つ一つクリックする」から「ユーザーが意図を表明し、システムが自動的に実行する」へと移行するにつれて、この問題は弱まるどころか、さらに拡大されるでしょう。
従来のDAppフロントエンド時代には、ユーザーは少なくともボタン、ページ、承認ポップアップを目にすることができました。たとえ理解が不完全でも、「自分が今いくつかの操作を行っている」、「これは承認か送金か」、「これはクロスチェーンか預け入れか」をぼんやりとでも認識できました。
しかし、エージェントの時代に入ると、このような可視的なプロセス感は大幅に圧縮されます。ユーザーはRouter、Bridge、Vault、Lending Marketを一つ一つ開いて各呼び出しを確認する代わりに、AIウォレットに対して「私のETHをより安定した収益戦略に換えて」、「Baseにクロスして、最大スリッページを抑えて」、「このエージェントが24時間以内に100 USDTだけを使うことを許可して」と指示し、その後「完了」の結果を待つだけになる可能性が高くなります。
これはもちろん効率の大幅な向上を意味しますが、同時に、途中の経路、パラメータ、承認、実行順序が、ますますユーザーの視界から隠されやすくなることも意味します。このような背景の中、imTokenは2つの並行する方向性を提案してきました。一つは、ユーザーが「何をしたいか」だけを表現すれば、システムが経路を見つけて実行を完了する、インテントベースのインタラクション経路を探求し続けること。もう一つは、「Unified & Verifiable UI」を推進し、「インターフェース自体も攻撃対象となり得る」という問題を、製品レベルの長期的な課題として明確に位置付けることです。
これは、次世代ウォレットの最も重要な責務の変化を正確に指し示しています。
かつてウォレットは、ユーザーの承認アクションをチェーンに送信する、署名ツールのようなものでした。しかし、エージェントがインタラクションフローに徐々に関与する段階では、ウォレットは単なる経路であってはならず、実行前の最後の確実性チェックポイントとなる必要があります。AIはニーズの理解、計画の生成、経路の計画を担当できますが、ウォレットはこれらの確率的な生成結果を、ユーザーが検証でき、システムがチェックでき、ルールが制約できる、確定的な実行内容に変換する責任を負わなければなりません。
<
