Last Updated on 2026年10月1日 by oba3
コインベース（Coinbase）が支援するレイヤー2のBaseは、2026年9月30日にメインネットでCobaltアップグレードを実施した。今回の更新では、オンチェーン状態を条件として取引の取り込み可否を判断するValidity Transactions、B20トークン規格の機能拡張、将来のアップグレード運用に向けた仕組みなどが導入された。
注目点はTPSや手数料の改善だけではない。残高やコントラクトの状態、ブロック番号などを条件として、取引をブロックへ取り込める状態を制御できるようになったことで、金融アプリが外部システムへ依存していた一部の処理をチェーンに近い場所へ配置できる。Baseが高速なL2から、市場を構築するための機能を持つ基盤へどこまで進むのかを見るアップグレードだ。
何が起きたのか？
Cobaltは2026年9月23日にSepoliaテストネットへ導入され、9月30日にBaseメインネットで稼働した。BaseのCobalt仕様では、Validity Transactions、B20の拡張、TEE署名者登録方式の変更、将来の動的なアップグレード運用に向けた機能などが主要項目として示されている。
金融アプリとの関係が深いのがValidity Transactionsだ。利用者は、残高、コントラクトのストレージ値、ブロック番号、Flashblock内の位置などを条件として取引へ付与できる。シーケンサーはその条件を確認し、条件が成立している取引だけを通常の手数料や実行ルールの下でブロックへの取り込み候補にする。
ここで重要なのは、条件成立が取引成功そのものを保証するわけではない点だ。Validity Transactionsが制御するのは、条件を満たしている間に取引をブロックへ取り込めるかどうかであり、その後のスマートコントラクト実行まで必ず成功させる機能ではない。
Baseは利用例として条件付きスワップなどを示している。価格に連動した処理を構築する場合も、Validity Transactionsが価格を直接読み取るのではなく、オラクルなどによってコントラクトへ保存されたオンチェーン状態を条件として利用する形になる。
同時にB20トークン規格も拡張された。複数のポリシーを組み合わせるUnionやIntersect、倍率更新のスケジュール設定に加え、権限を持つ管理者がトークン残高を再配分し、その理由を記録できるseizeWithMemoも追加された。資産発行だけでなく、管理権限や移転ルールまでトークン側へ持たせる機能が広がっている。
Cobaltには将来のアップグレード運用を柔軟化するための仕組みも含まれる。ただし、Cobalt時点のメインネットでは動的アップグレード機能は監視用のmetrics-onlyとして導入されており、今回からノード更新なしで自由にフォークを切り替えられるようになったわけではない。Cobalt自体の有効化は従来のスケジュール方式で行われた。
なぜ重要なのか？
これまでレイヤー2の比較では、TPS、ブロック生成速度、ガス代といった処理性能が目立ちやすかった。しかし金融アプリを運営する場合、必要なのは取引を高速に処理する能力だけではない。「どの状態なら取引を受け付けるか」「どの参加者に資産操作を認めるか」といった制御も必要になる。
従来こうした処理の一部は、スマートコントラクトに加えてキーパーと呼ばれる外部実行者や独自バックエンドを組み合わせて構築されてきた。Validity Transactionsによって、特定のフローでは外部キーパーを使わず、オンチェーン状態を基準として取引を待機させる設計が可能になる。
ただし、あらゆる金融ロジックがチェーン側へ移るわけではない。複雑な注文管理、オラクル、本人確認、リスク管理などは依然として別のコントラクトや外部システムを必要とする。今回増えたのは、金融アプリの処理をどこに置くかという設計上の選択肢である。
市場構造への影響
Cobaltを市場インフラとして見ると、取引と資産の二つの層が同時に拡張された点が重要になる。取引側ではValidity Transactionsがオンチェーン状態に応じた取り込み条件を扱い、資産側ではB20のポリシー機能が保有や移転に関する制御を持つ。
B20では許可リストや拒否リストなどのポリシーと複数条件の組み合わせに加え、管理権限を使った残高再配分も設計できる。これは規制資産や機関向け商品を構築する際に求められる制御と接点を持つ。ただし、B20そのものが本人確認や適格投資家判定、証券規制への適合を自動的に行うわけではない。
そのためCobaltの意味は、規制金融をチェーンだけで完結させたことではなく、アプリ開発者がこれまで独自に用意していた一部の市場機能を標準的なチェーン機能として利用できる範囲を広げたことにある。
今後ほかのL2でも同様の機能が広がるかはまだ分からない。現時点で確認できるのは、Baseが処理能力だけでなく、市場向け機能そのものをチェーンへ追加する戦略を取っていることだ。
資金・規制・流動性との関係
Cobaltの導入によってBaseへの資金流入や流動性が自動的に増えるわけではない。今回整備されたのは取引や資産を扱うための技術機能であり、市場規模への影響は、それを利用するサービスや金融商品がどこまで登場するかによって決まる。
Baseは2026年の戦略で、株式、コモディティ、予測市場、永久先物、現物市場などを含むグローバル市場を構築し、チェーンレベルで市場向けインフラを整備する方針を示している。Cobaltは、この方針を具体的なプロトコル機能へ落とし込む動きの一つとして位置付けられる。
規制資産を扱う場合には、本人確認、投資家資格、発行体の法的責任、情報開示などチェーン外の制度要件も残る。B20のポリシーや管理機能はそうした制度と接続するための技術的な部品にはなり得るが、それだけで法令対応が完了するわけではない。
流動性への影響を判断するには、Validity TransactionsやB20を使った市場が実際に増えるか、それらの市場へ取引量が集まるかを見る必要がある。技術機能の追加と金融市場としての利用拡大は分けて評価する必要がある。
初心者向け補足
Validity Transactionsは、「条件を満たしたら必ず成功する取引」ではなく、「条件を満たしている間だけブロックへの取り込み候補になれる取引」と考えると分かりやすい。
たとえば利用者があらかじめ取引へ署名し、特定のコントラクト状態になった場合だけ取り込み対象にすることができる。条件が合わなければシーケンサーはその取引をブロックへ含めず、設定した期限を過ぎれば失効させることもできる。
一方、取引がブロックへ取り込まれた後の実行には通常のスマートコントラクトのルールが適用される。そのためValidity Transactionsはスマートコントラクトを置き換えるものではなく、取引をチェーンへ入れる前段階に新しい条件判定を追加する仕組みと理解するとよい。
Web3Timesの視点
Cobaltで今後見るべきなのは、アップグレード直後のTPSではなく、新機能が実際のアプリ設計をどこまで変えるかだ。
第一の観測点は、Validity Transactionsを採用して外部キーパーへの依存を減らす取引サービスが登場するか。第二は、B20のポリシーやseizeWithMemoがトークン化株式や機関向け資産で実際に利用されるか。第三は、現在metrics-onlyの動的アップグレード機能が今後どの段階で本番のアップグレード運用へ組み込まれるかである。
これらが利用されれば、開発者がL2を選ぶ際の比較軸は処理速度や手数料だけではなくなる。どの取引条件を標準で扱えるか、資産へどのような管理機能を持たせられるか、外部システムへ依存する処理をどこまで減らせるかといった違いも重要になる。
Cobaltは、L2全体の競争がすでにこの方向へ移ったことを示すものではない。現時点で言えるのは、Base自身が市場向け機能をチェーンレベルへ追加する戦略を具体化し始めたということだ。今後その機能が実際の金融アプリに採用されるかが、今回のアップグレードの価値を測る次の材料になる。
