事後追跡（forensics）が捉えるのは症状である。受け取り側が「行動する前に来歴を検証する」とき、何が変わるのか。

TL;DR — 2026 年に繰り返されている cross-chain ブリッジ事象は、ひとつの構造を共有しています。トランザクション自体は暗号学的に正しい。しかし、システム境界をまたぐ「誰が・どこから・どんな条件で」という 来歴 についての前提はずれている。事後追跡・凍結・救済は機能していますが、受け取り側がコミットする 前 に来歴を検証する標準的な層が欠落しています。私たちはこの欠落層を pre-execution attestation（事前検証） と呼び、それが守るカテゴリを verifiable origin（来歴証明） と呼んでいます。エンドツーエンドのシナリオ実装を example-origin で公開しました。同じ構造はブリッジを超え、エージェントとツール・オラクルとコントラクト・モデルと実行系、すべての信頼境界に一般化します。

暗号学的に正しい ≠ 意味論的に正しい。

▸ 繰り返されているパターン

2026 年に入ってから、cross-chain ブリッジを巡る大規模事象が断続的に発生しています。共通しているのは、これらが「暗号が破られた」「秘密鍵が漏れた」「スマートコントラクトに通常の意味でのバグがあった」といった話とは別のものだ、という点です。事象に関与しているトランザクション自体は、ほぼあらゆる意味で正しいのです。

問題化しているのはもう一段奥にあります。「誰が、どのシステムから、どんな条件のもとで、その動作を起こしたのか」という 来歴 についての前提が、システム境界の手前と奥でずれているにもかかわらず、受け取り側のシステムがそのずれを検出する前に処理を確定してしまう、という構造です。

確定した瞬間に、構造的にはもうエクスプロイトは完了しています。その後の追跡・凍結・救済はすべて、すでに失われたポジションに対する事後対応です。

業界全体として、こうした事象に対する投資は事後対応スタックに集中し続けています。事前検証の層は薄いままです。

本記事は、この欠落を「個別事案」ではなく「カテゴリの問題」として位置づける議論です。

▸ 既存スタックが効く範囲、止まる地点

2026 年の cross-chain セキュリティは成熟した分野です:

これらはどれも重要で、運用も上手くなっています。「発覚から凍結まで」のリードタイムは確実に短縮されています。

ただ、これらは コミットの瞬間 を変えません。受け取り側のシステムが他システムからの状態遷移を受理するとき、業界として標準化された方法で次の問いに答える手段がない、という構造は変わっていません:

実装上、これらの問いは多くの場合「ブリッジオペレーターへの信頼」「マルチシグ/オラクル委員会の閾値」「経済インセンティブによる整合性想定」によって 暗黙に 答えられています。これらは来歴証明ではなく、来歴 仮定 です。

仮定が成立している間は何も起きません。崩れた瞬間に、その崩壊はもう境界の向こう側に到達しています。

▸ 欠落している層: pre-execution attestation

pre-execution attestation（事前検証） を、受け取り側がコミットする前に次を検証する行為と定義します:

  1. 受け取ろうとしている状態変化が、それが主張する主体によって発行されたこと
  2. それが主張する chain・コントラクト・オペレーターから発行されたこと
  3. 発行時点における条件が、その時点で検証可能な形で真であったこと
  4. 上記 1–3 の証明が、送り手側を信頼せずに受け取り側で独立検証可能であること

具体的には、発行側で origin proof（来歴証明） を生成し、それを状態変化と一緒に運び、受け取り側が安価に独立検証する、という構造を意味します。証明は行動を発信源に縛り付けるためにあります。

これは新しい暗号プリミティブを必要とするわけではありません。署名・accumulator・attestation・ゼロ知識証明・light-client 構造といった構成要素はすべて長年存在しています。欠落していたのは、構成要素ではなく、「受け取り側はコミット前に来歴を検証しなければならない」というカテゴリレベルの期待値 でした。

私たちの整理では、ブリッジ事象群はこのもっと広い失敗モードのうち、現時点で最も声の大きいインスタンスです。声が大きいのは金額が大きいからで、それが固有現象だからではありません。

▸ ブリッジを超えた一般化

「暗号学的には正しい / 意味論的には誤り」という同じ形は、信頼境界をまたぐすべての場面に現れます:

いずれの場合も失敗モードの形は同じです。暗号的なラッピングは正しい、意味論的な発信源は不確定、にもかかわらず受け取り側はコミットしてしまう。

ブリッジは出発点として優れています。失敗が公開され、金額化され、数えられるからです。Trust Layer を構築する仕事の本質は、すべての境界において、来歴検証を当然の期待値として扱うことにあります。

▸ 端から端までの実装: Kelp DAO / rsETH シナリオ

cross-system 文脈で pre-execution attestation を端から端まで通したシナリオ実装を公開しています。Kelp DAO / rsETH を題材としたフローです。

リポジトリ: github.com/lemmaoracle/example-origin

example-x402 で公開した同じ proof-bundle プリミティブセット — in-circuit commitment に Poseidon over BN254、issuance 側 selective disclosure に BBS+ over BLS12-381、ZK proof 本体に Groth16 — を踏襲しています。example-origin はこのパターンを2方向に拡張しています:

  1. ローカルで端から端まで動くパイプライン。 pnpm circuits:prove が実際の wasm + zkey artifacts を生成する。in-circuit Poseidon 制約は本番の proving run で評価される — この層に off-chain なハッシュ standin はない。
  2. 回路の上に乗る domain-policy 層。 bridge / LRT 設定固有のチェックを行う: replay-prevention、custody-path 検証、rehypothecation-depth バウンドなど。回路は来歴を検証し、policy 層は どの形の来歴を受け取り側として受理するか を制約する。

シナリオが扱う領域:

  1. 発行側 — 状態変化の瞬間に origin proof を生成し、検証可能な条件のもとで行動を発信源に紐づける
  2. transport — 送り手側の継続的な参加を必要とせずに、状態変化と一緒に proof を境界の向こうに運ぶ
  3. 検証側 — 受け取り側で pre-execution attestation を実行する。proof が検証通過した場合のみコミット。通過しなければ書き込み時点で reject される（事後検出ではなく事前 reject）
  4. failure injection — 暗号的には正しいが意味論的に誤っている遷移を注入し、pre-execution attestation がコミット前にそれを reject することを示す

この題材を選んだのは、現時点で最もコストが大きい失敗モードの一例だからであり、「発行・transport・検証」という構造自体は完全に一般的だからです。

実装の詳細な技術解説は別記事にて公開予定です。

実装ステータス: 本リファレンスは Base Sepolia 上のひとつのシナリオ形に閉じている。in-circuit Poseidon + Groth16 パイプラインは実動するが、issuer 署名は HMAC-SHA256 standin で、BBS+ over BLS12-381 が production target。配線済み／スキャフォールドの差分は repo の "PoC vs Production" 表を正典とする。

▸ Trust Layer のポジショニング

私たちにとって Trust Layer とは、システム境界をまたいで origin proof が「生成され・運ばれ・検証される」層のことです。来歴検証を、送り手側の防衛機能ではなく、受け取り側の当然の期待値 として扱います。

含意は2つあります。

ひとつめは統合の含意です。 多くのセキュリティ言説は発行者に義務を負わせます（「もっと強い署名を出せ」「validator セットを締めろ」）。pre-execution attestation はこれを反転させ、受け取り側に「来歴が検証通過しない限りコミットしない」という義務を置きます。信頼の所在を、行動が実際に起こる地点に寄せます。

ふたつめはスコープの含意です。 AI とデータが社会基盤を支える時代において、システム境界をまたぐ来歴の検証可能性は、もはや単なる技術機能ではなく、公共インフラとしての性格を帯び始めています。共有され、基層となり、期待されるもの。

日本では 「Trusted Web」 が、データの主体・出所・条件を独立に検証可能とする社会基盤の構想として提唱されてきました。欧州では EBSI（European Blockchain Services Infrastructure）が並行する方向に整備され、EU AI Act や各国の重要インフラ分野の規制も、AI の意思決定を「その来歴を含めて検証可能であること」を求める方向に収斂しつつあります。

Lemma が技術側から実装しているのは、これらの制度的潮流が指し示す共通の地点 — 信頼境界をまたぐあらゆる行動が、受け取り側で独立に検証可能であることが当然となる社会 — にほかなりません。Lemma の Trust Layer は、その社会的合意を支える検証基盤を、技術インフラとして整備する仕事です。

仕事の構えは単純です。ブリッジ、エージェントとツール、オラクルとコントラクト、モデルと実行系といった個別の境界ごとに別の道具を作るのではなく、すべての境界に共通する検証層 — verifiable origin — をひとつの基盤として構築し、必要な領域に順次展開する。共通基盤を先に築き、ユースケースとして社会実装していく。この順序こそが、Trust Layer に求められる工学的責務だと考えています。

Built for decisions that matter.

▸ ここから始める

DeFi 開発者、x402 / MCP 開発者、AI エージェント運用者、cross-system trust が必要なエンタープライズチームの方へ、3つの具体的な次のステップ: