TL;DR
2026 年に入り、cross-chain ブリッジを巡る大規模事象が断続的に発生しています。Kelp DAO / rsETH の事案では 1-of-1 DVN 構成下で約 $292M が 46 分以内に流出しました。トランザクション自体は暗号学的に正しく、ZK bridges（Polyhedra / Succinct 等）・light client・validator consensus（LayerZero V2 DVN 等）の改善は cross-chain の暗号的な来歴検証を着実に前進させてきました。残されているのは、受け取り側がコミット前に「この状態遷移は私のプロトコルのポリシー要件を満たしているか」を独立に検証する層 — ポリシー検証層としての pre-execution attestation です。Lemma の verifiable origin レイヤーは、ZK bridges の上に積み重ねる形で、replay-prevention・custody-path・rehypothecation-depth などのドメインポリシーを ZK 証明として独立検証する設計です。同じ構造はブリッジを超え、オラクル ↔ コントラクト、エージェント ↔ ツール、モデル ↔ 実行系、すべての信頼境界に一般化可能です。
暗号学的に正しい ≠ 意味論的に正しい。
事実関係は 2026-04-30 時点のものです。各プロトコルの設計は今後変動しうる点をご承知おきください。
1. ブリッジ・cross-system セキュリティスタックの現在地
cross-chain セキュリティは 2026 年時点で成熟した分野です。既存スタックの達成と、その上に残されている層を整理します。
技術側 — 既存スタックの達成と残されている層
既存スタックは、cross-chain の暗号的な来歴検証を着実に前進させてきました。3層構造で整理します。
| 層 | 役割 | 現状（2026-04時点） | 提供主体 |
|---|---|---|---|
| Layer 1: 暗号的来歴検証 | 状態遷移の発信元・条件を暗号証明で検証 | 実用段階、複数 vendor が提供 | Polyhedra / Succinct / LayerZero V2 / その他 ZK bridges |
| Layer 2: 監視・凍結・救済 | 異常フロー検出、中央集権的停止、流出後の救済プロセス | 実用段階、運用も成熟 | Chainalysis / Forta / 中央取引所 / DAO / 規制当局 |
| Layer 3: ポリシー検証 | 発行時点のドメイン固有ポリシー（replay、custody-path、rehypothecation-depth 等）を受け取り側で独立検証 | 多くのプロトコルが個別実装、業界標準は未確立 | Lemma の pre-execution attestation でカバー可能 |
「発覚から凍結まで」のリードタイムは確実に短縮されています。Kelp DAO / rsETH の事案のような失敗モードは、暗号的な来歴ではなく、ドメイン固有のポリシー（残高・custody-path・rehypothecation-depth など）が発行時点で本当に成立していたか を、受け取り側がコミット前に検証できなかった点に起因します。
このスタックを構成する各プレイヤーの役割を整理すると、以下の通りです。
- ZK bridges（Polyhedra / Succinct 等） — chain ↔ chain 間の暗号的な来歴検証
- Light client — chain 内・chain 間の状態遷移検証
- Validator consensus（LayerZero V2 DVN 等） — multi-source 検証による robust な来歴確認
- Lemma — ドメイン固有のポリシー（replay、custody-path、rehypothecation-depth 等）を受け取り側で独立検証する pre-execution attestation レイヤー
注: 上記の役割分担は技術スタックの構造を整理したものであり、各 vendor との公式な協業関係や提携を示すものではありません。Lemma は既存の ZK bridges / light client / validator consensus の上に補完的に動作する独立した拡張レイヤーとして設計されています。
ZK bridges が「送信元 chain での状態遷移は本当に起きたか」を扱うのに対し、Lemma の pre-execution attestation は「発行時点で、受け取り側プロトコルのポリシー要件は満たされていたか」を扱います。両者は競合せず、積み重ねることで初めて cross-system trust が成立します。
暗号学的には正しい。意味論的にはどうか、はまた別の論点です。
規制側の背景
cross-system 来歴の検証可能性を、社会基盤として位置づける制度的潮流も並行して進んでいます。
- 日本 — 「Trusted Web」構想として、データの主体・出所・条件を独立に検証可能とする社会基盤の整備が議論されています
- 欧州 — EBSI（European Blockchain Services Infrastructure）が並行する方向に整備されています。EU AI Act 下でも AI 判断の説明可能性が要件化されつつあります
- 米国 — 重要インフラ分野で provenance attestation を要求する規制（NIST 等）の議論が進んでいます
技術側のスタックが揃いつつある今、規制側からも来歴検証の標準化が求められています。残されているのは、暗号的な来歴の上に積み重ねるポリシー検証層 — その実装方法を、次節で整理します。
2. Lemma 導入で pre-execution attestation を組み込む
ポリシー検証層が満たすべき要件と、Lemma の pre-execution attestation がどう応えるかを、順に整理します。
pre-execution attestation が満たすべき要件
- 発行側で、状態遷移の発行時点におけるドメインポリシー（残高、custody-path、rehypothecation-depth 等）を改ざん不能な形で記録
- 受け取り側がコミット前に、その policy proof を送り手側を信頼せずに独立検証
- 暗号的に正しい（ZK bridges が検証する）ことに加え、意味論的にも正しい（policy proof が検証通過する）ことを担保
- 検証の通過が、コミット ＝ 状態確定の前提条件として書き込み時点で評価される（事後検出ではなく事前 reject）
Lemma の pre-execution attestation レイヤー
Lemma が提供しているのは、ドメイン固有ポリシーを ZK 証明として受け取り側で独立検証できる仕組みです。example-origin リファレンス実装で公開している proof bundle 構成は以下の通りです:
- in-circuit commitment: Poseidon over BN254（in-circuit のハッシュ制約。off-chain な standin は使いません）
- issuance 側の selective disclosure: BBS+ over BLS12-381
- ZK proof 本体: Groth16
- domain policy 層: bridge / LRT 設定固有のチェック（replay-prevention、custody-path 検証、rehypothecation-depth バウンド 等）を回路の上に積み重ねる
回路は来歴を検証し、policy 層は どの形の来歴を受け取り側として受理するか を制約します。両者は分離して設計されているため、新しいドメインへの拡張は policy 層の更新だけで可能です。
Lemma 導入で広がるユースケース
ZK bridges / light client / validator consensus の上に Lemma の pre-execution attestation を組み合わせることで、cross-system 状態遷移を扱う複数のワークフローを単一基盤で支えられます。
- ブリッジ ↔ LRT プロトコル: ブリッジ経由で入ってくる状態変化が、受け取り側 LRT プロトコルの policy（残高、custody-path、rehypothecation-depth 等）をコミット前に独立検証
- オラクル ↔ スマートコントラクト: 価格フィードや属性情報の発行元・条件・時刻を、受け取り側のコントラクトがコミット前に独立検証
- エージェント ↔ ツール: AI エージェントによる外部ツール呼び出しが、その権限・ポリシー条件をコミット前にツール側で独立検証
- モデル ↔ 実行系: モデルが返す構造化出力が、主張する版本・ポリシーで生成されたものかを実行系がコミット前に独立検証
リファレンス実装: example-origin
cross-system 文脈で pre-execution attestation を端から端まで通したシナリオ実装を公開しています。Kelp DAO / rsETH を題材としたフローです。
example-origin（2026-04-30 公開） — リポジトリ: github.com/lemmaoracle/example-origin
pnpm circuits:prove が実際の wasm + zkey artifacts を生成します。in-circuit Poseidon 制約は本番の proving run で評価されます。pnpm demo で 5 分以内に検証パイプラインを端から端まで動かせます。
実装ステータス: 本リファレンスは Base Sepolia 上のひとつのシナリオに閉じています。in-circuit Poseidon + Groth16 パイプラインは実動しますが、issuer 署名は HMAC-SHA256 standin で、BBS+ over BLS12-381 が production target です。配線済み／スキャフォールドの差分は repo の "PoC vs Production" 表を正典とします。
3. まとめ
- cross-chain セキュリティスタックは、ZK bridges（Polyhedra / Succinct 等）・light client・validator consensus が揃いつつあります。Lemma の pre-execution attestation レイヤーは、その上で動くドメイン固有のポリシー検証を提供します。
- BBS+ over BLS12-381・Poseidon over BN254・Groth16 の proof bundle 構成で、ブリッジ ↔ LRT・オラクル ↔ コントラクト・エージェント ↔ ツール・モデル ↔ 実行系など、cross-system trust が問題になる任意の境界に一般化可能です。
- 日本の Trusted Web、欧州 EBSI / AI Act など、cross-system 来歴の社会基盤化の動きも、この方向性を後押ししています。
暗号学的に正しい、意味論的にも正しい — その両方を、コミット前に検証する設計です。
ブリッジ事象の繰り返しが示しているのは、暗号的な来歴検証の上に積み重ねるべき「ポリシー検証層」が必要だということです。Lemma の pre-execution attestation レイヤーをご導入いただくことで、
- ブリッジ ↔ LRT プロトコル の replay・custody-path・rehypothecation のリスクを、コミット前に独立検証
- オラクル ↔ コントラクト の価格フィード・属性情報を、発行時点の条件を含めて独立検証
- エージェント ↔ ツール 呼び出しの権限・ポリシー条件を、受け取り側で独立検証
といった複数のユースケースを、ひとつの基盤の上に構築できます。ブリッジ・LRT プロトコル開発者、DeFi セキュリティ・監査エンジニア、AI エージェント / x402 / MCP プラットフォーム構築者 からのご相談をお待ちしております。原則 1 営業日以内にご返信いたします。
Built for decisions that matter.
Resources
- example-origin リファレンス実装 — github.com/lemmaoracle/example-origin
- example-x402（x402 上の proof bundle 実装）— github.com/lemmaoracle/example-x402
- Whitepaper v1 — whitepaper-v1-prove-ai-decisions
- 開発者ウェイトリスト — tally.so/r/kd0bZR