【2023】仮想通貨 ソラナ（SOL）とは？ 根拠のある今後の予想｜ホワイトペーパー

事務員

皆さんは仮想通貨調べる際、どのように調査していますか？
ググるくらいしか私分かんなくて…。

クリプ犬

確かに、自分も最初の方はググるとかSNSを見るとかしか分からなかったな…。
でもググった先のサイトとか、分かりやすいの多いからいいんじゃないかな。

事務員

でも、サイトによっては記載していることが違ったり、逆に多いのはほとんど同じ内容書かれていたり、参考にしがたい時があるの…。
自分で根拠のあるものをみて納得したいんだよね～。

クリプ犬

事務員さんも成長したなぁ～(笑)
確かに投資するならなおさら根拠あるものを見たいよね。
そんな時はホワイトペーパーを見てみるといいよ◎

事務員

ホワイトペーパーってなになに？？

ホワイトぺーパーとは？

ホワイトペーパーとはその仮想通貨の開発された目的や技術について、今後の計画などが記載された報告書のようなものです。
ほとんどの仮想通貨にはホワイトペーパーは必ず用意されており、信頼できる報告書です。
気になる仮想通貨がある場合は、必ずホワイトペーパーを見るようにしましょう。

ただ、ホワイトペーパーは全て英語で書かれていたり、技術の事ばかりで何書いているか分からないことも多いです…。

そこで、当サイトでは、仮想通貨毎のホワイトペーパーから読み取れた内容などを用いて今後の予想などしていきます。
ぜひ参考にしていってください◎

結論｜今後の予想

まず今後の予想から記載します。

結論：今回の分析だと、今後、最高値を更新することは厳しいのでは？と判断しました。

安心度合い：

過去最高価格は30000円ほどでしたが、FTXの破綻もあり現在は2000円ほどです。（2023/01/13現在）
筆者自身はトランザクションの速さや、プロジェクトが多くあることを期待し少し投資していますが、状況は芳しくはないでしょう。
ホワイトペーパーを軸にした分析上も以下の点で少し不安が残る形となりました。
・ロードマップが簡単には探せない点
・coimarketcap上で発行上限に記載が無くなっていた点
プラスの点としては、少し古いですが、2021年6月に344億円もの資金を調達している点です。

1.「ホワイトペーパー　確認ポイント」

まず以下の図をご覧ください。
ホワイトペーパーから読み取るべきポイントを簡単にまとめたものです。

ホワイトペーパーからはひとまず、発行上限までの6つの事項が確認できるかチェックしましょう。
仮想通貨は信用できる情報をどれだけ早く正確に手に入れられるかが大事です。
チェック項目を絞っておくことで、少しでも他の方より一歩先へ行けるよう準備しておきましょう。
ただ、ホワイトペーパーの中には、技術的側面が多く記載されたホワイトペーパーや、記載情報が少ないものもあります。
そこで、上記の6つの項目がホワイトペーパーに記載されているかの有無と、無かった場合の簡易的な検索結果をまとめましたので、ぜひご活用下さい。

1-1.ロードマップ（開発スケジュール）｜ソラナ　仮想通貨

ロードマップとは、丁寧に一言で表すと、「（ある仮想通貨の）今後の計画を記したもの」です。

ホワイトペーパ―の中で、その仮想通貨の今後または現在の進捗具合を知るのに、ロードマップは大きな役割を果たします。このロードマップが細かく書かれている方が投資家にとっても投資対象かどうか判断しやすいですし、綿密な計画を練っている事も判断できるので、ロードマップの粒度も確認したいポイントです。

【SOL　ロードマップ】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
2022年1月26日ころの記事によると2022年版のロードマップが公式より発表はされてないとのことでした。ただ記事によると初期ロードマップは発表されているようですが、筆者は見つけられませんでした。
一部抜粋したものを記載いたします。

2022年3月がSolanaのネットワークがベータ版を離れる可能性のある日付である可能性があるようです。これは、2019年後半にリリースされたSolanaの初期ロードマップの最後の部分を満たすでしょう。
それまでは、ブロックチェーンがまだ分散化を達成していないことを示唆した2021年9月のようなネットワーク停止の可能性がまだあります。
ロードマップ以外にも、2022年に多くのプロジェクトや開発がリリースされる予定ですが、コアSolanaチームの公式日程はまだ入手できません。

2022年のソラナ:重要な日付、ロードマップ、予測|ファインダー (finder.com.au)より引用
2022/12/21

1-2.発行主体（プロジェクトメンバー）｜SOL 開発メンバー

発行主体は見落としがちですが、しっかり確認しましょう。
時価総額が高くSOLのように有名であれば、発行元が不明瞭なことはあり得ませんが、念のためどのホワイトペーパーでも確認するようにしましょう。

【SOL　発行元】：
こちらはホワイトペーパーにメールアドレス？の記載がありました。
ソラナブロックチェーンの共同創設者でCEOの方のメールアドレスだと思われます。
Anatoly Yakovenkoを検索するとどんな人物なのか調べることが出来ますので、気になる方はぜひ。
以下ホワイトペーパーより抜粋。

Anatoly Yakovenko anatoly@solana.io

活動拠点（実際に存在するかも併せて）｜SOL 仮想通貨

開発拠点・活動拠点がしっかり記載してあれば、信用度は上がります。
ただこれからはより非中央集権化が進むと思われるため、活動拠点がしっかりとしているものも少なくなってくるかもしれません。あれば本当に存在しているのか確認してみましょう。

【SOL　活動拠点】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
住所以外にもプロジェクトメンバーや非上場企業であることなど会社の概要についての記載がありました。
住所に関して抜粋したものを以下に記載いたします。

会社規模　社員11名～50名
住所　530 Divisadero St　PMB 722　San Francisco、California、94117、US

Solana Labs | LinkedInより引用
2023/01/01

資金調達方法（資金の使い方も併せて）｜ソラナ ホワイトペーパー

資金の有無はその仮想通貨の将来性にも大きく関わってきます。
資金調達がしっかり公表されており、資金調達した企業が大物であればあるほど世間からの期待は大きいものとなり、価格もそれに比例するものです。
資金調達とは少し話がずれますが、かのイーロンマスクがドージコインに投資をするようなツイートをしたところ、とんでもない高騰を見せました。
たまたま買っていた方羨ましい…。(笑)

【SOL　資金調達方法】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
様々な方法で資金の調達はしているようですが、大きな金額が動いたもので言うとプライベートトークンセールによるものの様です。
以下に一部を抜粋したものを記載いたします。

暗号資産（仮想通貨）ソラナ（SOL）の開発を行う「Solana Labs」は9日、プライベートトークンセールでおよそ3.1億ドル（約344億円）の資金を調達したことを発表した。

仮想通貨ソラナ（SOL）のエコシステム拡大へ──Solana Labs、340億円超の資金調達を発表 (coinpost.jp)より引用
2023/01/01

開発目的（具体性のあるものかどうか）｜ソラナ 将来性

開発目的がはっきりしていない仮想通貨は将来性ははっきりいってありません。
もしあなたが本気でどこかの株を買う際、何のためにその会社が存在しているのか調べたりしますよね。
その会社が目的を持たずふんわりやっていそうだなと判断した時投資するでしょうか？
私ならしません…。
ただ、ホワイトペーパーに開発目的が書かれていないからといって将来性が無いとは言い切れません。
ホワイトペーパーが技術に関してを中心に書かれているものも多いためです。

【SOL　開発目的】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
SOLはETHなどのプラットフォームより高いスケーラビリティを実現できる分散型市場のプラットフォームを作成し、dAppsを作成する目的で作られて様です。
他プラットフォームよりPoHにより特筆すべきトランザクション処理速度を誇っていますが、度々障害を起こしてしまってる印象があります。（筆者の感想です）
以下に参考にした記事の一部抜粋したものを記載いたします。

Solanaはオープンソースのブロックチェーン暗号であり、いくつかの新しいテクノロジーを使用して分散型市場プラットフォームを作成し、スケーラブルで高速なアプリケーションである分散型アプリ(dApps)を作成します。

ソラナとは何ですか、そしてその目的は何ですか? |ECCプロジェクト暗号通貨 (cryptoecc.com)より引用
2023/01/03

Solanaは標準的なビザンチン将軍問題の解決を目指すProof of Stakeブロックチェーンですが、特筆すべきトランザクション処理能力を持っており、およそ200のノードで一秒あたり5万のトランザクションを行えるとしています。これは現CEOのAnatoly Yakovenko氏が2017年に提唱したProof of Historyという、信頼なきノード同士で時間を同期する手法の採用など、8つのイノベーションにより実現したものです。

仮想通貨ソラナ（SOL）とは｜注目ポイントと今後の将来性 (coinpost.jp)より引用
2023/01/03

発行上限｜SOL 価格

発行上限はその仮想通貨の価格に大きく影響を及ぼします。
極論を言ってしまうと、もし無限に発行されるものの場合、価格はどこまでも落ちる可能性があります。
上限がきちんと制定されているモノの方が筆者は安心いたします。

【SOL　発行上限】：
ホワイトペーパーからは見つけられませんでした。

【検索結果】：
最新のcoinmarketcapによると最大供給量の欄が「–」になっていました…。
発行上限が変わったのでしょうか。
調査完了次第、回答を記載いたします。
以下は参考にしたcoinmarketcapのURLです。

Solana（SOL）価格・チャート・時価総額 | CoinMarketCap
2023/01/03

2.「ホワイトペーパー」

2-1.SOL ホワイトペーパー 原文

2-2.SOL ホワイトペーパー 日本語訳

SOLNA：高性能ブロックチェーンのための新しいアーキテクチャ

注意書き：法的免責事項 このホワイトペーパーの内容は、トークンの販売の申し出、または購入の申し出の勧誘ではありません。 Solanaは、一般からのフィードバックとコメントを受け取るためだけに、このホワイトペーパーを公開しています。
Solanaがトークン (または将来のトークンの簡易契約) を販売する場合、開示文書とリスク要因を含む最終的な提供文書を通じて販売を行います。 これらの最終文書には、現在のバージョンとは大幅に異なる可能性がある、このホワイト ペーパーの更新版も含まれる予定です。
Solana が米国でそのような売り出しを行った場合、その売り出しは認定された投資家のみが利用できる可能性があります。このホワイトペーパーの内容は、Solanasのビジネスまたはトークンがどのように発展するか、またはトークンの有用性または価値を保証または約束するものとして扱われたり、読み取られたりするものではありません。このホワイトペーパーでは、現在の計画の概要を説明していますが、その計画は独自の裁量で変更される可能性があり、その成功は多くの要因に左右されます。これには、市場ベースの要因や、データおよび暗号通貨業界内の要因などが含まれます。将来の出来事に関する記述は、このホワイトペーパーに記載されている問題に関する Solanasの分析のみに基づいています。 その分析は間違っていることが判明するかもしれません。

概要

この論文では、Proof of History (PoH) に基づく新しいブロックチェーン アーキテクチャを提案します。これは、順序とイベント間の時間の経過を検証するための証明です。 PoH はトラストレスな時間の経過を台帳 (追加のみのデータ構造) にエンコードするために使用されます。 プルーフ オブ ワーク (PoW) やプルーフ オブ ステーク (PoS) などのコンセンサス アルゴリズムと一緒に使用すると、PoH はビザンチン フォールト トレラント レプリケート ステート マシンのメッセージング オーバーヘッドを削減し、1 秒未満のファイナリティ タイムを実現できます。 このホワイト ペーパーでは、PoH 台帳のタイムキーピング プロパティを活用する 2 つのアルゴリズムも提案します。1 つは、任意のサイズのパーティションから回復できる PoS アルゴリズムで、もう 1 つは効率的なストリーミングの複製証明 (PoRep) です。 PoRep と PoH の組み合わせは、時間 (順序付け) とストレージに関して台帳の偽造に対する防御を提供します。 プロトコルは 1 Gbps ネットワークで分析され、このホワイト ペーパーでは、現在のハードウェアで 1 秒あたり最大 71 万トランザクションのスループットが可能であることを示しています。

-1-

1 Introduction

ブロックチェーンは、フォールト トレラントなレプリケート ステート マシンの実装です。 現在公開されているブロックチェーンは、時間に依存していないか、参加者が時間を維持する能力について弱い仮定を置いています [4, 5]。 通常、ネットワーク内の各ノードは、ネットワーク内の他の参加者のクロックを認識せずに、独自のローカル クロックに依存します。 信頼できる時間のソースがないということは、メッセージのタイムスタンプを使用してメッセージを受け入れたり拒否したりする場合、ネットワーク内の他のすべての参加者がまったく同じ選択をするという保証がないことを意味します。 ここで提示される PoH は、検証可能な時間の経過、つまりイベント間の期間とメッセージの順序付けを含む台帳を作成するように設計されています。 ネットワーク内のすべてのノードが、台帳に記録された時間の経過を信頼なしで信頼できるようになることが予想されます。

2 Outline

この記事の残りの部分は、次のように構成されています。 全体的なシステム設計は、セクション 3 で説明されています。プルーフ オブ ヒストリーの詳細な説明は、セクション 4 で説明されています。提案されているプルーフ オブ ステーク コンセンサス アルゴリズムの詳細な説明は、セクション 5 で説明されています。提案されている高速複製証明の詳細な説明は、 セクション 6 で説明されています。システム アーキテクチャとパフォーマンスの制限は、セクション 7 で分析されています。高性能 GPU フレンドリーなスマート コントラクト エンジンは、セクション 7.5 で説明されています。

3 Network Design

図 1 に示すように、システム ノードはいつでもリーダーとして指定され、Proof of History シーケンスを生成し、ネットワークのグローバルな読み取りの一貫性と検証可能な時間の経過を提供します。 リーダーは、システム内の他のノードが効率的に処理できるように、ユーザー メッセージを順序付けて順序付けし、スループットを最大化します。 RAM に保存されている現在の状態でトランザクションを実行し、トランザクションと最終状態の署名を Verifier と呼ばれるレプリケーション ノードに発行します。 検証者は、状態のコピーに対して同じトランザクションを実行し、計算された状態の署名を確認として公開します。 公開された確認は、コンセンサス アルゴリズムの投票として機能します。

-2-

※「Solana: A new architecture for a high 」performance blockchain v0.8.13」より2022/10/25引用

パーティション化されていない状態では、常に 1 つのリーダーが通信網。 各 Verifier ノードは、リーダーと同じハードウェア機能を備えており、リーダーとして選出できます。これは、PoS ベースの選出を通じて行われます。 提案された PoS アルゴリズムの選択については、セクション 5.6 で詳しく説明します。 CAP定理に関しては、パーティションが発生した場合、ほぼ常に一貫性が可用性よりも優先されます。 大規模なパーティションの場合、この論文では、任意のサイズのパーティションからネットワークの制御を回復するメカニズムを提案します。 これについては、セクション 5.12 で詳しく説明します。

4 Proof of History

履歴の証明は、2 つのイベント間の時間の経過を暗号的に検証する方法を提供できる一連の計算です。入力から出力を予測できないように記述された暗号的に安全な関数を使用し、出力を生成するには完全に実行する必要があります。関数は単一のコアでシーケンスで実行され、以前の出力が現在の入力として実行され、現在の出力と呼び出された回数が定期的に記録されます。出力は、別のコアで各シーケンス セグメントをチェックすることにより、外部コンピューターによって並列に再計算および検証できます。データ (または一部のデータのハッシュ) を関数の状態に追加することにより、データをこのシーケンスにタイムスタンプすることができます。シーケンスに追加された状態、インデックス、およびデータの記録は、次のハッシュがシーケンスで生成される前にデータが作成されたことを保証できるタイムスタンプを提供します。この設計は水平方向のスケーリングもサポートします。これは、複数のジェネレーターが、それらの状態を相互のシーケンスに混合することによって相互に同期できるためです。水平スケーリングについては、セクション 4.4 で詳しく説明します。

-3-

-4.1 Description

このシステムは、次のように動作するように設計されています。 関数を実行しないと出力を予測できない暗号化ハッシュ関数 (sha256、ripemd など) を使用する場合は、ランダムな開始値から関数を実行し、その出力を取得して、同じ関数への入力として再度渡します。 関数が呼び出された回数と各呼び出しでの出力を記録します。 選択された開始ランダム値は、その日のニューヨークタイムズの見出しなど、任意の文字列にすることができます

※「Solana: A new architecture for a high 」performance blockchain v0.8.13」より2022/10/25引用

-4-

選択したハッシュ関数が耐衝突性である限り、この一連のハッシュは単一のコンピューター スレッドによってのみ順番に計算できます。 これは、開始値からアルゴリズムを実際に 300 回実行しないと、インデックス 300 のハッシュ値がどうなるかを予測する方法がないという事実から生じます。 したがって、インデックス 0 とインデックス 300 の間でリアルタイムが経過したことをデータ構造から推測できます。 PoH アルゴリズムでは、カウント 510144806912 とカウント 510146904064 の間でリアルタイムが経過したことを信頼できます。

※「Solana: A new architecture for a high 」performance blockchain v0.8.13」より2022/10/25引用

-5-

-4.2 Timestamp for Events

この一連のハッシュは、特定のハッシュ インデックスが生成される前にデータの一部が作成されたことを記録するためにも使用できます。 「combine」関数を使用して、データの一部を現在のインデックスの現在のハッシュと結合します。 データは、任意のイベント データの暗号化された一意のハッシュである場合があります。 結合関数は、データの単純な追加、または衝突に強い任意の操作にすることができます。 次に生成されるハッシュは、データのタイムスタンプを表します。これは、特定のデータが挿入された後にのみ生成される可能性があるためです。

※「Solana: A new architecture for a high 」performance blockchain v0.8.13」より2022/10/25引用

Hash336 は、添付された hash335 のバイナリ データと写真の sha256 から計算されます。 写真のインデックスと sha256 は、シーケンス出力の一部として記録されます。 したがって、このシーケンスを検証する人は誰でも、この変更をシーケンスに再作成できます。 検証は並行して行うことができ、セクション 4.3 で説明します。
最初のプロセスは依然としてシーケンシャルであるため、シーケンスに入力されたものは、将来のハッシュ値が計算される前に発生したに違いないことがわかります。

-6-

表３で表されるシーケンスでは、photo2 は hash600 の前に作成され、photo1 は hash336 の前に作成されました。 ハッシュのシーケンスにデータを挿入すると、シーケンス内の後続のすべての値が変更されます。 使用されるハッシュ関数が衝突耐性があり、データが追加されている限り、それはどのデータがシーケンスに統合されるかについての事前知識に基づいて、将来のシーケンスを事前計算することは計算上不可能です。
シーケンスに混合されるデータは、生データ自体、または付随するメタデータを含むデータの単なるハッシュの場合があります。
図 3 の例では、入力 cfd40df8… が Proof of History シーケンスに挿入されています。 挿入された回数は 510145855488 で、挿入された状態は 3d039eef3 です。 今後生成されるすべてのハッシュは、シーケンスに対するこの変更によって変更されます。この変更は、図の色の変化によって示されます。
このシーケンスを監視するすべてのノードは、すべてのイベントが挿入された順序を決定し、挿入間のリアルタイムを推定できます。

-7-

-4.3 Verification

シーケンスは、生成にかかった時間よりも大幅に短い時間で、マルチコア コンピューターによって正しいことを検証できます。

4000 コアの最新の GPU のように、いくつかのコアが与えられた場合、ベリファイアは一連のハッシュとそのインデックスを 4000 のスライスに分割し、並行して、各スライスが最初のハッシュから最後のハッシュまで正しいことを確認します。シーケンスの生成に予想される時間が次のようになる場合⇩

-8-

図 4 の例では、各コアがシーケンスの各スライスを並行して検証できます。 すべての入力文字列が出力に記録され、それらが追加されたカウンターと状態が記録されるため、検証者は各スライスを並行して複製できます。 赤色のハッシュは、データ挿入によってシーケンスが変更されたことを示します。

-4.4 Horizontal Scaling

各ジェネレーターから他の各ジェネレーターへのシーケンス状態を混合することにより、複数の Proof of History ジェネレーターを同期し、Proof of History ジェネレーターの水平方向のスケーリングを実現できます。 このスケーリングはシャーディングなしで行われます。 システム内のイベントの完全な順序を再構築するには、両方のジェネレーターの出力が必要です。

-9-

ジェネレーター A と B を指定すると、A は B からデータ パケット (hash1b) を受信します。これには、ジェネレーター B からの最後の状態と、ジェネレーター A から観測された最後の状態ジェネレーター B が含まれます。ジェネレーター A の次の状態ハッシュは、次の状態に依存します。 ジェネレータ B であるため、hash1b が hash3a の前に発生したことがわかります。 このプロパティは推移的である可能性があるため、3 つのジェネレーターが単一の共通ジェネレーター A ↔ B ↔ C を介して同期されている場合、直接同期されていなくても、A と C の間の依存関係を追跡できます。
ジェネレーターを定期的に同期することにより、各ジェネレーターは外部トラフィックの一部を処理できるため、システム全体で大量のイベントを処理して追跡することができますが、ジェネレーター間のネットワーク レイテンシーが原因で真の時間精度が犠牲になります。 グローバルな順序は、ハッシュ自体の値などによって、同期ウィンドウ内にあるイベントを順序付けする決定論的関数を選択することで実現できます。
図 5 では、2 つのジェネレーターが互いの出力状態を挿入し、操作を記録しています。 色の変化は、ピアからのデータがシーケンスを変更したことを示します。 各ストリームに混合される生成されたハッシュは、太字で強調表示されています。
同期は推移的です。 A ↔ B ↔ C B を介して A と C の間に証明可能なイベントの順序があります。この方法でのスケーリングは、可用性を犠牲にして行われます。 可用性が 0.999 の 10 × 1 Gbps 接続では、0.99910 = 0.99 av になります。

-4.5 Consistency

ユーザーは、生成されたシーケンスの一貫性を強制し、有効と見なすシーケンスの最後に観察された出力を入力に挿入することで、攻撃に対する耐性を持たせることができると期待されています。

-10-,-11-

悪意のある PoH ジェネレーターは、一度にすべてのイベントにアクセスできる場合、またはより高速な隠しシーケンスを生成できる場合、イベントを逆順に並べた 2 番目の隠しシーケンスを生成する可能性があります。 この攻撃を防ぐために、クライアントが生成した各イベントには、クライアントが有効なシーケンスと見なすものから観察した最新のハッシュが含まれている必要があります。 そのため、クライアントが「Event1」データを作成するとき、観察した最後のハッシュを追加する必要があります。

シーケンスが公開されると、Event3 は hash30a を参照し、このイベントの前のシーケンスにない場合、シーケンスの消費者は、それが無効なシーケンスであることを認識します。 部分的な並べ替え攻撃は、クライアントがイベントを監視している間、およびイベントが入力されたときに生成されるハッシュの数に制限されます。 クライアントは、最後に観察されたハッシュと挿入されたハッシュの間の短い期間のハッシュの順序が正しいと想定しないソフトウェアを作成できる必要があります。 悪意のある PoH ジェネレーターがクライアントのイベント ハッシュを書き換えるのを防ぐために、クライアントはデータだけでなく、イベント データの署名と最後に観察されたハッシュを送信できます。

このデータの検証には、署名の検証と、このハッシュの前の一連のハッシュでのハッシュのルックアップが必要です。確認⇩

-12-

図 6 では、ユーザーが指定した入力は、ハッシュ 0xdeadbeef… に依存しており、挿入される前に生成されたシーケンスに存在しています。 左上の青い矢印は、クライアントが以前に生成されたハッシュを参照していることを示しています。 クライアント メッセージは、ハッシュ 0xdeadbeef… を含むシーケンスでのみ有効です。シーケンス内の赤い色は、シーケンスがクライアント データによって変更されたことを示します。

-4.6 Overhead

1 秒あたり 4000 ハッシュでは、さらに 160 キロバイトのデータが生成され、4000 コアの GPU へのアクセスと、検証に約 0.25 ～ 0.75 ミリ秒の時間が必要になります。

-4.7 Attacks

-4.7.1 Reversal

逆の順序を生成するには、攻撃者が 2 番目のイベントの後に悪意のあるシーケンスを開始する必要があります。 この遅延により、悪意のないピア ツー ピア ノードが元の順序について通信できるようになります。

-13-

-4.7.2 Speed

複数のジェネレーターを使用すると、デプロイメントが攻撃に対してより耐性を持つ可能性があります。 1 つのジェネレーターは高帯域幅で、多くのイベントを受信してそのシーケンスに混合することができます。別のジェネレーターは、高帯域幅ジェネレーターと定期的に混合する高速低帯域幅である可能性があります。 高速シーケンスは、攻撃者が逆にしなければならないデータの二次シーケンスを作成します。

-4.7.3 Long Range Attacks

長距離攻撃には、破棄された古いクライアント秘密鍵の取得と、偽造台帳の生成が含まれます [10]。 履歴の証明は、長距離攻撃に対するある程度の保護を提供します。 古い秘密鍵にアクセスできる悪意のあるユーザーは、偽造しようとしている元の記録と同じくらいの時間をかけて履歴記録を再作成する必要があります。 これには、ネットワークが現在使用しているよりも高速なプロセッサへのアクセスが必要です。そうしないと、攻撃者は履歴の長さに追いつくことができません。 さらに、単一の時間ソースにより、より単純な複製証明の構築が可能になります (詳細はセクション 6 を参照)。 ネットワークは、ネットワーク内のすべての参加者がイベントの単一の履歴記録に依存するように設計されているためです。 PoRep と PoH を組み合わせることで、偽造元帳に対する空間と時間の両方の防御を提供する必要があります。

5 Proof of Stake Consensus

-5.1 Description

このプルーフ オブ ステークの特定のインスタンスは、プルーフ オブ ヒストリー ジェネレーターによって生成された現在のシーケンスを迅速に確認し、投票して次のプルーフ オブ ヒストリー ジェネレーターを選択し、不正な動作をするバリデーターを処罰するために設計されています。 このアルゴリズムは、特定のタイムアウト内に最終的にすべての参加ノードに到着するメッセージに依存します。

-14-

-5.2 Terminology

-5.3 Bonding

結合トランザクションは、コインの量を受け取り、それをユーザー ID の下の結合アカウントに移動します。 結合アカウントのコインは使用できず、ユーザーがコインを削除するまでアカウントに残す必要があります。 ユーザーは、タイムアウトになった古いコインのみを削除できます。 債券は、現在の利害関係者の過半数がシーケンスを確認した後に有効になります。

-5.4 Voting

Proof of History ジェネレーターは、事前定義された期間に州の署名を公開できると予想されます。 各結合 ID は、州の独自の署名付き署名を公開することにより、その署名を確認する必要があります。 投票は単純な賛成票で、反対票はありません。 ボンディングされた ID の過半数がタイムアウト内に投票した場合、このブランチは有効として受け入れられます。

-15-

-5.5 Unbonding

N 票の欠落があると、コインは古くなり、投票の資格がなくなったとマークされます。 ユーザーは、結合解除トランザクションを発行してそれらを削除できます。 N は、アクティブな投票に対する古い投票の比率に基づく動的な値です。 N は、古い投票の数が増えるにつれて増加します。 大規模なネットワーク パーティションが発生した場合、これにより、大規模なブランチが小規模なブランチよりも迅速に回復できます。

-5.6 Elections

PoH ジェネレーターの障害が検出されると、新しい PoH ジェネレーターの選択が行われます。最大の投票力を持つバリデーター、または同点の場合は最大の公開鍵アドレスを持つバリデーターが、新しい PoH ジェネレーターとして選択されます。新しいシーケンスでは、圧倒的多数の確認が必要です。超過半数の確認が利用可能になる前に新しいリーダーが失敗した場合、次に高いバリデーターが選択され、新しい一連の確認が必要になります。投票を切り替えるには、バリデーターはより高い PoH シーケンス カウンターで投票する必要があり、新しい投票には切り替えたい投票が含まれている必要があります。それ以外の場合、2 番目の投票はスラッシュ可能になります。投票の切り替えは、超過半数を持たない高さでのみ発生するように設計される予定です。 PoH ジェネレーターが確立されると、トランザクション処理の任務を引き継ぐためにセカンダリを選択できます。セカンダリが存在する場合、プライマリの障害時に次のリーダーと見なされます。プラットフォームは、例外が検出された場合、または事前定義されたスケジュールに従って、セカンダリがプライマリになり、下位ランクのジェネレーターが昇格するように設計されています。

-5.7 Election Triggers

-5.7.1 Forked Proof of History generator

PoH ジェネレーターは、生成されたシーケンスに署名する ID を使用して設計されています。 フォークは、PoH ジェネレーターの ID が侵害された場合にのみ発生します。 2 つの異なる履歴レコードが同じ PoH ID で公開されているため、フォークが検出されます。

-16-

-5.7.2 Runtime Exceptions

ハードウェア障害、バグ、または PoH ジェネレーターの意図的なエラーにより、無効な状態が生成され、ローカル バリデーターの結果と一致しない状態の署名が公開される可能性があります。 バリデーターはゴシップを介して正しい署名を公開し、このイベントは新しいラウンドの選挙を引き起こします。 無効な状態を受け入れるバリデーターは、ボンズが削減されます。

-5.7.3 Network Timeouts

ネットワーク タイムアウトは、選挙を引き起こします。

-5.8 Slashing

バリデーターが 2 つの別々のシーケンスを投票すると、スラッシングが発生します。 悪意のある投票の証拠は、保税コインを流通から削除し、マイニング プールに追加します。 競合するシーケンスに対する以前の投票を含む投票は、悪意のある投票の証拠として適格ではありません。 債券を削減する代わりに、この投票は、競合するシーケンスで現在キャストされている投票を削除します。 PoH ジェネレーターによって生成された無効なハッシュに対して投票が行われた場合も、スラッシュが発生します。 ジェネレーターは、セカンダリへのフォールバックをトリガーする無効な状態をランダムに生成することが期待されます。

-5.9 Secondary Elections

2 次および下位ランクの履歴ジェネレーターを提案し、承認することができます。 提案は、プライマリ ジェネレーター シーケンスにキャストされます。 提案にはタイムアウトが含まれます。モーションがタイムアウト前に投票の過半数によって承認された場合、セカンダリは選出されたと見なされ、スケジュールどおりに職務を引き継ぎます。 プライマリは、ハンドオーバーが発生することを示すメッセージを生成されたシーケンスに挿入するか、無効な状態を挿入してネットワークを強制的にセカンダリにフォールバックさせることにより、セカンダリへのソフト ハンドオーバーを実行できます。 セカンダリが選択され、プライマリが失敗した場合、セカンダリは選択中の最初のフォールバックと見なされます。

-17-

-5.10 Availability

パーティションを扱う CAP システムは、一貫性または可用性を選択する必要があります。私たちのアプローチは最終的に可用性を選択しますが、時間の客観的な尺度があるため、合理的な人間のタイムアウトで一貫性が選択されます。
プルーフ オブ ステークの検証者は、特定の一連のトランザクションに投票できるように、ステークに一定量のコインをロックします。コインのロックアップは、他のトランザクションと同様に、PoH ストリームに入力されるトランザクションです。
投票するには、PoS 検証者は状態のハッシュに署名する必要があります。これは、PoH 台帳の特定の位置へのすべてのトランザクションを処理した後に計算されたものです。この投票もトランザクションとして PoH ストリームに入力されます。 PoH台帳を見ると、各投票の間にどれくらいの時間が経過したか、分割が発生した場合は各検証者が利用できなかった期間を推測できます。合理的な人間の時間枠でパーティションに対処するために、利用できない検証者をアンステークする動的なアプローチを提案します。検証者の数が多く、2/3 を超えると、ステーク解除プロセスが高速になる可能性があります。使用できない検証者のステークが完全にステーク解除され、コンセンサスのためにカウントされなくなる前に、元帳に生成する必要があるハッシュの数が少なくなります。検証者の数が 2/3 rds 未満で 1/2 を超える場合、ステーク解除タイマーは遅くなり、欠落している検証者がステーク解除される前に、より多くのハッシュを生成する必要があります。 1/2 個以上のベリファイアが欠落しているパーティションのような大きなパーティションでは、ステーク解除プロセスは非常に遅くなります。トランザクションは引き続きストリームに入力でき、検証者は引き続き投票できますが、非常に大量のハッシュが生成され、利用できない検証者がステーキングを解除されるまで、完全な 2/3 rds コンセンサスは達成されません。ネットワークが活性を取り戻すまでの時間の違いにより、ネットワークの人間の時間枠の顧客として、引き続き使用したいパーティションを選択することができます。

-5.11 Recovery

私たちが提案するシステムでは、元帳は障害から完全に回復できます。 つまり、世界中の誰もが元帳の任意の場所をランダムに選択し、新しく生成されたハッシュとトランザクションを追加することで有効なフォークを作成できます。 すべての検証者がこのフォークから欠落している場合、追加の結合が有効になり、このブランチが 2/3 rds 超多数のコンセンサスを達成するのに非常に長い時間がかかります。 そのため、使用可能なバリデーターがゼロの状態で完全に回復するには、元帳に非常に大量のハッシュを追加する必要があり、使用できないすべてのバリデーターのステーキングが解除された後にのみ、新しいボンドが元帳を検証できるようになります。

-18-

-5.12 Finality

PoH を使用すると、ネットワークの検証者は、過去に何が起こったかをある程度確実に観察できます。 PoH ジェネレーターがメッセージのストリームを生成しているため、すべての検証者は 500 ミリ秒以内に状態の署名を送信する必要があります。 この数は、ネットワークの状態に応じてさらに減らすことができます。 各検証はストリームに入力されるため、ネットワーク内の誰もが、実際に投票を直接観察することなく、必要なタイムアウト内にすべての検証者が投票を送信したことを検証できます。

-5.13 Attacks

-5.13.1 Tragedy of Commons

PoS 検証者は、PoH ジェネレーターによって生成された状態ハッシュを確認するだけです。 彼らには、何の作業もせず、生成されたすべての状態ハッシュを単純に承認するという経済的インセンティブがあります。 この状態を回避するには、PoH ジェネレーターが無効なハッシュをランダムな間隔で挿入する必要があります。 このハッシュの有権者はすべて削減する必要があります。 ハッシュが生成されると、ネットワークはすぐに選択されたセカンダリ PoH ジェネレーターを昇格させる必要があります。 各検証者は、短いタイムアウト (たとえば 500 ミリ秒) 内で応答する必要があります。 タイムアウトは、悪意のある検証者が別の検証者の投票を観察してストリームに十分な速さで投票を取得する可能性が低くなるように、十分に低く設定する必要があります。

-5.13.2 Collusion with the PoH generatoy

PoH ジェネレーターと共謀している検証者は、無効なハッシュがいつ生成されるかを事前に知っており、それに投票しません。 このシナリオは、より大きな検証者のステークを持つ PoH ID と実際には違いはありません。 PoH ジェネレーターは、状態ハッシュを生成するためにすべての作業を行う必要があります。

-19-

-5.13.3 Censorship

債券所有者の 1/3 が新しい債券のシーケンスの検証を拒否すると、検閲またはサービス拒否が発生する可能性があります。プロトコルは、結合が古くなる速度を動的に調整することで、この形式の攻撃を防御できます。サービス拒否が発生した場合、より大きなパーティションは、ビザンチン債券保有者をフォークして検閲するように設計されます。ビザンチン ボンドが時間の経過とともに古くなるため、より大きなネットワークが回復します。小さいビザンチン パーティションは、より長い期間、前進できなくなります。アルゴリズムは次のように機能します。ネットワークの過半数が新しいリーダーを選出します。リーダーは、ビザンチンの債券所有者が参加するのを検閲します。 Proof of History ジェネレーターは、時間の経過を証明するために、十分な数のビザンチン ボンドが古くなり、より大きなネットワークが過半数を占めるまで、シーケンスを生成し続ける必要があります。ボンドが古くなる速度は、アクティブなボンドの割合に基づいて動的に決まります。そのため、ネットワークのビザンチン少数派フォークは多数派フォークよりもはるかに長く待機して、超多数派を回復する必要があります。超過半数が確立されると、ビザンチンの債券保有者を永久に罰するためにスラッシュが使用される可能性があります。

-5.13.4 Long Range Attacks

PoH は、長距離攻撃に対する自然な防御を提供します。 過去の任意の時点から台帳を復元するには、攻撃者が PoH ジェネレーターの速度を追い越して、有効な台帳を時間内に追い越す必要があります。 コンセンサス プロトコルは、すべての有効なバリデータのステークを解除するのにかかる時間よりも、攻撃に時間がかかるため、2 番目の防御層を提供します。 また、元帳の履歴に可用性のギャップが生じます。 同じ高さの 2 つの台帳を比較する場合、最小の最大パーティションを持つ台帳が客観的に有効であると見なすことができます。

-5.13.5 ASIC Attacks

このプロトコルには、ASIC 攻撃の機会が 2 つあります。分割中と、ファイナリティでの不正行為のタイムアウトです。 パーティション中の ASIC 攻撃の場合、結合が解除される速度は非線形であり、大きなパーティションを持つネットワークの場合、速度は ASIC 攻撃から予想される利益よりも桁違いに遅くなります。
ファイナリティ中の ASIC 攻撃の場合、この脆弱性により、結合されたステークを持つビザンチン バリデーターが他のノードからの確認を待ち、協力している PoH ジェネレーターで投票を注入することが可能になります。 その後、PoH ジェネレーターはより高速な ASIC を使用して 500 ミリ秒相当のハッシュをより短い時間で生成し、PoH ジェネレーターと協力ノード間のネットワーク通信を可能にします。 ただし、PoH ジェネレーターもビザンチンである場合、ビザンチン ジェネレーターが障害の挿入を予期するときに正確なカウンターを通信しなかった理由はありません。 このシナリオは、PoH ジェネレーターとすべてのコラボレーターが同じ ID を共有し、1 つの結合されたステークを持ち、1 セットのハードウェアのみを使用する場合と同じです。

-20-

6 Streaming Proof of Replication

-6.1 Description

Filecoin は、Proof of Replication [6] のバージョンを提案しました。 このバージョンの目標は、Proof of History 生成シーケンスで時間を追跡することによって有効になる、Proof of Replication の高速でストリーミング検証を行うことです。 レプリケーションはコンセンサス アルゴリズムとしては使用されませんが、高可用性でブロックチェーンの履歴または状態を保存するコストを考慮するのに役立つツールです。

-6.2 Algorithm

図 7 に示すように、CBC 暗号化では、以前に暗号化されたブロックを使用して入力データの XOR を使用して、データの各ブロックを順番に暗号化します。各レプリケーション ID は、Proof of History シーケンスで生成されたハッシュに署名することによってキーを生成します。これにより、キーがレプリケーターの ID と特定の Proof of History シーケンスに関連付けられます。特定のハッシュのみを選択できます。 (ハッシュ選択についてはセクション 6.5 を参照してください) データセットはブロックごとに完全に暗号化されます。次に、プルーフを生成するために、キーを使用して、各ブロックからランダムな 32 バイトを選択する疑似乱数ジェネレーターをシードします。選択した PoH ハッシュを各スライスの先頭に追加して、マークル ハッシュが計算されます。ルートは、キー、および生成された選択されたハッシュと共に公開されます。複製ノードは、Proof of History ジェネレーターによって生成される N ハッシュで別の証明を公開する必要があります。N は、データの暗号化にかかる時間の約 1/2 です。 Proof of History ジェネレーターは、事前定義された期間に、Proof of Replication の特定のハッシュを公開します。レプリケーター ノードは、プルーフを生成するために、次に公開されたハッシュを選択する必要があります。ここでも、ハッシュが署名され、ブロックからランダムなスライスが選択されて、マークル ルートが作成されます。 N 回の証明期間の後、データは新しい CBC キーで再暗号化されます。

-21-

-22-

-6.3 Verification

N 個のコアを使用すると、各コアは各 ID の暗号化をストリーミングできます。 前の暗号化ブロックは次の暗号化ブロックを生成するために必要なため、必要な合計スペースは 2blocks ∗ Ncores です。 その後、各コアを使用して、現在の暗号化されたブロックから派生したすべての証明を生成できます。 証拠を検証するための合計時間は、暗号化にかかる時間と同じであると予想されます。 プルーフ自体は、ブロックから数バイトのランダムなバイトを消費するため、ハッシュするデータの量は、暗号化されたブロック サイズよりも大幅に少なくなります。 同時に検証できるレプリケーション ID の数は、使用可能なコアの数と同じです。 最新の GPU には、CPU の 1/2 から 1/3 のクロック速度ではありますが、3500 以上のコアが利用可能です。

-6.4 Key Rotation

鍵のローテーションがなければ、同じ暗号化された複製が、複数の Proof of History シーケンスに対して安価な証明を生成できます。 キーは定期的にローテーションされ、各レプリケーションは一意の履歴証明シーケンスに関連付けられた新しいキーで再暗号化されます。 回転は、CPU よりもコアあたりの速度が遅い GPU ハードウェアで複製プルーフを検証するのに十分なほど遅くする必要があります。

-6.5 Hash Selection

Proof of History ジェネレーターは、ネットワーク全体で使用されるハッシュを発行して、Proofs of Replication を暗号化し、高速プルーフでのバイト選択の疑似乱数ジェネレーターとして使用します。 ハッシュは、データ セットの暗号化にかかる時間の約 1/2 に等しい定期的なカウンターで発行されます。 各レプリケーション ID は同じハッシュを使用し、ハッシュの署名付き結果をバイト選択のシードまたは暗号化キーとして使用する必要があります。 各レプリケータが証明を提供する必要がある期間は、暗号化時間よりも短くする必要があります。 それ以外の場合、レプリケーターは暗号化をストリーミングし、証明ごとに削除できます。 悪意のあるジェネレーターは、このハッシュの前にシーケンスにデータを挿入して、特定のハッシュを生成する可能性があります。 この攻撃については、5.13.2 で詳しく説明しています。

-23-

6.6 Proof Validation

Proof of History ノードは、送信された複製証明の証明を検証することは想定されていません。 レプリケータ ID によって提出された保留中および検証済みの証明の数を追跡することが期待されます。 レプリケータがネットワーク内のバリデータの大多数によってプルーフに署名できる場合、プルーフは検証されることが期待されます。 検証は、p2p ゴシップ ネットワークを介してレプリケータによって収集され、ネットワーク内のバリデータの大多数を含む 1 つのパケットとして送信されます。 このパケットは、Proof of History シーケンスによって生成された特定のハッシュの前にすべての証明を検証し、一度に複数のレプリケーター ID を含めることができます。

6.7 Attacks

-6.7.1 Spam

悪意のあるユーザーは、多数のレプリケーター ID を作成し、ネットワークに不正な証拠をスパム送信する可能性があります。 より迅速な検証を容易にするために、ノードは、検証を要求するときに、暗号化されたデータとマークル ツリー全体をネットワークの残りの部分に提供する必要があります。 このペーパーで設計された複製証明は、追加のスペースを必要としないため、追加の証明の安価な検証を可能にします。 ただし、ID ごとに 1 コアの暗号化時間が消費されます。 レプリケーション ターゲットは、すぐに利用できるコアの最大サイズに設定する必要があります。 最新の GPU には 3500 以上のコアが搭載されています。

-6.7.2 Partial Erasure

レプリケーター ノードは、状態全体を保存することを避けるために、データの一部を部分的に消去しようとする可能性があります。 証拠の数とシードのランダム性により、この攻撃は困難になります。 たとえば、1 テラバイトのデータを格納するユーザーは、1 メガバイトの各ブロックから 1 バイトを消去します。 メガバイトごとに 1 バイトをサンプリングするという単一の証明は、消去されたバイト 1 − (1 − 1/1, 000, 0000)1,000,000 = 0.63 と衝突する可能性があります。 5 回証明した後の尤度は 0.99 です。

-24-

-6.7.3 Collusion with PoH generator

署名付きハッシュは、サンプルのシードに使用されることが期待されています。 レプリケーターが事前に特定のハッシュを選択できる場合、レプリケーターはサンプリングされないすべてのバイトを消去できます。 Proof of History ジェネレーターと共謀しているレプリケーター ID は、ランダムなバイト選択のための事前定義されたハッシュが生成される前に、シーケンスの最後に特定のトランザクションを挿入する可能性があります。 十分な数のコアがあれば、攻撃者はレプリケーターの ID に適したハッシュを生成できます。 この攻撃は、1 つのレプリケーター ID にのみ利益をもたらす可能性があります。 すべての ID は、ECDSA (または同等のもの) で暗号的に署名されたまったく同じハッシュを使用する必要があるため、結果の署名は各レプリケーター ID に対して一意であり、衝突耐性があります。 単一のレプリケーター ID では、わずかな利益しか得られません。

-6.7.4 Denial of Service

レプリケーター ID を追加するコストは、ストレージのコストと同じになると予想されます。 すべてのレプリケーター ID を検証するために追加の計算能力を追加するコストは、レプリケーション ID ごとの CPU または GPU コアのコストに等しいと予想されます。 これにより、多数の有効なレプリケータ ID が作成されるため、ネットワークに対するサービス拒否攻撃の機会が作成されます。 この攻撃を制限するために、ネットワーク用に選択されたコンセンサス プロトコルはレプリケーション ターゲットを選択し、ネットワークでの可用性、帯域幅、地理位置情報などの望ましい特性を満たすレプリケーション証明を与えることができます。

-6.7.5 Tragedy of Commons

PoS 検証者は、何もせずに PoRep を確認するだけで済みます。 経済的インセンティブは、PoS 検証者と PoRep レプリケーション ノードの間でマイニングの支払いを分割するなど、PoS 検証者が機能するように調整する必要があります。 このシナリオをさらに回避するために、PoRep 検証者は、わずかな割合で偽の証明を送信できます。 彼らは、偽のデータを生成した関数を提供することで、証明が偽であることを証明できます。 虚偽の証明を確認した PoS 検証者はすべて切り捨てられます。

-25-

7 System Architecture

-7.1 Components

-7.1.1 Leader, Proof of History generator

リーダーは、選択されたプルーフ オブ ヒストリー ジェネレーターです。 任意のユーザー トランザクションを消費し、システム内で一意のグローバル順序を保証するすべてのトランザクションの履歴シーケンスを出力します。 トランザクションの各バッチの後、リーダーはトランザクションをその順序で実行した結果である状態の署名を出力します。 この署名は、リーダーの ID で署名されています。

-26-

-7.1.2 State

ユーザーのアドレスでインデックス付けされたナイーブ ハッシュ テーブル。 各セルには、完全なユーザー アドレスと、この計算に必要なメモリが含まれています。 たとえば、Transaction テーブルには以下が含まれます。

-7.1.3 Verifier, State Replication

Verifier ノードはブロックチェーンの状態を複製し、ブロックチェーンの状態の高可用性を提供します。 レプリケーション ターゲットはコンセンサス アルゴリズムによって選択され、コンセンサス アルゴリズムのバリデーターは、オフチェーンで定義された基準に基づいて、承認するプルーフ オブ レプリケーション ノードを選択して投票します。 ネットワークは、最小限のプルーフ オブ ステーク ボンド サイズと、ボンドごとに 1 つのレプリケーター ID の要件で構成できます。

-7.1.4 Validators

これらのノードは、検証者からの帯域幅を消費しています。 それらは仮想ノードであり、検証者またはリーダーと同じマシン上で実行することも、このネットワーク用に構成されたコンセンサス アルゴリズムに固有の別のマシン上で実行することもできます。

-27-

-7.2 Network Limits

リーダーは、着信ユーザー パケットを取得し、可能な限り最も効率的な方法でそれらを並べ替え、ダウンストリームの検証者に公開される履歴シーケンスにそれらをシーケンスできることが期待されます。 効率はトランザクションのメモリ アクセス パターンに基づいているため、トランザクションは障害を最小限に抑え、プリフェッチを最大化するように順序付けられます。

-28-

Proof of History シーケンス パケットには、現在のハッシュ、カウンタ、PoH シーケンスに追加されたすべての新しいメッセージのハッシュ、およびすべてのメッセージを処理した後の状態署名が含まれます。 このパケットは、N メッセージがブロードキャストされるごとに 1 回送信されます。 履歴パケットの証明:

1 Gbps のネットワーク接続では、可能なトランザクションの最大数は 1 ギガビット/秒 / 176 バイト = 最大 710k tps です。 イーサネット フレーミングが原因で、1 ～ 4% の損失が予想されます。 ネットワークの目標量を超える予備の容量を使用して、出力をリードソロモン コードでコーディングし、利用可能なダウンストリーム Verifier にストライピングすることで、可用性を高めることができます。

-29-

-7.3 Computational Limits

各トランザクションには、ダイジェスト検証が必要です。 この操作は、トランザクション メッセージ自体以外のメモリを使用せず、独立して並列化できます。 したがって、スループットは、システムで使用可能なコアの数によって制限されると予想されます。 GPU ベースの ECDSA 検証サーバーでは、1 秒あたり 90 万回の操作という実験結果が得られています [9]。

-7.4 Memory Limits

アカウントごとに 32 バイトのエントリを持つ 50% 完全なハッシュテーブルとして状態を単純に実装すると、理論的には 100 億のアカウントが 640 GB に収まります。 このテーブルへの定常状態のランダム アクセスは、1 秒あたり 1.1 ∗ 107 の書き込みまたは読み取りで測定されます。 トランザクションごとに 2 回の読み取りと 2 回の書き込みに基づくと、メモリ スループットは 1 秒あたり 2.75m のトランザクションを処理できます。 これは、アマゾン ウェブ サービスの 1 TB x1.16xlarge インスタンスで測定されました。

-7.5 High Performance Smart Contracts

スマート コントラクトは、トランザクションの一般化された形式です。これらは、各ノードで実行され、状態を変更するプログラムです。この設計は、拡張された Berkeley Packet Filter バイトコードを高速かつ簡単に分析し、JIT バイトコードをスマート コントラクト言語として活用します。その主な利点の 1 つは、ゼロ コストの外部関数インターフェイスです。組み込み関数、つまりプラットフォームに直接実装される関数は、プログラムから呼び出すことができます。組み込み関数を呼び出すと、そのプログラムが中断され、高性能サーバーで組み込み関数がスケジュールされます。組み込み関数はまとめてバッチ処理され、GPU 上で並列に実行されます。上記の例では、2 つの異なるユーザー プログラムが同じ組み込み関数を呼び出しています。各プログラムは、組み込み関数のバッチ実行が完了するまで中断されます。組み込みの例は ECDSA 検証です。これらの呼び出しをバッチ処理して GPU で実行すると、スループットが何千倍も向上します。 BPF バイトコードには、使用しているすべてのメモリに対して適切に定義されたコンテキストがあるため、このトランポリンはネイティブ オペレーティング システムのスレッド コンテキスト スイッチを必要としません。 eBPF バックエンドは 2015 年から LLVM に含まれているため、任意の LLVM フロントエンド言語を使用してスマート コントラクトを記述できます。これは 2015 年から Linux カーネルに組み込まれており、バイトコードの最初の反復は 1992 年から行われています。シングル パスで eBPF の正確性をチェックし、ランタイムとメモリの要件を確認して x86 命令に変換できます。

-30-

References