TendermintとMOLDの目指す世界観について

Published in

GAME

18 min readAug 9, 2018

MOLDでは、ゲームに特化した独自のブロックチェーンを構築することにより、次世代分散型ゲームプラットフォームの実現を目指しています。今回は、HyperledgerのようなPBFTを用いたコンソーシアムチェーンに少しだけ近く、即時ファイナリティ性を持つブロックチェーンであるtendermintについて考察を行い、我々のプラットホームに適切であるかどうかについて検討します。

MOLDが目指す世界観

私たちが目指している世界観は、

非中央集権的な仕組みにおけるユーザー個人のデジタル資産の管理
P2Pでのデジタル資産の自由で迅速な取引
ゲームディベロッパーがより多くの利益を享受しやすい環境

でした。これらの条件がTendermintで実現できるかどうかについて考えていきます。

Tendermintプロジェクトについて

はじめにTendermintのプロジェクトについて説明して行きます。TendermitはブロックチェーンにおけるコンセンサスアルゴリズムとP2Pネットワークをパッケージング化したソフトウェアです。これを用いることによって、簡単にかつ安全に新しく、独自のブロックチェーンネットワークを構築することが可能です。以下では、その主な特徴について説明します。

まず、Tendermintは、以下の特徴を持っています。

PoSコンセンサスで、あらかじめブロックを生成する人が絞られるのでトランザクションの処理速度が速い(数千TPSの処理速度)、
フォークが起きないためブロック生成後すぐにファイナリティを得られる。
バリデーションノードのうち1/3が停止またはビザンチンな振る舞いをしても問題ない
パブリックチェーンでもプライベートチェーンでも実装可能
あらゆるプログラミング言語で開発することが可能
コンポーネント化された設計とABCIによって独自のアプリケーションレイヤーを持つブロックチェーンを容易に実装可能

Tendermitの仕組み

上記の特徴をどのように実現しているのか、Tendermintの仕組みについて、簡潔にではありますが説明していきます。

Tendermintでは、ブロック生成に参加する人をvalidatorと呼びます。このvalidatorの中から、交代で新しくブロックを生成する人(Proposer)を選びます。このとき選ばれるproposerはStakeによって事前に決定論的に決められます。

Hyperledgerの場合は、リーダー固定制であったのに対して、Tendermintでは今述べたように、ラウンドロビン制という、交代でブロックを提案していく仕組みが取り入れられいます。

Proposerが選んだブロックを、Proposerに選ばれなかった人が投票を行い、2/3以上の同意が得られれば、承認され次のステップへ移ります。
Tendermintでは、同一のブロックに関して、同時にブロックが生成されないように二段階の投票を行います。はじめの投票をpre-vote、二回目の投票をpre-commitと呼びます。また、2/3以上の投票が集まらない場合は、制限時間内まで待ち続けます。そのため、tendermitは、部分的な非同期のコンセンサスです。

また、この２段階の投票プロセスの過程で、もしそのブロックの正当性に対して十分な投票数が得られなければ次のラウンドに移行することになります。次のラウンドでは投票プロセスを行うバリデーター群は異なり、失敗したブロック高に対する投票プロセスをもう一度行います。（ブロックに含まれるトランザクションが同じであるとは限らない。）

ここで、ラウンドとは、proposeからpre-commitまでの一連の流れを指します。一連の流れは以下の図で確認できます。

Tendrmint Official：https://tendermint.readthedocs.io/projects/tools/en/master/introduction.html

MOLDとTendermintの簡易比較

Tendermitを利用して、独自のBlockchainを構築できれば、MOLDの思想を達成することができると考えています。

Tendermintファイナリティについて

ゲームプラットフォームであるMOLDの場合、実用化に向けて高水準の即時決済性が求められます。すなわち、迅速なファイナリティの確約を達成しうる合意形成アルゴリズムを形成することが必要です。

Hyperledgerとの比較の際にも確認したが、現在のBitcoinやEthereumなどは、ソーシャルゲームで必要なスループットに比べ、かなり少量のスループットとなっています。
また、ファイナリティーの問題もあり、ブロックにトランザクションが格納されてから、一定時間経過するまで(複数のブロックが承認されるまで)メインチェーンが覆る可能があります。

一方、tendermintはこれらの二つの問題を解決することができます。独自のコンセンサスを取り入れたネットワークを用意することで、前述のように、高いTPSと決定的なファイナリティーを提供してくれています。

tendermitコンセンサスと分散性

MOLDでは、分散型のゲームプラットフォームの構築を目指します。それに当たって、誰でも自由にMOLDのネットワークに参加できる仕組みを作ることが必須です。
一方、Tendermintはコンソーシアムでも、パブリックなブロックチェーンも作ることができます。そのため、初めは、プラットホームの成長と拡大のためにMOLDチームが組成するメンバーにステークトークンを持ってもらい、コンソーシアムチェーンを作成し、十分ユーザーが集まってきた段階で、それらのステークトークンをパブリックに公開し、誰でもネットワークの維持に参加できるような仕組みを作ることも可能だと考えています。

Assetの定義に関して

Ethermitというプロジェクトは、Tendermintを用いてEthereumのEVMを利用できるようにしたtendermintベースのブロックチェーンです。このEVMを使うことによって、fungible(代替可能) なassetを数量限定で生成することができるとともに、Non-Fungibleなassetも表現することができます。

代替可能なトークンと代替不可能なトークンの発行は、MOLDプラットフォーム上で、ゲーム内アイテムのトークン化を目指す上で必要になる概念と言えます。

参考：MOLDのアイテムトークンについてーwhitepaperより抜粋ー

アイテムトークンには二種類のものがある。fungible(代替可能) トークンと Non-Fungible(代替不可能) トークンである。前者は、ゲーム内に多数存在するポーションのようなアイテムに利用される、Ethereum 上における ERC-20 トークンに対応するものである。fungible トークンとなったゲームアイテムは、一つ一つに代替可能性があり、例えば Molca の持っている 1 トークンと Molna の持っている 1 トークンは全く同値のものである。しかしながら、多くのゲームには個体値を持つユニークなゲーム内アイテムが存在し、ゲーム空間をよりエキサイティングにしている。ユニークな Level や攻撃力、スキル等を持つゲーム内アイテムはメタデータとしてそれらのステータスを保持し、Non-Fungibleトークンとなる。これは Ethereum 上における ERC-721 トークンに対応するものであり、世界に一つしかない代替不可能なトークンとなる。この時、Molca の持っている 1 トークンと Molna の持っている 1 トークンは等価交換できるとは限らない。いずれのアイテムトークンに関しても、ユーザーはMOLD 上でデジタル資産として所有することができ MOLDEX 等 (次章参照）を利用することで容易に取引が可能となる。また MOLD では、ゲーム開発者が容易に両トークンを発行可能となる仕組みをSDK（4.4.6 章参照）として用意する。

TendermintのTPS検証

ここでは、Tendermintでの処理スピードについて実際に調べてます。TPSとは、一秒間あたりの秒間トランザクションを意味し、ゲーム内通貨としてmoldcoinを活用するにあたり、MOLD内では、一定水準以上のスピードが求められます。

今回は、Tendermitのベンチマークツール、tm-benchを用いました。

動作環境
Mac上のVirtual Boxにて、

メインメモリー 512MB
プロセッサー数 1CPU
Linux/Ubuntu (64bit)
の環境下で、
version 0.22.4-c64a3c74のTendermitを用いて、local networkでベンチマークを
行いました。

以下その結果を引用します。

測定方法

10秒間数千トランザクションを発生させた時に処理できるトランザクションの数を測定しました。今回は、テストなので簡単なkey-value-storeのトランザクションを利用しています。

注意点

TPSの値は、使用するPCや動作環境によって大きく異なるので、今回のbenchmarkは、一つの目安に過ぎません。

Ubuntu machine 1台で

root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        594       352        876     5936      
Blocks/sec     0.900     0.300      1       9         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 2000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        577       355        874     6342      
Blocks/sec     0.818     0.386      1       9         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 3000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        607       343        859     6682      
Blocks/sec     0.909     0.287      1       10        
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 5000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        586       349        893     6443      
Blocks/sec     0.909     0.287      1       10

Ubuntu machine 2台で

Stats          Avg       StdDev     Max      Total     
Txs/sec        150       405        1360     1504      
Blocks/sec     0.200     0.400      1        2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1500 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        43        130        433     433       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1500 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        0         0          0       0         
Blocks/sec     0.000     0.000      0       0         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1500 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        51        154        513     513       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1200 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        40        119        396     396       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        45        136        452     452       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max      Total     
Txs/sec        100       302        1005     1005      
Blocks/sec     0.200     0.400      1        2

Ubuntu machine 3台で

root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657<img title='chart.jpeg' src='/attachments/19e5ae3f-d5c2-4e48-990b-042269f7b8e8' width="1200" data-meta='{"width":1200,"height":800}'>
Stats          Avg       StdDev     Max     Total     
Txs/sec        34        104        345     345       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        89        267        889     889       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 2000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        28        83         276     276       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        36        107        358     358       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        38        115        383     383       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1500 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        54        161        537     537       
Blocks/sec     0.200     0.400      1       2      
 
Stats          Avg       StdDev     Max     Total     
Txs/sec        33        99         331     331       
Blocks/sec     0.200     0.400      1       2

Ubuntu machine 4台で

Stats          Avg       StdDev     Max     Total     
Txs/sec        34        104        345     345       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        89        267        889     889       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        36        107        358     358       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        38        115        383     383       
Blocks/sec     0.200     0.400      1       2              
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        64        181        607     641       
Blocks/sec     0.200     0.400      1       2         
root@vagrant-ubuntu-trusty-64:~# tm-bench -T 10 -r 1000 localhost:26657
Stats          Avg       StdDev     Max     Total     
Txs/sec        70        170        564     700       
Blocks/sec     0.200     0.400      1       2

これらをわかりやすく図示すると、以下のようになります。
ただし、ここでは簡単にTPSの最高値を用いてグラフを作成しました。

このグラフを見ると、TPSはノードの数が増えるごとに指数函数的に減少することがわかります。しかし、低いスペックの環境下で実験を行ったとはいえ、TPSは数百にも登り既存のBlockchainよりも良い結果であることがわかりました。

考察

有名なブロックチェーンであるBitcoinとEthereumのTPSを表にして比べて見ると、Tendermintのトランザクション処理速度は速いことがわかります。

ノードの数を一台から2台に増やす時にガクッとTPSがさがっています。これは、ノードが1台とのときよりもブロックの伝搬とコンセンサスによる時間が格段と増えるためであります。

また、ノードの数を3台から4台に変化た際にTPSがあまり変化しなかったのは、
Tendermintのアルゴリズムが、3分の1未満のビザンチン障害であれば正常に動くためです。3台のノードの場合、3分の1未満したがって、1台のノードもビザンチン故障できないことになる、つまり3台でコンセンサスを取る必要です。一方、
4台の場合は、3分の1未満したがって、1.44台未満のビザンチン故障を許容し、3台のノードでコンセンサスをとればブロックが承認されます。そのため、3台のときと4台のときのTPSにあまり違いが起きなかったと推測できます。

まとめ

ここまで述べてきたように、tendermitは新しい独自チェーンを作る際に非常に利用しやすいことがわかります。そのため、我々はTendemintがMOLDの思想と現状のEthereumが合致しないファイナリティーの問題や、TPSの問題を解決し、ゲーム内で必要なAssetを表現できるブロックチェーンの候補して適していると考えています。
また、プラットホームの拡大の戦略もプライベートからパブリックのブロックチェーンまで利用できるTendermintはメリットがあると考えました。
一方で、EthereumでもPlasmaを代表するように、TPSを格段にあげる施策やプロジェクトが生まれ、実装に向かっています。そのため我々MOLDチームは、これらの技術を俯瞰して、どちらも実装できるようにしながら、今後の新着を見ながら、どのような実装によってブロックチェーンを構築するのか最も良いのか分析しながら開発を進めています。

— — — — — — — — — — — — — — — -
Cosmos Gaming Hub Project(旧MOLD Project)
CEO & Co-Founder

朝野巧己

全てのゲーム愛好家に最高のエンターテイメントを届けるために