---
id: 15
title: Bitroot のポジショニング：楽観的並列 EVM Layer 1 の境界
slug: bitroot-positioning
date: 2026/09/01
summary: 楽観的並列 EVM Layer 1 を選ぶことは、決済ドメイン、互換性、並列戦略における同時のトレードオフを意味します。本稿は Bitroot が解決することと解決しないことをスローガンではなく境界として述べ、技術要素がどう支え合うかを示します。
keywords: Bitroot,楽観的並列EVM,Layer 1,プロダクトのポジショニング,Pipeline BFT
heroImage: /images/community-bg.png
---

スループットの数値だけを引用するパブリックチェーンの物語は、次のより大きな数値に簡単に上書きされます。検証に耐えるのは座標です。スケーリングマップのどのセルか、並列実行の三つの路線のどれか、そしてその選択が認めるコストは何か。以前の記事で枠組みを敷きました。単一スレッドの上限、階層的なスケーリング、決定論的／楽観的／オブジェクトモデル、そして OCC のデータベースとしての骨格です。本稿はその枠組みを Bitroot に重ねます。何であると主張するのか、境界はどこか、どの記述がテストとエンジニアリング検証の言葉に留まるべきか。

## 一文でのポジショニング、語ごとに

Bitroot は、楽観的並列 EVM の上に築かれた高性能 Layer 1 として自らを位置づけ、決済、コンポーザブル DeFi、大規模なオンチェーン調整という、より広い実行幅を必要とするシナリオを狙います。すべての語がトレードオフです。

ロールアップではなく Layer 1 であることは、独自のコンセンサスとバリデータ集合を運営することを意味し、セキュリティを「イーサリアムから継承している」と気軽に説明することはできません。その代わり、決済と実行が同じドメインを共有し、既定のブリッジホップを省けます。決定論的な事前宣言ではなく楽観的並列を選ぶことは、依存関係の発見をランタイムに任せ、開発者が慣れ親しんだ方法で Solidity を書き続けられるようにします。オブジェクトモデルへのスタック変更ではなく EVM 互換性を貫くことは、データモデルがもたらすはずの構造的な並列性の一部を諦め、難しい問題をスケジューリング、コンフリクト検出、状態の構成へ押し出すことを意味します。

同じ楽観的並列 EVM 路線の仲間は、近い物語を異なるエンジニアリングの配合で追求しています。コンセンサスと実行の分離、サブ秒の最終性目標、決済レイヤーとしての枠組みです。Bitroot の差別化は、「並列性の唯一の発明者」のような検証不能な主張ではなく、具体的な仕組みの組み合わせにあるべきです。

## 三つのレイヤー：コンセンサス、実行、状態

Bitroot を理解するには、実行のスローガンを越えて、三つのレイヤーがどう協調するかを見る必要があります。

コンセンサス層はパイプライン化された BFT スタイル（Pipeline BFT）に従います。propose／vote／commit をパイプライン化して異なる高さの作業を重ね、リーダーローテーションと署名集約でバリデータ集合の拡大に伴う通信の爆発を和らげます。目標は「トランザクション順序を素早く確定する」ことがスループットの最初の壁にならないことです。仕組みの詳細は Pipeline BFT に関する既存の技術記事にあります。ここでの要点は役割分担です。コンセンサスが担うのは順序と最終性のパスであり、プロトコル内ですべての EVM 呼び出しを解釈することではありません。

実行層は楽観的並列 EVM です。ブロックの固定順序の下での投機的実行、読み書き集合の収集、コンフリクト検出、影響を受けるトランザクションの再実行により、最終状態が直列セマンティクスと等しくなるようにします。動的なグループ化と多段階のコンフリクト検出は、楽観的な賭けが外れたときのコストを局所化し、「一つのコンフリクトでバッチ全体が無効になる」ことを避けます。公開デモやテストネット環境のスループットとレイテンシの数値は、ハードウェア、トランザクションの構成、コンフリクト率の仮定と併せて読む必要があります。それらはエンジニアリングの進展を示すものであり、メインネットの混合負荷下での保証ではありません。

状態層は、アカウントやストレージの分割、キャッシュ、大きなオブジェクトの戦略を扱います。「実行は並列だが、単一の状態構造とディスクパスが依然として直列化する」という次のボトルネックです。パーティション間のメッセージングとホットデータの配置が、コンポーザブル DeFi が実際に並列の利得を捕まえられるかを決めます。ワークロードのホットスポット分析と同じ問題群です。

三つのレイヤーは協調して分離します。順序は先に確定でき、実行はその順序に対応する状態ルートへ非同期に収束し、コンセンサスが実行で遊ぶ偽の直列性を避けます。どれか一つのレイヤーが欠けると、ポジショニングは点の最適化に崩れます。

| レイヤー | 仕組みの焦点 | 主に解決する問題 |
|-------|-----------------|--------------------------|
| コンセンサス | パイプライン化 BFT、リーダーローテーション、署名集約 | BFT の直列フェーズとメッセージングコスト |
| 実行 | 楽観的並列、読み書き集合、コンフリクト時の再実行 | 単一スレッド EVM の実行幅 |
| 状態 | 分割、キャッシュ、大きなオブジェクトの戦略 | 単一点の状態とストレージパスのボトルネック |

## 明示的に選ばないもの

「EVM を捨ててオブジェクトモデルで並列性を買う」ことは選びません。移行と監査のコストがランタイムのスケジューリングコストより高いと判断しています。「アクセスリストを必須にした決定論的 EVM」も選びません。既存のバイトコードエコシステムと衝突します。「L2 にすぎず、難しい問題はすべてイーサリアムの DA と決済に押し戻す」ことも選びません。プロダクトは同一ドメインでの決済と自律的な性能の反復を望み、それはバリデータの分散化とセキュリティ前提の周りの通信負担を自ら負うことを意味します。

これらの「選ばない」線が、スローガンよりもよく境界を定義します。Bitroot は汎用の DA レイヤーではなく、最も深い流動性と決済のアンカーというイーサリアムのニッチを置き換えるものでもありません。別の L1 決済ドメインを提供し、実行幅のために楽観的並列を、移行摩擦の低さのために EVM 互換性を選んでいます。

## ポジショニングが実際に試されるシナリオ

読み書き集合が比較的分散した決済負荷は、楽観的並列が最も現金化しやすい領域です。レイテンシの安定性と手数料の予測可能性は、ピーク TPS よりもプロダクトにとって重要なことがよくあります。

コンポーザブル DeFi はストレステストです。一つのルートが順に多くのプールやヴォールトに触れることがあり、書き込みコンフリクトが増えます。エンジンが再実行の範囲を縮小できなければ、スループットは急速に落ちます。そのシナリオに直面することを選ぶことは、決済レイヤーが「無関係な送金」ベンチマークだけで良く見えるわけにはいかないことを認めることです。ホットスポットがどう生まれ、どう測定するかはワークロードの議論に属します。

大規模な調整と複雑な状態機械は、状態の構成とパーティション間プロトコルに圧力をかけます。実行の並列化は CPU 幅を買いますが、状態が追随できなければ、その幅は I/O とロック的なコンフリクトに食われます。

## いまだ検証途上の判断

公開で追跡可能な情報の範囲では、性能と安定性に関する多くの結論は依然としてテストネット、ベンチマーク、段階的なデモから来ています。バリデータの規模、クライアントの成熟度、メインネット級の敵対的条件は、ポジショニングが成り立つかどうかを変えます。分散化と性能の緊張は OCC を選んだからといって消えるわけではなく、ハードウェアの下限、帯域、状態の成長については依然として正直に別途議論する必要があります。

Bitroot を地図に戻しましょう。占めるのは「L1＋楽観的並列実行＋EVM 互換性」というセルであり、「スケーリング」という語の下のすべてのセルではありません。次に自然に湧く問いは、EVM 互換性が実際に何をカバーするのか——バイトコードか、プリコンパイルか、ツールチェーンか——です。互換性が縮めば、すでに支払ったエコシステムの対価も一緒に崩れるからです。

## 関連記事

- 前：[「楽観的並行制御（OCC）入門：データベースからオンチェーン実行へ」](/ja/blog/optimistic-concurrency-control-intro)
- 次：[「EVM 互換とは実際に何を意味するのか：バイトコード、プリコンパイル、ツールチェーン」](/ja/blog/evm-compatibility-explained)
- 関連：[「Bitroot の並列化 EVM 技術解説：楽観的並列化」](/ja/blog/bitrootevm-)、[「Bitroot のマルチエンジン並列実行設計の深掘り：EVM 性能ボトルネックの打破」](/ja/blog/bitroot-evm)、[「Bitroot の詳細分析：Pipeline BFT とマルチエンジン並列実行の相乗アーキテクチャ」](/ja/blog/bitroot-pipeline-bft)、[「分散化と性能の緊張：バリデータ要件、ハードウェア、地理的分布」](/ja/blog/decentralization-performance-tradeoff)