3.1 ネットワークインフラ (Network Infrastructure)

背景と特定された課題
伝統的なブロックチェーンネットワークは通常、ノードインフラを管理するためにソフトウェア層であるオペレーティングシステム（OS）に依存しています。これにより、特に高負荷な取引状況下でレイテンシ（遅延）を引き起こし、ハードウェア効率を低下させるアーキテクチャが生じます。ハードウェアとアプリケーションの間に存在する追加の層は、パフォーマンスのボトルネックになったり、セキュリティ管理の複雑さを増大させたりする可能性があります（Cachin & Vukolić, 2017）。

なぜベアメタル展開なのか？

Qubicは、仮想マシンや伝統的なOSに依存せず、コアソフトウェアをベアメタルハードウェア上で直接実行することで、パフォーマンスとセキュリティを向上させます。

このアーキテクチャ上の決定は、OSレベルの抽象化を排除し、ブロックチェーン運用、通信プロトコル、スマートコントラクト実行、および取引処理に必要な高いパフォーマンスを実現するためにハードウェア機能を直接使用するものです。

ベアメタル展開の利点:

• 信頼性:
  • 基本機能にUEFIシェルを使用することで、簡素化され制御された環境を提供し、複雑なOSに関連する潜在的な攻撃ベクトルを削減します。
  • サードパーティのソフトウェアプラットフォームへの依存を排除することで、Qubicは信頼性を向上させ、予期しないアップデートや互換性の問題による混乱のリスクを軽減します。

• 有効性:
  • 伝統的なOSがないことで計算上のオーバーヘッドとレイテンシが削減され、Qubicがハードウェア機能を効率的に活用できるようになります。
  • UEFIシェルは、取引のリアルタイム処理を含む高いスループットを必要とするアプリケーションにおいて極めて重要な、高速な起動と簡素化されたハードウェアレベルのアクセスを促進します。

• セキュリティ:
  • ソフトウェアスタックを最小限に抑えることで、Qubicは潜在的な攻撃対象領域を大幅に縮小し、OSレベルのエクスプロイトに対して強力な保護を提供します。
  • ベアメタル展開のアプローチは、インターネット経由で一般的に標的となる脆弱性を排除することで、リモート攻撃のリスクをさらに軽減します。
  • 代わりに、ベアメタルシステムを侵害するにはハードウェアへの物理的なアクセスが必要となり、リモートのアタッカーにとっては大幅に困難な課題となります。
  • これは、複雑さを軽減し不要なシステム層を削除することが脆弱性を最小限に抑える鍵であるという、Shostack（2014）の原則に一致しています。
  • さらに、ベアメタルノードのセットアップと維持に必要な努力は自然な参入障壁を生み出し、システムを深く理解した献身的な参加者のみがネットワークの一部となることを確実にします。
  • これは、より安全で回復力のあるエコシステムに寄与します。

裏付けとなる研究と引用
分散システムと高性能コンピューティングの研究によれば、ベアメタル展開はシステムの応答性を向上させ、特にリアルタイム環境における重要なアプリケーションのレイテンシを削減することが示されています（Rosenblum & Garfinkel, 2011）。ブロックチェーンプラットフォームで見られるような重い取引負荷を扱う分散ネットワークのシナリオにおいて、ベアメタルアーキテクチャはスループットの向上とレイテンシの削減という実質的なメリットを提供します（Cachin & Vukolić, 2017）。

定量的な指標とパフォーマンスの向上
最適化されたスマートコントラクト実行環境（セクション3.2参照）を備えたQubicのベアメタルインフラのテストでは、大幅なパフォーマンスの改善が示されました。スマートコントラクトのベンチマーク結果によると、取引のレイテンシが減少し、スループットの向上により1秒間に最大5,500万件のQUBICコイン送金が可能になっています（Qubic Team, 2024）。

背景と特定された課題
あらゆる分散型ネットワークにおいて、ノード間の通信は、コンセンサスの維持、データの整合性、およびタイムリーな取引処理のために極めて重要です。従来のブロックチェーンは、非効率な通信プロトコルによるボトルネックを経験することが多く、それが取引時間の鈍化やスケーラビリティの低下を招いています（Decker & Wattenhofer, 2013）。ネットワークのレイテンシ（遅延）や帯域幅の制限はコンセンサスメカニズムを妨げ、ネットワーク全体のパフォーマンスに影響を及ぼす可能性があります。

最適化されたノード間通信
Qubicは、低レイテンシと高スループットのために最適化された、独自の伝送制御プロトコル（TCP）ベースの通信プロトコルを実装することで、これらの課題に対処しています。このプロトコルはネットワーク全体での迅速なメッセージ伝送を保証し、取引やコンセンサス関連データの効率的な伝播を促進します。

クォーラムベースのコンセンサスモデル（セクション3.2.1参照）は、大多数のComputorが迅速に合意に達することを可能にし、取引の確定（ファイナリティ）における遅延を最小限に抑え、ノードの故障に対するネットワークの回復力を向上させます。Qubicは、ネットワークのより優れたスケーラビリティと信頼性を達成するために、通信プロトコルとコンセンサスメカニズムの両方を最適化するように設計されています。

通信プロトコルに関する知見
効果的な通信プロトコルは、分散ネットワークにおける取引速度の向上とシステム信頼性の実現に不可欠です。Nguyenら（2016）やDecker & Wattenhofer（2013）によって行われた主要な研究では、高性能コンピューティング環境においてレイテンシを最小化しスループットを向上させるための、カスタマイズされたTCP実装の重要性が指摘されています。

定量的な指標とパフォーマンスの向上
Qubicの通信プロトコルにより、ノードは1秒未満（サブセカンド）の間隔でコンセンサスを達成することが可能です。この改善により、Qubicは、即時の取引確定を必要とするリアルタイムのアプリケーションやサービスにとって極めて重要な、高頻度取引を処理できるようになります。

ピア共有 (Peer Sharing)
ネットワーク内の物理ノードであるピアは、ピア共有の文脈においてIPv4アドレスによって識別されます。これらはソースコード内では「パブリックピア（public peers）」と呼ばれます。各ノードは、既知のパブリックピアの初期セット（理想的には少なくとも4つ）を必要とします。自身のIPアドレスも、通常のピアとして `knownPublicPeers` に含める必要があります。

ピアは「検証済み（verified）」かどうかの状態を持ちます。検証済みのピアは他のピアと共有されます。`knownPublicPeers` 内のIPは、デフォルトで検証済みのステータスを取得します。

ピアは、Qubicノードのハンドシェイクとして扱われる `ExchangePublicPeers` メッセージを通じて共有されます。このメッセージは、新しい接続が確立された後（ノードがランダムに選択されたパブリックピアに接続した後）に送信されます。共有のためのIPは、検証済みピアのリストからランダムに選択されます（ただし、`ExchangePublicPeers` メッセージ内に重複したIPが含まれる場合があります）。リストに検証済みピアが存在しない場合は、`ExchangePublicPeers` とともにIPとして “0.0.0.0” を送信しなければなりません。

検証済みピアへの外向きの接続が拒否された場合、そのピアは検証済みステータスを失います。未検証のピアへの外向きの接続が拒否された場合、そのピアはピアリストから削除されます。未検証のピアへの外向きの接続が承認され、`ExchangePublicPeers` メッセージが受信された場合、そのピアは検証済みステータスを取得します。通信中のいかなる時点でもプロトコル違反が検出された場合（相手側がQubicノードではない何かを実行していると推測できる場合）、そのIPは検証済みであっても削除されます。IPがピアリストから削除されるのは、削除後もリストに少なくとも10個のエントリが残っており、かつそのIPが初期の `knownPublicPeers` に含まれていない場合に限られます。