SolanaのProof of History：PoHの仕組み

正確性に関する注意：ネットワークのパフォーマンス、バリデーター数、手数料、プロトコル機能、ウォレットのサポート、およびサードパーティの統合は時間の経過とともに変化します。古い数値は歴史的なスナップショットとして扱い、現在の一次ソースドキュメントを確認してください

SolanaのProof of Historyは暗号技術による時間順序付けメカニズムであり、スタンドアロンのコンセンサスプロトコルではありません。これはTower BFTやProof of Stakeと連携して、バリデーターがイベントを順序付けし、台帳に合意するのを支援します。

免責事項： 本記事は情報提供および教育目的のみを目的としています。金融的または投資的なアドバイスを構成するものではありません。暗号資産投資には元本を失う可能性を含む重大なリスクが伴います。投資判断を下す前に、資格のある財務アドバイザーにご相談ください。

目次

1. Proof of Historyとは？Solanaの暗号時計の解説
2. Proof of Historyの仕組み：SHA-256ハッシュチェーンのステップ解説
3. Proof of Historyが順序付けのオーバーヘッドを削減できる理由
4. Proof of History vs. Proof of Work vs. Proof of Stake：直接比較
5. Proof of HistoryがSolanaの全体アーキテクチャとどのように相互作用するか
6. Proof of Historyの限界と批判：率直な評価
7. Proof of HistoryとSolanaに関するよくある質問
8. 結論：Proof of Historyは真の革新か？

SolanaのProof of Historyとは？

Proof of History (PoH) は、Solanaブロックチェーンに組み込まれた暗号技術によるタイムキーピングメカニズムです。これにより、バリデーター同士がいつ何が起こったかを確立するために絶えず通信し合うことなく、イベントの順序とタイミングの検証可能な記録を作成します。

ブロックチェーンとは、中央の権限なしに参加者のネットワーク全体で記録が暗号的にリンクされ、維持される分散型台帳です。あらゆる分散型ブロックチェーンにおいて、ノードはトランザクションを承認する前に、「何が起きたか」と「いつ起きたか」という2つの事項に合意する必要があります。ほとんどのネットワークは、2番目の問いに対して多大な計算労力を費やします。Proof of Historyはこれを暗号技術で解決するため、ネットワークはそのすべての帯域幅を最初の問いに集中させることができます。

まず明確にすべき重要な違いがあります。それは、Proof of Historyはコンセンスメカニズムではないということです。Solanaの実際のコンセンスメカニズムはTower BFTです。PoHは、Tower BFTが効率的に動作するために依存しているタイムキーピングレイヤーです。この2つを混同することはSolanaの技術解説において最も一般的な誤りであり、本記事では全体を通してこの点を正しています。

Proof of Historyは、Solana Labsの共同創設者であり、以前はQualcommのシニアスタッフエンジニアであったAnatoly Yakovenko氏によって発明されました。彼は2017年のホワイトペーパー『Solana: A new architecture for a high performance blockchain』でこの概念を紹介しました。Solanaのメインネット・ベータは、そのホワイトペーパーに記載されたアーキテクチャに基づいて2020年3月にローンチされました。

Solanaは、ネイティブトークンとしてSOLを持つ高性能なレイヤー1ブロックチェーンです。Proof of Historyが他のいくつかのアーキテクチャ上の革新と連携することで可能になる理論上のスループット上限は、歴史的な理論値で約65,000トランザクション/秒 (TPS) です。一般的なネットワーク条件下での現実世界の持続的なスループットはこれよりも大幅に低く、本記事ではこの相違についても詳しく説明します。

もしProof of Historyが「Proof of Stakeと同じである」と説明されるのを聞いたり、それがSolanaのコンセンスメカニズムであると想定したりしているなら、それらはいずれも誤りです。これらのメカニズムの完全な比較と正確な関係については、以下のセクションで説明します。

Proof of Historyの仕組み：SHA-256ハッシュチェーンのステップ解説

暗号時計という例えはPoHの役割を捉えていますが、なぜ投資家や開発者がこれを真のアーキテクチャ上の革新として扱うのかを理解するには、その時計が実際にどのように動くかを知る必要があります。

暗号学的ハッシュ関数とは？（構成要素）

暗号学的ハッシュ関数は、任意の入力（単語、文書、トランザクション記録など）を受け取り、その入力に対して一意で決定論的な固定長の出力を生成します。また、実質的に逆算は不可能です。つまり、出力が分かっていても、何が入力されたかについて有用な情報は得られません。出力はハッシュと呼ばれ、それを生成したデータに対する固有の指紋のように機能します。

入力の1文字を変更するだけで、出力は完全に、そして予測不能に変化します。この入力に対する感度こそが、逐次的なハッシュ計算をタイムキーピングの信頼できる基盤にしている理由です。

Proof of Historyが使用する特定のハッシュ関数はSHA-256（Secure Hash Algorithm, 256-bit）であり、これはBitcoinのトランザクションを保護しているのと同じアルゴリズムです。SHA-256は実行に多大な計算負荷がかかりますが、検証は極めて高速に行えます。この非対称性が中心的な役割を果たしています。つまり、ハッシュの生成は低速ですが、そのチェックは一瞬です。この特性こそが、SHA-256をPoHのタイムキーピング機能に適したものにしています。

ハッシュチェーン：PoHがいかにして時間を暗号的にエンコードするか

PoHは、SHA-256を途切れることのないシーケンスで実行することで機能し、各出力が次の計算の入力になります。各ステップには、短縮不可能な実際の計算時間が必要であるため、出力の連鎖は経過時間の検証可能な記録となります。実際にステップ1から499,999までを計算することなく、ステップ500,000に到達したと偽ることは誰にもできません。

これを「暗号技術によるストップウォッチ」と考えてください。時計の各刻みは記録されたSHA-256の出力であり、刻みの連鎖は、特定の計算量、したがって測定可能な時間がイベント間で経過したことを証明します。

シーケンスの実行手順は以下の通りです：

1. リーダーバリデーターがチェーンを開始する。 指定されたバリデーター（そのスロットの「リーダー」）が、任意の数値または以前のブロックハッシュである初期入力に対してSHA-256を実行します。
2. 各出力が次の入力になる。 生成されたハッシュは、新しい入力としてSHA-256に戻されます。これがチェーンです。各リンクは完全にその前のリンクに依存します。
3. シーケンスカウンターがポジションを追跡する。 各反復にはカウント番号（ハッシュ#1、ハッシュ#2、ハッシュ#347,891など）が付随します。このカウンターが時計の刻み数となります。
4. トランザクションが到着時にチェーンに組み込まれる。 トランザクションがネットワークに入ると、リーダーはその瞬間にそれをシーケンスへとハッシュ化します。トランザクションのデータは、その特定のカウント位置におけるハッシュ出力に組み込まれます。
5. 組み込まれたポジションがトランザクションのタイミングを証明する。 ポジション347,891でハッシュ化されたトランザクションは、ポジション347,890の後、かつ347,892の前に発生したことが明白に証明されます。外部のタイムスタンプは不要です。チェーンそのものが証明となります。
6. 他のバリデーターがシーケンスを検証する。 ハッシュのチェックは生成にかかる時間の数分の一で済むため、検証は高速です。バリデーターは、すべての計算を再実行することなく、シーケンス全体が有効であることを確認できます。
7. 結果として得られるチェーンは、改ざん防止機能を持つタイムラインとなる。 どの位置のハッシュであっても変更すれば、それに続くすべてのハッシュが無効になるため、その後のすべての作業をやり直さない限り、記録を改ざんすることは不可能です。

写真の例えは、改ざん防止の特性をよく捉えています。毎秒写真を撮り、各写真のフレームの中に前の写真が含まれていると想像してください。1,000枚目の写真を見た人は誰でも、すべての撮影に立ち会っていなくてもその順序を検証できます。なぜなら、各画像が次の画像の中に暗号的に入れ子になっているからです。400枚目の写真を変更すれば、それ以降のすべての画像が目に見えて損なわれることになります。

この逐次的なハッシュチェーンは、暗号学者が検証可能な遅延関数（VDF）と機能的に類似していると呼ぶものです。Boneh、Bonneau、Bünz、Fischが2018年にCRYPTO（IACR ePrint 2018/601）で発表した論文で説明されている、形式的に定義されたVDFは、所定の時間計算に必要であり、その計算を高速化するために並列化できず、高速な検証を可能にする証明を生成する関数です。PoHは、逐次的なSHA-256ハッシュ処理を通じて同じ実質的な効果を達成します。厳密な計算複雑性理論的な意味では正式なVDFではありませんが、機能的な類似性は正確です。PoHを「VDFライク」または「非公式なVDF」と説明する学術研究者は、正確な表現を使用しています。

出典: Anatoly Yakovenko、「Solana: a new architecture for a high performance blockchain」、2017年。solana.com/solana-whitepaper.pdfで入手可能

この暗号学的タイムスタンプチェーンは、Solanaのコンセンサス層であるTower BFTが、時間の証明がすでにされているため、他のブロックチェーンを低速化させる通信ラウンドをスキップすることを可能にします。

Solana Proof of Historyが順序付けのオーバーヘッドを削減できる理由

出典は過去の理論的および観測されたスループット範囲を引用していますが、Proof of History単体ではTPSの数値は生成されません。トランザクションの組み合わせ、投票トラフィック、ランタイムスケジューリング、バリデータハードウェア、ネットワーキング、輻輳、測定方法論など、すべてが報告されるスループットに影響します。運用上の意思決定には、日付の付いたライブ測定値を使用してください。

Visa、Ethereum、またはBitcoinとの比較は同等ではありません。これらは異なるイベントをカウントし、異なる信頼、決済、ファイナリティモデルを使用しています。PoHは、Sealevel、Turbine、Gulf Stream、手数料市場、およびバリデータインフラストラクチャと並んで、Solanaの設計の一部です。

Tower BFTがPoHを使用して通信ラウンドをスキップする方法

PoHによる速度向上は、ハッシュ処理の高速化ではありません。これは、従来のコンセンサスメカニズムが必要とする通信カテゴリ全体を排除することです。

ビザンチン障害（障害のある、または悪意のある参加者）を許容する必要がある分散システムには、ビザンチン耐障害性（BFT）が必要です。これは、バリデーターの3分の1未満が侵害されている限り、一部のバリデーターがオフラインであったり、偽の情報を送信したり、敵対的に動作したりしても、合意に達する能力です。

主要な定義: ビザンチン耐障害性（BFT）とは、一部の参加者が障害を起こしたり、悪意を持って行動したりしても、分散システムが正しく運用を継続できる能力を指します。この概念は、Lamport、Shostak、Pease（1982年）による古典的なコンピューターサイエンスの思考実験であるビザンチン将軍問題に由来しています。

従来のBFTコンセンサスシステムでは、バリデーターはトランザクションを確認する前に、何が起こったか、そしてそれがいつ起こったかという2つのことについて合意するためにメッセージを交換する必要があります。タイミングに関する合意には、通常、ネットワーク全体での複数回のメッセージパッシングが必要です。バリデーターの数が増加するにつれて、この通信オーバーヘッドは二次的に増加し、迅速な合意に達するためにますます高価になります。

PoHは、一部のタイミング調整を削減できる検証可能な順序付け参照を提供します。これはコンセンサスコミュニケーションを排除するわけでも、1つのスロットを経済的ファイナリティと同等にするわけでもありません。楽観的確認、ルート化された確認、およびアプリケーションレベルの決済は、異なるしきい値とタイミングを使用します。

SealevelとGulf Stream: 時計を超えたスピード

PoH単体では65,000 TPSは生成されません。これはSolanaの他のパフォーマンスイノベーションを可能にする基盤レイヤーです。

SealevelはSolanaの並列スマートコントラクト実行ランタイムです。スマートコントラクトはブロックチェーン上に保存され、トランザクションを通じて呼び出されるプログラムです。EthereumのEVMがトランザクションを逐次的に処理するのに対し、Sealevelは複数のプロセッサコアで競合しないトランザクションを実行できます。この並列性は、各トランザクションが読み書きすると宣言するアカウントから生じます。PoHは順序付け参照を提供しますが、どのアカウントが独立しているかは決定しません。

Gulf StreamはSolanaのメンプールレス（mempool-less）トランザクション転送プロトコルです。未確認のトランザクションを待機プールに保持する代わりに、Gulf StreamはPoHのリーダー選出スケジュールを使用して次のリーダーが誰であるかを知り、現在のブロックがファイナライズされる前にトランザクションを次の予想されるバリリーダーに転送します。次に、BitTorrentに触発されたSolanaのブロック伝播プロトコルであるTurbineは、確認されたブロックをより小さなパケットに分割し、バリデータネットワーク全体に効率的に配布します。

PoHは基盤です。SealevelとGulf Streamは直接その上に構築され、Turbineも同様です。65,000 TPSという数値は、これらすべてのイノベーションが連携して動作した結果を反映しており、PoHはそれらすべてが依存する順序付けレイヤーです。

DeFi（分散型取引所やレンディングプロトコルなど）のアプリケーションは、スケーリングのために高いトランザクションスループットを必要とします。SolanaのPoH対応アーキテクチャは、これらのアプリケーションがベースレイヤーで毎秒数千のオペレーションを処理することを可能にし、これはほとんどの現在のレイヤー1ブロックチェーンが達成できない容量ですが、他のチェーンのレイヤー2ソリューションは特定のユースケースでこのギャップを縮小しています。

このアーキテクチャがなぜ重要なのかを理解するには、PoHをそれが連携するように設計されたコンセンサスメカニズムと直接比較すると役立ちます。

Proof of History vs. Proof of Work vs. Proof of Stake: 直接比較

この比較の前に、最も重要な構造的なポイントがあります。Proof of Historyはコンセンサスメカニズムではありません。Proof of WorkとProof of Stakeはコンセンサスメカニズムです。PoHをPoWまたはPoSと直接比較することは、時計と投票システムを比較するようなものです。それらは異なる問題を解決し、その区別がこの表の他のすべてを形作っています。

注: Solanaの理論的TPSは、最適条件でのPoH、Sealevel、Turbine、およびGulf Streamの統合出力を表します。この数値は、本番環境では通常達成されません。

PoH vs. Proof of Work: スピードとエネルギー

BitcoinのProof of WorkとSolanaのProof of Historyは異なる問題に対処していますが、スループットとエネルギーに関する両者の対比は歴然としています。PoWでは、マイナーは計算集約的なパズルを解くために競合します。勝者は次のブロックを追加し、報酬を受け取ります。この競争は意図的にコストがかかるものであり、エネルギー消費こそがチェーンの逆転を法外に高価なものにしているからです。Bitcoinはこの設計の結果として、約7 TPSを処理します。

PoHはPoWのセキュリティモデルを置き換えるものではありません。それは、はるかに少ない計算無駄で、時間順序付けという別の問題を解決します。すべてのマイナーが同時に競合するのではなく、1人のバリデーター（現在のリーダー）だけがPoHシーケンスを生成します。

SHA-256はビットコインのマイニングプロセスでも使用されますが、その応用は根本的に異なります。ビットコインマイナーは、競争的なレースで特定の特性を持つハッシュを探します。SolanaのPoHは、SHA-256をシーケンシャルに実行して時間記録を生成するのであり、何かを競争するものではありません。

PoH vs. プルーフ・オブ・ステーク: 同じものではない

いいえ、プルーフ・オブ・ヒストリーはプルーフ・オブ・ステークと同じではありません。SolanaはPoSの代わりにPoHを使用しているのではありません。PoHとPoSは、異なる目的のために同時に使用されます。

プルーフ・オブ・ステークは、バリデーターが担保としてステーキングした暗号資産の量に基づいてブロックを生成するために選ばれるコンセンサスメカニズムです。イーサリアムは2022年9月のMergeアップグレードでプルーフ・オブ・ステークに移行しました。イーサリアムのPoSは、ベースレイヤーで約15〜30 TPSを処理し、ArbitrumやOptimismのようなレイヤー2ソリューションが、その数値をはるかに超える実効スループットを拡張しています。

Solanaはバリデーター選択のためにPoSベースのシステムを使用しており、これにより特定のタイムスロットでPoHシーケンスを生成する責任者となるリーダーが決まります。PoHは、次にTower BFTがコンセンサスに達するために使用する時間順序を提供します。これら2つのメカニズムは競合するのではなく、補完的です。PoHは時計であり、PoSはその時計のぜんまいを巻く人を決定します。

Proof of HistoryがSolanaの完全なアーキテクチャとどのように連携するか

Solanaをプラットフォームとして評価する開発者にとって、問題となるのはPoHが単独で何をするかだけではありません。それは、2017年のホワイトペーパーでAnatoly Yakovenkoが説明した8つのイノベーションからなる完全なアーキテクチャにPoHがどのように適合し、そのアーキテクチャがそれを実行するハードウェアに何を要求するかということです。

Tower BFT: PoHレコードを投票クロックとして使用する

Tower BFTは、PoHの検証可能な時間レコードを使用して、共有された信頼できるスロットシーケンスなしでは不可能な投票ロックメカニズムを実装します。

実際には、次のように機能します。Solanaのバリデーターは、有効だと信じるブロックに投票します。各投票は特定のPoHスロット番号に関連付けられています。Tower BFTはロックアウト規則を強制します。バリデーターが一度スロットに投票すると、指数関数的に増加する後続のスロット数に対して、競合するフォークへの投票はできなくなります。ロックアウトが長くなるほど、バリデーターはフォークの両側に投票しようとした場合に、ステーキングしたSOLをスラッシングで失うリスクが高まります。

Tower BFTがこれらの時間ベースのロックアウトを強制できるのは、PoHが検証可能で共有されたスロットシーケンスを提供するためです。「スロット347,891がスロット347,892より前に発生した」という信頼できる共通の参照がない場合、時間ベースの投票ロックは機能しません。PoHがその時計です。

リーダーのスケジュールは、ステーキングされたSOLの重み付けを使用して事前に決定されます。バリデーターは、どのノードがPoHストリームを生成し、各今後のスロットのブロックを提案することが期待されているかを知っています。この予測可能性により、現在のブロックが最終決定される前にリーダーを認識した転送が可能になり、グローバルメンプールへの依存が軽減されますが、混雑、トランザクションドロップ、優先手数料、またはMEVリスクが完全に排除されるわけではありません。

Tower BFTにおけるBFTとは、ネットワークが最大3分の1のバリデーターが悪意を持って動作したり失敗したりしても、コンセンサスに達することを許容することを意味します。指数関数的なロックアウト構造により、投票操作によるネットワーク攻撃は、ロックアウト期間が長くなるにつれて幾何級数的に高価になります。

Sealevel: PoHトランザクション順序付けが並列処理をどのように可能にするか

ほとんどのブロックチェーンは、検証済みの順序付けがないと、どのトランザクションを安全に同時に実行できるか判断できないため、トランザクションを一度に1つずつシリアルに処理します。2つのトランザクションが同じアカウント残高の変更を試みた場合、その順序を知らずに並列処理すると、二重支払いの結果につながるリスクがあります。

Sealevelは、PoHの検証済みトランザクションキューを読み取り、各トランザクションの宣言された読み書きアカウントセットを分析することでこれを解決します。すべてのSolanaトランザクションは、読み書きするアカウントを指定する必要があるため、Sealevelは送信時にどのトランザクションが独立しているかを識別できます。独立したトランザクション（完全に異なるアカウントに触れるもの）は、複数のプロセッサコアまたはGPUスレッドで同時に実行できます。相互依存トランザクションは、検証済みのPoH順序でシリアルに実行されます。

PoHの役割は、Sealevelが消費する順序付けされたタイムスタンプ付きトランザクションキューを提供することです。PoHが生成する検証済みの順序付けがない場合、並列実行には競合を防ぐための高価な調整オーバーヘッドが必要になります。Solanaは、ネイティブドキュメントでは、オンチェーンプログラムを「スマートコントラクト」ではなく「プログラム」と呼んでおり、イーサリアムの実行モデルからのアーキテクチャ上の区別を反映していますが、「スマートコントラクト」という用語は業界全体で広く理解され使用されています。

Gulf StreamはPoHのリーダーシップスケジュールを使用して、未確認のトランザクションを次のリーダーバリデーターに直接プッシュし、TurbineはPoH順序付けブロックをBitTorrentスタイルのブロック伝播ツリーの基盤として使用します。Solanaのアーキテクチャにおけるすべての主要なパフォーマンスコンポーネントは、順序付けの基盤としてPoHに依存しています。

このアーキテクチャの密結合は、PoHの最も重大な批判の一部、特にバリデーターにかかるハードウェア要求の源でもあります。

Proof of Historyの制限と批判: 正直な評価

Proof of Historyには実際的なアーキテクチャ上のトレードオフがあり、その中で最も重要なのは、それを実行するバリデーターにかかるハードウェア要求です。

高いバリデーターハードウェア要件と中央集権化の圧力

Solanaバリデーターの実行には、ハイエンドサーバーハードウェアが必要です。高コア数CPU、最低128GBのRAM、NVMe SSD、およびギガビット以上のネットワーク接続が必要です。Solanaのドキュメントでは、組み立ておよび運用に5,000ドルから20,000ドル以上かかるハードウェア仕様を推奨しています。

このコストの障壁は、バリデーターセットへの参加を資金力のあるオペレーターに限定します。ビットコインのフルノードは100ドル未満のRaspberry Piで実行できます。Solanaバリデーターはできません。結果として中央集権化の圧力が生じます。参加コストが高くなるほど、潜在的なバリデーターのプールは小さくなり、ネットワークのコンセンサスパワーは資金力のある機関オペレーターに集中しやすくなります。

ここで正確なフレーミングは中央集権化の圧力であり、完了した中央集権化ではありません。Solanaは、約1,500〜2,000のアクティブなバリデーターを維持しており、これはイーサリアムの数百万人というバリデーターセットよりも少ないですが、イーサリアムの低いハードウェアしきい値には異なる経済的要件（ステーキングに32 ETHが必要）が伴います。Solana Foundationは、小規模なバリデーターをサポートするためにステーキング委任プログラムを実装しましたが、PoHのスループット要求によって駆動される根本的なハードウェア要件は、付随的なものではなく構造的なものです。

このトレードオフは意図的です。Yakovenkoのアーキテクチャは、アクセス可能性よりもスループットを優先し、パフォーマンスのコストとして中央集権化の圧力を受け入れています。そのトレードオフが許容できるかどうかは、評価者が何を最も重視するかによって異なります。

ネットワーク障害: Proof of Historyが原因か？

Proof of History自体は、Solanaの主要なネットワーク障害の原因ではありませんでした。障害は、スパムトランザクションの洪水がネットワークのコンピューティング能力を圧倒したことや、バリデータークライアントソフトウェアのバグに起因していました。

記録されているインシデントは具体的です。2021年9月、Raydiumの初期DEX提供の際にボット生成トランザクションの急増により、Solanaネットワークは17時間の停止を経験しました。スパムトランザクションの量がバリデーターのメモリを圧倒し、バリデーターがクラッシュして、協調的な再起動が組織されるまでネットワークが停止しました。2022年1月と2022年5月に追加のネットワーク障害が発生しましたが、これらはPoHメカニズム自体の失敗ではなく、スパム攻撃とバリデーターソフトウェアバグの組み合わせに起因するものでした。

正直なアーキテクチャ上の関連性はこうです。PoHの設計は、控えめなリソース管理よりもスループットを優先しており、それは、それらの停止期間中にネットワークに組み込みのレート制限や手数料ベースのスパム防止機能がなかったことを意味します。65,000 TPS向けに設計されたネットワークは、悪意のあるトラフィックを含む65,000 TPS相当の受信トラフィックを処理する必要があります。より控えめなアーキテクチャは、スループットを制限することで、攻撃対象領域も制限します。

2022年以降、Solanaはいくつかのエンジニアリング対応を実装しました。より回復力のあるトランザクション取り込みのためのQUICネットワーキングプロトコル、スパムを経済的に高コストにするためのトランザクション手数料市場、そして意味のあるステーキングを持つバリデーターからのトランザクションを優先するためのステーキング加重サービス品質です。これらの対策により、ネットワークの安定性は大幅に向上しました。

停止履歴は、高パフォーマンスシステムにおけるエンジニアリングの未熟さを反映しており、Proof of Historyの概念自体の欠陥ではありません。ただし、両者はアーキテクチャ上関連しています。Solanaを評価する投資家や開発者は、この区別を正確に理解する必要があります。

クロック同期の依存関係

PoHのシーケンシャルハッシュチェーンは、バリデーターが十分に正確なローカルクロックを維持することに依存しています。バリデーター間の大幅なクロックドリフトは、スロットタイミングの不整合を引き起こす可能性があり、バリデーターが特定のスロットハッシュ出力が属するスロットについて合意できなくなります。

実際には、これは標準的なNTP（Network Time Protocol）同期を通じて管理されており、クロックドリフトは実際の障害の有意な原因とはなっていません。これは理論上の攻撃対象領域を表します。意味のある数のバリデーターに到達する時間信号を操作できる洗練された攻撃者は、スロット割り当てを妨害する可能性があります。これは、現在の脅威モデルにおける重大な脆弱性というよりは、設計上の考慮事項として認識されています。

Solana Proof of Historyに関するよくある質問

以下の回答は、Proof of Historyに関する最も一般的な質問に答えるもので、投資家、開発者、研究者、懐疑論者が最も頻繁に尋ねる検索パターンに基づいています。

SolanaにおけるProof of Historyの目的は何ですか？

Proof of Historyは、Solanaのバリデーターが互いにタイムスタンプメッセージを交換することなく、トランザクションの順序とタイミングについて合意することを可能にする暗号化された時間記録を作成します。PoHは「これはいつ起こったのか」という問題を暗号学的に解決することで、Tower BFTが「これは有効か」という問題のみに集中できるようになり、コンセンサスオーバーヘッドを削減し、Solanaの高いトランザクションスループットを可能にします。

Proof of HistoryはProof of Stakeと同じですか？

いいえ。Proof of Historyは時間計測メカニズムであり、Proof of Stakeはブロックを提案するバリデーターを選択するためのコンセンサスメカニズムです。これらは異なる問題を解決します。Solanaは両方を同時に使用します。PoHはトランザクションを順序付ける検証可能な時間シーケンスを提供し、PoSベースのシステムが各スロットのPoHストリームを生成するバリデーターを決定します。Solanaに関する品質の低い報道でこれらを混同するのは一般的ですが、それらはアーキテクチャ上別個のコンポーネントです。

Proof of Historyを発明したのは誰ですか？

Solana Labsの共同創業者兼CEOであるAnatoly Yakovenkoが、2017年のホワイトペーパー「Solana: A new architecture for a high performance blockchain」でProof of Historyを導入しました。Solana Labsを設立する前、YakovenkoはQualcommのシニアスタッフエンジニアであり、分散オペレーティングシステムと圧縮アルゴリズムに取り組んでいました。Solanaのメインネットベータ版は2020年3月にローンチしました。

SolanaはEthereumと比較してどれくらい高速ですか？

Solanaの理論上のスループットは、最適な条件下での過去の理論値で約65,000トランザクション/秒ですが、実際の観測スループットは通常2,000～4,000 TPSの範囲です。Ethereumのベースレイヤーは約15～30 TPSを処理し、レイヤー2ソリューションが実効スループットを大幅に拡張します。Solanaのベースレイヤー速度の利点は、PoHの時間順序付けが並列実行とコンセンサスオーバーヘッドの削減を可能にする構造的なものです。

Proof of Historyの欠点は何ですか？

文書化されている3つの主な制限は以下の通りです。1) 高価なバリデーターハードウェア要件（128GB以上のRAM、NVMe SSD、ギガビット以上のネットワーク、5,000～20,000ドル以上のハードウェアコスト）により、リソースの少ない参加者を排除して中央集権化の圧力を生み出すこと。2) 2021年9月の17時間停止や、スパム攻撃とバリデータークライアントのバグによる2022年の複数回のネットワーク停止を含む、過去のネットワーク信頼性の問題。3) クロック同期の依存関係、つまり大幅なバリデータークロックドリフトが理論上の攻撃対象領域を表しており、実際にはNTP同期で管理されています。

Solanaは毎秒何トランザクションを処理できますか？

Solanaの理論上の最大値は、Yakovenkoの2017年のホワイトペーパーに記載されているように、約65,000トランザクション/秒という過去の理論値です。この数値は、最適なネットワーク条件下でSolanaのすべてのアーキテクチャ上のイノベーションが容量を発揮することを示しています。通常のライブネットワーク条件下での実際の観測スループットは、約2,000～4,000 TPSの範囲です。理論上の天井はアーキテクチャ設計を反映しており、実際の数値は本番環境のパフォーマンスを反映しています。

SolanaのTower BFTとは何ですか？

Tower BFTは、PoHスロットを中心に構築されたSolanaのステーキング加重投票およびフォーク選択メカニズムです。バリデーターはロックアウトを増やしながら投票するため、競合する投票はコストがかかります。1つのターゲットスロットを完全なファイナリティと同一視しないでください。現在のコミットメントレベルとアプリケーション要件を確認してください。

SolanaのProof of Historyは安全ですか？

暗号化メカニズム自体であるSHA-256シーケンシャルハッシュチェーンは安全です。SHA-256は本番環境で一度も破られたことがなく、セキュリティコミュニティによって暗号学的に健全であると考えられています。ネットワークレベルの信頼性、2021年と2022年の停止を含む、は暗号学的なセキュリティとは別の懸念事項です。PoHのハッシュチェーンは、Solanaのネットワーク停止中に侵害されていませんでした。これらのイベントは、暗号化プロトコルの失敗によるものではなく、リソースの枯渇とソフトウェアバグによって引き起こされました。

SolanaはなぜProof of Historyを必要とするのですか？

PoHがない場合、Solanaのバリデーターは、従来のBFTコンセンサスシステムが必要とするように、トランザクションの順序を確立するために、すべてのコンセンサスラウンドの前にタイムスタンプメッセージを交換する必要があります。このメッセージパッシングオーバーヘッドはバリデーターの数とともに増加し、スループットを制限します。PoHは、その通信を暗号化された証明に置き換えます。ハッシュチェーン自体がイベントの順序とタイミングを実証するため、バリデーターはタイミングの交渉を最初に行うのではなく、トランザクションの有効性に関する投票に直接進むことができます。

Proof of Historyは多くのエネルギーを使用しますか？

いいえ。PoHのシーケンシャルSHA-256ハッシュ計算は、各スロットに対して指定された単一のリーダーバリデーターで実行され、競争するマイナーのフィールド全体では実行されません。これは、すべてのマイナーが有効なハッシュを見つけるために同時に計算能力を費やすビットコインのProof of Workマイニングのような、エネルギー集約型ではありません。Solanaの総エネルギー消費量は、ビットコインのほんの一部です。Solanaバリデーターに関連するハードウェアコストは、財務上および分散化上の懸念事項ですが、エネルギー消費の問題とは区別されます。

Solanaはどのブロックチェーンを使用していますか？

Solana自体がレイヤー1ブロックチェーンです。Ethereumレイヤー2ソリューションが行っているように、他のネットワークの上に実行されているわけではありません。Solanaは、トランザクションの時間順序付けにProof of History、コンセンサスにTower BFTを使用し、SOLをネイティブトークンとして、独自の独立したブロックチェーンを運用しています。

他のブロックチェーンはProof of Historyを使用できますか？

Solanaのコードはオープンソースであり、PoHメカニズムは他のプロジェクトが研究および適応できる状態になっています。実際には、PoHはSolanaの完全なアーキテクチャに深く統合されています。Tower BFT、Sealevel、Gulf StreamはすべてPoHシーケンスに依存しています。PoHを別のブロックチェーンに抽出して適用するには、同じパフォーマンス上の利点を達成するために、Solanaの周囲のスタックの多くを再構築する必要があります。

SOL を Bybit で探る

読者は 現在の SOL 市場情報) または SOL/USDT 現物市場.) を確認できます。これらのリンクは市場へのアクセスを提供し、Solana、ウォレット、またはサードパーティ プロトコルがすべての読者に適していることを証明するものではありません。

結論：Proof of History は本物のイノベーションか？

Proof of History は本物の暗号学的イノベーションです。SHA-256 ハッシュ チェーン メカニズムは、分散システムにおける real problem を解決します。それは、単一のクロックを信頼することなく時間の経過を証明することであり、すべてのオブザーバーが検証可能であり、完全な計算を再実行する必要がない方法です。

パフォーマンスへの影響は real です。Solana の他の主要な レイヤー1 ブロックチェーンに対するベースレイヤー スループットの優位性は、付随的なものではなく構造的なものであり、PoH はそれを可能にする基盤となるメカニズムです。その優位性が持続的であるかどうかを評価する投資家は、それと記録されているトレードオフを比較検討する必要があります。すなわち、中央集権化の圧力を生み出すバリデーター ハードウェア要件、深刻な停止を含むネットワーク信頼性の履歴、および保守的な回復力よりもスループットを優先するパフォーマンス最適化設計です。

これらのトレードオフは、暗号学的設計における根本的な欠陥ではなく、エンジニアリング上の課題です。QUIC、料金市場、および ステーキング重み付け品質サービス の 2022 年以降の実装は、Solana エンジニアリング チームが最も急性な信頼性障害に対処したことを示しています。さらなる成熟が、回復力プロファイルをスループットの約束と一致させるかどうかは、ネットワークの進行中の運用履歴が答える質問です。

この記事を読み終えた読者は、Proof of History を正確に定義し、SHA-256 ハッシュ チェーンがどのように検証可能な時間記録を生成するかを説明できるようになります。PoH を Proof of Stake のような コンセンサスメカニズム と区別し、PoH が Solana のスループットの優位性をどのように可能にするかを説明し、適切なコンテキストで記録されている制限を評価できます。それが Solana のアーキテクチャをその merits で評価するために必要な技術的な picture です。

本記事の情報は、公開されている技術文書を反映しており、発行時点のものである。ブロックチェーン プロトコルおよびネットワーク パフォーマンス メトリックは、時間の経過とともに変化します。本コンテンツは、Solana Labs または Solana Foundation と提携または後援されていません。

関連記事

• Solana コンセンサスメカニズム
• Solana アーキテクチャ
• Solana スピード：実際の TPS vs 理論