DeFiブリッジ検証
Hide ── 隠す 送信元の鍵・ノード内部状態
Prove ── 証明する メッセージの起点が正規である
クロスチェーンメッセージの起点を、受信コミット前に独立検証。DVN と並走させる第二の暗号レイヤです。
live in production since 2025 · 公共インフラ PoC 稼働中 · ETHGlobal AI Agents 2026 Finalist
01 · 課題認識
推進担当の、3 つの声。
- DeFi プロトコル開発者
「Bridge 経由の tx が改ざんされていないか、独立検証する手段が要る」
- プロトコル運営
「Bridge を経由する資金の正当性を、外部の利用者に証明したい」
- セキュリティ
「Bridge 攻撃の検知に、暗号証跡が必要」
02 · 変化
原本を渡すか、事実だけを渡すか。
AI に渡すものが変われば、漏洩のリスクごと消える。
Without Lemma
原本をそのまま渡す
- tx_hash:
- 0x1234…
- from_chain:
- ETH
- to_chain:
- ARB
- amount:
- 100 ETH
- sender:
- 0xabc…
↓ すべて AI・外部へ渡る
With Lemma
事実だけを渡す
- subject:
- did:lemma:bridge-msg-eth-arb
- issuer:
- did:lemma:bridge-validators
- sourceHash:
- 0x7e2a…
- lineageChain:
- [source-finalized, relayed, verified]
- integrity:
- merkle-proof
- ZK verified:
- ✓ VALID
↓ 必要な事実だけ AI へ渡る
受信側が状態を確定する前に、メッセージの起点が正規かどうかを独立に検証する層を追加します。既存の検証ネットワークを置き換えるのではなく、第二の独立した検証として並走させる多層防御の構造です。起点の正しさが検証できなければ確定は成立せず、境界で停止します。攻撃後にログが消されても、固定された認証記録は残り、フォレンジック証拠は失われません。
技術詳細を見る ↗03 · 選定基準
3 つの基準で、選ぶ。
「中身を出さず渡す」「独立検証」「改ざん不能」の3 つが同時に要る業務こそが Lemma の領域です。
| 手段 | 中身を出さず渡す | 独立検証 | 改ざん不能 |
|---|---|---|---|
| アクセス制御のみ | △ | ✗ | ✗ |
| マスキング / 匿名化 | △ | ✗ | ✗ |
| 暗号化のみ | ✓ | ✗ | ✗ |
| Lemma（ZK 証明）唯一 3 つ揃う | ✓ | ✓ | ✓ |
04 · 進め方
進め方
脅威モデルの整理と PoC から入り、運用まで伴走します。
- 30分の棚卸し — 受信したメッセージを「設計通りに」実行している経路のうち、起点の独立検証がないものを特定。
- 証明したい判定(結果)を1〜2個に絞る — 例:「このメッセージは検証可能な条件下で発行された」「コミット可」など、書き込み前に確かめたい事実。実装詳細は出しません。
- 接続と並走運用を設計 — 既存の検証経路と受信側アダプターのどこに検証ゲートを挟むか、その接続方式と認証の固定方法を設計。
- PoC(見積ベース)で1経路を実証 — 1つの受信経路で、起点証明が揃わなければコミットが成立しないことを確認。
- 導入支援と運用の伴走へ — 導入から運用まで継続して伴走します。費用感の目安として既存プラン区分（Civic / Critical / Compliance）を参照しますが、構成と価格は会話のなかで設計します。
「有効な署名は揃うのに、起点が確かめられていない」経路を1つ、最初の30分で聞かせてください。実装の機微情報（個人情報や機密情報）の開示は必要ありません。
より広い活用シーン
このユースケースを含む、活用シーンの全体像。
業界・業務領域ごとの活用シーンと、4 つの軸で整理しています。
Solutions で 来歴証明の活用シーンを見る →DISCOVERY CALL
まずは、30 分の対話から。
Lemma の機能や活用場面について、ご質問にお答えします。技術的な詳細や機微情報（個人情報や機密情報など）の開示は不要です。