水平方向のスケーラビリティを実現するための既存のスケーラビリティソリューションの中で、おそらく最も採用されているソリューションがシャーディングです。
シャーディングの基本的な考え方は、グローバルシステムの状態を複数のサブ状態、すなわちシャードに分割し、各シャード内のトランザクションを比較的独立して処理することです。
シャーディング技術を適切に設計することにより、シャードとプロセッサー（ノード）の数が増加するにつれてシステムのキャパシティーを増加させることができます。
言い換えれば、直線的なスケーリングを実現することができます。
シャーディングを適用するにあたり、答えを出しておかなければならない重要な質問がいくつかあります。
グローバルシステムの状態とは何ですか、システムの状態をどのように変更するのですか？
• たとえば、分散されたKey-Value（KV）ストア（BigTable、Cassandraなど）では、システムの状態は任意バイト（Key）から任意バイト（Value）までのマップであり、システムの状態を変更する操作は次のとおりです。作成、読み取り、更新、削除（4つの頭文字をとってCRUD）。
• 別の例として、システムの状態がディレクトリとファイルのセットになっている分散された追加専用ファイルシステム（Googleファイルシステム（GFS）、Hadoop分散ファイルシステム（HDFS）など）であり、実行する操作は以下の2つです。「ディレクトリにおける作成、削除、リスト操作」「ファイルにおけるオープン、追加、読み取り、およびクローズ操作」
すべての操作を正確かつ効率的に処理できるように、システムの状態をシャードに分割する方法
パーティションを作成する方法は、システムのパフォーマンスにとって非常に重要です。パーティションの設計が不適切な場合は、システムのパフォーマンスが低下する可能性があります。パーティションを設計するには、考慮すべきいくつかの重要な側面があります。
• 状態からパーティションへ：システムの状態のどの部分を分割する必要があるのか。システムモデルを単純化するためには、パーティション化について次の2点に留意するべきです。1）サイズが大きすぎて1つのノードに収まらないシステムの状態の部分をパーティション化する。2）1秒間に多くの操作を必要とするシステムの状態の部分はパーティション化するが、単一のマシンでホストするのに容量は十分な小さく、操作も頻繁ではないシステムの状態の部分はパーティション化しない。たとえば、GFS / HDFSの初期のバージョンでは、ファイル内のデータをパーティション化するだけで、ディレクトリのデータサイズは小さく（ファイル内にデータとして格納するのと比較して）、ディレクトリ操作は頻繁ではないため、パーティションは分割されません。
• 操作（トランザクション）セマンティクスを保証する：操作セマンティクスを満たすためにシステムの状態をどのように分割するのか。1つのキーセマンティクスは原子性であり、複数のシャード内の状態を原子的に変更する操作の場合、そのような操作にはシャード間の適切な調整（たとえば、分散されたロックによる）が必要であり、コストがかかる可能性があります。結果として、そのような操作のパフォーマンスはシャーディング技術によってほとんど恩恵を受けることはできません。時にはパフォーマンスが悪化することさえあります。このような問題を回避するために、現代のシャーディングシステムのほとんどは、1つのシャード内で原子バッチ処理をサポートし、上位層のアプリケーションに複雑なマルチシャード原子性の問題を処理させます。
• 平衡負荷/サイズ：システムの状態を分割してa）すべてのシャードへの負荷が統計的に均等に分配され、b）分割されたシステムの状態のサイズもすべてのシャードに統計的に均等に分散されています。これを達成することが線形的スケーリングの重要な前提条件です。つまり、シャードを追加した後でも負荷/サイズが均等に分散されるので、新しいシャードを追加して処理するノードを増やすことでシステム容量を直線的に増やすことができます。分散性はユーザーの操作パターンと非常に関連しており、ユーザーの操作パターンが時間の経過とともに大きく変化すると、負荷が不均一（一時的または永続的にも）になる可能性があることに留意してください。
•Reshard：どのようにシャードを追加するのか。また、新しいノードがどのように新しいシャードになるのか。シャードを追加すると、新しいシャードは古いシャードからのいくつかの状態で構成され、新しいノードに移行されます。再シャーディング中の移行には時間がかかり、既存のサービスが一時停止することがあります。さらに、サポートされている操作のセマンティクスが再シャーディング前後で同じであることを保証する必要もあります。
前述のQuarkChainに関する質問に答える前に、システムモデルと既存のブロックチェーンにおけるシャーディングの難しさをまず紹介しましょう。
既存のブロックチェーンのシステムの状態とトランザクション
我々は、システムの状態が基本的にアドレスとそのアカウントデータによるKey-Valueマップである、Ethereumに類似したアカウントベースのブロックチェーンモデルを考えています。アドレスには2種類あります。
• ユーザーアドレス
• スマートコントラクトアドレス
アカウントデータは以下を含んでいます。
• 残高;
• ノンス;
• コード;
• ストレージ;
ユーザーアドレスのコードとストレージは空です。
CRUD操作のさまざまな組み合わせでサポートされるトランザクションには、次の2種類があります。
1、基本的に2つのアドレスの残高と送信者のノンスを更新し、2つのユーザーアドレス間のトランザクションを転送する。
2、スマートコントラクトトランザクション
• 送信者のノンスを更新する
• 複数のユーザーアドレスの残高を更新する
• callとdelegatecallを使用して残高と複数のスマートコントラクトのストレージを更新する
• 複数のユーザーアドレスとアカウントデータを作成する
• 複数のスマートコントラクトを作成する
ブロックチェーンシャーディングの課題
既存のスケーラビリティソリューションと比較したときに良いことは、ブロックチェーンのシステムの状態は、BigTableやCassandraなどの分散型KVストアとまったく同じであることです。
ただし、トランザクションのセマンティクスは単純なCRUD操作よりもはるかに複雑であるという欠点もあります。スマートコントラクトトランザクションは、システムの状態の任意のKey/ValueペアでCRUD操作を実行する可能性があります。
状態が異なるサブ状態（シャード）に分割されている場合、複数のシャード間の原子性を確保することは非常に困難です（ほとんど不可能です）。どのようにブロックチェーン元帳をパーティション化するかはブロックチェーンシャーディングの基本的な問題です。
さらに、すべてのシャード内のトランザクションを安全に処理するために適切なコンセンサスを構築する必要があるため、分散型の世界ではより多くの課題があります。
新しいシャーディングコンセンサスが新しい攻撃の可能性を生むことにもなるため、スレッドモデルの包括的な分析が行われないと、シャードが簡単に損なわれ、ネットワーク全体が簡単に崩壊する可能性があります。
パーティション化とコンセンサスの課題に加えて、シャーディングのもう1つの共通の問題は、シャード間の相互運用性、つまりクロスシャードトランザクションです。
基本的なロジックはユーザビリティです。ユーザーは、すべてのシャードのスマートコントラクトやその他のユーザーアカウントを含むすべてのリソースにアクセスできる必要があります。
効率的で安全なクロスシャードトランザクションをどのように開発するかが重要なトピックです。
次の記事では、ブロックチェーンシャーディングの課題に対するQuarkChainのソリューションについて説明します。さらに、GoogleのBigTableなどの既存の中央集権型のシステムとQuarkChainを比較し、中央集権型との類似点と相違点を示します。
ウェブサイト
https://www.quarkchain.io
テストネット
https://testnet.quarkchain.io/
英語テレグラム
https://t.me/quarkchainio
日本語テレグラム
https://t.me/QuarkChain_Japan
Twitter
https://twitter.com/Quark_Chain
日本公式Twitter
https://twitter.com/quarkchainjp
Medium
https://medium.com/quarkchain-official
日本語Medium
https://medium.com/@quarkchainjp
Reddit
https://www.reddit.com/r/quarkchainio/
Steemit
https://steemit.com/@quarkchain
日本語Steemit
https://steemit.com/@quarkchainjp
Weibo
https://weibo.com/QuarkChain