本文へ移動
Financial Context Wiki

履歴の証明: 記録された順序、ティック、スロット、およびコンセンサス境界

Proof of History は、Solana のシーケンシャル ハッシュ チェーン クロックです。プロデューサーの記録された順序と計算カウントを検証可能にしますが、実時間、公正なトランザクションの到着順序、フォークの選択やファイナリティを独立して証明するものではありません。

更新日

プロトコル分析の教育目的に限られ、投資、バリデーター運用、性能、セキュリティに関する助言ではありません。Proof of History のパラメーター、クライアントの動作、リーダーのスケジュール、投票、フォーク選択、確認規則は、ネットワークやソフトウェアのバージョンによって変わる可能性があります。

直接の答え

Proof of History (PoH) は、Solana の暗号化時計および台帳順序データ構造です。プロデューサは、各出力が前の出力に依存するようにハッシュ関数を繰り返し適用し、カウントと状態を定期的に記録し、トランザクション由来のデータをチェーンに混合します。検証者はこれらの遷移を再計算し、その特定のチェーンによって記録された順序を確認できます。

PoH はスタンドアロンのコンセンサス アルゴリズムではありません。正規のフォークを選択したり、ステーク重視の合意を提供したり、ブロックを完了したり、トランザクションが特定の時刻にネットワークに到達したことを証明したりすることはありません。 Solana は、スケジュールされたリーダー、トランザクションの実行、バリデーターの投票、フォークの選択、および Tower BFT スタイルのロックアウトとクロックを組み合わせます。 2 つのフォークにはそれぞれ、内部的に有効な PoH シーケンスを含めることができます。コンセンサス ルールにより、ネットワークがどの履歴に従うかが決まります。

この保証の範囲は限定的です。エントリが状態 h2 の後でデータ d をコミットしたなら、そのコミットなしに後続状態 h3 = H(h2 || d) は計算できません。これは生成者が h3 の計算前に d を知っていたことと、後続出力に対する記録位置を示します。各バリデーターの受信時刻、リーダーが到着順に採用したか、d が実世界の事実を表すか、そのエントリが正規履歴になったかは証明しません。

前のハッシュが存在するまで次の入力がわからないため、生成は順次行われます。公開された境界状態により、検証者は個別の境界セグメントを並行して再生できますが、集計ハッシュ作業は残ります。そのため、PoH は検証可能な遅延関数と比較されることがよくありますが、Solana 自身の Tower BFT の説明では、この用語の大雑把な使用とされています。正式な VDF には通常、評価および検証インターフェイスがあり、その検証は逐次評価に比べて効率的です。

Proof of Historyの分析方法

  1. ネットワークとソフトウェアの前提を固定します。 ネットワーク、ジェネシスハッシュ、スロット、エポック、Agave または別クライアントのバージョン、観測時刻を記録します。hashes_per_tick、ticks_per_slot、ns_per_slot の実効値を読み取り、古い記事や別クラスターの定数を流用しないでください。
  2. ハッシュ チェーンを再構築します。 信頼できる先行状態から開始し、各エントリの num_hashes、結果のハッシュおよびトランザクション リストを検証します。 Agave のエントリの実装では、エントリ識別子は前のエントリに依存し、トランザクションが存在する場合はその署名から導出されたハッシュに依存します。
  3. ティックとスロットの配置を検証します。 ティック エントリ、予想されるハッシュ カウント、ティックの高さ、および最大ティックの高さをバンクとレコーダーのルールに照らしてチェックします。レコーダーは、設定された ticks_per_slot を使用して、ティックの高さをスロットにマップします。スロットはプロトコル間隔であり、外部クロックからの独立した証拠ではありません。
  4. 包含と到着を区別します。 コミットメントは、入力がそのシーケンスへの挿入までに知られていたことを証明します。下限を要求するには、以前の PoH 状態への署名付き後方参照を特定します。どちらの境界も、グローバルな先見順序、メモリプールの公平性、または信頼できる UTC タイムスタンプを証明するものではありません。
  5. 生成と検証を分離します。 1 つの依存関係チェーンで順次プロダクションを測定し、認証されたセグメント境界と使用可能なコアを使用してリプレイを測定します。単に検証が「速い」と言うのではなく、総ハッシュ、クリティカル パスのレイテンシ、検証者の作業の集計、および境界データの仮定を報告します。
  6. コンセンサスパスを追跡します。 スケジュールされたリーダー、銀行の状態、投票、ロックアウト、フォーク選択ルール、ルートまたは確定された状態、およびコミットメント レベルを特定します。有効な PoH チェーンは負けたフォークに属している可能性があり、長く見えるカウンターだけではコンセンサス証明書ではありません。
  7. ストレス敵対的および運用上のケース。 テスト リーダーの曖昧さ、トランザクションの省略と並べ替え、スキップされたスロット、パーティション、高速または誤って調整されたハードウェア、無効なティック カウント、遅延リプレイ、台帳の利用不能、クライアントの相違、および関連するオペレーターまたはインフラストラクチャの制御。

レビュー出力では、シーケンスの有効性、設定されたプロトコル時間、コンセンサスステータス、外部時間の 4 つの主張を区別する必要があります。どの開始ハッシュおよび台帳データが信頼されたか、どのハッシュが再計算されたか、どの投票またはコミットメントの証拠がチェックされたか、どの観測結果がローカル時計またはサードパーティのサービスから得られたかを述べます。

作業例

1. データ挿入により記録位置が固定されます

h1 = H(h0)、次に h2 = H(h1) を検討します。プロデューサは、トランザクション由来のコミットメント d を挿入し、h3 = H(h2 || d) に続いて h4 = H(h3) を計算します。同じ操作を再実行すると、記録されたチェーンが h2 と h3 の間で d をコミットし、h4 が結果に依存していることを確認できます。

上限ステートメントは狭いです。プロデューサーは、h3 を計算する前に、d を知っていました。署名されたトランザクション自体が h1 を参照している場合、検証者は、署名と来歴のチェックを条件として、その以前の状態を知った後にそれが形成されたことを示すこともできます。このような後方参照がなければ、PoH だけでは下限が提供されません。どちらの場合も、別のノードが最初にトランザクションをいつ受信したかは証明されません。

2. セグメントの再生により、集約作業ではなくレイテンシが削減されます

記録された間隔に 1,000,000 個のハッシュが含まれており、認証されたチェックポイントがそれを 100,000 個のハッシュの 10 個のセグメントに分割するとします。十分なコアがあれば、10 個のセグメントを同時に再生できるため、実時間検証の遅延は 1 セグメントの継続時間にオーバーヘッドを加えた値に近づく可能性があります。

検証者は依然として合計 1,000,000 個のハッシュを実行しています。チェックポイントは独立した開始状態を公開しますが、チェーンを簡潔な証明には変換しません。パフォーマンスは、ハードウェア、スケジューリング、メモリの移動、および境界の信頼性に依存します。これが、並列 PoH リプレイがすべての正式な VDF 構築の効率的な検証アルゴリズムとして自動的に記述されるべきではない理由です。

3. ティックとスロットの演算は構成に依存します

hashes_per_tick = 100,000 および ticks_per_slot = 8 を使用した構成例を想定します。完全にハッシュされたスロットには、構成された各間隔の後にティック境界を持つ 100,000 * 8 = 800,000 ハッシュが含まれます。いずれかのパラメータを変更すると、マッピングが変更されます。この例は現在のメインネット定数ではありません。

Agave は、ハッシュ カウントの動作がこの単純化された乗算ではなく構成によって表されるプロトコルのケースもサポートします。レビュー担当者は銀行の実際のフィールドを取得し、クライアントのルールに照らしてエントリを検証する必要があります。スロットまたはカウントを秒に変換するには、暗号検証だけでなく、ターゲット期間の調整と実行の観察にも依存します。

4. 記録された順序は到着順またはファイナリティではありません

トランザクション A がトランザクション B よりも前にリーダーに到達したが、リーダーは B を 300,000 カウント近く、A を 450,000 カウント近く記録したとします。有効な PoH は、生成されたシーケンス内で B が A より前にあることを証明します。 B が最初に到着したこと、順序が公平であったこと、または別のリーダーが同じ順序を遵守したことを証明するものではありません。

ここで、パーティションがフォーク X とフォーク Y を生成し、それぞれが有効なシーケンスを持つと仮定します。 PoH 検証では、どちらのフォークでも不正なエントリを拒否できますが、X または Y は選択されません。リーダーのスケジュール、ステーク加重投票、ロックアウト、フォークの選択、および要求されたコミットメント レベルによってコンセンサス結果が決まります。アプリケーションは、確認またはファイナリティ証拠として PoH カウントを置き換えてはなりません。

リスクとレビューの失敗

暗号エラーとタイミングエラー

  • PoH を信頼できる壁時計と呼ぶか、ハッシュ カウントを独自に主張することで、UTC タイムスタンプが証明されます。
  • トランザクションを含めると、ネットワーク全体の受信時間、外部データの最初に見た順序、または真実性が証明されます。
  • 順次生成により、プロデューサーが既知のデータを差し控えたり、省略したり、挿入するタイミングを選択したりすることが防止されると仮定します。
  • 衝突耐性だけを、ハードウェア速度、キャリブレーションドリフト、または実装の差異に対する完全な限界として扱います。
  • 並列セグメントの再生をゼロ作業として、または集約ハッシュをカウントせずに簡潔な証明として説明します。
  • 比較される構造、証明インターフェイス、および検証の仮定を示さずに、PoH を正式な VDF と呼びます。
  • チェックポイント境界、先行ハッシュ、またはダウンロードされた台帳セグメントの出所を認証せずに信頼する。

コンセンサスエラーとプロトコルエラー

  • PoH コンセンサス、プルーフ オブ ステーク、Tower BFT、リーダー選出、フォーク選択、およびファイナリティを同じメカニズムと呼びます。
  • 投票とフォーク選択の状態を調べずに、最大カウントを持つ有効なシーケンスが正規である必要があると仮定します。
  • 要求されたコミットメント セマンティクスをチェックせずに、ローカルで再生されたエントリを確認済み、ルート化済み、またはファイナライズ済みとして扱うこと。
  • 過去の hashes_per_tick、ticks_per_slot、スロット期間を現在も普遍的に有効な定数として扱うこと。
  • 順序を再構築するときに、スキップされたスロット、リーダーの回転、パーティション、あいまいさ、およびクライアントのバージョンの違いを無視します。
  • 無関係なフォークまたは開始状態からのカウントを、それらが 1 つの認証されたシーケンスに属しているかのように比較します。
  • トランザクションの最近のブロックハッシュが、プロトコルの有効性コンテキストではなく、単なる実測のタイムスタンプであると仮定します。

操作、性能および制御エラー

  • 実行、署名検証、再生、帯域幅、ストレージを無視して、ハッシュ生成のみをベンチマークします。
  • 理論上のセグメント並列性と、CPU、I/O、およびメモリ競合で観察されたバリデーターのキャッチアップを同等にします。
  • ティック検証の失敗、レコーダーの停止、銀行業務の遅延、元帳のギャップ、スナップショットの信頼性、および破損した状態を無視します。
  • クライアント、ホスティング、ネットワーキング、リーダー インフラストラクチャ、またはコントロールが共有されている場合、バリデーター ID を独立したものとしてカウントします。
  • より高速なハードウェアにより、ネットワーク遅延、パケット損失、検閲、サービス拒否、またはステーク集中のリスクが排除されると仮定します。
  • サービス レベルの保証として、ターゲット スロット期間、スループット推定値、または古いベンチマークを提示します。

よくある誤解

  • PoH は、Solana の完全なコンセンサス アルゴリズムです。 PoH は検証可能な記録シーケンスを提供します。バリデーターの投票、ロックアウト、フォークの選択、その他のコンセンサス ルールによって、ネットワークがたどる履歴が決まります。
  • PoH は、すべてのトランザクションの正確な現実時間を証明します。 認証されたシーケンス内の依存関係とカウントを証明します。そのシーケンスを常用時間にマッピングするには、設定と外部観察が必要です。
  • PoH は公正なトランザクション順序を保証します。 リーダーはプロトコルとリソースの制約内で入力を選択、遅延、並べ替え、または省略できます。PoH が監査可能にするのは、結果として記録された順序です。
  • PoH は、別名を持つ Proof-of-Work マイニングです。 どちらもハッシュを使用しますが、PoH の中心的な役割はシーケンシャル クロックであり、勝利作品がチェーンを選択するオープン パラレル レースではありません。
  • 有効な PoH シーケンスが最終的です。 競合するフォークはそれぞれ内部的に有効である可能性があります。確認と最終決定には、ネットワークの合意証拠が必要です。

関連トピック

情報源

ナビゲーション

Wiki を検索...