ユーザー数やネットワークのノード数の増加に伴い、ビットコインやイーサリアムにおいてブロックチェーンのスケーラビリティ問題が深刻となってきています。
このスケーラビリティ問題に対処するためにビットコインやイーサリアムはさまざまな解決策が提案されています。
その中でも大きな影響を与えると考えられているのが、イーサリアムで開発が進められているシャーディング(Sharding)です。そこで、当記事ではイーサリアムにおけるシャーディングの仕組みや現状の課題点について解説していきます。
イーサリアムのスケーラビリティ問題
ブロックチェーンを基盤としたネットワークにおけるスケーラビリティ問題にはユーザーの増加とノードの増加という2つの側面があります。
ユーザーの増加は単純にトランザクションが増えることで、ブロックチェーンがそれを処理しきれなくなり送金遅延や手数料増加が起こります。
また、イーサリアムは分散型アプリケーションプラットフォームとして機能することを考えるとノード数の増加に対するスケーラビリティも十分に対処していかなければなりません。なぜなら、スマートコントラクトの処理には通常の送金処理よりもコストがかかるので、ノード数が増えるとそれだけネットワーク全体での処理能力が低下してしまうからです。
このようなスケーラビリティ問題の考え方については以下の記事で詳しくお伝えしていますので参考にしてください。
参考：【まとめ】ブロックチェーンのスケーラビリティ問題に対する１１の解決策
イーサリアムのノード数20,000以上存在していて、ビットコインよりも圧倒的に多いのです。ノード数が多いということはより分散化されているということですが、トランザクションの処理が遅延したり特定のノードに集中化が起きてしまうという負の側面もあります。
要するに、イーサリアムではネットワーク全体でトランザクションの処理能力を高めていけるような施策が必須であり、その方法のひとつとしてシャーディングの開発が進められているのです。
シャーディングとは
まず前提知識として『トランザクションレベルで理解する。イーサリアムの具体的な仕組みを解説』で解説しているように、イーサリアムのブロックチェーンには「状態(State)」という概念があります。
下図のように新たなトランザクションが実行してブロックチェーン内のデータが書き換えられるごとに状態は変化していきます。
そして、このような状態変化を起こすために必要なトランザクションはノードにより検証される必要があります。現在、イーサリアムでは全てのトランザクションに対して、ネットワークを構成するそれぞれのノードが検証作業を行なっています。
例えば、100のトランザクションが作成されたらネットワークを構成する1000のノードは、理論上それぞれ100回の検証作業を行うことになります。
シャーディングは、このトランザクションの検証作業をノード群ごとに役割分担し、検証作業を並列化していくことを目指しているのです。つまり、1000のノードが50ノードずつの20グループに分かれて、それぞれのグループが分担分のトランザクションを検証することになります。この場合、1つのグループ（50ノード）は5つ(=100/20)のトランザクションを検証するだけです。
この例で考えると、1つのノードが100回の検証作業を行わなくてはいけなかったのに対し、シャーディングの導入により5回の検証作業で済むようになったことになります。そして、グループごとに同時進行でトランザクションを処理していくことができます。
シャーディング(Sharding)とは元々データベースシステムの用語で、データベースを水平方向に分割することを意味しています。イーサリアムにおいても同様で、ブロックチェーンの「状態」が分割されて複数のシャード(Shard)が存在することになります。
それぞれのシャードは上述のように異なるノード群によって検証されブロックに追加されていくのです。シャードごとに並列してトランザクションの処理を行うことができるので大幅なパフォーマンス向上が見込めることになります。
それでは具体的にシャーディングがイーサリアム上でどのように機能していくのか見ていきましょう。
シャーディングの仕組み
シャード内のトランザクショングループ
シャードとは、ブロックチェーンにおける異なった「状態」ごとのかたまりでした。それぞれのシャードでは固有の状態が進行していて、ブロックチェーン全体で見ると複数の状態が並列化して進行していることになります。
それぞれのシャードには下図のようなトランザクショングループが存在します。
トランザクショングループはヘッダーとボディーに分かれ、ヘッダーにはシャードの情報と取引承認の署名(signature)が入っています。
シャードデータには、シャードIDやシャード間をつなぐためのレシート(Receipt)のマークル木、そして取引が適用される前後の状態のマークル木などが含まれています。（レシートとはトランザクションのログ情報です）
また、ランダムに選ばれたシャード内の取引の承認者の署名がヘッダー内右側の取引承認のsigに含まれます。ボディーにはシャード内のすべての取引IDが入っています。
ブロックチェーンレベルでのシャード
ブロックチェーンレベルでは、通常のブロックに加え状態(state)のマークル木ルートと上述したトランザクショングループのマークル木ルートが加わっています。
トランザクショングループで正しい取引が行われ、かつ完全に承認された場合のみそのトランザクショングループは有効化されるようになっています。
それぞれのブロックに状態のマークル木ルート(State root)とトランザクショングループのマークル木ルート(Transaction group root)が加わっただけでブロックチェーンの枠組みは変わっていません。
以上がイーサリアムにおけるシャーディングの概要とその仕組みです。しかし、このようなシャーディングを導入するためには安全なシャード間の通信を確保する必要があります。なぜなら、どのシャードがどのトランザクションを処理しているのか互いにコミュニケーションを取る必要があるがあるからです。
シャード間のコミュニケーション
それぞれのシャードで、それぞれのシャード内に含まれる取引の計算と承認が行われてもシャード間でのデータのやり取りができないとネットワークとして機能しません。
ここではどのようにしてシャード間でコミュニケーションを取るのか見ていきましょう。このコミュニケーションはレシート(Receipt)のやり取りによって行われます。
トランザクショングループの項で軽く触れましたが、それぞれのシャードの中にはレシートというログ情報が含まれています。
このレシートは、それぞれの取引に基いて作られ他のシャードから見ることができますが改ざんすることができません。レシートをシャード間で取引データとしてやり取りすることでコミュニケーションを行なっていくという仕組みです。
まとめると、シャーディングとはノードによるトランザクション検証の役割分担であると言えます。全てのノードが全てのトランザクション検証を行なっていたのに対し、シャーディングを実装することで個々のノードは自分の担当分のみの取引を検証すればOKということになります。
これにより個々のノードが検証するトランザクション数は減り、シャードごとに検証を同時に並行して行うことができるのでネットワーク全体の処理能力を高め、スケーラビリティ問題の解決に有効であると考えられます。
また、セキュリティ的な理由によりシャーディングはProof of Stake(PoS、プルーフ・オブ・ステーク）を実装した後に導入するべきだと考えられています。
シャーディングにPoSが必要な理由
シャーディングは、全てのノードが全てのトランザクションの検証作業を行うのではなく、複数のノード群でトランザクションの検証作業を役割分担していくことでした。つまり、それぞれのシャードごとに状態が異なり独立して成り立っています。
なので、少ないマイナーのハッシュパワーによってセキュリティが維持されているシャードに対して、攻撃が簡単になってしまうという問題があります。
例えば、シャードAとシャードBをという2つのシャードに分かれて検証作業を行っているとします。そして、シャードAが全体の10％のハッシュパワーを持っていて、シャードBが90％のハッシュパワーを持っている場合、シャードAに対してはたった5.1％のハッシュパワーで51％攻撃が可能になってしまいます。
（参考：ブロックチェーンの安全性を脅かす「51％攻撃」の仕組みと実態）
つまり、プルーフ・オブ・ワークではセキュリティを維持しながら、マイナーがどのシャードで独立的に働くかデザインすることがとても難しいのです。（シャードごとにブロックチェーンが分かれているのではなく、ただ「状態」が異なるだけであることに注意してください）
しかし、プルーフ・オブ・ステークを導入していれば以上のような攻撃は簡単に防ぐことができます。（プルーフ・オブ・ステークはコインの賭け金（デポジット）に応じてブロックを生成できるコンセンサスアルゴリズムです。）
イーサリアムで考えられているPoSのプロトコルでは、賭け金をデポジットしているバリデーター群をそれぞれのシャードごとに割り当てるだけで良いからです。
PoWではノードの計算を終えたマイナーがブロックを生成するので、実際にマイニングが成功するまでは匿名化されている状態と言えます。そして、マイナーは自分の意思でどのシャードで働くか選択することができてしまいます。
一方、PoSではあらかじめ賭け金をデポジットしている有効なバリデーター群が分かっているので、それらをシャードの規模に合わせて適切に担当を割り当てていくことができるのです。つまり、バリデーターは自分の意思でシャードを選択することができず、ただアルゴリズムに従うことになります。
このようにシャーディングの前にあらかじめプルーフ・オブ・ステークを導入していればセキュリティを維持しながら実装することができるので、シャーディングはPoSが前提の技術であると考えられているのです。
現在、イーサリアムではCasperというPoWとPoSの組み合わせたコンセンサスアルゴリズムの導入が進められています。
参考：【イーサリアム】CasperのFriendly Finality Gadget(FFG)を分かりやすく解説
