こんにちは、サイオステクノロジーの香西です。
ここ半年ほど、NFT を中心に Ethereum での dApps の開発を PM として進めてきましたので、自分の理解の整理も兼ねて Ethereum や dApps 開発、 NFT に関する解説を中心に記載していきます。実際の開発ノウハウはほかの方に譲るとして、PM の方が理解しておいたほうがいいこと、まだ dApps 開発をしたことがないけどとりあえずざっくり理解したい開発エンジニア向けに連載していくつもりです。何回かの続き物にしたいと思っていますので、気に入った方は最後までお付き合いいただけるとありがたいです。今回はとりあえず導入・さわりといったところです。
dApps とは？
dApps の具体例として、Uniswap や OpenSea、STEPEN などすでに多くの有名なサービスが運営されていますので、名前は聞いたことがある、すでに利用しているという方も多いのではないでしょうか。日本国内では、特に日本では NFT 領域での開発が活発に行われているように見受けます。NFT マーケットマーケットプレイスや NFT ゲームはもちろん、NFT による卒業証書発行、ライブ来場者への特典など、その活用事例も増えてきています。国の方でもWeb3.0 の政策推進という文脈で、法整備含めて色々と進めているようです。
このような dApps ですが、Ethereum の公式ドキュメントによれば、dApps とは「スマートコントラクト とフロントエンドのユーザーインターフェイスを組み合わせた、分散型ネットワーク上に構築されたアプリケーションのこと」とあります。スマートコントラクトとは、ブロックチェーン上で動くプログラムのこと、ここでいう分散型ネットワークもブロックチェーンと捉えて間違いないです。すなわち、ブロックチェーン上で動くプログラムと web2 上のフロントエンドで構築されるものが dApps という理解で問題ありません。
dApps の基本アーキテクチャ
そんな dApps ですが、基本的なアーキテクチャは web2 と似通ったところがあります。フロントエンドは通常のブラウザ上で実行され、バックエンドに当たる部分(図の Provider 以下)がブロックチェーンの世界になります。フロント ⇔ Provider 間は JSON-RPC の定められた IF により連携され、ブロックチェーン上でロジックの実行、データの記憶が行われます。実際の dApps 開発では、web2 上の Back-end や DB は残ったまま、Back-end から Provider の IF を呼び出すといった Hybrid アーキテクチャを取られることも多いです。
よって、dApps を開発するとは、
- Front-end の開発
- Back-end の開発
- スマートコントラクトの開発
の 3 つのプログラム開発を行うということになリます。
Front-end/Back-end の開発に関しては、基本的には従来の web2 開発と同様です。インフラの準備、言語・フレームワークの選定などを経て、開発を行う事が可能です。ただしより開発を効率的に進めることを考えるのであれば、Provider の選定に応じて開発言語は選定したほうが良いです。Alchemy や Infura などのサービスとしての Provider を用いる場合、これらサービスでは web3 上のノード提供だけでなく、より開発効率を向上させるようなフレームワーク、ライブラリを提供しているため、それを考慮した言語選定をすることにより、より効率的な開発を行うことができます。一方、ノードを自前で準備する際には、自分の好きな言語選定が可能です。前述の通りノードとは JSON-RPC で通信することになりますが、現在主流な javascript / python / ruby / php / java / c# / go といった開発言語では、活性度はともかくとしていずれもライブラリが準備はされていますので、これらをうまく活用して、ブロックチェーンと連携可能なフロント/バックの実装を行うことができます。
スマートコントラクトの開発に関しては、web2 の開発とはいくつかの点で顕著な違いがあります。例えば、以下のような点が明らかに異なります。
| 項目 | web2 | web3 |
|---|---|---|
| インフラ構成 | 検討必要 | 検討不要 |
| 性能・スケール | 検討必要 | 検討不可 |
| モジュール改変 | 可能 | 事前検討必要 |
| モジュールサイズ | 検討不要 | 検討必要 |
少し説明すると、web2 においてはインフラ構成の検討が必要になりますが、web3 ブロックチェーンはそれ自体が大きな計算機リソースであるため、その内部の構成というのはブロックチェーンそのものを構築する必要がない限り検討の必要はありません。逆に言うと、性能を良くするためにスケールアップ/スケールアウト的な発想はできず、ブロックの生成タイミングはブロックチェーンにより一定化されているため、dApps 側から処理の高速化を図るというのは基本できません(ブロックへの取り込みを早くするためには、ガス代を多く払うしかない)。またブロックチェーンでは、一度書き込まれたデータを修正することはできないため、ブロックチェーン上で動作するプログラム(スマートコントラクト)も同様に改変は不可能です。そのため、機能追加や不具合のためのバージョンアップを行うには、例えばプロキシパターンと言われるような予め特別なモジュール構成を実現しておく必要があります。同様にプログラムのファイルサイズにも制限があるため、ある程度の単位でプロジェクト自体を分割するといった考慮も必要です。この他にも、スマートコントラクトの開発で考慮すべきことは多くあります。
dApps 開発で考慮・検討しないといけないこと
前述の違いの他にも考慮しないといけないことは多くありますので、以下にざっと、開発に当たって考慮・検討しないといけないことを列挙します。
- ブロックチェーンの選定
- パブリック・プライベート・コンソーシアム、どのブロックチェーンを用いるのか。
- またパブリックであれば、Ethereum, Layer2, sidechain など、どのチェーンを用いるのか。
- ノードの形態選択
- 自前ノード でいくのか、ノードサービスを利用するのか
- フレームワーク・ライブラリの活用
- Truffle, OpenZeppelin, thirdweb を始め、多くのフレームワーク・ライブラリが存在
- Gas 代への配慮、EOA の管理
- ブロックチェーン上でプログラムを実行すると Gas 代と呼ばれる費用が発生。特に toC 向けサービスではそれを誰が負担するのか要考慮。
- ブロックチェーン上での実行には、Externally Owned Account(EOA)が必要。現状ではまだ metamask を所有していないユーザが大半なことから、特に toC 向けにおいて、どのように EOA を作成・管理するかが重要。
- 開発環境・テスト環境の選定
- 単体テスト、結合テストの実施の仕方、またその実行環境の選定が必要です。ブロックチェーンにはメインネットと呼ばれる本番ネットワーク以外にテストネットが用意されていますが、そこでの動作はテスト用の仮想通貨が必要となりますし、テストとはいえ一般ユーザから確認できる状態となる。
長くなってきましたので、今回はこのあたりで一旦終わります。今後、これらの考慮しないといけないことの深掘りや Ethereum を中心にブロックチェーンの仕組みの説明などを行っていくつもりです。ご興味が有りましたら、ひきつづきお読みいただければ幸いです。
ではまた次回。
