ブロックチェーンのスケーラビリティ問題
最初のビットコインのホワイトペーパーがリリースされたのは2008年。その頃からブロックッチェーンの可能性が大きくなるにつれ、私の興奮も増しています。
かつての遠い目標であった非中央集権化されたデジタル通貨が、最終的には今日の業界のメインストリームに進出しています。また私は仮想通貨が持つメリットだけでなく、分散型アプリケーションの可能性にも非常にわくわくしています。そして、ブロックチェーンのユースケースとして金融取引所、予測市場、資産管理プラットフォームはいずれも大きな可能性を秘めています。
ブロックチェーンによって信頼を必要としないそのようなシステム（例えば個人認証、スマートプロパティ、検閲に抵抗するSNS、DAOのような自律分散型システムの構造とガバナンスモデル）はこの上なく興味深いものです。最も破壊的なブロックチェーンのユースケースはおそらく未だに机上の空論となっています。
しかし、このままではこの構想は夢のままで終わってしまうと簡単に予測できます。言い換えると初期の愛好家や起業家がこれらの分散型アプリケーションを構築しようとしていますが、一つの大きなパズルのピースが足りていません。なぜならスケーラビリティ問題がこれらを実現するのを阻んでいるからです。つまり今日のブロックチェーンは、規模を拡大する能力に限界があります。
この問題が未来永劫当てはまるとは言いませんが、少なくとも現在では間違いなく、私たちがブロックチェーン技術で直面している最大の技術的障壁の1つであると主張できます。そして、それは早くもコミュニティの研究者や一般的な暗号学の研究分野の中で活発になっています。
▼目次
- なぜブロックチェーンはスケーラブルでは無いのか？
- ブロックチェーンのスケーリング問題の解決法
- ブロックチェーンのスケーリング解決策＃1：SegWit（Bitcoinのみ）
- ブロックチェーンのスケーリング解決策＃2：2MBブロックサイズ（Bitcoinのみ）
- ブロックチェーンのスケーリング解決策＃3：オフチェーンステートチャネル
- ブロックチェーンのスケーリング解決策＃4：シャーディング（Sharding）
- ブロックチェーンのスケーリング解決策＃5：Plasma
- ブロックチェーンのスケーリング解決策＃6：オフチェーン計算（例えば、TrueBit）
- ブロックチェーンスケール問題への他の解決策の提案
- ブロックチェーンレンタル
- 分散ストレージ
- 結論
なぜブロックチェーンはスケーラブルでは無いのか？
現在、Bitcoin、Ethereum、Ripple、Tendermintなどのすべてのブロックチェーンコンセンサスプロトコルには厳しい制限があります。なぜなら、ネットワークに参加しているすべてのノードがすべてのトランザクションを処理する必要があるからです。ブロックチェーンの非常に大きな特徴を思い出してみてください。そう「分散化」です。これはブロックチェーンネットワーク上のすべての単一ノードが、すべてのトランザクションを処理し、まるっきり同じ台帳のコピーを維持しています。
分散型コンセンサスメカニズムは、誤作動への耐性、強力なセキュリティ保証、政治的中立性、真正性といったいくつかの重要な利点を提供しますが、その代わりにスケーラビリティを犠牲にしています。ブロックチェーンが処理できるトランザクションの数は、ネットワークに参加している単一のノードの数を超えることはできません。実際には、追加のノードごとに対数的にノード間レイテンシが増加するため、ブロックチェーンはネットワークに追加されるノードが増えるほど遅延していきます。
従来のデータベースシステムでは、追加されたトランザクションを処理するために、より多くのサーバー（すなわち、計算能力）を追加することでスケーラビリティ問題を解決してきました。すべてのノードがすべてのトランザクションを処理して検証する必要がある分散型ブロックチェーンの世界では、ネットワークが高速化するためには、すべてのノードにもっと多くの計算を加える必要があります。ネットワーク内のすべてのパブリックノードを制御できないことは、私たちに困難な問題を残します。
その結果、分散型の方法で動作するすべてのパブリックブロックチェーンコンセンサスプロトコルは、低いトランザクションスループットと高い中央集権の度合いとのトレードオフとなってしまいます。言い換えれば、ブロックチェーンのサイズが大きくなると、ブロックチェーンネットワークへの参加に必要とされるストレージ、帯域幅、および計算能力の要件が増加します。ある時点では、いくつかのノードがブロックを処理することが唯一可能であり、集中化のリスクにつながるまでに扱いにくくなります。
そのためブロックチェーンのスケールには、ブロックチェーンプロトコル上で各トランザクションが有効であるというネットワークの信頼を保ちながら、各トランザクションを検証するために必要な参加ノード数を制限するメカニズムが必要です。それは言葉では単純に聞こえるかもしれませんが、技術的に非常に困難です。なぜでしょうか？
- すべてのノードがすべてのトランザクションを検証することを許可されていないため、（個人的に検証していない）ブロックが安全であることを検証するために統計的および省力的な手段を必要とする。
- データの可用性を保証するには、何らかの方法が必要である。言い換えると、たとえブロックがそのブロックを直接検証しないという観点から有効であるとしても、そのブロックのデータを利用不可にすると、ネットワーク内の他のバリデーターがトランザクションを検証したり新しいブロックを生成することができなくなる現在の状態に固執してしまう。 （悪意のある攻撃や停電など、ノードがオフラインになる理由はいくつかあります。）
- トランザクションはスケーラビリティのために、異なるノードが並列処理をする必要があります。しかし、ブロックチェーンの遷移ステートにはいくつかの並列化不可能な（シリアル）パーツがあるため、並列性とユーティリティのバランスをとってブロックチェーン上のステートをどのように遷移させるかには制約があります。
数字で検証してみる
スケーラビリティの数字は実際にどのように見えるのか、見てみましょう。
Ethereumノードの理論上の最大トランザクション処理能力は、1,000トランザクション/秒を超えています[1]。残念ながら、これはEthereumの “gas制限”による実際のスループットではありません。現在各ブロックの平均で約670万gasです[2]。
Source: etherscan.io
Ethereumでは、gas（取引によるマイナーへの報酬）は計算量の尺度であり、各操作には固定量のgasが割り当てられます（たとえば、口座の残高を400gasにする、契約は32,000gas、取引は21,000gasなど）。取引には、送付者が購入しようとするgasの最大量を指定するgas制限フィールドがあります。したがって、各ブロックの「gas制限」は、ブロック内の各取引で指定されたgas制限に基づいて、ブロックに収まる取引の数を決定します。
Bitcoinのブロックサイズの制限がプロトコルにハードコードされているのに対し、Ethereumのgas制限はマイナーによって動的に設定されるという違いがあり、Bitcoinの各ブロックのサイズに対する1MBの制限と多少似ています。
Ethereumのこのgas制限は、1ブロックあたりのネットワークの計算能力にソフトキャップを課しています。現在の670万gas制限と標準トランザクションあたりの現在の平均gas使用量は約21Kです。ブロックごとに約300の標準トランザクションを取得します。現在の平均ブロック時間は20秒で、これは最高でも毎秒15トランザクション（300/20 = 15）に相当します[4]。これは、より複雑な取引では大幅に低くなります（たとえば、スマート契約コールで使用されるメジアンガスは50K [3]、つまり約7トランザクション/秒を意味します）。
Ethereumネットワーク上のトランザクションの数が大幅に増加していることと相まって、これがどのように問題になるかを見ることができます。毎日の取引は、2016年第2四半期から約40Kから240Kに増加し、2017年第2四半期（前年比500％増）となりました。さらに、過去1ヶ月では、1日あたり440,000件以上の取引がピークに達しました！エンベロープ計算をやり直すと、1秒あたり平均5トランザクションになります。
これは非常にまずいです。
同様に、理論的限界である1秒間に4,000トランザクションという制限があるにもかかわらず、Bitcoinは現在、小規模なトランザクションの場合は1秒あたり約7トランザクション、さらに複雑なトランザクションの場合は1秒あたり3つのハード・キャップを持っています。
プライベートブロックチェーンでは、これらの制限が存在しないことに注意してください。プライベートブロックチェーンは、実際には、EthereumまたはBitcoinで1秒あたり1,000トランザクション以上を処理できます。なぜか？プライベートブロックチェーンを実行している場合は、ネットワーク上のすべてのノードが高帯域幅のインターネット接続を備えた高品質のコンピュータであることを保証する能力があります。現在、ブロックチェーンを拡大するには、ネットワークが高速化するために、すべてのノードにもっと多くの計算を加える必要があります。私的に管理されたネットワークはネットワーク内のすべてのノードを制御できるため、これを行うことができます。さらに、プライベートネットワーク上にいるので、参加している各ノードが実際のノードを実行していることを確認するなど、ブロックチェーンからブロックチェーン上で発生するアクションを処理できます。
私はEthereumで新しいプロトコルを設計して実装してきましたが、最初はスケーラビリティの問題の未来に直面しました。また個人的には、研究の量、議論、そして最も重要なことに、この問題を解決するために起こっている実験に魅了されました。残りの部分では、スケーラビリティを解決するためにコミュニティで議論されている提案されたソリューションのいくつかについて説明します。それぞれ独自の強みとトレードオフがあります。
残念ながら、問題の真実はいずれのソリューションもスケーラビリティに対する銀の弾丸などないということです。実際には、それぞれのソリューションは、スケーラビリティを徐々に向上させるのに役立ちます。これらをまとめて初めて、ブロックチェーンのスケーラビリティの将来性について有望な見通しがあります。
この記事の目的は、技術的な複雑さをすべて調べたり、提案された各ソリューションのメリットについて議論することではないことにご注意ください。そうではなく、私の目標は今まで私が気になってきた解決策を元に10,000フィート程度の概要を皆さんに与えることです。読者が興味を持っているなら、私は後の投稿でより具体的な解決法のいくつかを深掘りする事もできるでしょう。この記事では、ブロックチェーンの仕組みを基本的に理解していることを前提としています。 （そうでない場合は、私の最後の投稿「Bitcoin、Ethereum、Blockchain、Tokens、ICOs：誰かが気にする必要があるの？」を再確認することができます。）
ではさらに深掘りしてみましょう。
ブロックチェーンのスケーリング問題の解決法
ブロックチェーンのスケーリングは既知の課題であり、数年間にわたる積極的な研究分野となっています。具体的には、Bitcoinコミュニティで多年にわたる大惨事を経験したことがあるなら、2つのBitcoin特有のスケーリングソリューションとして、SegWitと2MBのブロックサイズの増加についての話を聞いたことがあるでしょう。
Bitcoinブロックチェーンにブロックあたり1MBのハードウェア制限が組み込まれており、ブロックに追加できるトランザクションの数を制限する、Bitcoin特有の問題の解決を目的としています。その結果、Bitcoinはいまやトランザクションの処理と確認において遅延する問題（数時間から数日かかることがあります）に直面しています。同様に、前のセクションで見てきたように、Ethereumも拡張性に限界があります。
ブロックチェーンをどのようにスケールするかを理解するまでは、ユースケースがどれほど高速かつ広範囲に拡大するかに制限されています。では、机上のいくつかのソリューションを見てみましょう。
ブロックチェーンのスケーリング解決策＃1：SegWit（Bitcoinのみ）
すべてのBitcoinトランザクションには次のものが含まれます。
入力
- 送信者の前回の取引詳細
- 送信者がトランザクションを行うために（前のトランザクションに基づいて）適切な金額を持っていることを確認する送信者独自の秘密鍵（scriptSig）
出力
- 送金額
- 受信者の公開アドレス（ScriptPubKey）
これらの要素のうち、デジタル署名（scriptSig）は、サイズの点で最大であり、トランザクションの約60〜70％を占めています。それでも、署名は検証時にのみ必要です。
分離された証人（Segwitとして一般にも知られている）は、取引データの残りから取引署名（証人）を分離（分離）する解決法です。署名は入力内から取り除かれ、トランザクションの終わりに向かって構造に移動されます。
さらに、SegWitを使用すると、証人者はトランザクションデータの新しい「証人者」フィールドに移動し、ブロックサイズの計算方法を変更することができます。ブロックサイズの制限はもはやバイト単位で測定されません。代わりに、ブロックおよびトランザクションには、ノードリソースの要求に対応する「重み」という新しいメトリックが与えられます。具体的には、隔離された証人の各バイトには1の重みが与えられ、ブロック内の各バイトには4の重みが与えられ、そしてブロックの最大許容重みは4,000,000であり、SegWitトランザクションを含むブロックは、データは現在の最大ブロックサイズで許容されるよりも大きくなります。これにより、1MB制限から4MB未満の制限へと効果的に増加し、トランザクションの約70％の増加をもたらします。
SegWitは、トランザクションの可用性やセキュリティの強化などのスケーラビリティ以外の問題も解決します（スケーラビリティに関係しないのでここでは触れません）。
ブロックチェーンのスケーリング解決策＃2：2 MBブロックサイズ（Bitcoinのみ）
Bitcoinコミュニティの一方の側（ユーザー）はSegWitを強くサポートしていますが、コミュニティのもう一方の側（マイナー）は1MBのブロックサイズ制限を2 MBに変更するハードフォークを好みます（ハードフォークなしに1MBの制限を変更することはできません）。基本的な考え方は単純です。ブロックサイズを増やすことで、各ブロックに多くのトランザクションを収めることができ、ネットワークは1秒あたりに多くのトランザクションを処理できます。
このブロックサイズの増加計画は、Bitcoinコミュニティで長年の議論の対象となっており、ブロックのサイズが現在のハードウェア制限値の1 MBに近づき始めた2015年以降、ますます注目を集めています。
ブロックチェーンのスケーリング解決策#3：オフチェーンステートチャネル
ステートチャネルは基本的に、ブロックチェーン上で通常起こりうるブロックチェーン相互作用がブロックチェーンから行われるメカニズムです。これは、参加者のリスクを増加させることなく、かつ安全に暗号化され、コストとスピードを大幅に向上させます。私は個人的には、ステートレベルのチャネルは、より高いレベルの使用をサポートするために、ブロックチェーンテクノロジのスケーリングの重要な部分となると考えています。
ステートチャネルは次のように動作します。
- ブロックチェーン状態の一部は、マルチシグネチャまたはスマートコントラクトの何らかの種類によってロックされます。特定のセットの参加者が完全に同意する場合が、更新する唯一の方法です。
- ブロックチェーン上にトランザクションを発行せずに参加者間でトランザクションを構築し、暗号署名することによって更新を行います。それぞれの新しい更新により、それまでの更新を上書きします。
- 後で、参加者はステートをブロックチェーンに戻します。ブロックチェーンはステートチャネルを閉じ、状態を再び解除します。
ステップ1および3は、ネットワークに公開され、 手数料を払い、確認を待つブロックチェーン操作を含みます。ただし、ステップ2ではブロックチェーンがまったく使用されません。無制限の更新を含めることができ、無期限に開いたままにすることができます。この意味で、ブロックチェーンは純粋に決済層として使用され、最終的な決済のための一連の相互作用の最終取引を処理します。これは、基礎となるブロックチェーンの負担を軽減します。
(プロセス中の任意の時点で、参加者は契約を締結してチャネルをクローズし、決済手順を開始することができます。これにより、参加者がトランザクションを提出できる時間制限が開始され、最高のシーケンス番号を持つトランザクションが処理されます。参加者の1人が辞めようとすると、参加者全員がステートに完全に同意していると仮定して、ブロックチェーンに最新のトランザクションをいつでも公開してステートを確定することができます。)
ステートのチャネルでは取引能力が向上するだけでなく、速度向上と手数料の削減という2つの非常に重要な利点もあります。トランザクションの大部分がオフチェーンで行われているため、オフブロックチェーンで発生した2人の間で更新が処理され、ネットワークによって確認される余分な時間を必要としないので、支払いは即座に処理できます。第2に、決済ステートチャネルを確保するために必要なオンチェーン取引が少なくて済み、取引の大部分は手数料なしでオフチェーンで行われているため、支払い手数料も安くなります。
これにはいくつかの異なる実装があります。たとえば、Lightning Networkは、スマートコントラクトを介してステートチャネルを使用して、参加者のネットワークを介して即時かつスケーラブルな支払いを可能にする分散型ネットワークです。当初、Bitcoin用にLightning Networkが作成されましたが、ブロックチェーン間でのトランザクションも可能になりました。
Raiden Networkは、LightningネットワークのEthereumのアナロジーです。 Raiden Networkはオフ・チェーンステートネットワークを活用し、スケーラブルで即時のトランザクションへとEthereumを拡張します。
ブロックチェーンのスケーリング解決策＃4：シャーディング（Sharding）
ブロックチェーンの世界でのシャーディングは、従来のソフトウェアシステムでのデータベースのシャーディングに似ています。従来のデータベースでは、シャードはデータベース内のデータの水平パーティションで、各シャードは別々のデータベースサーバーインスタンスに格納されます。これは、異なるサーバー間で負荷を分散させるのに役立ちます。
同様に、ブロックチェーンシャーディングでは、ブロックチェーンの全体的な状態が異なるシャードに分かれており、状態の各部分はネットワーク内の異なるノードによって格納されます。
（単一のシャード）
（ブロックチェーンシャーディングのトップレベルの図[6]）
ネットワーク上で発生するトランザクションは、影響を受けるシャードに応じて異なるノードに転送されます。各シャードは、状態のごく一部を処理し、並行して処理します。シャード間で通信するためには、いくつかのメッセージパッシング構造が必要です。
メッセージパッシングを実装する方法はいろいろあります。 Ethereumで取られているアプローチは「レシート」のパラダイムです。シャード内のトランザクションが実行されると、それは自分のローカルシャードの状態を変更することができます。また、後で他のシャードで見ることができる（ただし変更はできない）共有メモリ「レシート」も生成されます。
（Ethereum’s receipt paradigm [1]）
全体として、ブロックチェーンをシャーディングするには、高いセキュリティを維持しながら、すべてのノードがすべてのトランザクションのわずかな部分しか処理しないネットワークを作成する必要があります。
なぜでしょうか？
1つは、ブロックチェーンプロトコルは、ネットワーク内のすべてのノードが互いに信頼しないことを前提としています。それでも、トランザクションは異なるコンピュータで処理されているにもかかわらず、共通の状態に合意する必要があります。各ノードは他のノードを信頼しないので、シャードAのトランザクションを処理するノードが、トランザクションが発生したことをシャードBのトランザクションを処理するノードに単に伝えるだけでは不十分である。むしろ、何らかの形でそれを証明する必要があります。
さらに、シャーディングの目的はすべてのノードがすべてのトランザクションを検証することではないため、この膨大なネットワークを止めようと攻撃する機会を与える事無く、どのノードがどのシャードを安全に検証するかを決定するメカニズムを理解する必要があります。
シャーディングを実装するのが難しいもう一つの理由は、ブロックチェーン上で実行されるトランザクションが、ブロックチェーン内の前の状態のどの部分にも依存する可能性があるためです。さらに、並列化では、競合状態などを緩和するための偽の証明方法が必要になります。
Ethereumでシャーディングがどのように実装されるか、特に、暗号化経済インセンティブを使ってシステムの参加者を不正行為させないようにする方法（この場合、ノードが有効な情報を他のノードに渡していることを確認する方法を私は将来の投稿で探求したいと思っています。
ブロックチェーンのスケーリング解決策＃5：Plasma
Plasmaはごく最近導入され、ブロックチェーン上のスケーラブルな計算に対して提案された、より有望な解決策の1つです。
Plasmaとはルートブロックチェーン（メインイーサリアムブロックチェーン）の上を走る一連のコントラクトの事です。ルートブロックチェーンは、「フロードプルーフ」と呼ばれるものを使用して、プラズマチェーン内の状態の妥当性を強制します。 （注：フロードプルーフは、数学的証明を使用してブロックが無効かどうかをノードが判断できる仕組みです）。
Source: Plasma Whitepaper
ブロックチェーンはツリー階層に編成され、各ブランチは独自のブロックチェーン履歴とマップ縮小可能な計算を持つブロックチェーンとして扱われます。子チェーン(child-chain)を「Plasmaブロックチェーン」と呼びます。それぞれのブロックチェーンはブロック内で新たなチェーンとなります。
Source: Plasma Whitepaper
Plasmaブロックチェーンは、ルートチェーン上のブロックチェーンのコンテンツ（例えば、Ethereum）を開示していません。その代わりに、ブロックヘッダのハッシュだけがルートチェーン上にサブミットされ、ブロックの有効性を判断するのに十分です。ルートチェーン上で詐欺が行われたことが証明された場合、ブロックはロールバックされ、ブロック作成者にはペナルティが課されます。言い換えれば、私たちはビザンチンコンディションによってルートチェーンにデータを提出するだけです。
その結果、ルートブロックチェーンは、子ブロックチェーンからのコミットメントをわずかしか処理しないため、ルートブロックチェーンに渡されるデータ量が減少し、非常に多くの計算が可能になります。
Source: Plasma Whitepaper
さらに、データは、特定の状態を検証したい人に伝播されるだけです。これにより、すべてのノードがすべてのチェーンを監視する必要がなくなるため、契約の実行がよりスケーラブルになります。代わりに、彼らは正しい行動を強制し、不正行為を罰するために経済的に影響を受けるものだけを見ます。詐欺防止は、任意の当事者が無効なブロックを実施し、すべての状態遷移が有効であることを保証することを可能にします。
さらに、特定のチェーンに対する攻撃がある場合、参加者は破損した子チェーンから迅速かつ安価に大量退出を行うことができます。
Source: Plasma Whitepaper
Source: Plasma Whitepaper
Plasmaは、連鎖していないトランザクションを処理するステートチャネルの実装（例えば、Lightning Network）と同様に見えるかもしれません。主な違いは、Plasmaではすべての参加者が状態を更新するためにオンラインである必要はないということです。さらに、参加者はトランザクションに参加して確認するためにルートブロックチェーンにデータを提出する必要もありません。Plasmaについて素敵な点は、Lightning Networkのようなステートチャネルタイプのソリューションが、Plasmaの上での迅速な財政支払い/契約の主要なインターフェースレイヤーになるということです。Plasmaは最小限のルートチェーン状態コミットメントで状態を更新します。
Source: Plasma Whitepaper
このソリューションには複雑な詳細がたくさんあり、今後のポストを掘り下げたいと思っています。
ブロックチェーンのスケーリング解決策6：オフチェーン計算（例えば、TrueBit）
TrueBitは、オフチェーン計算を使用してEthereumスマートコントラクト間でスケーラブルなトランザクションを可能にするソリューションの例です。基本的には、ステートチャネルと同様に、TrueBitはブロックチェーン外のレイヤーを使用して重い作業を行います。換言すれば、オフチェーンで計算を実行するシステムは、そうでなければチェーン上で実行するのに非常に高価になります。それは以下のように動作します。
参加しているすべてのノードの代わりに、ネットワーク上の特定の参加者（ソルバー）は、スマートコントラクトによる計算を実行し、問題を解決するためにデポジットを提出します。ソルバーが正しければ、ソルバーに報酬が与えられ、デポジットが返されます。そうでない場合、つまりソルバーが不正行為をした場合、預金は失われ、「検証ゲーム」を使用してブロックチェーン上で紛争が解決されます。
検証ゲームは次のようになります。ソルバーの作業をブロックチェーンからチェックする「検証者」というネットワークの参加者がいます。 検証者がエラーを通知しない場合、システムは解決策を受け入れます。検証者がソルバーの解の正確性に異議を唱えた場合、ゲームは一連のラウンドで進行し、ブロックチェーンが紛争を解決します。ここでは、計算能力の限られたネットワークの「ジャッジ」がすべての紛争を裁決します。システムは、実際に必要となるブロックチェーンからの作業に比べ、ブロックチェーン上の審査員の作業のほうが小さいことを保証するように構築されています。
このゲームの最後に、ソルバーが実際に不正をしていた場合、それが発見され処罰されます。そうでない場合、チャレンジャーは誤ったアラームによって消費されたリソースを支払うことになります。
STrueBitで提案されたオフチェーン計算の非常に概略的な図
最後に、実際にバグが存在し、バグを見つけようと努力する価値があることを検証者に確信させるために、TrueBitはソルバーに間違ったソリューションを提出することがあります。間違った解決策を提出し、正しい解決策を提出して罰せられました。これにより、トランザクションの検証者のために常にシステムに報酬が与えられます。
要約すると、このプロトコルは誰でもコンピューティングタスクを投稿することができ、他の誰かがそれを完了するための報酬を受け取ることができ、システムのインセンティブ構造は返されたソリューションの正確性を保証する。計算と検証プロセスをEthereumブロックチェーンから別のプロトコルに移すことにより、Ethereumのgas制限に制約されることなく、多数の計算に拡張することができます。
ブロックチェーンスケール問題への他の解決策の提案
私が興味深いと思う暗号コミュニティに関して、他のいくつかの提案があります。ソリューションはスケーラビリティの解決を直接目的としたものではありませんが、スケーラビリティの問題に間接的に対処するのに役立ちます。
Proof of stake
PoWと同様に、Proof-of-Stakeは、二重支払いを防止することによってブロックチェーンのセキュリティを支える合意形成メカニズムです。
伝統的な実績ベースのブロックチェーンでは、マイナーは、報酬と引き換えに、計算集約型の実績のある数学的パズルを解決するために競争することによって、ブロックチェーンデータの完全性を維持します。この点で、CPUパワーでトランザクションを検証するのに役立ちます。また、CPUパワーが増えるほど、ネットワークに影響を及ぼす能力が比例して大きくなります。Proof-of-Stakeでは、ステークホルダーは、計算力の代わりに「ドル」（Ethereumの場合、ether）で投票します。
これは正確にはどのように機能するのでしょうか？
ブロックチェーンは、バリデーターの検証に参加するためにセキュリティデポジット（「ボンディング」と呼ばれます）を配置する必要がある「バリデータ」と呼ばれる特定の検証ノードを追跡します。検証者は、プロトコルが暗号で証明可能な方法で「無効」とみなすものを生成した場合、それらの預金とコンセンサスプロセスに参加する特権が失われます。彼らが正しく賭けた場合、彼らは取引手数料とともに預金を返済します。
効果的に、バリデーターは最終的なコンセンサスに賭けてお金を稼ぎ、反対にのコンセンサスに賭けてお金を失うようになります。それぞれのマイナーがブロックを受け入れるハッシュ・パワーで賭けている作業実績を類推することができます。彼らがシステムを不正行為するために間違って賭けた場合、彼らが生産するブロックは孤立して、彼らはお金を失う原因になります。
Proof-of-stakeコンセンサスアルゴリズムにはいくつかの種類がありますが、この記事では取り上げないバリデーターに報酬を割り当てるためのさまざまな仕組みがあります。
Proof-of-Stakeはスケーラビリティにどのように役立つのでしょうか？
1つの例はシャーディングです。実績のあるシャーディングは、安全に行うのは難しいです。シャーディングでは、多くのノード間で検証責任を分割し、すべてのノードがすべてを処理する必要がないことを思い出してください。しかし、作業実績は完全に匿名で実装されています。これは、単一のシャードがマイナーのハッシュパワーのほんの一部で保護されていても、攻撃者は自分のハッシュパワーのすべてをこのシャードを攻撃する方向に向けることができ、ネットワークを破壊することができます。たとえば、AとBの2つのシャードがあるとします。Aはハッシュパワーの90％、Bは10％のシャードを持っています。 Aは、（総攻撃の51％のおかげで）総ハッシュパワーのわずか5.1％でBを攻撃することができます。
これは、検証者が既知のアイデンティティ（すなわち、Ethereumアドレス）を持つように設計されているため、Ethereumの現在のステークの提案で変更されます。そのアイデンティティを知ることで、シャード上の任意の一連のトランザクションを処理するためにバリデーターセット全体からノードのセットをランダムに選択することにより、このタイプの標的攻撃を解決することができ、攻撃者が特定のシャードを特に対象とすることは不可能になります。
もう一つの理由は、Proof-of-Stakeでブロックを検証するマイナーに新しいトークンを発行する作業実績とは異なり、バリデーターが取引手数料のみを獲得するためです。結果として、検証サーバーが負荷を処理できるならば、ブロック “gas制限”を増やすインセンティブがあります（それにより、それぞれのブロックでより多くのトランザクションを合わせながらより多くの手数料を得ることができます）。注意点として、バリデーターは、他のバリデーターで許容されるポイントまでgasの限界を引き上げるだけです。そうしないと、他のより遅いバリデーターの同期が外れてしまいます。
ブロックチェーンレンタル
別のEthereum特有の解決策は、 “ブロックチェーンレンタル” [5]です。ブロックチェーンレンタルは、トランザクション時間を短縮するために、ネットワークに格納されているデータ量を削減することを目的としたソリューションです。 Ethereumを使用すると、ユーザーは計算ステップ、メモリ、トランザクションログ、および永続ストレージを支払うことになります。これらのほとんどはリソースが適切なインセンティブを持って支払われていますが、ここではストレージはそうではないという主張があります。
現在のシステムでは、ユーザーはストレージのバイト分だけを支払う事になっています。しかし実際には、ストレージは永久にブロックに格納されるため、ストレージは他のリソースとは異なるという主張をすることができます。代わりに、ブロックチェーンレンタルは、ストレージのコストを「バイト×時間」に設定することを提案しています。この方法では、ネットワークを軽く保ち、トランザクション時間を短縮するためのプロトコルに組み込まれたインセンティブがあります。
分散ストレージ
ネットワークを軽く保つためのもう1つのソリューションは、Swarmなどの分散ストレージサービスを使用しています。 SwarmはEthereum用のピアツーピアファイル共有プロトコルで、Ethereumブロックチェーンに接続されているswarmノードのメインブロックチェーンからアプリケーションコードとデータを格納し、後でブロックチェーン上でこのデータを交換することができます。ブロックチェーンにすべてを格納するノードの代わりに、ローカルでより頻繁に要求されるデータのみを格納し、Swarmを介して他のデータを「クラウド」に残します。
Swarmを使用した分散ストレージの非常に概略的な図
もっと多くありますが、簡潔さを保つ為に（この投稿はかなり長くなっています！）、今はこのままにしておきましょう 🙂
結論
このトピックは非常に複雑ですが、この投稿がブロックスケーラビリティでスケーラビリティがなぜ重要なのか、それがどのように解決されるのかを大まかに説明するのに役立つことを願っています。
決してこれは包括的なリストではありません。研究が進展するにつれてこのトピックをフォローアップしようと思います。個人的には、スケーラビリティに対する銀の弾丸の答えがあることを疑っています…しかし、いくつかのアプローチの組み合わせが最終的にこの問題を解決し、ブロックチェーンアプリケーションが飛躍が可能になると信じています。
また、躊躇せずに私がこれまでにしてきた間違いを訂正してください。もしくはコメントで（健全な）議論を始めましょう。
Happy blockchaining! 😉
＊＊＊＊＊＊＊
この投稿はHackenoonに投稿されたオリジナル記事「Blockchain don’t scale. Not today, at least. But there’s hope.」を投稿者 Preethi Kasireddyさんの許可を得て翻訳しています。
| この記事を書いた人 Preethi Kasireddy: medium （翻訳：石黒一明 / ブロックチェーンエンジニア / 株式会社クーガー） |
