０　はじめに

この記事は、下の動画を元にして、PoHが具体的にブロックの生成にどのように関わるかを説明しています。

元の動画もとてもわかりやすいので、よかったら見てみてください。

１　Solanaの概要について

１　PoHではなく、PoS

まず、Solanaは現在のイーサリアムと同じく、PoS（Proof of Stake）を採用しています。

一定量のSolanaを預けた人がバリデータとなり、ブロックの生成を行います。

PoHはPoSを支える技術であり、コンセンサスアルゴリズムは「PoS」です。

２　スラッシュについて

PoSなので、バリデータが怪しい行動をした時は、預けたSOLは没収されます。

これは「スラッシュ」と呼ばれます。

イーサリアムなどでも同じで、これがあることで、不正行為の抑制を行なっています。

３　リーダーについて

各スロット（一定の期間）ごとに、ブロックを生成するバリデータが選出されます。

下の場合、右にいた人が、「SLOT1」の生成に選ばれました。

この、ブロックを生成する人をリーダーと呼びます。

４　リーダーに選ばれる確率について

リーダーに選ばれる確率は、預けたステーク量に応じて、ランダムに決定されます。

５　リーダースケジュールについて

どのスロットにどのリーダーがついているかは「リーダーズ　スケジュール」を見ることで確認ができます。

これによって、他のバリデータは、どのスロットで誰がリーダーなのかを把握できます。

（一部、誤字だと思うので、修正しました。）

２　スロットの問題点について

ここで問題になるのが、それぞれのバリデータの時間感覚の違いです。

１　概要

例えば、「SLOT2」のリーダーが「No.7」の人だと分かっても、「SLOT2」になるタイミングを全てのバリデータが一致させるのは困難です。

ちなみに、多くのブロックチェーンでは、これを合わせるために、「同期」が行われ、それにより時間がかかります。

２　リーダーのタイミングの困難さ

仮にこのように、「１スロット」が0.5秒の時、この「リーダー３」がいつ自分の番になるのかを正確に知るのは難しいです。

３　ブロックが２つ作られた時の判別の困難さ

他にも、「リーダー２」が２つのブロックを作った時、どちらが正しいかを判断する必要があります。

これにより、ネットワークが遅くなってしまいます。

３　PoH（Proof of History）について

１　概要

PoHは上の問題を解決します。

PoHは「時間」という概念（何秒過ぎたか）を使わずに、物事の順番を確定させる技術です。

例えばこれにより、リーダーはいつ自分の番になったのかを確定的に判断できます。

２　コンセンサスアルゴリズムではない

また、名前が似ているので混同しがちですが、PoHは物事の順番を確定させる技術です。

Solanaの場合、あくまでもコンセンサスアルゴリズムは「PoS」です。

３　リーダーにとっての利点

PoHによって、リーダーは、いつブロックを生成するのかを判断することができます。

４　バリデータにとっての利点

PoHによって、バリデータは、リーダーが正しく順番を交代することを検証することができます。

「時間」の概念を使わずに、「リーダーズ スケジュール」に沿って、リーダーが交代していくことを検証できます。

４　ハッシュ関数について

１　Solanaで用いるハッシュ関数について

Solanaでは、「SHA-256」というハッシュ関数が使われます。

２　ハッシュ関数の特徴

ハッシュ関数は、同じ入力値からは、同じ出力が得られます。

また、少しでも入力値が異なる場合、出力が全く異なります。

また、少しでも入力値を変えると出力値が全く異なるので、出力値から入力値を導き出すのは困難です。

５　PoHを使ったリーダーのタイミングについて

１　状況確認

では、まずあなたが「No.34」で「SLOT 3」でリーダーになるスケジュールだとします。

２　SLOTで使う単位について

Slotで使う単位は「Ticks」です。

この単位は「時間」ではなく、「回数」です。（この説明は次に出てきます。）

ここでは、１つの「SLOT」の間隔を「10 Ticks」とします。

３　1 Tickあたりの回数

ここで、「1 Tick」は「ハッシュ関数５回の実行」とします。

ここでは、時間の概念は全く登場していません。

そして、先ほどあったように、今回は、「Slot」あたりの間隔は「10 Ticks」 とします。

４　どのくらい待てば良いのか

今回、あなたは「SLOT 3」を割り当てられたので、２つ分である「20 Ticks」を待つ必要があります。（ 2 Slot × 10 Ticks）

「1 Tick」はハッシュ関数は「ハッシュ関数５回の実行」だったので、20Ticks × 5回/ticksである、100回実行することが必要です。

つまり、あなたは「◯秒待つ」ではなく、「100回ハッシュ関数の実行が終えるまで待つ」ことになります。

６　PoHの仕組みについて

１　PoHの仕組みについて

PoHは大まかには、出力した値を都度、Hash化しています。

例えば、下のように、「Count 2」では、「Hash1」の結果がハッシュ化され、それが繰り返されます。

そのため、「Count 100」に行くためには、「Count 1」の結果を99回ハッシュ化する必要があります。

Hash関数は結果から入力値を導くのが困難なので、この方法以外で、「Count 100」を確認することはできません。

２　詳しい内容について

詳細につきましては、こちらもご確認ください。

７　リーダーの検証について

１　検証方法

では、「No.34」がリーダーになる際の検証を見てみましょう。

第５章で扱ったように、No.34は「100回ハッシュを実行」する必要がありました。

その他のバリデータがこの100個のハッシュを同様に計算することで、「No.34」 が２スロット分を待ったことが検証できます。

下のように、他のバリデータによって検証されました。

２　悪意のあるリーダーについて

では３番目のリーダーが悪意を持って、２番目と３番目のブロックを両方作ろうとしたとします。

本来、２番目のブロックは下の真ん中の「No.2」のリーダーがブロックを生成するはずです。

「No.2」を追い抜くには、「No.3」は「No.2」のブロックが検証されるまでに自分のブロックまで作る必要があります。

これを行うには、「No.2」のネットワークが悪いか、「No.3」が非常に早い必要があります。

「No.3が非常に早い」という条件なら満たせそうですが、なぜそれは難しいのでしょう。

３　悪意者がブロック生成を早くすることの困難さについて

では、なぜ悪意のあるものが、非常に早いスピードでブロックを生成するのが困難なのでしょう。

それは、ブロック生成において、「マルチコア」（たくさんのコアを使用）することができないためです。

例えば、仮にブロック生成を４つのコアでやってみたとしましょう。

下の場合、２つ目のコアでは、結局、「No.25」のハッシュができるのを待たなければいけません。

そのため、たくさんのコアを使っても、並列処理ができないため、スピードが上がりません。

４　マルチコアによる検証のスピードアップについて

一方、検証の場合は、マルチコアによってスピードを上げることができます。

検証時にはすでにハッシュができています。

そのため、例えば「コア２」では「No.26」から「No.50」がハッシュ化で導けることを確認すれば良いので、並列処理ができます。

このように、それぞれ独立して、検証を行うことができます。

これらのことから、各リーダーは時間の同期をする必要がないため、リーダーの交代をスムーズに行うことができます。

８　PoHの別の使い方について

PoHは「時間」の概念を使わずに順序を確定させる技術なので、色々な場面で応用が効きます。

１　PoHに含めるトランザクションについて

PoHを行う際には、下のように、トランザクションも含めてハッシュ化します。

下の場合、「Count 80」では「Transaction2」を含めてハッシュ化し、「Hash80」ができています。

そのため、「Hash80」は「Transaction2」より後であることが確定しています。

２　トランザクションに含めるハッシュについて

実は、トランザクションを作成する際にも、最近のハッシュを含めます。

例えば、下では、「Transaction2」に最近のハッシュである「Hash57」を含めています。

これにより、「Hash57」は「Transaction2」の後であることがわかります。

９　リーダーになった後の流れについて

では、リーダーになった後の流れを見てみましょう。

１　トランザクションの受信

まずは、リーダーはトランザクションを収集します。

２　トランザクションの検証・順序化について

検証を行い、無効または不正のトランザクションを削除します。

そして、第８章の方法で、トランザクションを順序化します。

３　バリデータによる検証

次に、順番に並んだトランザクションを空のハッシュと共にバリデータに送ります。

バリデータはそれぞれ並列処理ができるため、順次トランザクションの検証を行います。

ちなみに、バリデータが並列処理できるため、リーダーはブロックが完成する前に、順次トランザクションを送っています。

４　バリデータによる投票

ブロックが完成した後、ブロックの投票を行います。

投票が受け入れられると、ブロックが完了（ファイナライズ）します。

５　次のリーダーによるブロックの生成

次のリーダーは前のブロックが完了（ファイナライズ）する前にブロックの生成を始めます。

そのため、作っていたものの、前のブロックが拒絶されてしまうこともあり得ます。

この場合は、それに続く、３番目のブロックも無効になってしまいます。

なお、このようなことが発生した場合は、「ブロック２」を生成したリーダーはスラッシュ（SOLの没収）となります。

１０　最後に

以上で、PoHが具体的にどのように使われているのかの説明は終わりです。

よかったら、元となっている動画も見てみてください。