[cite_start]Qubic のインフラストラクチャは、ブロックチェーントランザクションと AI トレーニングの両方の計算要件に対処するように設計されています。 [cite: 433] [cite_start]次のセクションでは、直接的なハードウェア操作と最適化された通信が、ネットワークの効率とセキュリティにどのように貢献するかを探ります。 [cite: 434]

[cite_start]背景と特定された問題 [cite: 436]

[cite_start]従来のブロックチェーンネットワークは、通常、ノードインフラストラクチャを管理するためにソフトウェア層のオペレーティングシステム (OS) に依存しています。 [cite: 437] [cite_start]これにより、特に高トランザクション負荷の下で、遅延を引き起こし、ハードウェア効率を低下させるアーキテクチャが作成されます。 [cite: 438] [cite_start]ハードウェアとアプリケーションの間の追加の層は、パフォーマンスのボトルネックになるか、セキュリティ管理の複雑さを増す可能性があります。 [cite: 439]

[cite_start]ベアメタルデプロイメントの理由 [cite: 440]

[cite_start]Qubic は、仮想マシンや従来のオペレーティングシステムに依存するのではなく、コアソフトウェアをベアメタルハードウェア上で実行することにより、パフォーマンスとセキュリティを向上させます。 [cite: 441] [cite_start]このアーキテクチャ上の決定は、オペレーティングシステムレベルの抽象化を排除し、それによりハードウェア機能を直接使用して、ブロックチェーン操作、通信プロトコル、スマートコントラクトの実行、およびトランザクション処理に必要な高いパフォーマンスを満たします。 [cite: 442]

[cite_start]ベアメタルデプロイメントの利点: [cite: 443]

• [cite_start]信頼性: UEFI シェルを基本的な機能に使用することで、簡素化された制御された環境が提供され、それにより複雑なオペレーティングシステムに関連する可能性のある攻撃ベクトルが減少します。 [cite: 445] [cite_start]サードパーティのソフトウェアプラットフォームへの依存を排除することにより、Qubic は信頼性を向上させ、予期しない更新や互換性の問題によって引き起こされる潜在的な中断を減らします。 [cite: 446]
• [cite_start]有効性: 従来のオペレーティングシステムの欠如は、計算オーバーヘッドと遅延を減らし、Qubic がハードウェア機能を効率的に活用できるようにします。 [cite: 447] [cite_start]UEFI シェルは、より高速な起動時間と簡素化されたハードウェアレベルのアクセスを促進し、リアルタイムのトランザクション処理を含む高スループットを必要とするアプリケーションで不可欠です。 [cite: 448]

qubic whitepaper qubic.org 27

PAGE 29

• [cite_start]セキュリティ: ソフトウェアスタックを最小限に抑えることにより、Qubic は潜在的な攻撃対象領域を大幅に削減し、オペレーティングシステムレベルのエクスプロイトに対する強力な保護を提供します。 [cite: 452] [cite_start]ベアメタルデプロイメントアプローチは、インターネットを介して一般的に標的とされる脆弱性を排除することにより、リモート攻撃のリスクをさらに軽減します。 [cite: 453] [cite_start]代わりに、ベアメタルシステムを侵害するには、ハードウェアへの物理的なアクセスが必要となり、リモート攻撃者にとって著しくより困難なタスクとなります。 [cite: 454] [cite_start]これは、複雑さを減らし、不要なシステム層を削除することが脆弱性を最小限に抑えるための鍵であるという Shostack の原則と連携しています。 [cite: 455]

[cite_start]さらに、ベアメタルノードを設定および維持するために必要な労力は、自然な参入障壁を作成し、システムを深く理解している献身的な参加者のみがネットワークの一部になることを保証します。 [cite: 456] [cite_start]これは、より安全で回復力のあるエコシステムに貢献します。 [cite: 457]

[cite_start]支持する研究と引用 [cite: 458]

[cite_start]分散システムおよび高性能コンピューティングにおける研究は、ベアメタルデプロイメントが、特にリアルタイム環境において、重要なアプリケーションのシステム応答性を向上させ、遅延を減らすことを示しています。 [cite: 459] [cite_start]ブロックチェーンプラットフォームで発生するような重いトランザクション負荷に対処する非中央集権型ネットワークシナリオでは、ベアメタルアーキテクチャはスループットの増加と遅延の削減という実質的な利点を提供します。 [cite: 460]

[cite_start]定量的メトリックとパフォーマンスの向上 [cite: 461]

Qubic のベアメタルインフラストラクチャは、最適化されたスマートコントラクト実行環境 (セクション 3.2 を参照) とともに、大幅なパフォーマンスの改善を示しています: [cite_start]スマートコントラクトのベンチマーク結果によると、トランザクション遅延が減少し、スループットの向上により、1 秒あたり最大 5500 万 QUBIC コインの転送が可能になります。 [cite: 462]

[cite_start]背景と特定された問題 [cite: 464]

[cite_start]すべての非中央集権型ネットワークでは、コンセンサスの維持、データの整合性、およびタイムリーなトランザクション処理のために、ノード間の通信が重要です。 [cite: 465] [cite_start]従来のブロックチェーンは、非効率な通信プロトコルのためにボトルネックを経験することが多く、トランザクション時間の遅延とスケーラビリティの低下につながります。 [cite: 469] [cite_start]ネットワーク遅延と帯域幅の制限は、コンセンサス機構を妨げ、全体的なネットワークパフォーマンスに影響を与える可能性があります。 [cite: 470]

qubic whitepaper qubic.org 28

PAGE 30

[cite_start]最適化されたノード通信 [cite: 471]

[cite_start]Qubic は、カスタムの伝送制御プロトコル (TCP) ベースの通信プロトコルを実装することにより、これらの課題に対処します。これは、低遅延と高スループットのために最適化されています。 [cite: 472] [cite_start]このプロトコルは、ネットワーク全体での迅速なメッセージ送信を保証し、トランザクションとコンセンサス関連データの効率的な伝播を促進します。 [cite: 473] [cite_start]クォーラムベースのコンセンサスモデル (セクション 3.2.1 を参照) は、Computors の大多数が迅速に合意に達することを可能にし、トランザクションファイナリティの遅延を最小限に抑え、ノード障害に対するネットワークの回復力を向上させます。 [cite: 474] [cite_start]Qubic は、ネットワークのより良いスケーラビリティと信頼性を達成するために、通信プロトコルとコンセンサス機構の両方を最適化するように設計されています。 [cite: 475]

[cite_start]通信プロトコルに関する洞察 [cite: 476]

[cite_start]効果的な通信プロトコルは、分散ネットワークにおけるトランザクション速度の向上とシステム信頼性の実現に不可欠です。 [cite: 477] Nguyen et al. (2016) [cite_start]や Decker & Wattenhofer (2013) によって実施されたような主要な研究は、高性能コンピューティング設定における遅延の最小化とスループットの強化における調整された TCP 実装の重要性に注目しています。 [cite: 478, 479]

[cite_start]定量的メトリックとパフォーマンスの向上 [cite: 480]

[cite_start]Qubic の通信プロトコルにより、ノードはサブ秒間隔でコンセンサスを達成できます。 [cite: 481] [cite_start]この改善により、Qubic は、リアルタイムアプリケーションや即時のトランザクションファイナリティを必要とするサービスにとって重要な高頻度トランザクションを処理できます。 [cite: 482]

[cite_start]ピア共有 [cite: 483]

[cite_start]ピア (ネットワーク内の物理ノード) は、ピア共有のコンテキストで IPv4 アドレスによって識別されます。 [cite: 484] [cite_start]それらはソースコードで「public peers」と呼ばれています。 [cite: 485] [cite_start]各ノードは、既知のパブリックピアの初期セット (理想的には少なくとも 4) を必要とします。 [cite: 486] [cite_start]自身の IP アドレスは、通常のピアとして既知の Public Peers に含める必要があります。 [cite: 487]

[cite_start]ピアは、検証済みまたは未検証の状態を持つことができます。 [cite: 491] [cite_start]検証済みのピアは、他のピアと共有されます。 [cite: 491] [cite_start]既知の PublicPeers の IP は、デフォルトで検証済みのステータスを取得します。 [cite: 492] [cite_start]ピアは、Qubic ノードのハンドシェイクと見なすことができる Exchange PublicPeers メッセージを通じて共有されます。 [cite: 493] [cite_start]メッセージは、新しい接続が確立された後に送信されます (ノードはランダムに選択されたパブリックピアに接続します)。 [cite: 494] [cite_start]共有する IP は、検証済みのピア IP の中からランダムに選択されます (ただし、Exchange PublicPeers メッセージに重複した IP が含まれる場合があります)。 [cite: 495] [cite_start]ピアのリストに検証済みのピアがない場合は、Exchange PublicPeers とともに IP として “0.0.0.0” を送信する必要があります。 [cite: 496]

[cite_start]検証済みのピアへの送信接続が拒否された場合、そのピアは検証済みステータスを失います。 [cite: 497] [cite_start]未検証のピアへの送信接続が拒否された場合、そのピアはピアのリストから削除されます。 [cite: 498] [cite_start]未検証のピアへの送信接続が受け入れられ、Exchange PublicPeers メッセージが受信された場合、そのピアは検証済みステータスを取得します。 [cite: 499] [cite_start]通信中にプロトコル違反が検出された場合 (リモートエンドが Qubic ノードではない何かを実行していると想定できる場合)、検証済みであっても IP は削除されます。 [cite: 500] [cite_start]IP は、リストに少なくとも 10 のエントリが残っている場合、かつ初期の既知の PublicPeers にない場合にのみ、ピアのリストから削除されます。 [cite: 501]

qubic whitepaper qubic.org 29

PAGE 31