目次
はじめに
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
今回の内容
本記事は、2018年3月8日から10日まで行われたEthereum Community Conference(EthCC)で発表されたPlasma Cashについて解説します。
全3回のシリーズのうち、第1回となる今回はPlasma Cashの前提知識であるPlasmaと、そもそもPlasmaが何を解決しようとしているのかという点について解説し、Ethereumのスケーラビリティ問題への理解を深めることを目的とします。
前提知識としてブロックチェーンの構造、Ethereumについての知識があることが望ましいです。
第1章 ブロックチェーンのスケーラビリティ問題
Ethereumを含むブロックチェーンは、分散システムや分散アプリケーションと言われることがありますが、ブロックチェーン出現以前から存在する、既存のコンピュータシステムとしての分散アーキテクチャのアプリケーションとはその構造が大きく異なります。
一般的な分散処理技術とブロックチェーンの違い
一般的な分散処理技術の場合
例えば、分散処理技術であるHadoopは、実際にネットワークに参加しているノードで処理を分散して行い(Map)、それをまとめ上げることで(Reduce)、大きな処理を分割し高速に処理することが可能となっています。
つまり、オーバーヘッドのため直線的ではないにせよ、参加ノードが増えるほど、処理性能は向上します。
また、データも分散して保持するので参加ノードが増えれば、参加ノードの集合体であるクラスタの使用可能なストレージ容量も増加します。
図1 : 通常の分散アーキテクチャ
A, B, C,というデータがある場合は各ノードで分散してデータを保持します。処理も分散するので、ノードが増えるとストレージと処理性能がスケールします。
ブロックチェーンの場合
一方、ブロックチェーンではノードが増えたところでネットワーク自身の処理速度は向上しません。
ビットコインの場合は10分に一度のブロック生成、Ethereumでは約14秒間に一度のブロック生成とブロック生成時間の目安が決まっており、これは参加ノードの数に関係なく常に一定です。参加ノードが増えたとしてもこの間隔が短縮されることはありません。
また、全てのノードは最初のブロックから現在のブロックに至るまでのすべてのブロックを保持する必要があります。
一般的な分散処理技術のように、分割されたデータがネットワーク全体に分散されて保持されているわけではなく、ブロックチェーンでは各ノードが同一の状態を保持しています。そのため、参加ノードが増えたところで一台当たりのノードが保持する容量が減ることもありません。
図2 : 同一ステートを持つブロックチェーン
ブロックチェーンにA, B, Cというデータがあるとすると、全てのノードが同じデータを持つことになります。RDBではマルチマスター方式などと呼ばれることもあります。
処理速度に関しては、処理できるトランザクションの限界を一時的に超えてしまい、送金詰まり、トランザクション詰まりと呼ばれる現象を引き起こすことがあります。
例えばEthereumでは、人気のInitial Coin Offering(ICO)により、一時的にトランザクションが大量発生し、トランザクションが長時間承認されないという事態が発生しています。
また、昨年の2017年末に子猫を育成するアプリケーションであるCryptoKittiesが人気になった時も同様に、一時的にEthereumのネットワークが混雑し、CryptoKittiesを利用していないユーザーのトランザクションにも影響が出たことがありました。
どのブロックチェーンでも処理性能が向上しないのはシステム的に問題です。ことEthereumにおいてはアプリケーションプラットフォームとしての役割から、あらゆるアプリケーションを稼働させるために、スケーラビリティの向上が解決すべき必須の問題となっています。
スケーラビリティを向上させる方法として、以下の取り組みがあります。
- 当サロンでも過去に紹介したRaiden
- 今回紹介するPlasma Cashの前提技術であるPlasma
- CasperによるProof of Stakeの導入後に構想されているState Sharding
第2章 Raiden
Raidenはオフチェーンによりスケーラビリティを向上させる技術です。
オフチェーンのアプローチとしては、ビットコインのライトニングネットワークと同様で、二者間の複数の取引をまとめてブロックチェーンの外で処理し、その取引を一つのトランザクションにまとめることによってトランザクション数を減らす手法です。
また、現時点で実装されているμRaiden(マイクロライデン)では、ETHの送金とERC20準拠のトークンの送金ができるのみで、そのほかのコントラクトのオフチェーン処理はまだ実現できていません。
CryptoKittiesなどのアプリケーションのトランザクションは現時点ではRaidenにより処理速度を向上することはできないのです。
図3 : Raidenのオフチェーン
AliceからBobに送金する際には、ステートチャネルと呼ばれるトランザクションを発行し、そこに送金する資金を入金します。
チャネルをクローズしてブロックチェーンに書き込むまでは、ブロックチェーンの外で送金するので入金した資金の中で何度でもやり取りが可能です。
第3章 Plasma
Plasmaはブロックチェーン本体と接続する形でもう一つの別のブロックチェーンを接続し、処理を後者のチェーンに移譲することによって処理性能を向上する技術です。このような手法は一般的にサイドチェーンと呼ばれます。
μRaidenとは異なり、こちらはブロックチェーンに接続しているので、通常のスマートコントラクトのトランザクションも実行可能ですし、特定の処理に特化したPlasmaチェーンを用意することもできます。
CryptoKittiesのように、大量のトランザクションが発生するアプリケーションの処理が問題になった場合は、アプリケーション固有のPlasmaチェーンを用意するなどということも可能です。
また、サイドチェーンの下にさらなるサイドチェーンを接続することも可能で、下図のように階層的にブロックチェーンを用意し処理を移譲していくことで2段目、3段目目の処理性能向上を行うことが可能です。
図4 : Plasmaのサイドチェーン
一番下のブロックチェーンから2,３段目のPlasmaチェーンに処理をしていきます。
第4章 Sharding
Etheruemで実現が検討されているShardingはState Shardingと呼ばれ、ユーザーの状態やコントラクトの状態からトランザクションを処理するノードを割り振ることで、処理性能を向上します。
ブロックチェーンのノード自体で処理を分散化しているため、ノードを追加することでブロックチェーン自体のパフォーマンスは上がります。これは一般的な分散技術と同様の仕組みといえるでしょう。
しかし、このState Shardingを導入するにはいくつかの障壁が存在します。
まず、このShardingを実装するための前段階として、当オンラインサロンで過去に説明したCasperの稼働が必要になります。また、どのノードがどの処理をすべきか効率的に割り振る必要があり、その方法も検討しなければなりません。
また、状態が全てのノードで変更されるわけではないので、それをどのタイミングで安全に同期するべきかといった問題もあります。Shardingに関してはまだ未知数の部分が多いと言えるでしょう。
まとめ
今回はEthereumのスケーラビリティについて、どのような問題があるのか、またそれを解決するためにどのような手法が考えられているかについて概要を解説しました。
次回以降はPlasmaの詳細と、Plasmaの問題点を解決するためのPlasma Cashの導入について解説します。
参考資料
Joseph Poon joseph, Vitalik Buterin “Plasma: Scalable Autonomous Smart Contracts(https://plasma.io/plasma.pdf)”
