仕組みの解説2026-10-27約 4分

OracleのBesu基盤：EVM互換性と参加権限は別の話

Oracleの26.3.1発表は、Besuを中心とする企業向け基盤を説明している。コントラクト実行、参加権限、署名の管理、リリース承認、SQLによる履歴参照は別々の役割を持つ。

コードの互換性と参加許可を表したAI生成の概念図。実在するOracle施設や確認済みの導入事例を再現したものではない。

要点

Oracleは10月27日の発表で、26.3.1を10月のLimited Availabilityと記した。Besu、QBFT、カストディ型ウォレットは26.2の文書にも登場する。
EVM互換性はコントラクト実行に関する性質だ。承認された検証者、ウォレットの署名、リリースの承認は、それぞれ異なる判断を担う。
Rich Historyは台帳の活動をSQLで参照するための任意の索引であり、調査や報告に使う。ブロックチェーンの合意を置き換えるものではない。

出来事のタイムライン

2026-10-27Oracleが26.3.1の基盤を紹介

デジタル資産アプリケーション向けの統合された制御機能を説明し、2026年10月のLimited Availabilityと記した。

提供範囲が限定された発表

2026年10月27日、OracleはBlockchain Platform Enterprise Edition 26.3.1の概要を公開した。許可型のデジタル資産アプリケーション向けに統合された構成を説明し、提供状況を2026年10月のLimited Availability（限定提供）と記している。製品と提供範囲についての発表であり、紹介されたアプリケーションが特定の金融機関で本番稼働した証拠ではない。^[1]

見出しを読む際には、バージョンの違いにも注意が必要だ。以前の26.2文書には、QBFTを使うBesuの検証者、Ethereum JSON-RPCへのアクセス、カストディ型ウォレットサービスが既に記載されている。今回がBesu、QBFT、署名のカストディ機能への初対応だとは書けない。注目すべきなのは、文書に示された制御機能の役割分担だ。^[3][1]

実行規則が共通でも台帳は別

26.3の構成では、Ethereum Virtual Machine、つまりEVMでSolidityのコントラクトを実行する。アプリケーションから要求を受け付けるRPC Proxyを通じ、Ethereum方式のインターフェースを提供する。ただし同じ文書は、独自のBesuインスタンスとノードの役割を持つ許可型のプライベートEthereumネットワークと説明している。^[2]

実行の互換性とネットワークへの参加資格は、別の性質である。EVMを使うだけで、取引が公開Ethereumに記録されるわけではない。この設計では、取引は設定されたBesuネットワークへ送られる。アプリケーションを理解するには、使える契約言語に加え、誰がネットワークを運営し、誰が参加できるかを知る必要がある。^[2]

要求への署名とブロックへの合意

Oracleは各機能を分けている。RPC Proxyは呼び出し元の組織を特定し、基盤のアクセス制御を適用する。Universal Wallet as a Service（UWaaS）はカストディ型ウォレットとポリシーのサービスを提供し、インスタンスごとのウォレットサービスがBesu向けの署名や取引の送信を担う。アプリケーションが秘密鍵を直接扱う代わりに、署名サービスが利用者に代わって鍵を管理する構成だ。^[2]

Besuの検証者はQBFTでブロックに合意する。Oracleは、承認された組織が検証を分担し、プロトコルの障害許容範囲内で、コミットされた取引に確定的なファイナリティを与えると説明する。有効な署名、要求を送る権限、台帳上の順序への合意は、この経路の別々の要素だ。「EVM互換」という言葉だけでは、それぞれを誰が管理するかは分からない。^[1][2]

コントラクトのリリースにも承認経路がある

発表は、コントラクトを最初に無効な状態で配置するガバナンス付きデプロイモードを説明している。設定された承認がGovernanceコントラクトを通じてオンチェーンに記録されると有効になり、アップグレードにも同じ承認経路が適用される。組織が選び、ポリシーを設定して運用するモードであり、すべてのSolidityコントラクトに自動で付く制御ではない。^[1]

コントラクトのレジストリは、ABI、バイトコード、ストレージレイアウトなどをバージョンごとに保持する。これらはソフトウェアによる呼び出し方、配置したコード、状態の保存構造を記述する。審査する側は具体的な実装を対象に承認でき、過去の状態を解釈する際にも使える。このリリース承認は、検証者によるブロックへの合意とは別の判断だ。^[1]

SQL履歴は台帳を見るためのデータ

Rich Historyは、ブロックチェーンの取引、イベント、実行トレース、状態をOracle DatabaseやMySQLへ複製し、索引を作成できる。管理者はSQLで検索し、オフチェーンの業務記録と組み合わせて報告や照合に利用する。26.3の概要では、Rich Historyとアーカイブノードは任意の構成要素と明記されている。^[2][4]

このアーキテクチャは、履歴の参照を実行や合意と区別している。検証者がブロックに合意し、Rich Historyの構成要素が台帳情報を取り込む。コンソーシアムの参加者は設立組織が提供するデータベースを共有しても、自分のノードに接続したデータベースを別に持ってもよい。SQLの結果は取得済みの履歴への問い合わせであり、新たな検証者合意ではない。^[2][4]

互換性の表示から、権限の中身へ

Oracleの発表は、なじみのあるコントラクトコードの周囲に、ネットワーク参加、鍵のカストディ、リリース承認、履歴参照という独立した選択があることを示す具体例だ。文書が説明するのは、基盤として意図された動作である。提供状況や設計の説明だけでは、特定機関の本番導入は確認できず、これらの私設ネットワークが公開Ethereumの一部になるわけでもない。何が発表されたかを理解するには、この境界も読む必要がある。^[1][2]

次の疑問へ