X.ブロックチェーンと分散システム
分散システムは、Tanenbaumらによって”DISTRIBUTED SYSTEMS — Principles and Paradigms”の中で、「分散システムは、その利用者に対して単一で首尾一貫したシステムとして見える独立したコンピュータの集合である」と定義されている。
Andrew S. Tanenbaum and Maaetem an Steen : DISTRIBUTED SYSTEMS — Principles and Paradigms Second Edition, Pearson Pretice Hall (2007)
ブロックチェーンは、まさに世界的な分散システムを構築することによって、非中央集権的な新しいデータストアや組織構造の実現を試みたものである。
そもそも、分散システムへの志向理由というのは、スケーラビリティ・局所性・可用性が主に挙げられる。ブロックチェーンも例外ではなく、グローバルな価値保存ネットワークを形成するための地理的なスケーラビリティ・非中央集権的構造下においてデータの改竄不可能性を含む情報保護のための局所性・ゼロダウンタイムでシステムが作動し続ける可用性を実現している分散システムであるといえる。
MOLDでは、独自チェーンの開発を行なっているが、分散システムを構築するにあたり、そもそも分散システムとはどのようなものであり、正常にかつ高性能に作動するために何が必要であるかに関する理解は必要不可欠である。MOLDの目指す非中央集権的な仮想空間の実現に際して、そもそも分散システムとはどのようなものであるのか、述べていきたい。
1.はじめに（一貫性の概要と全体の流れ）
分散システムにおいて、主に「信頼性」と「性能」のためデータが複製される。特に分散システムが数量と地理的に拡大する必要がある場合、複製が求められる。また、データの破損やレプリカのクラッシュ時にも対応できる。
この時、データとレプリカの状態の一貫性の維持が必要となる。但しこれは、スケーラビリティの問題に直結する。一貫性を実現する時の理想は、「全てのレプリカが全く同じ状態と操作をし続けること」、つまり原子性が実装されることだが難題である。
現実的には、一貫性制約をある程度諦めなければスケーラビリティの問題を解決できない。よって、そのシステムにおいてどの程度一貫性が必要になるか、またどのようにその一貫性を実現するかについての理解が必要となる。
本章では、複製間の一貫性について、以下の順に説明していく。
・一貫性のモデルにはどのようなものがあるか
・複製管理について
— どこ、どのタイミングで複製を配置するか
— 誰が複製を配置するか（クライアント？サーバー？）
— どのように複製間の一貫性を確保するか
・具体的な一貫性プロトコルの例と実装
2. データ中心一貫性モデル
伝統的に、一貫性は、データ（データストア）中心に論じられてきた。
分散システムにおいて、各プロセスは各々のローカルコピーを保持するが、ローカルコピーを含む保存されたデータの集合体を分散データストアと呼ぶ。
プロセスがデータストアから読み取り操作を行う時、最後の書き込み操作の結果がデータとして返ってくることを期待する。どれが最後の書き込みかを明確にするため、グローバルクロックが存在しない場合に定義される、実時間ではない順序関係のことを一貫性と呼ぶ。
1節で述べたように、完璧な一貫性を保持することは不可能に近い。不一貫性を許容することで性能と両立できるが、何をどこまで許容できるかはアプリケーションによって異なる。そこで、まずどのような一貫性があるのかを理解する必要がある。
広く使われている重要な一貫性モデルを順序一貫性と呼ぶ。その弱い変形として因果一貫性がある。
2–1.順序一貫性
以下の条件を満たす時、データストアは順序的に一貫している。
どのような実行順序による結果も、データストアへの全てのプロセスによる読み取り・書き込み操作が、ある連続して特定の順序により実行された結果と同一となり、個々のプロセスの操作はプロセスにより指定された順序にシーケンスで現れる。要は、各プロセスの操作を比べた時にどれも同じ順序になるということ。
以下の図において、(a)は順序一貫であるが、(b)はP3とP4の読み込み順序が異なる為、順序一貫的でない。具体的には、P3ではP2による書き込み結果の値bからP1による値aへ変更したことになっているが、P4では逆である。
*W(x)aは、データ項目xに対する値aの書き込みを、R(x)bは、データ項目xからの値bの読み取りを表す。
2–2.因果一貫性
以下の条件を満たす時、データストアは因果的に一貫している。
因果的に関連している可能性のある書き込みは、全てのプロセスによって、同じ順序で観測されなければならない。異なるマシンでは、並行書き込みは異なる順序で観測されてもよい。つまり、順序一貫性の制約を弱め、因果関係がない処理順序はバラバラでも良いということである。
この時、どの操作がどの操作に依存しているか（因果関係があるか）が大切だが、この時、ベクトルタイムスタンプを用いることが有効である。
以下の図において、上の図では、値bと値cの書き込みは並行操作である為因果一貫性を満足する。
2–3. エントリ一貫性
まず同期変数を用意する。同期変数を獲得し、所有しているプロセスのみがデータを更新することができるという仕組みによっても一貫性を保持できる。これをエントリ一貫性と呼ぶ。
エントリ一貫性が保持されるには、書き込みを行うような排他モードアクセスによる同期変数の所有者が二人になってはならない。読み取りはできるが書き込みはできない非排他モードでは複数のプロセスが同期変数を同時に所有することは可能である。
以下の図において、P2はデータ項目yへのアクセス権(=同期変数)を保持していないため、読み取り結果はNILになってしまう。
この時、データと同期変数をどのように適切に関連づけるかが問題となる。オブジェクト指向の際は、各オブジェクトに同期変数を暗黙的に関連づけることで実現できる。
3. クライアント中心一貫性モデル
イベンチュアル一貫性とクライアント中心一貫性モデルについて
通常、プロセス間の非一貫性はある程度、許容できるものである。例えば、webキャッシュにおいて、クライアントに返答されるキャッシュされたページは、実際にWebサーバーの存在するバージョンに比べて古いこともある。しかし、多くのユーザーにとってこのような非一貫性はある程度まで許容できる。
例え上記のように非一貫性があったとしても、長時間が経過すれば全てのレプリカは次第に一貫してくるはずである。この形の一貫性をイベンチュアル一貫性（eventual consistency)と呼ぶ。
イベンチュアル一貫性のあるデータストアでは、クライアントが常に同じレプリカをアクセスする場合に限り正常に動作する。しかしながら、短時間で異なるレプリカにアクセスするような移動ユーザーがいる場合どうだろうか。例えば、新幹線に乗っている場合、クライアントが短期間で他の位置に移動し、異なるレプリカにアクセスすることになるが、ここで以前行われた更新がまだ伝播されていなければ一貫性が無いように見えてしまう。
以上のような問題に関して、クライアント中心一貫性の導入が解決策となる。これは前節のデータ中心一貫性モデルと異なり、単一のクライアントに一貫性を保証することを目的としたモデルである。
クライアント中心一貫性は、以下のようなものがある。
・モノトニック読み取り
・モノトニック書き込み
・書き込み後読み取り
・読み取り後書き込み
モノトニック読み取り
以下がモノトニック読み取り一貫性を満たす条件である。
以下の図において、(b)では、書き込みオペレーションWS(x1)の内容がL2の読み取り結果に含まれているという保証は無いため、モノトニック読み取り一貫性がない。
例：分散メールボックス
- いつどこのメールサーバに接続しても、前回までにサーバにアクセスした際に読めたメールは全て、移動先でも読めることを保証する。
モノトニック書き込み
以下がモノトニック書き込み一貫性を満たす条件である。
あるデータ項目xへの一つのプロセスによる書き込みオペレーションは、同じプロセスによるxへのどの後続の書き込みよりも前に完了されている。
モノトニック書き込み一貫性は、データ中心FIFO一貫性に似ている。FIFO一貫性の本質は、同じプロセスによる書き込みオペレーションは、どこでも正しい順序で行われるということである。モノトニック書き込み一貫性では、同じ順序制約であるが、並行プロセスの集まりではなく単一のプロセスのみが対象となる。
書き込み後読み取り
以下が書き込み後読み取り一貫性を満たす条件である。
データ項目xへのあるプロセスによる書き込みオペレーションの結果は、同じプロセスによる後続する読み取りオペレーションによって常に観測される。つまり、ある書き込みペレーションは、どこで行うかによらず同じプロセスが行う後続する読み取りオペレーションの前に常に完了しているということである。
例1：webページを更新すると、以降自分のブラウザでは常に新しいページ内容が表示される。
例2：パスワードを更新した時、移動先で更新後のパスワードが利用できることを保証
読み取り後書き込み
以下が読み取り後書き込み一貫性を満たす条件である。
データ項目xへのあるプロセスにより書き込みオペレーションの結果は、同じプロセスによる後続する読み取りオペレーションによって常に観測される。例：掲示板への書き込みで、AのレスとしてBを書き込む場合。
- 移動先でAが読める場合にのみBが書き込まれていることを保証。
4.複製管理
これまで、一貫性の種類について詳しく述べた。本節では、どこに、いつ、誰によって複製が配置されるか、そしてどのように一貫性を実現するかという複製配置について述べる。
複製配置には、1.レプリカサーバの配置問題と、2.コンテンツの配置問題がある。
4–1. レプリカサーバ配置問題
サーバの配置問題に関して、一つには、クライアントとサーバの距離に基づいて配置する方法がある。距離は、伝送遅れと帯域幅により測定が可能である。サーバーとクライアント間の平均距離が最小になるように一つのサーバを選択すると良い。
代替案としては、ネットワークトポロジーを考えるものがある。最大数のネットワークインターフェース（すなわちリンク）を持つルータの上にサーバを配置すると良い。
これらの問題は計算量が大きいという点である。こと、フラッシュクラウド（あるサイトに対する突然爆発的要求）時の計算を許容できない。この時、領域を区切って最もアクセスの多い領域を見つけることで効率をあげる方法などが対策としてある。
4–2. コンテンツの複製と配置
コンテンツに関しては、以下の図のように3つの異なるタイプのレプリカが区別され、体系化される。
永久レプリカ
分散データストア構成する複製の初期セットである。多くの場合、永久レプリカの数は少ない。
サーバ起動レプリカ
データストア所有者の起動により生成され、性能を高める為に使用されるデータストアのコピー。動的配置複製とは、Webホスティングサービスに置いて、性能の改善が必要なファイルをサーバに動的に複製するものである。
例えば、東京に置かれているwebサーバに対して、サーバから離れた予期しない場所のクライアントにより数日に渡り爆発的に要求が増えた際、その地域に一時的に複製を多数配置することは有効である。
クライアント起動レプリカ
これは一般的にクライアントキャッシュと呼ばれるものである。これは、データへのアクセス時間を改善する為にのみ使用される。同一データの読み取り操作が必要な時、レプリカを限定された時間内に限りクライアント側で保持するキャッシュ機能は有効である。
4–3. コンテンツ配信
複製管理には、レプリカサーバーへの更新コンテンツ配信の伝播（どのように更新するか）も含まれる。
伝播される情報種
実際に伝播されるべき情報は、以下の三つの可能性がある。
- 更新の通知だけを伝播
- ある複製から他の複製に更新データを伝送
- 他の複製に更新操作を伝播
1の通知の伝播は無効通知プロトコルが行う。もはやレプリカの情報が有効でないことだけがわかる。利点として、ネットワーク帯域幅をほとんど使用しないという点があり、レプリカの更新頻度が少なくても良い場合に利用される。
2は、更新されたデータをレプリカ間に伝送するというものである。更新がより実効的になりやすい。
3では、どのような更新オペレーションをすれば良いかだけを通知する。この時、各レプリカは常にデータを最新状態に保つ能力を持ってると仮定することができる為、1に対して一貫性が改善しているといえる。
プル対プッシュ
更新伝播の方法には、プルとプッシュがある。
読み書き比率が高い時、サーバーからのプッシュによって更新された方が一貫性が保持されるため効率が良い。
一方読み書き比率が低い時、更新頻度が高いことは帯域幅等の無駄な利用になる為、プルの方が適している。
プッシュとプルは以下のような特徴をもつ。
*ポーリング：複数の機器やソフトウェアを円滑に連携させる制御方式の一つで、主となるシステムが他のシステムに対して一定間隔で順繰りに要求がないか尋ねる方式
ユニキャスト対マルチキャスト
プッシュベースの手法はマルチキャストを使用することにより効率的に実装できる。それとは対象に、プルベースの手法ではユニキャストが最も効率的な解決策となる。
5. 一貫性プロトコル
本節では、具体的にどのような一貫性プロトコルがあるのか見ていく。
5–1. プライマリベースプロトコル
順序一貫性の実現には、プライマリベースプロトコルがよく用いられる。このプロトコルでは、項目xに対応づけられたプライマリサーバが、その書き込み操作を責任を持って実行する。
プライマリベースプロトコルには、
- プライマリサーバを特定のサーバに肯定する方法
- 書き込み操作が起動されたサーバにプライマリサーバを移動した後書き込み操作を実行する方法の二つがある。
5–1–1. 遠隔書き込みプロトコル
全ての書き込み操作は固定された単一のプライマリサーバに転送されて実行される。遠隔書き込みプロトコル（プライマリバックアッププロトコル）では、全ての書き込みをプライマリサーバがグローバルで一意な時間順序で順序づけることができる為、順序一貫性の直接的な実装となっている。
（ただしこのプロトコルは、相対的に長い時間待たされるという性能上の課題をもつ。これはノンブロッキング方式の採用により改善するが、更新の確実性とのトレードオフとなる。）
5–1–2. ローカル書き込みプロトコル
書き込み操作をするプロトコルが動作するサーバを、プライマリレプリカとして扱えるように権利を移動するプロトコル。多くの分散メモリシステムに適用された。
5–2. 重複書き込みプロトコル
プライマリベース複製では、一つの複製に書き込み操作を行なったが、重複書き込みプロトコルでは、書き込み操作を複数の複製に実行する。
重複書き込みプロトコルには、
- 操作命令を全ての複製に転送するアクティブ複製プロトコル
- 多数決投票に基づく一貫性プロトコル
の二つがある。
5–2–1. アクティブ複製プロトコル
各複製は、各々、更新操作を実行するプロセスをもち、書き込み操作が実行される。この時、全ての複製が同一順序で実行されなければならない。
順序づけは、Lamportの論理クロックを用いた全順序マルチキャストにより実現できるが、大規模分散システムへの規模拡大が難しく、中央コーディネータもしくはシーケンサを使用することにより全順序付けを実現することが一般的である。
5–2–2. 定数ベースプロトコル
投票を用いて複製された書き込み操作を実現するもの。基本的には、データ項目の読み取り及び書き込み実行前に、複数のレプリカサーバに対して操作の許可要求を行い、許可が得られた場合に実行する。
この時、サーバの数をNとし、読み取り定数をNR,書き込み定数をNWとするすると、以下のような束縛条件がある。
- NW + NR > N
- NW > N/2
この二つを満たす時、読み書き競合や書き書き競合を防ぐことができる。二つの定数は、読み/書きそれぞれの頻度によって最適化させる。
5–3. キャッシュ首尾一貫性プロトコル
前の二つと異なり、サーバではなくクライアントによって一貫性がコントロールされる。キャッシュ首尾一貫性プロトコルは、いくつかの設計方法に分けることができる。
まず、不一貫性がどのタイミングで検出されるかによって以下のように分けられる。
- トランザクションの間にキャッシュされたデータ項目がアクセスされた時に一貫性を検証する場合
- データ項目の検証最中にもトランザクションを進行させる場合
- トランザクションがコミットするときのみ一貫性を検証する場合
次に、レプリカ間の一貫性を維持する方法によって以下のように分けられる。
- 更新時に、サーバーが必ず全てのキャッシュを無効にさせる場合
- 単に更新を伝播する場合
多くの場合、更新操作はサーバによってのみ行われ、クライアントからのプルベースのよって更新が伝播される。
クライアントがキャッシュされたデータを変更することを許容する、プライマリベースローカル書き込みプロトコルに類似した方法も存在する。この方式は分散ファイルシステムで使用され、ライトスルーキャッシュ方式と呼ばれる。このとき、順序一貫性を保証するためにクライアントは排他的書き込み許可を保持する必要がある。更新の電波を遅延させ、サーバーに通知する前に複数の書き込みを許容するならばさらに性能を改善でき、ライトバックキャッシュと呼ばれる。
<分散ファイルシステムに使われる二つのキャッシュシステム>
6. ブロックチェーンにおける一貫性
以上のことからわかるように、分散システムにおいて複製されたプロセスやデータ間における一貫性を保持するためには様々な工夫が必要であることがわかる。
通常、大規模な分散システムにおいて一貫性を維持するのは非常に骨の折れる仕事である。ブロックチェーンは、まさに分散システムを体現させるための仕組みであるが、トランザクションを集めたブロックをチェーン状に繋げるというその構造によって全順序一貫性の実現を可能にした新しい技術である。
6–1. ブロックチェーンにおける順序一貫性
ブロックチェーンにおいて、トランザクション同士の順序は常に一貫している。例えばビットコインであれば、AさんのUTXOがBさんに移行し、その後、BさんがそのUTXOによってCさんに支払いを行ったというような、あるビットコインのトランザクションに関する順序はどのノードにおいても一貫している。これは、トランザクションをまとめたブロックがチェーン上に繋がれていること、そして新しいブロックの生成について合意が取れており、過去のトランザクションと整合性がなければトランザクションが承認されないという特徴によって実現されている。
以上のことから、ブロックチェーン上におけるトランザクションに関しては全てのノードにおいてデフォルトで順序一貫性が保たれていることがわかる。このように、ブロックチェーンは、非常にシンプルな仕組みによって分散システムとその一貫性を実現しているといえる。
しかしながら、より厳密にブロックチェーンの一貫性を考察すると、かなり不完全な一貫性であるともいえる。さらなる考察のために、CAP定理についてまず確認しておきたい。
6–2. CAP定理とブロックチェーン
「CAP 定理 (CAP theorem)」とは、2000 年に Brewer により予想され、後にGilbert らにより定式化・証明された、分散システムの性質である。CAP定理では、分散システムにおいて、一貫性、可用性、分断性のうち二つの性質を満たすことはできるが、三つを同時に満たすことはできないとするものである。
https://www.researchgate.net/figure/CAP-Theorem_fig4_221462089
性質内容Consistency最新の書き込みデータを読み込めるAvailabilityいつでも利用可能で有限時間内に応答するPartition Toleranceネットワークが分断されても動作する
Bitcoinのように、PoWをコンセンサスアルゴリズムとして採用している、Permissionlessなパブリック型のブロックチェーンでは、（詳細は「ブロックチェーン比較（パブリック・プライベート・コンソーシアム型）」”https://medium.com/mold-project/blockchain-comparison-51f881c8399f" を参照）可用性と分断性に関して高い水準にある。一部のノードに障害がおきてもブロックチェーンネットワークは動き続け（可用性）、ネットワークが分断されても迂回して通信を行える（分断性）。一方で、一貫性に関しては不完全である。前節で述べたように、確かにトランザクションの順序一貫性は時間とともに確立されていくものの、PoWのようなコンセンサスアルゴリズムの元ではファイナリティが存在せず、フォークが起きる。各々のマイナーは自分たちがナンスを見つけたタイミングでブロードキャストを行い最新の状態へと更新するため、頻繁にフォークが起きてしまう。CAP定理にあてはめて考えると、可用性と分断性を選択し、ある程度一貫性を犠牲にしているということになる。
とはいえ、一定の時間経過とともに、その一貫性は確固たるものとなっていく。ファイナリティが存在しない事は、一つの問題として今でも議論が進められているものの、時間が経てば全順序一貫性を保ち、対改竄性もあるというのはCAP定理を踏まえても優れたシステムであるといえる。これが昨今、ブロックチェーン技術が世の中で益々注目を集めている所以でもあるといえよう。
Seth Gilbert and Nancy Lynch. Brewer’s Conjecture and the Feasibility of Consistent, Available, Partitiontolerant Web Services.
https://www.glassbeam.com/sites/all/themes/glassbeam/images/blog/10.1.1.67.6951.pdf
6–3. ブロックチェーンと複製管理
本記事でこれまで述べてきたように、分散システムを動かすにあたって、どこに、いつ、誰によって複製が管理されるか、そして複製間の一貫性を確保するにはどのようなメカニズムをしようするかという複製管理の問題は重要である。では、ブロックチェーンにおいて複製管理はどのように行われているだろうか。
まず、複製サーバー配置問題に関して。一般的に、サーバー配置問題を考える際、通信が集中している箇所などを根拠に効率の良い配置を求める。しかしながら、Bitcoinなどのブロックチェーンは非中央集権的な運営を行うものであり、フルノードとしてネットワークに参加するかどうかは各々の参加者に依存する。つまり、システム全体として柔軟に配置を行うことは難しい。
では、レプリカ間における更新コンテンツ配信はどのように行われているだろうか。更新時に伝播されるべき情報については、次の3種の可能性があった。
- 更新の通知だけを伝播
- ある複製から他の複製に更新データを伝送
- 他の複製に更新操作を伝播
ブロックチェーンでは、フォークや改竄を防ぐため、できる限り全てのノードがネットワークの最新情報を保持することが望ましい。加えて、最も長いチェーンのみが正当なチェーンとみなされるため、素早く最新のブロックに関する情報を取り込んで次のナンス値を探そうとするようなインセンティブ構造が設計されている。以上の理由から、ブロックチェーンにおいてレプリカ間は、更新データそのものを伝送し、できる限り早い更新コンテンツのやりとりを行なっている。
また基本的に、非中央集権的なシステムであるブロックチェーンの通信はP2P通信で行われている。ブロックチェーンネットワーク内のP2P通信では、主にマルチキャストが利用されている。
まず、マイナーがナンス値を見つけた際には、すぐにネットワーク参加者全員にプッシュベースのマルチキャストが行われる。マイナーは、自分が見つけたブロックをできる限り早く全てのノードに送って承認してもらい、ブロック生成報酬を確定しようとするのである。
ネットワークに新しく参加するノードや、一度接続を切っていて再び参加しようとするノードは、プルベースのマルチキャストを行なってネットワークの最新情報を同期する。二重改竄などに騙されないようにするため、クライアントもできる限り最新のデータを得ようとすると同時に、なるべく複数のノードと同期して通信を行おうとする。
また、信頼できるフルノードに対し、プルベースプロトコルの元でユニキャストを行いアプリケーションに最新データを取り込むようなクライアントも十分に考えられるだろう。
6–4. ブロックチェーンとプライマリベースプロトコル
ブロックチェーンでは、全世界にノードが散らばっており、レプリカがあらゆる地域に分散している。各トランザクションは、PoWコンセンサスの場合、ナンスを一番最初に見つけたノードによって新しく書き込まれる。つまり、各々のトランザクションは対応づけられたプライマリサーバを持っているといえる。
このことから、ブロックチェーンの一貫性を保つためのPoWプロトコルは、5–1–2で述べた、プライマリベースプロトコルの、ローカル書き込みプロトコルに分類されるといえる。ビットコインブロックチェーンにおいては、プライマリサーバとしての書き込み権利は、排他制御・リーダー選出アルゴリズムとしてのPoWの元、ハッシュ値の0がn桁続くようなナンス値を一番最初に見つけることによって得られ、各ブロックごとにその権利は移動していくのである。ただし、プライマリサーバとなるような権利をもつノードが同時に現れたとき、ブロックチェーンがフォークしてしまう。
6–5. ブロックチェーンと重複書き込みプロトコル
一方、Tendermintをはじめ各種PBFTベースのコンセンサスアルゴリズムは、各データの更新を最初に責任を持って実行するプライマリサーバを持たない。各々のアプリケーションにおけるレプリカまで書き込み操作の権利を持っているわけではなく、その権利の保持はコンセンサスアルゴリズムに参加するノードに限られるが、参加ノード全てが同期間に書き込み操作を行える。つまり、PBFT型の一貫性プロトコルは、重複書き込みタイプの、アクティブ複製プロトコルに近いといえる。
アクティブ複製プロトコルの大きな課題として、操作が全ての複製において同一順序で行われるのが難しいというものがある。Lamportの論理クロックを用いた全順序マルチキャストの実行によってこれは解決できるが、大規模化が難しいため、中央コーディネータを設ける場合が多い。HyperledgerにおけるPBFTアルゴリズムはまさにこの形に近く、信頼できる機関がリーダー（Order）となってブロックの更新順序を管理する。しかし、これでは本来ブロックチェーンが目指していた非中央集権的なシステムの実現ができない。
一方Tendermintは、3相コミット形式を導入した独自のTenderimintコンセンサスによって全順序一貫性を維持する方法を取っている。さらに詳しい説明は”ブロックチェーンを形作る分散システムにおけるフォールトトレラント性https://mold.kibe.la/shared/entries/e70139f8-4dd0-4255-b2d2-d224733af8d2
）”で説明するが、全順序性と非中央集権性を同時に実現した新しいアクティブ複製プロトコルである。
— — — — — — — — — — — — — — — -
Cosmos Gaming Hub Project(旧MOLD Project)
CEO & Co-Founder
朝野 巧己
全てのゲーム愛好家に最高のエンターテイメントを届けるために
