「イーサリアム」はなぜスケールアップしないのか　分散型パブリックブロックチェーンのスケーラビリティをサポートする「Mousse」「Shargri-La」

自己紹介と開発背景

岡南直哉氏（以下、岡南）：それでは「次世代分散型アプリケーションプラットフォームのためのプロトコル開発支援システム」の発表をします。よろしくお願いします。私は、岡南と言います。ふだんはLayerX Labsで、パブリックチェーンの研究開発をしています。

中村龍矢氏（以下、中村）：同じくLayerXで執行役員をしています、中村と言います。最初は私がお話します。

まず背景です。タイトルの「分散型アプリケーションプラットフォーム」についてですが、これは、イーサリアム（Ethereum）をはじめとするパブリックブロックチェーンのことを指しています。イーサリアムは、特定の管理者のいない非中央集権的な分散型アプリケーションを載せるプラットフォームで、その核となる技術としてブロックチェーンを使っています。

この分散型アプリケーションの例としては、ブロックチェーン上のデジタル資産を取引する取引所だったり、デジタル資産を使った保険、ほかにも貸付、借入、デリバティブの発行などが行えます。

このような分散型アプリケーションが今非常に盛り上がっていて、結果的にこの1年間でイーサリアムの手数料が高騰する現象が起きています。これはユーザーの需要によって決まりますが、イーサリアムを使う時には手数料が必要になってきてしまいました。分散型アプリケーションのユーザーが増えた結果、手数料が高騰してユーザーエクスペリエンスが悪化する現象が起きています。

この原因とは、イーサリアムのスケーラビリティが乏しいところにあります。ブロックチェーンは分散的にたくさんのノードがいりますが、それらのノードは並列処理をしているわけではなく、まったく同じ処理を実行していて、同じブロックチェーンを複製して管理しています。

そのため、よくある例としては、クレジットカードのVISAが秒間数万決済処理しているところを、イーサリアムで同じことをやろうとすると秒間15決済しかできないといった課題があり、適用できるアプリケーションに大きな制約があります。そこで“次世代”というところが関わってきます。

イーサリアムのコミュニティで引かれているロードマップ

イーサリアムのコミュニティでは、このスケーラビリティを改善するために、スライドのようなロードマップを引いています。1つ目の段階が、Rollupという技術です。

Rollupは今のイーサリアムと組み合わせて使う技術になっています。普通のブロックチェーンだと、何か処理する時に発行するトランザクションをデータをブロックチェーンに載せ、そのトランザクションに則ってブロックチェーン上でプログラムを実行します。

Rollupではこのプログラムの実行を、ブロックチェーンの外側に追いやって効率的に行うことにより、プログラム実行の分の計算コストを削減する技術です。この時に、トランザクションのデータはあくまでブロックチェーン上に載っけられる必要があるというのがポイントです。Rollupはすでに開発が進んでいて、実際にイーサリアムで使われ始めています。

この次の段階がイーサリアム2.0というもので、今お話したRollupとShardingという技術が組み合わさって使われます。

イーサリアム.0はRollupとは違い、既存のイーサリアムを抜本的なアップグレードするプロジェクトで、具体的にはProof-of-Stake、それからShardingという2つの技術を導入します。これによって、イーサリアムのセキュリティとスケーラビリティの向上を狙っています。

イーサリアム2.0は非常に大きなプロジェクトなので、段階的に進んでいきます。まずはじめにProof-of-StakeのBeacon Chainという、全体の核となる部分がローンチされ、そのあとにShardingが導入されます。Shardingも2つの段階に分かれていて、これは後ほど岡南からお話ししますが、Data ShardingとExecution Shardingに分かれています。

ちょうど2019年12月にBeacon Chainというシステムの心臓の部分がローンチされています。Beacon　Chainはあくまで核となる部分であって、ユーザーはこれ単体では使えません。

今はBeacon Chainのローンチが終わり、いよいよこの2つの種類のShardingに向けて進んでいる状況です。

開発の成果物について

岡南：ということで、代わって岡南が発表します。本題になりますが、我々が開発したのは、RollupやShardingというような、次世代のスケーリング技術が導入されるプラットフォームの開発をサポートするソフトウェアです。

成果物は大きく2つあります。「Mousse」と「Shargri-La」です。MousseとShargri-Laは、Eth2（イーサリアム2.0）のロードマップにおける、Data ShardingとExecution Shardingという2つのシャーディングに紐づいています。まずMousseは次にローンチ予定のData Shardingを対象としています。一方で、Shargri-Laはそれよりも未来に導入されるExecution Shardingを対象としています。

シャーディングを対象とするのは一緒ですが、MousseとShargri-Laはターゲットと提供価値がかなり異なっています。MousseはEth2を利用するアプリケーションの開発者をターゲットにしていて、Ethe2のアプリの実装を支援するソフトウェアです。一方でShargri-Laは、シャーディング自体の研究者をターゲットにしていて、特にユーザーコードの分析を行えるソフトウェアになっています。

Mousseが実装しているData Sharding

ということで、Mousseが実装しているData Shardingについて簡単に説明します。Data Shardingはデータの保存を並列化できます。先ほど紹介したBeacon ChainというEth2の核となるチェーンに、Shardというネットワークが64個新しく加わります。Shardには、データを保存できます。単純計算でデータの容量が64倍になるということです。

そのData Sharding含むイーサリアム2.0は、当面は既存のイーサリアムと共存します。つまり、異なる2つのチェーンが動き続け、連携し合う構造になっています。

Data Shardingが何のデータを保存するために使われるのかというと、主にRollupのトランザクションデータです。Data Shardingにはトランザクションデータが書き込まれ、現行のイーサリアムは、そのトランザクションデータを利用可能です。

というわけで、今後このData Shardingが導入されるため、Eth2向けのRollupの開発が進んでいくわけです。となると、Eth2のローカルテストツールが必要ではないかと、我々は考えました。それがMousseになります。MousseはEth2のアプリケーションをローカルテストするためのエミュレータです。

この「ローカルテスト用エミュレータ」とは何なのかと思われる方もいると思います。ローカルテストツールはかなり需要があり、現行のイーサリアムには「Ganache」というローカルテストツールがあります。これが非常に人気で、GitHubのスター数でも2,500くらいありますが、イーサリアムデベロッパーのみなさんは使ったことあるのではないかなと思います。

Ganacheは、具体的にはローカル環境でイーサリアムチェーンをエミュレーションするソフトウェアです。そのGanacheにアプリケーションをデプロイしてテストするのが、定番の開発手法になっています。エミュレータのメリットとしては、実際のノードを動かすのに比べてローカルで完結する分、柔軟、かつ、高速に扱えるというのがあります。

というわけで、我々はEth2版のGanacheを作りました。それがMousseです。主なユースケースは、Eth2を用いるRollupの開発支援です。黒色で示す四角がRollupに関するプログラムで、それらを開発するためにMousseが使えます。Rollup Operatorは、Rollupを管理するノードです。MousseはこのRollup Operatorから送られてくるデータの保存や読み込みなどの要求に応えたり、RollupアプリケーションからのRollupのトランザクションの参照に応えたりします。ちなみに、MousseはRustで実装しています。

Mousseは、内部では各種P2Pクライアントとのやりとりを再現しています。主に3つのノードがあり、Beacon Node、Shard Node、Data Market Nodeです。これらがアプリケーションと通信を行います。

Mousseを利用してアプリを開発する際は、APIを叩いてテストできます。APIはREST的に定義しており、その定義に従って通信が行われます。

Mousseのデモ

それでは、Mousseの実際に動かしているデモを見せます。上のターミナル見てください。まず、Mousseを起動しました。起動すると、MousseがEth2のエミュレータとして振る舞い始めます。この状態でMousseにAPI経由でリクエストを送ると、ブロックチェーンを操作したり、データを取得したりできます。

まずはブロックの一覧を取得してみました。まだ時間を進めていないので、当然ブロックはありません。

それではcurlを使って、ブロックを10個つなぐリクエストを送ってみます。送りました。では、再度ブロックの一覧を取得してみます。

ブロックが返ってきました。これでチェーンが伸びていることがわかります。このように、Eth2アプリケーションの開発者は、API経由でいろいろなテストを実施できます。

それではdashboardも起動します。dashboardは、ブロックチェーンのデータを可視化したい時や、手動でアドホックな操作をしたい時に有用になります。起動しました。dashboardを起動すると、まずブロックの一覧が、最新のブロックから順に表示されています。

SLOTは、Eth2チェーンの時間の単位です。ブロックをクリックすると中身が見れて、シャードに保存されているデータへの参照が記録され、どんな情報が保存されているかがわかります。

では、ここからそのデータを保存する一連の動作をしてみます。保存するデータは、今回は未踏のログを使います。まず、Processingページに移りました。

今、下のBidというフォームでデータを選択しました。そうすると、左のコミットメントが自動で更新されます。コミットメントは、いわゆるハッシュみたいなものです。データはブロックチェーンに保存されるのですが、コミットメントが目印のような役割を持ちます。このコミットメントは手動で記入しても問題ありません。

ほかには、どのシャードのどのスロットで、いくらの手数料で送るかを指定できます。今回はShard：3、Slot：11、手数料：100に設定して送信します。

送信したので、スロットを1つ進めてみます。スロットを進めるのは、上のフォームを使います。1つ進めるために11を指定します。右のラジオボタンでは、正常系、あるいはさまざまな異常系のシナリオを指定できます。まずは正常な、つまり通常のブロックチェーンのように動かすことをやってみます。

ブロック一覧に戻ります。最新のブロックを見てみます。シャードで最新のブロックを見てみると、SHRAD：3、SLOT：11に先ほどのコミットメントが確認されているので、データの保存が成功しました。

では、次に、異常系のシナリオをテストします。Processingページに戻りました。データの保存リクエストを再度送ってみます。今回もデータは未踏のログを使います。Shard：3、Slot：15、手数料：100にします。

では、異常系でスロットを進めます。我々のMousseは、右にあるさまざまな異常系の異常なシナリオをエミュレーションできるのが強みになっています。

例えば、上から4番目のwithout shared header inclusionは、Beacon Chainからシャードを参照できなくなるシナリオです。下から2番目のwithout beacon block proposalは、Beacon Chainでブロックが提案されなかった場合のシナリオです。

一番下は異常系をランダムに実行するというシナリオになっています。今回はwithout shared header inclusionを選択して、スロットを20まで進めてみます。今のスロットは11です。

ブロックページに戻りました。赤色で表示されてるスロットがいくつかありますが、赤色は何か異常が起きたことを示しています。クリックすると、一切シャードが参照できなくなっていることがわかります。このように、Mousseは実際のノードを動かすよりも簡単に、異常系のテストが可能です。

今までのリクエストのログはすべて保存されていて、ログページから確認できます。過去にどういったエンドポイントにどういったリクエストを送り、どういったレスポンスが返ってきたかがわかります。以上がMousseのデモです。これでMousseの紹介は終わりです。

Shargri-Laについて

それでは、もう1つのShargri-Laという成果物について紹介します。Shargri-Laは、Data Shardingよりも未来のExecution Shardingを想定したソフトウェアになります。

まずはExecution Shardingについてお話しします。Data Shardingと同じように、64個のシャードがあります。Beacon Chainがシャードを参照するという仕組みも変わりません。ただ、Data Shardingと明確に異なる点があります。それはシャードにデータ保存するだけでなく、ブロックの実行やETH（Ethereum）の送金が可能になったことです。それによってどうなるかというと、ユーザーがRollupを介さず、直接シャードを利用できるようになります。

では、ユーザーが直接シャードを利用できるようになるとどんな問題が生じるかというと、例えばユーザーが手数料が安いシャードを利用したいであれば、どのシャードを利用すればいいのかを考えるようになります。このような行動が、システム全体にどのような影響を及ぼすのかは、まだまだ未知数と考えられています。

ということで、我々は、現実でユーザーがExecution Shardingを利用する前に、ユーザー行動を再現、かつ、解析できるようなシミュレーターが必要なのではないかと考えました。それがShargri-Laです。

Shargri-LaはEth2におけるユーザー行動を解析するシミュレータです。Mousseと違う点は、ユーザー行動に特化していること、各種プロトコルの分析や設計が行えることです。そのため、ターゲットはシャーディング自体の研究者で、ちょっとアカデミック寄りなソフトウェアになります。これもRustで実装しています。

我々は、実際にShargri-Laを使ってプロトコルの分析を行って公開しました。内容は、Execution Shardingにおける利己的なユーザー行動になります。問題設定はETHの送金に限定しました。

Shargri-Laはユーザー行動の解析を目的としているので、ユーザーの行動をどうモデル化するかが非常に重要になります。我々はUserGraghという重要なモデルを定義しました。各ユーザー間でどれくらいの確率、かつ、どれくらいの手数料の予算で送金するかというモデルです。このUserGraghをもとにトランザクションを発生させました。

Shargri-Laを使って発見したこと

Shargri-Laを使って発見したことの一部を簡単に紹介します。Execution　Shardingだと各シャードの手数料は異なります。そうなると、シャード間での手数料は偏ってしまいます。偏ると当然、安いシャードに手数料が利己的なユーザーが殺到して、トランザクション詰まりが起こってしまいます。

左のグラフは横軸が時間、縦軸は各シャードのユーザー数です。この色つきは、3つのシャードをピックしているものになります。振れ幅が大きいのが見て取れると思いますが、ユーザーがたくさんいるシャードと、いないシャードでだいぶ差ができています。人がたくさんいるシャードが、時間とともにどんどん変わっていっています。要は、手数料が安いシャードにユーザーが大移動していることが見て取れます。