この記事は、「分散化について考察する(Thinking Decentralized)」と題したシリーズからの一編です。この例では、メインネット内のトランザクションのみ、もしくはメインネットに接続する単一のサイドチェーンの使用のみに基づく、モノリシックアプリケーション構造を作成しない方が良い理由についてご紹介します。それに代わり、インターチェーンメッセージングや類似のメカニズムを介してパブリックメインネットに接続する複数の弾性サイドチェーンを活用する方法が、より優れた、柔軟なソリューションとなる理由についてもご紹介します。

サイドチェーンの定義

サイドチェーンは、メインのブロックチェーンネットワークと接続するブロックチェーンネットワークで、多くの場合はイーサリアムメインネットの様に公共ネットワークです。サイドチェーンは、トランザクションブロックからなるチェーンを介してトランザクションを保存するという点で、同様の基本理念を採っていますが、異なるコンセンサスアルゴリズムやバリデーション方法を使用している場合があります。また、メインネットにはみられない追加機能を含むこともあります。このような機能としては、追加のストレージオプション、許可されたアクセス、ゼロ知識証明、代替料金メカニズムなどが挙げられます。

ブロックチェーンソリューションの設計・作成において複数の弾性サイドチェーンの使用が推奨される点は、他の最新のアプリケーション開発状況におけるアーキテクチャパターンを鑑みるに、それほど驚くべきことではありません。ここでは、注目すべきいくつかのパターンをお示しします。

データベースからの教訓

データベースでの作業からの教訓は、アプリケーション内のすべてのデータに対して単一のデータベースを使用することは最も賢明な方法ではないことを示しています。テストアプリケーションやテストサービスでは問題なく動作したとしても、システムにトランザクションやデータの負荷が発生した場合、データストレージとアクセス方法を調整することは、システムの構築とスケーリングを正常に行うために必要なステップです。

ほぼすべてのアプリケーションには、ユーザーデータ、トランザクションデータ、ログイン資格情報、メディアファイル、ユーザー入力、関係性情報、分析データ、メディアファイル、その他の種類・形式の多数のデータが入っています。これらあらゆる形式のデータに対して単一データベースを使用することは、現在のテクノロジーの状態を考えると、単に実用的でないだけでなく、ほぼ不可能だといえるでしょう。単一データベースを介してすべてのアプリクエリを実行すると、そのデータベースがどんなにシェーティングやインデックス化されていたとしても、すぐにデータベースが屈服してしまい、その後の開発が非常に難しくなります。

その代わり、ほとんどの設計者は、さまざまなデータ形式やデータを元に稼働するトランザクションに合わせてデータストレージを構成し、最適化しています。例えば、ユーザーデータは迅速な読み取りアクセスのために水平にシェーディングされたNoSQLデータベースに保管され、トランザクションデータは迅速なクエリ実行のために関係性データと密接にインデックス化され、メディアファイルはブロックストレージ内に、分析データは時系列データ内に、関係性や関連性についてはGraph DB内に格納する、といったことです。各データベースは通常、読み取り/書き込みロード、データのサイズと形式、データスキーム、コミット時間とレイテンシ要件、クエリの種類、安全上のニーズ、その他多数ののパラメーターについて最適化されます。また、格納するデータの量と実行されるクエリの数と種類の両方の増加に対処できるよう、注意が必要です。

データサイエンスとCAP定理

CAP定理は、データサイエンス分野で使われる用語で、分散型データ保管は、一貫性、可用性、分断耐性に関する3つの保証のうち、2つを超えて同時に提供できないと規定しています。そのため、アプリケーションエンジニアやデータベースエンジニアは、特定のデータストレージタイプを選択する際に、特定のアプリの機能やサービスにとって最も重要な保証を最適化するために、トレードオフを行う必要のある場合が出てきます。

ほとんどのアプリケーション開発者や設計者にとって、データタイプとデータ使用量に合わせて異なるデータベースを使用することは、通常の作業範囲内です。

A screenshot of a cell phone

Description automatically generated
ストレージの種類と特性

マイクロサービスからの教訓

この認識は、イベントやトランザクションの処理に関しても同様に当てはまるようになってきています。単一の実行ファイルにコンパイルもしくはリンクされたモノリシックアプリケーションで、すべてのユーザーアクションやサイドイベントを処理するのではなく、アプリ開発者は、一般に一連のサービスとしてアプリケーションを開発しています。これらのサービスはそれぞれが互いに機能的に分離されており、APIやリモートプロシージャコール(RPC)を介して相互接続されるか、メッセージキュー、データベース、サーバーレス関数呼び出し、その他メカニズムを使用してアプリケーションワークフローを調整しています。

一見、マイクロサービスにより複雑化しているように見られますが、それとは正反対の結果を生みます。アプリケーションを一連のマイクロサービスとして開発することで、チームの動きが迅速化するだけでなく、アプリケーションの拡張や新機能の追加が容易になります。

モノリシックアプリケーションでは、コードベースが常に変更、更新されることとなり、コード–テスト間の矛盾と常に戦い続けなければなりません。必要となるテストの量と予期せぬ結果をもたらすリスクが増加するため、ちょうど良いタイミングで更新をリリースすることは難しくなります。マイクロサービスを使用することで、変更をより簡単に分離でき、開発の迅速化、リスクの軽減、より頻繁な更新サイクルが実現します。

A close up of a logo

Description automatically generated
モノリシックとマイクロサービスアーキテクチャの比較

そしてブロックチェーンへ

ブロックチェーンネットワークを使用して分散型アプリケーションを開発する場合、懸念事項の分離に関する同様原則の多くが適用されます。単一のブロックチェーンネットワークやサイドチェーン(例えばイーサリアムのメインネットなど)を使用するのではなく、パブリックメインネットに接続する複数のサイドチェーンを使用する方が理にかなっています。

多くの人は、レイヤ1のスケーリングはレイヤ2ソリューションの必要性を排除すると言うでしょうが、それはスケーラブルなdAppを構築している大多数の人々の見解は異なります。2019年10月に行われたScalar Capital Summitで、ダーマのCEOで共同創設者でもあるナダフ・ホランダーは、スケーラブルなレイヤー1が開始しても、継続してレイヤ2ソリューションが必要となると語りました

「多くの次世代ブロックチェーンの主なセールスポイントはスケーラビリティ、それもレイヤ1スケーラビリティにありますが、それら全ては、スケーリングする方法として、様々な形でシャーディングを行っているようです。シャーディングの難しい点は、DeFiスケーラビリティにおける完全な解決策とはならないということです。ここではあまり技術的な詳細には触れませんが、ETH2のようなシステムであっても、頻繁に取引されているDeFiプロトコルでは、これらの機能をスケーラブルにするために非常に洗練されたレイヤ2システムを作成する必要が高くなります。それらすべてで、レイヤ1スケーラビリティの利点は重要ですが、DeFiプロトコルとしての問題を完全に解決するものではありません。」

– ナダフ・ホランダー、ダーマCEO・共同創設者

レイヤ2ソリューション(つまりは弾性サイドチェーン)を使用することは、あらゆる種類のスケーラブルな分散型ソリューションを構築する上で、ほとんど必要不可欠となります。分散型アプリケーションであっても依然としてアプリケーションであるため、ユーザーイベント、処理ニーズ、データアクセス方法が同様である場合は、集中型アプリケーションとして処理を行います。分散型の環境で作業を行う開発者であっても、ストレージ、機能開発、データタイプ、トランザクションやコミットのレイテンシなどについて、依然として関心を持つ必要があります。

ブロックチェーンの使用により課される複雑性(コミット時間、トランザクション料金、ストレージや処理における制約、スマートコントラクト永続性など)が、この方程式にさらなる懸念を追加します。モノリシックな考え方で作業するのではなく、複数のサイドチェーンを使用する分別が大切です。

複数のサイドチェーンを使用する理由

開発におけるアジリティの向上

弾性サイドチェーンを使用すると、分散型アプリケーションやプロトコルの開発が容易になり、それらの配備もより迅速に行えます。サイドチェーンを使用することで、処理とデータに関する問題を分離できるだけでなく、開発チームのダイナミクスも助けます。集中型アプリ内でモノリシックアプリの作業を行うと、同じコードベースやデータベースとやり取りする場合にチーム内で摩擦が生じるように、単一のメインネットまたはサイドチェーンを介してすべてのトランザクションを実行すると、あるアクションが別のアクションの処理を効果的に妨げるような状況が生じてしまう可能性があります。

協調して開発を行う場合に必要なコミュニケーション経路やチーム内の調整は、開発に費やす時間を無駄にするだけでなく、開発スピードを機能チームとしてなし得る最も遅いペースにまで落としてしまう傾向があります。効果的なチェーン間メッセージングソリューションを活用して状態管理やアクションの同期を行いつつ、複数のサイドチェーンを使用することで、開発における摩擦が軽減され、ローンチがより迅速に行えます。

新規dAppと既存dApp

弾性サイドチェーンを使用すると、新規dAppと既存dAppの両方を助けられることも特筆すべき点です。

新規dAppsの場合、当初からサイドチェーンを使用することは非常に理にかなっています。その理由は、開発者が開発時間に大きな影響(もしあるなら)を与えることなく、開始からスケールするシステムを構築することができるからです。サイドチェーンの使用は、GAS手数料とコミット時間を削減できるため、ゲームプレイやdAppの経済性を高めることができます。

既存dAppの場合、新機能を追加したり、既存機能をメインネットから弾性サイドチェーンに移行したりすることは、容易に実行可能なだけでなく、リスクも低下できます(サイドチェーンを正しく設定し、スマートコントラクトを正しく実行する点を除き)。サイドチェーンに移行する理由として、トランザクションのスループットを向上させる、GAS手数料を削減する、より複雑なスマートコントラクトを可能にする、より大きなサイドチェーンストレージを利用するなどが挙げられます。特定のトランザクションセットやデータタイプのためにサイドチェーンを作成することで、開発者はその機能のチェーンサイズを変更して最適化できます。

A close up of a map

Description automatically generated
弾性サイドチェーンにより、開発のアジリティが向上

パフォーマンスの向上

トランザクションのコミットメント時間と応答のレイテンシは、いかなるアプリケーションにおいても重大な要素となりますが、分散型アプリケーションではなおさらです。集中型アプリケーションのコミット時間は、ミリ秒またはマイクロ秒単位で行われます。分散型アプリケーションのコミット時間は、分単位(もしくは、ネットワーク負荷とGAS手数料によっては時間単位)で行われる場合もあります。レイヤ1をスケーリングするソリューションは役に立ちますが、最も単純なdApp以外のアプリケーションにおける、トランザクションタイプとコミット時間をサポートできはしないでしょう。

弾性サイドチェーンを使用すると、トランザクションタイプに合わせて最適化することができます。ある種のイベントやトランザクションタイプは、資産の完全性の面から重要となる場合があります。その他のタイプも値付けやゲームプレイの面からは重要かもしれませんが、上記に比べてそれほど重要ではありません。後者の例としては、分散型メディアストリーミングアプリ内のソーシャルアクションが挙げられます(いいね、フォロー、共有、バックグランドイベントとして処理されるその他のアクション、コミットの成功を楽観視するものなど)。

したがって、イベントタイプごとにトランザクションのコミットメント時間が異なります。資産の送金は優先順位が高いため、コミット時間を短縮できる最適化が必須となります(ひとつまたは複数のメインネットとの最適化メッセージングを含む)。アプリ内アクションもまた、高いパフォーマンスニーズを有している場合もありますが、データとトランザクションタイプに合わせて調整したサイドチェーン内で全てを実行する場合もあります。

A screenshot of a cell phone

Description automatically generated

ただし、すべてのサイドチェーンが同じという訳ではない点に注意してください。トランザクションの有効性とdAppの整合性を確保するためには、パフォーマンスニーズを満たすだけでなく、適切なコンセンサスメカニズムとセキュリティ対策を備えた検証モデルを含んだサイドチェーンを使用する必要があります。

ネットワーク経済の向上

集中型アプリケーションと分散型アプリケーションのその他の大きな違いは、主にトランザクションのコストに関するものです。集中型アプリケーションのトランザクションコストは、非常に安価です。確かに処理コストとストレージコストは生じますが、これらはトランザクション毎にかかり、その費用はごく僅かです。この低コストは、パブリックブロックチェーンネットワークを使用してトランザクションを完成させるために必要な、GAS手数料の額と直接比較できます。例えば、イーサリアムのGAS手数料は、単一のトランザクションで数セントからその5-10倍の範囲に収まります。

これらの手数料は、システム内の全トランザクションに対してメインネットを使用することを困難にさせます。したがって、サイドチェーンは、エンドステートトランザクションからインターステートトランザクションを切り離すのに最適なメカニズムを提供することで、運用コストを削減し、アプリケーションやプロトコルについての経済性を向上させます。言い換えれば、弾性サイドチェーンに移行することで、アプリケーションのユーザーのためにGAS手数料を大幅に削減したり、さらには撤廃したりすることが可能になります。例えば資産の作成や送金など、主要なステート変更はメインネットに委ねなければならない場合もまだありますが、その他のほぼ全てのトランザクションについてはサイドチェーンで実行できます。

Picture 7

ストレージの改善

集中型アプリケーションの場合と同様に、分散型アプリケーションにおいても、データの種類や形式、インデックス方法や読み取り/書き込みの負荷は様々です。これらの違いが、メインネットに書き込むべき情報、サイドチェーンストレージに格納できる情報、分散型(もしくは集中管理型) ストレージに格納できる情報を決定します。メインネットは、仮想通貨、トークン、その他のデジタル資産の所有権や、送金、配置、その他ステート変更を記録するために使用されます。これらの資産のその他の使用やステート変更は、適切なインターチェーンメッセージングやアセットロックメカニズムを使用することで、サイドチェーンに反映することができます。

例としては、分散型カードゲームが挙げられます。ベットはメインネット上で確立されるとしても(各プレーヤーが資金を投入して)、カードの扱いや移動はサイドチェーン上に記録され、各カードプレイは各ユーザーによって署名され、他のプレイヤーに送信されます。メインネットは、エンドゲーム時やベットのペイオフ決済時にのみ、織り込まれることとなります。

別の例としては、分散型メディアストリーミングアプリケーションなどが挙げられます。例えば、分散型音楽サービスや分散型YouTubeプラットフォームなどです。これらのシステムタイプのデータには、ファイルに関連付けられたメディアファイルとメタデータ(タイトル、アーティスト、説明、時間)、再生メトリクス、ソーシャルメトリクス(いいね、共有、フォロー)、ユーザーデータ(レビュー、プレイリスト)、支払い履歴などが含まれます。これらのデータは、いくつもの理由から(GASコスト、ストレージ制限、書き込み遅延など)、メインネット上(もしくはIPFS上)にすべて置くことはできませんでした。

しかし、複数のサイドチェーンを使用することで、データ処理を簡素化し、運用コストを大幅に削減できます。その理由は、アプリ開発者が、アカウントのストレージ手数料やコミットメント時間、アクセスとルックアップのメカニズムなどを考慮に入れて、適切なストレージの場所にデータの読み取りと書き込みを最適化できるからです。

A close up of a map

Description automatically generated
ストレージオプションは、メインネットからサイドチェーン、分散型(および集中型)ストレージまで多岐に渡る‌‌

処理の複雑性の増加

弾性サイドチェーンを使用する場合に見逃されがちな、しかし重要な側面のひとつに、処理の複雑性が挙げられます。メインネット内での処理は、大幅に制約される場合があります。資産の変更(作成、送金、消滅)よりも複雑な処理は、GAS手数料とコミット時間の増加につながります。複雑性は、メインネット上のスマートコントラクトの公共性を考えると、リスクを増加させます。サイドチェーンを使用しても、コントラクトロジックの不良のリスクを必ずしも排除できるとは限りませんが、その影響を切り分けたり、ミスの重大性を軽減したりすることができます。

より複雑なスマートコントラクトを作成する主な利点は、開発者がより豊富な機能を利用できることにあります。これらの機能は、新たに出現した領域内でしか増やすことはできません。フルステートコントラクト処理とは、チェーンへの完全なアクセスがあることを意味します。つまり、チェーンの完全なステートに関する知識を前提にして、精度と適時性の高いステート変化を実行できます。GAS手数料からの解放は、他のプロトコルを呼び出したり、オラクルを利用したり、提供されるサイドチェーン機能(例えば乱数生成器など)を利用したりできる自由度が高いことを意味します。サイドチェーン内でこの作業を行うことは、詰まるところセーフティネットを提供しています。すなわち、GASコストを厳格にコントロールしつつ、開発者がより迅速に行動し、より急速にイノベーションを進めることのできる自由を提供しているのです。

A close up of a logo

Description automatically generated

SKALEネットワークの利用

SKALE Labsは、弾性ブロックチェーンネットワークプロトコルであるSKALEネットワークの考案者です。当社の使命は、フルステートスマートコントラクトを実行できる、費用対効果の高い、高性能サイドチェーンの設定を迅速かつ簡単にすることにあります。私たちは、セキュリティや分散化で妥協することなくスピードと機能をお届けできるパフォーマンス体験を開発者に提供することを目指しています。当社をTelegramTwitterDiscordでフォローしたり、SKALEウェブサイトを訪問して、開発者向けドキュメントをぜひご覧ください。

SKALEネットワークの発展の背後にある哲学は、複数の弾性サイドチェーンを採用するというこの見解に従っています。サイドチェーンをすばやく配置してスケーリングする機能、信頼できるチェーン検証のためのプールされた検証モデルの使用(小規模のサイドチェーンについても)、拡張可能なノード構成、フルステートスマートコントラクト処理などは、SKALEネットワークを弾性サイドチェーンとして展開することによる利点のほんの一部です。

読者の皆さんが、SKALEの持つ利点について詳しく調べてみたり、さらには開発者の支持者の誰かとつながりを持つようになることを願っています。質問に答えたり、オンラインハックセッションを行ってこれらのアイデアを詳しく説明することも喜んでいたします。弾性サイドチェーンは現実のものであるだけでなく、迅速なローンチや、スケーラビリティの問題点への対処、運用コストの削減、次世代の優れた分散型アプリケーションの構築における、優れた選択肢のひとつでもあります。

免責事項この文書は情報提供のみを目的としており、N.O.D.E. Foundation, SKALE Labs, Inc.、またその関連企業の株式もしくは有価証券を売却する申し出または勧誘を行うものではありません。そのような申し出または勧誘は、機密提供覚書によってのみ行われるもので、適用される証券法およびその他の法律に従って行われます。