スマコンのHTTP・LLM実行をsidecarに任せる仕組み

スマートコントラクトは、HTTP通信もLLM推論もEVMの中だけでは実行できません。Ritual Chainが示す設計では、コントラクトは専用のprecompileアドレスを呼ぶだけで、重い処理をTEE（Trusted Execution Environment）上のsidecarに委譲します。

この記事では、0xhammadx氏が紹介した「モジュール化されたsidecar呼び出し」の流れと、Ritual Chain公式ドキュメントが説明するHTTP・LLM precompileの仕組みを整理します。

この記事でわかること

スマートコントラクトがHTTPとLLMを呼び出す具体的な流れ
0x0801（HTTP）と0x0802（LLM）がそれぞれ担う役割
TEE attestationで結果の正当性を担保する理由

コントラクトが全部やらなくていい理由

従来のEVMは、トークン送金やストレージ更新など決定論的な処理に向いています。一方、外部APIへのHTTPリクエストやLLM推論は、ネットワークI/OとGPU計算を伴い、全バリデータが同じ結果を再現する方式とは相性が悪いです。

Ritual Chainのドキュメントでは、この問題を「レプリケーションではなく委譲（delegation）」で解くと説明しています。LLM推論はGPUで数秒かかり、温度パラメータ付きのサンプリングは意図的に非決定論的です。正直なバリデータ同士でも出力が一致しないのは、バグではなく仕様です。

0xhammadx氏の投稿でも、「スマートコントラクトが自前で全処理を担う必要はなく、特定の計算タスクごとにモジュール化されたsidecarを呼び出す」という設計が示されています。コントラクトはオーケストレーターに徹し、HTTP取得やLLM実行は専用モジュールへ渡します。

TEE-EOVMTと3層アーキテクチャ

https://docs.ritualfoundation.org/

Ritual ChainはTEE-EOVMT（Off-chain Verifiable Machine Tasks対応のEVM）上で動作します。アーキテクチャは3層に分かれます。

アプリケーション層 — フロントエンドとスマートコントラクト
precompile層 — 16個の組み込みコントラクト（HTTP、LLM、ONNXなど）
チェーン層 — AsyncJobTracker、RitualWallet、Schedulerなどのオーケストレーション

コントラクトから0x0801や0x0802を呼ぶと、実際の処理はTEE内のexecutorが実行します。executorは結果を偽造できません。各レスポンスは、リクエスト内容と結びついた暗号学的証明として返され、TEEServiceRegistryに登録されたexecutorのattestationのみがブロックビルダーに受理されます。

0x0801：HTTP取得をTEE内で完結させる

0x0801はHTTP precompileです。コントラクトから見ると通常のprecompile呼び出しと同じですが、裏側ではTEEが外部APIへリクエストを送り、レスポンスにattestationを付けて返します。

公式ドキュメントの説明によると、オラクルやオフチェーンrelayerを挟まず、1回のprecompile呼び出しで価格フィード更新やマーケット決済まで完結できます。レスポンスボディはbytes型で返るため、テキストはTextDecoderでデコードします。HTTPステータスコードとは別に、precompileレベルのエラーはerrorMessageフィールドで確認する必要があります。

HTTP precompileはShort-Running Async（単一フェーズ）に分類されます。ブロックビルダーがprecompile呼び出しを検知すると、TEE executorへジョブを送り、署名済み結果を同じトランザクション内でコントラクトに返します。処理時間の目安は100ミリ秒から2秒程度です。

0x0802：TEE enclave内でLLMを動かす

0x0802はLLM precompileです。0xhammadx氏の投稿でも、「言語モデルをTEE enclave内で実行する」モジュールとして位置づけられています。

Ritual Chainではzai-org/GLM-4.7-FP8（64Kコンテキスト、MITライセンス）をTEE fleet上で直接ホストしています。OpenAIやAnthropicのAPIキーをコントラクト側で管理する必要はなく、プロンプトを送れば同一トランザクション内でcompletionを受け取れます。

フロントエンドで逐次表示が必要な場合は、ストリーミングにも対応しています。トランザクション確定前にSSEでトークンが届き、各チャンクはEIP-712で署名されるため、UI側でTEE由来であることを検証できます。

LLM precompileもHTTPと同様にShort-Running Asyncです。ただし制約として、1トランザクションあたりの非同期precompile呼び出しは1回までです。HTTPとLLMを同じtxで組み合わせることはできず、Schedulerで別トランザクションに分割するか、ワークフローを設計し直す必要があります。

結果が返る3つの経路

precompileの処理時間によって、結果の受け取り方が変わります。

経路	対象	結果の返却方法
Synchronous	ONNX（`0x0800`）、Ed25519など	同一コールフレーム内で即時返却
Short-Running Async	HTTP（`0x0801`）、LLM（`0x0802`）	同一tx内で`receipt.spcCalls`に格納
Long-Running Async	Long HTTP（`0x0805`）、Agent（`0x080C`）など	コールバックtxで別途配信

HTTPとLLMは中間層に位置し、数秒以内に終わる外部連携とAI推論をオンチェーンから直接扱える点が特徴です。画像・音声・動画生成やCLI型エージェント実行はLong-Running側に回され、完了後にコールバックで結果が届きます。

Flashbots Sirrahとの共通点

この設計思想はRitual固有のものではありません。FlashbotsのSirrah（SUAVE向けTEE coprocessor）でも、EVMに追加precompileを載せ、SGX enclave上のKettleノードが実処理を担う構成が採られています。ベースチェーンのバリデータには意味を持たないprecompileアドレスが、TEEノード側ではHTTP取得やattestation生成として機能する点は、今回のsidecarモデルと同型です。

違いは、Ritual ChainがHTTP・LLM・ONNX・マルチモーダル生成まで16個のprecompileをチェーン標準機能として提供していることです。開発者はSolidityから固定アドレスを呼ぶだけで、TEE executorへのルーティングやattestation検証のインフラを意識せずに済みます。

開発者が押さえる注意点

まず、非同期precompileを使う前にRitualWalletへ残高を入金しておく必要があります。executor報酬、コミットメント費用、インクルージョン費用の3分割で課金されます。

次に、Long-Running Asyncではコールバック到着までの間にオンチェーン状態が変わるTOCTOU（Time-of-Check to Time-of-Use）リスクがあります。precompileはコミット時点の入力を固定しますが、コールバック時に前提条件がまだ成立しているかはコントラクト側で再検証する必要があります。

最後に、1ウォレットあたり同時に1件までしか非同期ジョブを持てません。フロントエンドでは、同一EOAからの非同期リクエストを直列化する設計が求められます。

次に試すなら

Ritual Chainのテストネット（Chain ID 1979）では、HTTP precompileで外部APIのレスポンスをそのままオンチェーン状態に書き込む最小コントラクトから着手するのが近道です。LLM precompileはプロンプト設計とconvoHistoryフィールドの扱いが肝になるため、まずHTTP連携で非同期ライフサイクルに慣れてから組み合わせると、Schedulerを使った分割トランザクション設計までスムーズに進められます。