Proof of History（PoH）

Proof of History（PoH）とは？

Proof of History（PoH）は、ブロックチェーン上のイベントの順序と、イベント間に経過した時間を検証可能な形で記録する暗号学的な時刻管理方式です。

暗号資産の分野では、Proof of HistoryはSolanaの中核技術として知られており、バリデーターがトランザクションの順序により効率的に合意するのを支援します。

Solanaのホワイトペーパーでは、Proof of Historyはイベントの順序とイベント間の経過時間を検証するための証明として説明されています。

PoHは単独のコンセンサスメカニズムだと誤解されることがよくありますが、コンセンサスと連携する暗号学的な時計と捉えるのが適切です。

SolanaはProof of StakeおよびTower BFT型の投票と併せてProof of Historyを使い、バリデーターによるブロック処理、フォークへの投票、台帳の確定を支援しています。

PoHが解決しようとする主な問題は、分散型ネットワークでは、信頼できる共通の時計が自然に共有されないことです。

グローバルなブロックチェーンネットワークでは、遅延、地理的な距離、ハードウェアの違い、ネットワークの混雑により、バリデーターごとにメッセージを受信するタイミングが異なります。

信頼できる順序付けの方法がなければ、どのイベントが先に発生したかに合意するため、バリデーター間の通信頻度が増える可能性があります。

Proof of Historyは、検証可能な時間の連続性を台帳に組み込むことで、その通信負担を軽減します。

PoHを最も簡単に理解するには、通常の時計を信頼しなくてもバリデーターが確認できる、暗号学的な時間軸をブロックチェーンに与えるものと考えるとよいでしょう。

Proof of Historyの仕組み

Proof of Historyは、ハッシュの連鎖を生成する逐次的な暗号処理によって機能します。

各ハッシュは直前のハッシュに依存します。

各ステップが前のステップに依存するため、この一連の処理を一度に並列生成することはできません。

これにより、連続する二つの地点の間に、一定量の逐次計算が行われたことを示す証拠が生まれます。

SolanaのProof of Historyの時計に関する解説では、PoHは時間の経過に伴うカウントと出力を記録する、高頻度のVerifiable Delay Function（検証可能遅延関数）として説明されています。

現在の状態にデータをハッシュ化して組み込むことで、そのデータをシーケンスに追加できます。

データが追加されると、その後に生成されるすべてのハッシュが追加されたデータに依存します。

つまり、そのデータが後続のハッシュ生成より前に存在したことを、シーケンスで示せます。

また、そのデータが先行するハッシュの生成後に追加されたことを証明するのにも役立ちます。

バリデーターは後からシーケンスを検証し、順序が正しいか確認できます。

暗号学的な時計としてのProof of History

Proof of Historyは暗号学的な時計として機能しますが、スマートフォン、ノートパソコン、サーバーの通常の時計とは異なります。

通常の時計は、現実世界での現在時刻を示します。

PoHの時計は、特定の順序で一連の計算ステップが行われたことを証明します。

ブロックチェーンがバリデーターのローカル時刻をそのまま信頼できないため、この違いは重要です。

悪意あるバリデーターや設定に問題のあるバリデーターは、誤ったタイムスタンプを主張する可能性があります。

ネットワークの遅延も、異なるマシン間でタイムスタンプの信頼性を損なう場合があります。

Anzaの同期に関するドキュメントでは、Solanaのリーダーノードが、前回の証明から一定時間が経過したことを示す暗号学的証明を使ってブロックにタイムスタンプを付けると説明されています。

同じドキュメントでは、ブロックが異なる順序で届いた場合や、後から再生された場合でも、バリデーターは証明を検証できると説明されています。

そのため、PoHはローカル時計への信頼ではなく計算に基づく共通の時間構造をバリデーターに提供します。

この仕組みにより、順序に合意するために必要な往復通信が減り、ネットワークの処理速度向上につながります。

Proof of HistoryとVerifiable Delay Function

Verifiable Delay Function（VDF、検証可能遅延関数）は、計算には一定量の逐次処理が必要ですが、計算結果は後から比較的容易に検証できる関数です。

Proof of Historyは、高頻度のVDFに似た処理として説明されることがよくあります。

重要な特性は、実際にシーケンスを実行しない限り、出力を予測できないことです。

各ステップが前の出力に依存するため、処理によって測定可能な遅延が生じます。

この遅延を、ブロックチェーンシステム内で経過した時間の記録として利用できます。

Solanaの設計では、PoH処理が連続的なハッシュシーケンスを使って時間軸を生成します。

バリデーターは後から、シーケンスの各部分を並列に検証できます。

シーケンスの生成は逐次的に行う必要がある一方、検証ははるかに速く行えるため、これは重要です。

この非対称性は、多くの優れた暗号システムに共通しています。

証明の作成は難しく、他の人がその有効性を確認するのはより簡単です。

Proof of HistoryとProof of Workの違い

Proof of HistoryはProof of Workとは異なります。

Proof of Workは、マイナーがハッシュパズルの解決を競い、ブロックを提案するコンセンサスメカニズムです。

Proof of Historyは、イベントが相互にどの順序で発生したかをネットワークが証明するのに役立つ、時刻と順序付けの方法です。

Proof of Workは、セキュリティコストとして計算を利用します。

Proof of Historyは、逐次計算を時間順序の記録として利用します。

Proof of Workでは、多数のマイナーが有効なブロックハッシュを見つけるために競争します。

Proof of Historyでは、リーダーが検証可能なシーケンスを生成し、記録やトランザクションの順序付けを支援します。

PoWチェーンでは、蓄積された作業量を使って有効なチェーンを判断します。

PoHを基盤とする設計では、PoHシーケンスを使って同期、ブロックの構築、バリデーターの投票をより迅速なパイプラインで支援します。

どちらもハッシュを利用しますが、目的は異なります。

PoWは主に経済的セキュリティとブロック生成競争に関するもので、PoHは主に検証可能な時間と順序付けに関するものです。

Proof of HistoryとProof of Stakeの違い

Proof of HistoryはProof of Stakeとも異なります。

Proof of Stakeは、バリデーターがステークをロックし、ブロックの検証、投票、ファイナリティに参加するコンセンサスメカニズムです。

Proof of Historyだけでステーキングの代わりになるわけではありません。

ネットワークに信頼性の高い順序構造を提供することで、バリデーターの処理を支援します。

Solanaは一般に、Proof of Historyを主要な同期・順序付け要素として利用するProof of Stakeブロックチェーンと説明されています。

このモデルでは、ステークがバリデーターの影響力やリーダーのスケジュールに関わり、PoHが記録の時間軸を整理します。

Anzaのリーダー交代に関するドキュメントでは、バリデーターがリーダースケジュールに基づいて次のリーダーを予測し、スロットリーダーが署名していないブロックを拒否すると説明されています。

PoHは、リーダーが割り当てられたスロットで順序付けられた記録を生成するのに役立ちます。

その後、バリデーターはプロトコルのコンセンサスルールに基づいて、記録を検証、再生、投票します。

PoSが経済的セキュリティを提供し、PoHが暗号学的な時間構造を提供します。

Proof of HistoryとSolanaのリーダー

Solanaのリーダーとは、特定の時間スロットで記録を生成するよう割り当てられたバリデーターです。

リーダーはトランザクションを受信し、有効なものを選別して実行し、記録にまとめ、他のバリデーターに配信します。

PoHシーケンスは、これらの記録を正しい順序に整理するのに役立ちます。

リーダーは、イベントが特定の順序で発生したと主張するだけではありません。

他のバリデーターが順序を検証できるよう、イベントをPoHシーケンスに記録します。

バリデーターごとにネットワークパケットの受信時刻が異なる場合があるため、これは重要です。

受信時刻だけに頼るのではなく、バリデーターはリーダーのPoH記録を確認できます。

Anzaのフォーク生成に関するドキュメントでは、ノードが順番にリーダーとなって、状態変更を符号化するPoHを生成すると説明されています。

また、特定のスロットでは一人のリーダーのトランザクションのみが受け入れられると説明されています。

このリーダー型の構造により、Solanaはトランザクションを迅速に処理しながら、生成された履歴をバリデーターが検証できるようにしています。

Proof of Historyとエントリー

Solanaでは、エントリーはバリデーターにストリーミング配信される小規模なトランザクションのまとまりです。

Anzaの同期に関するドキュメントでは、Solanaはブロックをエントリーと呼ばれる小さなまとまりに分割し、ブロックのコンセンサスが完了する前にリアルタイムでバリデーターへ配信できると説明されています。

これは、多くの処理を始める前にバリデーターがブロック全体を待つシステムとは異なる設計です。

バリデーターは、エントリーが届き次第、暫定的に処理できます。

暫定処理とは、最終的なコンセンサスが完了する前に、データの実行と確認を始めることです。

後でコンセンサスによりフォークが拒否された場合、バリデーターは状態をロールバックできます。

エントリーが検証可能な順序に結び付けられるため、PoHによってこの高速なパイプラインが実現します。

バリデーターは、データが時間軸のどこに位置するかをより確信しながら処理できます。

これにより、待機時間が減り、スループットが向上します。

ただし、バリデーターはフォーク、ロールバック、投票、リーダー交代を慎重に処理する必要があり、プロトコルはより複雑になります。

Proof of Historyとスロット

スロットとは、予定されたリーダーがエントリーを生成する時間の単位です。

Solanaのリーダースケジュールでは、バリデーターが事前に各スロットへ割り当てられます。

割り当てられたスロット中、リーダーはPoHストリームを生成し、トランザクションをエントリーにまとめることが期待されます。

Anzaの最新の同期に関するドキュメントによると、現在の実装ではブロック時間を800ミリ秒に設定しています。

リーダーの交代、投票、承認には、ネットワークが予測可能なリズムを持つ必要があるため、スロットのタイミングは重要です。

PoHは、経過したシーケンスステップを暗号学的に記録することで、これらのスロットを機能させます。

リーダーが有効なエントリーを生成できなくても、他のバリデーターはティックやスキップされたスロットを通じて時間経過を記録できます。

そのため、一部のリーダーがオフライン、低速、または切断状態になっても、ネットワークは処理を続けられます。

スロットは、ユーザー向けの速度指標だけではありません。

PoH、リーダー交代、フォーク、バリデーターの投票を結び付ける内部の時間構造の一部です。

Proof of Historyとティック

ティックとは、ユーザーのトランザクションが含まれない場合でも時間が経過したことを示す、空のPoHエントリーです。

ネットワークには、アクティブなトランザクションのまとまりだけでなく、連続した時間の記録が必要なため、ティックは重要です。

Anzaのフォーク生成に関するドキュメントでは、PoHストリームにはリーダーが稼働中であることとクラスター内で時間が経過したことを示すティックが含まれると説明されています。

含めるトランザクションがない場合でも、リーダーはティックを生成できます。

リーダーが不在の場合やデータを配信できない場合、バリデーターはティックのみの経路を使って、想定される時間の経過を記録する場合があります。

これにより、起こり得るフォークを抑え、リーダー交代の構造を保つのに役立ちます。

ティックはPoHシーケンスの心拍のようなものです。

常にユーザーの活動を示すわけではありませんが、ネットワークの進行状況を測るのに役立ちます。

これは投票、ロールバック、再生、同期に役立ちます。

ティックがなければ、台帳は何も起きなかった時間の経過を証明しにくくなります。

Proof of HistoryとTower BFT

Tower BFTは、PoHの時間構造と連携するSolanaの投票ロックアウト方式です。

バリデーターはフォークに投票し、時間の経過とともにフォークを切り替えるコストが高くなる投票タワーを構築します。

AnzaのTower BFTドキュメントでは、バリデーターが署名付き投票を通じて、どのフォークが最も重いと考えるかを伝えると説明されています。

また、ロックアウトはスロットで測定され、バリデーターがフォークに機会費用を伴う形でコミットするよう求めると説明されています。

Tower BFTはスロットに基づく時間管理と構造化された台帳イベントのシーケンスに依存するため、PoHが重要です。

バリデーターは投票を使って特定のフォークへの支持を示します。

投票が蓄積するにつれてロックアウトが増加し、矛盾するフォークへの切り替えが難しくなります。

このプロセスは、ネットワークが一つの承認済み履歴に収束するのに役立ちます。

PoH自体は投票システムではありません。

投票システムが効率的に機能するための時間構造を提供します。

Proof of Historyとフォーク

フォークとは、台帳の異なるバージョンが同時に存在する状態です。

高速なブロックチェーンでは、リーダーがデータを見落としたり、バリデーターごとに情報の受信時刻が異なったり、ネットワークが分断されたりすることで、フォークが発生する場合があります。

Solanaでは、新しく生成されたブロックについてすべてのバリデーターの合意を待ってから次のブロックを生成するわけではありません。

Anzaのフォーク生成に関するドキュメントでは、そのためフォークが頻繁に発生し、クラスターが一つのバージョンを確定するまで、バリデーターが一つのフォークに投票する必要があると説明されています。

各リーダーのエントリーがスロットのタイミングとPoHシーケンスの構造に結び付けられるため、PoHはフォークを整理するのに役立ちます。

バリデーターは各スロットについて、予定されたリーダーからのエントリーを想定します。

誤ったリーダーからのブロックやエントリーは拒否できます。

リーダーがスロットを飛ばしたり、役割を果たせなかったりした場合、ネットワークはスキップされたスロットやティックのみの履歴を通じて処理できます。

これにより、起こり得るフォークの形が限定され、バリデーターが台帳を再生しやすくなります。

PoHはフォークをなくすものではありませんが、フォーク処理をより構造化するのに役立ちます。

Proof of Historyとトランザクションの順序付け

トランザクションの順序付けは、Proof of Historyの最も重要な用途の一つです。

多数のユーザーが同時にトランザクションを送信すると、どのトランザクションが先に発生したか、どの順序で処理するかをネットワークが判断する必要があります。

従来の分散システムでは、順序への合意に何度も通信が必要になる場合があります。

この通信には時間がかかり、スループットが制限される可能性があります。

PoHは、トランザクションを検証可能なシーケンスに配置することで、この問題を軽減します。

トランザクションまたはトランザクションのまとまりがPoHストリームに記録されると、他のエントリーと比べてどこに位置するかをバリデーターが検証できます。

これは、ユーザーが順番を正確に指定できるという意味ではありません。

プロトコルのルールに従って、どの有効なトランザクションを含め、どのようにまとめるかは、依然としてリーダーが決定します。

また、あらゆるMEVや順序付けに関する懸念がなくなるわけでもありません。

PoHは順序の記録を提供しますが、トランザクションの選択や執行の公平性は、より広範なプロトコルやバリデーターの行動にも左右されます。

Proof of Historyとネットワークスループット

Proof of Historyは、連携に伴う遅延を減らして高いスループットを支えるよう設計されています。

バリデーターが検証可能な時間シーケンスをすでに共有していれば、イベントの基本的な順序に合意するための通信を減らせます。

これにより、トランザクション処理、ブロック配信、再生、投票をより積極的にパイプライン化できます。

暗号資産アプリケーションでは、高速かつ低コストの処理が求められることが多いため、高いスループットは重要です。

取引、ゲーム、決済、NFT、DeFi、消費者向けアプリケーションは、承認が遅かったり手数料が高かったりすると、いずれも影響を受ける可能性があります。

PoHは、多くの処理を並列に、または厳密にスケジュールされたパイプラインで実行する設計をSolanaが追求するうえで役立ちます。

ただし、PoHだけでスループットが実現するわけではありません。

実行環境の設計、ネットワーク上での伝播、バリデーターのハードウェア、手数料市場、ソフトウェアの最適化、アカウントへのアクセスパターン、コンセンサスルールにも左右されます。

PoHは、高性能なブロックチェーンアーキテクチャを構成する重要な要素の一つです。

Proof of Historyとバリデーターのハードウェア

PoHはパフォーマンスを高める可能性がありますが、Solanaのバリデーターに要求される高い運用水準にも関係しています。

バリデーターは、大量のデータの処理、エントリーの検証、トランザクションの実行、フォークの管理、投票、同期の維持を行う必要があります。

高性能なチェーンでは、低速なチェーンより高性能なハードウェアやネットワークが必要になることがよくあります。

これにより、速度とバリデーターの参加しやすさとの間にトレードオフが生まれます。

ハードウェア要件が高すぎると、参加できる独立したバリデーターが減る可能性があります。

要件が低すぎると、同等のスループット目標を達成できない場合があります。

PoH自体は時刻管理の仕組みですが、その周辺の設計は高速なパイプラインと高いバリデーター負荷を促します。

そのため、PoHを利用するシステムを評価する際は、発表されている速度だけでなく、他の点も確認してください。

バリデーターの分布、ハードウェア要件、クライアントの多様性、ホスティングの集中度、ネットワークの信頼性も調べましょう。

独立した多数のバリデーターが現実的に運用・検証できる場合、高速なブロックチェーンはより強固になります。

Proof of Historyとファイナリティ

ファイナリティとは、ネットワークのルールに基づいてトランザクションが確定したと認められることです。

PoHは高速な処理に役立ちますが、ファイナリティは依然としてバリデーターの投票とコンセンサスルールに依存します。

Solanaでは、バリデーターがフォークに投票し、コンセンサスプロセスを通じてクラスターが一つの履歴を確定します。

Neodymeのコンセンサス分析では、SolanaはProof of Stakeブロックチェーンであり、各スロットに指定されたリーダーが選ばれ、ファイナリティはステークの重みを反映したバリデーター投票によって決まると説明されています。

PoHだけでトランザクションが確定すると考えてはいけません。

PoHはイベントの順序を確立するのに役立ち、バリデーターの投票はどのフォークが承認されるかを決定します。

この違いは、入金、出金、取引システム、ブリッジ、確かな決済処理を必要とするアプリケーションにとって重要です。

トランザクションはすぐに表示されても、アプリケーションによって確認に使う基準は異なる場合があります。

高額の送金では、ユーザーと開発者はコミットメントレベルとファイナリティの前提を理解する必要があります。

迅速な順序付けは、絶対的に即時のファイナリティと同じではありません。

Proof of Historyとセキュリティ

Proof of Historyは、イベントの順序を検証可能にし、事後に改ざんすることを困難にすることで、セキュリティを高めます。

シーケンスが逐次的なハッシュ計算に依存するため、攻撃者が後続の出力に影響を与えずにイベントの順序を自由に変更することはできません。

これにより、台帳の時間軸の完全性が保護されます。

ただし、PoHだけで完全なセキュリティモデルが実現するわけではありません。

ネットワークには、ステークの重みを反映したバリデーター、リーダーのスケジュール、投票、フォーク選択ルール、スラッシングまたはペナルティの前提、ソフトウェアの正確性、誠実な参加も必要です。

バリデーターソフトウェア、ネットワーク運用、ガバナンス、トランザクション実行の弱点をPoHだけで解決することはできません。

PoHは台帳内の順序と経過時間を証明しますが、すべてのアプリケーションが安全であることを証明するわけではありません。

PoHを利用するチェーンでも、悪意あるスマートコントラクト、フィッシングトランザクション、詐欺トークン、侵害されたウォレットによってユーザーが損害を受ける可能性があります。

暗号資産のセキュリティは、常に複数のレイヤーで成り立ちます。

Proof of HistoryはSolanaの広範なアーキテクチャを構成する一つのレイヤーです。

Proof of Historyと分散化

Proof of Historyは、時間と順序についてバリデーターが合意するための通信量を減らし、分散化を支援する可能性があります。

通信の負担が減れば、世界中に分散した多数のバリデーターがより効率的にデータを処理できる場合があります。

ただし、PoHだけで分散化が保証されるわけではありません。

分散化は、独立したバリデーター数、ステークの分布、リーダースケジュールの仕組み、バリデーターソフトウェアの運用しやすさ、インフラの集中度に左右されます。

検証に多額のコストがかかったり、少数のグループがステークの大部分を管理していたりすると、高速なネットワークでも分散化が懸念される可能性があります。

巧妙な時計を備えたネットワークでも、アップグレードやセキュリティ上の判断には、社会的・経済的な協調が必要です。

PoHは技術的な設計上の選択肢であり、ネットワーク全体が分散化されている証明ではありません。

適切な分散化分析では、ステークの集中度、バリデーター数、クライアントの多様性、地理的な分布、ホスティング、ガバナンス、検閲耐性を調べる必要があります。

PoHはシステムのスケーリングに役立つ可能性がありますが、分散化はエコシステム全体に依存します。

Proof of Historyのメリット

Proof of Historyの第一のメリットは、検証可能な時間順序です。

通常のタイムスタンプを信頼せずに、イベントの順序をバリデーターが確認できます。

第二のメリットは、連携に必要な負担が減ることです。

時間について常に通信しなくても、バリデーターは順序付けられたエントリーを処理できます。

第三のメリットは、トランザクション処理の高速化です。

検証可能なシーケンスは、パイプライン処理、暫定処理、迅速な投票を支援します。

第四のメリットは、再生と監査可能性の向上です。

バリデーターは台帳を再生し、PoHシーケンスを検証してイベントの順序が正しいことを確認できます。

第五のメリットは、高スループットを必要とするアプリケーションの支援です。

迅速な順序付けは、DeFi、決済、ゲーム、NFT、消費者向け暗号資産アプリケーションの応答性向上に役立つ可能性があります。

第六のメリットは、リーダースケジュールがより明確になることです。

PoHは、スロット、リーダー、ティックと連携し、ブロック生成を構造化します。

第七のメリットは、分散型システムに強固な内部時計をもたらすことです。

この時計は、単一の時刻サーバーへの信頼ではなく、暗号学的な計算に基づいています。

Proof of Historyの課題

第一の課題は、PoHが単独のコンセンサスメカニズムではないことです。

バリデーター投票、ステークの重み付け、フォーク選択、ファイナリティのルールと連携する必要があります。

第二の課題は複雑さです。

PoHを基盤とするシステムは、よりシンプルなブロック生成方式より、ユーザーや開発者にとって理解しにくい場合があります。

第三の課題は、ハードウェアへの負荷です。

高性能な設計では、バリデーターに求められる資源が増える可能性があります。

第四の課題は、PoHがあらゆる種類の攻撃を防ぐわけではないことです。

PoHは順序付けと時間の検証に役立ちますが、フィッシング、悪意あるアプリケーション、秘密鍵の窃取、安全でないスマートコントラクトを防ぐものではありません。

第五の課題は、各スロットにおけるリーダーへの依存です。

予定されたリーダーの処理に問題がある場合や、データを配信できない場合、ネットワークはスロットのスキップ、フォーク、復旧経路に対処する必要があります。

第六の課題は、速度が運用上の問題を生む可能性があることです。

高速なネットワークでは、ソフトウェアのバグ、ネットワークの混雑、スパム、バリデーターの同期に慎重に対処する必要があります。

第七の課題は、ユーザーの誤解です。

「Proof of History」という名前からPoWやPoSと同じ仕組みだと思われることがありますが、実際には異なる種類の暗号学的要素です。

Proof of Historyとスマートコントラクト

PoHに対応するブロックチェーン上のスマートコントラクトも、トランザクションの順序付けや状態更新について基盤となるチェーンに依存します。

PoHは、台帳の時間軸上でトランザクションがどこに位置するかを決めるのに役立ちます。

その後、実行環境がスマートコントラクトのルールに従ってトランザクションを処理します。

つまり、PoHはスマートコントラクトのやり取りを順序付け、処理する速度を高める可能性があります。

ただし、PoHによってスマートコントラクトが自動的に安全になるわけではありません。

スマートコントラクトには、バグ、安全でない権限、設計上の経済的な問題、悪意ある命令が含まれる可能性があります。

ユーザーはコントラクトアドレス、トークンプログラム、ウォレットの確認画面、承認内容、公式ドキュメントを引き続き確認してください。

開発者もプログラムを監査し、境界事例をテストし、アップグレードを慎重に管理し、管理者鍵を保護する必要があります。

PoHは基盤チェーンの時間構造を改善しますが、アプリケーションレベルのセキュリティは別途対応が必要です。

迅速な実行は優れたアプリケーションの改善に役立つ一方、詐欺も迅速に進行する可能性があります。

Proof of HistoryとMEV

MEVとはMaximal Extractable Value（最大抽出可能価値）のことで、トランザクションの順序付け、取り込み、除外によって獲得できる価値を指します。

PoHはイベントの高速かつ検証可能な順序を作るのに役立つため、トランザクションがネットワークを通過する方法に直接関係します。

PoHは事後に順序をより透明にできますが、あらゆる順序決定権をなくすわけではありません。

各スロット中にどのトランザクションを取り込むかについて、リーダーは依然として影響力を持ちます。

ネットワークの経路、優先手数料、スパム、遅延、バリデーターの行動は、いずれもトランザクションの実行に影響します。

トレーダーやDeFiユーザーにとって、執行品質全体は基盤プロトコルの時間設計だけでは決まりません。

スリッページ、優先手数料、失敗したトランザクション、ルーティングの品質、流動性、敵対的な行動の可能性も考慮してください。

開発者は、高速な順序付け、競合状態、トランザクションの集中に耐えられるアプリケーションを設計する必要があります。

PoHは強力な順序付けツールですが、公平な執行を実現するには、エコシステム全体での対応が必要です。

暗号学的な時計があっても、MEVを考慮した設計は欠かせません。

Proof of Historyに関するよくある誤解

よくある誤解の一つは、Proof of HistoryがProof of Stakeと同じだというものです。

Proof of Stakeは経済的なコンセンサスモデルであり、Proof of Historyは暗号学的な時刻管理と順序付けのシステムです。

もう一つの誤解は、Proof of Historyがバリデーターに取って代わるというものです。

トランザクションの検証、フォークへの投票、コンセンサスソフトウェアの実行、ネットワークの維持には、引き続きバリデーターが必要です。

PoHが現実世界の正確な時刻を証明するという誤解もあります。

PoHが証明するのは、台帳内での相対的な順序と計算上の時間経過であり、現実世界の特定の時刻にイベントが発生したことではありません。

PoHがフォークを不可能にするという誤解もあります。

フォークは依然として発生する可能性がありますが、PoHはエントリー、スロット、ティック、リーダーの出力の処理を構造化するのに役立ちます。

PoHだけでトランザクションが確定するという誤解もあります。

ファイナリティは引き続きバリデーターの投票、ステークの重みを反映したコンセンサス、フォーク選択ルールに依存します。

ユーザー向けのベストプラクティス

PoHはネットワーク設計上の機能であり、個人のウォレットを保護する機能ではないと理解してください。

シードフレーズ、秘密鍵、ハードウェアウォレットは引き続き慎重に保護しましょう。

承認が速いからといって、すべてのトランザクションがリスクフリーになるわけではありません。

高速なチェーンでは誤操作もすぐに実行される可能性があるため、署名する前にトランザクションの詳細を確認してください。

オンチェーンプログラムを利用する前に、アプリケーションの公式リンクとトークンアドレスを確認しましょう。

アプリケーションを通じて入金または出金する際は、コミットメントレベルを理解してください。

PoHは詐欺、フィッシング、偽トークン、悪意あるプログラムを防ぐものではありません。

混雑や通常と異なる動きが見られる場合は、ネットワークの稼働状況に関する更新を確認してください。

新しいアドレスやプログラムに資金を送る際は、少額のテスト送金を行いましょう。

PoHはパフォーマンスと順序付けの機能であり、投資の安全性を保証するものではありません。

開発者向けのベストプラクティス

スロット、リーダー、エントリー、ティック、フォークがアプリケーションの動作にどのように影響するか理解してください。

トランザクションの順序付け、アカウントのロック、再生、障害時の処理を慎重に考慮したプログラムを設計しましょう。

処理が速いからといって、入念なテストが不要になるとは考えないでください。

優先手数料、トランザクションの競合、遅延がユーザー体験に与える影響を監視しましょう。

トランザクションが迅速に到着したり、競合する順序で処理されたりしても安全なアプリケーションを設計してください。

入金、出金、ミント、強制決済、決済処理に関する確認の前提を文書化しましょう。

チェーンの処理が速いという理由だけで、機密性の高い非公開データをオンチェーンに保存しないでください。

プログラムを監査し、アップグレード権限を慎重に管理し、実行環境の変更を監視しましょう。

ユーザーが何に署名するのか正確に分かる、明確なウォレットの確認画面を作成してください。

PoHは高速なアプリケーションを支援できますが、安全なアプリケーションロジックを実現する責任は開発者にあります。

FAQ

Proof of Historyとはどういう意味ですか？

Proof of Historyとは、ブロックチェーンが暗号学的なシーケンスを使い、イベント間の順序と時間の経過を証明する仕組みです。

Proof of Historyはコンセンサスメカニズムですか？

Proof of Historyは通常、単独の完全なコンセンサスメカニズムとはみなされません。バリデーターの投票やProof of Stake型のコンセンサスと連携するためです。

Proof of Historyで知られるブロックチェーンはどれですか？

Proof of Historyと最も強く結び付けられているブロックチェーンはSolanaです。

Proof of Historyが重要なのはなぜですか？

Proof of Historyは検証可能な時間軸をバリデーターに提供し、通信の負担を減らしてトランザクション処理を高速化する可能性があるため重要です。

Proof of Historyはどのようにトランザクションを順序付けますか？

先行する入力に後続の出力が依存する逐次的なハッシュストリームにデータを挿入することで、トランザクションを順序付けます。

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

いいえ。Proof of Workはマイニング競争をコンセンサスに利用し、Proof of Historyは検証可能な時間と順序のシーケンスを作成します。

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

いいえ。Proof of Stakeはステーキングされた資産とバリデーターをコンセンサスに利用し、Proof of Historyは順序付けと同期を支援する暗号学的な時計を提供します。

PoHのティックとは何ですか？

PoHのティックとは、PoHストリームでリーダーの稼働状況と時間の経過を示す空のエントリーです。

Solanaのリーダーとは何ですか？

Solanaのリーダーとは、特定のスロットでエントリーを生成し、PoHシーケンスに記録するよう予定されたバリデーターです。

PoHはフォークを防ぎますか？

いいえ。PoHはあらゆるフォークを防ぐものではありませんが、フォークの生成、再生、バリデーターの投票を構造化するのに役立ちます。

PoHによってトランザクションは即時に確定しますか？

いいえ。PoHは迅速な順序付けに役立ちますが、ファイナリティは引き続きバリデーターの投票とコンセンサスルールに依存します。

PoHはユーザーを詐欺から守りますか？

いいえ。PoHは時刻管理と順序付けの仕組みです。ユーザーは引き続きウォレットのセキュリティ、トランザクションの確認、アプリケーションの慎重な調査を行う必要があります。

まとめ

Proof of History（PoH）は、イベント間の順序と経過時間をブロックチェーンが証明するのに役立つ暗号学的な時刻管理方式です。

PoHはSolanaのアーキテクチャの中核要素として知られており、Proof of Stake、リーダースケジュール、エントリー、ティック、フォーク、Tower BFT型のバリデーター投票と連携します。

PoHはProof of WorkともProof of Stakeとも異なります。

これは暗号学的な時計であり、通信の負担を減らしながら、バリデーターがイベントの順序に合意するのを支援します。

これにより、トランザクション処理の高速化、高いスループット、暫定的な実行、効率的な再生、より構造化されたリーダーパイプラインが実現する可能性があります。

一方、PoHだけですべてのブロックチェーンの問題が解決するわけではありません。

バリデーター、ステークの重みを反映したコンセンサス、ファイナリティのルール、フォーク選択、安全なソフトウェア、適切なガバナンス、安全なスマートコントラクトが引き続き必要です。

また、フィッシング、秘密鍵の窃取、悪意あるプログラム、不適切な投資判断からユーザーを保護するものでもありません。

Proof of Historyの主な価値は、中央集権型の時計に頼らず、分散型ネットワークに検証可能な時間軸を与えることです。

PoHを最も簡単に理解するには、時間を暗号学的な記録に変換し、イベントが相互にいつ発生したかをバリデーターが確認できるようにして、ブロックチェーン上の処理をより効率化する仕組みと考えるとよいでしょう。