メモです。

https://solana.com/solana-whitepaper.pdf

4 Proof of History

• POH = ２つのevent間のpassageをverifyする計算
  • outputがinputから予測できないこと
  • (completely executedってなんだろう)

4.1 Description

• 適当な初期値を用意し、それにハッシュ関数を繰り返しかける
• 計算結果の全部を公開する必要はなく、例えば1,200,300番目とか飛び飛びでもよい
  • (データ量を軽くするのは大事だからね)
• この計算は並列化できない(ハッシュ関数が脆弱でない限り)
  • ので、300番目を得るには300回計算するしかない
  • ので、hash200からhash300の間には正の実時間が経過したことが保証される
  • (あー、これを使ってイベント間の順序を保証するわけ？賢いな。)

4.2 Timestamp for Events

• あとは、「hash200が計算されたとき、このデータはすでに存在した」という紐付けをしたい
  • まずデータにハッシュ関数をかける。ハッシュ関数が予測不可能であれば、ハッシュを計算した際にデータが存在したことが保証される
  • hash336 = hash("#{hash335}#{photo1.jpg.hash}") みたいにすることで、photo1はhash336より前に存在したことが保証される
• この列を観測しているすべてのノードは、挿入されたイベント間の順序を決定でき、またイベント間の実時間も推定することができる
  • (推定はどうやって？これから出てくるのかな。)

4.3 Verification

• 検証は並列化することができる。(まじ？)
  • (あそうか、「hash200〜300を検証するやつ」と「hash300〜400を検証するやつ」は同時にできるんだ。なるほど)

4.4 Horizontal Scaling

• (PoH generatorが複数台あるときの話かな)
• (全部を同期しなくても、「自分の今の最新ハッシュはこれです」をときどき送り合って織り込むことで順序の検証には十分と)
• (true time accuracyのとこ大事そうだけどよくわからん)

4.5 Consistensy

• 悪いPoH generatorがいたらどうするか
  • たとえばevent1,2,3の順で起こったのを「3,2,1の順だったよ」と言ってくるような
  • これの対策として、event作成者が「そのときの最新hash」を織り込むようにする

5 PoS consensus

• next PoH generator(とは？)を選ぶときなどにProof of Stakeを使う

6 Streaming Proof of Replication

7 System Architecture

7.1 Components

• Leader
  • PoH generatorのうち、選挙に選ばれたやつ
• State
  • (Ripemdっていうハッシュ関数があるんだ。)
• Verifier
  • blockchain stateを複製し、その可用性に寄与する
  • 複製先はconsensus algorithmで決まる
• Validator
  • (Verifierからデータを受け取る？)
  • 独立したマシンに置いてもいいし、VerifierやLeaderと同じマシンにいてもいい

7.2 Network Limits